Image | Radxa ZERO 3 #7024
Comments
|
Also, I am happy to get a board for whoever needs it to test. Just reach out to me on discord or email and ping me here. @SelfhostedPro on discord and my email is on my profile. |
|
I've been working on building this myself but have been running into the following issue and am not fully sure why/how to resolve it: I'm building out some actions to clone/build armbian as well as diet pi. I also run into this same issue trying to build with imager on my pi5. |
|
Seems the image was cut after the partition table was generated, so that the secondary/backup partition table was cut off. A little unclean, but it is a backup partition table only. We assure it is present and at the right position since it otherwise throws warnings whenever touching the partition table. But probably those can be ignored, as we do the same after everything has been done, so the final image will have the backup partition table present and correctly located in any case. Can you try this version of the script: https://raw.githubusercontent.com/MichaIng/DietPi/imager/.build/images/dietpi-imager |
|
I believe that's the version I'm using here: https://github.com/SelfhostedPro/radxa-zero3w/blob/98020929a55d62b304dc053b6a40d72ca6a1ce6f/.github/workflows/armbian_custom.yml#L153
Here is the action if you're curious of the context: The dietpi side of things is currently here: |
|
Ah, latest one got much further but runs into the same error: https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8768856129/job/24063717270#step:11:192 |
|
I've tried a few variations of options but am still running into similar errors. https://github.com/SelfhostedPro/radxa-zero3w/actions/workflows/armbian_custom.yml These are the actions. Arabian builds fine but still having the same issue with the diet-pi imager. Would you be opposed to me rewriting it in python? Feel like it has enough functionality that it would be beneficial to have the debugging features and readability. |
|
Ah, I didn't know that workflow. Please try to replace An alternative would be indeed to use MBR instead of GPT partition table, but there are bootloader builds which do not support MBR, so it might then fail to boot. A matter of testing. |
|
Hey, sorry. I have tried that in my latest runs and it got further than with master but still fails: (Also tried messing around the dos partition variables). |
|
Ah I see, this is on the final I wonder whether the partition table is (much!) larger than the 34 sectors we expect. This is the default, covering 128 partition entries: https://en.wikipedia.org/wiki/GUID_Partition_Table I see no evidence in the Armbian scripts that a non-default partition table size is used: https://github.com/armbian/build/blob/main/lib/functions/image/partitioning.sh I wonder whether there is a way to read the GPT size (number of possible entries). |
|
This is the commit that added board support to Armbian: https://github.com/armbian/build/blob/main/config/boards/radxa-zero3.wip This is the command I'm using for the build: https://github.com/SelfhostedPro/radxa-zero3w/blob/acd31e2c4b010296a3ccf5e3af4819a6eca6dd36/.github/workflows/armbian_custom.yml#L108 I don't think anything would modify the partition tables from standard from looking though. |
|
Looks all good, nothing which should affect the partition table size generated on the fresh loop device for image generation. It is too late for today here, but I'll add the Makes sense to test a recent official Armbian image as well, whether it has the same GPT size. |
|
Sounds good. Have a good night and I appreciate your help with this! |
|
I played with this image, too curious: root@dietpi:/tmp# sgdisk -p Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
Disk Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img: 5185536 sectors, 2.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 8FE29520-29EE-AB4D-B92F-A6C93E1B2D6F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 5185502
Partitions will be aligned on 2048-sector boundaries
Total free space is 30720 sectors (15.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 32768 557055 256.0 MiB EA00 bootfs
2 557056 5185502 2.2 GiB 8300 rootfs
root@dietpi:/tmp# sgdisk -e Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.
root@dietpi:/tmp# ls -l Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
-rw-r--r-- 1 root root 2654994432 Apr 21 23:05 Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
2024-04-22 00:43:41 root@dietpi:/tmp# gdisk Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
GPT fdisk (gdisk) version 1.0.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): x
Expert command (? for help): s
Current partition table size is 128.
Enter new size (4 up, default 128): 128
Expert command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
root@dietpi:/tmp# sgdisk -e Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.
root@dietpi:/tmp#This is so weird: The GPT table has the expected 128 entries size. With the end of the last partition, the required image size is hence 2.654.994.432 bytes, which is exactly (to the exact byte) the size of the image file. So it is exactly as we expect, the last partition is expanded (by Armbian script auto-sizing of last partition) exactly to leave the last 34 sectors free for the backup partition table. And still, even after resetting the size and rewriting the table, it still shows this weird error about the overlap. I do not wonder whether this is a bug in One thing to check is whether the bootloader is probably flashed a way that it is interpreted by |
|
Would there be an alternative command to sgdisk that we could utilize? Or something I could run in the armbian customization process to enable another command to use if it is an error? I’ll be able to mess with the image file some tomorrow to see if I can find a workaround. How would I go about checking that the bootloader is flashed that way? |
|
Also, just wanting to link the pr in armbian that added support: armbian/build#6420 |
|
em.... it seems there is a problem with the image creation script, I am not sure if it is similar to my previous case with Orangepi 3B. https://dietpi.com/forum/t/failure-in-creating-image-through-imager-script/18035 |
|
It looks like someone had success using the official radxa image here: https://forum.radxa.com/t/share-of-unofficial-dietpi-image-for-radxa-zero-3w/20430/5 |
|
Interesting, @disablewong I did not remember your identical report from last year. I just tested the community maintained Orange Pi 3B image, and it is the same: https://github.com/armbian/community/releases/download/24.5.0-trunk.433/Armbian_community_24.5.0-trunk.433_Orangepi3b_bookworm_vendor_6.1.43_minimal.img.xz root@dietpi:/tmp# sgdisk -e Armbian_community_24.5.0-trunk.433_Orangepi3b_bookworm_vendor_6.1.43_minimal.img
Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.Same with officially supported Orange Pi 5 image, so all Armbian images with GPT partition table are affected. I am just not sure why, since our own GPT images go through it fine, and the partition table definitely has the default 128 entries and GPT overall 34 sectors size. The Armbian scripts seem to do something on their partitioning which makes root@dietpi:/tmp# sgdisk -p Armbian_24.2.1_Orangepi5_jammy_legacy_5.10.160_minimal.img
Disk Armbian_24.2.1_Orangepi5_jammy_legacy_5.10.160_minimal.img: 3203072 sectors, 1.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 1718C59C-EE29-C949-AA5C-4CC4048AC17C
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 3203038
Partitions will be aligned on 2048-sector boundaries
Total free space is 30720 sectors (15.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 32768 557055 256.0 MiB EA00 bootfs
2 557056 3203038 1.3 GiB 8300 rootfsThis caught my eyes: Let's compare with our image: root@dietpi:/tmp# sgdisk -p DietPi_OrangePi5-ARMv8-Bookworm.img
Disk DietPi_OrangePi5-ARMv8-Bookworm.img: 2097185 sectors, 1024.0 MiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 75DABD45-859D-4B22-BC6C-615235F05849
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 2097151
Partitions will be aligned on 2048-sector boundaries
Total free space is 32734 sectors (16.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 32768 2095103 1007.0 MiB 8300 root
2 2095104 2097151 1024.0 KiB 0700The partitions in our case are 2048 sectors aligned as well, but in case of Armbian, this seems to apply for the GPT as well. And there it is: https://manpages.debian.org/bookworm/fdisk/sfdisk.8.en.html#Header_lines
And root@dietpi:/tmp# fdisk DietPi_OrangePi5-ARMv8-Bookworm.img
Command (m for help): g
Created a new GPT disklabel (GUID: 1D1C8CDB-7107-4CED-9993-337EB5552081).
Command (m for help): w
The partition table has been altered.
Syncing disks.
root@dietpi:/tmp# sgdisk -p DietPi_OrangePi5-ARMv8-Bookworm.img
Disk DietPi_OrangePi5-ARMv8-Bookworm.img: 2097185 sectors, 1024.0 MiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 1D1C8CDB-7107-4CED-9993-337EB5552081
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 2097151
Partitions will be aligned on 2048-sector boundaries
Total free space is 2095104 sectors (1023.0 MiB)
root@dietpi:/tmp# sfdisk DietPi_OrangePi5-ARMv8-Bookworm.img -N1 <<< ',+'
root@dietpi:/tmp# truncate -s $(( (2095103+34) * 512 )) DietPi_OrangePi5-ARMv8-Bookworm.img
root@dietpi:/tmp# sgdisk -e DietPi_OrangePi5-ARMv8-Bookworm.img
...
Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.So this is how to obtain the value: root@dietpi:/tmp# sgdisk -p DietPi_OrangePi5-ARMv8-Bookworm.img 2>&1 | mawk -F[\ ,] '/^First usable sector/{print $5}'
2048 |
|
I updated Glad to have finally found the underlying reason. Though For reference: https://sourceforge.net/p/gptfdisk/discussion/939590/thread/da2435b5a8/ |
|
Hmmm. Still failing: Is this using the correct branch and whatnot? |
|
Ah my fault, copy&paste error. Now it should work. |
|
Seems it was successful now 🙂: https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8790829053/job/24123741616 |
|
Yeah! It went through! |
|
Okay, I merged it into |
|
Hey, as a note. For at least the imager branch I'm using it doesn't create a separate boot partition with config files in it even with I'll go ahead and change to dev in the meantime, thanks! Got to mess with it a bit today and it boots which is cool. |
|
I am about to add native support for this device: #7042 Here a first image to test: https://dietpi.com/downloads/images/testing/DietPi_RadxaZERO3-ARMv8-Bookworm.img.xz So instead of converting an Armbian image, you could then also use our build script: https://github.com/MichaIng/DietPi/blob/newimages/.build/images/dietpi-build Please use only Ah, and the script actually sets those to |
MichaIng
added
Testing/testers required 🔽
Solution available 🥂
|
Great! I'm also building a Trixie image now, as this is currently possible. But again, I am 99.99% sure that is has no effect on GPU/display driver issues, Radxa simply will have more differences between their images, than the Debian userland version alone. Also, while builds go currently through, on my Trixie systems, I still face a lot of errors coming and going due to 64-bit time_t transition, i.e. one or more packages are hold back due to dependency conflicts. Running forces full-upgrade, result in unwanted purged packages to resolve those conflicts, which can potentially result in a broken system on/after first boot of DietPi. Hence, I strongly recommend to not use Trixie for any production case for the next month(s), until time_t transition has fully finished. But of course, it does not hurt to test/verify whether the Bookworm system really has no GPU/display issue, which the Trixie system does not have. |
|
So, since the wrong device tree was the reason (indeed I just found that Radxa's kernel sources provide that one, while Armbian's kernel sources do not, but their default DTS matches the AIC8800 one from Radxa), probably it works actually well with Linux 6.1, when defining the device tree explicitly. I'll recreate an image with that: https://github.com/MichaIng/DietPi/actions/runs/8924902271 Will be available again here: https://dietpi.com/downloads/images/testing/ EDIT: Okay, the Linux 6.1 image seems to have no HDMI output and throws mali/panfrost kernel errors with stack trace at reboot. Hence for now we'll stick with legacy Linux 5.10 kernel, and will generate Linux 6.1 kernel packages by times, or in case we see some related commit at Armbian or Radxa (who did not add ZERO 3 support to their 6.1 branch either). |
|
em.... it sound strange to me.... my board can use HDMI with kernel 6.1.43.... The current problem is the wifi was not detected during the first boot, it only show up after rebooting... |
|
Interesting, when testing the Radxa ZERO 3E with @StephanStS, it did not work, but worked when just placing the SD card with 5.10 build. Not sure whether 3E and 3W have some other differences in this regards? Does WiFi not work on any cold boot, or is it only missing on the very first boot? And does it work immediately with the 5.10 image? And when it is missing, does the kernel log I was looking through Armbian implementation. Strange is, regarding the device tree, that U-Boot is configured to select the correct one:
Confusing why it was still trying to load The bigger problem now is, that the ZERO 3W comes with two different onboard WiFi chips: AP6212 and AIC8800. In our images/with Armbian kernel, the default supports AIC8800. AP6212 requires a switch to the I mixed it up, ignore ...
EDIT: Ah, I mixed it up: You required additional firmware for AP6212, not AIC8800. And of course, the converted Radxa Debian image does not contain And, I hope there is a way to detect the used WiFi chip e.g. via board revision/serial number: cat /proc/device-tree/serial-number |
|
The output of this command |
|
I hope that the serial number follows some pattern to differentiate between the revisions. So far it does not like it does, but let's see how those of the others look like. Would be good if you could test both images. Especially check whether WiFi works, i.e. whether the adapter shows up in |
|
Found the code which overrides the device tree based some hardware ID ranges: https://github.com/radxa/u-boot/pull/45/files We can do the following in our
👍. |
The wifi in my case show-up in both In my opinion, I would give compatibility with ap6212 a lower priority, cause this batch of board should be in small quantity (~500 pcs), and will not be produced again as I learnt from Radxa. Now it is in Labor's Day holidays in China and they would return to work next week. |
|
Thanks, this basically verifies that Armbian did no wrong decision to make the AIC8800 device tree the default. Instead of checking and adjusting I'll implement this tomorrow. Even if the batch is small, it is sufficiently simple to keep supporting the boards of those early adopters. So far, no need for help from Radxa, as the code is self-explaining, but thanks for the offer to ask 🙂. |
|
Totally forgot about the U-Boot patch. Done now: MichaIng/build@084efdc cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-u-boot-radxa-zero3-legacy.deb
dpkg -i linux-u-boot-radxa-zero3-legacy.deb
/boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
sed -i '/^[[:blank:]]*fdtfile=/s/^/#/' /boot/dietpiEnv.txt
rebootIf it does not boot anymore, still trying to load the wrong device tree, the revert the change in |
|
Is anyone able to test the above? So I can merge those builds into our APT repo. |
|
yes Michalng, thanks for the hard works. |
|
I've tested the image, with some strange output at a glance.
The image I've tested was Trixie, kernel version was 5.10.xx |
The device tree supports both: ZERO 3W and ZERO 3E. But it should not take longer to boot because of this. First boot takes long because DietPi is doing some first boot setup stuff: https://github.com/MichaIng/DietPi/blob/master/rootfs/var/lib/dietpi/services/dietpi-firstboot.bash Hmm, how to find out which device tree was picked. Can you check this: find /proc/device-tree -name 'wireless[-_]wlan'It should return a directory. If so, that should contain a file named Alternative: sed -i '/^setenv bootargs/s/"$/ fdtfile=${fdtfile}"/' /boot/boot.cmd
mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scrThen, after reboot, you can read back the variable via cat /proc/cmdline |
|
@StephanStS cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-u-boot-radxa-zero3-legacy.deb
dpkg -i linux-u-boot-radxa-zero3-legacy.deb
/boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
sed -i '/^[[:blank:]]*fdtfile=/s/^/#/' /boot/dietpiEnv.txt
reboot |
I used the image from there for my Radxa ZERO 3E: https://dietpi.com/downloads/images/DietPi_RadxaZERO3-ARMv8-Bookworm.img.xz and executed the commands given. The boot process failed (no output on HDMI). |
|
Thanks, I found it, I just did a rebuild, would be great if you could test it again. As alternatively to flashing a new image, you could also edit the |
|
The new downloaded image now works (UART console output as well as HDMI output. |
|
Okay great, thanks for testing. I'll merge this into our APT repository then for the next images to have it fixed. |
|
Can someone replicate that HDMI does NOT work anymore when upgrading to vendor kernel? apt update
apt install linux-{image,dtb}-vendor-rk35xx@StephanStS faced this issue on Radxa ZERO 3E, so would be interesting to know whether its the case on 3W as well. I also just pushed an updated package version, so maybe that was even fixed. |
|
I just downloaded the latest image and used on my Zero3W. No display from HDMI. Will have console output later, other work I have to resolve first. |
|
Okay, good to know. Then we will keep using the |
Creating an image request
Formal device information
Is the SBC officially supported by the Debian installer?
If not, is a reliable 3rd party Debian image available for this SBC?
If not, are there install instructions for Debian available?
Here are the official instructions for installing an OS: https://docs.radxa.com/en/zero/zero3/getting-started/install-os
The text was updated successfully, but these errors were encountered: