[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

Hey all,

I'm looking over some patches for am43xx to enable the case of non-SPL
XIP booting and this means we start getting code that's shared with
am335x that looks like:
#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT) || \
	defined(CONFIG_QSPI_BOOT)
...
#endif

Because we need to do certain init either in SPL or early U-Boot.  While
I don't see another XIP boot case being added anytime soon, it would be
nice to instead write:
#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SYS_XIP_BOOT)
or whatever makes the most sense for a name.  Thoughts on the name?
Thanks!

-- 
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/20140305/8ffb8c9f/attachment.pgp>

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Albert ARIBAUD]

Hi Tom,

On Wed, 5 Mar 2014 12:28:06 -0500, Tom Rini <trini@ti.com> wrote:

> Hey all,
> 
> I'm looking over some patches for am43xx to enable the case of non-SPL
> XIP booting and this means we start getting code that's shared with
> am335x that looks like:
> #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT) || \
> 	defined(CONFIG_QSPI_BOOT)
> ...
> #endif
> 
> Because we need to do certain init either in SPL or early U-Boot.  While
> I don't see another XIP boot case being added anytime soon, it would be
> nice to instead write:
> #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SYS_XIP_BOOT)
> or whatever makes the most sense for a name.  Thoughts on the name?
> Thanks!

Or maybe name the config option not after the boot mode but after what
it actually does, and then in the board config, enable this option if
the boot mode wants it?

Amicalement,
-- 
Albert.

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 06:31:41PM +0200, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Wed, 5 Mar 2014 12:28:06 -0500, Tom Rini <trini@ti.com> wrote:
> 
> > Hey all,
> > 
> > I'm looking over some patches for am43xx to enable the case of non-SPL
> > XIP booting and this means we start getting code that's shared with
> > am335x that looks like:
> > #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT) || \
> > 	defined(CONFIG_QSPI_BOOT)
> > ...
> > #endif
> > 
> > Because we need to do certain init either in SPL or early U-Boot.  While
> > I don't see another XIP boot case being added anytime soon, it would be
> > nice to instead write:
> > #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SYS_XIP_BOOT)
> > or whatever makes the most sense for a name.  Thoughts on the name?
> > Thanks!
> 
> Or maybe name the config option not after the boot mode but after what
> it actually does, and then in the board config, enable this option if
> the boot mode wants it?

Right.  But what to call the option?

-- 
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/85a0ea36/attachment.pgp>

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140305172806.GY16805@bill-the-cat> you wrote:
> 
> I'm looking over some patches for am43xx to enable the case of non-SPL
> XIP booting and this means we start getting code that's shared with
> am335x that looks like:


What exactly do you mean by "non-SPL XIP booting"?  Is this not the
standard boot mode which has actually been the first (and only one)
that U-Boot has ever been designed for, like booting from a ROM (like
parallel NOR flash)?  Because the we do exactly that: we execute the
code as is from the boot device...

> Because we need to do certain init either in SPL or early U-Boot.  While
> I don't see another XIP boot case being added anytime soon, it would be
> nice to instead write:

What you call "XIP boot" is the default for all systems booting from
NOR flash (or other boot ROM) - or am I missing something?

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
Voodoo Programming: Things programmers do that  they  know  shouldn't
work  but they try anyway, and which sometimes actually work, such as
recompiling everything.                             - Karl Lehenbauer

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 07:05:36PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140305172806.GY16805@bill-the-cat> you wrote:
> > 
> > I'm looking over some patches for am43xx to enable the case of non-SPL
> > XIP booting and this means we start getting code that's shared with
> > am335x that looks like:
> 
> What exactly do you mean by "non-SPL XIP booting"?  Is this not the
> standard boot mode which has actually been the first (and only one)
> that U-Boot has ever been designed for, like booting from a ROM (like
> parallel NOR flash)?  Because the we do exactly that: we execute the
> code as is from the boot device...

Exactly.  But most modern platforms are not XIP booting by default, if
ever.  When it is, it's a special case and needs the code we usually
only call in SPL (say memory controller init) linked in.  Today this is
done with say:
#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
...
#endif
on am335x.  Looking at am43xx we have both traditional NOR and QSPI NOR
as boot options, along with SD/NAND/various-peripheral-boots.

