[U-Boot-Users] simplify bootm command

[U-Boot-Users] simplify bootm command

[Kumar Gala]

If we really want to simplify what bootm does than I think we should  
remove ft_board_setup() from lib_ppc/bootm.c and expect any actually  
modification of the device tree to have already occurred.

Is this something we'd really be willing to do?

- k

diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 81803dd..8a86d52 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -190,10 +190,6 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int  
argc, char *argv[],
                         fdt_error ("/chosen node create failed");
                         goto error;
                 }
-#ifdef CONFIG_OF_BOARD_SETUP
-               /* Call the board-specific fixup routine */
-               ft_board_setup(of_flat_tree, gd->bd);
-#endif
         }

         /* Fixup the fdt memreserve now that we know how big it is */

[U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Kumar Gala wrote:
> If we really want to simplify what bootm does than I think we should  
> remove ft_board_setup() from lib_ppc/bootm.c and expect any actually  
> modification of the device tree to have already occurred.
> 
> Is this something we'd really be willing to do?
> 
> - k

I don't think so.  We would horribly break backward compatibility and 
make a severe mess for those trying to Just Ship Product[tm].

My current best thought is to create a new "boot simple" (boots? 
bootsm?) command that contains only the essence of bootm.  I would then 
change the command "bootm" to do a hush script run of the env variable 
"bootm" (i.e. the command "bootm" would really just be "run bootm"). 
The env variable "bootm" would then have to be created with the complex 
(board/config appropriate) sequence that is currently hardcoded in the 
command "bootm", with the last command being "boots", of course.  This 
would be selected by a new CONFIG_ configuration so that old boards 
would go on as is until or unless the maintainer chose to move forward.

We probably would be able to auto-create the appropriate bootm script 
string via the C preprocessor (ala the current "bootm" command), in 
which case we could transparently replace the hardcoded "bootm" command 
with a bootm script, remaining backwards compatible.  I'm thinking the 
New Improved[tm] "bootm" command would look for a "bootm" env variable 
and, if it was not found, run a cpp-generated built-in script string 
that implemented the present "bootm" sequence.

Best regards,
gvb

[U-Boot-Users] simplify bootm command

[Wolfgang Denk]

In message <48982523.4030706@gmail.com> you wrote:
>
> My current best thought is to create a new "boot simple" (boots? 
> bootsm?) command that contains only the essence of bootm.  I would then 
> change the command "bootm" to do a hush script run of the env variable 
> "bootm" (i.e. the command "bootm" would really just be "run bootm"). 
> The env variable "bootm" would then have to be created with the complex 
> (board/config appropriate) sequence that is currently hardcoded in the 
> command "bootm", with the last command being "boots", of course.  This 
> would be selected by a new CONFIG_ configuration so that old boards 
> would go on as is until or unless the maintainer chose to move forward.

Hm... if we go to such efforts, we might even go one step farther and
solve the problem in a more general way.

One idea that has been spinning in my mind for some time is  to  make
the  "run"  command to execute the content of an environment variable
optional. Instead, we could try and handle environment variable names
similar to command names, i. e. instead of typing "run foo; run  bar"
you  could  just  write  "foo;  bar" (I woull probably still keep the
"run" command around to allow for the implicit error handling as used
in "run foo bar" without forcing the user to use the  hush  shell  to
get the equivalent "foo && bar").

Then it's just a matter of defining the search order: if the variable
name space gets searched before the command names, we could  redefine
all builtin commands. [Probbaly the search order (variables before or
after   builtin  commands)  can  be  even  mad  selectable  using  an
environment variable :-) ].

A new "builtin" command would allow to stillr efer to the original
builtin commands.

With such an implementation, we could move the FDT  handling  into  a
command  sequence  stored  in a "bootm" environment variable, and the
last part of this variable would be "builtin bootm" to run  the  real
(simplified) command.

