[U-Boot-Users] bootm change for standalone images

[U-Boot-Users] bootm change for standalone images

[Andrew May]

I need to boot a HW test program and it expects to be loaded down at address 0x0
with the interrupt vectors laid out. So it is like a stupid homegrown OS.

I came up with this quick fix to check for a load to address 0x0 for a standalone
type, and not re-enable interrupts.

But I am not sure if the check would be universal.
Would it better to add a new type or flag to image header.

It looks like RTEMS is the simplest OS loader and it should work as
is with my image, but it would be nice to have a generic print instead.

-------------- next part --------------
--- u-boot-1.1.1/common/cmd_bootm.c	2004-04-18 14:13:43.000000000 -0700
+++ u-boot-gige2/common/cmd_bootm.c	2004-07-15 19:55:08.000000000 -0700
@@ -363,7 +363,7 @@
 
 	switch (hdr->ih_type) {
 	case IH_TYPE_STANDALONE:
-		if (iflag)
+		if ( ntohl(hdr->ih_load) != 0x0 && iflag)
 			enable_interrupts();
 
 		/* load (and uncompress), but don't start if "autostart"

[U-Boot-Users] bootm change for standalone images

[Wolfgang Denk]

Dear Andrew,

in message <20040727012114.GA22062@acmay.homeip.net> you wrote:
> 
> I need to boot a HW test program and it expects to be loaded down at address 0x0
> with the interrupt vectors laid out. So it is like a stupid homegrown OS.

This is a perfectly valid requirement.

> I came up with this quick fix to check for a load to address 0x0 for a standalone
> type, and not re-enable interrupts.

Thisi s not a good idea; at least it is not  general  enough  if  you
consider all the different architectures etc.

> But I am not sure if the check would be universal.
> Would it better to add a new type or flag to image header.

If you boot "a stupid homegrown OS" then do it  like  that:  use  the
"bootm" command for it.

> It looks like RTEMS is the simplest OS loader and it should work as
> is with my image, but it would be nice to have a generic print instead.

What exactly do you mean by "have a generic print instead" ?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Sometimes a man will tell his bartender things he'll never tell his doctor.
	-- Dr. Phillip Boyce, "The Menagerie" ("The Cage"),
	   stardate unknown.

[U-Boot-Users] bootm change for standalone images

[Andrew May]

On Wed, Jul 28, 2004 at 12:05:20AM +0200, Wolfgang Denk wrote:
> Dear Andrew,
> 
> in message <20040727012114.GA22062@acmay.homeip.net> you wrote:
.....
> > But I am not sure if the check would be universal.
> > Would it better to add a new type or flag to image header.
> 
> If you boot "a stupid homegrown OS" then do it  like  that:  use  the
> "bootm" command for it.
> 
> > It looks like RTEMS is the simplest OS loader and it should work as
> > is with my image, but it would be nice to have a generic print instead.
> 
> What exactly do you mean by "have a generic print instead" ?

Not until after I did the code and started to write the message
did I start to look at the other OS type boots.
Then I realized that the RTEMS bootm is just what I need. So
instead of adding a whole new type just change RTEMS to a generic
OS type, that may not care about the args.

So just change the function names and printf to make it obvious
it is a simple OS type. Also do a fall through case for both
RTEMS and GENERIC OS image types.

Here is an incomplete patch of what I mean.
-------------- next part --------------
--- u-boot-gige2/common/cmd_bootm.c	2004-07-15 19:55:08.000000000 -0700
+++ u-boot-gige2/common/cmd_bootm.c.test	2004-07-27 15:21:06.000000000 -0700
@@ -121,7 +121,7 @@
 static void fixup_silent_linux (void);
 #endif
 static boot_os_Fcn do_bootm_netbsd;
-static boot_os_Fcn do_bootm_rtems;
+static boot_os_Fcn do_bootm_generic_os;
 #if (CONFIG_COMMANDS & CFG_CMD_ELF)
 static boot_os_Fcn do_bootm_vxworks;
 static boot_os_Fcn do_bootm_qnxelf;
@@ -413,8 +413,9 @@
 #endif
 
 	case IH_OS_RTEMS:
-	    do_bootm_rtems (cmdtp, flag, argc, argv,
-			     addr, len_ptr, verify);
+	case IH_OS_GENERIC:
+	    do_bootm_generic (cmdtp, flag, argc, argv,
+                              addr, len_ptr, verify);
 	    break;
 
 #if (CONFIG_COMMANDS & CFG_CMD_ELF)
@@ -1302,7 +1303,7 @@
 #endif /* CONFIG_BZIP2 */
 
 static void
-do_bootm_rtems (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
+do_bootm_generic (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 		ulong addr, ulong *len_ptr, int verify)
 {
 	DECLARE_GLOBAL_DATA_PTR;
@@ -1311,7 +1312,7 @@
 
 	entry_point = (void (*)(bd_t *)) hdr->ih_ep;
 
-	printf ("## Transferring control to RTEMS (at address %08lx) ...\n",
+	printf ("## Transferring control to OS (at address %08lx) ...\n",
 		(ulong)entry_point);
 
 	SHOW_BOOT_PROGRESS (15);

[U-Boot-Users] bootm change for standalone images

[Wolfgang Denk]

In message <20040727223152.GA11596@acmay.homeip.net> you wrote:
> 
> So just change the function names and printf to make it obvious
> it is a simple OS type. Also do a fall through case for both
> RTEMS and GENERIC OS image types.

I don't think that this is a "generic" OS.

> Here is an incomplete patch of what I mean.

Frankly, I don't like it.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It may be that your whole purpose in life is simply  to  serve  as  a
warning to others.

[U-Boot-Users] bootm change for standalone images

[Andrew May]

On Wed, 2004-07-28 at 01:57, Wolfgang Denk wrote:
> In message <20040727223152.GA11596@acmay.homeip.net> you wrote:
> > 
> > So just change the function names and printf to make it obvious
> > it is a simple OS type. Also do a fall through case for both
> > RTEMS and GENERIC OS image types.
> 
> I don't think that this is a "generic" OS.

Do you not like the name. Are you concerned with belittling RTEMS?

> > Here is an incomplete patch of what I mean.
> 
> Frankly, I don't like it.

Any reason why or just a gut feeling?
I just wanted it to be small and simple. It seems like
a waste to do a whole new function that differs only in
the print and the args passed. Every other OS does a lot
more work.

Would you prefer something like this?
....
	case IH_TYPE_STANDALONE:
		if (iflag)
			enable_interrupts();

		/* load (and uncompress), but don't start if "autostart"
		 * is set to "no"
		 */
		if (((s = getenv("autostart")) != NULL) && (strcmp(s,"no") == 0)) {
			char buf[32];
			sprintf(buf, "%lX", len);
			setenv("filesize", buf);
			return 0;
		}
	case IH_TYPE_STANDALONE_DISABLE_IRQ:
		appl = (int (*)(int, char *[]))ntohl(hdr->ih_ep);
		(*appl)(argc-1, &argv[1]);
		return 0;

[U-Boot-Users] bootm change for standalone images

[Wolfgang Denk]

In message <1091044779.17855.13.camel@mud> you wrote:
>
> > I don't think that this is a "generic" OS.
> 
> Do you not like the name. Are you concerned with belittling RTEMS?

I don't like the term "generic OS" because  IMHO  there  is  no  such
thing.

> > Frankly, I don't like it.
> 
> Any reason why or just a gut feeling?

A bit more than this, but difficult to put in words.

What you have is clearly NOT a U-Boot standalone application - which,
by definition, will be based on services provided by U-Boot and after
succesful completion will return to U-Boot. Since you  overwrite  the
exception  vector code you cannot use U-Boot services, and you cannot
return.

So you must have something different...


> I just wanted it to be small and simple. It seems like

Yes, I understand this.

> Would you prefer something like this?
> ....
> 	case IH_TYPE_STANDALONE:
...
> 	case IH_TYPE_STANDALONE_DISABLE_IRQ:

No, of course not - see above. The environment for U-Boot  standalone
applications  is  well defined (at least in my head), and it does NOT
allow you to overwrite any of U-Boot's code, including the  exception
vectors.

To avoid duplicating code or to use misleading names I see two simple
options: (1) just use "-O RTEMS" when building your images and  gnash
your    teeth    when    you   see   "RTEMS"   printed   instead   of
"your_custom_code_without_a_proper_name", or (2)  give  your  code  a
name  which we can add as new OS type, and let's use the RTEMS booter
for your new "OS", too.

I think I'd like to see you chosing (1).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Behind every great man, there is a woman -- urging him on.
	-- Harry Mudd, "I, Mudd", stardate 4513.3

[U-Boot-Users] bootm change for standalone images

[Andrew May]

On Wed, 2004-07-28 at 14:22, Wolfgang Denk wrote:
> In message <1091044779.17855.13.camel@mud> you wrote:
> To avoid duplicating code or to use misleading names I see two simple
> options: (1) just use "-O RTEMS" when building your images and  gnash
> your    teeth    when    you   see   "RTEMS"   printed   instead   of
> "your_custom_code_without_a_proper_name", or (2)  give  your  code  a
> name  which we can add as new OS type, and let's use the RTEMS booter
> for your new "OS", too.

Well I may just do (1), but I wanted to make it easier for the next poor
soul that had the same issue. It is not obvious at all that RTEMS would
work for more than just RTEMS.

The other thing with names is that standalone sure doesn't standalone
when it uses U-Boot to do console IO for it. So when I was looking at
the code and doing mkimage I saw the choices and though well my
code wants to standalone, so the standalone image sounds good.
Sure the README describes standalone very well, but it doesn't help
when it seems to go against the dictionary definition of the word.

So I don't want to push for changing names around, but I hope you at
least understand my confusion.

[U-Boot-Users] bootm change for standalone images

[Wolfgang Denk]

In message <1091121391.19389.33.camel@mud> you wrote:
>
> Well I may just do (1), but I wanted to make it easier for the next poor
> soul that had the same issue. It is not obvious at all that RTEMS would
> work for more than just RTEMS.

Well, it will work for anything which has the same call interface.

> The other thing with names is that standalone sure doesn't standalone
> when it uses U-Boot to do console IO for it. So when I was looking at

"standalone" is intended to mean "runs without  OS".  You  just  have
special  requirements  which don;t fit in the implemented model. [You
could work around these, though. For example you  could  implement  a
"real"  U-Boot  standalone  proram,  which first disables interrupts,
then installs it's own exception vector table, and then goes on doing
whatever it likes to do.]

> the code and doing mkimage I saw the choices and though well my
> code wants to standalone, so the standalone image sounds good.
> Sure the README describes standalone very well, but it doesn't help
> when it seems to go against the dictionary definition of the word.

You are expected to read the documentation. It says: "runnable in the
environment provided by U-Boot" and "continue to work in U-Boot after
return from the Standalone Program". 

> So I don't want to push for changing names around, but I hope you at
> least understand my confusion.

Maybe you can suggest a better description of  "Standalone  Programs"
that what's give in the README to avoid confusion like uyours?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
This is a story about sex and drugs and Music with Rocks In.  Well...
...one out of three ain't bad.  Actually, it's only thirty-three per-
cent, but it could be worse.          - Terry Pratchett, _Soul Music_

[U-Boot-Users] bootm change for standalone images

[Andrew May]

On Thu, 2004-07-29 at 10:29, Wolfgang Denk wrote:
> In message <1091121391.19389.33.camel@mud> you wrote:
> > So I don't want to push for changing names around, but I hope you at
> > least understand my confusion.
> 
> Maybe you can suggest a better description of  "Standalone  Programs"
> that what's give in the README to avoid confusion like uyours?

I think you missed the point. The README is great, but the word
"Standalone" is misleading.
Here is a stupid example.
You can call something a cat in the code but describe it as a dog
in the docs as explicitly as possible, but people will still be
confused.

I would suggest "U-boot App" instead of "standalone".