[U-Boot-Users] outline of bootm script

[U-Boot-Users] outline of bootm script

[Kumar Gala]

here's a rough start at an outline for the bootm script based on the  
code (I've only outlined the Linux/PPC boot case its seems the most  
complicated).  One of the first things we clearly need is a imload  
command.  Thoughts on the various disable_{interrupts, usb, caches} ?

- k

bootm script:

	disable_interrupts		/* sets an env with the state of interrupts  
before disabling */
#ifdef CONFIG_CMD_USB
	disable_usb
#endif
#ifdef CONFIG_AMIGAONEG3SE
	disable_caches
#endif
	imload <kernel_image>
	
	switch(on OS type from imload)

		LINUX:
			if (fdt)
				fdt relocate to after kernel_image + padding
				fdt fixups (board setup, etc)

			if (ramdisk)
				imload ramdisk
				if (fdt)
					fixup initrd info in fdt
			bootm_linux
		...

- k

[U-Boot-Users] outline of bootm script

[Jerry Van Baren]

Kumar Gala wrote:
> here's a rough start at an outline for the bootm script based on the  
> code (I've only outlined the Linux/PPC boot case its seems the most  
> complicated).  One of the first things we clearly need is a imload  
> command.  Thoughts on the various disable_{interrupts, usb, caches} ?
> 
> - k

Another rough start on an outline (only cmd_bootm.c, need to add image.c 
information):
   <http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm>

Goal is to identify the major pieces of the sequence, identify what 
commands we have and what we need to make a scripted equivalent sequence 
for (ultimately) each path through the sequence.

Best regards,
gvb

[U-Boot-Users] outline of bootm script

[Kumar Gala]

On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> here's a rough start at an outline for the bootm script based on  
>> the  code (I've only outlined the Linux/PPC boot case its seems the  
>> most  complicated).  One of the first things we clearly need is a  
>> imload  command.  Thoughts on the various disable_{interrupts, usb,  
>> caches} ?
>> - k
>
> Another rough start on an outline (only cmd_bootm.c, need to add  
> image.c information):
>  <http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm>
>
> Goal is to identify the major pieces of the sequence, identify what  
> commands we have and what we need to make a scripted equivalent  
> sequence for (ultimately) each path through the sequence.

I added a few bullets about functionality I'd like to see the new  
sequence to be capable of it.

one idea is having "stages" of bootm handled as sub commands:

bootm start <args>
bootm prep    (disable interrupts, stop usb, disable caches)
bootm load_os (decompress OS image)
bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd  
prep, board setup?? [or do via fdt boardsetup command])
bootm load_initrd
bootm jump

bootm restore (undo anything prep did, reset state tracking)

And we keep state around so the next stage can run w/o a lot of  
arguments and you have to execute these in order, and only once.  But  
you can intermix other commands between the stages.

We could also have some "bootm query <foo>" to expose the internal  
state if that's useful.  We could completely get rid of the various  
"env" vars that impact bootm and just make them state variables  
("verify", "autostart", "bootm_size", "bootm_low", ...)

Also, bootm would be the sequence of:
   bootm start <args>
   bootm prep
   bootm load_os
   bootm load_fdt
   bootm load_initrd
   bootm jump

comments?

- k

[U-Boot-Users] outline of bootm script

[Wolfgang Denk]

In message <5E53E387-237D-480E-A046-68AD7F9B90A5@kernel.crashing.org> you wrote:
> 
> one idea is having "stages" of bootm handled as sub commands:
> 
> bootm start <args>
> bootm prep    (disable interrupts, stop usb, disable caches)
--- Point of no return here ---
> bootm load_os (decompress OS image)
> bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd  
> prep, board setup?? [or do via fdt boardsetup command])
> bootm load_initrd
> bootm jump
> 
> bootm restore (undo anything prep did, reset state tracking)

Note that you cannot recover / restore after starting to uncompress
the image, because usually you will overwrite the exception vectors.

> And we keep state around so the next stage can run w/o a lot of  
> arguments and you have to execute these in order, and only once.  But  
> you can intermix other commands between the stages.

