[PATCH 0/3] sunxi: add OrangePi Zero 3 board support

[PATCH 0/3] sunxi: add OrangePi Zero 3 board support

[Andre Przywara]

The OrangePi Zero 3 is a small development board featuring the Allwinner
H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses
LPDDR4 DRAM instead of DDR3 DRAM, and an X-Powers AXP313 PMIC instead of
the AXP305.
U-Boot gained support for both LPDDR4 DRAM and the new PMIC just
recently, so add a user for those features by adding a defconfig for the
new board.
To make this work, patch 1/3 introduces support for zBIT SPI NOR flash
chip, and patch 2/3 removes the default AXP305 PMIC selection when
compiling for H616 SoCs.
Patch 3/3 then adds the defconfig. The DT was already synced from the
Linux kernel repo a few weeks ago.

Cheers,
Andre

Andre Przywara (3):
  mtd: spi-nor: Add support for zBIT ZB25VQ128
  sunxi: H616: remove default AXP305 selection
  sunxi: H616: Add OrangePi Zero 3 board support

 arch/arm/dts/Makefile            |  1 +
 board/sunxi/MAINTAINERS          |  5 +++++
 configs/orangepi_zero2_defconfig |  1 +
 configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
 configs/x96_mate_defconfig       |  1 +
 drivers/mtd/spi/Kconfig          |  5 +++++
 drivers/mtd/spi/spi-nor-ids.c    |  5 +++++
 drivers/power/Kconfig            |  1 -
 8 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 configs/orangepi_zero3_defconfig

-- 
2.35.8

[PATCH 1/3] mtd: spi-nor: Add support for zBIT ZB25VQ128

[Andre Przywara]

Add support for the zBIT ZB25VQ128 (128M-bit) SPI NOR flash memory chip,
as used on the Xunlong Orange Pi Zero 3 board.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/mtd/spi/Kconfig       | 5 +++++
 drivers/mtd/spi/spi-nor-ids.c | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 732b0760452..abed392c28d 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -224,6 +224,11 @@ config SPI_FLASH_XTX
 	  Add support for various XTX (XTX Technology Limited)
 	  SPI flash chips (XT25xxx).
 
