[U-Boot] Breakage on gw_ventana

[Tim Harvey]

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.

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