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

[Andre Przywara]

Hi,

On 12/12/16 16:18, Chen-Yu Tsai wrote:
> On Tue, Dec 13, 2016 at 12:04 AM, Andre Przywara <andre.przywara at arm.com> 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).
>> 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.
> 
> Bailing out should be expected. LPDDR3 runs at a lower voltage, so the
> standard DDR3 chip w/ LPDDR3 boot0 would not get sufficient power to
> work.

I don't think this is the reason. The AXP803 has a pin to externally
select a reset voltage for DCDC5, which drives the DRAM chips. So a
board vendor would connect this pin appropriately to match the
_soldered_ DRAM chips.

> Also, it seems LPDDR3 uses a different protocol.

Yes, that's what I found also, and I hope that this is sufficient enough
to reliably tell the two apart. Somehow the algorithm found out that
something is wrong and quit. I was wondering if this could be used in a
reliable way.

> I'm not an expert
> on this though. See
> 
> https://blogs.synopsys.com/committedtomemory/2014/01/10/when-is-lpddr3-not-lpddr3-when-its-ddr3l/
> https://blogs.synopsys.com/committedtomemory/files/2014/01/DDR3-DDR3L-LPDDR3-Comparison.jpg

Thanks for those links, I will add these to my constantly piling up heap
of "how DRAM works" documents that populate my desktop lately, leading
to the OOM killer going 'round yesterday on my machine ;-)

> As I see it, there would need to be 2 settings:
> 
>   a) RAM type. We already have a Kconfig option to support LPDDR2 for
>      the A83T.

Yes, though it's just DDR3 vs LPDDR3 in our case.

>   b) DRAM speed bin. This would probably select one of the standard
>      JEDEC timings for the selected DRAM type.

Yes.

> 
> Note that Allwinner's boot0 supposedly just has all the DRAM parameters
> in its header, including options to use standard or custom timings.

By staring at the boot0 disassembly lately I believe the existing
boot0's ignore all those numerous parameters unless a bit in this tpr13
parameter is set (which is clear on the A64 one).
Instead they just derive the timing parameters from the given frequency,
though in a slightly non-standard (wrong?) way.

So yes: I hope that just "memory type" and "frequency/JEDEC speed bin"
should be sufficient to get the right DRAM setup, which could then
happily live as two Kconfig parameters.

Cheers,
Andre.


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