[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?
Tom Rini
trini at ti.com
Mon Apr 7 21:57:31 CEST 2014
On Mon, Apr 07, 2014 at 09:19:09PM +0200, Wolfgang Denk wrote:
> Dear Tom,
>
> In message <20140407190210.GK23803 at bill-the-cat> you wrote:
> >
> > > I think CONFIG_ENV_IS_IN.. is an independent thing. Even when booting
> > > from NOR you can have the environment anywhere else.
> >
> > Well, maybe. I'm not sure (and too lazy to dig through the board doc
> > atm) on if you can have both NOR and QSPI available on the reference
> > design, but I think not. But also, for ..._qspiboot I want to show
> > everything from QSPI, and ..._norboot I want everything on NOR.
>
> OK, but this is a design decision for this specific board, then. It
> is not a fundamental property of the U-Boot design. For us, boot
> device and environment storage are independent. And so it should be
> implemented.
Maybe, maybe not. But it's beside the point. The point is we have SoC
init code that needs to be run once. Sometimes this is true when
CONFIG_SPL_BUILD=y, sometimes this is true when other options are set
instead. What should we call the option to denote one-time init?
Should we extend CONFIG_SKIP_LOWLEVEL_INIT to cover this case?
> > > As for the differences between NOR and QSPI... IIRC we cannot execute
> > > any code directly on QSPI, we have to load it to some memory first,
> > > right? So QSPI is not much different from loading the code from any
> > > other storage device - or am I missing something? How is XIP from
> > > QSPI working?
> >
> > Nope, this board has memory mapped QSPI and on reading something other
> > than all 0s or all 1s ROM jumps to it.
>
> If you use the memory mapped mode, then it looks just like any
> other ROM, and we should not need special code either.
Well, for CONFIG_NOR_BOOT we must have it on am335x (haven't checked
am43xx) to finish doing pinmux as only 12KiB is mapped, in addition to
env related options. On am43xx and QSPI it's just used to denote when
we are doing one-time init in U-Boot proper rather than SPL.
This is, I guess, yet another extension of "we need to treat SPL as a
U-Boot with x/y/z set, not a special magic build target like we do
today" and Kconfig will help.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140407/6a28b34a/attachment.pgp>
More information about the U-Boot
mailing list