Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2012 05:08 AM, Sughosh Ganu wrote: > On Wed Jul 11, 2012 at 04:43:19AM -0700, Tom Rini wrote: >> On 07/11/2012 04:05 AM, Sughosh Ganu wrote: > > > I'm fine saying that we should wrap the call around an #if, but I would expect it to be set in the common case and only not set in custom production boards. >>> >>> Correct, so all that is needed for SD/MMC loading can still be >>> kept separate from, say nand load in the spl.c file, isn't it. >>> So if sd/mmc spl load needs heap to be set up, can't it be done >>> only for that case. >> >> Yes, but we don't want to have N locations that set up the heap. >> We want one location that will, if the board has defined a heap >> area, we set it up. Or to put it another way, calling >> mem_malloc_init isn't part of the mmc boot-flow, it's part of the >> general boot flow. > > Fair enough. My only concern was just that if some feature is not > needed for a board, it should be possible to exclude it out. To be clear, absolutely agreed. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP/W50AAoJENk4IS6UOR1W6VEQAJ2C+IlU/irdxIBQJkWKdGoe Rwr1bdQpnUIA4ILEBuD7jwiDj/Q6znfzUQf0XXZuRg+ShYu10y/2HBazn/alfrMj FyLqm7YnjxDoWpfbSzR5EajdUOD7UgdDbZURwyte/NQos2WeS89IZTrlIT5sxfYV L7DT0fDdK4pfh7+gArr99Ge/eE3ddm9kVdoxFbvYsr0BQs8xLnjh7t1DZ2rk0P7Y AabwKIiM1o7xNn5GPIb7lraO4A1/m7U1/if2ad+I/qtEsAnsTC+Ds7VPvnxSdK/w ga/r/OcYzpQLHna0dBQ4qXqnl5hKDARw3ZX2EYiqxRECRDLMDo2OWJio2F7yEqID nYhhVKFNcSIC6mcIz1DyPGd/q3QFziCRFfFq0xrfF6K2rNByfXK4xHdld33EFvM1 V7Kfu8XSXeswGU41T+I6hHZyaCFWeNzDBTF/JtfXoZ0IoGgb045JLc6i14KAmwpO AVCLhQy64h4O7BfvrzYK5u93RmI0PtjdXwkrBMpqAcICwsiPJ0mAU2azYQNbhYVk NJM5xecgobni0HQek1f/UgzwllwDusjrjo5Hv+Di/D5wYBYTOWxPKZGEHOWfcuf6 O/io1QVQc3FMdrU3cCf5kB/tDAXDOpENhStCkkCgbFVf6u2hVz4vdSxV7oZ5Gmkp bpFoazwtHzXpzE5B6eIe =kJeB -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On Wed Jul 11, 2012 at 04:43:19AM -0700, Tom Rini wrote: > On 07/11/2012 04:05 AM, Sughosh Ganu wrote: > >> I'm fine saying that we should wrap the call around an #if, but I > >> would expect it to be set in the common case and only not set in > >> custom production boards. > > > > Correct, so all that is needed for SD/MMC loading can still be kept > > separate from, say nand load in the spl.c file, isn't it. So if sd/mmc > > spl load needs heap to be set up, can't it be done only for that > > case. > > Yes, but we don't want to have N locations that set up the heap. We > want one location that will, if the board has defined a heap area, we > set it up. Or to put it another way, calling mem_malloc_init isn't part > of the mmc boot-flow, it's part of the general boot flow. Fair enough. My only concern was just that if some feature is not needed for a board, it should be possible to exclude it out. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On 07/11/2012 04:05 AM, Sughosh Ganu wrote:
> On Wed Jul 11, 2012 at 03:46:46AM -0700, Tom Rini wrote:
>> On 07/11/2012 03:40 AM, Sughosh Ganu wrote:
>>> On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
> On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
>> On Wed, 11 Jul 2012 00:09:06 +0530
>> Sughosh Ganu wrote:
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
>>>
>>>
>>>
void board_init_r(gd_t *id, ulong dummy)
{
-#ifdef CONFIG_SPL_NAND_LOAD
- nand_init();
- puts("Nand boot...\n");
- nand_boot();
-#endif
-#ifdef CONFIG_SPL_SPI_LOAD
- mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
- CONFIG_SYS_MALLOC_LEN);
+ u32 boot_device;
+ void (*uboot)(void) __noreturn;
+
+ mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
+ CONFIG_SYS_SPL_MALLOC_SIZE);
>>>
>>> We do not need any heap for the spl on the hawkboard, so can you
>>> please explain why do we need the heap allocation for all spl
>>> images. Can't this be made configurable.
>>
>> this is needed at least for:
>> * MMC support
>> * SPI support
>> * gunzip support (see next patch)
>>
>> it can be configurable, but is it reasonable?
>
> I would think so -- i guess it should be fine to include this only for
> boards/configurations that actually need the heap.
Shouldn't "load u-boot.img from vfat SD card" be a common case at least
for developers?
>>>
>>> Yes, it should be, but what i meant was that things that are not
>>> needed for certain boards or configurations need not be made
>>> common. Like in this case, why does setting up a heap, which is not
>>> needed at least on my board need to be common for all spl images. If a
>>> particular board/configuration needs it, then use it.
>>
>> Wouldn't load from SD be a common case on hawkboard, esp once the ones
>> that can load from SD, from the ROM become more available?
>
> Yes, loading from SD could be supported on any board in the future,
> but in that case, should it not be just a matter of adding something
> like CONFIG_SPL_MMC_LOAD to the board's config file.
Yes, along with adding the defines for the heap. And unless you end up
being severely space constrained for the SPL file, it's usually the case
you build in support for a few modes, when it's possible to detect at
run time where you came from.
>> I'm fine saying that we should wrap the call around an #if, but I
>> would expect it to be set in the common case and only not set in
>> custom production boards.
>
> Correct, so all that is needed for SD/MMC loading can still be kept
> separate from, say nand load in the spl.c file, isn't it. So if sd/mmc
> spl load needs heap to be set up, can't it be done only for that
> case.
Yes, but we don't want to have N locations that set up the heap. We
want one location that will, if the board has defined a heap area, we
set it up. Or to put it another way, calling mem_malloc_init isn't part
of the mmc boot-flow, it's part of the general boot flow.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On Wed Jul 11, 2012 at 03:46:46AM -0700, Tom Rini wrote:
> On 07/11/2012 03:40 AM, Sughosh Ganu wrote:
> > On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
> >> On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
> >>> On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
> On Wed, 11 Jul 2012 00:09:06 +0530
> Sughosh Ganu wrote:
> >> diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
> >> b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
> >> --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
> >> +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
> >
> >
> >
> >> void board_init_r(gd_t *id, ulong dummy)
> >> {
> >> -#ifdef CONFIG_SPL_NAND_LOAD
> >> - nand_init();
> >> - puts("Nand boot...\n");
> >> - nand_boot();
> >> -#endif
> >> -#ifdef CONFIG_SPL_SPI_LOAD
> >> - mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
> >> - CONFIG_SYS_MALLOC_LEN);
> >> + u32 boot_device;
> >> + void (*uboot)(void) __noreturn;
> >> +
> >> + mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
> >> + CONFIG_SYS_SPL_MALLOC_SIZE);
> >
> > We do not need any heap for the spl on the hawkboard, so can you
> > please explain why do we need the heap allocation for all spl
> > images. Can't this be made configurable.
>
> this is needed at least for:
> * MMC support
> * SPI support
> * gunzip support (see next patch)
>
> it can be configurable, but is it reasonable?
> >>>
> >>> I would think so -- i guess it should be fine to include this only for
> >>> boards/configurations that actually need the heap.
> >>
> >> Shouldn't "load u-boot.img from vfat SD card" be a common case at least
> >> for developers?
> >
> > Yes, it should be, but what i meant was that things that are not
> > needed for certain boards or configurations need not be made
> > common. Like in this case, why does setting up a heap, which is not
> > needed at least on my board need to be common for all spl images. If a
> > particular board/configuration needs it, then use it.
>
> Wouldn't load from SD be a common case on hawkboard, esp once the ones
> that can load from SD, from the ROM become more available?
Yes, loading from SD could be supported on any board in the future,
but in that case, should it not be just a matter of adding something
like CONFIG_SPL_MMC_LOAD to the board's config file.
> I'm fine saying that we should wrap the call around an #if, but I
> would expect it to be set in the common case and only not set in
> custom production boards.
Correct, so all that is needed for SD/MMC loading can still be kept
separate from, say nand load in the spl.c file, isn't it. So if sd/mmc
spl load needs heap to be set up, can't it be done only for that
case.
-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On 07/11/2012 03:40 AM, Sughosh Ganu wrote:
> On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
>> On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
>>> On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
On Wed, 11 Jul 2012 00:09:06 +0530
Sughosh Ganu wrote:
>> diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
>> b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
>> --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
>> +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
>
>
>
>> void board_init_r(gd_t *id, ulong dummy)
>> {
>> -#ifdef CONFIG_SPL_NAND_LOAD
>> -nand_init();
>> -puts("Nand boot...\n");
>> -nand_boot();
>> -#endif
>> -#ifdef CONFIG_SPL_SPI_LOAD
>> -mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
>> -CONFIG_SYS_MALLOC_LEN);
>> +u32 boot_device;
>> +void (*uboot)(void) __noreturn;
>> +
>> +mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
>> +CONFIG_SYS_SPL_MALLOC_SIZE);
>
> We do not need any heap for the spl on the hawkboard, so can you
> please explain why do we need the heap allocation for all spl
> images. Can't this be made configurable.
this is needed at least for:
* MMC support
* SPI support
* gunzip support (see next patch)
it can be configurable, but is it reasonable?
>>>
>>> I would think so -- i guess it should be fine to include this only for
>>> boards/configurations that actually need the heap.
>>
>> Shouldn't "load u-boot.img from vfat SD card" be a common case at least
>> for developers?
>
> Yes, it should be, but what i meant was that things that are not
> needed for certain boards or configurations need not be made
> common. Like in this case, why does setting up a heap, which is not
> needed at least on my board need to be common for all spl images. If a
> particular board/configuration needs it, then use it.
Wouldn't load from SD be a common case on hawkboard, esp once the ones
that can load from SD, from the ROM become more available? I'm fine
saying that we should wrap the call around an #if, but I would expect it
to be set in the common case and only not set in custom production boards.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
> On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
> > On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
> >> On Wed, 11 Jul 2012 00:09:06 +0530
> >> Sughosh Ganu wrote:
> diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
> b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
> --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
> +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
> >>>
> >>>
> >>>
> void board_init_r(gd_t *id, ulong dummy)
> {
> -#ifdef CONFIG_SPL_NAND_LOAD
> -nand_init();
> -puts("Nand boot...\n");
> -nand_boot();
> -#endif
> -#ifdef CONFIG_SPL_SPI_LOAD
> -mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
> -CONFIG_SYS_MALLOC_LEN);
> +u32 boot_device;
> +void (*uboot)(void) __noreturn;
> +
> +mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
> +CONFIG_SYS_SPL_MALLOC_SIZE);
> >>>
> >>> We do not need any heap for the spl on the hawkboard, so can you
> >>> please explain why do we need the heap allocation for all spl
> >>> images. Can't this be made configurable.
> >>
> >> this is needed at least for:
> >> * MMC support
> >> * SPI support
> >> * gunzip support (see next patch)
> >>
> >> it can be configurable, but is it reasonable?
> >
> > I would think so -- i guess it should be fine to include this only for
> > boards/configurations that actually need the heap.
>
> Shouldn't "load u-boot.img from vfat SD card" be a common case at least
> for developers?
Yes, it should be, but what i meant was that things that are not
needed for certain boards or configurations need not be made
common. Like in this case, why does setting up a heap, which is not
needed at least on my board need to be common for all spl images. If a
particular board/configuration needs it, then use it.
Loading an image from a media is a common case, but for that
particular media only. Other media might have different requirements.
-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
> On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
>> On Wed, 11 Jul 2012 00:09:06 +0530
>> Sughosh Ganu wrote:
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
>>>
>>>
>>>
void board_init_r(gd_t *id, ulong dummy)
{
-#ifdef CONFIG_SPL_NAND_LOAD
- nand_init();
- puts("Nand boot...\n");
- nand_boot();
-#endif
-#ifdef CONFIG_SPL_SPI_LOAD
- mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
- CONFIG_SYS_MALLOC_LEN);
+ u32 boot_device;
+ void (*uboot)(void) __noreturn;
+
+ mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
+ CONFIG_SYS_SPL_MALLOC_SIZE);
>>>
>>> We do not need any heap for the spl on the hawkboard, so can you
>>> please explain why do we need the heap allocation for all spl
>>> images. Can't this be made configurable.
>>
>> this is needed at least for:
>> * MMC support
>> * SPI support
>> * gunzip support (see next patch)
>>
>> it can be configurable, but is it reasonable?
>
> I would think so -- i guess it should be fine to include this only for
> boards/configurations that actually need the heap.
Shouldn't "load u-boot.img from vfat SD card" be a common case at least
for developers?
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
> On Wed, 11 Jul 2012 00:09:06 +0530
> Sughosh Ganu wrote:
> > > diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
> > > b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
> > > --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
> > > +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
> >
> >
> >
> > > void board_init_r(gd_t *id, ulong dummy)
> > > {
> > > -#ifdef CONFIG_SPL_NAND_LOAD
> > > - nand_init();
> > > - puts("Nand boot...\n");
> > > - nand_boot();
> > > -#endif
> > > -#ifdef CONFIG_SPL_SPI_LOAD
> > > - mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
> > > - CONFIG_SYS_MALLOC_LEN);
> > > + u32 boot_device;
> > > + void (*uboot)(void) __noreturn;
> > > +
> > > + mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
> > > + CONFIG_SYS_SPL_MALLOC_SIZE);
> >
> > We do not need any heap for the spl on the hawkboard, so can you
> > please explain why do we need the heap allocation for all spl
> > images. Can't this be made configurable.
>
> this is needed at least for:
> * MMC support
> * SPI support
> * gunzip support (see next patch)
>
> it can be configurable, but is it reasonable?
I would think so -- i guess it should be fine to include this only for
boards/configurations that actually need the heap.
>
> > >
> > > gd = &gdata;
> > > gd->bd = &bdata;
> > > gd->flags |= GD_FLG_RELOC;
> > > +#ifdef CONFIG_SPL_SERIAL_SUPPORT
> > > gd->baudrate = CONFIG_BAUDRATE;
> > > - serial_init(); /* serial communications setup */
> > > + serial_init();
> > > gd->have_console = 1;
> > > +#endif
> >
> > This call to serial_init is not needed on the hawkboard -- we
> > initialise the console needed for spl through NS16550_init for all
> > da8xx based spl's in arch_cpu_init, which suffices for spl's debug
> > message requirement. I know this is being used for spi based spl
> > images, but now that this is being made common, just wanted to
> > know why we need this. Also, do these changes have any impact on the
> > size of the spl images.
>
> hm, i'll look on it more carefully. I've just look on spi support in spl.
>
> What about ymodem support? If I am not mistake it require a normal console.
If it's needed for ymodem support, include it for that use case -- i
see that your patch already has a separate cases for ymodem
support, spi flash support and so on. Can't it be called for cases
where it is really needed.
Btw, forgot to mention in my earlier mail that you need to add the
license header for all the new files, like spl_mmc.c etc.
-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On Wed, 11 Jul 2012 00:09:06 +0530
Sughosh Ganu wrote:
> hi Mikhail,
> On Mon Jul 09, 2012 at 10:53:39PM +0400, Mikhail Kshevetskiy wrote:
> > This patch allow us to have a universal spl that detects a boot
> > device and select a corresponding boot algorithm for main u-boot part
> > (SOC_DA8XX only)
>
> I have not tested this patch, will do so sometime this week. I had a
> couple of questions though.
>
>
>
> > diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
> > b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
> > --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
> > +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
>
>
>
> > void board_init_r(gd_t *id, ulong dummy)
> > {
> > -#ifdef CONFIG_SPL_NAND_LOAD
> > - nand_init();
> > - puts("Nand boot...\n");
> > - nand_boot();
> > -#endif
> > -#ifdef CONFIG_SPL_SPI_LOAD
> > - mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
> > - CONFIG_SYS_MALLOC_LEN);
> > + u32 boot_device;
> > + void (*uboot)(void) __noreturn;
> > +
> > + mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
> > + CONFIG_SYS_SPL_MALLOC_SIZE);
>
> We do not need any heap for the spl on the hawkboard, so can you
> please explain why do we need the heap allocation for all spl
> images. Can't this be made configurable.
this is needed at least for:
* MMC support
* SPI support
* gunzip support (see next patch)
it can be configurable, but is it reasonable?
> >
> > gd = &gdata;
> > gd->bd = &bdata;
> > gd->flags |= GD_FLG_RELOC;
> > +#ifdef CONFIG_SPL_SERIAL_SUPPORT
> > gd->baudrate = CONFIG_BAUDRATE;
> > - serial_init(); /* serial communications setup */
> > + serial_init();
> > gd->have_console = 1;
> > +#endif
>
> This call to serial_init is not needed on the hawkboard -- we
> initialise the console needed for spl through NS16550_init for all
> da8xx based spl's in arch_cpu_init, which suffices for spl's debug
> message requirement. I know this is being used for spi based spl
> images, but now that this is being made common, just wanted to
> know why we need this. Also, do these changes have any impact on the
> size of the spl images.
hm, i'll look on it more carefully. I've just look on spi support in spl.
What about ymodem support? If I am not mistake it require a normal console.
> -sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
hi Mikhail,
On Mon Jul 09, 2012 at 10:53:39PM +0400, Mikhail Kshevetskiy wrote:
> This patch allow us to have a universal spl that detects a boot
> device and select a corresponding boot algorithm for main u-boot part
> (SOC_DA8XX only)
I have not tested this patch, will do so sometime this week. I had a
couple of questions though.
> diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
> b/arch/arm/cpu/arm926ejs/davinci/spl.c
> index 74632e5..50b4bbc 100644
> --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
> +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
> void board_init_r(gd_t *id, ulong dummy)
> {
> -#ifdef CONFIG_SPL_NAND_LOAD
> - nand_init();
> - puts("Nand boot...\n");
> - nand_boot();
> -#endif
> -#ifdef CONFIG_SPL_SPI_LOAD
> - mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
> - CONFIG_SYS_MALLOC_LEN);
> + u32 boot_device;
> + void (*uboot)(void) __noreturn;
> +
> + mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
> + CONFIG_SYS_SPL_MALLOC_SIZE);
We do not need any heap for the spl on the hawkboard, so can you
please explain why do we need the heap allocation for all spl
images. Can't this be made configurable.
>
> gd = &gdata;
> gd->bd = &bdata;
> gd->flags |= GD_FLG_RELOC;
> +#ifdef CONFIG_SPL_SERIAL_SUPPORT
> gd->baudrate = CONFIG_BAUDRATE;
> - serial_init(); /* serial communications setup */
> + serial_init();
> gd->have_console = 1;
> +#endif
This call to serial_init is not needed on the hawkboard -- we
initialise the console needed for spl through NS16550_init for all
da8xx based spl's in arch_cpu_init, which suffices for spl's debug
message requirement. I know this is being used for spi based spl
images, but now that this is being made common, just wanted to
know why we need this. Also, do these changes have any impact on the
size of the spl images.
-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On Mon, 9 Jul 2012 13:08:07 -0700 Tom Rini wrote: > On 07/09/2012 12:57 PM, Mikhail Kshevetskiy wrote: > > On Mon, 9 Jul 2012 12:41:06 -0700 > > Tom Rini wrote: > > > >> On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote: > >>> This patch allow us to have a universal spl that detects a boot > >>> device and select a corresponding boot algorithm for main u-boot part > >>> (SOC_DA8XX only) > >>> > >>> This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and > >>> drivers/mtd/spi/spi_spl_load.c for the following reasons: > >>> * avoid jump to main u-boot code just after its loading (required > >>>for the next patch: spl - add compressed u-boot image support) > >>> * makes a structure similar to omap3 sources > >>> > >>> Signed-off-by: Mikhail Kshevetskiy > >> > >> I guess I wasn't clear enough when I asked the series to be split. I > >> want to see this portion turned into: > >> a) Move omap-common spl bits to arch/arm/lib/ > >> b) davinci converted (and as needed, omap3/4/am33xx converted) to be > >> able to use the same code. > >> > >> We shouldn't introduce a new spl_mmc.c for example, we should modify the > >> davinci structure to be able to re-use the same spl_mmc.c code to > >> load/verify and let the next step, as needed happen. I want to see > >> "omap" be able to re-use SPI (since am33xx can do it too, and I've > >> kludged the davinci stuff before) and potentially be able to re-use for > >> example the gunzip support. This I think is the easy set of steps to > >> being able to reuse this fairly common SPL logic outside of not just TI > >> parts but anyone else that wants it. > > > > Ok, I'll take this task. Unfortunately I have no too much free time for this > > job (summer, parents visit, new job and so on), so it may take a month or > > so. > > OK, thanks. > > > What about other patches? > > The ddr/uart ones should make their way in soon and I've assigned the > SPI ones to the custodian in patchwork. > > -- > Tom Thanks! Mikhail ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On Mon, 9 Jul 2012 12:41:06 -0700 Tom Rini wrote: > On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote: > > This patch allow us to have a universal spl that detects a boot > > device and select a corresponding boot algorithm for main u-boot part > > (SOC_DA8XX only) > > > > This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and > > drivers/mtd/spi/spi_spl_load.c for the following reasons: > > * avoid jump to main u-boot code just after its loading (required > >for the next patch: spl - add compressed u-boot image support) > > * makes a structure similar to omap3 sources > > > > Signed-off-by: Mikhail Kshevetskiy > > I guess I wasn't clear enough when I asked the series to be split. I > want to see this portion turned into: > a) Move omap-common spl bits to arch/arm/lib/ > b) davinci converted (and as needed, omap3/4/am33xx converted) to be > able to use the same code. > > We shouldn't introduce a new spl_mmc.c for example, we should modify the > davinci structure to be able to re-use the same spl_mmc.c code to > load/verify and let the next step, as needed happen. I want to see > "omap" be able to re-use SPI (since am33xx can do it too, and I've > kludged the davinci stuff before) and potentially be able to re-use for > example the gunzip support. This I think is the easy set of steps to > being able to reuse this fairly common SPL logic outside of not just TI > parts but anyone else that wants it. Ok, I'll take this task. Unfortunately I have no too much free time for this job (summer, parents visit, new job and so on), so it may take a month or so. What about other patches? Mikhail > > -- > Tom > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On 07/09/2012 12:57 PM, Mikhail Kshevetskiy wrote: > On Mon, 9 Jul 2012 12:41:06 -0700 > Tom Rini wrote: > >> On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote: >>> This patch allow us to have a universal spl that detects a boot >>> device and select a corresponding boot algorithm for main u-boot part >>> (SOC_DA8XX only) >>> >>> This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and >>> drivers/mtd/spi/spi_spl_load.c for the following reasons: >>> * avoid jump to main u-boot code just after its loading (required >>>for the next patch: spl - add compressed u-boot image support) >>> * makes a structure similar to omap3 sources >>> >>> Signed-off-by: Mikhail Kshevetskiy >> >> I guess I wasn't clear enough when I asked the series to be split. I >> want to see this portion turned into: >> a) Move omap-common spl bits to arch/arm/lib/ >> b) davinci converted (and as needed, omap3/4/am33xx converted) to be >> able to use the same code. >> >> We shouldn't introduce a new spl_mmc.c for example, we should modify the >> davinci structure to be able to re-use the same spl_mmc.c code to >> load/verify and let the next step, as needed happen. I want to see >> "omap" be able to re-use SPI (since am33xx can do it too, and I've >> kludged the davinci stuff before) and potentially be able to re-use for >> example the gunzip support. This I think is the easy set of steps to >> being able to reuse this fairly common SPL logic outside of not just TI >> parts but anyone else that wants it. > > Ok, I'll take this task. Unfortunately I have no too much free time for this > job (summer, parents visit, new job and so on), so it may take a month or so. OK, thanks. > What about other patches? The ddr/uart ones should make their way in soon and I've assigned the SPI ones to the custodian in patchwork. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote: > This patch allow us to have a universal spl that detects a boot > device and select a corresponding boot algorithm for main u-boot part > (SOC_DA8XX only) > > This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and > drivers/mtd/spi/spi_spl_load.c for the following reasons: > * avoid jump to main u-boot code just after its loading (required >for the next patch: spl - add compressed u-boot image support) > * makes a structure similar to omap3 sources > > Signed-off-by: Mikhail Kshevetskiy I guess I wasn't clear enough when I asked the series to be split. I want to see this portion turned into: a) Move omap-common spl bits to arch/arm/lib/ b) davinci converted (and as needed, omap3/4/am33xx converted) to be able to use the same code. We shouldn't introduce a new spl_mmc.c for example, we should modify the davinci structure to be able to re-use the same spl_mmc.c code to load/verify and let the next step, as needed happen. I want to see "omap" be able to re-use SPI (since am33xx can do it too, and I've kludged the davinci stuff before) and potentially be able to re-use for example the gunzip support. This I think is the easy set of steps to being able to reuse this fairly common SPL logic outside of not just TI parts but anyone else that wants it. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