What do you think?

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
"The net result is a system that is not only binary  compatible  with
4.3  BSD, but is even bug for bug compatible in almost all features."
- Avadit  Tevanian,  Jr.,  "Architecture-Independent  Virtual  Memory
Management  for  Parallel  and  Distributed  Environments:  The  Mach
Approach"

[U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <48982523.4030706@gmail.com> you wrote:
>> My current best thought is to create a new "boot simple" (boots? 
>> bootsm?) command that contains only the essence of bootm.  I would then 
>> change the command "bootm" to do a hush script run of the env variable 
>> "bootm" (i.e. the command "bootm" would really just be "run bootm"). 
>> The env variable "bootm" would then have to be created with the complex 
>> (board/config appropriate) sequence that is currently hardcoded in the 
>> command "bootm", with the last command being "boots", of course.  This 
>> would be selected by a new CONFIG_ configuration so that old boards 
>> would go on as is until or unless the maintainer chose to move forward.
> 
> Hm... if we go to such efforts, we might even go one step farther and
> solve the problem in a more general way.
> 
> One idea that has been spinning in my mind for some time is  to  make
> the  "run"  command to execute the content of an environment variable
> optional. Instead, we could try and handle environment variable names
> similar to command names, i. e. instead of typing "run foo; run  bar"
> you  could  just  write  "foo;  bar" (I woull probably still keep the
> "run" command around to allow for the implicit error handling as used
> in "run foo bar" without forcing the user to use the  hush  shell  to
> get the equivalent "foo && bar").
> 
> Then it's just a matter of defining the search order: if the variable
> name space gets searched before the command names, we could  redefine
> all builtin commands. [Probbaly the search order (variables before or
> after   builtin  commands)  can  be  even  mad  selectable  using  an
> environment variable :-) ].
> 
> A new "builtin" command would allow to stillr efer to the original
> builtin commands.
> 
> With such an implementation, we could move the FDT  handling  into  a
> command  sequence  stored  in a "bootm" environment variable, and the
> last part of this variable would be "builtin bootm" to run  the  real
> (simplified) command.
> 
> What do you think?

