usb3 device not detected on usb2 port
I am using an orangepizero3 and trying to boot from spi flash and then a usb3 SSD on usb-1 port, which is usb2. U-boot does not detect the usb3 SSD drive. I have been booting Armbian regularly from an old usb2 hard disk drive in the same way. After Armbian starts the usb3 SSD drive is detected by the os and works properly in the os. Some console log output below shows the issue. Has anyone experienced this? *** boot from SD card U-Boot 2024.01-rc5-armbian (Jan 13 2024 - 14:13:09 +) 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@402: 0 Loading Environment from FAT... Unable to use mmc 0:1... In:serial@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: Unsupported value 13, using default (13) Unsupported value 13, using default (13) eth0: ethernet@502using 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 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 Autoboot in 1 seconds, press to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr *** test usb3 SSD in usb-1 after boot root@orangepizero3:~# lsusb Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@orangepizero3:~# mount /dev/sda1 /mnt mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload. root@orangepizero3:~# ls -alh /mnt total 88K drwxr-xr-x 19 root root 4.0K Jan 29 21:37 . drwxr-xr-x 19 root root 4.0K Jan 16 12:29 .. lrwxrwxrwx 1 root root7 Jan 13 02:56 bin -> usr/bin drwxr-xr-x 3 root root 4.0K Jan 29 21:39 boot drwxr-xr-x 2 root root 4.0K Jan 29 21:30 dev drwxr-xr-x 96 root root 4.0K Jan 29 21:37 etc drwxr-xr-x 2 root root 4.0K Dec 9 13:08 home lrwxrwxrwx 1 root root 34 Jan 29 21:32 initrd.img -> boot/initrd.img-6.7.2-edge-sunxi64 lrwxrwxrwx 1 root root 34 Jan 29 21:32 initrd.img.old -> boot/initrd.img-6.7.2-edge-sunxi64 lrwxrwxrwx 1 root root7 Jan 13 02:56 lib -> usr/lib drwx-- 2 root root 16K Jan 29 21:37 lost+found drwxr-xr-x 2 root root 4.0K Jan 13 02:56 media drwxr-xr-x 2 root root 4.0K Jan 13 02:56 mnt drwxr-xr-x 2 root root 4.0K Jan 13 02:56 opt drwxr-xr-x 2 root root 4.0K Jan 13 02:56 proc drwx-- 3 root root 4.0K Jan 29 21:34 root drwxr-xr-x 4 root root 4.0K Jan 29 21:38 run lrwxrwxrwx 1 root root8 Jan 13 02:56 sbin -> usr/sbin drwxrwxr-x 2 root root 4.0K Jan 29 21:30 selinux drwxr-xr-x 2 root root 4.0K Jan 13 02:56 srv drwxr-xr-x 2 root root 4.0K Dec 9 13:08 sys drwxrwxrwt 2 root root 4.0K Jan 13 02:57 tmp drwxr-xr-x 11 root root 4.0K Jan 13 02:56 usr drwxr-xr-x 12 root root 4.0K Jan 29 21:30 var lrwxrwxrwx 1 root root 31 Jan 29 21:32 vmlinuz -> boot/vmlinuz-6.7.2-edge-sunxi64 lrwxrwxrwx 1 root root 31 Jan 29 21:32 vmlinuz.old -> boot/vmlinuz-6.7.2-edge-sunxi64 *** boot from spi flash and usb2 hard drive in usb-1 U-Boot 2024.01-rc5-armbian (Dec 25 2023 - 16:25:36 -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@402: 0 Loading Environment from SPIFlash... SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: Unsupported value 13, using default (13) Unsupported value 13, using default (13) eth0: ethernet@502using 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... 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 Autoboot in 2 seconds, press to stop Card did not
Re: [PATCH v2 0/3] sunxi: add OrangePi Zero 3 board support
I have tested a newly built u-boot with the patches you provided and it works well. It is the same configuration as what I have been testing with for the last few weeks. I loaded the U-boot to SPI flash and tested with the SD card removed from the system and put in a USB card reader. The output for that test is below. For completeness you might want to mention that another difference between the zero2 and zero3 is the emac phy going from Realtek to Motorcomm. Thank you for fixing my patch attempt. It is the first one I have ever done. Thank you also for your patience with my fumbling attempts. I have learned a lot from you in the last two weeks. U-Boot SPL 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -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 0x4a0b2828, 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 = 0x4a00 INFO:SPSR = 0x3c9 INFO:Changed devicetree. U-Boot 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -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@402: 0 Loading Environment from SPIFlash... SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 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 1052 bytes read in 1 ms (1 MiB/s) ## Executing script at 4fc0 Card did not respond to voltage select! : -110 ** Bad device specification mmc 0 ** 19472 bytes read in 3 ms (6.2 MiB/s) No FDT memory address configured. Please configure the FDT address via "fdt addr " command. Aborting! 7088139 bytes read in 324 ms (20.9 MiB/s) 22491144 bytes read in 1025 ms (20.9 MiB/s) Moving Image from 0x4008 to 0x4020, end=4180 ## Loading init Ramdisk from Legacy Image at 4ff0 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size:7088075 Bytes = 6.8 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 Working FDT set to 4fa0 Loading Ramdisk to 4993d000, end 49fff7cb ... OK Loading Device Tree to 49935000, end 4993cc0f ... OK Working FDT set to 49935000 Starting kernel ... Welcome to Debian GNU/Linux 12 (bookworm)! On 2023-12-03 4:59 p.m., Andre Przywara wrote: A small update for the OrangePi Zero 3 support series. This fixes USB support, and upgrades the DRAM clock to 792, for better stability (as the other DRAM parameters were tailored to that frequency). I added the tags on the way. Please test! = 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
[PATCH 1/1] correct documentation for SPI flashing
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 --- 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 0xf -# mtd_debug write /dev/mtdX 0 0xf 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 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf 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
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 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf 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 --- 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 0xf -# mtd_debug write /dev/mtdX 0 0xf 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: mdt_debug write
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 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf 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
OrangePI Zero3 memory timing testing
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 totalusedfree shared buff/cache available Mem: 1.9Gi 139Mi 1.7Gi 360Ki82Mi 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 totalusedfree shared buff/cache available Mem: 917Mi 137Mi 766Mi 360Ki79Mi 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 0xf000 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 totalusedfree shared buff/cache available Mem: 917Mi 134Mi 768Mi 360Ki79Mi 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 0xf000 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
mdt_debug write
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 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf 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 0xf Erased 983040 bytes from address 0x in flash root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf fread(): Success
Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
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 = 0x dram_para1 = 0x30fa dram_para2 = 0x 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 = 0x dram_para1 = 0x30fa dram_para2 = 0x 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 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 0xf Erased 983040 bytes from address 0x in flash root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf 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
Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
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 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 0xf Erased 983040 bytes from address 0x in flash root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf 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 = 0x4a00 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@402: 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@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... Device NOT ready Request Sense returned 02 3A 00 Devic
Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
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 0xf Erased 983040 bytes from address 0x in flash root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf 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 = 0x4a00 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@402: 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@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 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 4fc0 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 4fc0 19472 bytes read in 3 ms (6.2 MiB/s) Working FDT set to 4fa0 7088139 bytes read in 326 ms (20.7 MiB/s) 22491144 bytes read in 1031 ms (20.8 MiB/s) Moving Image from 0x4008 to 0x4020, end=4180 ## Loading init Ramdisk from Legacy Image at 4ff0 ... Image Name: uInitrd Image Type:
Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
0.00] 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 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
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=0x CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 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=40 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-9-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@402: 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@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 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 4fc0 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 " command. Aborting! 4203 bytes read in 4 ms (1 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 4500 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 0x4008 to 0x4020, end=4180 ## Loading init Ramdisk from Legacy Image at 4ff0 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size:7088075 Bytes = 6.8 MiB Load Address: Entry Point: 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 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 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
Re: orangepi zero3
I tested a u-boot build with the emac timing changes you pointed out and with CONFIG_DRAM_CLK=792. It looks like this configuration and dts changes works with both 100Mb and 1Gb switches. I am struggling to get something to actually load. Is there an easy way to get a debian image onto the sd card so that u-boot can actually load something. Console output: U-Boot SPL 2024.01-rc3-9-g9e53e45292-dirty (Nov 24 2023 - 18:47:11 +) DRAM: 1024 MiB Trying to boot from MMC1 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 0x4a0b2750, 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 = 0x4a00 INFO: SPSR = 0x3c9 INFO: Changed devicetree. U-Boot 2024.01-rc3-9-g9e53e45292-dirty (Nov 24 2023 - 18:47:11 +) 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@402: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using 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@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 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 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... No EFI system partition No EFI system partition Failed to persist EFI variables BootOrder not defined EFI boot manager: Cannot load any image Device 0: unknown device BOOTP broadcast 1 DHCP client bound to address 192.168.1.63 (4 ms) *** Warning: no boot file name; using 'C0A8013F.img' Using ethernet@502 device TFTP from server 192.168.1.253; our IP address is 192.168.1.63 Filename 'C0A8013F.img'. Load address: 0x4200 Loading: T T T On 2023-11-23 4:11 p.m., Andre Przywara wrote: On Thu, 23 Nov 2023 11:12:25 -0800 Stephen Graf wrote: Hi Stephen, Thank you for your reply. Thanks for coming back. Please keep the list(s) on CC:, as this is also interesting for others, and more eyes help to find issues faster. CC:ing Piotr and Mikhail, who were debugging the LPDDR4 DRAM setup before. I built u-boot with the proposed changes and it seems to work. It does however report "DRAM: 2048 MiB" although I have a board with only 1G. Ah, that's a good report! I actually saw the same issue (reporting 8GB instead of 4GB), and my hunch is that it's related to some missing barriers or delays, as seen on other boards. Can you try to add a "dsb();" to the beginning of arch/arm/mach-sunxi/dram_helpers.c:mctl_mem_matches(), before the first writel()? I am still not convinced this is the right place to put the barrier, but it would confirm that this is the issue. Also I didn't see this effect consistently, so did this happen for you every time? Another thing you could try is to increase the voltage to 1150mV, this is what Piotr needed for reliable operation. When I built u-boot with the config that I used it reported 1G correctly. The Zunlong distros do have different images for various RAM configurations. Yeah, I saw this, and I hope we can avoid this. I am not sure if you are the first one with a 1GB board, so your testing is definitely helpful. I do not know enough about the details to determine which differences in the two configs result in the change. I am more than willing to test and report if someone can direct me a bit. sysadmin@ubuntu:~/defconfgs$ diff sg.txt andre.txt (please use "diff -u", that's easier to read and people are more used to its output style) 9d8 < CONFIG_DRAM_SUN50I_H616_TPR0=0x0 11,13c10,12 < CONFIG_DRAM_SUN50I_H616_TPR10=0x402f0663 < CONFIG_DRAM_SUN50I_H616_TPR11=0x24242323 < CONFIG_DRAM_SUN50I_H616_TPR12=0x0e0e0e0e --- > CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663 > CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624 > CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f I don't think those minor timing differences matter much, but you can try to experiment with both set of values. 16d14 < CONFIG_DRAM_CLK=792 Not specifying DRAM_CLK
add orangepi zero3 to u-boot
I have been able to build a working (tested on my orangepi zero3 1G) u-boot for the orangepi zero3 with the following defconfig. Would it be possible to add this config to the working boards. I would test it again with an official build. The dtb/dts is in linux 6.6 and in u-boot. The H618 processor is software compatible with the H616 and the zero3 board is very similar to the zero2 with the exception of DDR3 replaced with LPDDR4 and the Realtek phy with Motorcomm. 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=0x CONFIG_DRAM_SUN50I_H616_TPR0=0x0 CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 CONFIG_DRAM_SUN50I_H616_TPR10=0x402f0663 CONFIG_DRAM_SUN50I_H616_TPR11=0x24242323 CONFIG_DRAM_SUN50I_H616_TPR12=0x0e0e0e0e CONFIG_MACH_SUN50I_H616=y CONFIG_SUNXI_DRAM_H616_LPDDR4=y CONFIG_DRAM_CLK=792 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=40 CONFIG_SPI_FLASH_MACRONIX=y CONFIG_PHY_MOTORCOMM=y CONFIG_SUN8I_EMAC=y CONFIG_SPI=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_MUSB_GADGET=y CONFIG_AXP313_POWER=y CONFIG_AXP_DCDC3_VOLT=1100 CONFIG_CMD_BOOTZ=y
orangepi zero3
I have been able to build a working (on my orangepi zero3 1G) u-boot for the orangepi zero3 with the following defconfig. Would it be possible to add this config to the working boards. I would test it again with an official build. The dtb/dts is in linux and in u-boot. The H618 processor is software compatible with the H616 and the zero3 board is very similar to the zero2 with the exception of DDR3 replaced with LPDDR4 and the Realtek phy with Motorcomm. 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=0x CONFIG_DRAM_SUN50I_H616_TPR0=0x0 CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 CONFIG_DRAM_SUN50I_H616_TPR10=0x402f0663 CONFIG_DRAM_SUN50I_H616_TPR11=0x24242323 CONFIG_DRAM_SUN50I_H616_TPR12=0x0e0e0e0e CONFIG_MACH_SUN50I_H616=y CONFIG_SUNXI_DRAM_H616_LPDDR4=y CONFIG_DRAM_CLK=792 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=40 CONFIG_SPI_FLASH_MACRONIX=y CONFIG_PHY_MOTORCOMM=y CONFIG_SUN8I_EMAC=y CONFIG_SPI=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_MUSB_GADGET=y CONFIG_AXP313_POWER=y CONFIG_AXP_DCDC3_VOLT=1100 CONFIG_CMD_BOOTZ=y