+config SPI_FLASH_ZBIT
+	bool "ZBIT SPI flash support"
+	help
+	  Add support for Zbit Semiconductor Inc. SPI flash chips (ZB25xxx).
+
 endif
 
 config SPI_FLASH_USE_4K_SECTORS
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3cb132dcffc..f86e7ff8e58 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -571,6 +571,11 @@ const struct flash_info spi_nor_ids[] = {
 	       SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
 	{ INFO("xt25w01g", 0x0b651B, 0, 64 * 1024, 2048,
 	       SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+#endif
+#ifdef CONFIG_SPI_FLASH_ZBIT
+	/* Zbit Semiconductor Inc. */
+	{ INFO("zb25vq128", 0x5e4018, 0, 64 * 1024, 256,
+	       SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
 #endif
 	{ },
 };
-- 
2.35.8

[PATCH 2/3] sunxi: H616: remove default AXP305 selection

[Andre Przywara]

The original H616 devices released about three years ago were typically
paired with an X-Powers AXP305 PMIC. Newer devices uses the smaller
AXP313, and there seem to be far more systems with this PMIC around now.

Remove the default AXP305 selection for the H616 SoC from the Kconfig,
and move the PMIC selection into the board defconfig files instead.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 configs/orangepi_zero2_defconfig | 1 +
 configs/x96_mate_defconfig       | 1 +
 drivers/power/Kconfig            | 1 -
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/orangepi_zero2_defconfig b/configs/orangepi_zero2_defconfig
index f13735e91c7..127cf9e365a 100644
--- a/configs/orangepi_zero2_defconfig
+++ b/configs/orangepi_zero2_defconfig
@@ -19,6 +19,7 @@ CONFIG_SYS_I2C_SPEED=400000
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_PHY_REALTEK=y
 CONFIG_SUN8I_EMAC=y
+CONFIG_AXP305_POWER=y
 CONFIG_SPI=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig
index 318951e19c2..e805e0952b3 100644
--- a/configs/x96_mate_defconfig
+++ b/configs/x96_mate_defconfig
@@ -18,6 +18,7 @@ CONFIG_SPL_SYS_I2C_LEGACY=y
 CONFIG_SYS_I2C_MVTWSI=y
 CONFIG_SYS_I2C_SLAVE=0x7f
 CONFIG_SYS_I2C_SPEED=400000
+CONFIG_AXP305_POWER=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 2395720c99c..33b8bc1214d 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -56,7 +56,6 @@ choice
 	depends on ARCH_SUNXI
 	default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
 	default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_R40
-	default AXP305_POWER if MACH_SUN50I_H616
 	default AXP818_POWER if MACH_SUN8I_A83T
 	default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I || MACH_SUN8I_V3S
 
-- 
2.35.8

[PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Andre Przywara]

The OrangePi Zero 3 is a small development board featuring the Allwinner
H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
connector and two USB sockets.
The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
which was recently added to U-Boot.

Add a defconfig file selecting the right drivers and DRAM options.
Since the .dts file was synced from the Linux kernel repo already, we
just need to add one line to the Makefile to actually build the .dtb.

The DRAM parameters were derived from the values found in the BSP DRAM
drivers on the SPI NOR flash.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm/dts/Makefile            |  1 +
 board/sunxi/MAINTAINERS          |  5 +++++
 configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
 3 files changed, 36 insertions(+)
 create mode 100644 configs/orangepi_zero3_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1be08c5fdc2..5fc888680b3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
 	sun50i-h6-tanix-tx6-mini.dtb
 dtb-$(CONFIG_MACH_SUN50I_H616) += \
 	sun50i-h616-orangepi-zero2.dtb \
+	sun50i-h618-orangepi-zero3.dtb \
 	sun50i-h616-x96-mate.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
 	sun50i-a64-amarula-relic.dtb \
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 00614372119..f556857a391 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -455,6 +455,11 @@ M:	Jernej Skrabec <jernej.skrabec@siol.net>
 S:	Maintained
 F:	configs/orangepi_zero2_defconfig
 
+ORANGEPI ZERO 3 BOARD
+M:	Andre Przywara <andre.przywara@arm.com>
+S:	Maintained
+F:	configs/orangepi_zero3_defconfig
+
 ORANGEPI PC 2 BOARD
 M:	Andre Przywara <andre.przywara@arm.com>
 S:	Maintained
diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig
new file mode 100644
index 00000000000..e59044f6639
--- /dev/null
+++ b/configs/orangepi_zero3_defconfig
@@ -0,0 +1,30 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
+CONFIG_SPL=y
+CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
+CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
+CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
+CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
+CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
+CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
+CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
+CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
+CONFIG_MACH_SUN50I_H616=y
+CONFIG_SUNXI_DRAM_H616_LPDDR4=y
+CONFIG_R_I2C_ENABLE=y
+CONFIG_SPL_SPI_SUNXI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_I2C=y
+CONFIG_SPL_SYS_I2C_LEGACY=y
+CONFIG_SYS_I2C_MVTWSI=y
+CONFIG_SYS_I2C_SLAVE=0x7f
+CONFIG_SYS_I2C_SPEED=400000
+CONFIG_SPI_FLASH_ZBIT=y
+CONFIG_PHY_MOTORCOMM=y
+CONFIG_SUN8I_EMAC=y
+CONFIG_AXP313_POWER=y
+CONFIG_SPI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_MUSB_GADGET=y
-- 
2.35.8

Re: [PATCH 2/3] sunxi: H616: remove default AXP305 selection

[Jaehoon Chung]

On 11/14/23 10:31, Andre Przywara wrote:
> The original H616 devices released about three years ago were typically
> paired with an X-Powers AXP305 PMIC. Newer devices uses the smaller
> AXP313, and there seem to be far more systems with this PMIC around now.
> 
> Remove the default AXP305 selection for the H616 SoC from the Kconfig,
> and move the PMIC selection into the board defconfig files instead.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

Best Regards,
Jaehoon Chung

> ---
>  configs/orangepi_zero2_defconfig | 1 +
>  configs/x96_mate_defconfig       | 1 +
>  drivers/power/Kconfig            | 1 -
>  3 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/configs/orangepi_zero2_defconfig b/configs/orangepi_zero2_defconfig
> index f13735e91c7..127cf9e365a 100644
> --- a/configs/orangepi_zero2_defconfig
> +++ b/configs/orangepi_zero2_defconfig
> @@ -19,6 +19,7 @@ CONFIG_SYS_I2C_SPEED=400000
>  CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_PHY_REALTEK=y
>  CONFIG_SUN8I_EMAC=y
> +CONFIG_AXP305_POWER=y
>  CONFIG_SPI=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_OHCI_HCD=y
> diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig
> index 318951e19c2..e805e0952b3 100644
> --- a/configs/x96_mate_defconfig
> +++ b/configs/x96_mate_defconfig
> @@ -18,6 +18,7 @@ CONFIG_SPL_SYS_I2C_LEGACY=y
>  CONFIG_SYS_I2C_MVTWSI=y
>  CONFIG_SYS_I2C_SLAVE=0x7f
>  CONFIG_SYS_I2C_SPEED=400000
> +CONFIG_AXP305_POWER=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_OHCI_HCD=y
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 2395720c99c..33b8bc1214d 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -56,7 +56,6 @@ choice
>  	depends on ARCH_SUNXI
>  	default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
>  	default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_R40
> -	default AXP305_POWER if MACH_SUN50I_H616
>  	default AXP818_POWER if MACH_SUN8I_A83T
>  	default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I || MACH_SUN8I_V3S
>  

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Mikhail Kalashnikov]

Hi Andre!
Thanks for your patches. I started checking and noticed that USB storage
was not working:

=> usb reset
resetting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... 1 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
=> usb storage
No storage devices, perhaps not 'usb start'ed..?

Otherwise my OpiZero3 (4GB) board looks working.
Ethernet works with my 10 Mbps usb-dongle.

sf probe detect spi nor flash:
=> sf probe
SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total 
16 MiB

Loading the kernel and running the operating system (from microsd) also
without problems.

Tested-by: Mikhail Kalashnikov <iuncuim@gmail.com>


On 14.11.2023 04:31, Andre Przywara wrote:
> The OrangePi Zero 3 is a small development board featuring the Allwinner
> H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
> connector and two USB sockets.
> The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
> which was recently added to U-Boot.
>
> Add a defconfig file selecting the right drivers and DRAM options.
> Since the .dts file was synced from the Linux kernel repo already, we
> just need to add one line to the Makefile to actually build the .dtb.
>
> The DRAM parameters were derived from the values found in the BSP DRAM
> drivers on the SPI NOR flash.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>   arch/arm/dts/Makefile            |  1 +
>   board/sunxi/MAINTAINERS          |  5 +++++
>   configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
>   3 files changed, 36 insertions(+)
>   create mode 100644 configs/orangepi_zero3_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 1be08c5fdc2..5fc888680b3 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
>   	sun50i-h6-tanix-tx6-mini.dtb
>   dtb-$(CONFIG_MACH_SUN50I_H616) += \
>   	sun50i-h616-orangepi-zero2.dtb \
> +	sun50i-h618-orangepi-zero3.dtb \
>   	sun50i-h616-x96-mate.dtb
>   dtb-$(CONFIG_MACH_SUN50I) += \
>   	sun50i-a64-amarula-relic.dtb \
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index 00614372119..f556857a391 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -455,6 +455,11 @@ M:	Jernej Skrabec <jernej.skrabec@siol.net>
>   S:	Maintained
>   F:	configs/orangepi_zero2_defconfig
>   
> +ORANGEPI ZERO 3 BOARD
> +M:	Andre Przywara <andre.przywara@arm.com>
> +S:	Maintained
> +F:	configs/orangepi_zero3_defconfig
> +
>   ORANGEPI PC 2 BOARD
>   M:	Andre Przywara <andre.przywara@arm.com>
>   S:	Maintained
> diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig
> new file mode 100644
> index 00000000000..e59044f6639
> --- /dev/null
> +++ b/configs/orangepi_zero3_defconfig
> @@ -0,0 +1,30 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
> +CONFIG_SPL=y
> +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
> +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
> +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
> +CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
> +CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
> +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
> +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
> +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
> +CONFIG_MACH_SUN50I_H616=y
> +CONFIG_SUNXI_DRAM_H616_LPDDR4=y
> +CONFIG_R_I2C_ENABLE=y
> +CONFIG_SPL_SPI_SUNXI=y
> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_SPL_I2C=y
> +CONFIG_SPL_SYS_I2C_LEGACY=y
> +CONFIG_SYS_I2C_MVTWSI=y
> +CONFIG_SYS_I2C_SLAVE=0x7f
> +CONFIG_SYS_I2C_SPEED=400000
> +CONFIG_SPI_FLASH_ZBIT=y
> +CONFIG_PHY_MOTORCOMM=y
> +CONFIG_SUN8I_EMAC=y
> +CONFIG_AXP313_POWER=y
> +CONFIG_SPI=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_MUSB_GADGET=y

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Andre Przywara]

On Sat, 25 Nov 2023 20:43:12 +0300
Mikhail Kalashnikov <iuncuim@gmail.com> wrote:

Hi Mikhail,

> Hi Andre!
> Thanks for your patches. I started checking and noticed that USB storage
> was not working:
> 
> => usb reset  
> resetting USB...
> Bus usb@5200000: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@5200000 for devices... 1 USB Device(s) found
> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>        scanning usb for storage devices... 0 Storage Device(s) found
> => usb storage  
> No storage devices, perhaps not 'usb start'ed..?

Ah, thanks for the report, seems I didn't even test this!
So digging around I figured it's working in Linux, and it's the right
USB port, but we are missing the VBUS power switch, which is a GPIO
controlled regulator. There are pending patches to pick this from the
devicetree[1], but we are not there yet, so we need:
CONFIG_USB1_VBUS_PIN="PC16"
in the defconfig, for now. I will update the file. The same is
actually missing from the OrangePi Zero2 defconfig, I will send a patch
ASAP.
 
> Otherwise my OpiZero3 (4GB) board looks working.
> Ethernet works with my 10 Mbps usb-dongle.
> 
> sf probe detect spi nor flash:
> => sf probe  
> SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total 
> 16 MiB
> 
> Loading the kernel and running the operating system (from microsd) also
> without problems.
> 
> Tested-by: Mikhail Kalashnikov <iuncuim@gmail.com>

Great, thanks for the tag!

Cheers,
Andre

> On 14.11.2023 04:31, Andre Przywara wrote:
> > The OrangePi Zero 3 is a small development board featuring the Allwinner
> > H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
> > connector and two USB sockets.
> > The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
> > which was recently added to U-Boot.
> >
> > Add a defconfig file selecting the right drivers and DRAM options.
> > Since the .dts file was synced from the Linux kernel repo already, we
> > just need to add one line to the Makefile to actually build the .dtb.
> >
> > The DRAM parameters were derived from the values found in the BSP DRAM
> > drivers on the SPI NOR flash.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >   arch/arm/dts/Makefile            |  1 +
> >   board/sunxi/MAINTAINERS          |  5 +++++
> >   configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
> >   3 files changed, 36 insertions(+)
> >   create mode 100644 configs/orangepi_zero3_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 1be08c5fdc2..5fc888680b3 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
> >   	sun50i-h6-tanix-tx6-mini.dtb
> >   dtb-$(CONFIG_MACH_SUN50I_H616) += \
> >   	sun50i-h616-orangepi-zero2.dtb \
> > +	sun50i-h618-orangepi-zero3.dtb \
> >   	sun50i-h616-x96-mate.dtb
> >   dtb-$(CONFIG_MACH_SUN50I) += \
> >   	sun50i-a64-amarula-relic.dtb \
> > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > index 00614372119..f556857a391 100644
> > --- a/board/sunxi/MAINTAINERS
> > +++ b/board/sunxi/MAINTAINERS
> > @@ -455,6 +455,11 @@ M:	Jernej Skrabec <jernej.skrabec@siol.net>
> >   S:	Maintained
> >   F:	configs/orangepi_zero2_defconfig
> >   
> > +ORANGEPI ZERO 3 BOARD
> > +M:	Andre Przywara <andre.przywara@arm.com>
> > +S:	Maintained
> > +F:	configs/orangepi_zero3_defconfig
> > +
> >   ORANGEPI PC 2 BOARD
> >   M:	Andre Przywara <andre.przywara@arm.com>
> >   S:	Maintained
> > diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig
> > new file mode 100644
> > index 00000000000..e59044f6639
> > --- /dev/null
> > +++ b/configs/orangepi_zero3_defconfig
> > @@ -0,0 +1,30 @@
> > +CONFIG_ARM=y
> > +CONFIG_ARCH_SUNXI=y
> > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
> > +CONFIG_SPL=y
> > +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
> > +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
> > +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
> > +CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
> > +CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
> > +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
> > +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
> > +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
> > +CONFIG_MACH_SUN50I_H616=y
> > +CONFIG_SUNXI_DRAM_H616_LPDDR4=y
> > +CONFIG_R_I2C_ENABLE=y
> > +CONFIG_SPL_SPI_SUNXI=y
> > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > +CONFIG_SPL_I2C=y
> > +CONFIG_SPL_SYS_I2C_LEGACY=y
> > +CONFIG_SYS_I2C_MVTWSI=y
> > +CONFIG_SYS_I2C_SLAVE=0x7f
> > +CONFIG_SYS_I2C_SPEED=400000
> > +CONFIG_SPI_FLASH_ZBIT=y
> > +CONFIG_PHY_MOTORCOMM=y
> > +CONFIG_SUN8I_EMAC=y
> > +CONFIG_AXP313_POWER=y
> > +CONFIG_SPI=y
> > +CONFIG_USB_EHCI_HCD=y
> > +CONFIG_USB_OHCI_HCD=y
> > +CONFIG_USB_MUSB_GADGET=y  
> 

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Stephen Graf]

I built u-boot with the additional parameter for usb and it works, I think.  There was one message that might be of concern "
Card did not respond to voltage select! : -110". I am not sure of the details of the boot.cmd. The output below came from
the supplier image on an SD plugged into a USB card reader. The SD slot of the board was empty.

I was able to install u-boot to the SPI flash memory and there is a warning message from that also: "
Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18
*** Warning - spi_flash_probe_bus_cs() failed, using default environment"

Thank you for your advice on getting something to boot. None of the Debian installer images were suitable.  Even SID was at 6.1.
I built the latest Linux 6.6.2 and wrestled with the rootfs before I got it running. I built the tested u-boot with this system,
as a test of system stability.

defconfig used + emac patches

CONFIG_ARM=y
CONFIG_ARCH_SUNXI=y
CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
CONFIG_SPL=y
CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
CONFIG_MACH_SUN50I_H616=y
CONFIG_SUNXI_DRAM_H616_LPDDR4=y
#
CONFIG_DRAM_CLK=792
CONFIG_USB1_VBUS_PIN="PC16"
#
CONFIG_R_I2C_ENABLE=y
CONFIG_SPL_SPI_SUNXI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_I2C=y
CONFIG_SPL_SYS_I2C_LEGACY=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_SYS_I2C_SLAVE=0x7f
CONFIG_SYS_I2C_SPEED=400000
CONFIG_SPI_FLASH_ZBIT=y
CONFIG_PHY_MOTORCOMM=y
CONFIG_SUN8I_EMAC=y
CONFIG_AXP313_POWER=y
CONFIG_SPI=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_MUSB_GADGET=y


Console Output:

U-Boot 2024.01-rc3-00009-g9e53e45292-dirty (Nov 25 2023 - 18:32:16 -0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB
Core:  57 devices, 25 uclasses, devicetree: separate
WDT:   Not starting watchdog@30090a0
MMC:   mmc@4020000: 0
Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

Loading Environment from FAT... Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Allwinner mUSB OTG (Peripheral)
Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
RNDIS ready
, eth1: usb_ether
starting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
2 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
        scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
Card did not respond to voltage select! : -110

Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
             Type: Removable Hard Disk
             Capacity: 15193.5 MB = 14.8 GB (31116288 x 512)
... is now current device
Scanning usb 0:1...
Found U-Boot script /boot/boot.scr
3636 bytes read in 1 ms (3.5 MiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from usb
205 bytes read in 1 ms (200.2 KiB/s)
Failed to load '/boot/dtb/allwinner/sun50i-h618-orangepi-zero3.dtb'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
4203 bytes read in 4 ms (1 MiB/s)
Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
## Executing script at 45000000
7088139 bytes read in 325 ms (20.8 MiB/s)
9419107 bytes read in 430 ms (20.9 MiB/s)
    Uncompressing Kernel Image
Moving Image from 0x40080000 to 0x40200000, end=41800000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
    Image Name:   uInitrd
    Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
    Data Size:    7088075 Bytes = 6.8 MiB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
ERROR: Did not find a cmdline Flattened Device Tree

On 2023-11-25 4:23 p.m., Andre Przywara wrote:
> On Sat, 25 Nov 2023 20:43:12 +0300
> Mikhail Kalashnikov<iuncuim@gmail.com>  wrote:
>
> Hi Mikhail,
>
>> Hi Andre!
>> Thanks for your patches. I started checking and noticed that USB storage
>> was not working:
>>
>> => usb reset
>> resetting USB...
>> Bus usb@5200000: USB EHCI 1.00
>> Bus usb@5200400: USB OHCI 1.0
>> scanning bus usb@5200000 for devices... 1 USB Device(s) found
>> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>>         scanning usb for storage devices... 0 Storage Device(s) found
>> => usb storage
>> No storage devices, perhaps not 'usb start'ed..?
> Ah, thanks for the report, seems I didn't even test this!
> So digging around I figured it's working in Linux, and it's the right
> USB port, but we are missing the VBUS power switch, which is a GPIO
> controlled regulator. There are pending patches to pick this from the
> devicetree[1], but we are not there yet, so we need:
> CONFIG_USB1_VBUS_PIN="PC16"
> in the defconfig, for now. I will update the file. The same is
> actually missing from the OrangePi Zero2 defconfig, I will send a patch
> ASAP.
>   
>> Otherwise my OpiZero3 (4GB) board looks working.
>> Ethernet works with my 10 Mbps usb-dongle.
>>
>> sf probe detect spi nor flash:
>> => sf probe
>> SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total
>> 16 MiB
>>
>> Loading the kernel and running the operating system (from microsd) also
>> without problems.
>>
>> Tested-by: Mikhail Kalashnikov<iuncuim@gmail.com>
> Great, thanks for the tag!
>
> Cheers,
> Andre
>
>> On 14.11.2023 04:31, Andre Przywara wrote:
>>> The OrangePi Zero 3 is a small development board featuring the Allwinner
>>> H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
>>> connector and two USB sockets.
>>> The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
>>> which was recently added to U-Boot.
>>>
>>> Add a defconfig file selecting the right drivers and DRAM options.
>>> Since the .dts file was synced from the Linux kernel repo already, we
>>> just need to add one line to the Makefile to actually build the .dtb.
>>>
>>> The DRAM parameters were derived from the values found in the BSP DRAM
>>> drivers on the SPI NOR flash.
>>>
>>> Signed-off-by: Andre Przywara<andre.przywara@arm.com>
>>> ---
>>>    arch/arm/dts/Makefile            |  1 +
>>>    board/sunxi/MAINTAINERS          |  5 +++++
>>>    configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
>>>    3 files changed, 36 insertions(+)
>>>    create mode 100644 configs/orangepi_zero3_defconfig
>>>
>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>> index 1be08c5fdc2..5fc888680b3 100644
>>> --- a/arch/arm/dts/Makefile
>>> +++ b/arch/arm/dts/Makefile
>>> @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
>>>    	sun50i-h6-tanix-tx6-mini.dtb
>>>    dtb-$(CONFIG_MACH_SUN50I_H616) += \
>>>    	sun50i-h616-orangepi-zero2.dtb \
>>> +	sun50i-h618-orangepi-zero3.dtb \
>>>    	sun50i-h616-x96-mate.dtb
>>>    dtb-$(CONFIG_MACH_SUN50I) += \
>>>    	sun50i-a64-amarula-relic.dtb \
>>> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
>>> index 00614372119..f556857a391 100644
>>> --- a/board/sunxi/MAINTAINERS
>>> +++ b/board/sunxi/MAINTAINERS
>>> @@ -455,6 +455,11 @@ M:	Jernej Skrabec<jernej.skrabec@siol.net>
>>>    S:	Maintained
>>>    F:	configs/orangepi_zero2_defconfig
>>>    
>>> +ORANGEPI ZERO 3 BOARD
>>> +M:	Andre Przywara<andre.przywara@arm.com>
>>> +S:	Maintained
>>> +F:	configs/orangepi_zero3_defconfig
>>> +
>>>    ORANGEPI PC 2 BOARD
>>>    M:	Andre Przywara<andre.przywara@arm.com>
>>>    S:	Maintained
>>> diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig
>>> new file mode 100644
>>> index 00000000000..e59044f6639
>>> --- /dev/null
>>> +++ b/configs/orangepi_zero3_defconfig
>>> @@ -0,0 +1,30 @@
>>> +CONFIG_ARM=y
>>> +CONFIG_ARCH_SUNXI=y
>>> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
>>> +CONFIG_SPL=y
>>> +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
>>> +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
>>> +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
>>> +CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
>>> +CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
>>> +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
>>> +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
>>> +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
>>> +CONFIG_MACH_SUN50I_H616=y
>>> +CONFIG_SUNXI_DRAM_H616_LPDDR4=y
>>> +CONFIG_R_I2C_ENABLE=y
>>> +CONFIG_SPL_SPI_SUNXI=y
>>> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>>> +CONFIG_SPL_I2C=y
>>> +CONFIG_SPL_SYS_I2C_LEGACY=y
>>> +CONFIG_SYS_I2C_MVTWSI=y
>>> +CONFIG_SYS_I2C_SLAVE=0x7f
>>> +CONFIG_SYS_I2C_SPEED=400000
>>> +CONFIG_SPI_FLASH_ZBIT=y
>>> +CONFIG_PHY_MOTORCOMM=y
>>> +CONFIG_SUN8I_EMAC=y
>>> +CONFIG_AXP313_POWER=y
>>> +CONFIG_SPI=y
>>> +CONFIG_USB_EHCI_HCD=y
>>> +CONFIG_USB_OHCI_HCD=y
>>> +CONFIG_USB_MUSB_GADGET=y

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Bob McChesney]

On Sat, Nov 25, 2023 at 08:43:12PM +0300, Mikhail Kalashnikov wrote:
> Tested-by: Mikhail Kalashnikov <iuncuim@gmail.com>
> 
> On 14.11.2023 04:31, Andre Przywara wrote:
> > The OrangePi Zero 3 is a small development board featuring the Allwinner
> > H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
> > connector and two USB sockets.
> > The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
> > which was recently added to U-Boot.
> > 
> > Add a defconfig file selecting the right drivers and DRAM options.
> > Since the .dts file was synced from the Linux kernel repo already, we
> > just need to add one line to the Makefile to actually build the .dtb.
> > 
> > The DRAM parameters were derived from the values found in the BSP DRAM
> > drivers on the SPI NOR flash.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >   arch/arm/dts/Makefile            |  1 +
> >   board/sunxi/MAINTAINERS          |  5 +++++
> >   configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
> >   3 files changed, 36 insertions(+)
> >   create mode 100644 configs/orangepi_zero3_defconfig

Tested-by: Bob McChesney <bob@electricworry.net>

Am I ok to just tag onto Mikhail's email to add my tested tag? I've got
a 4GB Orange Pi Zero 3 and can confirm that it works, despite any
limitations that may be present.

Regards,
Bob

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Andre Przywara]

On Sat, 25 Nov 2023 20:27:05 -0800
Stephen Graf <stephen.graf@gmail.com> wrote:

Hi Stephen,

> I built u-boot with the additional parameter for usb and it works, I think.  There was one message that might be of concern "
> Card did not respond to voltage select! : -110".

This is a normal, though admittedly confusing message if no SD card is
inserted. The code tries to (unconditionally) access the SD card, and
sees that no card is there, the missing respond to the voltage select
command is just the first real proof of this.

> I am not sure of the details of the boot.cmd. The output below came from
> the supplier image on an SD plugged into a USB card reader. The SD slot of the board was empty.
> 
> I was able to install u-boot to the SPI flash memory and there is a warning message from that also: "
> Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment"

So for a start there is no environment on the SPI flash yet, so it
wouldn't do anything. But the "unrecognised JEDEC id bytes" message
doesn't sound right. Can you dig into this? Do you have patch 1/3
applied, which tells U-Boot about 0x5e meaning zBIT?

> Thank you for your advice on getting something to boot. None of the Debian installer images were suitable.  Even SID was at 6.1.
> I built the latest Linux 6.6.2 and wrestled with the rootfs before I got it running. I built the tested u-boot with this system,
> as a test of system stability.
> 
> defconfig used + emac patches
> 
> CONFIG_ARM=y
> CONFIG_ARCH_SUNXI=y
> CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
> CONFIG_SPL=y
> CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
> CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
> CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
> CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
> CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
> CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
> CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
> CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
> CONFIG_MACH_SUN50I_H616=y
> CONFIG_SUNXI_DRAM_H616_LPDDR4=y
> #
> CONFIG_DRAM_CLK=792
> CONFIG_USB1_VBUS_PIN="PC16"
> #
> CONFIG_R_I2C_ENABLE=y
> CONFIG_SPL_SPI_SUNXI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> CONFIG_SPL_I2C=y
> CONFIG_SPL_SYS_I2C_LEGACY=y
> CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_SYS_I2C_SLAVE=0x7f
> CONFIG_SYS_I2C_SPEED=400000
> CONFIG_SPI_FLASH_ZBIT=y
> CONFIG_PHY_MOTORCOMM=y
> CONFIG_SUN8I_EMAC=y
> CONFIG_AXP313_POWER=y
> CONFIG_SPI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_MUSB_GADGET=y
> 
> 
> Console Output:
> 
> U-Boot 2024.01-rc3-00009-g9e53e45292-dirty (Nov 25 2023 - 18:32:16 -0800) Allwinner Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  1 GiB
> Core:  57 devices, 25 uclasses, devicetree: separate
> WDT:   Not starting watchdog@30090a0
> MMC:   mmc@4020000: 0
> Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
> 
> Loading Environment from FAT... Card did not respond to voltage select! : -110
> ** Bad device specification mmc 0 **
> In:    serial@5000000
> Out:   serial@5000000
> Err:   serial@5000000
> Allwinner mUSB OTG (Peripheral)
> Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
> MAC de:ad:be:ef:00:01
> HOST MAC de:ad:be:ef:00:00
> RNDIS ready
> , eth1: usb_ether
> starting USB...
> Bus usb@5200000: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@5200000 for devices... Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> 2 USB Device(s) found
> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> Card did not respond to voltage select! : -110
> 
> Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
>              Type: Removable Hard Disk
>              Capacity: 15193.5 MB = 14.8 GB (31116288 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found U-Boot script /boot/boot.scr
> 3636 bytes read in 1 ms (3.5 MiB/s)
> ## Executing script at 4fc00000
> U-boot loaded from SD
> Boot script loaded from usb
> 205 bytes read in 1 ms (200.2 KiB/s)
> Failed to load '/boot/dtb/allwinner/sun50i-h618-orangepi-zero3.dtb'
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> No FDT memory address configured. Please configure
> the FDT address via "fdt addr <address>" command.
> Aborting!
> 4203 bytes read in 4 ms (1 MiB/s)
> Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
> ## Executing script at 45000000
> 7088139 bytes read in 325 ms (20.8 MiB/s)
> 9419107 bytes read in 430 ms (20.9 MiB/s)
>     Uncompressing Kernel Image
> Moving Image from 0x40080000 to 0x40200000, end=41800000
> ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
>     Image Name:   uInitrd
>     Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>     Data Size:    7088075 Bytes = 6.8 MiB
>     Load Address: 00000000
>     Entry Point:  00000000
>     Verifying Checksum ... OK
> ERROR: Did not find a cmdline Flattened Device Tree

OK, so this is because you don't have the OPi Zero3 DTB on your image.
And this is frankly not needed, because U-Boot carries this very DTB
already.
In general this is some old school boot sequence, with a uImage
wrapped initrd and the DTB loaded from disk. The wrapped initrd is
mostly an small annoyance from a developers point of view, so this is
fine.
But can you tweak the boot script to use "$fdtcontroladdr", instead of
trying load a DTB from "disk"?
So remove (or ignore) the "load .... $fdt_addr_r ..." line, and change
the booti command to use "$fdtcontroladdr" instead of "$fdt_addr_r".
That should be all you need.

Good luck!

Cheers,
Andre
 
> On 2023-11-25 4:23 p.m., Andre Przywara wrote:
> > On Sat, 25 Nov 2023 20:43:12 +0300
> > Mikhail Kalashnikov<iuncuim@gmail.com>  wrote:
> >
> > Hi Mikhail,
> >  
> >> Hi Andre!
> >> Thanks for your patches. I started checking and noticed that USB storage
> >> was not working:
> >>  
> >> => usb reset  
> >> resetting USB...
> >> Bus usb@5200000: USB EHCI 1.00
> >> Bus usb@5200400: USB OHCI 1.0
> >> scanning bus usb@5200000 for devices... 1 USB Device(s) found
> >> scanning bus usb@5200400 for devices... 1 USB Device(s) found
> >>         scanning usb for storage devices... 0 Storage Device(s) found  
> >> => usb storage  
> >> No storage devices, perhaps not 'usb start'ed..?  
> > Ah, thanks for the report, seems I didn't even test this!
> > So digging around I figured it's working in Linux, and it's the right
> > USB port, but we are missing the VBUS power switch, which is a GPIO
> > controlled regulator. There are pending patches to pick this from the
> > devicetree[1], but we are not there yet, so we need:
> > CONFIG_USB1_VBUS_PIN="PC16"
> > in the defconfig, for now. I will update the file. The same is
> > actually missing from the OrangePi Zero2 defconfig, I will send a patch
> > ASAP.
> >     
> >> Otherwise my OpiZero3 (4GB) board looks working.
> >> Ethernet works with my 10 Mbps usb-dongle.
> >>
> >> sf probe detect spi nor flash:  
> >> => sf probe  
> >> SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total
> >> 16 MiB
> >>
> >> Loading the kernel and running the operating system (from microsd) also
> >> without problems.
> >>
> >> Tested-by: Mikhail Kalashnikov<iuncuim@gmail.com>  
> > Great, thanks for the tag!
> >
> > Cheers,
> > Andre
> >  
> >> On 14.11.2023 04:31, Andre Przywara wrote:  
> >>> The OrangePi Zero 3 is a small development board featuring the Allwinner
> >>> H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
> >>> connector and two USB sockets.
> >>> The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
> >>> which was recently added to U-Boot.
> >>>
> >>> Add a defconfig file selecting the right drivers and DRAM options.
> >>> Since the .dts file was synced from the Linux kernel repo already, we
> >>> just need to add one line to the Makefile to actually build the .dtb.
> >>>
> >>> The DRAM parameters were derived from the values found in the BSP DRAM
> >>> drivers on the SPI NOR flash.
> >>>
> >>> Signed-off-by: Andre Przywara<andre.przywara@arm.com>
> >>> ---
> >>>    arch/arm/dts/Makefile            |  1 +
> >>>    board/sunxi/MAINTAINERS          |  5 +++++
> >>>    configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
> >>>    3 files changed, 36 insertions(+)
> >>>    create mode 100644 configs/orangepi_zero3_defconfig
> >>>
> >>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> >>> index 1be08c5fdc2..5fc888680b3 100644
> >>> --- a/arch/arm/dts/Makefile
> >>> +++ b/arch/arm/dts/Makefile
> >>> @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
> >>>    	sun50i-h6-tanix-tx6-mini.dtb
> >>>    dtb-$(CONFIG_MACH_SUN50I_H616) += \
> >>>    	sun50i-h616-orangepi-zero2.dtb \
> >>> +	sun50i-h618-orangepi-zero3.dtb \
> >>>    	sun50i-h616-x96-mate.dtb
> >>>    dtb-$(CONFIG_MACH_SUN50I) += \
> >>>    	sun50i-a64-amarula-relic.dtb \
> >>> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> >>> index 00614372119..f556857a391 100644
> >>> --- a/board/sunxi/MAINTAINERS
> >>> +++ b/board/sunxi/MAINTAINERS
> >>> @@ -455,6 +455,11 @@ M:	Jernej Skrabec<jernej.skrabec@siol.net>
> >>>    S:	Maintained
> >>>    F:	configs/orangepi_zero2_defconfig
> >>>    
> >>> +ORANGEPI ZERO 3 BOARD
> >>> +M:	Andre Przywara<andre.przywara@arm.com>
> >>> +S:	Maintained
> >>> +F:	configs/orangepi_zero3_defconfig
> >>> +
> >>>    ORANGEPI PC 2 BOARD
> >>>    M:	Andre Przywara<andre.przywara@arm.com>
> >>>    S:	Maintained
> >>> diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig
> >>> new file mode 100644
> >>> index 00000000000..e59044f6639
> >>> --- /dev/null
> >>> +++ b/configs/orangepi_zero3_defconfig
> >>> @@ -0,0 +1,30 @@
> >>> +CONFIG_ARM=y
> >>> +CONFIG_ARCH_SUNXI=y
> >>> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
> >>> +CONFIG_SPL=y
> >>> +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
> >>> +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
> >>> +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
> >>> +CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
> >>> +CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
> >>> +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
> >>> +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
> >>> +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
> >>> +CONFIG_MACH_SUN50I_H616=y
> >>> +CONFIG_SUNXI_DRAM_H616_LPDDR4=y
> >>> +CONFIG_R_I2C_ENABLE=y
> >>> +CONFIG_SPL_SPI_SUNXI=y
> >>> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> >>> +CONFIG_SPL_I2C=y
> >>> +CONFIG_SPL_SYS_I2C_LEGACY=y
> >>> +CONFIG_SYS_I2C_MVTWSI=y
> >>> +CONFIG_SYS_I2C_SLAVE=0x7f
> >>> +CONFIG_SYS_I2C_SPEED=400000
> >>> +CONFIG_SPI_FLASH_ZBIT=y
> >>> +CONFIG_PHY_MOTORCOMM=y
> >>> +CONFIG_SUN8I_EMAC=y
> >>> +CONFIG_AXP313_POWER=y
> >>> +CONFIG_SPI=y
> >>> +CONFIG_USB_EHCI_HCD=y
> >>> +CONFIG_USB_OHCI_HCD=y
> >>> +CONFIG_USB_MUSB_GADGET=y  

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Mikhail Kalashnikov]

On 26.11.2023 03:23, Andre Przywara wrote:
Hi Andre,
> On Sat, 25 Nov 2023 20:43:12 +0300
> Mikhail Kalashnikov <iuncuim@gmail.com> wrote:
>
> Hi Mikhail,
>
>> Hi Andre!
>> Thanks for your patches. I started checking and noticed that USB storage
>> was not working:
>>
>> => usb reset
>> resetting USB...
>> Bus usb@5200000: USB EHCI 1.00
>> Bus usb@5200400: USB OHCI 1.0
>> scanning bus usb@5200000 for devices... 1 USB Device(s) found
>> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>>         scanning usb for storage devices... 0 Storage Device(s) found
>> => usb storage
>> No storage devices, perhaps not 'usb start'ed..?
> Ah, thanks for the report, seems I didn't even test this!
> So digging around I figured it's working in Linux, and it's the right
> USB port, but we are missing the VBUS power switch, which is a GPIO
> controlled regulator. There are pending patches to pick this from the
> devicetree[1], but we are not there yet, so we need:
> CONFIG_USB1_VBUS_PIN="PC16"

With that usb storage work. Also I successfully loaded u-boot image to spi

with command:

sunxi-fel -p spiflash-write 0 u-boot-sunxi-with-spl.bin
100% [================================================]   828 kB,   74.7 
kB/s

After that u-boot successful started from spi.

Best regards,

Mikhail

> in the defconfig, for now. I will update the file. The same is
> actually missing from the OrangePi Zero2 defconfig, I will send a patch
> ASAP.
>   
>> Otherwise my OpiZero3 (4GB) board looks working.
>> Ethernet works with my 10 Mbps usb-dongle.
>>
>> sf probe detect spi nor flash:
>> => sf probe
>> SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total
>> 16 MiB
>>
>> Loading the kernel and running the operating system (from microsd) also
>> without problems.
>>
>> Tested-by: Mikhail Kalashnikov <iuncuim@gmail.com>
> Great, thanks for the tag!
>
> Cheers,
> Andre
>
>> On 14.11.2023 04:31, Andre Przywara wrote:
>>> The OrangePi Zero 3 is a small development board featuring the Allwinner
>>> H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
>>> connector and two USB sockets.
>>> The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
>>> which was recently added to U-Boot.
>>>
>>> Add a defconfig file selecting the right drivers and DRAM options.
>>> Since the .dts file was synced from the Linux kernel repo already, we
>>> just need to add one line to the Makefile to actually build the .dtb.
>>>
>>> The DRAM parameters were derived from the values found in the BSP DRAM
>>> drivers on the SPI NOR flash.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>    arch/arm/dts/Makefile            |  1 +
>>>    board/sunxi/MAINTAINERS          |  5 +++++
>>>    configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
>>>    3 files changed, 36 insertions(+)
>>>    create mode 100644 configs/orangepi_zero3_defconfig
>>>
>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>> index 1be08c5fdc2..5fc888680b3 100644
>>> --- a/arch/arm/dts/Makefile
>>> +++ b/arch/arm/dts/Makefile
>>> @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
>>>    	sun50i-h6-tanix-tx6-mini.dtb
>>>    dtb-$(CONFIG_MACH_SUN50I_H616) += \
>>>    	sun50i-h616-orangepi-zero2.dtb \
>>> +	sun50i-h618-orangepi-zero3.dtb \
>>>    	sun50i-h616-x96-mate.dtb
>>>    dtb-$(CONFIG_MACH_SUN50I) += \
>>>    	sun50i-a64-amarula-relic.dtb \
>>> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
>>> index 00614372119..f556857a391 100644
>>> --- a/board/sunxi/MAINTAINERS
>>> +++ b/board/sunxi/MAINTAINERS
>>> @@ -455,6 +455,11 @@ M:	Jernej Skrabec <jernej.skrabec@siol.net>
>>>    S:	Maintained
>>>    F:	configs/orangepi_zero2_defconfig
>>>    
>>> +ORANGEPI ZERO 3 BOARD
>>> +M:	Andre Przywara <andre.przywara@arm.com>
>>> +S:	Maintained
>>> +F:	configs/orangepi_zero3_defconfig
>>> +
>>>    ORANGEPI PC 2 BOARD
>>>    M:	Andre Przywara <andre.przywara@arm.com>
>>>    S:	Maintained
>>> diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig
>>> new file mode 100644
>>> index 00000000000..e59044f6639
>>> --- /dev/null
>>> +++ b/configs/orangepi_zero3_defconfig
>>> @@ -0,0 +1,30 @@
>>> +CONFIG_ARM=y
>>> +CONFIG_ARCH_SUNXI=y
>>> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3"
>>> +CONFIG_SPL=y
>>> +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707
>>> +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
>>> +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
>>> +CONFIG_DRAM_SUN50I_H616_ODT_EN=0xaaaaeeee
>>> +CONFIG_DRAM_SUN50I_H616_TPR6=0x44000000
>>> +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
>>> +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
>>> +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
>>> +CONFIG_MACH_SUN50I_H616=y
>>> +CONFIG_SUNXI_DRAM_H616_LPDDR4=y
>>> +CONFIG_R_I2C_ENABLE=y
>>> +CONFIG_SPL_SPI_SUNXI=y
>>> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>>> +CONFIG_SPL_I2C=y
>>> +CONFIG_SPL_SYS_I2C_LEGACY=y
>>> +CONFIG_SYS_I2C_MVTWSI=y
>>> +CONFIG_SYS_I2C_SLAVE=0x7f
>>> +CONFIG_SYS_I2C_SPEED=400000
>>> +CONFIG_SPI_FLASH_ZBIT=y
>>> +CONFIG_PHY_MOTORCOMM=y
>>> +CONFIG_SUN8I_EMAC=y
>>> +CONFIG_AXP313_POWER=y
>>> +CONFIG_SPI=y
>>> +CONFIG_USB_EHCI_HCD=y
>>> +CONFIG_USB_OHCI_HCD=y
>>> +CONFIG_USB_MUSB_GADGET=y

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Stephen Graf]

