[U-Boot] Breakage on gw_ventana

[U-Boot] Breakage on gw_ventana

[Stefano Babic]

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case
kernel is on a fs, we need to pass the name for kernel.  These two
defines should be set into gw_ventana.h:

	CONFIG_SPL_FS_LOAD_KERNEL_NAME
	CONFIG_SPL_FS_LOAD_ARGS_NAME

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL
is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
mx6 with smaller SRAM has at least 128KB.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] Breakage on gw_ventana

[Tim Harvey]

On Thu, May 19, 2016 at 6:02 AM, Stefano Babic <sbabic@denx.de> wrote:
> Hi Tim,
>
> last changes break build for the gw_ventana board. In fact, in case
> kernel is on a fs, we need to pass the name for kernel.  These two
> defines should be set into gw_ventana.h:
>
>         CONFIG_SPL_FS_LOAD_KERNEL_NAME
>         CONFIG_SPL_FS_LOAD_ARGS_NAME
>
> I could simply fix it, but it does not make sense without asking you :-)
>
> I have also seen that SPL for gw_ventana raises an exception because SPL
> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
> mx6 with smaller SRAM has at least 128KB.
>

Stefano,

Thanks for the heads-up. I have to admit I haven't looked at mainline
u-boot on Ventana for quite some time - I'm still using a 2015-04
branch with some patches on top that I haven't had time to mainline
yet.

When you say 'last changes' was there something specific? Something
must of grown the size of the SPL code quite a bit.

Your right that the smallest imx6 SRAM has 128KB although we have to
be careful not to clobber the SRAM being used by the boot ROM. The
reference manual indicates (IMX6*RM Figure 8-3) that there is only
free area 68KB available after you carve out the 28KB reserved
section, the 24KB MMU table, and the 8K stack. Admittedly I don't know
if the BOOT rom code really uses all of these areas in such a way that
it cant load the SPL into any of them. Take a look at my comments at
the top of include/configs/imx6_spl.h and let me know if you find
something wrong with my analysis that led to a 64KB max.

Regards,

Tim

[U-Boot] Breakage on gw_ventana

[Stefano Babic]

Hi Tim,

On 19/05/2016 15:48, Tim Harvey wrote:
> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic <sbabic@denx.de> wrote:
>> Hi Tim,
>>
>> last changes break build for the gw_ventana board. In fact, in case
>> kernel is on a fs, we need to pass the name for kernel.  These two
>> defines should be set into gw_ventana.h:
>>
>>         CONFIG_SPL_FS_LOAD_KERNEL_NAME
>>         CONFIG_SPL_FS_LOAD_ARGS_NAME
>>
>> I could simply fix it, but it does not make sense without asking you :-)
>>
>> I have also seen that SPL for gw_ventana raises an exception because SPL
>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>> mx6 with smaller SRAM has at least 128KB.
>>
> 
> Stefano,
> 
> Thanks for the heads-up. I have to admit I haven't looked at mainline
> u-boot on Ventana for quite some time - I'm still using a 2015-04
> branch with some patches on top that I haven't had time to mainline
> yet.
> 
> When you say 'last changes' was there something specific? Something
> must of grown the size of the SPL code quite a bit.

I think (but I am not sure) the biggest increase was done by allowing to
load image directly from filesystem, and then the size increased.

But I admit I did not take a closer look before - it looks like that
gw_ventana is the first to fail, just because it supports more methods
for booting. Most boards boots just from one media,

> 
> Your right that the smallest imx6 SRAM has 128KB although we have to
> be careful not to clobber the SRAM being used by the boot ROM. The
> reference manual indicates (IMX6*RM Figure 8-3) that there is only
> free area 68KB available after you carve out the 28KB reserved
> section, the 24KB MMU table, and the 8K stack. Admittedly I don't know
> if the BOOT rom code really uses all of these areas in such a way that
> it cant load the SPL into any of them.

I do not know as well - maybe some NXP developers can tell something more.

