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

[Andre Przywara]

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).
And I don't care about NAND, really ;-)
Is anyone aware of an A64 board using this?

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

> And that would prevent us from doing any kind of DRAM settings
> enhancements in the future, every one using the best common
> denominator, which seems inefficient.

Yeah, I think this is a much better point. I was a lot in DRAM land in
the past few days, and I think we _have_ different DRAMs already:
1) The Pine64 uses DDR3-1333 DRAM chips @ 672 MHz
2) The SoPine and the Pinebook use LPDDR3 DRAM, which requires a
slightly different setup, also the stock frequency in that one boot0.bin
floating around is much lower (524 MHz, IIRC).
3) The BananaPi M64 and Theobroma's board use SKhynix DDR3 DRAM chips
which are from a DDR3-1600 bin. I think Philipp reported to have it
running at 800 MHz with some sane JEDEC based timing happily, so it's
worth to enable this there.

Which brings us to the following complications:
a) We have similar, but still different DRAM _controllers_ (H3, A64,
H5). Those have a slightly different register set, though it seems to be
mostly missing/added features, so nothing really conflicting.
b) We have different DRAM _chips_ being used on top of possibly any of
those controllers.

So this brings us from "one type of DRAM chip on top of one DRAM
controller" today for the H3 driver to "multiple DRAM chips on top of
slightly different controllers", which is a totally different story.
I was looking into significantly reworking the DRAM driver to address
that, but was hoping to defer this to a later stage.

While the DRAM controller part can probably be solved by #ifdef'ing or
static parameters, I wonder if we should really explore how to address
different DRAM chips properly:
I) We create a DT binding loosely based on the "jedec,lpddr2-timings"
one in the kernel and use of-platdata as Simon suggested.
II) We create some fixed tables of standard (JEDEC) timings in the
driver and let one of those tables be selected at runtime based on some
parameters, for instance in the SPL header. This could as easy as
"DDR3-1333" vs. "LPDDR3-1066". This would allow us to adopt an existing
SPL to multiple chips/boards without needing to rebuild it, possibly
even open the door to auto-detection. For instance I found the LPDDR3
boot0 bailing out on the Pine64, so we might at least detect the
difference there.
III) Something in between.

It's just a pity that this could hold off upstreaming the Pine64 SPL
support.

Cheers,
Andre.

>> 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.
> 
> That would work for MMC and UART (in u-boot, not in the SPL), but not
> for the RAM setup.