[U-Boot] [PATCH] arm: sunxi: initial support for NanoPi Neo2

[Andreas Färber]

Am 24.05.2017 um 14:44 schrieb Andre Przywara:
> On 24/05/17 12:50, Andreas Färber wrote:
>> Am 09.05.2017 um 14:43 schrieb Patrick Wildt:
>>> The NanoPi Neo2 is basically the same as the NanoPi Neo, but that they
>>> replaced the SoC with the 64-bit Allwinner H5 SoC.  Add a (64-bit only)
>>> defconfig defining the required options to build the U-Boot proper.
>>>
>>> Create a new .dts file for it by including the (32-bit) H3 SoC .dtsi
>>> and changing the differing components accordingly, like it's been
>>> done for the OrangePi PC 2.
>>>
>>> Signed-off-by: Patrick Wildt <patrick at blueri.se>
>>
>> I've tested this patch on top of yesterday's master branch
>> (4c78028737c3185f49f5691183aeac3478b5f699 "mksunxi_fit_atf.sh: Allow for
>> this to complete when bl31.bin is missing").
>>
>> Considering Tom's unanswered question, is there any diff to the upstream
>> kernel .dts? Expected would be to just copy the Linux .dts file here and
>> to state which tree and commit/tag it was taken from.
> 
> I think we have a similar diversion between Linux and U-Boot .dts here,
> given that the U-Boot support was merged earlier.
> Updating the DTs for H5 and the board(s) was on my plan, but it's a bit
> more involved since it affects the H3 .dts as well (H3 and H5 use a
> shared stub .dtsi now). Also the H5 .dtsi just got into Linux
> (4.12-rc1), so it hasn't been in an officially released kernel yet.
> 
>> Using this dtb here via UEFI distro boot, my openSUSE kernel image that
>> booted okay on orangepi_pc2 fails to find the MMC devices on Neo2,
>> although it obviously succeeded to boot from SD in U-Boot and GRUB...

Hmm, this may be related to my initrd being too big for 512 MB RAM:

[    0.298393] Unpacking initramfs...
[    3.619116] Initramfs unpacking failed: write error
[    3.671293] Freeing initrd memory: 72888K

>> Also, if I "reset" from the downstream or patched mainline U-Boot
>> prompt, SPL gets stuck:
>>
>> => reset
>> resetting ...
>> INFO:    PSCI Affinity Map:
>> INFO:      AffInst: Level 0, MPID 0x0, State ON
>> INFO:      AffInst: Level 0, MPID 0x1, State OFF
>> INFO:      AffInst: Level 0, MPID 0x2, State OFF
>> INFO:      AffInst: Level 0, MPID 0x3, State OFF
>>
>> U-Boot SPL 2017.05-00660-g4bffee2792 (May 24 2017 - 00:43:24)
>> DRAM: 512 MiB
>> Trying to boot from MMC1
>>
>>
>> If instead I unpower it (by plugging Micro USB), it boots okay:
>>
>> U-Boot SPL 2017.05-00660-g4bffee2792 (May 24 2017 - 00:43:24)
>> DRAM: 512 MiB
>> Trying to boot from MMC1
>> NOTICE:  BL3-1: Running in SRAM A2 (@0x44000)
>> NOTICE:  Configuring SPC Controller
>> NOTICE:  BL3-1: v1.0(debug):1.0~20160809T000419~45ab97e
>> NOTICE:  BL3-1: Built : 01:01:56, Nov 15 2016
> 
> Your ATF build is quite old, it doesn't really support the H5.
> Please you the latest HEAD[1], it should print the SoC name at the
> beginning, and then won't try to configure an AXP on the H5.

Switching from allwinner-scpi to allwinner branch I now see H5:

NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):1.0~20170220T001539�aa75c8da
NOTICE:  BL3-1: Built : 12:54:47, May 24 2017
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9

but the reset issue persists. It appears to be a works-sometimes type
problem - could it depend on SRAM contents or something? (1 out of ~5)

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)