> Take a look at my comments at
> the top of include/configs/imx6_spl.h and let me know if you find
> something wrong with my analysis that led to a 64KB max.

Nothing wrong, but as far as I know in start.S cache and muu are turned
off, and they are turned on later again. This could let us to reuse
maybe the 24KB space previously set by the Bootrom

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] Breakage on gw_ventana

[Tim Harvey]

On Thu, May 19, 2016 at 7:05 AM, Stefano Babic <sbabic@denx.de> wrote:
> Hi Tim,
>
> On 19/05/2016 15:48, Tim Harvey wrote:
>> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic <sbabic@denx.de> wrote:
>>> Hi Tim,
>>>
>>> last changes break build for the gw_ventana board. In fact, in case
>>> kernel is on a fs, we need to pass the name for kernel.  These two
>>> defines should be set into gw_ventana.h:
>>>
>>>         CONFIG_SPL_FS_LOAD_KERNEL_NAME
>>>         CONFIG_SPL_FS_LOAD_ARGS_NAME
>>>
>>> I could simply fix it, but it does not make sense without asking you :-)
>>>
>>> I have also seen that SPL for gw_ventana raises an exception because SPL
>>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>>> mx6 with smaller SRAM has at least 128KB.
>>>
>>
>> Stefano,
>>
>> Thanks for the heads-up. I have to admit I haven't looked at mainline
>> u-boot on Ventana for quite some time - I'm still using a 2015-04
>> branch with some patches on top that I haven't had time to mainline
>> yet.
>>
>> When you say 'last changes' was there something specific? Something
>> must of grown the size of the SPL code quite a bit.
>
> I think (but I am not sure) the biggest increase was done by allowing to
> load image directly from filesystem, and then the size increased.
>
> But I admit I did not take a closer look before - it looks like that
> gw_ventana is the first to fail, just because it supports more methods
> for booting. Most boards boots just from one media,
>

That makes sense.

Looking at my notes (again this is based on 2015.04) I found the
following increases in SPL:

base+serial+i2c: 23K
+mmc: +12K
+nand: +8K
+gpio: +4K
+env: +12K (big!)
+fat: +4K
+ext: +8K
+fastboot: +4K

These numbers were with backported thumb binary support (without it
they get much more inflated).

My SPL is at 63K currently but that is largely because I'm including
nand+mmc and env (both env from nand and from mmc) with the help of a
patch to allow either env that didn't get accepted upstream (because
of the desire to re-write the env code for DM). I was after a single
SPL that could handle a NAND or MMC boot device.

I don't include fs support simply because I didn't have the room so if
that truly was added I can see how that through it over the edge.

I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
me that should be in the board config file(s) where needed and not in
the general SPL config file, otherwise your adding support that some
boards (like ventana!) don't have room for.

>>
>> Your right that the smallest imx6 SRAM has 128KB although we have to
>> be careful not to clobber the SRAM being used by the boot ROM. The
>> reference manual indicates (IMX6*RM Figure 8-3) that there is only
>> free area 68KB available after you carve out the 28KB reserved
>> section, the 24KB MMU table, and the 8K stack. Admittedly I don't know
>> if the BOOT rom code really uses all of these areas in such a way that
>> it cant load the SPL into any of them.
>
> I do not know as well - maybe some NXP developers can tell something more.
>
>> Take a look at my comments at
>> the top of include/configs/imx6_spl.h and let me know if you find
>> something wrong with my analysis that led to a 64KB max.
>
> Nothing wrong, but as far as I know in start.S cache and muu are turned
> off, and they are turned on later again. This could let us to reuse
> maybe the 24KB space previously set by the Bootrom

they may be turned off by the time we get to U-Boot SPL or within
U-Boot SPL but the question is 'does the boot ROM need them?'. I
suppose its not too difficult to test by artificially growing the SPL
with random/zero'd data and letting it clobber the 24KB shown for the
MMU table.

Tim

[U-Boot] Breakage on gw_ventana

