[U-Boot-Users] simplify bootm command
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 */
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
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
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
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
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,
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
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,
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
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
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
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:
- verify and uncompress kernel image
- relocate fdt (if needed)
- ft_board_setup()
- verify and uncompress ramdisk
- update initrd info in device tree
- 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
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:
- verify and uncompress kernel image
- relocate fdt (if needed)
- ft_board_setup()
- verify and uncompress ramdisk
- update initrd info in device tree
- 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
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
Can we drop any functionality from the current bootm?
For example does powerpc still need to support bd_t based booting?
- k
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
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
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:
- verify and uncompress kernel image
- relocate fdt (if needed)
- ft_board_setup()
- verify and uncompress ramdisk
- update initrd info in device tree
- 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
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:
- verify and uncompress kernel image
- relocate fdt (if needed)
- ft_board_setup()
- verify and uncompress ramdisk
- update initrd info in device tree
- 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
[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
participants (6)
-
Albert ARIBAUD -
Detlev Zundel -
Jerry Van Baren -
Jerry Van Baren -
Kumar Gala -
Wolfgang Denk