Yes I forgot about the zBIT patch. With this patch also included I built 
and retested u-boot loaded from SPI flash.  The two warning/error 
messages disappeared and the flash worked properly and booted from a USB 
device.

There was one message that I did not understand:
"Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment"

I tried to follow the u-boot documentation on writing the SPI flash but 
had problems with the write command.  When issued it returned 
immediately. The erase command took about 5 sec to execute. I researched 
use of mtd commands and got a suggestion to use cat instead, which worked.

"root@orangepizero3:~# mtdinfo
Count of MTD devices:           1
Present MTD devices:            mtd0
Sysfs interface supported:      yes
root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
Erased 983040 bytes from address 0x00000000 in flash
root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
/home/sysadmin/u-boot-sunxi-with-spl.bin
file_to_flash: fread, size 0xf0000, n 0xf0000
fread(): Success
root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin > 
/dev/mtd0


Console log of boot:

U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
-0800)
DRAM: 1024 MiB
Trying to boot from sunxi SPI
NOTICE:  BL31: v2.10.0  (debug):v2.10.0
NOTICE:  BL31: Built : 18:07:18, Nov 23 2023
NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2798, model: OrangePi Zero3
INFO:    ARM GICv2 driver initialized
INFO:    Configuring SPC Controller
INFO:    PMIC: Probing AXP305 on RSB
ERROR:   RSB: set run-time address: 0x10003
INFO:    Could not init RSB: -65539
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for erratum 855873 was applied
INFO:    BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
INFO:    PSCI: Suspend is unavailable
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9
INFO:    Changed devicetree.


