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