From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] outline of bootm script
Date: Wed, 06 Aug 2008 21:41:52 +0200 [thread overview]
Message-ID: <20080806194152.ECA6624847@gemini.denx.de> (raw)
In-Reply-To: Your message of "Wed, 06 Aug 2008 14:15:52 CDT." <5E53E387-237D-480E-A046-68AD7F9B90A5@kernel.crashing.org>
In message <5E53E387-237D-480E-A046-68AD7F9B90A5@kernel.crashing.org> you wrote:
>
> one idea is having "stages" of bootm handled as sub commands:
>
> bootm start <args>
> bootm prep (disable interrupts, stop usb, disable caches)
--- Point of no return here ---
> 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])
> bootm load_initrd
> bootm jump
>
> bootm restore (undo anything prep did, reset state tracking)
Note that you cannot recover / restore after starting to uncompress
the image, because usually you will overwrite the exception vectors.
> 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.
Sounds like Fortran to me - let's have a big COMMON section ;-)
I'm not sure if this leads to good design.
> 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", ...)
I have to admit that I have no idea why "bootm_size" or "bootm_low"
are needed. If we can drop these, all the better.
"verify" and "autostart" must be kept as environment variables,
because that's the way how the user can influence the boot behaviour.
Even if you find a better way to implement this, they will be needed
for backward compatibility.
> Also, bootm would be the sequence of:
> bootm start <args>
> bootm prep
> bootm load_os
> bootm load_fdt
> bootm load_initrd
> bootm jump
I'm asking myself if that order is technically necessary. IMHO it
should be possible as well to move the load_fdt step before load_os
and eventually before prep, too.
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: wd at denx.de
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy arrangement for
the people. - Eleanor Roosevelt
next prev parent reply other threads:[~2008-08-06 19:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-05 14:35 [U-Boot-Users] outline of bootm script Kumar Gala
2008-08-06 2:33 ` Jerry Van Baren
2008-08-06 19:15 ` Kumar Gala
2008-08-06 19:41 ` Wolfgang Denk [this message]
2008-08-06 20:05 ` Kumar Gala
2008-08-06 20:26 ` Wolfgang Denk
2008-08-06 20:33 ` Kumar Gala
2008-08-06 19:55 ` Jerry Van Baren
2008-08-06 20:19 ` Kumar Gala
2008-08-06 20:36 ` Wolfgang Denk
2008-08-06 20:45 ` Kumar Gala
2008-08-06 21:15 ` Wolfgang Denk
2008-08-06 21:37 ` Kumar Gala
2008-08-06 22:00 ` Wolfgang Denk
2008-08-06 22:09 ` [U-Boot-Users] bootm -- load_os inputs/outputs Kumar Gala
2008-08-06 20:39 ` [U-Boot-Users] outline of bootm script Jerry Van Baren
2008-08-06 20:21 ` Wolfgang Denk
2008-08-06 20:29 ` Jerry Van Baren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080806194152.ECA6624847@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox