Skip to contentSkip to conversation

arm: sunxi: initial support for NanoPi Neo2

PATCH New Patrick Wildt 5 participants 15 messages May 9, 2017 – Jun 1, 2017

Subsystems (3)
Network drivers Arm (32-bit) Arm/Allwinner sunXi SoC support
lore
Share & tools
lore

Patrick Wildt

author
#0 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

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 <[email protected]>
---
 arch/arm/dts/Makefile                  |   1 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 170 +++++++++++++++++++++++++++++++++
 board/sunxi/MAINTAINERS                |   5 +
 configs/nanopi_neo2_defconfig          |  19 ++++
 4 files changed, 195 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo2.dts
 create mode 100644 configs/nanopi_neo2_defconfig
arch/arm/dts/Makefile +1 -0
index 4d656ce4cc..fa2f3932cb 100644
@@ -311,6 +311,7 @@ dtb-$(CONFIG_MACH_SUN8I_R40) += \
 dtb-$(CONFIG_MACH_SUN8I_V3S) += \
 	sun8i-v3s-licheepi-zero.dtb
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
+	sun50i-h5-nanopi-neo2.dtb \
 	sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
 	sun50i-a64-pine64-plus.dtb \
arch/arm/dts/sun50i-h5-nanopi-neo2.dts new file +170 -0

170 lines not on this page · raw message

board/sunxi/MAINTAINERS +5 -0
index 1c8817375d..0c645bc7ca 100644
@@ -243,6 +243,11 @@ M:	Jelle van der Waa <[email protected]>
 S:	Maintained
 F:	configs/nanopi_neo_defconfig
 
+NANOPI-NEO2 BOARD
+M:	Patrick Wildt <[email protected]>
+S:	Maintained
+F:	configs/nanopi_neo2_defconfig
+
 NANOPI-NEO-AIR BOARD
 M:	Jelle van der Waa <[email protected]>
 S:	Maintained
configs/nanopi_neo2_defconfig new file +19 -0
new file mode 100644
index 0000000000..e0e50e33ba
@@ -0,0 +1,19 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_MACH_SUN50I_H5=y
+CONFIG_DRAM_CLK=504
+CONFIG_DRAM_ZQ=3881977
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-nanopi-neo2"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_CONSOLE_MUX=y
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SPL_SPI_SUNXI=y
+CONFIG_SUN8I_EMAC=y
+CONFIG_USB_EHCI_HCD=y
Signature · 1 line
2.12.2
#1 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 4 lines · 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.

Quoted 8 lines

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 <[email protected]>
---
 arch/arm/dts/Makefile                  |   1 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 170 +++++++++++++++++++++++++++++++++

Is this dts file coming from the Linux Kernel? If so, please cite the githash / tag that it's from, thanks.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170509/8337ec32/attachment.sig>
#2 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

In reply to Patrick Wildt

Hej Patrick,

Am 09.05.2017 um 14:43 schrieb Patrick Wildt:

Quoted 9 lines

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 <[email protected]>

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.

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

Signature · 3 lines
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
#3 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Hi,

Quoted 13 lines · Andreas Färber

Hej Patrick,

Am 09.05.2017 um 14:43 schrieb Patrick Wildt:

Quoted 9 lines

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 <[email protected]>
Quoted 7 lines

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.

Quoted 22 lines

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:

Quoted 7 lines

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

Quoted 35 lines
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

#4 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 24 lines · Andre Przywara

Hi,

Quoted 13 lines · Andreas Färber

Hej Patrick,

Am 09.05.2017 um 14:43 schrieb Patrick Wildt:

Quoted 9 lines

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 <[email protected]>
Quoted 7 lines

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.

Quoted 6 lines

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.

I'm fine with re-syncing to v4.12-rc2, btw.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170524/89bd152d/attachment.sig>
#5 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

In reply to Andre Przywara

Am 24.05.2017 um 14:44 schrieb Andre Przywara:

Quoted 20 lines · Andreas Färber
Quoted 11 lines

Am 09.05.2017 um 14:43 schrieb Patrick Wildt:

Quoted 9 lines

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 <[email protected]>
Quoted 7 lines

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.

Quoted 10 lines

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.

Quoted 3 lines

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
Quoted 26 lines
Quoted 18 lines

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:

Quoted 7 lines

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
Quoted 3 lines

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

Signature · 3 lines
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
author
#6 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

In reply to Andre Przywara
Quoted 23 lines · Andre Przywara

Hi,

Quoted 20 lines · Andreas Färber

Hej Patrick,

Am 09.05.2017 um 14:43 schrieb Patrick Wildt:

Quoted 9 lines

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 <[email protected]>

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

Quoted 83 lines

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.

Quoted 22 lines

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:

Quoted 7 lines

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

Quoted 35 lines
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

#7 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 25 lines · Patrick Wildt
Quoted 23 lines · Andre Przywara

Hi,

Quoted 20 lines · Andreas Färber

Hej Patrick,

Am 09.05.2017 um 14:43 schrieb Patrick Wildt:

Quoted 9 lines

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 <[email protected]>

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.

Quoted 5 lines

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?

Sorry. I'm trying to help make sure dts changes are on their way to the mainline Linux kernel, so that we don't get out of sync. So, does v4.12-rc2 have everything you need? Thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170601/ed4ffd7c/attachment.sig>
author
#8 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 30 lines · Tom Rini
Quoted 29 lines · Patrick Wildt
Quoted 23 lines · Andre Przywara

Hi,

Quoted 20 lines · Andreas Färber

Hej Patrick,

Am 09.05.2017 um 14:43 schrieb Patrick Wildt:

Quoted 9 lines

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 <[email protected]>

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.

Quoted 8 lines
Quoted 1 line

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

Sorry. I'm trying to help make sure dts changes are on their way to the mainline Linux kernel, so that we don't get out of sync. So, does v4.12-rc2 have everything you need? Thanks!

Signature · 1 line
Tom

There's even v4.12-rc3 now. It does not have the NanoPi Neo2, but I guess as a start one should do a sync for the rest of the stuff.

What's holding us up from using the Linux device trees without any changes? This diff I attach inline copies all a64, h3 and h5 related files from v4.12-rc3 (so, mainline) and modifies the emac driver to use the new pinmux attributes.

Copied from 5ed02dbb497422bf225783f46e6eadd237d23d6b, v4.12-rc3.

Opinions?

Patrick

arch/arm/dts/sun50i-a64-bananapi-m64.dts +0 -1
index 02db114..6872135 100644
@@ -1,6 +1,5 @@
 /*
  * Copyright (c) 2016 ARM Ltd.
- * Copyright (C) 2017 Jagan Teki <[email protected]>
  *
  * This file is dual-licensed: you can use it either under the terms
  * of the GPL or the X11 license, at your option. Note that this dual
arch/arm/dts/sun50i-h5-orangepi-pc2.dts +104 -63

228 lines not on this page · raw message

arch/arm/dts/sun50i-h5.dtsi new file +124 -0

124 lines not on this page · raw message

arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +34 -11

76 lines not on this page · raw message

arch/arm/dts/sun8i-h3-bananapi-m2-plus.dts +7 -14
index f3b1d5f..52acbe1 100644
@@ -46,7 +46,6 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
-#include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
 	model = "Banana Pi BPI-M2-Plus";

@@ -156,24 +155,18 @@
 
 &r_pio {
 	pwr_led_bpi_m2p: led_pins at 0 {
-		allwinner,pins = "PL10";
-		allwinner,function = "gpio_out";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+		pins = "PL10";
+		function = "gpio_out";
 	};
 
 	sw_r_bpi_m2p: key_pins at 0 {
-		allwinner,pins = "PL3";
-		allwinner,function = "gpio_in";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+		pins = "PL3";
+		function = "gpio_in";
 	};
 
 	wifi_en_bpi_m2p: wifi_en_pin {
-		allwinner,pins = "PL7";
-		allwinner,function = "gpio_out";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+		pins = "PL7";
+		function = "gpio_out";
 	};
 };
 

@@ -185,7 +178,7 @@
 
 &uart1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&uart1_pins_a>;
+	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
 	status = "okay";
 };
arch/arm/dts/sun8i-h3-nanopi-neo-air.dts +0 -1
index 3ba081c..03ff6f8 100644
@@ -45,7 +45,6 @@
 #include "sunxi-common-regulators.dtsi"
 
 #include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
 	model = "FriendlyARM NanoPi NEO Air";
arch/arm/dts/sun8i-h3-nanopi-neo.dts +0 -11
index 5113059..8d2cc6e 100644
@@ -46,14 +46,3 @@
 	model = "FriendlyARM NanoPi NEO";
 	compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
 };
-
-&emac {
-	phy = <&phy1>;
-	phy-mode = "mii";
-	allwinner,use-internal-phy;
-	allwinner,leds-active-low;
-	status = "okay";
-	phy1: ethernet-phy at 1 {
-		reg = <1>;
-	};
-};
arch/arm/dts/sun8i-h3-orangepi-2.dts +27 -29

92 lines not on this page · raw message

arch/arm/dts/sun8i-h3-orangepi-lite.dts +6 -13
index 1550fee..9b47a0d 100644
@@ -46,7 +46,6 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
-#include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
 	model = "Xunlong Orange Pi Lite";

@@ -143,26 +142,20 @@
 
 &pio {
 	leds_opc: led_pins at 0 {
-		allwinner,pins = "PA15";
-		allwinner,function = "gpio_out";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+		pins = "PA15";
+		function = "gpio_out";
 	};
 };
 
 &r_pio {
 	leds_r_opc: led_pins at 0 {
-		allwinner,pins = "PL10";
-		allwinner,function = "gpio_out";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+		pins = "PL10";
+		function = "gpio_out";
 	};
 
 	sw_r_opc: key_pins at 0 {
-		allwinner,pins = "PL3";
-		allwinner,function = "gpio_in";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+		pins = "PL3";
+		function = "gpio_in";
 	};
 };
arch/arm/dts/sun8i-h3-orangepi-one.dts +43 -23

111 lines not on this page · raw message

arch/arm/dts/sun8i-h3-orangepi-pc-plus.dts +2 -2
index 851fd2c..8b93f5c 100644
@@ -82,7 +82,7 @@
 
 &mmc2_8bit_pins {
 	/* Increase drive strength for DDR modes */