-- 
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/0f1f84b0/attachment.pgp>

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140407171943.GG23803@bill-the-cat> you wrote:
> 
> > What exactly do you mean by "non-SPL XIP booting"?  Is this not the
> > standard boot mode which has actually been the first (and only one)
> > that U-Boot has ever been designed for, like booting from a ROM (like
> > parallel NOR flash)?  Because the we do exactly that: we execute the
> > code as is from the boot device...
>
> Exactly.  But most modern platforms are not XIP booting by default, if
> ever.  When it is, it's a special case and needs the code we usually
> only call in SPL (say memory controller init) linked in.  Today this is
> done with say:
> #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
> ...
> #endif
> on am335x.  Looking at am43xx we have both traditional NOR and QSPI NOR
> as boot options, along with SD/NAND/various-peripheral-boots.

OK.  So if this basically the same what we do when booting XIP from
parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
generic name, like CONFIG_XIP_BOOT ?

I would like to have only one name for one thing...

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
Writing a book is like washing an elephant: there's no good place  to
begin  or  end,  and  it's  hard to keep track of what you've already
covered.

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 07:41:39PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140407171943.GG23803@bill-the-cat> you wrote:
> > 
> > > What exactly do you mean by "non-SPL XIP booting"?  Is this not the
> > > standard boot mode which has actually been the first (and only one)
> > > that U-Boot has ever been designed for, like booting from a ROM (like
> > > parallel NOR flash)?  Because the we do exactly that: we execute the
> > > code as is from the boot device...
> >
> > Exactly.  But most modern platforms are not XIP booting by default, if
> > ever.  When it is, it's a special case and needs the code we usually
> > only call in SPL (say memory controller init) linked in.  Today this is
> > done with say:
> > #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
> > ...
> > #endif
> > on am335x.  Looking at am43xx we have both traditional NOR and QSPI NOR
> > as boot options, along with SD/NAND/various-peripheral-boots.
> 
> OK.  So if this basically the same what we do when booting XIP from
> parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
> generic name, like CONFIG_XIP_BOOT ?

Nope, not everything for NOR is required for QSPI nor correct, so we'll
still need NOR/QSPI boot options (CONFIG_ENV_IS_IN.. then
size/location).

-- 
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/35c6ec3d/attachment.pgp>

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140407174936.GJ23803@bill-the-cat> you wrote:
> 
> > OK.  So if this basically the same what we do when booting XIP from
> > parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
> > generic name, like CONFIG_XIP_BOOT ?
> 
> Nope, not everything for NOR is required for QSPI nor correct, so we'll
> still need NOR/QSPI boot options (CONFIG_ENV_IS_IN.. then
> size/location).

I think CONFIG_ENV_IS_IN.. is an independent thing. Even when booting
from NOR you can have the environment anywhere else.

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?

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
"No matter where you go, there you are..."          - Buckaroo Banzai

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 08:45:42PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140407174936.GJ23803@bill-the-cat> you wrote:
> > 
> > > OK.  So if this basically the same what we do when booting XIP from
> > > parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
> > > generic name, like CONFIG_XIP_BOOT ?
> > 
> > Nope, not everything for NOR is required for QSPI nor correct, so we'll
> > still need NOR/QSPI boot options (CONFIG_ENV_IS_IN.. then
> > size/location).
> 
> 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.

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

-- 
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/9ca0668a/attachment.pgp>

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140407190210.GK23803@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.

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

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
I am not now, nor have I ever been, a member of the demigodic party.
                                                   -- Dennis Ritchie

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 09:19:09PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140407190210.GK23803@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>

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140407195731.GL23803@bill-the-cat> you wrote:
> 
> 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?

Um... I think, if we build (and use) the SPL, then the low level init
code would always be run (if at all) in the SPL; without SPL, it would
be run in the normal U-Boot code.  CONFIG_SKIP_LOWLEVEL_INIT is
intended to skip running this low level init code.  To me this looks
independent of where this init code is located - it is yet another
orthogonal decision.

Which sort of extension do you have in mind here?


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

Sorry, I lost you.  what is the "it" in both sentences referring to?

