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

[Andre Przywara <andre.przywara@arm.com>]

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.
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.

Actually I had the idea of eventually going the other way around:
Providing one U-Boot proper A64 defconfig and let the DT (provided by
the SPL) sort out the differences. Then we might be able to live with
separate SPL defconfigs. But that's another patchset and probably quite
some work.

> This looks like it's not generic at all, it's just a configuration for
> the Pine64.

And the BananaPi M64. And the upcoming Olimex board (trusting their
latest published schematics).
If in need, we can always provide separate defconfigs for "odd" boards.

So this is the best solution I came up with, if you have a better one: I
am all ears.
Would it make sense to rename this file to not claim universal coverage?

Cheers,
Andre.