[Stefano Babic]

Hi Tim,

On 19/05/2016 16:34, Tim Harvey wrote:
> On Thu, May 19, 2016 at 7:05 AM, Stefano Babic <sbabic@denx.de> wrote:
>> Hi Tim,
>>
>> On 19/05/2016 15:48, Tim Harvey wrote:
>>> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>> Hi Tim,
>>>>
>>>> last changes break build for the gw_ventana board. In fact, in case
>>>> kernel is on a fs, we need to pass the name for kernel.  These two
>>>> defines should be set into gw_ventana.h:
>>>>
>>>>         CONFIG_SPL_FS_LOAD_KERNEL_NAME
>>>>         CONFIG_SPL_FS_LOAD_ARGS_NAME
>>>>
>>>> I could simply fix it, but it does not make sense without asking you :-)
>>>>
>>>> I have also seen that SPL for gw_ventana raises an exception because SPL
>>>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>>>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>>>> mx6 with smaller SRAM has at least 128KB.
>>>>
>>>
>>> Stefano,
>>>
>>> Thanks for the heads-up. I have to admit I haven't looked at mainline
>>> u-boot on Ventana for quite some time - I'm still using a 2015-04
>>> branch with some patches on top that I haven't had time to mainline
>>> yet.
>>>
>>> When you say 'last changes' was there something specific? Something
>>> must of grown the size of the SPL code quite a bit.
>>
>> I think (but I am not sure) the biggest increase was done by allowing to
>> load image directly from filesystem, and then the size increased.
>>
>> But I admit I did not take a closer look before - it looks like that
>> gw_ventana is the first to fail, just because it supports more methods
>> for booting. Most boards boots just from one media,
>>
> 
> That makes sense.
> 
> Looking at my notes (again this is based on 2015.04) I found the
> following increases in SPL:
> 
> base+serial+i2c: 23K
> +mmc: +12K
> +nand: +8K
> +gpio: +4K
> +env: +12K (big!)
> +fat: +4K
> +ext: +8K
> +fastboot: +4K
> 
> These numbers were with backported thumb binary support (without it
> they get much more inflated).
> 
> My SPL is at 63K currently but that is largely because I'm including
> nand+mmc and env (both env from nand and from mmc) with the help of a
> patch to allow either env that didn't get accepted upstream (because
> of the desire to re-write the env code for DM). I was after a single
> SPL that could handle a NAND or MMC boot device.
> 
> I don't include fs support simply because I didn't have the room so if
> that truly was added I can see how that through it over the edge.
> 
> I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
> just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
> me that should be in the board config file(s) where needed and not in
> the general SPL config file, otherwise your adding support that some
> boards (like ventana!) don't have room for.
> 

Yes, agree - this should be splitted and moved to board config files.

>>> Take a look at my comments at
>>> the top of include/configs/imx6_spl.h and let me know if you find
>>> something wrong with my analysis that led to a 64KB max.
>>
>> Nothing wrong, but as far as I know in start.S cache and muu are turned
>> off, and they are turned on later again. This could let us to reuse
>> maybe the 24KB space previously set by the Bootrom
> 
> they may be turned off by the time we get to U-Boot SPL or within
> U-Boot SPL but the question is 'does the boot ROM need them?'. I
> suppose its not too difficult to test by artificially growing the SPL
> with random/zero'd data and letting it clobber the 24KB shown for the
> MMU table.

Right - and it should be very nice to know what happens to the
"reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks
like that the Boot ROM does not use it - but it is marked as reserved in
the manual, and for this reason it was never used, but I am now
speculating if the space can be taken for our purposes.

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] Breakage on gw_ventana

[Marek Vasut]