That would be REALLY cool!  It would take some initial work, but the 
reward would be really simple and transparent expandability for the 
command set.  As with the "bootm" command, we might end up with simpler 
code (I don't think too many commands are as bad as bootm, however).

One minor flaw, I don't see how "bootm" the env script could run "bootm" 
the built-in command, because it would instead recursively run "bootm" 
the env script if scripts have higher priority and the command line 
"bootm" would run the built-in "bootm" if scripts have lower priority. 
The way I see it, env scripts should have higher priority than built-in 
commands and would supercede the built-in.  Hmm, one possible way out of 
the dilemma would be to support quoting built-in commands to force them, 
rather than the env script: `bootm` would be the built-in command (just 
as a concept, I don't know how back-tick quoting would conflict with 
existing hush parsing).

gvb

[U-Boot-Users] simplify bootm command

[Wolfgang Denk]

In message <48982DAD.2060408@gmail.com> you wrote:
>
> That would be REALLY cool!  It would take some initial work, but the 
> reward would be really simple and transparent expandability for the 
> command set.  As with the "bootm" command, we might end up with simpler 
> code (I don't think too many commands are as bad as bootm, however).

:-)

> One minor flaw, I don't see how "bootm" the env script could run "bootm" 
> the built-in command, because it would instead recursively run "bootm" 
> the env script if scripts have higher priority and the command line 
> "bootm" would run the built-in "bootm" if scripts have lower priority. 

That's why I think we should have an explicit "builtin" command, i. e.
command with the name "builtin" that will always run the corresponding
builtin command, no if there is a "command alias" or not - similar to
the bash command:

       builtin shell-builtin [arguments]
              Execute the specified shell builtin, passing it
              arguments, and return its exit status. This is useful
              when defining a function whose name is the same as a
              shell builtin, retaining the functionality of the
              builtin within the function. The cd builtin is commonly
              redefined this way. The return status is false if
              shell-builtin is not a shell builtin command.

> The way I see it, env scripts should have higher priority than built-in 
> commands and would supercede the built-in.  Hmm, one possible way out of 
> the dilemma would be to support quoting built-in commands to force them, 
> rather than the env script: `bootm` would be the built-in command (just 
> as a concept, I don't know how back-tick quoting would conflict with 
> existing hush parsing).

I don't like to use quoting (of  any  kind)  for  this  because  this
already  has  certain  meaning in the shell. Also, this would be more
effort to implement that the "builtin" command I suggested.

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
Vulcans believe peace should not depend on force.
	-- Amanda, "Journey to Babel", stardate 3842.3

[U-Boot-Users] simplify bootm command

[Albert ARIBAUD]

Wolfgang Denk a ?crit :

> That's why I think we should have an explicit "builtin" command, i. e.
> command with the name "builtin" that will always run the corresponding
> builtin command, no if there is a "command alias" or not - similar to
> the bash command

... and make sure that one can *never* define an environment variable 
called 'builtin', and even remove any such definition if found in the 
environment when reading it from persistent memory at boot.

Amicalement,
-- 
Albert.

[U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Wolfgang Denk wrote:
>> One minor flaw, I don't see how "bootm" the env script could run "bootm" 
>> the built-in command, because it would instead recursively run "bootm" 
>> the env script if scripts have higher priority and the command line 
>> "bootm" would run the built-in "bootm" if scripts have lower priority. 
> 
> That's why I think we should have an explicit "builtin" command, i. e.
> command with the name "builtin" that will always run the corresponding
> builtin command, no if there is a "command alias" or not - similar to
> the bash command:

Ahh, I missed the point that "builtin" was a command, not a concept. 
Yes, that solves the dilemma neatly.

WRT Albert's comment:
> ... and make sure that one can *never* define an environment variable 
> called 'builtin', and even remove any such definition if found in the 
> environment when reading it from persistent memory at boot.

...another way of handling this would be to special-case the "builtin" 
command so that it takes precedence over a "builtin" env variable (i.e. 
ignore an env variable named "builtin").  I'm not wild about 
auto-deleting env variables.

Best regards,
gvb

[U-Boot-Users] simplify bootm command

[Kumar Gala]

On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:

> In message <48982523.4030706@gmail.com> you wrote:
>>
>> My current best thought is to create a new "boot simple" (boots?
>> bootsm?) command that contains only the essence of bootm.  I would  
>> then
>> change the command "bootm" to do a hush script run of the env  
>> variable
>> "bootm" (i.e. the command "bootm" would really just be "run bootm").
>> The env variable "bootm" would then have to be created with the  
>> complex
>> (board/config appropriate) sequence that is currently hardcoded in  
>> the
>> command "bootm", with the last command being "boots", of course.   
>> This
>> would be selected by a new CONFIG_ configuration so that old boards
>> would go on as is until or unless the maintainer chose to move  
>> forward.
>
> Hm... if we go to such efforts, we might even go one step farther and
> solve the problem in a more general way.
>
> One idea that has been spinning in my mind for some time is  to  make
> the  "run"  command to execute the content of an environment variable
> optional. Instead, we could try and handle environment variable names
> similar to command names, i. e. instead of typing "run foo; run  bar"
> you  could  just  write  "foo;  bar" (I woull probably still keep the
> "run" command around to allow for the implicit error handling as used
> in "run foo bar" without forcing the user to use the  hush  shell  to
> get the equivalent "foo && bar").
>
> Then it's just a matter of defining the search order: if the variable
> name space gets searched before the command names, we could  redefine
> all builtin commands. [Probbaly the search order (variables before or
> after   builtin  commands)  can  be  even  mad  selectable  using  an
> environment variable :-) ].
>
> A new "builtin" command would allow to stillr efer to the original
> builtin commands.
>
> With such an implementation, we could move the FDT  handling  into  a
> command  sequence  stored  in a "bootm" environment variable, and the
> last part of this variable would be "builtin bootm" to run  the  real
> (simplified) command.
>
> What do you think?

While this is a cleaner implementation of what I've implemented w/ 
ft_env_setup() it still doesn't completely solve my problem.  We'd  
need to have a command to deal with image loading separate from bootm  
since the 'fdt' processing that does occur today is in the middle of  
the bootm flow.

bootm:
1. verify and uncompress kernel image
2. relocate fdt (if needed)
3. ft_board_setup()
4. verify and uncompress ramdisk
5. update initrd info in device tree
6. jump to kernel

I don't see how we can accomplish the same steps w/o breaking bootm  
down into a set of builtin commands to handle the various steps and  
providing enough information between the steps to accomplish the next  
step.

- k

[U-Boot-Users] simplify bootm command

[Wolfgang Denk]

In message <48983694.8000803@free.fr> you wrote:
> 
> > That's why I think we should have an explicit "builtin" command, i. e.
> > command with the name "builtin" that will always run the corresponding
> > builtin command, no if there is a "command alias" or not - similar to
> > the bash command
> 
> ... and make sure that one can *never* define an environment variable 
> called 'builtin', and even remove any such definition if found in the 
> environment when reading it from persistent memory at boot.

No. That's where the "always" in my sentence above comes  into  play.
Even  if  you define such a variable I would just issue a warning and
then ignore it when it comes to command execution.

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
"Why should we subsidize intellectual curiosity?" - Ronald Reagan

[U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:

[snip]

>> One idea that has been spinning in my mind for some time is  to  make
>> the  "run"  command to execute the content of an environment variable
>> optional. Instead, we could try and handle environment variable names
>> similar to command names, i. e. instead of typing "run foo; run  bar"
>> you  could  just  write  "foo;  bar" (I woull probably still keep the
>> "run" command around to allow for the implicit error handling as used
>> in "run foo bar" without forcing the user to use the  hush  shell  to
>> get the equivalent "foo && bar").

[snip]

>> With such an implementation, we could move the FDT  handling  into  a
>> command  sequence  stored  in a "bootm" environment variable, and the
>> last part of this variable would be "builtin bootm" to run  the  real
>> (simplified) command.
>>
>> What do you think?
> 
> While this is a cleaner implementation of what I've implemented w/ 
> ft_env_setup() it still doesn't completely solve my problem.  We'd  
> need to have a command to deal with image loading separate from bootm  
> since the 'fdt' processing that does occur today is in the middle of  
> the bootm flow.
> 
> bootm:
> 1. verify and uncompress kernel image
> 2. relocate fdt (if needed)
> 3. ft_board_setup()
> 4. verify and uncompress ramdisk
> 5. update initrd info in device tree
> 6. jump to kernel
> 
> I don't see how we can accomplish the same steps w/o breaking bootm  
> down into a set of builtin commands to handle the various steps and  
> providing enough information between the steps to accomplish the next  
> step.

Yes, that is Wolfgang's (and my) proposal: rationalize the built-in 
"bootm" to do just #6.  Steps 1-5 already exist as built-in commands or 
commands could be created almost trivially to invoke the existing code. 
  The current "bootm" behavior would then be emulated by a bootm script 
chaining them together.  All the different "bootm" behaviors would then 
be in the script (customizable by the user) rather than being 
hard-compiled into the actual bootm built-in command.

Rather than using the C preprocessor (and deductions based on 
parameters) to select the "appropriate" bootm behavior, an appropriate 
script would be used (there would be quite a few possible scripts, 
depending on _which_ "bootm" behavior is needed for a specific 
board/config).  (Despite just having "dissed" cpp bootm behavior 
generation, I'm thinking that we would want to use the cpp to generate a 
default script that would emulate the current bootm behavior.)

Best regards,
gvb

[U-Boot-Users] simplify bootm command

[Albert ARIBAUD]

Wolfgang Denk a ?crit :
> In message <48983694.8000803@free.fr> you wrote:
>>> That's why I think we should have an explicit "builtin" command, i. e.
>>> command with the name "builtin" that will always run the corresponding
>>> builtin command, no if there is a "command alias" or not - similar to
>>> the bash command
>> ... and make sure that one can *never* define an environment variable 
>> called 'builtin', and even remove any such definition if found in the 
>> environment when reading it from persistent memory at boot.
> 
> No. That's where the "always" in my sentence above comes  into  play.
> Even  if  you define such a variable I would just issue a warning and
> then ignore it when it comes to command execution.

My bad. I'd analyzed your "always" to apply to builtin's argument (the 
second word in the command), not to 'builtin' itself (the first word in the 
command).

Amicalement,
-- 
Albert.

[U-Boot-Users] simplify bootm command

[Detlev Zundel]

Hi,

> Wolfgang Denk wrote:
>>> One minor flaw, I don't see how "bootm" the env script could run "bootm" 
>>> the built-in command, because it would instead recursively run "bootm" 
>>> the env script if scripts have higher priority and the command line 
>>> "bootm" would run the built-in "bootm" if scripts have lower priority. 
>> 
>> That's why I think we should have an explicit "builtin" command, i. e.
>> command with the name "builtin" that will always run the corresponding
>> builtin command, no if there is a "command alias" or not - similar to
>> the bash command:
>
> Ahh, I missed the point that "builtin" was a command, not a concept. 
> Yes, that solves the dilemma neatly.
>
> WRT Albert's comment:
>> ... and make sure that one can *never* define an environment variable 
>> called 'builtin', and even remove any such definition if found in the 
>> environment when reading it from persistent memory at boot.
>
> ...another way of handling this would be to special-case the "builtin" 
> command so that it takes precedence over a "builtin" env variable (i.e. 
> ignore an env variable named "builtin").  I'm not wild about 
> auto-deleting env variables.

But ignoring it by having a separate precedence is again a special case
which we want to avoid ;) 

So I agree 100% with the whole idea and agree with Albert to "fail
loudly" in this case (another pretty clever Unix design philosophy).

Cheers
  Detlev

-- 
Directories are added, deleted, and rearranged much as you would
expect, even if you don't know it's what you'd expect.
                                         -- Tom Lord in TLA Documentation
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot-Users] simplify bootm command

