From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 06 Aug 2008 15:55:15 -0400 Subject: [U-Boot-Users] outline of bootm script In-Reply-To: <5E53E387-237D-480E-A046-68AD7F9B90A5@kernel.crashing.org> References: <2E8CBC61-B62F-45C4-BF98-CF18CE437309@kernel.crashing.org> <48990D7A.7070507@gmail.com> <5E53E387-237D-480E-A046-68AD7F9B90A5@kernel.crashing.org> Message-ID: <489A01A3.6000800@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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): >> >> >> 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 > 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 " 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 > 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 (|-) " could be used for backward compatibility and "bootm " 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