On 05/20/2016 02:41 PM, Stefano Babic wrote:
> Hi Tim,
> 
> On 19/05/2016 16:34, Tim Harvey wrote:
>> On Thu, May 19, 2016 at 7:05 AM, Stefano Babic <sbabic@denx.de> wrote:
>>> Hi Tim,
>>>
>>> On 19/05/2016 15:48, Tim Harvey wrote:
>>>> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>>> Hi Tim,
>>>>>
>>>>> last changes break build for the gw_ventana board. In fact, in case
>>>>> kernel is on a fs, we need to pass the name for kernel.  These two
>>>>> defines should be set into gw_ventana.h:
>>>>>
>>>>>         CONFIG_SPL_FS_LOAD_KERNEL_NAME
>>>>>         CONFIG_SPL_FS_LOAD_ARGS_NAME
>>>>>
>>>>> I could simply fix it, but it does not make sense without asking you :-)
>>>>>
>>>>> I have also seen that SPL for gw_ventana raises an exception because SPL
>>>>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>>>>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>>>>> mx6 with smaller SRAM has at least 128KB.
>>>>>
>>>>
>>>> Stefano,
>>>>
>>>> Thanks for the heads-up. I have to admit I haven't looked at mainline
>>>> u-boot on Ventana for quite some time - I'm still using a 2015-04
>>>> branch with some patches on top that I haven't had time to mainline
>>>> yet.
>>>>
>>>> When you say 'last changes' was there something specific? Something
>>>> must of grown the size of the SPL code quite a bit.
>>>
>>> I think (but I am not sure) the biggest increase was done by allowing to
>>> load image directly from filesystem, and then the size increased.
>>>
>>> But I admit I did not take a closer look before - it looks like that
>>> gw_ventana is the first to fail, just because it supports more methods
>>> for booting. Most boards boots just from one media,
>>>
>>
>> That makes sense.
>>
>> Looking at my notes (again this is based on 2015.04) I found the
>> following increases in SPL:
>>
>> base+serial+i2c: 23K
>> +mmc: +12K
>> +nand: +8K
>> +gpio: +4K
>> +env: +12K (big!)
>> +fat: +4K
>> +ext: +8K
>> +fastboot: +4K
>>
>> These numbers were with backported thumb binary support (without it
>> they get much more inflated).
>>
>> My SPL is at 63K currently but that is largely because I'm including
>> nand+mmc and env (both env from nand and from mmc) with the help of a
>> patch to allow either env that didn't get accepted upstream (because
>> of the desire to re-write the env code for DM). I was after a single
>> SPL that could handle a NAND or MMC boot device.
>>
>> I don't include fs support simply because I didn't have the room so if
>> that truly was added I can see how that through it over the edge.
>>
>> I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
>> just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
>> me that should be in the board config file(s) where needed and not in
>> the general SPL config file, otherwise your adding support that some
>> boards (like ventana!) don't have room for.
>>
> 
> Yes, agree - this should be splitted and moved to board config files.
> 
>>>> Take a look at my comments at
>>>> the top of include/configs/imx6_spl.h and let me know if you find
>>>> something wrong with my analysis that led to a 64KB max.
>>>
>>> Nothing wrong, but as far as I know in start.S cache and muu are turned
>>> off, and they are turned on later again. This could let us to reuse
>>> maybe the 24KB space previously set by the Bootrom
>>
>> they may be turned off by the time we get to U-Boot SPL or within
>> U-Boot SPL but the question is 'does the boot ROM need them?'. I
>> suppose its not too difficult to test by artificially growing the SPL
>> with random/zero'd data and letting it clobber the 24KB shown for the
>> MMU table.
> 
> Right - and it should be very nice to know what happens to the
> "reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks
> like that the Boot ROM does not use it - but it is marked as reserved in
> the manual, and for this reason it was never used, but I am now
> speculating if the space can be taken for our purposes.

It's it used during HAB ? It might be some area used by the crypto
coprocessor or somesuch.


-- 
Best regards,
Marek Vasut

[U-Boot] Breakage on gw_ventana

[Tim Harvey]