-	allwinner,drive = <SUN4I_PINCTRL_40_MA>;
+	drive-strength = <40>;
 	/* eMMC is missing pull-ups */
-	allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	bias-pull-up;
 };
arch/arm/dts/sun8i-h3-orangepi-pc.dts +32 -24

89 lines not on this page · raw message

arch/arm/dts/sun8i-h3-orangepi-plus.dts +4 -34
index e7079b2..8c40ab7 100644
@@ -47,18 +47,6 @@
 	model = "Xunlong Orange Pi Plus / Plus 2";
 	compatible = "xunlong,orangepi-plus", "allwinner,sun8i-h3";
 
-	reg_gmac_3v3: gmac-3v3 {
-		compatible = "regulator-fixed";
-		pinctrl-names = "default";
-		pinctrl-0 = <&gmac_power_pin_orangepi>;
-		regulator-name = "gmac-3v3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		startup-delay-us = <100000>;
-		enable-active-high;
-		gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>;
-	};
-
 	reg_usb3_vbus: usb3-vbus {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";

@@ -76,15 +64,6 @@
 	status = "okay";
 };
 
-&emac {
-	/* The Orange Pi Plus uses an external phy */
-	pinctrl-names = "default";
-	pinctrl-0 = <&emac_rgmii_pins>;
-	phy-supply = <&reg_gmac_3v3>;
-	phy-mode = "rgmii";
-	/delete-property/allwinner,use-internal-phy;
-};
-
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_8bit_pins>;

@@ -97,24 +76,15 @@
 
 &mmc2_8bit_pins {
 	/* Increase drive strength for DDR modes */
-	allwinner,drive = <SUN4I_PINCTRL_40_MA>;
+	drive-strength = <40>;
 	/* eMMC is missing pull-ups */
-	allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	bias-pull-up;
 };
 
 &pio {
-	gmac_power_pin_orangepi: gmac_power_pin at 0 {
-		allwinner,pins = "PD6";
-		allwinner,function = "gpio_out";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-	};
-
 	usb3_vbus_pin_a: usb3_vbus_pin at 0 {
-		allwinner,pins = "PG11";
-		allwinner,function = "gpio_out";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+		pins = "PG11";
+		function = "gpio_out";
 	};
 };
