In message <[EMAIL PROTECTED]> you wrote:
>
> > 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.
ACK. And if we really restore anything, than just interrupts and
caches, but not any interfaces.
> > We could also have some "bootm query <foo>" 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.
ACK.
> 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
We alreay have a verify command. It's called "imls".
> 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...)
Hint: keep it backwards compatible, please.
> 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 <addr> (<addr>|-) <addr>"
> could be used for backward compatibility and "bootm <subcmd>" for New
> Improved[tm] functionality.
How do your differentiate beween <addr> and <subcmd> then?
> 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).
ACK.
> 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...
ACK.
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: [EMAIL PROTECTED]
To live is always desirable.
-- Eleen the Capellan, "Friday's Child", stardate 3498.9
-------------------------------------------------------------------------
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
