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

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


-- 
Best regards,
Marek Vasut