Sounds like Fortran to me - let's have a big COMMON section ;-)

I'm not sure if this leads to good design.

> We could also have some "bootm query <foo>" to expose the internal  
> state if that's useful.  We could completely get rid of the various  
> "env" vars that impact bootm and just make them state variables  
> ("verify", "autostart", "bootm_size", "bootm_low", ...)

I have to admit that I have no idea why "bootm_size" or "bootm_low"
are needed. If we can drop these, all the better.

"verify" and "autostart"  must  be  kept  as  environment  variables,
because that's the way how the user can influence the boot behaviour.
Even  if you find a better way to implement this, they will be needed
for backward compatibility.

> Also, bootm would be the sequence of:
>    bootm start <args>
>    bootm prep
>    bootm load_os
>    bootm load_fdt
>    bootm load_initrd
>    bootm jump

I'm asking myself if that order is technically necessary. IMHO it
should be possible as well to move the load_fdt step before load_os
and eventually before prep, too.

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
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy  arrangement  for
the people.                                       - Eleanor Roosevelt

[U-Boot-Users] outline of bootm script

[Kumar Gala]

On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:

> In message <5E53E387-237D-480E- 
> A046-68AD7F9B90A5 at kernel.crashing.org> you wrote:
>>
>> one idea is having "stages" of bootm handled as sub commands:
>>
>> bootm start <args>
>> bootm prep    (disable interrupts, stop usb, disable caches)
> --- Point of no return here ---
>> bootm load_os (decompress OS image)
>> bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd
>> prep, board setup?? [or do via fdt boardsetup command])
>> bootm load_initrd
>> bootm jump
>>
>> bootm restore (undo anything prep did, reset state tracking)
>
> Note that you cannot recover / restore after starting to uncompress
> the image, because usually you will overwrite the exception vectors.

Normally that is true.. however there are some situations that its  
feasible.  For example if you are booting a kernel at a non-zero  
address.  We do this on 85xx HW.  Or if you are trying to boot a  
kernel on the second core of a dual core setup (at a non-zero  
address).  Both of these cases we can 'bootm restore' out of.

>> And we keep state around so the next stage can run w/o a lot of
>> arguments and you have to execute these in order, and only once.  But
>> you can intermix other commands between the stages.
>
> Sounds like Fortran to me - let's have a big COMMON section ;-)
>
> I'm not sure if this leads to good design.

I'm trying to reduce have A LOT of control logic in the script.  There  
is a fair amount of state needed between the various stages.

>> We could also have some "bootm query <foo>" to expose the internal
>> state if that's useful.  We could completely get rid of the various
>> "env" vars that impact bootm and just make them state variables
>> ("verify", "autostart", "bootm_size", "bootm_low", ...)
>
> I have to admit that I have no idea why "bootm_size" or "bootm_low"
> are needed. If we can drop these, all the better.

We use them for booting at non-zero locations.

> "verify" and "autostart"  must  be  kept  as  environment  variables,
> because that's the way how the user can influence the boot behaviour.
> Even  if you find a better way to implement this, they will be needed
> for backward compatibility.

Ok.  What did we decide 'autostart' means with regards to bootm?

>> Also, bootm would be the sequence of:
>>   bootm start <args>
>>   bootm prep
>>   bootm load_os
>>   bootm load_fdt
>>   bootm load_initrd
>>   bootm jump
>
> I'm asking myself if that order is technically necessary. IMHO it
> should be possible as well to move the load_fdt step before load_os
> and eventually before prep, too.

If you know the layout of memory than its not fully needed.  The issue  
is knowing how big the uncompress kernel is.

- k

[U-Boot-Users] outline of bootm script

[Wolfgang Denk]

In message <B754896C-6D4C-43B0-8F84-062884E569C2@kernel.crashing.org> you wrote:
> 
> > Note that you cannot recover / restore after starting to uncompress
> > the image, because usually you will overwrite the exception vectors.
> 
> Normally that is true.. however there are some situations that its  
> feasible.  For example if you are booting a kernel at a non-zero  
> address.  We do this on 85xx HW.  Or if you are trying to boot a  
> kernel on the second core of a dual core setup (at a non-zero  
> address).  Both of these cases we can 'bootm restore' out of.

