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. > >>>> 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. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