arch/arm/dts/sun8i-h3-orangepi-plus2e.dts +0 -30
index f97b040..5851a47 100644
@@ -50,34 +50,4 @@
 / {
 	model = "Xunlong Orange Pi Plus 2E";
 	compatible = "xunlong,orangepi-plus2e", "allwinner,sun8i-h3";
-
-	reg_gmac_3v3: gmac-3v3 {
-		compatible = "regulator-fixed";
-		pinctrl-names = "default";
-		pinctrl-0 = <&gmac_power_pin_orangepi>;
-		regulator-name = "gmac-3v3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		startup-delay-us = <100000>;
-		enable-active-high;
-		gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>;
-	};
-};
-
-&emac {
-	/* The Orange Pi Plus 2E uses an external gbit phy */
-	pinctrl-names = "default";
-	pinctrl-0 = <&emac_rgmii_pins>;
-	phy-supply = <&reg_gmac_3v3>;
-	phy-mode = "rgmii";
-	/delete-property/allwinner,use-internal-phy;
-};
-
-&pio {
-	gmac_power_pin_orangepi: gmac_power_pin at 0 {
-		allwinner,pins = "PD6";
-		allwinner,function = "gpio_out";
-		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-	};
 };
arch/arm/dts/sun8i-h3.dtsi +40 -448

505 lines not on this page · raw message

arch/arm/dts/sunxi-h3-h5.dtsi new file +601 -0

601 lines not on this page · raw message

configs/nanopi_neo2_defconfig new file +19 -0
new file mode 100644
index 0000000..74c7d74
@@ -0,0 +1,19 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN50I_H5=y
+CONFIG_SPL=y
+CONFIG_DRAM_CLK=504
+CONFIG_DRAM_ZQ=3881977
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-nanopi-neo2"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_CONSOLE_MUX=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUN8I_EMAC=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_SPL_SPI_SUNXI=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
drivers/net/sun8i_emac.c +11 -5
index a3dbe28..2526f72 100644
@@ -465,14 +465,20 @@ static int parse_phy_pins(struct udevice *dev)
 	}
 
 	drive = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
-					     "allwinner,drive", 4);
-	pull = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
-					    "allwinner,pull", 0);
+					     "drive-strength", 40) / 10;
+
+	if (fdt_getprop(gd->fdt_blob, offset, "bias-pull-down", NULL))
+		pull = 2;
+	else if (fdt_getprop(gd->fdt_blob, offset, "bias-pull-up", NULL))
+		pull = 1;
+	else
+		pull = 0;
+
 	for (i = 0; ; i++) {
 		int pin;
 
 		pin_name = fdt_stringlist_get(gd->fdt_blob, offset,
-					      "allwinner,pins", i, NULL);
+					      "pins", i, NULL);
 		if (!pin_name)
 			break;
 		if (pin_name[0] != 'P')

@@ -488,7 +494,7 @@ static int parse_phy_pins(struct udevice *dev)
 	}
 
 	if (!i) {
-		printf("WARNING: emac: cannot find allwinner,pins property\n");
+		printf("WARNING: emac: cannot find pins property\n");
 		return -2;
 	}
#9 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Am 01.06.2017 um 16:04 schrieb Patrick Wildt:

Quoted 4 lines

What's holding us up from using the Linux device trees without any changes? This diff I attach inline copies all a64, h3 and h5 related files from v4.12-rc3 (so, mainline) and modifies the emac driver to use the new pinmux attributes.

Andre or someone had already sent a series sync'ing a64 and pine64. Can you keep h5/h3 separate or rebase onto that series please to not cause merge conflicts? Thanks for your work on this.

Regards,
Andreas

P.S. Recently a couple mails to you bounced.

Signature · 3 lines
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
#10 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 9 lines · Andreas Färber

Am 01.06.2017 um 16:04 schrieb Patrick Wildt:

Quoted 4 lines

What's holding us up from using the Linux device trees without any changes? This diff I attach inline copies all a64, h3 and h5 related files from v4.12-rc3 (so, mainline) and modifies the emac driver to use the new pinmux attributes.

Andre or someone had already sent a series sync'ing a64 and pine64. Can you keep h5/h3 separate or rebase onto that series please to not cause merge conflicts? Thanks for your work on this.

Yeah, it's been on u-boot-sunxi/master

thanks!

Signature · 4 lines
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
author
#11 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 7 lines · Jagan Teki
Quoted 6 lines · Andreas Färber

Am 01.06.2017 um 16:04 schrieb Patrick Wildt:

Quoted 4 lines

