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