U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
-0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB
Core:  57 devices, 25 uclasses, devicetree: separate
WDT:   Not starting watchdog@30090a0
MMC:   mmc@4020000: 0
Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

Loading Environment from FAT... Card did not respond to voltage select! 
: -110
** Bad device specification mmc 0 **
In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Allwinner mUSB OTG (Peripheral)
Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS 
ep2in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
RNDIS ready
, eth1: usb_ether
starting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
Device NOT ready
    Request Sense returned 02 3A 00
2 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
        scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
Card did not respond to voltage select! : -110

Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
             Type: Removable Hard Disk
             Capacity: 3828.0 MB = 3.7 GB (7839744 x 512)
... is now current device
Scanning usb 0:1...
Found U-Boot script /boot.scr
1575 bytes read in 1 ms (1.5 MiB/s)
## Executing script at 4fc00000
Mainline u-boot / new-style environment detected.
This installer medium does not contain a suitable device-tree file for
this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot 
process.
SCRIPT FAILED: continuing...
Found U-Boot script /boot/boot.scr
621 bytes read in 2 ms (302.7 KiB/s)
## Executing script at 4fc00000
19472 bytes read in 3 ms (6.2 MiB/s)
Working FDT set to 4fa00000
7088139 bytes read in 326 ms (20.7 MiB/s)
22491144 bytes read in 1031 ms (20.8 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=41800000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
    Image Name:   uInitrd
    Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
    Data Size:    7088075 Bytes = 6.8 MiB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
    Booting using the fdt blob at 0x4fa00000
Working FDT set to 4fa00000
    Loading Ramdisk to 4993d000, end 49fff7cb ... OK
    Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
Working FDT set to 498cf000

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 6.6.2 (orangepi@orangepizero3) (gcc (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov 
25 18:37:47 UTC 2023


On 2023-11-26 4:23 a.m., Andre Przywara wrote:
> On Sat, 25 Nov 2023 20:27:05 -0800
> Stephen Graf <stephen.graf@gmail.com> wrote:
> 
> Hi Stephen,
> 
>> I built u-boot with the additional parameter for usb and it works, I think.  There was one message that might be of concern "
>> Card did not respond to voltage select! : -110".
> 
> This is a normal, though admittedly confusing message if no SD card is
> inserted. The code tries to (unconditionally) access the SD card, and
> sees that no card is there, the missing respond to the voltage select
> command is just the first real proof of this.
> 
>> I am not sure of the details of the boot.cmd. The output below came from
>> the supplier image on an SD plugged into a USB card reader. The SD slot of the board was empty.
>>
>> I was able to install u-boot to the SPI flash memory and there is a warning message from that also: "
>> Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18
>> *** Warning - spi_flash_probe_bus_cs() failed, using default environment"
> 
> So for a start there is no environment on the SPI flash yet, so it
> wouldn't do anything. But the "unrecognised JEDEC id bytes" message
> doesn't sound right. Can you dig into this? Do you have patch 1/3
> applied, which tells U-Boot about 0x5e meaning zBIT?
> 

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Stephen Graf]

Since the last test I rebuilt u-boot without the
"CONFIG_DRAM_CLK=792" in the defconfig and got the wrong DRAM size 
problem (showing 2G instead of 1G). I had to do a power down/up to see this.
Are you planning to add this parameter to your patch?

U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 12:25:33 
-0800) Allwin                                                      ner 
Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  2 GiB


On 2023-11-27 12:21 p.m., Stephen Graf wrote:
> Yes I forgot about the zBIT patch. With this patch also included I built 
> and retested u-boot loaded from SPI flash.  The two warning/error 
> messages disappeared and the flash worked properly and booted from a USB 
> device.
> 
> There was one message that I did not understand:
> "Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment"
> 
> I tried to follow the u-boot documentation on writing the SPI flash but 
> had problems with the write command.  When issued it returned 
> immediately. The erase command took about 5 sec to execute. I researched 
> use of mtd commands and got a suggestion to use cat instead, which worked.
> 
> "root@orangepizero3:~# mtdinfo
> Count of MTD devices:           1
> Present MTD devices:            mtd0
> Sysfs interface supported:      yes
> root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
> Erased 983040 bytes from address 0x00000000 in flash
> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
> /home/sysadmin/u-boot-sunxi-with-spl.bin
> file_to_flash: fread, size 0xf0000, n 0xf0000
> fread(): Success
> root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin > 
> /dev/mtd0
> 
> 
> Console log of boot:
> 
> U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
> -0800)
> DRAM: 1024 MiB
> Trying to boot from sunxi SPI
> NOTICE:  BL31: v2.10.0  (debug):v2.10.0
> NOTICE:  BL31: Built : 18:07:18, Nov 23 2023
> NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
> NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2798, model: OrangePi Zero3
> INFO:    ARM GICv2 driver initialized
> INFO:    Configuring SPC Controller
> INFO:    PMIC: Probing AXP305 on RSB
> ERROR:   RSB: set run-time address: 0x10003
> INFO:    Could not init RSB: -65539
> INFO:    BL31: Platform setup done
> INFO:    BL31: Initializing runtime services
> INFO:    BL31: cortex_a53: CPU workaround for erratum 855873 was applied
> INFO:    BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
> INFO:    PSCI: Suspend is unavailable
> INFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0x4a000000
> INFO:    SPSR = 0x3c9
> INFO:    Changed devicetree.
> 
> 
> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
> -0800) Allwinner Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  1 GiB
> Core:  57 devices, 25 uclasses, devicetree: separate
> WDT:   Not starting watchdog@30090a0
> MMC:   mmc@4020000: 0
> Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
> 
> Loading Environment from FAT... Card did not respond to voltage select! 
> : -110
> ** Bad device specification mmc 0 **
> In:    serial@5000000
> Out:   serial@5000000
> Err:   serial@5000000
> Allwinner mUSB OTG (Peripheral)
> Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS 
> ep2in
> MAC de:ad:be:ef:00:01
> HOST MAC de:ad:be:ef:00:00
> RNDIS ready
> , eth1: usb_ether
> starting USB...
> Bus usb@5200000: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@5200000 for devices... Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> 2 USB Device(s) found
> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> Card did not respond to voltage select! : -110
> 
> Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
>              Type: Removable Hard Disk
>              Capacity: 3828.0 MB = 3.7 GB (7839744 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found U-Boot script /boot.scr
> 1575 bytes read in 1 ms (1.5 MiB/s)
> ## Executing script at 4fc00000
> Mainline u-boot / new-style environment detected.
> This installer medium does not contain a suitable device-tree file for
> this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot 
> process.
> SCRIPT FAILED: continuing...
> Found U-Boot script /boot/boot.scr
> 621 bytes read in 2 ms (302.7 KiB/s)
> ## Executing script at 4fc00000
> 19472 bytes read in 3 ms (6.2 MiB/s)
> Working FDT set to 4fa00000
> 7088139 bytes read in 326 ms (20.7 MiB/s)
> 22491144 bytes read in 1031 ms (20.8 MiB/s)
> Moving Image from 0x40080000 to 0x40200000, end=41800000
> ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
>     Image Name:   uInitrd
>     Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>     Data Size:    7088075 Bytes = 6.8 MiB
>     Load Address: 00000000
>     Entry Point:  00000000
>     Verifying Checksum ... OK
> ## Flattened Device Tree blob at 4fa00000
>     Booting using the fdt blob at 0x4fa00000
> Working FDT set to 4fa00000
>     Loading Ramdisk to 4993d000, end 49fff7cb ... OK
>     Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
> Working FDT set to 498cf000
> 
> Starting kernel ...
> 
> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> [    0.000000] Linux version 6.6.2 (orangepi@orangepizero3) (gcc (Debian 
> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov 
> 25 18:37:47 UTC 2023
> 
> 
> On 2023-11-26 4:23 a.m., Andre Przywara wrote:
>> On Sat, 25 Nov 2023 20:27:05 -0800
>> Stephen Graf <stephen.graf@gmail.com> wrote:
>>
>> Hi Stephen,
>>
>>> I built u-boot with the additional parameter for usb and it works, I 
>>> think.  There was one message that might be of concern "
>>> Card did not respond to voltage select! : -110".
>>
>> This is a normal, though admittedly confusing message if no SD card is
>> inserted. The code tries to (unconditionally) access the SD card, and
>> sees that no card is there, the missing respond to the voltage select
>> command is just the first real proof of this.
>>
>>> I am not sure of the details of the boot.cmd. The output below came from
>>> the supplier image on an SD plugged into a USB card reader. The SD 
>>> slot of the board was empty.
>>>
>>> I was able to install u-boot to the SPI flash memory and there is a 
>>> warning message from that also: "
>>> Loading Environment from SPIFlash... jedec_spi_nor flash@0: 
>>> unrecognized JEDEC id bytes: 5e, 40, 18
>>> *** Warning - spi_flash_probe_bus_cs() failed, using default 
>>> environment"
>>
>> So for a start there is no environment on the SPI flash yet, so it
>> wouldn't do anything. But the "unrecognised JEDEC id bytes" message
>> doesn't sound right. Can you dig into this? Do you have patch 1/3
>> applied, which tells U-Boot about 0x5e meaning zBIT?
>>

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Andre Przywara]

On Mon, 27 Nov 2023 12:21:44 -0800
Stephen Graf <stephen.graf@gmail.com> wrote:

Hi Stephen!

> Yes I forgot about the zBIT patch. With this patch also included I built 
> and retested u-boot loaded from SPI flash.  The two warning/error 
> messages disappeared and the flash worked properly and booted from a USB 
> device.

Great!

> There was one message that I did not understand:
> "Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment"

This is because there is no environment saved on the SPI flash (yet).
You just copied the U-Boot image, the environment is in a separate
area (behind that), defined by CONFIG_ENV_OFFSET, which is 64K below
1MB. There could be any kind of garbage there, initially, and U-Boot
fortunately protects the environment with a checksum, so detects that
this is not valid data, and falls back to the built-in environment.
And frankly this is probably all you ever need, I think these days
there is little that needs to be saved in the environment.
If you want to give it a try, type "saveenv" on the U-Boot prompt. On
the next boot U-Boot would detect this now properly initialised data
region and you will probably not see the message anymore.
But again this really only makes sense if you *change* something in the
environment and want that preserved across reboots.

> I tried to follow the u-boot documentation on writing the SPI flash but 
> had problems with the write command.  When issued it returned 
> immediately. The erase command took about 5 sec to execute. I researched 
> use of mtd commands and got a suggestion to use cat instead, which worked.

Mmh, can you elaborate on that? Did you mean you piped in the data into
the mtd_debug command? Or did you write directly to /dev/mtd0, using
cat? And which version of mtd_debug was this, exactly? I guess the
official one from Debian Bookworm?

Cheers,
Andre


> "root@orangepizero3:~# mtdinfo
> Count of MTD devices:           1
> Present MTD devices:            mtd0
> Sysfs interface supported:      yes
> root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
> Erased 983040 bytes from address 0x00000000 in flash
> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
> /home/sysadmin/u-boot-sunxi-with-spl.bin
> file_to_flash: fread, size 0xf0000, n 0xf0000
> fread(): Success
> root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin > 
> /dev/mtd0
> 
> 
> Console log of boot:
> 
> U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
> -0800)
> DRAM: 1024 MiB
> Trying to boot from sunxi SPI
> NOTICE:  BL31: v2.10.0  (debug):v2.10.0
> NOTICE:  BL31: Built : 18:07:18, Nov 23 2023
> NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
> NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2798, model: OrangePi Zero3
> INFO:    ARM GICv2 driver initialized
> INFO:    Configuring SPC Controller
> INFO:    PMIC: Probing AXP305 on RSB
> ERROR:   RSB: set run-time address: 0x10003
> INFO:    Could not init RSB: -65539
> INFO:    BL31: Platform setup done
> INFO:    BL31: Initializing runtime services
> INFO:    BL31: cortex_a53: CPU workaround for erratum 855873 was applied
> INFO:    BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
> INFO:    PSCI: Suspend is unavailable
> INFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0x4a000000
> INFO:    SPSR = 0x3c9
> INFO:    Changed devicetree.
> 
> 
> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
> -0800) Allwinner Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  1 GiB
> Core:  57 devices, 25 uclasses, devicetree: separate
> WDT:   Not starting watchdog@30090a0
> MMC:   mmc@4020000: 0
> Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
> 
> Loading Environment from FAT... Card did not respond to voltage select! 
> : -110
> ** Bad device specification mmc 0 **
> In:    serial@5000000
> Out:   serial@5000000
> Err:   serial@5000000
> Allwinner mUSB OTG (Peripheral)
> Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS 
> ep2in
> MAC de:ad:be:ef:00:01
> HOST MAC de:ad:be:ef:00:00
> RNDIS ready
> , eth1: usb_ether
> starting USB...
> Bus usb@5200000: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@5200000 for devices... Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> Device NOT ready
>     Request Sense returned 02 3A 00
> 2 USB Device(s) found
> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> Card did not respond to voltage select! : -110
> 
> Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
>              Type: Removable Hard Disk
>              Capacity: 3828.0 MB = 3.7 GB (7839744 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found U-Boot script /boot.scr
> 1575 bytes read in 1 ms (1.5 MiB/s)
> ## Executing script at 4fc00000
> Mainline u-boot / new-style environment detected.
> This installer medium does not contain a suitable device-tree file for
> this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot 
> process.
> SCRIPT FAILED: continuing...
> Found U-Boot script /boot/boot.scr
> 621 bytes read in 2 ms (302.7 KiB/s)
> ## Executing script at 4fc00000
> 19472 bytes read in 3 ms (6.2 MiB/s)
> Working FDT set to 4fa00000
> 7088139 bytes read in 326 ms (20.7 MiB/s)
> 22491144 bytes read in 1031 ms (20.8 MiB/s)
> Moving Image from 0x40080000 to 0x40200000, end=41800000
> ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
>     Image Name:   uInitrd
>     Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>     Data Size:    7088075 Bytes = 6.8 MiB
>     Load Address: 00000000
>     Entry Point:  00000000
>     Verifying Checksum ... OK
> ## Flattened Device Tree blob at 4fa00000
>     Booting using the fdt blob at 0x4fa00000
> Working FDT set to 4fa00000
>     Loading Ramdisk to 4993d000, end 49fff7cb ... OK
>     Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
> Working FDT set to 498cf000
> 
> Starting kernel ...
> 
> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> [    0.000000] Linux version 6.6.2 (orangepi@orangepizero3) (gcc (Debian 
> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov 
> 25 18:37:47 UTC 2023
> 
> 
> On 2023-11-26 4:23 a.m., Andre Przywara wrote:
> > On Sat, 25 Nov 2023 20:27:05 -0800
> > Stephen Graf <stephen.graf@gmail.com> wrote:
> > 
> > Hi Stephen,
> >   
> >> I built u-boot with the additional parameter for usb and it works, I think.  There was one message that might be of concern "
> >> Card did not respond to voltage select! : -110".  
> > 
> > This is a normal, though admittedly confusing message if no SD card is
> > inserted. The code tries to (unconditionally) access the SD card, and
> > sees that no card is there, the missing respond to the voltage select
> > command is just the first real proof of this.
> >   
> >> I am not sure of the details of the boot.cmd. The output below came from
> >> the supplier image on an SD plugged into a USB card reader. The SD slot of the board was empty.
> >>
> >> I was able to install u-boot to the SPI flash memory and there is a warning message from that also: "
> >> Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18
> >> *** Warning - spi_flash_probe_bus_cs() failed, using default environment"  
> > 
> > So for a start there is no environment on the SPI flash yet, so it
> > wouldn't do anything. But the "unrecognised JEDEC id bytes" message
> > doesn't sound right. Can you dig into this? Do you have patch 1/3
> > applied, which tells U-Boot about 0x5e meaning zBIT?
> >   
> 

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Andre Przywara]

On Mon, 27 Nov 2023 14:31:19 -0800
Stephen Graf <stephen.graf@gmail.com> wrote:

Hi,

> Since the last test I rebuilt u-boot without the
> "CONFIG_DRAM_CLK=792" in the defconfig and got the wrong DRAM size 
> problem (showing 2G instead of 1G). I had to do a power down/up to see this.
> Are you planning to add this parameter to your patch?

This symptom is pretty surely not directly related to the DRAM
frequency, it's caused by a missing barrier or delay *somewhere*.
People report that this is fixed by adding another "dsb();" at the
beginning of the mctl_mem_matches() function, but I don't have a good
explanation why exactly there, and would like to avoid submitting
patches that "just seem to work (TM)".

If I find some time, I will try to setup some automated environment
where I can run some experiments with different barrier locations.
I can offer some rationale for putting it at the end of the function(s)
that call mctl_mem_matches(), so hope that this fixes it.

Cheers,
Andre

> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 12:25:33 
> -0800) Allwin                                                      ner 
> Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  2 GiB
> 
> 
> On 2023-11-27 12:21 p.m., Stephen Graf wrote:
> > Yes I forgot about the zBIT patch. With this patch also included I built 
> > and retested u-boot loaded from SPI flash.  The two warning/error 
> > messages disappeared and the flash worked properly and booted from a USB 
> > device.
> > 
> > There was one message that I did not understand:
> > "Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
> > size 256 Bytes, erase size 4 KiB, total 16 MiB
> > *** Warning - bad CRC, using default environment"
> > 
> > I tried to follow the u-boot documentation on writing the SPI flash but 
> > had problems with the write command.  When issued it returned 
> > immediately. The erase command took about 5 sec to execute. I researched 
> > use of mtd commands and got a suggestion to use cat instead, which worked.
> > 
> > "root@orangepizero3:~# mtdinfo
> > Count of MTD devices:           1
> > Present MTD devices:            mtd0
> > Sysfs interface supported:      yes
> > root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
> > Erased 983040 bytes from address 0x00000000 in flash
> > root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
> > /home/sysadmin/u-boot-sunxi-with-spl.bin
> > file_to_flash: fread, size 0xf0000, n 0xf0000
> > fread(): Success
> > root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin > 
> > /dev/mtd0
> > 
> > 
> > Console log of boot:
> > 
> > U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
> > -0800)
> > DRAM: 1024 MiB
> > Trying to boot from sunxi SPI
> > NOTICE:  BL31: v2.10.0  (debug):v2.10.0
> > NOTICE:  BL31: Built : 18:07:18, Nov 23 2023
> > NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
> > NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2798, model: OrangePi Zero3
> > INFO:    ARM GICv2 driver initialized
> > INFO:    Configuring SPC Controller
> > INFO:    PMIC: Probing AXP305 on RSB
> > ERROR:   RSB: set run-time address: 0x10003
> > INFO:    Could not init RSB: -65539
> > INFO:    BL31: Platform setup done
> > INFO:    BL31: Initializing runtime services
> > INFO:    BL31: cortex_a53: CPU workaround for erratum 855873 was applied
> > INFO:    BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
> > INFO:    PSCI: Suspend is unavailable
> > INFO:    BL31: Preparing for EL3 exit to normal world
> > INFO:    Entry point address = 0x4a000000
> > INFO:    SPSR = 0x3c9
> > INFO:    Changed devicetree.
> > 
> > 
> > U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46 
> > -0800) Allwinner Technology
> > 
> > CPU:   Allwinner H616 (SUN50I)
> > Model: OrangePi Zero3
> > DRAM:  1 GiB
> > Core:  57 devices, 25 uclasses, devicetree: separate
> > WDT:   Not starting watchdog@30090a0
> > MMC:   mmc@4020000: 0
> > Loading Environment from SPIFlash... SF: Detected zb25vq128 with page 
> > size 256 Bytes, erase size 4 KiB, total 16 MiB
> > *** Warning - bad CRC, using default environment
> > 
> > Loading Environment from FAT... Card did not respond to voltage select! 
> > : -110
> > ** Bad device specification mmc 0 **
> > In:    serial@5000000
> > Out:   serial@5000000
> > Err:   serial@5000000
> > Allwinner mUSB OTG (Peripheral)
> > Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS 
> > ep2in
> > MAC de:ad:be:ef:00:01
> > HOST MAC de:ad:be:ef:00:00
> > RNDIS ready
> > , eth1: usb_ether
> > starting USB...
> > Bus usb@5200000: USB EHCI 1.00
> > Bus usb@5200400: USB OHCI 1.0
> > scanning bus usb@5200000 for devices... Device NOT ready
> >     Request Sense returned 02 3A 00
> > Device NOT ready
> >     Request Sense returned 02 3A 00
> > Device NOT ready
> >     Request Sense returned 02 3A 00
> > 2 USB Device(s) found
> > scanning bus usb@5200400 for devices... 1 USB Device(s) found
> >         scanning usb for storage devices... 1 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > Card did not respond to voltage select! : -110
> > 
> > Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
> >              Type: Removable Hard Disk
> >              Capacity: 3828.0 MB = 3.7 GB (7839744 x 512)
> > ... is now current device
> > Scanning usb 0:1...
> > Found U-Boot script /boot.scr
> > 1575 bytes read in 1 ms (1.5 MiB/s)
> > ## Executing script at 4fc00000
> > Mainline u-boot / new-style environment detected.
> > This installer medium does not contain a suitable device-tree file for
> > this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot 
> > process.
> > SCRIPT FAILED: continuing...
> > Found U-Boot script /boot/boot.scr
> > 621 bytes read in 2 ms (302.7 KiB/s)
> > ## Executing script at 4fc00000
> > 19472 bytes read in 3 ms (6.2 MiB/s)
> > Working FDT set to 4fa00000
> > 7088139 bytes read in 326 ms (20.7 MiB/s)
> > 22491144 bytes read in 1031 ms (20.8 MiB/s)
> > Moving Image from 0x40080000 to 0x40200000, end=41800000
> > ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
> >     Image Name:   uInitrd
> >     Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
> >     Data Size:    7088075 Bytes = 6.8 MiB
> >     Load Address: 00000000
> >     Entry Point:  00000000
> >     Verifying Checksum ... OK
> > ## Flattened Device Tree blob at 4fa00000
> >     Booting using the fdt blob at 0x4fa00000
> > Working FDT set to 4fa00000
> >     Loading Ramdisk to 4993d000, end 49fff7cb ... OK
> >     Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
> > Working FDT set to 498cf000
> > 
> > Starting kernel ...
> > 
> > [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > [    0.000000] Linux version 6.6.2 (orangepi@orangepizero3) (gcc (Debian 
> > 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov 
> > 25 18:37:47 UTC 2023
> > 
> > 
> > On 2023-11-26 4:23 a.m., Andre Przywara wrote:  
> >> On Sat, 25 Nov 2023 20:27:05 -0800
> >> Stephen Graf <stephen.graf@gmail.com> wrote:
> >>
> >> Hi Stephen,
> >>  
> >>> I built u-boot with the additional parameter for usb and it works, I 
> >>> think.  There was one message that might be of concern "
> >>> Card did not respond to voltage select! : -110".  
> >>
> >> This is a normal, though admittedly confusing message if no SD card is
> >> inserted. The code tries to (unconditionally) access the SD card, and
> >> sees that no card is there, the missing respond to the voltage select
> >> command is just the first real proof of this.
> >>  
> >>> I am not sure of the details of the boot.cmd. The output below came from
> >>> the supplier image on an SD plugged into a USB card reader. The SD 
> >>> slot of the board was empty.
> >>>
> >>> I was able to install u-boot to the SPI flash memory and there is a 
> >>> warning message from that also: "
> >>> Loading Environment from SPIFlash... jedec_spi_nor flash@0: 
> >>> unrecognized JEDEC id bytes: 5e, 40, 18
> >>> *** Warning - spi_flash_probe_bus_cs() failed, using default 
> >>> environment"  
> >>
> >> So for a start there is no environment on the SPI flash yet, so it
> >> wouldn't do anything. But the "unrecognised JEDEC id bytes" message
> >> doesn't sound right. Can you dig into this? Do you have patch 1/3
> >> applied, which tells U-Boot about 0x5e meaning zBIT?
> >>  
> 

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Stephen Graf]

I got the initial defconfig that I started testing with from:

https://gist.github.com/iuncuim/2150b7a5317700314393665260ca628e

which has CONFIG_DRAM_CLK=792.

Just a few hours ago, when I was testing without this parameter, my 
system misbehaved and refused to reboot. The file system was corrupted 
and I had to reinstall the rootfs to get it going again.  I put the 
u-boot with the CONFIG_DRAM_CLK=792 back on it.

I will retest the system by building u-boot which is what I was doing 
when it crashed.

On 2023-11-27 5:37 p.m., Andre Przywara wrote:
> On Mon, 27 Nov 2023 14:31:19 -0800
> Stephen Graf <stephen.graf@gmail.com> wrote:
> 
> Hi,
> 
>> Since the last test I rebuilt u-boot without the
>> "CONFIG_DRAM_CLK=792" in the defconfig and got the wrong DRAM size
>> problem (showing 2G instead of 1G). I had to do a power down/up to see this.
>> Are you planning to add this parameter to your patch?
> 
> This symptom is pretty surely not directly related to the DRAM
> frequency, it's caused by a missing barrier or delay *somewhere*.
> People report that this is fixed by adding another "dsb();" at the
> beginning of the mctl_mem_matches() function, but I don't have a good
> explanation why exactly there, and would like to avoid submitting
> patches that "just seem to work (TM)".
> 
> If I find some time, I will try to setup some automated environment
> where I can run some experiments with different barrier locations.
> I can offer some rationale for putting it at the end of the function(s)
> that call mctl_mem_matches(), so hope that this fixes it.
> 
> Cheers,
> Andre
> 
>> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 12:25:33
>> -0800) Allwin                                                      ner
>> Technology
>>
>> CPU:   Allwinner H616 (SUN50I)
>> Model: OrangePi Zero3
>> DRAM:  2 GiB
>>
>>
>> On 2023-11-27 12:21 p.m., Stephen Graf wrote:
>>> Yes I forgot about the zBIT patch. With this patch also included I built
>>> and retested u-boot loaded from SPI flash.  The two warning/error
>>> messages disappeared and the flash worked properly and booted from a USB
>>> device.
>>>
>>> There was one message that I did not understand:
>>> "Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
>>> size 256 Bytes, erase size 4 KiB, total 16 MiB
>>> *** Warning - bad CRC, using default environment"
>>>
>>> I tried to follow the u-boot documentation on writing the SPI flash but
>>> had problems with the write command.  When issued it returned
>>> immediately. The erase command took about 5 sec to execute. I researched
>>> use of mtd commands and got a suggestion to use cat instead, which worked.
>>>
>>> "root@orangepizero3:~# mtdinfo
>>> Count of MTD devices:           1
>>> Present MTD devices:            mtd0
>>> Sysfs interface supported:      yes
>>> root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
>>> Erased 983040 bytes from address 0x00000000 in flash
>>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000
>>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>>> file_to_flash: fread, size 0xf0000, n 0xf0000
>>> fread(): Success
>>> root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin >
>>> /dev/mtd0
>>>
>>>
>>> Console log of boot:
>>>
>>> U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
>>> -0800)
>>> DRAM: 1024 MiB
>>> Trying to boot from sunxi SPI
>>> NOTICE:  BL31: v2.10.0  (debug):v2.10.0
>>> NOTICE:  BL31: Built : 18:07:18, Nov 23 2023
>>> NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
>>> NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2798, model: OrangePi Zero3
>>> INFO:    ARM GICv2 driver initialized
>>> INFO:    Configuring SPC Controller
>>> INFO:    PMIC: Probing AXP305 on RSB
>>> ERROR:   RSB: set run-time address: 0x10003
>>> INFO:    Could not init RSB: -65539
>>> INFO:    BL31: Platform setup done
>>> INFO:    BL31: Initializing runtime services
>>> INFO:    BL31: cortex_a53: CPU workaround for erratum 855873 was applied
>>> INFO:    BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
>>> INFO:    PSCI: Suspend is unavailable
>>> INFO:    BL31: Preparing for EL3 exit to normal world
>>> INFO:    Entry point address = 0x4a000000
>>> INFO:    SPSR = 0x3c9
>>> INFO:    Changed devicetree.
>>>
>>>
>>> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
>>> -0800) Allwinner Technology
>>>
>>> CPU:   Allwinner H616 (SUN50I)
>>> Model: OrangePi Zero3
>>> DRAM:  1 GiB
>>> Core:  57 devices, 25 uclasses, devicetree: separate
>>> WDT:   Not starting watchdog@30090a0
>>> MMC:   mmc@4020000: 0
>>> Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
>>> size 256 Bytes, erase size 4 KiB, total 16 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Loading Environment from FAT... Card did not respond to voltage select!
>>> : -110
>>> ** Bad device specification mmc 0 **
>>> In:    serial@5000000
>>> Out:   serial@5000000
>>> Err:   serial@5000000
>>> Allwinner mUSB OTG (Peripheral)
>>> Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS
>>> ep2in
>>> MAC de:ad:be:ef:00:01
>>> HOST MAC de:ad:be:ef:00:00
>>> RNDIS ready
>>> , eth1: usb_ether
>>> starting USB...
>>> Bus usb@5200000: USB EHCI 1.00
>>> Bus usb@5200400: USB OHCI 1.0
>>> scanning bus usb@5200000 for devices... Device NOT ready
>>>      Request Sense returned 02 3A 00
>>> Device NOT ready
>>>      Request Sense returned 02 3A 00
>>> Device NOT ready
>>>      Request Sense returned 02 3A 00
>>> 2 USB Device(s) found
>>> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>>>          scanning usb for storage devices... 1 Storage Device(s) found
>>> Hit any key to stop autoboot:  0
>>> Card did not respond to voltage select! : -110
>>>
>>> Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
>>>               Type: Removable Hard Disk
>>>               Capacity: 3828.0 MB = 3.7 GB (7839744 x 512)
>>> ... is now current device
>>> Scanning usb 0:1...
>>> Found U-Boot script /boot.scr
>>> 1575 bytes read in 1 ms (1.5 MiB/s)
>>> ## Executing script at 4fc00000
>>> Mainline u-boot / new-style environment detected.
>>> This installer medium does not contain a suitable device-tree file for
>>> this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot
>>> process.
>>> SCRIPT FAILED: continuing...
>>> Found U-Boot script /boot/boot.scr
>>> 621 bytes read in 2 ms (302.7 KiB/s)
>>> ## Executing script at 4fc00000
>>> 19472 bytes read in 3 ms (6.2 MiB/s)
>>> Working FDT set to 4fa00000
>>> 7088139 bytes read in 326 ms (20.7 MiB/s)
>>> 22491144 bytes read in 1031 ms (20.8 MiB/s)
>>> Moving Image from 0x40080000 to 0x40200000, end=41800000
>>> ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
>>>      Image Name:   uInitrd
>>>      Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>>>      Data Size:    7088075 Bytes = 6.8 MiB
>>>      Load Address: 00000000
>>>      Entry Point:  00000000
>>>      Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 4fa00000
>>>      Booting using the fdt blob at 0x4fa00000
>>> Working FDT set to 4fa00000
>>>      Loading Ramdisk to 4993d000, end 49fff7cb ... OK
>>>      Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
>>> Working FDT set to 498cf000
>>>
>>> Starting kernel ...
>>>
>>> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>> [    0.000000] Linux version 6.6.2 (orangepi@orangepizero3) (gcc (Debian
>>> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov
>>> 25 18:37:47 UTC 2023
>>>
>>>
>>> On 2023-11-26 4:23 a.m., Andre Przywara wrote:
>>>> On Sat, 25 Nov 2023 20:27:05 -0800
>>>> Stephen Graf <stephen.graf@gmail.com> wrote:
>>>>
>>>> Hi Stephen,
>>>>   
>>>>> I built u-boot with the additional parameter for usb and it works, I
>>>>> think.  There was one message that might be of concern "
>>>>> Card did not respond to voltage select! : -110".
>>>>
>>>> This is a normal, though admittedly confusing message if no SD card is
>>>> inserted. The code tries to (unconditionally) access the SD card, and
>>>> sees that no card is there, the missing respond to the voltage select
>>>> command is just the first real proof of this.
>>>>   
>>>>> I am not sure of the details of the boot.cmd. The output below came from
>>>>> the supplier image on an SD plugged into a USB card reader. The SD
>>>>> slot of the board was empty.
>>>>>
>>>>> I was able to install u-boot to the SPI flash memory and there is a
>>>>> warning message from that also: "
>>>>> Loading Environment from SPIFlash... jedec_spi_nor flash@0:
>>>>> unrecognized JEDEC id bytes: 5e, 40, 18
>>>>> *** Warning - spi_flash_probe_bus_cs() failed, using default
>>>>> environment"
>>>>
>>>> So for a start there is no environment on the SPI flash yet, so it
>>>> wouldn't do anything. But the "unrecognised JEDEC id bytes" message
>>>> doesn't sound right. Can you dig into this? Do you have patch 1/3
>>>> applied, which tells U-Boot about 0x5e meaning zBIT?
>>>>   
>>
> 

Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support

[Stephen Graf]

I did some digging into the orangepi SDK and it sort of looks like the 
zero3 is set up for dram_clk = 792. I use their image as a fallback and 
it has been stable (built linux kernel and set up debian rootfs).

from https://github.com/orangepi-xunlong/orangepi-build.git

external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero3-u-boot-legacy.dts: 
                  dram_type = <0x8>;


external/packages/pack-uboot/sun50iw9/bin/sys_config/sys_config_orangepizero3.fex

[dram_para]
dram_clk = 792
dram_type = 8
dram_dx_odt = 0x07070707
dram_dx_dri = 0x0e0e0e0e
dram_ca_dri = 0x0e0e
dram_odt_en = 0xaaaaeeee
dram_para1 = 0x30fa
dram_para2 = 0x0000
dram_mr0 = 0x0
dram_mr1 = 0x34
dram_mr2 = 0x1b
dram_mr3 = 0x33
dram_mr4 = 0x3
dram_mr5 = 0x0
dram_mr6 = 0x0
dram_mr11 = 0x4
dram_mr12 = 0x72
dram_mr13 = 0x0
dram_mr14 = 0x9
dram_mr16 = 0x0
dram_mr17 = 0x0
dram_mr22 = 0x24
dram_tpr0 = 0x0
dram_tpr1 = 0x0
dram_tpr2 = 0x0
dram_tpr3 = 0x0
dram_tpr6 = 0x35808080
dram_tpr10 = 0x402f6663
dram_tpr11 = 0x36363535
dram_tpr12 = 0x10101110
dram_tpr13 = 0x2080C60


[dram_para16]
dram_clk = 792
dram_type = 8
dram_dx_odt = 0x07070707
dram_dx_dri = 0x0e0e0e0e
dram_ca_dri = 0x0e0e
dram_odt_en = 0xaaaaeeee
dram_para1 = 0x30fa
dram_para2 = 0x0000
dram_mr0 = 0x0
dram_mr1 = 0x34
dram_mr2 = 0x1b
dram_mr3 = 0x33
dram_mr4 = 0x3
dram_mr5 = 0x0
dram_mr6 = 0x0
dram_mr11 = 0x4
dram_mr12 = 0x72
dram_mr13 = 0x0
dram_mr14 = 0x9
dram_mr16 = 0x0
dram_mr17 = 0x0
dram_mr22 = 0x24
dram_tpr0 = 0x0
dram_tpr1 = 0x0
dram_tpr2 = 0x0
dram_tpr3 = 0x0
dram_tpr6 = 0x35808080
dram_tpr10 = 0x402f6663
dram_tpr11 = 0x36363535
dram_tpr12 = 0x10101110
dram_tpr13 = 0x2080C60

On 2023-11-27 5:37 p.m., Andre Przywara wrote:
> On Mon, 27 Nov 2023 14:31:19 -0800
> Stephen Graf <stephen.graf@gmail.com> wrote:
> 
> Hi,
> 
>> Since the last test I rebuilt u-boot without the
>> "CONFIG_DRAM_CLK=792" in the defconfig and got the wrong DRAM size
>> problem (showing 2G instead of 1G). I had to do a power down/up to see this.
>> Are you planning to add this parameter to your patch?
> 
> This symptom is pretty surely not directly related to the DRAM
> frequency, it's caused by a missing barrier or delay *somewhere*.
> People report that this is fixed by adding another "dsb();" at the
> beginning of the mctl_mem_matches() function, but I don't have a good
> explanation why exactly there, and would like to avoid submitting
> patches that "just seem to work (TM)".
> 
> If I find some time, I will try to setup some automated environment
> where I can run some experiments with different barrier locations.
> I can offer some rationale for putting it at the end of the function(s)
> that call mctl_mem_matches(), so hope that this fixes it.
> 
> Cheers,
> Andre
> 
>> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 12:25:33
>> -0800) Allwin                                                      ner
>> Technology
>>
>> CPU:   Allwinner H616 (SUN50I)
>> Model: OrangePi Zero3
>> DRAM:  2 GiB
>>
>>
>> On 2023-11-27 12:21 p.m., Stephen Graf wrote:
>>> Yes I forgot about the zBIT patch. With this patch also included I built
>>> and retested u-boot loaded from SPI flash.  The two warning/error
>>> messages disappeared and the flash worked properly and booted from a USB
>>> device.
>>>
>>> There was one message that I did not understand:
>>> "Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
>>> size 256 Bytes, erase size 4 KiB, total 16 MiB
>>> *** Warning - bad CRC, using default environment"
>>>
>>> I tried to follow the u-boot documentation on writing the SPI flash but
>>> had problems with the write command.  When issued it returned
>>> immediately. The erase command took about 5 sec to execute. I researched
>>> use of mtd commands and got a suggestion to use cat instead, which worked.
>>>
>>> "root@orangepizero3:~# mtdinfo
>>> Count of MTD devices:           1
>>> Present MTD devices:            mtd0
>>> Sysfs interface supported:      yes
>>> root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
>>> Erased 983040 bytes from address 0x00000000 in flash
>>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000
>>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>>> file_to_flash: fread, size 0xf0000, n 0xf0000
>>> fread(): Success
>>> root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin >
>>> /dev/mtd0
>>>
>>>
>>> Console log of boot:
>>>
>>> U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
>>> -0800)
>>> DRAM: 1024 MiB
>>> Trying to boot from sunxi SPI
>>> NOTICE:  BL31: v2.10.0  (debug):v2.10.0
>>> NOTICE:  BL31: Built : 18:07:18, Nov 23 2023
>>> NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
>>> NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2798, model: OrangePi Zero3
>>> INFO:    ARM GICv2 driver initialized
>>> INFO:    Configuring SPC Controller
>>> INFO:    PMIC: Probing AXP305 on RSB
>>> ERROR:   RSB: set run-time address: 0x10003
>>> INFO:    Could not init RSB: -65539
>>> INFO:    BL31: Platform setup done
>>> INFO:    BL31: Initializing runtime services
>>> INFO:    BL31: cortex_a53: CPU workaround for erratum 855873 was applied
>>> INFO:    BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
>>> INFO:    PSCI: Suspend is unavailable
>>> INFO:    BL31: Preparing for EL3 exit to normal world
>>> INFO:    Entry point address = 0x4a000000
>>> INFO:    SPSR = 0x3c9
>>> INFO:    Changed devicetree.
>>>
>>>
>>> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
>>> -0800) Allwinner Technology
>>>
>>> CPU:   Allwinner H616 (SUN50I)
>>> Model: OrangePi Zero3
>>> DRAM:  1 GiB
>>> Core:  57 devices, 25 uclasses, devicetree: separate
>>> WDT:   Not starting watchdog@30090a0
>>> MMC:   mmc@4020000: 0
>>> Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
>>> size 256 Bytes, erase size 4 KiB, total 16 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Loading Environment from FAT... Card did not respond to voltage select!
>>> : -110
>>> ** Bad device specification mmc 0 **
>>> In:    serial@5000000
>>> Out:   serial@5000000
>>> Err:   serial@5000000
>>> Allwinner mUSB OTG (Peripheral)
>>> Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS
>>> ep2in
>>> MAC de:ad:be:ef:00:01
>>> HOST MAC de:ad:be:ef:00:00
>>> RNDIS ready
>>> , eth1: usb_ether
>>> starting USB...
>>> Bus usb@5200000: USB EHCI 1.00
>>> Bus usb@5200400: USB OHCI 1.0
>>> scanning bus usb@5200000 for devices... Device NOT ready
>>>      Request Sense returned 02 3A 00
>>> Device NOT ready
>>>      Request Sense returned 02 3A 00
>>> Device NOT ready
>>>      Request Sense returned 02 3A 00
>>> 2 USB Device(s) found
>>> scanning bus usb@5200400 for devices... 1 USB Device(s) found
>>>          scanning usb for storage devices... 1 Storage Device(s) found
>>> Hit any key to stop autoboot:  0
>>> Card did not respond to voltage select! : -110
>>>
>>> Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
>>>               Type: Removable Hard Disk
>>>               Capacity: 3828.0 MB = 3.7 GB (7839744 x 512)
>>> ... is now current device
>>> Scanning usb 0:1...
>>> Found U-Boot script /boot.scr
>>> 1575 bytes read in 1 ms (1.5 MiB/s)
>>> ## Executing script at 4fc00000
>>> Mainline u-boot / new-style environment detected.
>>> This installer medium does not contain a suitable device-tree file for
>>> this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot
>>> process.
>>> SCRIPT FAILED: continuing...
>>> Found U-Boot script /boot/boot.scr
>>> 621 bytes read in 2 ms (302.7 KiB/s)
>>> ## Executing script at 4fc00000
>>> 19472 bytes read in 3 ms (6.2 MiB/s)
>>> Working FDT set to 4fa00000
>>> 7088139 bytes read in 326 ms (20.7 MiB/s)
>>> 22491144 bytes read in 1031 ms (20.8 MiB/s)
>>> Moving Image from 0x40080000 to 0x40200000, end=41800000
>>> ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
>>>      Image Name:   uInitrd
>>>      Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>>>      Data Size:    7088075 Bytes = 6.8 MiB
>>>      Load Address: 00000000
>>>      Entry Point:  00000000
>>>      Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 4fa00000
>>>      Booting using the fdt blob at 0x4fa00000
>>> Working FDT set to 4fa00000
>>>      Loading Ramdisk to 4993d000, end 49fff7cb ... OK
>>>      Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
>>> Working FDT set to 498cf000
>>>
>>> Starting kernel ...
>>>
>>> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>> [    0.000000] Linux version 6.6.2 (orangepi@orangepizero3) (gcc (Debian
>>> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov
>>> 25 18:37:47 UTC 2023
>>>
>>>
>>> On 2023-11-26 4:23 a.m., Andre Przywara wrote:
>>>> On Sat, 25 Nov 2023 20:27:05 -0800
>>>> Stephen Graf <stephen.graf@gmail.com> wrote:
>>>>
>>>> Hi Stephen,
>>>>   
>>>>> I built u-boot with the additional parameter for usb and it works, I
>>>>> think.  There was one message that might be of concern "
>>>>> Card did not respond to voltage select! : -110".
>>>>
>>>> This is a normal, though admittedly confusing message if no SD card is
>>>> inserted. The code tries to (unconditionally) access the SD card, and
>>>> sees that no card is there, the missing respond to the voltage select
>>>> command is just the first real proof of this.
>>>>   
>>>>> I am not sure of the details of the boot.cmd. The output below came from
>>>>> the supplier image on an SD plugged into a USB card reader. The SD
>>>>> slot of the board was empty.
>>>>>
>>>>> I was able to install u-boot to the SPI flash memory and there is a
>>>>> warning message from that also: "
>>>>> Loading Environment from SPIFlash... jedec_spi_nor flash@0:
>>>>> unrecognized JEDEC id bytes: 5e, 40, 18
>>>>> *** Warning - spi_flash_probe_bus_cs() failed, using default
>>>>> environment"
>>>>
>>>> So for a start there is no environment on the SPI flash yet, so it
>>>> wouldn't do anything. But the "unrecognised JEDEC id bytes" message
>>>> doesn't sound right. Can you dig into this? Do you have patch 1/3
>>>> applied, which tells U-Boot about 0x5e meaning zBIT?
>>>>   
>>
> 

mdt_debug write

[Stephen Graf]

Below is the consol log from trying to use mtd_debug write. It returned 
immediately with a strange success message.

root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
/home/sysadmin/u-boot-sunxi-with-spl.bin
file_to_flash: fread, size 0xf0000, n 0xf0000
fread(): Success

I then used the cat command to write to the SPI flash which took a few 
seconds to execute:

root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin > 
/dev/mtd0



>>>
>>> I tried to follow the u-boot documentation on writing the SPI flash but
>>> had problems with the write command.  When issued it returned
>>> immediately. The erase command took about 5 sec to execute. I researched
>>> use of mtd commands and got a suggestion to use cat instead, which worked.
>>>
>>> "root@orangepizero3:~# mtdinfo
>>> Count of MTD devices:           1
>>> Present MTD devices:            mtd0
>>> Sysfs interface supported:      yes
>>> root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
>>> Erased 983040 bytes from address 0x00000000 in flash
>>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000
>>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>>> file_to_flash: fread, size 0xf0000, n 0xf0000
>>> fread(): Success
>>> 
>>>

OrangePI Zero3 memory timing testing

[Stephen Graf]

Some testing results:

With the default DRAM timing of 30x24=720, most often when my system 
boots it comes up with DRAM 2G, but I have a 1G system. Once in a while 
the boot shows 1G.  When it shows 2G the linux OS also shows 2G and 
continuing does not make much sense.

On one boot where u-boot reported 1G the OS agreed and I ran memtester 
successfully.

If I build u-boot with CONFIG_DRAM_CLK=792 (33*24=792) I have never seen 
my system boot with anything other than DRAM 1G showing in u-boot. I ran 
memtester successfully and this system has been stable running linux 6.6.2.

Andre, if you can put together a few patches I can test them to see 
which works.

If anyone else with different variations of the Zero3 would test with 
the two DRAM timings and report results.

I also use the Zunlong image on occasion and it consistently shows 1G 
and from my poking around I think it runs at a 792 clk.


Console output with DRAM default:

U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 
-0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  2 GiB

Last login: Wed Nov 29 09:35:15 PST 2023 on ttyS0
root@orangepizero3:~# free -h
                total        used        free      shared  buff/cache 
available
Mem:           1.9Gi       139Mi       1.7Gi       360Ki        82Mi 
   1.7Gi
Swap:             0B          0B          0B


U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 
-0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB

root@orangepizero3:~# free -h
                total        used        free      shared  buff/cache 
available
Mem:           917Mi       137Mi       766Mi       360Ki        79Mi 
   780Mi
Swap:             0B          0B          0B


root@orangepizero3:~# memtester 700M 1
memtester version 4.6.0 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 700MB (734003200 bytes)
got  700MB (734003200 bytes), trying mlock ...locked.
Loop 1/1:
   Stuck Address       : ok
   Random Value        : ok
   Compare XOR         : ok
   Compare SUB         : ok
   Compare MUL         : ok
   Compare DIV         : ok
   Compare OR          : ok
   Compare AND         : ok
   Sequential Increment: ok
   Solid Bits          : ok
   Block Sequential    : ok
   Checkerboard        : ok
   Bit Spread          : ok
   Bit Flip            : ok
   Walking Ones        : ok
   Walking Zeroes      : ok
   8-bit Writes        : ok
   16-bit Writes       : ok

Done.

Console output with DRAM clk 792:


U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 21:34:46 
-0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB

root@orangepizero3:~# free -h
                total        used        free      shared  buff/cache 
available
Mem:           917Mi       134Mi       768Mi       360Ki        79Mi 
   782Mi
Swap:             0B          0B          0B


root@orangepizero3:~# memtester 700M 1
memtester version 4.6.0 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 700MB (734003200 bytes)
got  700MB (734003200 bytes), trying mlock ...locked.
Loop 1/1:
   Stuck Address       : ok
   Random Value        : ok
   Compare XOR         : ok
   Compare SUB         : ok
   Compare MUL         : ok
   Compare DIV         : ok
   Compare OR          : ok
   Compare AND         : ok
   Sequential Increment: ok
   Solid Bits          : ok
   Block Sequential    : ok
   Checkerboard        : ok
   Bit Spread          : ok
   Bit Flip            : ok
   Walking Ones        : ok
   Walking Zeroes      : ok
   8-bit Writes        : ok
   16-bit Writes       : ok

Done.


On 2023-11-27 5:37 p.m., Andre Przywara wrote:

> 
> This symptom is pretty surely not directly related to the DRAM
> frequency, it's caused by a missing barrier or delay *somewhere*.
> People report that this is fixed by adding another "dsb();" at the
> beginning of the mctl_mem_matches() function, but I don't have a good
> explanation why exactly there, and would like to avoid submitting
> patches that "just seem to work (TM)".
> 
> If I find some time, I will try to setup some automated environment
> where I can run some experiments with different barrier locations.
> I can offer some rationale for putting it at the end of the function(s)
> that call mctl_mem_matches(), so hope that this fixes it.
> 
> Cheers,
> Andre
> 

Re: mdt_debug write

[Andre Przywara]

Hi Stephen,

On 28/11/2023 20:07, Stephen Graf wrote:
> Below is the consol log from trying to use mtd_debug write. It returned 
> immediately with a strange success message.
> 
> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
> /home/sysadmin/u-boot-sunxi-with-spl.bin
> file_to_flash: fread, size 0xf0000, n 0xf0000
> fread(): Success

interesting, I was under the impression that "mtd_debug write" would be 
the way to write to flash. In hindsight, the "debug" in that name should 
have probably put me off. Anyway, "cat" is probably not a good choice, 
"dd" is better, but it looks like "flashcp" (also part of mtdutils) is 
the go-to tool, since it does the required erasing automatically and 
also reportedly does some error detection. Can you please test this?
# flashcp u-boot-sunxi-with-spl.bin /dev/mtd0
I would test this on my end ASAP as well.

Do you feel like sending a patch to the U-Boot documentation to get this 
changed then?

Thanks,
Andre

> I then used the cat command to write to the SPI flash which took a few 
> seconds to execute:
> 
> root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin > 
> /dev/mtd0
> 
> 
> 
>>>>
>>>> I tried to follow the u-boot documentation on writing the SPI flash but
>>>> had problems with the write command.  When issued it returned
>>>> immediately. The erase command took about 5 sec to execute. I 
>>>> researched
>>>> use of mtd commands and got a suggestion to use cat instead, which 
>>>> worked.
>>>>
>>>> "root@orangepizero3:~# mtdinfo
>>>> Count of MTD devices:           1
>>>> Present MTD devices:            mtd0
>>>> Sysfs interface supported:      yes
>>>> root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
>>>> Erased 983040 bytes from address 0x00000000 in flash
>>>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000
>>>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>>>> file_to_flash: fread, size 0xf0000, n 0xf0000
>>>> fread(): Success
>>>>
>>>>
> 

Re: OrangePI Zero3 memory timing testing

[Andre Przywara]

Hi Stephen,

On 29/11/2023 18:45, Stephen Graf wrote:
> Some testing results:
> 
> With the default DRAM timing of 30x24=720, most often when my system 
> boots it comes up with DRAM 2G, but I have a 1G system. Once in a while 
> the boot shows 1G.  When it shows 2G the linux OS also shows 2G and 
> continuing does not make much sense.
> 
> On one boot where u-boot reported 1G the OS agreed and I ran memtester 
> successfully.
> 
> If I build u-boot with CONFIG_DRAM_CLK=792 (33*24=792) I have never seen 
> my system boot with anything other than DRAM 1G showing in u-boot. I ran 

Interesting, many thanks for the elaborate experiments!
To be fair, the timing parameters were from Xunlong's setup, so with 792 
MHz, but I remember that in my early testing this failed more often than 
not, so I reverted back to 720MHz. But I had different parameters back 
then, I believe. I will try to arrange some boot loop, to see how it 
fares with the 792 MHz, though I believe you that it's more stable.
If that works, I will send a v2 with the USB and the DRAM clock fixed.

Thanks again for testing and the report!

Cheers,
Andre

> memtester successfully and this system has been stable running linux 6.6.2.
> 
> Andre, if you can put together a few patches I can test them to see 
> which works.
> 
> If anyone else with different variations of the Zero3 would test with 
> the two DRAM timings and report results.
> 
> I also use the Zunlong image on occasion and it consistently shows 1G 
> and from my poking around I think it runs at a 792 clk.
> 
> 
> Console output with DRAM default:
> 
> U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 
> -0800) Allwinner Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  2 GiB
> 
> Last login: Wed Nov 29 09:35:15 PST 2023 on ttyS0
> root@orangepizero3:~# free -h
>                 total        used        free      shared  buff/cache 
> available
> Mem:           1.9Gi       139Mi       1.7Gi       360Ki        82Mi   
> 1.7Gi
> Swap:             0B          0B          0B
> 
> 
> U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 
> -0800) Allwinner Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  1 GiB
> 
> root@orangepizero3:~# free -h
>                 total        used        free      shared  buff/cache 
> available
> Mem:           917Mi       137Mi       766Mi       360Ki        79Mi   
> 780Mi
> Swap:             0B          0B          0B
> 
> 
> root@orangepizero3:~# memtester 700M 1
> memtester version 4.6.0 (64-bit)
> Copyright (C) 2001-2020 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
> 
> pagesize is 4096
> pagesizemask is 0xfffffffffffff000
> want 700MB (734003200 bytes)
> got  700MB (734003200 bytes), trying mlock ...locked.
> Loop 1/1:
>    Stuck Address       : ok
>    Random Value        : ok
>    Compare XOR         : ok
>    Compare SUB         : ok
>    Compare MUL         : ok
>    Compare DIV         : ok
>    Compare OR          : ok
>    Compare AND         : ok
>    Sequential Increment: ok
>    Solid Bits          : ok
>    Block Sequential    : ok
>    Checkerboard        : ok
>    Bit Spread          : ok
>    Bit Flip            : ok
>    Walking Ones        : ok
>    Walking Zeroes      : ok
>    8-bit Writes        : ok
>    16-bit Writes       : ok
> 
> Done.
> 
> Console output with DRAM clk 792:
> 
> 
> U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 21:34:46 
> -0800) Allwinner Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  1 GiB
> 
> root@orangepizero3:~# free -h
>                 total        used        free      shared  buff/cache 
> available
> Mem:           917Mi       134Mi       768Mi       360Ki        79Mi   
> 782Mi
> Swap:             0B          0B          0B
> 
> 
> root@orangepizero3:~# memtester 700M 1
> memtester version 4.6.0 (64-bit)
> Copyright (C) 2001-2020 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
> 
> pagesize is 4096
> pagesizemask is 0xfffffffffffff000
> want 700MB (734003200 bytes)
> got  700MB (734003200 bytes), trying mlock ...locked.
> Loop 1/1:
>    Stuck Address       : ok
>    Random Value        : ok
>    Compare XOR         : ok
>    Compare SUB         : ok
>    Compare MUL         : ok
>    Compare DIV         : ok
>    Compare OR          : ok
>    Compare AND         : ok
>    Sequential Increment: ok
>    Solid Bits          : ok
>    Block Sequential    : ok
>    Checkerboard        : ok
>    Bit Spread          : ok
>    Bit Flip            : ok
>    Walking Ones        : ok
>    Walking Zeroes      : ok
>    8-bit Writes        : ok
>    16-bit Writes       : ok
> 
> Done.
> 
> 
> On 2023-11-27 5:37 p.m., Andre Przywara wrote:
> 
>>
>> This symptom is pretty surely not directly related to the DRAM
>> frequency, it's caused by a missing barrier or delay *somewhere*.
>> People report that this is fixed by adding another "dsb();" at the
>> beginning of the mctl_mem_matches() function, but I don't have a good
>> explanation why exactly there, and would like to avoid submitting
>> patches that "just seem to work (TM)".
>>
>> If I find some time, I will try to setup some automated environment
>> where I can run some experiments with different barrier locations.
>> I can offer some rationale for putting it at the end of the function(s)
>> that call mctl_mem_matches(), so hope that this fixes it.
>>
>> Cheers,
>> Andre
>>