Also, I'm not sure what exactly you mean by "one-time"init - all
initialization steps in init_sequence[] are executed only once.
These settings you are referring to - can these me made here, or is
this stuff that is running before board_init_f() ?


Um... I just ran over this in "arch/arm/lib/spl.c":

 21  * In the context of SPL, board_init_f must ensure that any clocks/etc for
 22  * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
 23  * and call board_init_f.  We provide this version by default but mark it
           ^^^^^^^^^^^^^^^^^
 24  * as __weak to allow for platforms to do this in their own way if needed.
 25  */
 26 void __weak board_init_f(ulong dummy)   
 27 {
 28         /* Clear the BSS. */
 29         memset(__bss_start, 0, __bss_end - __bss_start);
 30
 31         /* Set global data pointer. */
 32         gd = &gdata;
 33 
 34         board_init_r(NULL, 0);
            ^^^^^^^^^^^^

The comment says _f, the code has _r - which is right?


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

Yes, probabvly.

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
A fanatic is a person who can't change his mind and won't change  the
subject.                                          - Winston Churchill

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Tue, Apr 08, 2014 at 03:02:44PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140407195731.GL23803@bill-the-cat> you wrote:
> > 
> > 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?
> 
> Um... I think, if we build (and use) the SPL, then the low level init
> code would always be run (if at all) in the SPL; without SPL, it would
> be run in the normal U-Boot code.  CONFIG_SKIP_LOWLEVEL_INIT is
> intended to skip running this low level init code.  To me this looks
> independent of where this init code is located - it is yet another
> orthogonal decision.
> 
> Which sort of extension do you have in mind here?

Maybe talking about this in patches will be clearer.  If instead of
adding a new CONFIG option, I use CONFIG_SKIP_LOWLEVEL_INIT like this!
diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c
index fb44cc8..28c16f8 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -142,7 +142,7 @@ int arch_misc_init(void)
 	return 0;
 }
 
-#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
+#ifndef CONFIG_SKIP_LOWLEVEL_INIT
 /*
  * This function is the place to do per-board things such as ramp up the
  * MPU clock frequency.
@@ -200,9 +200,7 @@ static void watchdog_disable(void)
 	while (readl(&wdtimer->wdtwwps) != 0x0)
 		;
 }
-#endif
 
-#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
 void s_init(void)
 {
 	/*
diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
index 50c3203..89d14c8 100644
--- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -69,7 +69,8 @@
  * Since SPL did pll and ddr initialization for us,
  * we don't need to do it twice.
  */
-#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_NOR_BOOT)
+#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_NOR_BOOT) && \
+	!defined(CONFIG_QSPI_BOOT)
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #endif

The following is true:
a) am335x_evm build, SPL calls s_init, does DDR init, u-boot.img
continues to not do so, just like today.
b) am335x_evm_norboot, _no_ SPL, u-boot.bin calls s_init, does DDR init,
just like today.
c) am43xx_evm build, SPL and u-boot.img work just like am335x_evm
d) am43xx_evm_qspiboot, _no_ SPL, u-boot.bin calls s_init, does DDR
init, just like today with the patch series that adds the target.

If instead we add a new option (for the moment, CONFIG_SYS_XIP_BOOT):

diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c
index fb44cc8..133ca1c 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -142,7 +142,7 @@ int arch_misc_init(void)
 	return 0;
 }
 