On Fri, May 20, 2016 at 5:50 AM, Marek Vasut <marex@denx.de> wrote:
> On 05/20/2016 02:41 PM, Stefano Babic wrote:
>> Hi Tim,
>>
>> On 19/05/2016 16:34, Tim Harvey wrote:
>>> On Thu, May 19, 2016 at 7:05 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>> Hi Tim,
>>>>
>>>> On 19/05/2016 15:48, Tim Harvey wrote:
>>>>> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>>>> Hi Tim,
>>>>>>
>>>>>> last changes break build for the gw_ventana board. In fact, in case
>>>>>> kernel is on a fs, we need to pass the name for kernel.  These two
>>>>>> defines should be set into gw_ventana.h:
>>>>>>
>>>>>>         CONFIG_SPL_FS_LOAD_KERNEL_NAME
>>>>>>         CONFIG_SPL_FS_LOAD_ARGS_NAME
>>>>>>
>>>>>> I could simply fix it, but it does not make sense without asking you :-)
>>>>>>
>>>>>> I have also seen that SPL for gw_ventana raises an exception because SPL
>>>>>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>>>>>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>>>>>> mx6 with smaller SRAM has at least 128KB.
>>>>>>
>>>>>
>>>>> Stefano,
>>>>>
>>>>> Thanks for the heads-up. I have to admit I haven't looked at mainline
>>>>> u-boot on Ventana for quite some time - I'm still using a 2015-04
>>>>> branch with some patches on top that I haven't had time to mainline
>>>>> yet.
>>>>>
>>>>> When you say 'last changes' was there something specific? Something
>>>>> must of grown the size of the SPL code quite a bit.
>>>>
>>>> I think (but I am not sure) the biggest increase was done by allowing to
>>>> load image directly from filesystem, and then the size increased.
>>>>
>>>> But I admit I did not take a closer look before - it looks like that
>>>> gw_ventana is the first to fail, just because it supports more methods
>>>> for booting. Most boards boots just from one media,
>>>>
>>>
>>> That makes sense.
>>>
>>> Looking at my notes (again this is based on 2015.04) I found the
>>> following increases in SPL:
>>>
>>> base+serial+i2c: 23K
>>> +mmc: +12K
>>> +nand: +8K
>>> +gpio: +4K
>>> +env: +12K (big!)
>>> +fat: +4K
>>> +ext: +8K
>>> +fastboot: +4K
>>>
>>> These numbers were with backported thumb binary support (without it
>>> they get much more inflated).
>>>
>>> My SPL is at 63K currently but that is largely because I'm including
>>> nand+mmc and env (both env from nand and from mmc) with the help of a
>>> patch to allow either env that didn't get accepted upstream (because
>>> of the desire to re-write the env code for DM). I was after a single
>>> SPL that could handle a NAND or MMC boot device.
>>>
>>> I don't include fs support simply because I didn't have the room so if
>>> that truly was added I can see how that through it over the edge.
>>>
>>> I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
>>> just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
>>> me that should be in the board config file(s) where needed and not in
>>> the general SPL config file, otherwise your adding support that some
>>> boards (like ventana!) don't have room for.
>>>
>>
>> Yes, agree - this should be splitted and moved to board config files.

Marek,

Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
config? It looks like the novena board was the only one using it and
it breaks Ventana build.

>>
>>>>> Take a look at my comments at
>>>>> the top of include/configs/imx6_spl.h and let me know if you find
>>>>> something wrong with my analysis that led to a 64KB max.
>>>>
>>>> Nothing wrong, but as far as I know in start.S cache and muu are turned
>>>> off, and they are turned on later again. This could let us to reuse
>>>> maybe the 24KB space previously set by the Bootrom
>>>
>>> they may be turned off by the time we get to U-Boot SPL or within
>>> U-Boot SPL but the question is 'does the boot ROM need them?'. I
>>> suppose its not too difficult to test by artificially growing the SPL
>>> with random/zero'd data and letting it clobber the 24KB shown for the
>>> MMU table.
>>
>> Right - and it should be very nice to know what happens to the
>> "reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks
>> like that the Boot ROM does not use it - but it is marked as reserved in
>> the manual, and for this reason it was never used, but I am now
>> speculating if the space can be taken for our purposes.
>
> It's it used during HAB ? It might be some area used by the crypto
> coprocessor or somesuch.

