[U-Boot-Users] outline of bootm script

[Kumar Gala]

On Aug 6, 2008, at 3:36 PM, Wolfgang Denk wrote:

> In message <6130E31C-5845-4DCF- 
> A24C-4436DA575808 at kernel.crashing.org> you wrote:
>>
>>> Ooo, that sounds hard.  If we are only re-enabling interrupts/usb/
>>> caches it probably is manageable, but my hackles.
>>
>> This is a buyer-beware kinda of situation.  Think about a case that  
>> we
>> are booting a kernel at a location of memory that NO hw (usb,
>> interrupts, etc) would be touching.  In that case you an reasonable
>> 'bootm restore'
>
> Our exerience is that a consisten user interface and behaviour is much
> more important that to actually offer all options that are technically
> possible.
>
> For the sake of mind of a clean user interface I vote  not  to  spend
> efforts on implementing such a special behaviour (which is of limited
> value  anyway  -  what is the big difference between a recovery and a
> reset?)

Its not about recovery/reset...

>>> 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?
>
> I think the average user does not need to now this. He can  just  run
> the  systemn-provided  "bootm"  command  without  caring if this is a
> monolithic pile of unreeadable  code,  or  a  wrapper  function  that
> sequentially calls out for a list of simple helper functions, or some
> sort  of  script  (or  list  of  commands  stored  in  an environment
> variable) that get executed.
>
> But the developer gets the freedom to implement exactly the behaviour
> he wants by being able to redefine the steps he rund and their order.

I understand.. but moving ALL the control logic that exists in bootm  
into a script language just seem like a bad idea to me.  This means  
boots will be that much slower as we have to parse all this control  
logic in the "shell".

> "UNIX was not designed to stop you from doing stupid things,  because
> that would also stop you from doing clever things."       - Doug Gwyn
>
>
>> 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.
>
> Stop, this is not correct. "filesize" gets set when loading the
> (compressed) image. It contains the _file_ size, i. e. the sum of all
> included images plus headers etc.
>
> bootm does not touch filesize.

in the method you guys seem to be arguing for we have to return the  
address the image was loaded at and the size.  W/o this info I dont  
see how the next step can decide where to boot the .dtb or initrd.  I  
was just 'filesize' just as part of my example.

>> 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.
>
> Why cannot U-Boot just malloc() space for the fdt?

Because the memory malloc() gives me isn't guaranteed to meet the set  
of constraints we have.  (the memory can't be part of the OS image,  
has to be properly aligned, has to be within the BOOTMAP_SZ).

- k