[U-Boot-Users] outline of bootm script

[Wolfgang Denk]

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?)

> > 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.


"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.

> 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?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real programmers can write assembly code in any language.   :-)
                      - Larry Wall in  <8571 at jpl-devvax.JPL.NASA.GOV>