-#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
+#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SYS_XIP_BOOT)
 /*
  * This function is the place to do per-board things such as ramp up the
  * MPU clock frequency.
@@ -200,9 +200,7 @@ static void watchdog_disable(void)
 	while (readl(&wdtimer->wdtwwps) != 0x0)
 		;
 }
-#endif
 
-#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
 void s_init(void)
 {
 	/*
diff --git a/boards.cfg b/boards.cfg
index b4203f1..b5a79d0 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -267,7 +267,7 @@ Active  arm         armv7          am33xx      silica          pengwyn
 Active  arm         armv7          am33xx      ti              am335x              am335x_boneblack                     am335x_evm:SERIAL1,CONS_INDEX=1,EMMC_BOOT                                                                                         Tom Rini <trini@ti.com>
 Active  arm         armv7          am33xx      ti              am335x              am335x_evm                           am335x_evm:SERIAL1,CONS_INDEX=1,NAND                                                                                              Tom Rini <trini@ti.com>
 Active  arm         armv7          am33xx      ti              am335x              am335x_evm_nor                       am335x_evm:SERIAL1,CONS_INDEX=1,NAND,NOR                                                                                          Tom Rini <trini@ti.com>
-Active  arm         armv7          am33xx      ti              am335x              am335x_evm_norboot                   am335x_evm:SERIAL1,CONS_INDEX=1,NOR,NOR_BOOT                                                                                      Tom Rini <trini@ti.com>
+Active  arm         armv7          am33xx      ti              am335x              am335x_evm_norboot                   am335x_evm:SERIAL1,CONS_INDEX=1,NOR,NOR_BOOT,SYS_XIP_BOOT                                                                         Tom Rini <trini@ti.com>
 Active  arm         armv7          am33xx      ti              am335x              am335x_evm_spiboot                   am335x_evm:SERIAL1,CONS_INDEX=1,SPI_BOOT                                                                                          Tom Rini <trini@ti.com>
 Active  arm         armv7          am33xx      ti              am335x              am335x_evm_uart1                     am335x_evm:SERIAL2,CONS_INDEX=2,NAND                                                                                              Tom Rini <trini@ti.com>
 Active  arm         armv7          am33xx      ti              am335x              am335x_evm_uart2                     am335x_evm:SERIAL3,CONS_INDEX=3,NAND                                                                                              Tom Rini <trini@ti.com>
diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
index 50c3203..1092c25 100644
--- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -69,7 +69,8 @@
  * Since SPL did pll and ddr initialization for us,
  * we don't need to do it twice.
  */
-#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_NOR_BOOT)
+#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_NOR_BOOT) && \
+	!defined(CONFIG_QSPI_BOOT)
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #endif
 
Pasting it out, I like using CONFIG_SKIP_LOWLEVEL_INIT more to cover
this code.  Does that work for you?

> > > 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.
> 
> Sorry, I lost you.  what is the "it" in both sentences referring to?

First it is the running binary (in this case, U-Boot).  The second it is
CONFIG_QSPI_BOOT.

> Also, I'm not sure what exactly you mean by "one-time"init - all
> initialization steps in init_sequence[] are executed only once.

Right, but we don't initalize DDR twice, especially if we're running
from DDR.

> These settings you are referring to - can these me made here, or is
> this stuff that is running before board_init_f() ?
> 
> 
> Um... I just ran over this in "arch/arm/lib/spl.c":
> 
>  21  * In the context of SPL, board_init_f must ensure that any clocks/etc for
>  22  * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
>  23  * and call board_init_f.  We provide this version by default but mark it
>            ^^^^^^^^^^^^^^^^^
>  24  * as __weak to allow for platforms to do this in their own way if needed.
>  25  */
>  26 void __weak board_init_f(ulong dummy)   
>  27 {
>  28         /* Clear the BSS. */
>  29         memset(__bss_start, 0, __bss_end - __bss_start);
>  30
>  31         /* Set global data pointer. */
>  32         gd = &gdata;
>  33 
>  34         board_init_r(NULL, 0);
>             ^^^^^^^^^^^^
> 
> The comment says _f, the code has _r - which is right?

Oops, the comment should say "_r" as board_init_r is common SPL code.

-- 
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/20140408/0fa750e2/attachment.pgp>

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Albert ARIBAUD]

Hi Tom,

On Tue, 8 Apr 2014 14:00:29 -0400, Tom Rini <trini@ti.com> wrote:

> Maybe talking about this in patches will be clearer.

To us people, possibly. To Patchwork, possibly not. :)

http://patchwork.ozlabs.org/patch/337713/

Amicalement,
-- 
Albert.

[U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140408180029.GR23803@bill-the-cat> you wrote:
> 
> Maybe talking about this in patches will be clearer.  If instead of
> adding a new CONFIG option, I use CONFIG_SKIP_LOWLEVEL_INIT like this!

I like this, too :-)

> Pasting it out, I like using CONFIG_SKIP_LOWLEVEL_INIT more to cover
> this code.  Does that work for you?

Yes, it does.  Thanks!


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
Only two things are infinite,  the universe and human stupidity,  and
I'm not sure about the former.                     -- Albert Einstein