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