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

[Chen-Yu Tsai]

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. Also, it seems LPDDR3 uses a different protocol. 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

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.

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

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

Regards
ChenYu

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