Agreed. But compare the benefit of such a soft recovery (versus a
reset of the board) against the added complexity and irregular user
interface - on this board you can write to low RAM, on the other board
you crash the system; on one board the system recovers after a failed
attempt to load a kernel, but maybe not always, just in certain cases,
on another board it always resets the board.

KISS. Define a point of no return, and after that, recovery == reset.

> > I have to admit that I have no idea why "bootm_size" or "bootm_low"
> > are needed. If we can drop these, all the better.
> 
> We use them for booting at non-zero locations.

Why is this needed?

> > "verify" and "autostart"  must  be  kept  as  environment  variables,
> > because that's the way how the user can influence the boot behaviour.
> > Even  if you find a better way to implement this, they will be needed
> > for backward compatibility.
> 
> Ok.  What did we decide 'autostart' means with regards to bootm?

Yes, of course we did. It means exactly what's documented in the
manual.


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
Copy from one, it's plagiarism; copy from two, it's research.

[U-Boot-Users] outline of bootm script

[Kumar Gala]

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

> In message  
> <B754896C-6D4C-43B0-8F84-062884E569C2@kernel.crashing.org> you wrote:
>>
>>> Note that you cannot recover / restore after starting to uncompress
>>> the image, because usually you will overwrite the exception vectors.
>>
>> Normally that is true.. however there are some situations that its
>> feasible.  For example if you are booting a kernel at a non-zero
>> address.  We do this on 85xx HW.  Or if you are trying to boot a
>> kernel on the second core of a dual core setup (at a non-zero
>> address).  Both of these cases we can 'bootm restore' out of.
>
> Agreed. But compare the benefit of such a soft recovery (versus a
> reset of the board) against the added complexity and irregular user
> interface - on this board you can write to low RAM, on the other board
> you crash the system; on one board the system recovers after a failed
> attempt to load a kernel, but maybe not always, just in certain cases,
> on another board it always resets the board.
>
> KISS. Define a point of no return, and after that, recovery == reset.

Its not about recovery.  Its about using the mechanism to setup the  
memory state to run and than using another command to jump.  In a dual  
core setup we can run u-boot on core0 and use all the bootm commands  
but 'jump' to setup the state of memory.  Than we can use the 'cpu'  
command to 'release' core1 to run that OS.

>>> I have to admit that I have no idea why "bootm_size" or "bootm_low"
>>> are needed. If we can drop these, all the better.
>>
>> We use them for booting at non-zero locations.
>
> Why is this needed?

We have customers that want to run at non-zero address.  Think of a  
dual core chip with a custom OS that 0 and Linux running at 256M.  (We  
allow this and have customers running in such situations).

>>> "verify" and "autostart"  must  be  kept  as  environment   
>>> variables,
>>> because that's the way how the user can influence the boot  
>>> behaviour.
>>> Even  if you find a better way to implement this, they will be  
>>> needed
>>> for backward compatibility.
>>
>> Ok.  What did we decide 'autostart' means with regards to bootm?
>
> Yes, of course we did. It means exactly what's documented in the
> manual.

ok.

- k

[U-Boot-Users] outline of bootm script

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> here's a rough start at an outline for the bootm script based on  
>>> the  code (I've only outlined the Linux/PPC boot case its seems the  
>>> most  complicated).  One of the first things we clearly need is a  
>>> imload  command.  Thoughts on the various disable_{interrupts, usb,  
>>> caches} ?
>>> - k
>> Another rough start on an outline (only cmd_bootm.c, need to add  
>> image.c information):
>>  <http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm>
>>
>> Goal is to identify the major pieces of the sequence, identify what  
>> commands we have and what we need to make a scripted equivalent  
>> sequence for (ultimately) each path through the sequence.
> 
> I added a few bullets about functionality I'd like to see the new  
> sequence to be capable of it.

Thanks for updating the page.

