[U-Boot] [RESEND PATCH 0/3] arm: Introduce writel/readl_relaxed accessors
Jagan Teki
jagan at amarulasolutions.com
Thu Apr 18 16:59:42 UTC 2019
On Thu, Apr 18, 2019 at 6:07 AM André Przywara <andre.przywara at arm.com> wrote:
>
> On 17/04/2019 13:00, Jagan Teki wrote:
> > On Mon, Apr 15, 2019 at 1:21 PM André Przywara <andre.przywara at arm.com> wrote:
> >>
> >> On 15/04/2019 07:22, Jagan Teki wrote:
> >>
> >> Hi,
> >>
> >>> On Mon, Apr 15, 2019 at 11:40 AM Chen-Yu Tsai <wens at kernel.org> wrote:
> >>>>
> >>>> On Mon, Apr 15, 2019 at 2:07 PM Jagan Teki <jagan at amarulasolutions.com> wrote:
> >>>>>
> >>>>> On Sun, Feb 10, 2019 at 9:49 PM Andre Przywara <andre.przywara at arm.com> wrote:
> >>>>>>
> >>>>>> Hi, this is a resend of what I posted some weeks ago, just adding the
> >>>>>> missing Signed-off-by: in patch 2/3, as pointed out by Philipp. I used
> >>>>>> the opportunity to add his Reviewed-by: tags on the first two patches.
> >>>>>> (Many thanks for that!) The rest is unchanged.
> >>>>>> -------------------
> >>>>>>
> >>>>>> Admittedly this is the long way round to solve some nasty SPL code size
> >>>>>> problem, but it looked beneficial to others as well, so here we go:
> >>>>>>
> >>>>>> arch/arm/include/asm/io.h looks like it's been around since the dawn of
> >>>>>> time, and was more or less blindly copied from Linux.
> >>>>>> We don't use and don't need most of the definitions, and mainline Linux
> >>>>>> got rid of them anyway, so patch 1/3 cleans up this header file to
> >>>>>> just contain what we need in U-Boot.
> >>>>>>
> >>>>>> Patch 2/3 introduces readl/writel_relaxed accessors, which are cheaper,
> >>>>>> but more importantly save one (barrier) instruction per accessor. This
> >>>>>> helps to bring down code size, since especially DRAM controller inits in
> >>>>>> SPLs tend to do a lot of MMIO.
> >>>>>>
> >>>>>> Consequently patch 3/3 introduces them in the Allwinner H6 DRAM driver,
> >>>>>> which reduces the SPL size by a whopping 2KB, due to a twist:
> >>>>>> The AArch64 exception table needs to be 2KB aligned, but we don't do
> >>>>>> anything special about it the linker script. So depending on where the
> >>>>>> code before the vectors ends, we have potentially large padding:
> >>>>>> At the moment this last address is 0x1824 for the H6, so the vectors can
> >>>>>> only start at 0x2000. By reducing the code size before the vectors by just
> >>>>>> (at least) 9 instructions, the vectors start at 0x1800 and we save most of
> >>>>>> the padding.
> >>>>>
> >>>>> How come it reduces to 2KB? I can see the diff size of 160 bytes for gcc-6.3.1
> >>>>>
> >>>>> ₹ aarch64-linux-gnu-size spl/u-boot-spl*
> >>>>> text data bss dec hex filename
> >>>>> 28376 408 504 29288 7268 spl/u-boot-spl
> >>>>>
> >>>>> ₹ aarch64-linux-gnu-size spl/u-boot-spl*
> >>>>> text data bss dec hex filename
> >>>>> 28216 408 504 29128 71c8 spl/u-boot-spl
> >>>>
> >>>> Because of section alignment issues? I believe Andre is referring to the
> >>>> size of the whole file. Since it gets loaded as a whole, the total size
> >>>> is what matters, not the size of the individual sections.
> >>>
> >>> Well, the input for final sunxi-spl.bin would be u-boot-spl and the
> >>> above shows the size of file as well 29128 bytes with -160 bytes from
> >>> 29288.
> >>>
> >>> Since the size of sunxi-spl.bin is truncated to 32K, I couldn't see
> >>> any difference either.
> >>
> >> As mentioned in the commit messasge, this is a fragile topic. Since
> >> commit ef331e3685fe ("armv8: Disable exception vectors in SPL by
> >> default") we disable the SPL exception vectors by default now, so the
> >> numbers are now different.
> >
> > Sorry, I over looked the commit messages.
> >
> >> You should be able to see the 2K saving with the SPL exception vectors
> >> explicitly enabled in menuconfig.
> >
> > Oh. So I enabled the vectors via ARMV8_SPL_EXCEPTION_VECTORS=y but it
> > seems increased the SPL size.
> >
> > ₹ aarch64-linux-gnu-size spl/u-boot-spl
> > text data bss dec hex filename
> > 30130 408 504 31042 7942 spl/u-boot-spl
>
> Sure, I meant you should see an effect with vs. without these patches,
> both with the vectors enabled. But as mentioned, this is somewhat
> random, depending on other code changes.
> With current mainline for pine_h64_defconfig I get 29344 vs. 29504 bytes
> without the vectors, and 31202 vs. "will not fit" with the vectors.
Okay.
More information about the U-Boot
mailing list