None of the OrangePi 3B images boot (v2.1, SDCard, not NVMe)

Troubleshooting
1

Hi Everyone,

I have an OrangePi 3B v2.1 and want to load DietPi on it because I’ve been running DietPi on my RPi boards and love it.

I downloaded the image linked on dietpi.com (https://dietpi.com/downloads/images/DietPi_OrangePi3B-ARMv8-Bookworm.img.xz) and used BalenaEtcher to flash it to a microSD card. Popped the card in the OPi and… Nothing but a black screen.

So then I found that if I went to Index of /downloads/images there are actually 3 images available there:

  • DietPi_OrangePi3B-ARMv8-Trixie.img.xz
  • DietPi_OrangePi3B-ARMv8-Bookworm.img.xz
  • DietPi_OrangePi3B-ARMv8-Bullseye.img.xz

So I downloaded them all (file date 2024-12-24) and tried each of those. Same result.

To make sure the board wasn’t broken, I downloaded and tried the Debian and Ubuntu images from the vendor’s site (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-3B.html). Those worked fine, but I don’t like how they get all their packages from Huawei servers in China, and I believe they’re running really old versions (kernel 5.10 I think).

I started digging through old threads on here and found several, but all of them seemed to be from folks who could get the images to boot but had other hardware issues. I dove down the rabbit hole trying to figure out dtb files and how to edit the environment to load them, but nothing seemed to work well.

Through a reddit thread I found this github repo that had links to some Armbian images that worked (orangepi3b_v2.1/Armbian_Noble_rk6.1.75 at main · defencedog/orangepi3b_v2.1 · GitHub), but since they were Ubuntu based I ran into lots of issues trying to turn them into DietPi after the fact.

At this point I’m stumped. I just want a DietPi image that boots from SSD and has a working NIC. Literally everything else (audio, GPIO, USB ports, you name it) is optional. I mention that because those are aome of the bits of hardware that people were having trouble with, but I cant even get it to boot.

Can anyone help?

2

personally I don’t have an OPi 3B. Maybe something @StephanStS or @MichaIng could help with. Nor sure if one of them could help with.

Of course this is not going to work as DietPi requires a Debian base image.

3

I’ve got a 3B, and I don’t like the Huawei servers either…

4

Yeah, I knew it was unsupported and unlikely to work, but I was desperate so I tried it anyway… And predictably it did not work.

I’m not linux-savvy enough to know how to try and take a bone stock Debian iso and turn it into a working SBC SDCard image that boots.

I read somewhere that the Orange Pi 3B will have drivers right in the 6.12 LTS kernel, but like hell if I can figure out how to retro fit a different kernel into an image that I can’t even boot. Presumably there’s some kind of virtual environment or other SBC that I could open the Trixie image on and update the kernel from the testing repo, but seeing as I’ve only once updated a kernel on any Linux distro ever (and it was on a booting RHEL install on an x86-64 blade server), my skills aren’t yet up for the task.

Though I’m just curious and stubborn enough that if someone were to point me to some material on how to build images for SBCs from scratch I’d give it the old college try.

5

Small update:

I’ve ordered a UART-USB cable to see what we’re getting on the console. That should be here later this week.

I also grabbed the Debian-based Armbian “Minimal/IoT” image and tried to convert it. The image initially loaded and ran fine, and the DietPi conversion script ran fine. I got to the message at the end that said I could shutdown and image the SDCard or reboot. But on reboot I get the same lack of display.

I tried connecting another monitor since I saw mention in another thread that monitors with wonky resolutions can cause an issue. I unplugged my 3440x1440 widescreen and instead dug out an old 24" 1080p monitor. No difference.

So … I’m still stumped. Will update when I get the UART cable.

6

Just tried DietPi on my Orange Pi 3B and encountered the same issue.

U-boot complains about not being able to find /boot/dtb/rockchip/rk3566-orangepi-3b-v1.1.dtb during startup (while executing the /boot/boot.scr script). I checked the dtbs directory, which actually only contains /boot/dtb/rockchip/rk3566-orangepi-3b.dtb. This seems the reason for the boot failure.

@Cryovenom, as a temporary workaround, when you have access to the serial console, try manually booting the kernel once by entering the following in the U-Boot console:

load mmc 0 ${kernel_addr_r} /boot/vmlinuz-6.10.6-edge-rockchip64

load mmc 0 ${fdt_addr_r} /boot/dtb/rockchip/rk3566-orangepi-3b.dtb

setenv bootargs initrd=/initrd.img-6.10.6-edge-rockchip64 console=ttyS2,1500000 root=PARTUUID=2f3fd9c7-cb58-43ae-978e-60f136cfd91c rw loglevel=2

booti ${kernel_addr_r} - ${fdt_addr_r}

Note that the PARTUUID here is incorrect, so it will definitely fail to boot. However, the kernel will complain and print the correct UUIDs of all partitions during the boot process. Replace the parameter with the correct partition UUID then.

After entering the system, copy /boot/dtb/rockchip/rk3566-orangepi-3b.dtb as /boot/dtb/rockchip/rk3566-orangepi-3b-v1.1.dtb.

7

Alrighty, so I got the UART working and came across something very similar to what you did.

When booting the image, I get this:

Scanning bootdev 'mmc@fe2b0000.bootdev':
  1  script       ready   mmc          1  mmc@fe2b0000.bootdev.part /boot/boot.scr
** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with script
303 bytes read in 4 ms (73.2 KiB/s)
31076864 bytes read in 2604 ms (11.4 MiB/s)
13151992 bytes read in 1140 ms (11 MiB/s)
Failed to load '/boot/dtb/rockchip/rk3566-orangepi-3b-v2.1.dtb'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC

So I’m guessing that your board is a v1.1 and mine is a v2.1 and it has detected the difference. But since the only dtb available has neither a v1.1 nor a v2.1 in the filename, it can’t find one to load.

I tried the steps you suggested, but that hit a snag:

=> load mmc 0 ${kernel_addr_r} /vmlinux z-6.10.6-edge-rockchip64
Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
Couldn't find partition mmc 0
Can't set block device
=>

No matter, my laptop is a Linux box (Zorin OS) with an SD Card slot so I just moved the SD Card over to my laptop, changed into the directory on the SD Card with the DTBs and did a:

sudo cp rk3566-orangepi-3b.dtb rk3566-orangepi-3b-v2.1.dtb

Ejected the SDCard, popped it in the OrangePi and tried again.

The good news:
It now booted up and I got output on my HDMI monitor

The bad news:
It looks like the rk3566-orangepi-3b.dtb is the one for the v1.1 board and so I’ve got all the same bugs that folks were reporting before. When the NIC didn’t grab a DHCP address I manually set the sync rate to 100M and was able to get an IP, but yeah this DTB is not the right one.

I did an additional test where I grabbed the rk3566-orangepi3b-v2.2.dtb from my working armbian/debian SDCard and copied it over. Despite both being debian bookworm it didn’t take. I didn’t get the missing file error, but instead it just freezes when it hits “loading kernel”.

So it looks like whatever fix @MichaIng did in this thread (Ethernet not working in the new version of Orange Pi 3B - #28 by MichaIng) or got rolled back or something.

On the bright side, if we can get his attention we now have someone with a v1.1 board and someone with a v2.1 board, both with UART cables… so we can do some troubleshooting to help iron out any issues!

1 Like
8

I forgot to upload my PuTTY logs. Here they are for reference.

Bootlog-DietPi_OrangePi3B-ARMv8-Bookworm.txt (9.7 KB)
Bootlog-DietPi_OrangePi3B-ARMv8-Bookworm-AfterCopyingDTB.txt (52.2 KB)

9

Oh… you’re right, my 3B was bought at the end of 2023, so it should be the previous generation (v1.1). I don’t know much about v2.1.

The thing I forgot to mention here is that you might have selected the wrong MMC. According to my observation (on v1.1), mmc 0 is the eMMC, 1 is the SD card, and 2 is the SPI Flash. If you primarily use the SD card, you probably should try mmc 1 instead of 0.

10

Looks like our image was built with the old kernel somehow, which does not support v2.1 revision yet. And since the new bootloader expects now dtb files with revision suffix, also the old revision won’t work without defining the old dtb name in /boot/dietpiEnv.txt.

I’ll check and redo in 2 hours.

1 Like
11

Awesome, thanks MichaIng!

Once the fix is made, how long will it take for the new images to become available for download? I noticed that all the current ones have the same date (2024-12-24) so I’m guessing that there’s a periodic, scheduled rebuild of the images that we will have to wait for.

12

Builds are done manually, always. There is no fix schedule.

13

I moved the new images in place, based on “current” kernel branch, as it is/should be new enough now. Would be great if someone could test them.

14

Alright, here’s the result of my testing:

DietPi Test Cases

Date: 2025-01-02
SBC: OrangePi 3B, hardware revision v2.1
Storage: SDCard

Test Case 1 - New DietPi Bookworm Image

RESULT:
PASSED, Conditionally

Image:
DietPi_OrangePi3B-ARMv8-Bookworm.img.xz File Date: 2025-01-02 06:14
Downloaded from link on main DietPi.com site:
https://dietpi.com/downloads/images/DietPi_OrangePi3B-ARMv8-Bookworm.img.xz

Checklist:

  • U-Boot Console Output: Yes
  • Errors/Warnings during U-Boot: No
  • HDMI Output: Yes
  • Errors/Warnings on HDMI: Yes*
  • OS Starts, configures: Yes
  • NIC Picks Up DHCP: Yes
  • NIC Auto-negotiates Gigabit; Yes

Notes:
On HDMI output got the following error but boot process continued:
[FAILED] Failed to start systemd-modules-load.service - Load Kernel Modules

Bootup froze for a long time after:
[ OK ] Started systemd-rfkill.service - Load/Save RF Kill Switch Status.

Eventually it output the following:
[FAILED] Failed to start ifupdown-pre.service - Helper to synchronize boot up for ifupdown.

Followed By:
timed out waiting for udev queue being empty.

Otherwise it booted up fine, read the config file, and configured itself no problem.

Logged in, /proc/version shows:
Linux version 6.12.7-current-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP PREEMPT Fri Dec 27 13:02:20 UTC 2024

Log is attached as “20250102 - DietPi_OrangePi3B-ARMv8-Bookworm.log”

20250102 - DietPi_OrangePi3B-ARMv8-Bookworm.log (55.1 KB)

Test Case 2 - New DietPi Bullseye Image

RESULT:
FAILED.

Image:
DietPi_OrangePi3B-ARMv8-Bullseye.img.xz File Date: 2025-01-02 06:11
Downloaded from images listing
Index of /downloads/images

Checklist:

  • U-Boot Console Output: Yes
  • Errors/Warnings during U-Boot: No
  • HDMI Output: Yes
  • Errors/Warnings on HDMI: Yes*
  • OS Starts, configures: No
  • NIC Picks Up DHCP: N/A
  • NIC Auto-negotiates Gigabit; N/A

Notes:
Expected this one to fail. Perhaps it shouldn’t get generated at all?

Error on HDMI output:

[ TIME ] Timed out waiting for device /dev/ttyS2
[DEPEND] Dependency failed for Serial Getty on ttyS2

Then it continued but it got stuck after:
[ OK ] Reached target System Time Synchronized.

It was stuck on:
[ *** ] A start job is running for Coldplug All udev Devices (11min 1s / no limit)

I killed it after 11 minutes of waiting. Never got to a login screen.
Log is attached as “20250102 - DietPi_OrangePi3B-ARMv8-Bullseye.log”
20250102 - DietPi_OrangePi3B-ARMv8-Bullseye.log (47.3 KB)

Test Case 3 - New DietPi Trixie Image

RESULT:
PASSED.

Image:
DietPi_OrangePi3B-ARMv8-Trixie.img.xz File Date: 2025-01-02 06:29
Downloaded from images listing
Index of /downloads/images

Checklist:

  • U-Boot Console Output: Yes
  • Errors/Warnings during U-Boot: No
  • HDMI Output: Yes
  • Errors/Warnings on HDMI: No
  • OS Starts, configures: Yes
  • NIC Picks Up DHCP: Yes
  • NIC Auto-negotiates Gigabit; Yes

Notes:
By far the fastest startup with the fewest issues.
In less than 30sec it was up, with an IP, and pulling updates.
No warnings or errors seen in HDMI output (though it went by so quickly).

Logged in. /proc/version shows:
Linux version 6.12.7-current-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP PREEMPT Fri Dec 27 13:02:20 UTC 2024

Log attached as “20250102 - DietPi_OrangePi3B-ARMv8-Trixie.log”
20250102 - DietPi_OrangePi3B-ARMv8-Trixie.log (55.4 KB)

Since the “issues” with Bookworm weren’t breaking issues, I’m OK with the state of things as they are. I’ll probably run with the Trixie image though, since it ran the cleanest. I’ll leave it up to others whether the Bookworm issues should be addressed or left.

Just have to see how things ran on @w568w 's v1.1 board to see if it’s similar.

If anyone knows how to capture the output that goes to HDMI that isn’t sent to the UART let me know and I’ll re-test and capture that info (or if there are additional logs anyone wants to see).

1 Like
15

Sorry for late response. My Orange Pi already has data on it, so formatting the partition and reinstalling is a tough task for me.

However, I noticed that linux-dtb-edge-rockchip64 has been updated, and running apt upgrade upgraded me from 6.10.6-edge-rockchip64 to 6.13.0-rc4-edge-rockchip64. I checked the updated dtbs directory and here it is:

# ls /boot/dtb/rockchip/rk3566-orangepi*
/boot/dtb/rockchip/rk3566-orangepi-3b.dtb  /boot/dtb/rockchip/rk3566-orangepi-3b-v1.1.dtb  /boot/dtb/rockchip/rk3566-orangepi-3b-v2.1.dtb

After rebooting the device, everything seems to be working. So I think it’s been fixed. Thanks for your efforts @MichaIng !

Upon reviewing the logs you uploaded, it appears that sprdwl_ng, the WiFi kernel driver module for the Unisoc/Spreadtrum platform, is continuously throwing errors. I think the module included in that kernel has some compatibility issues with v2.1, which is working fine on my end.

1 Like
16

Thanks for testing guys!

And indeed sprdwl_ng was also my first guess to make systemd-modules-load.service fail and udev to not settle, as it failed to load in various different circumstances on Orange Pi Zero 3 and 2W as well. Sometimes it was needed to load the related Bluetooth module sprdbt_tty, sometimes the other way round, sometimes it did load via /etc/modules-load.d only, sometimes via modprobe after boot only. I currently do not find the source code of the driver, can someone share:

modinfo sprdwl_ng
modinfo sprdbt_tty

And check whether

modprobe -r sprdwl_ng
modprobe sprdwl_ng

works without throwing errors, or

modprobe -r sprdwl_ng
modprobe sprdbt_tty
modprobe sprdwl_ng

instead, and whether the onboard WiFi interface even shows up?

ip l

On subsequent reboots, if WiFi is not enabled explicitly, /etc/modules-load.d/dietpi-enable_wifi.conf should be removed (which loads the module so that WiFi can be configured automatically on first boot already). Hence subsequent reboots are faster, without the failures/hangs?

EDIT: Ah, that driver is patched into the kernel, but without a transparent source, only a huge patch file, and complex conditional follow-up patches:

Makes sense that it behaves so inconsistent, and breaks every now and then, as long as it is not mainlined (merged into and maintained within mainline Linux).

For completeness, most recent 3rd party driver source, which, based on commit text, has support for Linux 6.11: GitHub - SUISHUI/uwe5622_driver: uwe5622的内核驱动
We could apply all the Armbian patches, do a diff between the resulting source and the one, and add another patch :smile:. Not something I find time and mood for any time soon, just an idea, especially if the driver causes issues on other SBCs with Linux 6.11 and up as well.

1 Like