[Kumar Gala]

On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
>
> [snip]
>
>>> One idea that has been spinning in my mind for some time is  to   
>>> make
>>> the  "run"  command to execute the content of an environment  
>>> variable
>>> optional. Instead, we could try and handle environment variable  
>>> names
>>> similar to command names, i. e. instead of typing "run foo; run   
>>> bar"
>>> you  could  just  write  "foo;  bar" (I woull probably still keep  
>>> the
>>> "run" command around to allow for the implicit error handling as  
>>> used
>>> in "run foo bar" without forcing the user to use the  hush  shell   
>>> to
>>> get the equivalent "foo && bar").
>
> [snip]
>
>>> With such an implementation, we could move the FDT  handling   
>>> into  a
>>> command  sequence  stored  in a "bootm" environment variable, and  
>>> the
>>> last part of this variable would be "builtin bootm" to run  the   
>>> real
>>> (simplified) command.
>>>
>>> What do you think?
>> While this is a cleaner implementation of what I've implemented w/  
>> ft_env_setup() it still doesn't completely solve my problem.  We'd   
>> need to have a command to deal with image loading separate from  
>> bootm  since the 'fdt' processing that does occur today is in the  
>> middle of  the bootm flow.
>> bootm:
>> 1. verify and uncompress kernel image
>> 2. relocate fdt (if needed)
>> 3. ft_board_setup()
>> 4. verify and uncompress ramdisk
>> 5. update initrd info in device tree
>> 6. jump to kernel
>> I don't see how we can accomplish the same steps w/o breaking  
>> bootm  down into a set of builtin commands to handle the various  
>> steps and  providing enough information between the steps to  
>> accomplish the next  step.
>
> Yes, that is Wolfgang's (and my) proposal: rationalize the built-in  
> "bootm" to do just #6.  Steps 1-5 already exist as built-in commands  
> or commands could be created almost trivially to invoke the existing  
> code.  The current "bootm" behavior would then be emulated by a  
> bootm script chaining them together.  All the different "bootm"  
> behaviors would then be in the script (customizable by the user)  
> rather than being hard-compiled into the actual bootm built-in  
> command.
>
> Rather than using the C preprocessor (and deductions based on  
> parameters) to select the "appropriate" bootm behavior, an  
> appropriate script would be used (there would be quite a few  
> possible scripts, depending on _which_ "bootm" behavior is needed  
> for a specific board/config).  (Despite just having "dissed" cpp  
> bootm behavior generation, I'm thinking that we would want to use  
> the cpp to generate a default script that would emulate the current  
> bootm behavior.)