That's a good question. Are you using HAB anywhere or anyone else we
know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE
to 0x00900000?

Regards,

Tim

[U-Boot] Breakage on gw_ventana

[Marek Vasut]

On 05/20/2016 03:10 PM, Tim Harvey wrote:
> On Fri, May 20, 2016 at 5:50 AM, Marek Vasut <marex@denx.de> wrote:
>> On 05/20/2016 02:41 PM, Stefano Babic wrote:
>>> Hi Tim,
>>>
>>> On 19/05/2016 16:34, Tim Harvey wrote:
>>>> On Thu, May 19, 2016 at 7:05 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>>> Hi Tim,
>>>>>
>>>>> On 19/05/2016 15:48, Tim Harvey wrote:
>>>>>> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>>>>> Hi Tim,
>>>>>>>
>>>>>>> last changes break build for the gw_ventana board. In fact, in case
>>>>>>> kernel is on a fs, we need to pass the name for kernel.  These two
>>>>>>> defines should be set into gw_ventana.h:
>>>>>>>
>>>>>>>         CONFIG_SPL_FS_LOAD_KERNEL_NAME
>>>>>>>         CONFIG_SPL_FS_LOAD_ARGS_NAME
>>>>>>>
>>>>>>> I could simply fix it, but it does not make sense without asking you :-)
>>>>>>>
>>>>>>> I have also seen that SPL for gw_ventana raises an exception because SPL
>>>>>>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>>>>>>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>>>>>>> mx6 with smaller SRAM has at least 128KB.
>>>>>>>
>>>>>>
>>>>>> Stefano,
>>>>>>
>>>>>> Thanks for the heads-up. I have to admit I haven't looked at mainline
>>>>>> u-boot on Ventana for quite some time - I'm still using a 2015-04
>>>>>> branch with some patches on top that I haven't had time to mainline
>>>>>> yet.
>>>>>>
>>>>>> When you say 'last changes' was there something specific? Something
>>>>>> must of grown the size of the SPL code quite a bit.
>>>>>
>>>>> I think (but I am not sure) the biggest increase was done by allowing to
>>>>> load image directly from filesystem, and then the size increased.
>>>>>
>>>>> But I admit I did not take a closer look before - it looks like that
>>>>> gw_ventana is the first to fail, just because it supports more methods
>>>>> for booting. Most boards boots just from one media,
>>>>>
>>>>
>>>> That makes sense.
>>>>
>>>> Looking at my notes (again this is based on 2015.04) I found the
>>>> following increases in SPL:
>>>>
>>>> base+serial+i2c: 23K
>>>> +mmc: +12K
>>>> +nand: +8K
>>>> +gpio: +4K
>>>> +env: +12K (big!)
>>>> +fat: +4K
>>>> +ext: +8K
>>>> +fastboot: +4K
>>>>
>>>> These numbers were with backported thumb binary support (without it
>>>> they get much more inflated).
>>>>
>>>> My SPL is at 63K currently but that is largely because I'm including
>>>> nand+mmc and env (both env from nand and from mmc) with the help of a
>>>> patch to allow either env that didn't get accepted upstream (because
>>>> of the desire to re-write the env code for DM). I was after a single
>>>> SPL that could handle a NAND or MMC boot device.
>>>>
>>>> I don't include fs support simply because I didn't have the room so if
>>>> that truly was added I can see how that through it over the edge.
>>>>
>>>> I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
>>>> just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
>>>> me that should be in the board config file(s) where needed and not in
>>>> the general SPL config file, otherwise your adding support that some
>>>> boards (like ventana!) don't have room for.
>>>>
>>>
>>> Yes, agree - this should be splitted and moved to board config files.
> 
> Marek,
> 
> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
> config? It looks like the novena board was the only one using it and
> it breaks Ventana build.

