[U-Boot] SPL boot modes

[U-Boot] SPL boot modes

[Joel A Fernandes]

Hi Simon,

Great work on the SPL patches for omap. I am getting a bit familiar
with this and earlier SPL work.

Just one question about one of your patches I happen to notice [1],
why is there a SPL build for each different boot mode such as for
NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that
tried different boot modes one after the other, something like what
x-load already does? Are there are any challenges with this approach?

Thanks!
Joel

[U-Boot] SPL boot modes

[Joel A Fernandes]

On Fri, Sep 16, 2011 at 1:11 AM, Joel A Fernandes <agnel.joel@gmail.com> wrote:
> Hi Simon,
>
> Great work on the SPL patches for omap. I am getting a bit familiar
> with this and earlier SPL work.
>
> Just one question about one of your patches I happen to notice [1],

Sorry, I was referring to this patch:
http://patchwork.ozlabs.org/patch/107431/

Thanks,
Joel

[U-Boot] SPL boot modes

[Simon Schwarz]

Hi Joel,

The current release (based on u-boot-ti) is V9: 
http://patchwork.ozlabs.org/bundle/Simon/OMAP3_SPL_V9/

Or V10 
http://mid.gmane.org/1315949258-12064-1-git-send-email-trini at ti.com 
(based on u-boot-arm)

Actually this may already work (although I haven't tested it yet). If 
you define CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_NAND_SUPPORT (plus the 
necessary defines for them) in your board header it is looking for the 
bootdevice the ROM code used and tries to load  the image from it.

If you try MMC with OMAP3 I would appreciate a message if it works or not.

Regards
Simon

On 09/16/2011 08:11 AM, Joel A Fernandes wrote:
> Hi Simon,
>
> Great work on the SPL patches for omap. I am getting a bit familiar
> with this and earlier SPL work.
>
> Just one question about one of your patches I happen to notice [1],
> why is there a SPL build for each different boot mode such as for
> NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that
> tried different boot modes one after the other, something like what
> x-load already does? Are there are any challenges with this approach?
>
> Thanks!
> Joel

[U-Boot] SPL boot modes

[Tom Rini]

On Fri, Sep 16, 2011 at 1:14 AM, Simon Schwarz
<simonschwarzcor@googlemail.com> wrote:
> Hi Joel,
>
> The current release (based on u-boot-ti) is V9:
> http://patchwork.ozlabs.org/bundle/Simon/OMAP3_SPL_V9/
>
> Or V10
> http://mid.gmane.org/1315949258-12064-1-git-send-email-trini at ti.com
> (based on u-boot-arm)
>
> Actually this may already work (although I haven't tested it yet). If
> you define CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_NAND_SUPPORT (plus the
> necessary defines for them) in your board header it is looking for the
> bootdevice the ROM code used and tries to load ?the image from it.
>
> If you try MMC with OMAP3 I would appreciate a message if it works or not.

I've managed to port over to omap3evm and beagleboard (both xM and rev
C) and boot from MMC.  I haven't yet gotten NAND happy on omap3evm and
will be attempting NAND on beagleboard rev C soon.  And I'll post a
full patch series once things work a bit more (as I've told Simon
privately I had to rework the memory init hook a bit).

-- 
Tom

[U-Boot] SPL boot modes

[Wolfgang Denk]

Dear Joel A Fernandes,

In message <CAD=GYpaAUVQo3S_8FOUfDLNAyUYS5cFs-fkL5GUv3oNnG_zerA@mail.gmail.com> you wrote:
> 
> Just one question about one of your patches I happen to notice [1],
> why is there a SPL build for each different boot mode such as for
> NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that
> tried different boot modes one after the other, something like what
> x-load already does? Are there are any challenges with this approach?

Yes, this would be nice.  Question: how do we make this fit in - say -
the 2 KiB code size that some processors load?  Including all the
drivers for NAND, MMC etc.?

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
Lots of people drink from the wrong bottle sometimes.
	-- Edith Keeler, "The City on the Edge of Forever",
	   stardate unknown

[U-Boot] SPL boot modes

[Simon Schwarz]

On 09/16/2011 02:31 PM, Wolfgang Denk wrote:
> Dear Joel A Fernandes,
>
> In message<CAD=GYpaAUVQo3S_8FOUfDLNAyUYS5cFs-fkL5GUv3oNnG_zerA@mail.gmail.com>  you wrote:
>>
>> Just one question about one of your patches I happen to notice [1],
>> why is there a SPL build for each different boot mode such as for
>> NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that
>> tried different boot modes one after the other, something like what
>> x-load already does? Are there are any challenges with this approach?
>
> Yes, this would be nice.  Question: how do we make this fit in - say -
> the 2 KiB code size that some processors load?  Including all the
> drivers for NAND, MMC etc.?
>
> Best regards,
>
> Wolfgang Denk
>

That's the reason for the librarys in SPL. One can build a SPL that is 
able to boot from more than one source (although it might not work yet - 
the tools are there).

If size matters: Just include the one needed

Regards
Simon

[U-Boot] SPL boot modes

[Joel A Fernandes]

On Fri, Sep 16, 2011 at 7:31 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Joel A Fernandes,
>
> In message <CAD=GYpaAUVQo3S_8FOUfDLNAyUYS5cFs-fkL5GUv3oNnG_zerA@mail.gmail.com> you wrote:
>>
>> Just one question about one of your patches I happen to notice [1],
>> why is there a SPL build for each different boot mode such as for
>> NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that
>> tried different boot modes one after the other, something like what
>> x-load already does? Are there are any challenges with this approach?
>
> Yes, this would be nice. ?Question: how do we make this fit in - say -
> the 2 KiB code size that some processors load? ?Including all the
> drivers for NAND, MMC etc.?

Hi Wolfgang,

Thanks for your email. I have to admit that I am new to the SPL way of
doing things but..

Based on which drivers have configured, we can cycle through the
available boot modes one after the other like:

#ifdef CONFIG_NAND
  nand_boot()
#endif
else
#ifdef CONFIG_MMC
  mmc_boot()
#endif
etc..

This should work for boards < 2k mem I'm guessing.

Also, we can allow the board to decide in which order to go through
based on preferences set in the board and/or config file.
For eg. (unless this is already done), it will nice if omap-like
boards can read through the sysboot pins to decide which order to try
the boot.

What do you think?

Thanks,
Joel