On 26/11/17 00:15, Dr. Philipp Tomsich wrote: > >> On 26 Nov 2017, at 01:06, André Przywara <andre.przyw...@arm.com> wrote: >> >> On 25/11/17 23:35, Dr. Philipp Tomsich wrote: >>> Jagan, >>> >>> I resolved this by introducing a new Kconfig that affects what functionality >>> is included in spl_fit.c; however, this leaves an uneasy feeling, as we now >>> start to have different logic in our SPL stage. >> >> Thanks for taking care. Is that about Falcon boot? Don't we need >> explicit platform support for this anyway? Then disabling this looks >> much cleaner, if sunxi just doesn't support this for now (until we find >> a good solution). > > It is related to, but not caused by, the Falcon boot support. I need to > record the loadables into the FDT, so ATF is aware of some bits and > pieces (i.e. PMU firmware) that gets loaded. > > As this needs to tie in with the Falcon changes, some refactoring was > needed before adding our new functionality—and this pushed sun50i > over the edge, even if only the refactoring was included.
Ah, OK, thanks for the explanation. >> >>> Is there a plan in place to move sun50i to a TPL->SPL->U-Boot model? >> >> I am not aware that anyone has ever started looking into this. So far we >> were thinking about other options: >> 1) Use runtime decompression. ssvb mentioned this several times. The >> boot ROM limits the load to 32KB, but the ARMv8 SoCs have in fact bigger >> SRAM than that. >> Siarhei, is this the time you come to the rescue with a flying cape? >> >> 2) Try to shave off some bits here and there. For instance I once >> proposed a "tiny ctype" implementation, which saved around 200 bytes. >> However this didn't save space universally for every platform or board, >> so I dropped this back then. >> >> 3) Compile the SPL as ARM (using Thumb2). This gives quite some savings >> and we should be good for quite a while with this. I keep a working >> branch around[1]. >> >> 4) Try to compile with -mabi=ilp32 to see if that saves some space, due >> to pointers and longs being only 32-bit (which is all we need on sunxi >> anyway, but especially for the SPL). Last time I tried this triggered >> ICE's in GCC, but I might give this a shot again. >> >> Point 3) gives us the biggest and sustainable saving, but has serious >> implications to the build system, as we now need two (cross-)compilers >> to generate an image. In the moment I solve this manually by using a >> different defconfig, compiling with arm-gcc and saving the generated spl >> binary. Then I re-configure for AArch64 and compile U-Boot proper, >> manually glueing the two together. >> >> Can you elaborate what makes your code blow up the SPL image? > > Cleaning up the various code paths (and yes: this is related to Falcon > support in spl_fit.c) introduced a call to > fit_image_get_os() > which adds a bit of bulk. > >> From what >> I understand you mentioned the exception vector alignment, I guess it's >> the ".align 11" in exceptions.S? So what does this push over the 2K >> edge here? > > The exception vector alignment wastes approx. 1600 byte in sun50i > images, as of writing. Indeed, I just found this myself. I guess it's quite risky to play with the linker script to find some more clever location with less padding for the table, as the script covers *all* platforms with ARMv8 SPL support. One thing I found is that our exception code is 136 bytes per entry, which is just 8 bytes more than we could directly put into the table. So we waste 124 bytes per entry by just placing a branch in there. And apart from the register savings there is mostly our dynamic EL determination that uses code, which I am not sure is useful in an exception context at all. We should actually very much know which EL we are in, for a given particular table entry. I'll try tomorrow to bring this down to 32 instructions. But apart from that I am wondering about the usefulness of the exception table for the SPL in general. I guess we don't loose much if we just drop it (somehow)? Cheers, Andre >> I was wondering if we could build (or copy) the exception table on the >> fly instead of relying it to be verbatim and properly aligned in the >> image file? >> >> Cheers, >> Andre. >> >> [1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip >> >>> >>> Thanks, >>> Philipp. >>> >>>> On 24 Nov 2017, at 21:42, Dr. Philipp Tomsich >>>> <philipp.toms...@theobroma-systems.com> wrote: >>>> >>>>> >>>>> On 24 Nov 2017, at 21:36, Jagan Teki <ja...@amarulasolutions.com> wrote: >>>>> >>>>> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich >>>>> <philipp.toms...@theobroma-systems.com> wrote: >>>>>> Jagan, Maxime & Tom, >>>>>> >>>>>> I have a couple of changes to spl_fit.c queued that we need to get >>>>>> merged to fix some issues for ATF support on Rockchip platforms. >>>>> >>>>> Does all rk64 has enough SPL size's to fit? >>>> >>>> The 64bit Rockchip platforms either have more than enough SRAM (i.e. the >>>> RK3399) or are already using a TPL w/ SPL executing in DRAM. >>>> So the only failures I get are sun50i and sun50i_h3 platforms. >>>> >>>>> >>>>>> However, due to internal alignment before the ARMv8 vectors, this breaks >>>>>> the sun50i builds (all exceeding their SPL size by up to approx. 1KB), >>>>>> even though I am adding only about a 100 bytes to the size of spl_fit.c. >>>>> >>>>> Yes, as per as my trails[1] it's not possible to increase SPL size. >>>> >>>> That is why I was suggesting to remove exceptions for sun50i for the time >>>> being, as the alignment for the vectors is more than 1kB in binary size. >>>> >>>>>> The change that triggers this is: >>>>>> https://patchwork.ozlabs.org/patch/813598/ >>>>>> >>>>>> However, the root cause lies in the “.align 11” in exceptions.c, which >>>>>> generates a ‘*fill*’ similar to this one (and we have been lucky enough >>>>>> that this came out as a rather small number up until me increasing the >>>>>> size of spl_fit.o): >>>>>> *fill* 0x0000000000011214 0x5ec >>>>>> .text.vectors 0x0000000000011800 0x838 >>>>>> arch/arm/cpu/armv8/built-in.o >>>>>> >>>>>> The quickest way to resolve would be to drop support for exception >>>>>> vectors on sun50i. >>>>> >>>>> Don't we miss the exceptions during SPL? >>>>> >>>>>> Any other suggestions are also welcome. >>>>> >>>>> I would rather think to implement TPL provided if there is no option >>>>> to increase the SPL size instead of missing exception vectors. >>>> >>>> Someone will have to do this eventually, as the sun50i platforms are >>>> becoming an issue for other platforms now. >>>> >>>>> >>>>> [1] https://patchwork.ozlabs.org/patch/835973/ >>>>> >>>>> thanks! >>>>> -- >>>>> Jagan Teki >>>>> Senior Linux Kernel Engineer | Amarula Solutions >>>>> U-Boot, Linux | Upstream Maintainer >>>>> Hyderabad, India. >>>> >>>> _______________________________________________ >>>> U-Boot mailing list >>>> U-Boot@lists.denx.de >>>> https://lists.denx.de/listinfo/u-boot >>> >> > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