If this is what Wolfgang was aiming I'm all for it.  is it?

I think we should start with a detailed 'script' to mimic existing  
bootm behavior to know what commands we need to add beyond the builtin  
change.

- k

[U-Boot-Users] simplify bootm command

[Wolfgang Denk]

In message <48985761.5010800@ge.com> you wrote:
> 
> Yes, that is Wolfgang's (and my) proposal: rationalize the built-in 
> "bootm" to do just #6.  Steps 1-5 already exist as built-in commands or 
> commands could be created almost trivially to invoke the existing code. 
>   The current "bootm" behavior would then be emulated by a bootm script 
> chaining them together.  All the different "bootm" behaviors would then 
> be in the script (customizable by the user) rather than being 
> hard-compiled into the actual bootm built-in command.

I just would like to point out that this is also a great chance to get
rid of a lot of architecture dependent code:

	lib_arm/bootm.c
	lib_avr32/bootm.c
	lib_blackfin/bootm.c
	lib_i386/bootm.c
	lib_m68k/bootm.c
	lib_microblaze/bootm.c
	lib_mips/bootm.c
	lib_nios/bootm.c
	lib_nios2/bootm.c
	lib_ppc/bootm.c
	lib_sh/bootm.c
	lib_sparc/bootm.c

There is a LOT of duplicated code in these files...


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
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

