[U-Boot-Users] bootm change for standalone images
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.
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
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.
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
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;
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
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.
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
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".
participants (2)
-
Andrew May -
Wolfgang Denk