Re: mdt_debug write

[Stephen Graf]

Thank you for the update Andre.

The flashcp worked.  I rebooted without an SD card and the new u-boot 
started properly.

Now as to making a patch file, I will give it a try.  Keep in mind that 
when I started my working career the concept of patching was to shuffle 
a deck of IBM 80 column punched cards.

Console output:

root@orangepizero3:~# flashcp -v 
/home/sysadmin/u-boot-sunxi-with-spl.bin_with_792_clk /dev/mtd0
Erasing blocks: 206/206 (100%)
Writing data: 822k/822k (100%)
Verifying data: 822k/822k (100%)
root@orangepizero3:~#




On 2023-11-29 3:57 p.m., Andre Przywara wrote:
> Hi Stephen,
> 
> On 28/11/2023 20:07, Stephen Graf wrote:
>> Below is the consol log from trying to use mtd_debug write. It 
>> returned immediately with a strange success message.
>>
>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>> file_to_flash: fread, size 0xf0000, n 0xf0000
>> fread(): Success
> 
> interesting, I was under the impression that "mtd_debug write" would be 
> the way to write to flash. In hindsight, the "debug" in that name should 
> have probably put me off. Anyway, "cat" is probably not a good choice, 
> "dd" is better, but it looks like "flashcp" (also part of mtdutils) is 
> the go-to tool, since it does the required erasing automatically and 
> also reportedly does some error detection. Can you please test this?
> # flashcp u-boot-sunxi-with-spl.bin /dev/mtd0
> I would test this on my end ASAP as well.
> 
> Do you feel like sending a patch to the U-Boot documentation to get this 
> changed then?
> 
> Thanks,
> Andre
> 

Re: mdt_debug write

[Stephen Graf]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Is the attached patch file going in the right direction?

On 2023-11-29 3:57 p.m., Andre Przywara wrote:
> Hi Stephen,
> 
> On 28/11/2023 20:07, Stephen Graf wrote:
>> Below is the console log from trying to use mtd_debug write. It 
>> returned immediately with a strange success message.
>>
>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>> file_to_flash: fread, size 0xf0000, n 0xf0000
>> fread(): Success
> 
> interesting, I was under the impression that "mtd_debug write" would be 
> the way to write to flash. In hindsight, the "debug" in that name should 
> have probably put me off. Anyway, "cat" is probably not a good choice, 
> "dd" is better, but it looks like "flashcp" (also part of mtdutils) is 
> the go-to tool, since it does the required erasing automatically and 
> also reportedly does some error detection. Can you please test this?
> # flashcp u-boot-sunxi-with-spl.bin /dev/mtd0
> I would test this on my end ASAP as well.
> 
> Do you feel like sending a patch to the U-Boot documentation to get this 
> changed then?
> 
> Thanks,
> Andre
> 

[-- Attachment #2: --- docboardallwinnersunxi.rst .txt --]
[-- Type: text/plain, Size: 518 bytes --]

--- doc/board/allwinner/sunxi.rst       2023-11-28 21:31:06.844607403 -0800
+++ doc/board/allwinner/sunxi.rst_updated       2023-11-29 16:48:03.682352328 -0800
@@ -251,8 +251,7 @@

     # apt-get install mtd-utils
     # mtdinfo
-    # mtd_debug erase /dev/mtdX 0 0xf0000
-    # mtd_debug write /dev/mtdX 0 0xf0000 u-boot-sunxi-with-spl.bin
+    # flashcp -v u-boot-sunxi-with-spl.bin /dev/mtdX

 ``/dev/mtdX`` needs to be replaced with the respective device name, as listed
 in the output of ``mtdinfo``.

Re: OrangePI Zero3 memory timing testing

[Siarhei Siamashka]

Hello,

Please try to insert udelay() calls in addition to dsb() in the
mctl_mem_matches()
and see if this helps. I suspect that there's just no way to do
perfectly reliable
synchronization all the way from the CPU to DRAM and back in this particular
scenario (which involves wacky things, such as accessing aliased physical
memory addresses). So just having a generous delay may do the job and
solve all the timing issues.

Another comment is about the use of memtester program. It's actually not very
sensitive to memory reliability problems as-is.

Back in A10/A20 and H3 days, it was necessary to run memtester simultaneously
with a Mali GPU rendered spinning textured cube animation for best results:
        https://github.com/ssvb/lima-memtester
For example, a misconfigured H3 DRAM was showing no problems at all in
the memtester test at 624MHz, but couldn't survive memtester together with
the spinning textured cube until downclocked to 384MHz. Only aggressive
simultaneous access from both CPU and GPU really exposes reliability
problems. The other types of DMA transfers couldn't replace the GPU. It
was also possible to use the G2D accelerator instead of the Mali GPU, but
only when performing 90 degrees rotations. Doing simple non-rotated blits
with G2D was useless and couldn't expose reliability problems.

I would suggest to install 3D drivers (whatever is available for the
modern kernels
nowadays) and run some textured spinning cube demo together with memtester
before deciding that your DRAM configuration is alright.

On Thu, Nov 30, 2023 at 2:11 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> Hi Stephen,
>
> On 29/11/2023 18:45, Stephen Graf wrote:
> > Some testing results:
> >
> > With the default DRAM timing of 30x24=720, most often when my system
> > boots it comes up with DRAM 2G, but I have a 1G system. Once in a while
> > the boot shows 1G.  When it shows 2G the linux OS also shows 2G and
> > continuing does not make much sense.
> >
> > On one boot where u-boot reported 1G the OS agreed and I ran memtester
> > successfully.
> >
> > If I build u-boot with CONFIG_DRAM_CLK=792 (33*24=792) I have never seen
> > my system boot with anything other than DRAM 1G showing in u-boot. I ran
>
> Interesting, many thanks for the elaborate experiments!
> To be fair, the timing parameters were from Xunlong's setup, so with 792
> MHz, but I remember that in my early testing this failed more often than
> not, so I reverted back to 720MHz. But I had different parameters back
> then, I believe. I will try to arrange some boot loop, to see how it
> fares with the 792 MHz, though I believe you that it's more stable.
> If that works, I will send a v2 with the USB and the DRAM clock fixed.
>
> Thanks again for testing and the report!
>
> Cheers,
> Andre
>
> > memtester successfully and this system has been stable running linux 6.6.2.
> >
> > Andre, if you can put together a few patches I can test them to see
> > which works.
> >
> > If anyone else with different variations of the Zero3 would test with
> > the two DRAM timings and report results.
> >
> > I also use the Zunlong image on occasion and it consistently shows 1G
> > and from my poking around I think it runs at a 792 clk.
> >
> >
> > Console output with DRAM default:
> >
> > U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39
> > -0800) Allwinner Technology
> >
> > CPU:   Allwinner H616 (SUN50I)
> > Model: OrangePi Zero3
> > DRAM:  2 GiB
> >
> > Last login: Wed Nov 29 09:35:15 PST 2023 on ttyS0
> > root@orangepizero3:~# free -h
> >                 total        used        free      shared  buff/cache
> > available
> > Mem:           1.9Gi       139Mi       1.7Gi       360Ki        82Mi
> > 1.7Gi
> > Swap:             0B          0B          0B
> >
> >
> > U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39
> > -0800) Allwinner Technology
> >
> > CPU:   Allwinner H616 (SUN50I)
> > Model: OrangePi Zero3
> > DRAM:  1 GiB
> >
> > root@orangepizero3:~# free -h
> >                 total        used        free      shared  buff/cache
> > available
> > Mem:           917Mi       137Mi       766Mi       360Ki        79Mi
> > 780Mi
> > Swap:             0B          0B          0B
> >
> >
> > root@orangepizero3:~# memtester 700M 1
> > memtester version 4.6.0 (64-bit)
> > Copyright (C) 2001-2020 Charles Cazabon.
> > Licensed under the GNU General Public License version 2 (only).
> >
> > pagesize is 4096
> > pagesizemask is 0xfffffffffffff000
> > want 700MB (734003200 bytes)
> > got  700MB (734003200 bytes), trying mlock ...locked.
> > Loop 1/1:
> >    Stuck Address       : ok
> >    Random Value        : ok
> >    Compare XOR         : ok
> >    Compare SUB         : ok
> >    Compare MUL         : ok
> >    Compare DIV         : ok
> >    Compare OR          : ok
> >    Compare AND         : ok
> >    Sequential Increment: ok
> >    Solid Bits          : ok
> >    Block Sequential    : ok
> >    Checkerboard        : ok
> >    Bit Spread          : ok
> >    Bit Flip            : ok
> >    Walking Ones        : ok
> >    Walking Zeroes      : ok
> >    8-bit Writes        : ok
> >    16-bit Writes       : ok
> >
> > Done.
> >
> > Console output with DRAM clk 792:
> >
> >
> > U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 21:34:46
> > -0800) Allwinner Technology
> >
> > CPU:   Allwinner H616 (SUN50I)
> > Model: OrangePi Zero3
> > DRAM:  1 GiB
> >
> > root@orangepizero3:~# free -h
> >                 total        used        free      shared  buff/cache
> > available
> > Mem:           917Mi       134Mi       768Mi       360Ki        79Mi
> > 782Mi
> > Swap:             0B          0B          0B
> >
> >
> > root@orangepizero3:~# memtester 700M 1
> > memtester version 4.6.0 (64-bit)
> > Copyright (C) 2001-2020 Charles Cazabon.
> > Licensed under the GNU General Public License version 2 (only).
> >
> > pagesize is 4096
> > pagesizemask is 0xfffffffffffff000
> > want 700MB (734003200 bytes)
> > got  700MB (734003200 bytes), trying mlock ...locked.
> > Loop 1/1:
> >    Stuck Address       : ok
> >    Random Value        : ok
> >    Compare XOR         : ok
> >    Compare SUB         : ok
> >    Compare MUL         : ok
> >    Compare DIV         : ok
> >    Compare OR          : ok
> >    Compare AND         : ok
> >    Sequential Increment: ok
> >    Solid Bits          : ok
> >    Block Sequential    : ok
> >    Checkerboard        : ok
> >    Bit Spread          : ok
> >    Bit Flip            : ok
> >    Walking Ones        : ok
> >    Walking Zeroes      : ok
> >    8-bit Writes        : ok
> >    16-bit Writes       : ok
> >
> > Done.
> >
> >
> > On 2023-11-27 5:37 p.m., Andre Przywara wrote:
> >
> >>
> >> This symptom is pretty surely not directly related to the DRAM
> >> frequency, it's caused by a missing barrier or delay *somewhere*.
> >> People report that this is fixed by adding another "dsb();" at the
> >> beginning of the mctl_mem_matches() function, but I don't have a good
> >> explanation why exactly there, and would like to avoid submitting
> >> patches that "just seem to work (TM)".
> >>
> >> If I find some time, I will try to setup some automated environment
> >> where I can run some experiments with different barrier locations.
> >> I can offer some rationale for putting it at the end of the function(s)
> >> that call mctl_mem_matches(), so hope that this fixes it.
> >>
> >> Cheers,
> >> Andre
> >>

Re: mdt_debug write

[Andre Przywara]

Hi Stephen,

On 30/11/2023 01:13, Stephen Graf wrote:
> Is the attached patch file going in the right direction?

yes, thanks, the change itself looks alright, but it needs to be:
- in a separate email, with a descriptive subject, prefixed by [PATCH]
- have the diff inline, not as an attachment (to allow easy commenting 
in an email thread)
- have a Signed-off-by: tag with your name and email address. This is to 
signify that the change is an original one made by you and you are happy 
to submit this under the (GPL) license conditions.
- an explanation *why* this change is required (mtd_debug write being 
not reliable, etc)
- sent to the U-Boot list and the maintainer (me)

Look at the U-Boot mailing list (archive) for examples.
"git format-patch" creates everything in the right format (mbox), and 
"git send-email" will send this via an SMTP server you point it to. Or 
you import this into your client.

If you could try this (with the Signed-off-by being the most important 
change), I am happy to submit this with the next push.

Thanks,
Andre

> 
> On 2023-11-29 3:57 p.m., Andre Przywara wrote:
>> Hi Stephen,
>>
>> On 28/11/2023 20:07, Stephen Graf wrote:
>>> Below is the console log from trying to use mtd_debug write. It 
>>> returned immediately with a strange success message.
>>>
>>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 
>>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>>> file_to_flash: fread, size 0xf0000, n 0xf0000
>>> fread(): Success
>>
>> interesting, I was under the impression that "mtd_debug write" would 
>> be the way to write to flash. In hindsight, the "debug" in that name 
>> should have probably put me off. Anyway, "cat" is probably not a good 
>> choice, "dd" is better, but it looks like "flashcp" (also part of 
>> mtdutils) is the go-to tool, since it does the required erasing 
>> automatically and also reportedly does some error detection. Can you 
>> please test this?
>> # flashcp u-boot-sunxi-with-spl.bin /dev/mtd0
>> I would test this on my end ASAP as well.
>>
>> Do you feel like sending a patch to the U-Boot documentation to get 
>> this changed then?
>>
>> Thanks,
>> Andre
>>