> one idea is having "stages" of bootm handled as sub commands:
> 
> bootm start <args>
> bootm prep    (disable interrupts, stop usb, disable caches)
> bootm load_os (decompress OS image)
> bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd  
> prep, board setup?? [or do via fdt boardsetup command])

fdt boardsetup - absolutely!

> bootm load_initrd
> bootm jump
> 
> bootm restore (undo anything prep did, reset state tracking)

Ooo, that sounds hard.  If we are only re-enabling interrupts/usb/caches 
it probably is manageable, but my hackles.

> And we keep state around so the next stage can run w/o a lot of  
> arguments and you have to execute these in order, and only once.  But  
> you can intermix other commands between the stages.
> 
> We could also have some "bootm query <foo>" to expose the internal  
> state if that's useful.  We could completely get rid of the various  
> "env" vars that impact bootm and just make them state variables  
> ("verify", "autostart", "bootm_size", "bootm_low", ...)

State is bad.

Aside: verify should be an image verify command, not a env variable flag 
(see below).  This is probably true of most of the current env 
variables: the reason we need them is because we kept throwing stuff 
into "bootm" and then controlling it with env variables rather than 
having a sequence and controlling it with what commands are in the 
sequence.  (Part of my simplification argument...)

> Also, bootm would be the sequence of:
>    bootm start <args>
>    bootm prep
>    bootm load_os
>    bootm load_fdt
>    bootm load_initrd
>    bootm jump
> 
> comments?
> 
> - k

I also was thinking we should invent a new major/minor command as you 
outlined, but it didn't occur to me that "bootm" would be a good major 
command.  This is a good idea: a bare "bootm <addr> (<addr>|-) <addr>" 
could be used for backward compatibility and "bootm <subcmd>" for New 
Improved[tm] functionality.

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

Thanks,
gvb

[U-Boot-Users] outline of bootm script

[Kumar Gala]

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

> Kumar Gala wrote:
>> On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
>>> Kumar Gala wrote:
>>>> here's a rough start at an outline for the bootm script based on   
>>>> the  code (I've only outlined the Linux/PPC boot case its seems  
>>>> the  most  complicated).  One of the first things we clearly need  
>>>> is a  imload  command.  Thoughts on the various  
>>>> disable_{interrupts, usb,  caches} ?
>>>> - k
>>> Another rough start on an outline (only cmd_bootm.c, need to add   
>>> image.c information):
>>> <http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm>
>>>
>>> Goal is to identify the major pieces of the sequence, identify  
>>> what  commands we have and what we need to make a scripted  
>>> equivalent  sequence for (ultimately) each path through the  
>>> sequence.
>> I added a few bullets about functionality I'd like to see the new   
>> sequence to be capable of it.
>
> Thanks for updating the page.
>
>> one idea is having "stages" of bootm handled as sub commands:
>> bootm start <args>
>> bootm prep    (disable interrupts, stop usb, disable caches)
>> bootm load_os (decompress OS image)
>> bootm load_fdt(relocates fdt to proper place, setup bootargs,  
>> initrd  prep, board setup?? [or do via fdt boardsetup command])
>
> fdt boardsetup - absolutely!
>
>> bootm load_initrd
>> bootm jump
>> bootm restore (undo anything prep did, reset state tracking)
>
> 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'

>> And we keep state around so the next stage can run w/o a lot of   
>> arguments and you have to execute these in order, and only once.   
>> But  you can intermix other commands between the stages.
>> We could also have some "bootm query <foo>" to expose the internal   
>> state if that's useful.  We could completely get rid of the  
>> various  "env" vars that impact bootm and just make them state  
>> variables  ("verify", "autostart", "bootm_size", "bootm_low", ...)
>
> State is bad.
> Aside: verify should be an image verify command, not a env variable  
> flag (see below).  This is probably true of most of the current env  
> variables: the reason we need them is because we kept throwing stuff  
> into "bootm" and then controlling it with env variables rather than  
> having a sequence and controlling it with what commands are in the  
> sequence.  (Part of my simplification argument...)
>
>> Also, bootm would be the sequence of:
>>   bootm start <args>
>>   bootm prep
>>   bootm load_os
>>   bootm load_fdt
>>   bootm load_initrd
>>   bootm jump
>> comments?
>> - k
>
> I also was thinking we should invent a new major/minor command as  
> you outlined, but it didn't occur to me that "bootm" would be a good  
> major command.  This is a good idea: a bare "bootm <addr> (<addr>|-)  
> <addr>" could be used for backward compatibility and "bootm  
> <subcmd>" for New Improved[tm] functionality.
>
> 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?

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

