[U-Boot-Users] outline of bootm script

Jerry Van Baren
2008-08-06T20:39:30Z

Kumar Gala wrote:
>
> On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:

[snip]

>> Having said that, I was thinking and would advocate pushing
>> functionality out of bootm and into other commands, as appropriate.
>> As an example, bootm doesn't need to do *any* fdt stuff, the "fdt"
>> built-in has all the capability we need (or should).
>
> except for locating the fdt at the right location and dealing w/initrd
> (but that could possibly be fixed).
>
>> The same may be also true about load_os and load_initrd - they are
>> copy-with-(optional)-
>> decompression operations (we may need additional commands for these).
>>
>> Philosophy: bootm should do only bootm stuff. It (probably) should
>> not do any image stuff (find/copy/decompress/verify). It (probably)
>> should not do any fdt stuff (board fixup, other?). Etc...
>
> This DOES NOT WORK... sorry I'm trying to make progress on this and I'm
> not getting suggestions on a solutions just gripes about what I'm
> suggesting.
>
> The problem with breaking things up is that you HAVE to disable
> interrupts and USB before you can reasonable load the OS image. Are we
> could to add a command for each "prereq". How does a user know if they
> need to "disable_caches" on their board or not?

Understood, there are some things that inherently must be done in bootm.
That is why it is a philosophy and not a rule. ;-)

> Also there is logic in the bootm that knows how to layout the images
> based on the constraints of memory. Let use an example (assume OS image
> will be loaded at 0):
>
> bootm 1000000 - fff00000
>
> we load to 0, the resulting size is 1234151 bytes. So we set "filesize"
> to 0x12D4E7. Since the fdt is in flash we have to copy it to memory.
>
> So what address do we copy it to? 0x12D4E7? No because we have to be
> 8-byte aligned. So 0x12D4F0? No because we have to ensure space for the
> kernel .bss. So we have to encode all that logic in the script? That's
> just asking for pain.
>
> - k

I agree with you, ideally the script would be just a sequence of
cmd && cmd && cmd && cmd
with no conditionals other than, if a cmd failed, it aborts the sequence
(I'm assuming the last "cmd" would be where the point of no return is
embedded: copying the image over the interrupt vectors, etc.).

My thoughts are that addresses would be handled by setting env variables
initially and/or as a side effect of a cmd (yeah, side effects are
yucky) and what is currently hard-coded as conditionals in the code
would be re-scripted as /n/ scripts, where /n/ is some subset of the
permutations of however many conditionals the current bootm has.

We will have to see how it plays out in reality...
gvb