[U-Boot] [PATCH v2 23/23] sunxi: A64: add 32-bit SPL support

[Maxime Ripard]

On Fri, Dec 16, 2016 at 03:39:06PM +0000, Andre Przywara wrote:
> On 16/12/16 14:52, Maxime Ripard wrote:
> > On Mon, Dec 12, 2016 at 04:04:23PM +0000, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 12/12/16 15:13, Maxime Ripard wrote:
> >>> On Tue, Dec 06, 2016 at 12:22:59PM +0000, Andre Przywara wrote:
> >>>> Hi,
> >>>>
> >>>> On 06/12/16 11:28, Maxime Ripard wrote:
> >>>>> On Mon, Dec 05, 2016 at 01:52:30AM +0000, Andre Przywara wrote:
> >>>>>> When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't
> >>>>>> use the more compact Thumb2 encoding, which only exists for AArch32
> >>>>>> code. This makes the SPL rather big, up to a point where any code
> >>>>>> additions or even a different compiler may easily exceed the 32KB limit
> >>>>>> that the Allwinner BROM imposes.
> >>>>>> Introduce a separate, mostly generic sun50i-a64 configuration, which
> >>>>>> defines the CPU_V7 symbol and thus will create a 32-bit binary using
> >>>>>> the memory-saving Thumb2 encoding.
> >>>>>
> >>>>> "mostly generic". Where do you draw the line? How do you deal with a
> >>>>> board that would use a different UART? a different MMC? different
> >>>>> memory configuration.?
> >>>>
> >>>> My impression was that it's rather pointless to provide another set of
> >>>> 32-bit SPL defconfigs for each board again, especially given that for
> >>>> the SPL's needs the boards so far seem to be very similar.
> >>>> For the loading part we will probably go with what the BROM already
> >>>> started: load more data from one of the BROM boot sources, which is
> >>>> fixed in the SoC and can't be really changed by a board vendor anyway.
> >>>> Which really leaves the DRAM setup and the UART.
> >>>
> >>> So you plan on enabling all BROM boot sources as well (NAND, SPI) ?
> >>
> >> In fact SPI works already (with little to no changes).
> > 
> > It's the little changes that I'm interested in to be honest :)
> 
> Well, thinking about it again I think normal SPI boot (legacy U-Boot
> image as the payload) requires no changes: just enable it in the
> defconfig. The patches I was talking about were about enabling FIT
> support on top of it.
> 
> The reason why it works is due to Siarhei's SPL SPI code and due to the
> fact it is kind of "supported" on these boards, which is not true for
> NAND on most boards, AFAIK.
> But if we get support for that, it would just work the same way, due to
> the boot source detection. So I think handling multiple boot sources
> within one SPL binary is a general sunxi SPL feature already implemented
> today. I definitely use the same thing for FEL, SPI and SD and eMMC.

At what offset for the SPL? U-Boot binary? with or without redundacy
for U-Boot? for the environment? with an environment in the first
place?

All those things are user configurable, and will also depend on some
board features (staring with the size of the EEPROM embedded on that
board). We should treat them as user configurable, and not just as
"meh, don't care, works for my setup".

> >> And I don't care about NAND, really ;-)
> >> Is anyone aware of an A64 board using this?
> > 
> > Well, it's one of the possible boot source, so we have to consider it
> > and not ignore it entirely hoping that no one will use it, ever.
> 
> But there isn't any support for it so far, is there? Even if we wanted
> to compile an SPL just for NAND.

The thing is once you started telling people to use something,
removing that something somewhere down the road is *not* nice. So I'd
really like to have it taken into account.

> > SPI booting was not used for 5-6 years, until someone started that
> > trend and now we have a significant number of boards implementing it.
> > 
> >>>> I can't predict the future, but so far those A64 boards look fairly
> >>>> similar in this respect. So I just avoid having another SPL defconfig
> >>>> for the BananaPi M64, for instance. I just added MMC_SUNXI_SLOT_EXTRA
> >>>> because this doesn't hurt on the Pine64, so less churn here.
> >>>>
> >>>> So if you know of any board which breaks this assumption, I am happy to
> >>>> hear about it and see if it can be integrated.
> >>>
> >>> I know at least of one board that uses the UART3 on A33, instead of
> >>> UART0. The trend is very clear on the A64 and the previous SoCs, but
> >>> we also had some variations, so we need to take that into
> >>> account. Which brings me back to my original question, where do you
> >>> draw the line ? :)
> >>
> >> I don't know, and to make this clear: I see the point in having separate
> >> configs for the SPL, but due to the 32-bit/64-bit split we probably need
> >> _two_ sets of defconfigs, which gets pretty messy very quickly.
> >> Especially given that they are very similar.
> >>
> >> So how do we avoid this? Can we somehow share a defconfig between armv8
> >> and armv7? In the moment "CONFIG_CPU_V7" and "CONFIG_ARM64" conflict in
> >> the same file.
> > 
> > I guess the easiest and most robust solution to do this would be to
> > just generate it from the defconfig. It really feels from your patches
> > that it's just a matter of sed -i 's/CONFIG_MACH_SUN50I/CONFIG_MACH_SUN50I_32'
> > on the "real" defconfig.
> 
> Yes, the difference between the defconfigs is really minimal. They look
> more different at the moment because we don't need Ethernet and USB in
> the SPL, for instance, and the SPI support is SPL only atm.
> But yeah, we could unify them, no question.
> 
> BUT: What do you mean exactly with: "just generate it from the defconfig"?
> Some Makefile hack? Like detecting 32 vs 64 with the help of the ARCH
> environment variable or ${CROSS_COMPILE}gcc -dumpmachine output?

Plugging into a makefile target seems for reasonable.

In particular, I guess that would imply:
  - Generating an spl/include/generated/autoconf.h
  - Since that file is included through include/linux/kconfig.h,
    create / copy that one over
  - Change UBOOTINCLUDE to have a different one for the SPL that would
    automatically pick the right kconfig.h

I guess some of that can also be eased through the include order in
the C flags.

Once that is done, you can easily mangle your configuration in the
Makefile rule only for the SPL.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161219/5e1dfde6/attachment.sig>