[U-Boot-Users] simplify bootm command -- deprecated or removing functionality?

[Kumar Gala]

Can we drop any functionality from the current bootm?

For example does powerpc still need to support bd_t based booting?

- k

[U-Boot-Users] simplify bootm command -- deprecated or removing functionality?

[Wolfgang Denk]

In message <940B425D-31DA-4B2D-87BA-63928AB31388@kernel.crashing.org> you wrote:
> Can we drop any functionality from the current bootm?

Any? You mean:

	int bootm (...)
	{
		return 0;
	}

:-)

> For example does powerpc still need to support bd_t based booting?

Yes, of course we need this. There is lots of systems out there that
use pre-DT kernels and still want recent versions of U-Boot for
various reasons.

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
Being schizophrenic is better than living alone.

[U-Boot-Users] simplify bootm command -- deprecated or removing functionality?

[Kumar Gala]

On Aug 5, 2008, at 9:45 AM, Wolfgang Denk wrote:

> In message  
> <940B425D-31DA-4B2D-87BA-63928AB31388@kernel.crashing.org> you wrote:
>> Can we drop any functionality from the current bootm?
>
> Any? You mean:
>
> 	int bootm (...)
> 	{
> 		return 0;
> 	}
>
> :-)

if it were only so easy :)

>> For example does powerpc still need to support bd_t based booting?
>
> Yes, of course we need this. There is lots of systems out there that
> use pre-DT kernels and still want recent versions of U-Boot for
> various reasons.

ok.

- k

[U-Boot-Users] simplify bootm command

[Kumar Gala]

