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

[Patrick Wildt]

On Wed, May 24, 2017 at 01:44:26PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 24/05/17 12:50, Andreas Färber wrote:
> > Hej Patrick,
> > 
> > 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 mailed Tom in private asking what to explictly state since 90% was
from u-boot and 10% from Linux-Sunxi (not mainline).  I didn't get a
reply, so there was no further mail from me.

So should I pull it now from v4.12-rc2?

Patrick

> 
> 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...
> > 
> > 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.
> Please let me know if that fixes your problem.
> 
> Cheers,
> Andre.
> 
> [1] https://github.com/apritzel/arm-trusted-firmware/commits/allwinner
> 
> > NOTICE:  Configuring AXP PMIC
> > ERROR:   set run-time address: 0x0
> > ERROR:   PMIC: unknown PMIC type number 0x0
> > ERROR:   Could not connect to AXP PMIC.
> > 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
> > 
> > 
> > U-Boot 2017.05-00660-g4bffee2792 (May 24 2017 - 00:43:24 +0200)
> > Allwinner Technology
> > 
> > CPU:   Allwinner H5 (SUN50I)
> > Model: FriendlyARM NanoPi NEO2
> > DRAM:  512 MiB
> > MMC:   SUNXI SD/MMC: 0
> > *** Warning - bad CRC, using default environment
> > 
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   No ethernet found.
> > starting USB...
> > USB0:   USB EHCI 1.00
> > USB1:   USB OHCI 1.0
> > scanning bus 0 for devices... 1 USB Device(s) found
> >        scanning usb for storage devices... 0 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > 
> > 
> > Andre, is this reset problem maybe an ATF issue?
> > 
> > Regards,
> > Andreas
> >