[U-Boot-Users] outline of bootm script

[Wolfgang Denk]

In message <6130E31C-5845-4DCF-A24C-4436DA575808@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@jpl-devvax.JPL.NASA.GOV>

[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

[U-Boot-Users] outline of bootm script

[Wolfgang Denk]

In message <1083C28A-076D-4D63-B9B6-9FFFABFF4B54@kernel.crashing.org> you wrote:
> 
> > 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".

If you compare the number of CPU cycles it takes to uncompress a
recent kernel image against the cycles needed to parse a line of shell
commands I am pretty sure that this will not actually matter. Even if
it was a few milliseconds - that's something I'm more than willing to
pay for the all the much cleaner code.

And keep in mind that this applies only to the expert user who plays
shell tricks; Johnny Luser will just run the pre-canned function
builtin.

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

No, we pass the load address as argument to the loader / uncompressor.
Just like we are doing it now.

> see how the next step can decide where to boot the .dtb or initrd.  I  
> was just 'filesize' just as part of my example.

Well, at the moment we don't do any such clever stuff eihter. We load
the kernel low and the ramdisk high. That's all.

Do we need more?

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

So load it high within the limits of BOOTMAP_SZ.

Please read the README again - it explains the whole philosophy as it
used to be implemented 8 years ago - plain simple and reliable:  load
the  kernel  low  (because  that's  what  the kernel needed), and the
ramdisk high  (within  the  limits  of  RAM  size  and,  if  defined,
initrd_high).  If  you  want  to  stick in the DTB here, then load it
before the ramdisk, and the ramdisk below it. The DTB size is easy to
get, me thinks.

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
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
                                                        -- S. Beckett

[U-Boot-Users] outline of bootm script

[Kumar Gala]

>>> 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
>
> No, we pass the load address as argument to the loader / uncompressor.
> Just like we are doing it now.
>
>> see how the next step can decide where to boot the .dtb or initrd.  I
>> was just 'filesize' just as part of my example.
>
> Well, at the moment we don't do any such clever stuff eihter. We load
> the kernel low and the ramdisk high. That's all.
>
> Do we need more?

Yes. bd_t for old style boot... no idea on non-ppc.

Have you looked at the fdt handling code in lib_ppc/bootm.c:

look at boot_get_fdt(), boot_relocate_fdt() and think about recoding  
that in a script. eeck!

>>> 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).
>
> So load it high within the limits of BOOTMAP_SZ.
>
> Please read the README again - it explains the whole philosophy as it
> used to be implemented 8 years ago - plain simple and reliable:  load
> the  kernel  low  (because  that's  what  the kernel needed), and the
> ramdisk high  (within  the  limits  of  RAM  size  and,  if  defined,
> initrd_high).  If  you  want  to  stick in the DTB here, then load it
> before the ramdisk, and the ramdisk below it. The DTB size is easy to
> get, me thinks.


dtb size is NOT easy to get.  It can change significantly between the  
"raw" dtb and after "fdt boardsetup".

- k

[U-Boot-Users] outline of bootm script

[Wolfgang Denk]

In message <1C0F961D-7380-4114-8114-BD36157C2618@kernel.crashing.org> you wrote:
>
> > Well, at the moment we don't do any such clever stuff eihter. We load
> > the kernel low and the ramdisk high. That's all.
> >
> > Do we need more?
> 
> Yes. bd_t for old style boot... no idea on non-ppc.

bd_t is already handled as described.

> dtb size is NOT easy to get.  It can change significantly between the  
> "raw" dtb and after "fdt boardsetup".

I still think that it should be easy to implement a function to
return the current size (plus padding, if needed).

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
Felson's Law:
	To steal ideas from one person is plagiarism; to steal from
	many is research.

[U-Boot-Users] bootm -- load_os inputs/outputs

[Kumar Gala]

So I proposed something like:

bootm load_os
bootm load_fdt

so I figured trying to expand on what load_os does might be useful.

input:
ENV:bootm_low
ENV:bootm_size
BOOTMAP_SZ
image specifier (a standalone uImage, a multi-uImage, a FIT specifier)

output:
ERROR: if image doesn't pass validity checks
ERROR: (if image is compressed) error during decompression
ERROR: if resulting decompress exceeds, bootm_size/BOOTMAP_SZ
ERROR: if image load address is less than bootm_low

ENV?: image OS type (LINUX, NETBSD, etc..)
ENV?: LMB to keep track of memory regions used
ENV?: entry point
MEM: "raw memory image, decompressed, no header, etc."

I think that's everything..

So my suggestion is to keep track of the image OS type, LMB, entry  
point via the existing global 'static bootm_headers_t images'.  If  
this is not acceptable it means adding support to some how pass around  
the LMB info via env var.

comments?

- k

[U-Boot-Users] outline of bootm script

[Jerry Van Baren]

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

[U-Boot-Users] outline of bootm script

[Wolfgang Denk]

In message <489A01A3.6000800@ge.com> you wrote:
>
> > bootm restore (undo anything prep did, reset state tracking)
> 
> Ooo, that sounds hard.  If we are only re-enabling interrupts/usb/caches 
> it probably is manageable, but my hackles.

ACK. And if we really restore anything, than just interrupts and
caches, but not any interfaces.

> > We could also have some "bootm query <foo>" to expose the internal  
> > state if that's useful.  We could completely get rid of the various  
> > "env" vars that impact bootm and just make them state variables  
> > ("verify", "autostart", "bootm_size", "bootm_low", ...)
> 
> State is bad.

ACK.

> Aside: verify should be an image verify command, not a env variable flag 
> (see below).  This is probably true of most of the current env 

We alreay have a verify command. It's called "imls".

> variables: the reason we need them is because we kept throwing stuff 
> into "bootm" and then controlling it with env variables rather than 
> having a sequence and controlling it with what commands are in the 
> sequence.  (Part of my simplification argument...)

Hint: keep it backwards compatible, please.

> I also was thinking we should invent a new major/minor command as you 
> outlined, but it didn't occur to me that "bootm" would be a good major 
> command.  This is a good idea: a bare "bootm <addr> (<addr>|-) <addr>" 
> could be used for backward compatibility and "bootm <subcmd>" for New 
> Improved[tm] functionality.

How do your differentiate beween <addr> and <subcmd> then?

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

ACK.

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

ACK.

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
To live is always desirable.
	-- Eleen the Capellan, "Friday's Child", stardate 3498.9

[U-Boot-Users] outline of bootm script

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <489A01A3.6000800@ge.com> you wrote:

[snip]

>> Aside: verify should be an image verify command, not a env variable flag 
>> (see below).  This is probably true of most of the current env 
> 
> We alreay have a verify command. It's called "imls".

<ack>

>> variables: the reason we need them is because we kept throwing stuff 
>> into "bootm" and then controlling it with env variables rather than 
>> having a sequence and controlling it with what commands are in the 
>> sequence.  (Part of my simplification argument...)
> 
> Hint: keep it backwards compatible, please.

Yes, and then deprecate it.  ;-)

>> I also was thinking we should invent a new major/minor command as you 
>> outlined, but it didn't occur to me that "bootm" would be a good major 
>> command.  This is a good idea: a bare "bootm <addr> (<addr>|-) <addr>" 
>> could be used for backward compatibility and "bootm <subcmd>" for New 
>> Improved[tm] functionality.
> 
> How do your differentiate beween <addr> and <subcmd> then?

Don't use deadbeef as a command?  ;-)  With judicious choices for subcmd 
names, we can first check for subcmd and fall through to the backward 
compatibility.

[snip]

Best regards,
gvb