On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
>
> [snip]
>
>>> One idea that has been spinning in my mind for some time is  to   
>>> make
>>> the  "run"  command to execute the content of an environment  
>>> variable
>>> optional. Instead, we could try and handle environment variable  
>>> names
>>> similar to command names, i. e. instead of typing "run foo; run   
>>> bar"
>>> you  could  just  write  "foo;  bar" (I woull probably still keep  
>>> the
>>> "run" command around to allow for the implicit error handling as  
>>> used
>>> in "run foo bar" without forcing the user to use the  hush  shell   
>>> to
>>> get the equivalent "foo && bar").
>
> [snip]
>
>>> With such an implementation, we could move the FDT  handling   
>>> into  a
>>> command  sequence  stored  in a "bootm" environment variable, and  
>>> the
>>> last part of this variable would be "builtin bootm" to run  the   
>>> real
>>> (simplified) command.
>>>
>>> What do you think?
>> While this is a cleaner implementation of what I've implemented w/  
>> ft_env_setup() it still doesn't completely solve my problem.  We'd   
>> need to have a command to deal with image loading separate from  
>> bootm  since the 'fdt' processing that does occur today is in the  
>> middle of  the bootm flow.
>> bootm:
>> 1. verify and uncompress kernel image
>> 2. relocate fdt (if needed)
>> 3. ft_board_setup()
>> 4. verify and uncompress ramdisk
>> 5. update initrd info in device tree
>> 6. jump to kernel
>> I don't see how we can accomplish the same steps w/o breaking  
>> bootm  down into a set of builtin commands to handle the various  
>> steps and  providing enough information between the steps to  
>> accomplish the next  step.
>
> Yes, that is Wolfgang's (and my) proposal: rationalize the built-in  
> "bootm" to do just #6.  Steps 1-5 already exist as built-in commands  
> or commands could be created almost trivially to invoke the existing  
> code.  The current "bootm" behavior would then be emulated by a  
> bootm script chaining them together.  All the different "bootm"  
> behaviors would then be in the script (customizable by the user)  
> rather than being hard-compiled into the actual bootm built-in  
> command.

As I look at this more and more I think trying to re-encode the  
control flow of the bootm command in a script is just insane.  There  
are too many special cases we have to deal with that we'd just being  
moving from C code into the script.

Unless there is some believed simplification I'm missing I don't think  
going through all this effort produces anything that is significantly  
better.

My needs are meet with the simple ft_env_setup() call out.  Beyond  
that trying to rework bootm for legacy images, CONFIG_FIT, booting w/ 
dts, boot w/o dts, linux, *bsd, vxworks, etc just seems like a lot of  
work w/o any real benefit.

- k

[U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:

[snip]

>>>> What do you think?
>>> While this is a cleaner implementation of what I've implemented w/ 
>>> ft_env_setup() it still doesn't completely solve my problem.  We'd  
>>> need to have a command to deal with image loading separate from 
>>> bootm  since the 'fdt' processing that does occur today is in the 
>>> middle of  the bootm flow.
>>> bootm:
>>> 1. verify and uncompress kernel image
>>> 2. relocate fdt (if needed)
>>> 3. ft_board_setup()
>>> 4. verify and uncompress ramdisk
>>> 5. update initrd info in device tree
>>> 6. jump to kernel
>>> I don't see how we can accomplish the same steps w/o breaking bootm  
>>> down into a set of builtin commands to handle the various steps and  
>>> providing enough information between the steps to accomplish the 
>>> next  step.
>>
>> Yes, that is Wolfgang's (and my) proposal: rationalize the built-in 
>> "bootm" to do just #6.  Steps 1-5 already exist as built-in commands 
>> or commands could be created almost trivially to invoke the existing 
>> code.  The current "bootm" behavior would then be emulated by a bootm 
>> script chaining them together.  All the different "bootm" behaviors 
>> would then be in the script (customizable by the user) rather than 
>> being hard-compiled into the actual bootm built-in command.
> 
> As I look at this more and more I think trying to re-encode the control 
> flow of the bootm command in a script is just insane.  There are too 
> many special cases we have to deal with that we'd just being moving from 
> C code into the script.

My assumption is that a given board/config/user will likely be using 
exactly one of the n!/k!(n-k)! possibilities implemented in the current 
"bootm" (I don't know what n and k are, but n is pretty large and k is 
hard to determine :-O).  I figure, in the worst case, a given user may 
want two or three possibilities.

By selecting from a (smallish) set of "simple" bootX scripts, I'm 
speculating that each script will not need conditional logic other than 
"&&" to bail out if an error occurs.  I'm also suspicious that replacing 
"bootm" with a simplified "bootm" with a (single) "bootm" script isn't 
going to be workable (as you contend - script complexity)... the 
solution I would propose if that happens is to maintain "bootm" as is as 
a backwards compatible CONFIG_ option and create a new "bootsimple" (or 
some such) command that is what bootm would have been if we had hush 
scripting (and prescience[1]) a few years ago.

> Unless there is some believed simplification I'm missing I don't think 
> going through all this effort produces anything that is significantly 
> better.

To make an omelet, you have to break some eggs. :-)  I see Wolfgang 
illustrated the current complexity with a list of bootm hack^H^H^H^H 
customizations in a separate message.

