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

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