ag123 Posted April 19 Author Share Posted April 19 ok just an update, I managed to get past that '1.5GB' issue the hack is done in u-boot, but the bad news is that that alone won't fix things: Spoiler U-Boot SPL 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) sunxi_board_init DRAM:sunxi_dram_initdetected memsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b4330, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 U-Boot 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 58 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... 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... 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... Found U-Boot script /boot/boot.scr 3259 bytes read in 4 ms (794.9 KiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 205 bytes read in 4 ms (49.8 KiB/s) 32823 bytes read in 8 ms (3.9 MiB/s) Working FDT set to 4fa00000 4203 bytes read in 7 ms (585.9 KiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 10936176 bytes read in 457 ms (22.8 MiB/s) 23570440 bytes read in 982 ms (22.9 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41910000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 10936112 Bytes = 10.4 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 49592000, end 49ffff30 ... OK Loading Device Tree to 0000000049521000, end 0000000049591fff ... OK Working FDT set to 49521000 Starting kernel ... [ 2.144698] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down [ 2.153147] reboot: HARDWARE PROTECTION shutdown (Temperature too high) [ 2.192185] reboot: Power down This gpu over temperature is nonsense, the chip is hardly warm and this same image boots just fine on a 2GB device with the 'standard' u-boot. It'd seem that some other things is at play here, e.g. that the registers for 1.5GB model are after all different and may need a different DTS configuration. I don't have a solution to go forward for now for 1.5GB devices, configuring DTS takes much more than this little hack, in the sense that we'd not know if this gpu thermal thing is the only odd thing or that there are other things that needs to be fixed as well. -- for those who insist if you would like to test this solution, the attached file is the modified u-boot compiled from https://source.denx.de/u-boot/u-boot https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1353 the function arch / arm /mach-sunxi /dram_sun50i_h616.c function mctl_calc_size() is modified as: static unsigned long mctl_calc_size(const struct dram_config *config) { u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ unsigned long long memsz = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; log_info("detected memsize %d M\n", (int)(memsz >> 20)); /* 1.5 GB hardcoded */ memsz = 2048UL * 1024UL * 1024UL * 3 / 4; return memsz; } i.e. that 1.5GB is *hardcoded*, obviously this won't be appropriate for most boards except in particular case of 1.5GB. Initially, i placed an if statement that says if the detected ram is 2GB say that it is 1.5GB, that is bad as well as then 2GB boards will simply read 1.5GB. however, during tests, I noted that the detected dram size varies between 2 GB and 4 GB. my guess is there are timing issues associated with the 1.5GB dram chip, hence I resorted to hard coding which does not bother how much dram is really detected. if you prefer to build u-boot from sources, follow instructions from here: https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html To use this modified u-boot, the best practice is to start with / use an image that is known to work on 1GB / 2GB / 4GB Orange Pi Zero 3 boards. update: the modified u-boot is in this repository https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ you can download the u-boot-SPL.bin from there. assuming that your image SD card is mounted at /dev/sdX, you can backup your existing u-boot e.g. sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024 that should backup the u-boot in your device to u-boot-backup.bin then to write the modified u-boot into the SD card it is (be sure that you are writing to the correct device ! mistakes here can corrupt your existing hard disks / storage) sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8 it may be possible to write that to an existing image file (do backup your image file beforehand) dd if=u-boot-sunxi-with-spl.bin of=file.img bs=1024 seek=8 conv=notrunc but that I've not tried this. I've created a 'sd image u-boot patcher' uploaded here in github gist: https://gist.github.com/ag88/cebfcd2bc1b413d2a0d43dafa6b572f0 usage: sdimage-u-boot-patcher.py [-h] [--nobak] [--ignimgsize] [--bkname BKNAME] image uboot_bin patch u-boot binary into image positional arguments: image image file uboot_bin u-boot bin file options: -h, --help show this help message and exit --nobak do not backup u-boot SPL from image --ignimgsize ignore image size check --bkname BKNAME u-boot SPL backup file name you need python3 to use that 'sd image u-boot patcher' https://www.python.org/downloads/release/python-3123/ run it as python3 sdimage-u-boot-patcher.py imagefile.img uboot-spl.bin This python script will first extract and backup the u-boot bin image from the image into u-boot-SPL-backup.bin in the current directory. This helps in case something goofs up, you can try restoring it with python3 sdimage-u-boot-patcher.py --nobak imagefile.img u-boot-SPL-backup.bin it is a console app, which means that for Windows users, it'd need to be run in a Cmd prompt window. note: I've not tried running this in Windows, only tested in Linux. This may help for 'Windows' users who may not have access to commands like 'dd' which is mainly available in unix, Linux. This is so that you can patch the image file directly and perhaps use Balena etcher https://etcher.balena.io/ or Rufus https://rufus.ie/en/ to write the image to an SD card / usb drive. In linux, it is found that the sdimage-u-boot-patcher script can actually update /dev/sdX directly. But that it it cannot determine the image size as it is a device and normally it'd need to be run as root. Hence, I've added a --ignimgsize ignore image size check flag for those who wanted to use it that way. e.g. sudo python3 sdimage-u-boot-patcher.py --ignimgsize /dev/sdX uboot-spl.bin This python script will first extract and backup the u-boot bin image from the image into u-boot-SPL-backup.bin in the current directory. This helps in case something goofs up, you can try restoring it with sudo python3 sdimage-u-boot-patcher.py --ignimgsize --nobak /dev/sdX u-boot-SPL-backup.bin this is 'slightly safer' than using dd as sdimage-u-boot-patcher actually validates the image format (it look for signatures for a master boot record this can still be confused with a regular disk, and a signature for u-boot at around 8k. it would prompt that the image does not appear to be valid linux image if it either can't find the master boot record 1st sector and the u-boot signature at 8k. you can then stop the patch by pressing control-c or answering 'n' when prompted to continue. for a valid image, it also verifies that the u-boot bin file should not overwrite into the root partition and note this is caveat emptor (let the user beware, use at your own risk), there is no assurance if after all it fixes anything or break other things. 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted April 20 Share Posted April 20 Thanks @ag123 for your help! I tried your u-boot image and I got a different error, probably because Debian image I have is different than yours, so I have to restore u-boot from backup. This is console output I got: Quote U-Boot SPL 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) sunxi_board_init DRAM:sunxi_dram_initdetected memsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b4330, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 U-Boot 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 58 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... 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... 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... Found U-Boot script /boot/boot.scr 3636 bytes read in 2 ms (1.7 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 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 2 ms (2 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 12128483 bytes read in 502 ms (23 MiB/s) 9419112 bytes read in 390 ms (23 MiB/s) Uncompressing Kernel Image to 0 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: 12128419 Bytes = 11.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree SCRIPT FAILED: continuing... No EFI system partition No EFI system partition Failed to persist EFI variables No EFI system partition Failed to persist EFI variables No EFI system partition Failed to persist EFI variables Loading Boot0000 'mmc 0' failed EFI boot manager: Cannot load any image Device 0: unknown device ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.missing environment variable: pxeuuid Retrieving file: pxelinux.cfg/01-02-00-d4-1d-f4-77 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/00000000 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/0000000 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/000000 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/00000 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/0000 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/000 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/00 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/0 ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/default-arm-sunxi-sunxi ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/default-arm-sunxi ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/default-arm ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Retrieving file: pxelinux.cfg/default ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.Config file not found ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.ethernet@5020000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! The remote end did not respond in time.=> I see some differences from u-boot of my Debian image, but I am not able to see what is wrong or missing. Here is normal console log to compare: Quote U-Boot SPL 2021.07-orangepi (Sep 28 2023 - 09:25:54 +0800) DRAM: 1536 MiB Trying to boot from MMC1 NOTICE: BL31: v2.9(debug):84de50c7 NOTICE: BL31: Built : 11:01:01, Sep 25 2023 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a082628, 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 2021.07-orangepi (Sep 28 2023 - 09:25:54 +0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 I2C: ready DRAM: 1.5 GiB MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Net: No ethernet found. starting USB... No working controllers found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 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 mmc 205 bytes read in 0 ms 39931 bytes read in 5 ms (7.6 MiB/s) 4203 bytes read in 3 ms (1.3 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 12128483 bytes read in 1001 ms (11.6 MiB/s) 9419112 bytes read in 778 ms (11.5 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: 12128419 Bytes = 11.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Loading Ramdisk to 4946e000, end 49fff0a3 ... OK Loading Device Tree to 00000000493fb000, end 000000004946dfff ... OK Starting kernel ... Orange Pi 1.0.2 Bookworm ttyS0 orangepizero3 login: 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted April 20 Author Share Posted April 20 @voapilro oops, did you backup your original u-boot from the image? to restore this, you would need that u-boot backup. some u-boot bin files are customized with particular ways to start the kernel and that stored into u-boot in that 1st 1 meg or so. For the standard u-boot, it uses files in /boot/boot.cmd or /boot/boot.scr in the Linux root partition to boot linux, that is normally the case for Armbian distributions btw that scary prompt is the u-boot command prompt / shell https://docs.u-boot.org/en/latest/usage/index.html https://linux-sunxi.org/U-Boot https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html try ls mmc 0 [directory e.g. /, /boot etc] and 'help' in the u-boot command prompt, confusing at least if you can post the contents of /boot/boot.cmd in the root partition, normally those are the commands to boot linux from u-boot. If that is goofy (incorrect), linux will not boot. Those bunch of u-boot commands are critical to start linux. normally that can be compiled into another file called /boot/boot.scr (that is for an older version of u-boot) u-boot reads that /boot/boot.cmd (or /boot/boot.scr) which contains the commands to start linux with the kernel image, ram disk and the device tree binary (also called the flattened device tree FDT) this is so that changing the kernel probably means only editing /boot/boot.cmd (and generate /boot/boot.scr if needed) 0 Quote Link to comment Share on other sites More sharing options...
c0rnelius Posted April 20 Share Posted April 20 Try adding a delay and see if that corrects the DRAM detection. https://github.com/armbian/build/blob/main/patch/u-boot/v2024.01/board_bananapim4zero/006-sunxi-restore-modified-memory.patch#L149 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted April 20 Share Posted April 20 2 hours ago, ag123 said: oops, did you backup your original u-boot from the image? to restore this, you would need that u-boot backup. some u-boot bin files are customized with particular ways to start the kernel and that stored into u-boot in that 1st 1 meg or so. @ag123 Yes, I did a backup of original u-boot before testing, and restored it successfully after testing. 2 hours ago, ag123 said: For the standard u-boot, it uses files in /boot/boot.cmd or /boot/boot.scr in the Linux root partition to boot linux, that is normally the case for Armbian distributions This is a directory listing of my /boot folder: Quote -rw-rw-r-- 1 root root 230456 Sep 28 2023 boot.bmp -rw-rw-r-- 1 root root 3564 Sep 28 2023 boot.cmd -rw-rw-r-- 1 root root 3636 Sep 28 2023 boot.scr -rw-r--r-- 1 root root 206846 Sep 28 2023 config-6.1.31-sun50iw9 lrwxrwxrwx 1 root root 19 Sep 28 2023 dtb -> dtb-6.1.31-sun50iw9 drwxr-xr-x 3 root root 4096 Sep 28 2023 dtb-6.1.31-sun50iw9 lrwxrwxrwx 1 root root 23 Sep 28 2023 Image -> vmlinuz-6.1.31-sun50iw9 -rw-r--r-- 1 root root 12128419 Apr 15 17:16 initrd.img-6.1.31-sun50iw9 -rwxrwxr-x 1 root root 1152056 Sep 28 2023 logo.bmp -rw-rw-r-- 1 root root 205 Apr 20 10:41 orangepiEnv.txt -rw-rw-r-- 1 root root 1542 Sep 28 2023 orangepi_first_run.txt.template -rw-r--r-- 1 root root 3544938 Sep 28 2023 System.map-6.1.31-sun50iw9 lrwxrwxrwx 1 root root 23 Apr 15 17:16 uInitrd -> uInitrd-6.1.31-sun50iw9 -rw-r--r-- 1 root root 12128483 Apr 15 17:16 uInitrd-6.1.31-sun50iw9 -rw-r--r-- 1 root root 9419112 Sep 28 2023 vmlinuz-6.1.31-sun50iw9 And I also attached most of its contents, skipping big ones. 2 hours ago, ag123 said: try ls mmc 0 [directory e.g. /, /boot etc] Too late 🙂 I will try it next time I flash u-boot. I typed help command and some others, but I did not know what to do. some-files-from-boot-folder-20240420.tgz 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted April 20 Author Share Posted April 20 I kinda remember that in the original image, u-boot can be extracted from there the same way posted a few comments earlier, that with the u-boot SPL bin file and instructions. I looked at the /boot/boot.cmd from the some-files-from-boot-folder archive Spoiler # DO NOT EDIT THIS FILE # # Please edit /boot/orangepiEnv.txt to set supported parameters # # default values setenv load_addr "0x45000000" setenv overlay_error "false" setenv rootdev "/dev/mmcblk0p1" setenv verbosity "1" setenv rootfstype "ext4" setenv console "both" setenv docker_optimizations "on" setenv bootlogo "false" # Print boot source itest.b *0x10028 == 0x00 && echo "U-boot loaded from SD" itest.b *0x10028 == 0x02 && echo "U-boot loaded from eMMC or secondary SD" itest.b *0x10028 == 0x03 && echo "U-boot loaded from SPI" echo "Boot script loaded from ${devtype}" if test -e ${devtype} ${devnum} ${prefix}orangepiEnv.txt; then load ${devtype} ${devnum} ${load_addr} ${prefix}orangepiEnv.txt env import -t ${load_addr} ${filesize} fi if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=ttyS0,115200 console=tty1"; fi if test "${console}" = "serial"; then setenv consoleargs "console=ttyS0,115200"; fi if test "${bootlogo}" = "true"; then setenv consoleargs "splash plymouth.ignore-serial-consoles ${consoleargs}" else setenv consoleargs "splash=verbose ${consoleargs}" fi # get PARTUUID of first partition on SD/eMMC it was loaded from # mmc 0 is always mapped to device u-boot (2016.09+) was loaded from if test "${devtype}" = "mmc"; then part uuid mmc 0:1 partuuid; fi setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}" if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} fdt addr ${fdt_addr_r} fdt resize 65536 for overlay_file in ${overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done if test "${overlay_error}" = "true"; then echo "Error applying DT overlays, restoring original DT" load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} else if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" source ${load_addr} fi if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr echo "Applying user provided fixup script (fixup.scr)" source ${load_addr} fi fi if test "${ethernet_phy}" = "rtl8211f"; then fdt set /soc/ethernet@5020000 allwinner,rx-delay-ps <3100> fdt set /soc/ethernet@5020000 allwinner,tx-delay-ps <700> fi if test "${ethernet_phy}" = "yt8531c"; then fdt set /soc/ethernet@5020000 allwinner,rx-delay-ps <0> fdt set /soc/ethernet@5020000 allwinner,tx-delay-ps <600> fi load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr thoughts are that things could have changed between u-boot versions as new u-boot versions 'advanced' till today, though I'm not sure if Orange Pi could have made some customizations in u-boot (the actual core u-boot code itself) so that the /boot/boot.cmd works the way they wanted it. e.g. that some of the 'environment variables' may not be there in the 'standard' u-boot. that could cause the boot script to fail and hence what you saw. to get things back on track, I'd guess restoring the old u-boot could be a simplest resort, but the 'old' 1.5g issue stays with that u-boot. to be upfront, I'm learning all these new as well, u-boot basically run a bunch of scripts within the 'environment (with variables)', u-boot's own (specialized) shell commands / scripts. there is a bunch of scripts (environment (variables)) in the 'standard' core, then along the way core u-boot scripts evaluates/calls the scripts in /boot/boot.scr (if it exists), if not /boot/boot.cmd directly, that enables u-boot to 'pass' 'environment variables' between the core u-boot to the scripts in /boot/boot.cmd in the linux root partition. this will more than likely break things (e.g. script fail) when u-boot tries to run a /boot/boot.cmd that use 'environment variables' not there in the 'standard'. of course, this technique is 'powerful', everything is 'black magic' - undocumented, can vary with every different implementation of /boot/boot.cmd in infinite number of permutations (e.g. you can always add a variable in core u-boot for your hardware, then reference it in the /boot/boot.cmd (or /boot/boot.scr), then a 'standard' implementation would simply throw error once it reach there. not that it is 'wrong', but that that is the state of the art, 'bleeding edge' if you'd like to call it. that is the state of the art of the embedded world infinite permutations of permutations and no 2 of them are 'standard'. raspberry pi uses u-boot as well, so do a 'thousand' other soc and boards and no 2 u-boot implementation is 'the same', among all of all of them. 1 Quote Link to comment Share on other sites More sharing options...
Вячеслав Вишневский Posted April 22 Share Posted April 22 Hello! I have a SPI touchscreen http://www.lcdwiki.com/3.5inch_RPi_Display How I can made work that screen with orange pi zero 3? 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted April 22 Author Share Posted April 22 SPI tft can be quite an adventure (possibly difficult) to get going, but you can take a look at this project for some hints. https://github.com/notro/fbtft it would also take figuring out how to work SPI on Armbian and Zero 3 not tried that yet. 0 Quote Link to comment Share on other sites More sharing options...
bjorn Posted April 22 Share Posted April 22 I could not get simple SPI device to work even on the Orange Pi Debian image. (So am not sure there is any SPI capable system for it yet). I got normal GPIO operations to work and I2C though but no SPI. 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted April 26 Author Share Posted April 26 @voapilro @bjorn @Long-Johnny, all psst some fun stuff https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ ok that's the 2nd attempt to create a custom u-boot to boot Armbian on 1.5 GB OPi Zero 3 boards, do visit the repository for more info. first you can try that with the 'official' image https://www.armbian.com/orange-pi-zero-3/ but that this u-boot is build from mainline u-boot at the 2024.04 release https://gitlab.com/u-boot/u-boot and that it requires a working /boot/boot.scr or /boot/boot.cmd to boot linux. /boot/boot.scr or /boot/boot.cmd are the boot scripts that actually has u-boot commands which loads the kernel and dependencies and boot linux. if the boot drops you into a command shell, it could mean either that the /boot/boot.scr or /boot/boot.cmd is invalid or that it is using a *custom* u-boot and the /boot/boot.cmd, /boot/boot.scr uses or is expecting some variables that is not there in 'standard' mainline u-boot. I managed to boot to the Linux command prompt this time ! I'd just like to say that I took the Armbian Bookworm minimal image from the Armbian release web for Orange Pi Zero 3 Armbian_community 24.5.0-trunk.474 6.6.28 https://www.armbian.com/orange-pi-zero-3/ did my u-boot patch, run it on my 1.5 GB Orange Pi Zero 3 and it booted to the prompt! and just right now Here is a screenshot running from Orange Pi Zero 3 - 1.5 GB board tethered from usb-uart to debug console, I ran the command 'free' which shows that the total memory is 1.5GB how about that for a proof-of-concept without this u-boot 'patch' u'd get 'stuck' at the boot reporting 2GB seen on the usb-uart debug console for the 1.5GB board. men I feel like celebrating, now Armbian runs on 'all variants' of Orange Pi Zero 3 - 1 GB / 1.5 GB (with this hack) / 2 GB / 4GB 2 Quote Link to comment Share on other sites More sharing options...
robertoj Posted April 26 Share Posted April 26 On 4/22/2024 at 9:03 PM, bjorn said: I could not get simple SPI device to work even on the Orange Pi Debian image. (So am not sure there is any SPI capable system for it yet). I got normal GPIO operations to work and I2C though but no SPI. Is there something specially difficult about SPI versus I2C? Luckily, my servo controller I plan to use with my opiz3 is I2C, but I was hoping to use an SPI LCD too in the future. Is there an spi-overlay option in armbian-config? https://forum.armbian.com/topic/12571-opi-win-how-to-steering-rgb-led-apa106/ 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 4 Share Posted May 4 (edited) @ag123 I have been doing a lot of tests using official Orange Pi Zero 3 SDK following instructions here, and I think a got a way to detect the right memory size. I was not able to fix random memory size detection yet, so it would be next. Anyway, what I saw is that current memory size detection is based on top address wap around to base address. It works well for 1GB, 2GB and 4GB, but not for 1.5GB, as it is not even tried by this method. So I tried to write something to 1.5GB memory address and looking around memory to find a match, and I did not find anything. Instead what I got is that address maps to nowhere, because writing something and then reading once an again, what I got was a kind of random values. And based on that I coded a memory size fix. First of all I need a funcion to check top memory: bool mctl_mem_matches_top(ulong offset) { static const unsigned value= 0xaa55aa55; /* Take last usable memory address */ offset -= sizeof(unsigned); dsb(); /* Set zero at last usable memory address */ writel(0, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Set other value at last usable memory address */ writel(value, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Check if the same value is actually observed when reading back */ return readl((ulong)CONFIG_SYS_SDRAM_BASE + offset) == value; } And then just use it to fix memory size: static unsigned long mctl_calc_size(struct dram_para *para) { u8 width = para->bus_full_width ? 4 : 2; unsigned long size; /* 8 banks */ size = (1ULL << (para->cols + para->rows + 3)) * width * para->ranks; /* Fix size if last usable memory address is not valid */ if (!mctl_mem_matches_top(size)) size = (size * 3) / 4; return size; } Edited May 4 by voapilro 2 Quote Link to comment Share on other sites More sharing options...
ag123 Posted May 5 Author Share Posted May 5 @voapilro thanks, I'd do some tests when I've some time, possibly working that into the custom bootloader code so that others can test that as well. I hardcoded 1.5GB as an/the author partly of the h616/h618 dram initialization/detection reported that (some?) 1.5 GB ddr4 dram chips has address wrap around issues https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233 I'm not sure if this is after all true. As if that is true, then that writing to and reading the last accessible address e.g. 2GB would actually return a false match, saying that there is memory there when there is actually none (i.e. writes to somewhere else). my guess would be to patch that custom u-boot loader with this 'version 2' codes and let 'everyone' test it out including those having non 1.5 GB boards. we'd probably need a way to collect some feedback from the 'testers' if after all that 'works'. the notion is that if there is after all no wraparound, the codes can possibly be committed to u-boot mainline, and become codes in the mainline u-boot. That is truly ideal. of course, a catch with this code is that we'd assume the only 'odd' size is only 1.5 GB, it is unknown if there could possibly be some other weird permutations e.g. 2.5 GB, 3.5GB, 1.2GB, 0.9GB etc that may declare 'too little' or 'too much' dram for some such boards. for that i'd think the only 'right' way is to wait till someone release a means to read the dram registers, which stores the actual memory sizes configurations. 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 5 Share Posted May 5 @ag123 I have only tested on a 1.5GB board, but there should be no problem in remaining boards of 1GB, 2GB and 4GB, as 1.5GB is the only odd case. As far as I know there are no more memory options available. In principle, I was thinking in making detection to cover all possible cases, but I decided not to do it as there would be no board to test them. 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted May 5 Author Share Posted May 5 @voapilro, I'd think for 1.5GB, we'd make do with that 1.5GB custom bootloader, I'd likely adopt your codes so that most who use that can benefit from it. As for pushing it to mainline, I'd think it is pre-mature, as that code applies to *all* H616/H618 devices and not simply Orange Pi Zero 3. 0 Quote Link to comment Share on other sites More sharing options...
Dmitry Loki Posted May 6 Share Posted May 6 hey guys! nice to meet you all! my goal is to get TV-OUT working on Zero 2W (posting here instead of Zero 2W topic since this one is more live ). I've seen in this discussion that @VioletGiraffe have the same goal as well. I'm trying to modify those 6.1 (H2 H3 H5) patches for 6.6 || 6.7. If someone is working on that as well, let's collaborate (actually I'm open for an extra donation if someone does that btw) and please share if there is some progress with that. Many thanks in advance! One question to clarify: - as I understand there is no code in 6.8 that fix TV-OUT issue, right? 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted May 6 Author Share Posted May 6 @voapilro I tried patching those codes into my custom u-boot loader https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ unfortunately, when I tried booting with the updated u-boot, I noted 2 scenarios that is goofy and didn't work first the board is incorrectly detect as a 4GB board. For reasons I'm unsure, the detection is not stable. Sometimes it is detected as a 4GB board, other times 2GB. when it is correctly detected as 2GB, apparently I'm observing the 'dram wraparound' problem, i.e. writing to a little before 2GB spoofs and faked memory at that location when there is actually none. Spoiler U-Boot SPL 2024.04-FixOPiZero3_1.5Gv2 (May 06 2024 - 13:37:58 +0800) DRAM:detected memsize 2048 M 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0(debug):v2.10.0-760-gfb7aa3756 NOTICE: BL31: Built : 01:19:32, Apr 27 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b3778, 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. If it is working correctly, it should detect 2048M and return 1.5GB instead. The patch is like such: Spoiler Index: 1.5GB_Fix_for_Armbian_on_OrangePiZero3/u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c =================================================================== --- 1.5GB_Fix_for_Armbian_on_OrangePiZero3.orig/u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c +++ 1.5GB_Fix_for_Armbian_on_OrangePiZero3/u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c @@ -1345,12 +1345,37 @@ static void mctl_auto_detect_dram_size(c } } + +bool mctl_mem_matches_top(unsigned long long offset) +{ + static const unsigned value= 0xaa55aa55; + +#define CONFIG_SYS_SDRAM_BASE 0 + /* Take last usable memory address */ + offset -= sizeof(unsigned); + dsb(); + /* Set zero at last usable memory address */ + writel(0, (ulong)CONFIG_SYS_SDRAM_BASE + offset); + dsb(); + /* Set other value at last usable memory address */ + writel(value, (ulong)CONFIG_SYS_SDRAM_BASE + offset); + dsb(); + /* Check if the same value is actually observed when reading back */ + return readl((ulong)CONFIG_SYS_SDRAM_BASE + offset) == value; +} + static unsigned long mctl_calc_size(const struct dram_config *config) { u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ - return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; + unsigned long long memsz = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; + log_info("detected memsize %d M\n", (int)(memsz >> 20)); + + /* Fix size if last usable memory address is not valid */ + if (!mctl_mem_matches_top(memsz)) + memsz = (memsz * 3) / 4; + return memsz; } As such, I reverted the codes to the old 1.5GB hard coded version. It would have been good if this works (well), at least that it can be used on all the different Orange Pi Zero 3 boards 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 6 Share Posted May 6 @ag123 Thanks for testing it! But I think there is a mistake in your patch. Why you redefine CONFIG_SYS_SDRAM_BASE as 0? I forked u-boot and made a branch with my changes here and this is the patch. Please, can you try it? 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted May 6 Author Share Posted May 6 @voapilro I think there could be another mistake besides that, my memory computation is using unsigned long long, my guess is that'd be 64 bits, that becomes the 'offset' in mctl_mem_matches_top(offset). I made a guess that the unsigned long long would be truncated dropping the high order 32 bits, that would still match the 32 bits based address, but could be wrong. For reasons uncertain, searching for CONFIG_SYS_SDRAM_BASE 'returns a blank' in my source base, as such I took a liberty to define that as 0. A thing is memsz is computed as 2 GB ( 2048 * 1024 * 1024 ), as I guess observed, I'm not too sure if that might be offset away a little, say the 'bottom' 32kb 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 6 Share Posted May 6 @ag123 The value of CONFIG_SYS_SDRAM_BASE for opi-zero3 is 0x40000000 i.e. 1GB of memory, so it makes a big difference in results of memory size detection. By the other hand, CONFIG_SYS_SDRAM_BASE was renamed to CFG_SYS_SDRAM_BASE at some point between u-boot-sunxi and latest u-boot official release, so I updated my patch. Besides I was trying to use Armbian builder to generate an u-boot image to test patch: Quote $ git clone --branch=main https://github.com/armbian/build $ cd build $ ./compile.sh uboot BOARD=orangepizero3 KERNEL_MAJOR_MINOR=6.6 ATF_PLAT=sun50i_h616 And after that, I got u-boot-sunxi-with-spl.bin in cache/sources/u-boot-worktree/u-boot/v2024.01 folder. So just adding patch to userpatches/u-boot/u-boot-sunxi folder and repeating build, I would get patched u-boot image. Well, to force rebuild, I had to remove packages in output/debs folder. The problem is that patch does not apply to v2024.01 u-boot release, so I had to create a new one from such release. Those new changes are here, and this is the new patch. This way I got a patched u-boot image I attached here. I replaced u-boot in my board by this patched one, and this is what I got: Quote U-Boot SPL 2024.01-armbian (May 06 2024 - 21:19:02 +0200) DRAM base address is defined as 0x40000000 DRAM has 16 b/raw, 10 b/col, 4 B/width, 1 #rank and 8 #bank DRAM top address must be less than 0x80000000 DRAM top address must be less than 0x60000000 DRAM: 1536 MiB Trying to boot from MMC1 NOTICE: BL31: v2.9(debug):armbian NOTICE: BL31: Built : 19:08:57, May 6 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b2e60, 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 855873 was applied INFO: BL31: cortex_a53: CPU workaround for 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. ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2024.01-armbian (May 06 2024 - 21:19:02 +0200) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) So, I works in my board. Well, It does not boot because of my u-boot configuration. I was no able to get a working Armbian build for opi-zero3, so I am using the vendor opi-zero3 Debian image. Any help for testing patch in other boards would be welcome, specially with1.5GB ones. u-boot-sunxi-with-spl-armbian-v2024.01-20240506-patch.tgz 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted May 7 Author Share Posted May 7 @voapilro Thanks To try to get it to boot, try applying the patches https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main/patches in particular: https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/THS_fix.patch https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/enable_GPU.patch note that these are for mainline u-boot 2024-04 release (tag), the patches are for the same found in Armbian. I really disliked all these 'black magic', but that these are really the 'state-of-the-art'. After I did my initial 1.5GB 'hack' patches, originally I've got that 'gpu overheating' issue. But with that 2 patches, it booted to the prompt ! As for 'vendor' u-boot, I'm suspecting that orange pi customized u-boot to pass some additional variables (possibly hard coded) to boot.scr, boot.cmd. When something fails there, I'd guess it dropped to the u-boot prompt. It'd take figuring out what is the statement that the boot.scr, or boot.cmd aborted and what it needs. When that is figured out, you may also be able to do that same 'black magic', passing the variables boot.scr or boot.cmd is expecting. I kind of disliked these 'black magic', the 'right' way is for these to goto the device tree source or overlays (dts files), so that the relevant board use the correct board dts file instead of hard coding them in u-boot. But it is somewhat the 'state-of-the-art' as well as of current, the catch is mainline u-boot won't boot those custom boot.scr and boot.cmd as those 'special' hard coded variables won't be there. if you clone my repository, I've updated a build guide https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/build.md those steps should compile the mainline u-boot for Orange Pi Zero 3 - note with the '1.5GB hack' my repository is managed using quilt https://wiki.debian.org/UsingQuilt to make edits (note those steps in build.md needs to be done at least once prior this) quilt series quilt push patches/1.5GB_OPZ3_fix.patch vi u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c <- or use any editor you prefer quilt refresh <- note this would update patches/1.5GB_OPZ3_fix.patch quilt push -a <- this applies the remaining of the patches # compile it cd arm-trusted-firmware bash arm-trust-fw-make.sh <- normally only need to be done once, not necessary if that is already built prior cd u-boot bash build.sh # test it if necessary # you can rollback all the patches using # quilt pop -a 0 Quote Link to comment Share on other sites More sharing options...
OttawaHacker Posted May 7 Share Posted May 7 (edited) Any chances you guys could share your images? Been struggling getting a recent image to boot with my 1.5Gb one. only the old official Debian images work. One of the github links from Orange PI provides a bin uboot for the 1.5Gb but I had no luck with that. leeboby/opizero3-uboot-dtb: 保存opizero3 1.5gb和4gb版本的开发板linux6.x系统需要替换的u-boot和dtb文件 (github.com) Edited May 7 by OttawaHacker 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 7 Share Posted May 7 @ag123 I have good news, I patched an Armbian community build with this patched u-boot, and now it boot 🙂 Before applying patch it detected 2GB memory and stopped: Quote U-Boot SPL 2024.01-armbian (Mar 14 2024 - 00:32:50 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.2(debug):armbian NOTICE: BL31: Built : 00:32:32, Mar 14 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b2e60, 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. ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2024.01-armbian (Mar 14 2024 - 00:32:50 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 2 GiB (effective 16 EiB) But after applying patch, it boots to the end: Quote U-Boot SPL 2024.01-armbian (May 06 2024 - 21:19:02 +0200) DRAM base address is defined as 0x40000000 DRAM has 16 b/raw, 10 b/col, 4 B/width, 1 #rank and 8 #bank DRAM top address must be less than 0x80000000 DRAM top address must be less than 0x60000000 DRAM: 1536 MiB Trying to boot from MMC1 NOTICE: BL31: v2.9(debug):armbian NOTICE: BL31: Built : 19:08:57, May 6 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b2e60, 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 855873 was applied INFO: BL31: cortex_a53: CPU workaround for 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. ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2024.01-armbian (May 06 2024 - 21:19:02 +0200) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) Net: Unsupported value 13, using default (13) Unsupported value 13, using default (13) 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... 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 <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3259 bytes read in 1 ms (3.1 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 205 bytes read in 1 ms (200.2 KiB/s) 32799 bytes read in 4 ms (7.8 MiB/s) Working FDT set to 4fa00000 4203 bytes read in 3 ms (1.3 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 10908486 bytes read in 451 ms (23.1 MiB/s) 23431176 bytes read in 968 ms (23.1 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=418e0000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 10908422 Bytes = 10.4 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 49598000, end 49fff306 ... OK Loading Device Tree to 0000000049527000, end 0000000049597fff ... OK Working FDT set to 49527000 Starting kernel ... Armbian_community 24.5.0-trunk.433 Bookworm ttyS0 orangepizero3 login: And this is what I did to patch image: Quote $ wget https://github.com/armbian/community/releases/download/24.5.0-trunk.433/Armbian_community_24.5.0-trunk.433_Orangepizero3_bookworm_current_6.6.28_minimal.img.xz $ unxz Armbian_community_24.5.0-trunk.433_Orangepizero3_bookworm_current_6.6.28_minimal.img.xz $ dd bs=1k seek=8 if=u-boot-sunxi-with-spl-armbian-v2024.01-20240506-patch.bin of=Armbian_community_24.5.0-trunk.433_Orangepizero3_bookworm_current_6.6.28_minimal.img conv=notrunc I would suggest to add u-boot patch to community builds in order to any new build would be able to boot in any opi-zero3 board, even in the ones with 1.5GB memory. Do you know who is in charge of generating community builds? 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted May 7 Share Posted May 7 2 hours ago, voapilro said: Do you know who is in charge of generating community builds? 1st sentence: https://github.com/armbian/community/blob/main/README.md once per week 0 Quote Link to comment Share on other sites More sharing options...
SteeMan Posted May 7 Share Posted May 7 3 hours ago, voapilro said: I would suggest to add u-boot patch to community builds Get involved and submit a PR to: https://github.com/armbian/build 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 7 Share Posted May 7 1 hour ago, SteeMan said: Get involved and submit a PR to: https://github.com/armbian/build @SteeMan This is what I am trying to do, but I should submit at least two patches, one for u-boot release v2024.01 and other one for v2024.04 and newer. After doing some tests, adding patch to patch/u-boot/u-boot-sunxi folder, it is applied during build, but for any u-boot release. I tried to add it to patch/u-boot/v2024.01 folder, but it does not work. I did not find any document explaining how to do it. Any help is welcome. 0 Quote Link to comment Share on other sites More sharing options...
OttawaHacker Posted May 7 Share Posted May 7 5 hours ago, voapilro said: I would suggest to add u-boot patch to community builds in order to any new build would be able to boot in any opi-zero3 board, even in the ones with 1.5GB memory. Do you know who is in charge of generating community builds? This is awesome. Would you be able to share the uboot bin file to start? Also PR to the community build would be super useful but I suspect there is a bit more to figure out. I did some digging around the builds and was not able to figure out where the u-boot thing was happening. Would the OPI Zero 3 1.5G be a separate configuration? Sounds like it needs to be a separate build and configuration (until more uboot magic can be figured out). Also this doesn't look like a regular patch if a u-boot bin needs to be applied. 0 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 7 Share Posted May 7 11 minutes ago, OttawaHacker said: Would you be able to share the uboot bin file to start? @OttawaHacker I already did it, you can find it attached here: 12 minutes ago, OttawaHacker said: Would the OPI Zero 3 1.5G be a separate configuration? This is what I am trying to avoid. 1 Quote Link to comment Share on other sites More sharing options...
voapilro Posted May 7 Share Posted May 7 (edited) @ag123 @OttawaHacker I submitted a pull request in order to add DRAM patch to community builds. Let's see how it goes... Edited May 7 by voapilro 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted May 8 Author Share Posted May 8 @OttawaHacker Quote Any chances you guys could share your images? Been struggling getting a recent image to boot with my 1.5Gb one. only the old official Debian images work. One of the github links from Orange PI provides a bin uboot for the 1.5Gb but I had no luck with that. leeboby/opizero3-uboot-dtb: 保存opizero3 1.5gb和4gb版本的开发板linux6.x系统需要替换的u-boot和dtb文件 (github.com) you could try the images from here: https://www.armbian.com/orange-pi-zero-3/ and to patch the u-boot into the image from here https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.