I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
ventana. If we have FS boot, we should push for filesystems which are
not a patent minefield (like fat).

So what about adding this to ventana:
#undef CONFIG_SPL_EXT_SUPPORT

>>>
>>>>>> Take a look at my comments at
>>>>>> the top of include/configs/imx6_spl.h and let me know if you find
>>>>>> something wrong with my analysis that led to a 64KB max.
>>>>>
>>>>> Nothing wrong, but as far as I know in start.S cache and muu are turned
>>>>> off, and they are turned on later again. This could let us to reuse
>>>>> maybe the 24KB space previously set by the Bootrom
>>>>
>>>> they may be turned off by the time we get to U-Boot SPL or within
>>>> U-Boot SPL but the question is 'does the boot ROM need them?'. I
>>>> suppose its not too difficult to test by artificially growing the SPL
>>>> with random/zero'd data and letting it clobber the 24KB shown for the
>>>> MMU table.
>>>
>>> Right - and it should be very nice to know what happens to the
>>> "reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks
>>> like that the Boot ROM does not use it - but it is marked as reserved in
>>> the manual, and for this reason it was never used, but I am now
>>> speculating if the space can be taken for our purposes.
>>
>> It's it used during HAB ? It might be some area used by the crypto
>> coprocessor or somesuch.
> 
> That's a good question. Are you using HAB anywhere or anyone else we
> know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE
> to 0x00900000?

I am not using HAB on mx6, I think there was only one user of it ever.

> Regards,
> 
> Tim
> 


-- 
Best regards,
Marek Vasut

[U-Boot] Breakage on gw_ventana

[Stefano Babic]

Hi Marek, Tim,

On 20/05/2016 15:16, Marek Vasut wrote:

>> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
>> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
>> config? It looks like the novena board was the only one using it and
>> it breaks Ventana build.
> 
> I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
> ventana. If we have FS boot, we should push for filesystems which are
> not a patent minefield (like fat).
> 
> So what about adding this to ventana:
> #undef CONFIG_SPL_EXT_SUPPORT

Agree. This makes sense. We set as common rules what most boards need,
if that let us the way to disable for some boards. The way described by
Marek does this.

>>> It's it used during HAB ? It might be some area used by the crypto
>>> coprocessor or somesuch.
>>
>> That's a good question. Are you using HAB anywhere or anyone else we
>> know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE
>> to 0x00900000?
> 
> I am not using HAB on mx6, I think there was only one user of it ever.

HAB remains a use case, but I cannot find in the manual any reference
for the IRAM (if any) it needs.

Regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] Breakage on gw_ventana

[Tim Harvey]

On Fri, May 20, 2016 at 6:16 AM, Marek Vasut <marex@denx.de> wrote:
>> Marek,
>>
>> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
>> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
>> config? It looks like the novena board was the only one using it and
>> it breaks Ventana build.
>
> I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
> ventana. If we have FS boot, we should push for filesystems which are
> not a patent minefield (like fat).
>
> So what about adding this to ventana:
> #undef CONFIG_SPL_EXT_SUPPORT
>

sounds reasonable - I'll submit that shortly

Regards,

Tim

[U-Boot] Breakage on gw_ventana

[Marek Vasut]

On 05/20/2016 04:23 PM, Tim Harvey wrote:
> On Fri, May 20, 2016 at 6:16 AM, Marek Vasut <marex@denx.de> wrote:
>>> Marek,
>>>
>>> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
>>> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
>>> config? It looks like the novena board was the only one using it and
>>> it breaks Ventana build.
>>
>> I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
>> ventana. If we have FS boot, we should push for filesystems which are
>> not a patent minefield (like fat).
>>
>> So what about adding this to ventana:
>> #undef CONFIG_SPL_EXT_SUPPORT
>>
> 
> sounds reasonable - I'll submit that shortly

Cool, thanks!


-- 
Best regards,
Marek Vasut