> My needs are meet with the simple ft_env_setup() call out.  Beyond that 
> trying to rework bootm for legacy images, CONFIG_FIT, booting w/dts, 
> boot w/o dts, linux, *bsd, vxworks, etc just seems like a lot of work 
> w/o any real benefit.

That is the practical approach for now, but that is also how we got to 
here - incrementally adding complexity to bootm.

Best regards,
gvb

[1] 
<http://en.wikipedia.org/wiki/Minor_characters_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Gogrilla_Mincefriend>

[U-Boot-Users] simplify bootm command

[Kumar Gala]

[snip]

>> As I look at this more and more I think trying to re-encode the  
>> control flow of the bootm command in a script is just insane.   
>> There are too many special cases we have to deal with that we'd  
>> just being moving from C code into the script.
>
> My assumption is that a given board/config/user will likely be using  
> exactly one of the n!/k!(n-k)! possibilities implemented in the  
> current "bootm" (I don't know what n and k are, but n is pretty  
> large and k is hard to determine :-O).  I figure, in the worst case,  
> a given user may want two or three possibilities.

that might be true in a custom board port but for reference boards  
like we produce at FSL its difficult to know what a customer might  
want so we effective have the kitchen sink.

> By selecting from a (smallish) set of "simple" bootX scripts, I'm  
> speculating that each script will not need conditional logic other  
> than "&&" to bail out if an error occurs.  I'm also suspicious that  
> replacing "bootm" with a simplified "bootm" with a (single) "bootm"  
> script isn't going to be workable (as you contend - script  
> complexity)... the solution I would propose if that happens is to  
> maintain "bootm" as is as a backwards compatible CONFIG_ option and  
> create a new "bootsimple" (or some such) command that is what bootm  
> would have been if we had hush scripting (and prescience[1]) a few  
> years ago.

which means I'll have to keep the old method around.

>> Unless there is some believed simplification I'm missing I don't  
>> think going through all this effort produces anything that is  
>> significantly better.
>
> To make an omelet, you have to break some eggs. :-)  I see Wolfgang  
> illustrated the current complexity with a list of bootm hack^H^H^H^H  
> customizations in a separate message.

but I doubt we will be able to remove those as they should be dealing  
with the ARCH specific boot methods.

>> My needs are meet with the simple ft_env_setup() call out.  Beyond  
>> that trying to rework bootm for legacy images, CONFIG_FIT, booting  
>> w/dts, boot w/o dts, linux, *bsd, vxworks, etc just seems like a  
>> lot of work w/o any real benefit.
>
> That is the practical approach for now, but that is also how we got  
> to here - incrementally adding complexity to bootm.

Fair point but I have yet to see how the new approach is going to get  
rid of the old one.  What's the point in adding code if we can't get  
rid of the old code?

- k