On 05/20/2016 03:10 PM, Tim Harvey wrote: > On Fri, May 20, 2016 at 5:50 AM, Marek Vasut <ma...@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 <sba...@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 <sba...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
