[U-Boot] Breakage on gw_ventana

[Tim Harvey]

On Fri, May 20, 2016 at 5:50 AM, Marek Vasut <marex at 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 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.

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