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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