[PATCH 1/1] correct documentation for SPI flashing

[Stephen Graf]

The mtd_debug write does not work in this context. The flashcp command does work, provides
both the erase and write functions and with the verbose option gives good feedback.

Signed-off-by: Stephen Graf <stephen.graf@gmail.com>
---
  doc/board/allwinner/sunxi.rst | 3 +--
  1 file changed, 1 insertions(+), 2 deletions(-)

diff --git a/doc/board/allwinner/sunxi.rst b/doc/board/allwinner/sunxi.rst
index 797222d8d3..d0c89b956b 100644
--- a/doc/board/allwinner/sunxi.rst
+++ b/doc/board/allwinner/sunxi.rst
@@ -251,8 +251,7 @@ the SPI flash content from Linux, using the `MTD utils`_::

      # apt-get install mtd-utils
      # mtdinfo
-    # mtd_debug erase /dev/mtdX 0 0xf0000
-    # mtd_debug write /dev/mtdX 0 0xf0000 u-boot-sunxi-with-spl.bin
+    # flashcp -v u-boot-sunxi-with-spl.bin /dev/mtdX

  ``/dev/mtdX`` needs to be replaced with the respective device name, as listed
  in the output of ``mtdinfo``.
---

On 2023-11-30 4:27 p.m., Andre Przywara wrote:
> Hi Stephen,
> 
> On 30/11/2023 01:13, Stephen Graf wrote:
>> Is the attached patch file going in the right direction?
> 
> yes, thanks, the change itself looks alright, but it needs to be:
> - in a separate email, with a descriptive subject, prefixed by [PATCH]
> - have the diff inline, not as an attachment (to allow easy commenting in an email thread)
> - have a Signed-off-by: tag with your name and email address. This is to signify that the change is an original one made by you and you are happy to submit this under the (GPL) license conditions.
> - an explanation *why* this change is required (mtd_debug write being not reliable, etc)
> - sent to the U-Boot list and the maintainer (me)
> 
> Look at the U-Boot mailing list (archive) for examples.
> "git format-patch" creates everything in the right format (mbox), and "git send-email" will send this via an SMTP server you point it to. Or you import this into your client.
> 
> If you could try this (with the Signed-off-by being the most important change), I am happy to submit this with the next push.
> 
> Thanks,
> Andre
> 
>>
>> On 2023-11-29 3:57 p.m., Andre Przywara wrote:
>>> Hi Stephen,
>>>
>>> On 28/11/2023 20:07, Stephen Graf wrote:
>>>> Below is the console log from trying to use mtd_debug write. It returned immediately with a strange success message.
>>>>
>>>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 /home/sysadmin/u-boot-sunxi-with-spl.bin
>>>> file_to_flash: fread, size 0xf0000, n 0xf0000
>>>> fread(): Success
>>>
>>> interesting, I was under the impression that "mtd_debug write" would be the way to write to flash. In hindsight, the "debug" in that name should have probably put me off. Anyway, "cat" is probably not a good choice, "dd" is better, but it looks like "flashcp" (also part of mtdutils) is the go-to tool, since it does the required erasing automatically and also reportedly does some error detection. Can you please test this?
>>> # flashcp u-boot-sunxi-with-spl.bin /dev/mtd0
>>> I would test this on my end ASAP as well.
>>>
>>> Do you feel like sending a patch to the U-Boot documentation to get this changed then?
>>>
>>> Thanks,
>>> Andre
>>>

Re: [PATCH 1/1] correct documentation for SPI flashing

[Andre Przywara]

On Fri, 1 Dec 2023 10:50:39 -0800
Stephen Graf <stephen.graf@gmail.com> wrote:

Hi Stephen,

thanks for the patch, and you almost nailed it, some little things:

- The patch should start a new thread on the list, so do not reply to
  an existing discussion or (un)related patch. This avoids the patch
  getting buried in longish threads and helps tools like patchworks to
  find and process it. Also please just send the patch, and avoid any
  quoted text from previous discussions outside of the commit message.
- Please prefix your commit message with some context tags, in this
  case "sunxi: ", so that people scanning the list can ignore it if
  it's outside their scope of interest.
- Please limit commit messages to 75 characters per line.
  $ scripts/checkpatch.pl
  0001-correct_documentation_for_SPI_flashing.patch
  will do some checks on the patch and would report this.

Anyway, those are minor things, I will just fix them while committing.

> The mtd_debug write does not work in this context. The flashcp command does work, provides
> both the erase and write functions and with the verbose option gives good feedback.
> 
> Signed-off-by: Stephen Graf <stephen.graf@gmail.com>

Reviewed-by: Andre Przywara <andre.przywara@arm.com>

Cheers,
Andre

> ---
>   doc/board/allwinner/sunxi.rst | 3 +--
>   1 file changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/board/allwinner/sunxi.rst b/doc/board/allwinner/sunxi.rst
> index 797222d8d3..d0c89b956b 100644
> --- a/doc/board/allwinner/sunxi.rst
> +++ b/doc/board/allwinner/sunxi.rst
> @@ -251,8 +251,7 @@ the SPI flash content from Linux, using the `MTD utils`_::
> 
>       # apt-get install mtd-utils
>       # mtdinfo
> -    # mtd_debug erase /dev/mtdX 0 0xf0000
> -    # mtd_debug write /dev/mtdX 0 0xf0000 u-boot-sunxi-with-spl.bin
> +    # flashcp -v u-boot-sunxi-with-spl.bin /dev/mtdX
> 
>   ``/dev/mtdX`` needs to be replaced with the respective device name, as listed
>   in the output of ``mtdinfo``.
> ---
> 
> On 2023-11-30 4:27 p.m., Andre Przywara wrote:
> > Hi Stephen,
> > 
> > On 30/11/2023 01:13, Stephen Graf wrote:  
> >> Is the attached patch file going in the right direction?  
> > 
> > yes, thanks, the change itself looks alright, but it needs to be:
> > - in a separate email, with a descriptive subject, prefixed by [PATCH]
> > - have the diff inline, not as an attachment (to allow easy commenting in an email thread)
> > - have a Signed-off-by: tag with your name and email address. This is to signify that the change is an original one made by you and you are happy to submit this under the (GPL) license conditions.
> > - an explanation *why* this change is required (mtd_debug write being not reliable, etc)
> > - sent to the U-Boot list and the maintainer (me)
> > 
> > Look at the U-Boot mailing list (archive) for examples.
> > "git format-patch" creates everything in the right format (mbox), and "git send-email" will send this via an SMTP server you point it to. Or you import this into your client.
> > 
> > If you could try this (with the Signed-off-by being the most important change), I am happy to submit this with the next push.
> > 
> > Thanks,
> > Andre
> >   
> >>
> >> On 2023-11-29 3:57 p.m., Andre Przywara wrote:  
> >>> Hi Stephen,
> >>>
> >>> On 28/11/2023 20:07, Stephen Graf wrote:  
> >>>> Below is the console log from trying to use mtd_debug write. It returned immediately with a strange success message.
> >>>>
> >>>> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000 /home/sysadmin/u-boot-sunxi-with-spl.bin
> >>>> file_to_flash: fread, size 0xf0000, n 0xf0000
> >>>> fread(): Success  
> >>>
> >>> interesting, I was under the impression that "mtd_debug write" would be the way to write to flash. In hindsight, the "debug" in that name should have probably put me off. Anyway, "cat" is probably not a good choice, "dd" is better, but it looks like "flashcp" (also part of mtdutils) is the go-to tool, since it does the required erasing automatically and also reportedly does some error detection. Can you please test this?
> >>> # flashcp u-boot-sunxi-with-spl.bin /dev/mtd0
> >>> I would test this on my end ASAP as well.
> >>>
> >>> Do you feel like sending a patch to the U-Boot documentation to get this changed then?
> >>>
> >>> Thanks,
> >>> Andre
> >>>  
>