[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 at 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 at 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
=====================================================================