What's holding us up from using the Linux device trees without any changes? This diff I attach inline copies all a64, h3 and h5 related files from v4.12-rc3 (so, mainline) and modifies the emac driver to use the new pinmux attributes.

Quoted 12 lines
Quoted 3 lines

Andre or someone had already sent a series sync'ing a64 and pine64. Can you keep h5/h3 separate or rebase onto that series please to not cause merge conflicts? Thanks for your work on this.

Yeah, it's been on u-boot-sunxi/master

thanks!

Signature · 4 lines
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

I had already rebased it against u-boot-sunxi/master, so the attached diff should be fine. Should I send it as a separate [PATCH] mail?

Thanks,
Patrick

#12 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 12 lines · Patrick Wildt
Quoted 11 lines · Jagan Teki
Quoted 9 lines · Andreas Färber

Am 01.06.2017 um 16:04 schrieb Patrick Wildt:

Quoted 4 lines

What's holding us up from using the Linux device trees without any changes? This diff I attach inline copies all a64, h3 and h5 related files from v4.12-rc3 (so, mainline) and modifies the emac driver to use the new pinmux attributes.

Andre or someone had already sent a series sync'ing a64 and pine64. Can you keep h5/h3 separate or rebase onto that series please to not cause merge conflicts? Thanks for your work on this.

Quoted 6 lines
Quoted 3 lines

Yeah, it's been on u-boot-sunxi/master

thanks!

I had already rebased it against u-boot-sunxi/master, so the attached diff should be fine. Should I send it as a separate [PATCH] mail?

To be clear, you were re-syncing those boards with only changes that will be going upstream to the Linux kernel at some point, right? Or are already there? And nothing U-Boot specific?

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170601/489e49fc/attachment.sig>
author
#13 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 15 lines · Tom Rini
Quoted 14 lines · Patrick Wildt
Quoted 13 lines · Jagan Teki
Quoted 9 lines · Andreas Färber

Am 01.06.2017 um 16:04 schrieb Patrick Wildt:

Quoted 4 lines

What's holding us up from using the Linux device trees without any changes? This diff I attach inline copies all a64, h3 and h5 related files from v4.12-rc3 (so, mainline) and modifies the emac driver to use the new pinmux attributes.

Andre or someone had already sent a series sync'ing a64 and pine64. Can you keep h5/h3 separate or rebase onto that series please to not cause merge conflicts? Thanks for your work on this.

Yeah, it's been on u-boot-sunxi/master

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

thanks!

I had already rebased it against u-boot-sunxi/master, so the attached diff should be fine. Should I send it as a separate [PATCH] mail?

To be clear, you were re-syncing those boards with only changes that will be going upstream to the Linux kernel at some point, right? Or are already there? And nothing U-Boot specific?

More the other way around. I replaced the u-boot ones with the files from linux, so there should be nothing u-boot specific anymore if there was at all. Is that approach incorrect?

#14 lore raw

PATCH 1/1 arm: sunxi: initial support for NanoPi Neo2

Quoted 21 lines · Patrick Wildt
Quoted 20 lines · Tom Rini
Quoted 18 lines · Patrick Wildt
Quoted 7 lines · Jagan Teki
Quoted 6 lines · Andreas Färber

Am 01.06.2017 um 16:04 schrieb Patrick Wildt:

Quoted 4 lines

What's holding us up from using the Linux device trees without any changes? This diff I attach inline copies all a64, h3 and h5 related files from v4.12-rc3 (so, mainline) and modifies the emac driver to use the new pinmux attributes.

Quoted 7 lines
Quoted 3 lines

Andre or someone had already sent a series sync'ing a64 and pine64. Can you keep h5/h3 separate or rebase onto that series please to not cause merge conflicts? Thanks for your work on this.

Yeah, it's been on u-boot-sunxi/master

thanks!

I had already rebased it against u-boot-sunxi/master, so the attached diff should be fine. Should I send it as a separate [PATCH] mail?

Quoted 7 lines
Quoted 3 lines

To be clear, you were re-syncing those boards with only changes that will be going upstream to the Linux kernel at some point, right? Or are already there? And nothing U-Boot specific?

More the other way around. I replaced the u-boot ones with the files from linux, so there should be nothing u-boot specific anymore if there was at all. Is that approach incorrect?

No, that's what I wanted to hear, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170601/c4b7a636/attachment.sig>