Radxa 5b - where do I start? - 5 major problems?

Can someone please explain the following:

  1. Radxa 5b is slower than OrangePi5 and Mekotronic R58 despite same RK3588 CPU?
  2. The Power supply issus - a standard phone charge adapter will not provide enough power - only a super high wattage adapter. Is that the cause of boot loop?
  3. Many of the software offerings don’t start up - go into reboot. Why is Ubuntu desktop only in the github? Having stumbled on it, it does not work anyway? Loading ubuntu minimal and attempting desktop add-on does not work - why is that?
  4. M.2 wifi and usb wifi dongles will not work because of driver issues - customers should be told only to buy the radxa approved ones - drivers need kernel recompile and then still don’t work because of blacklisting. Gosh
  5. Expecting the average user to get the SPI flashed is a stretch - why is this even necessary to allow NVME drive boot? - I got NVME boot working despite the poor instruction, but then it won’t boot from SD, do I need to erase the flash?

Please help

3 Likes

1 - Bullshit.
2 - Power Supply like I said plenty 45W Samsung is the wey or u can go pi 4b PSU as many say.
3 - Not entirely sure… it always worked for me the only issue I had was OpenFyde but that was cause I wasnt flashing it properly and after an spi flash it cleared all my reboots (on this particular OS).
4 - No A8 Module works straight but some users dont plug them their antennas… what doesnt and requires a terminal input is the bluetooth. For AX210 yes I think its only drivers whats required (not sure if wifi works straight I think so). I dont know about usb wifi dongles…
5 - I cant help it as I am still to buy an nvme for my testings.

I would say here is a good start: All-Images-Depot Rock 5B

2 Likes

Nope, that’s just few Youtube reviewers ignoring the difference settings make.

Rock 5B ‘got slower’ when Radxa enabled the DMC governor in their own kernel sources which resulted in ~600W lower idle consumption since now DRAM is clocked most of the time at 528 MHz while the Orange Pi OS images use the older kernel settings and therefore faster benchmark scores are generated with DRAM at 2112 MHz all the time (with the Mekotronic thing it’s most probably the same).

The new Radxa default settings (uptreshold=40) result in DRAM clock not ramping up fast enough when needed and as such benchmark scores now are lower than they were back last year when we early adopters tested with Rock 5B.

Click here for all the details.

4 Likes

So NOT true…

  • OrangePi5 has RK3588s chip
    Radxa Rock5b has RK3588 (more i.o. exposed/available)
  • From my testing, Rock5b has been considerably faster using Armbian and RebornOS
2 Likes

Well, then your testing is somewhat flawed or you need to ask those Armbian and ‘RebornOS’ people why their settings suck on Orange Pi. Since unless you do storage benchmarks where the RK3588 with its rich I/O capabilities can shine RK3588 and RK3588S perform the same. All differences in benchmarks are due to different settings/software as explained above or thermal throttling.

In fact I’ve not found any method so far to determine whether software (in this case my sbc-bench script) is running on a RK3588 or RK3588s.

1 Like
  1. NVME Boot and SD not working, see here:

happy with mine, just wish there was more support

I currently just use mine to serve up hard drives over the network with nbd and it’s nice for that for sure, very stable and fast, I also use it as like a place to run xterminals with x2go server I can leave it up all the time, reboot my main pc and come right back to them etc and run basic graphical apps as well. I’m also using it to compile openwrt images

definitely would like to get a mainline kernel going at least where the onboard lan and usb ports work, it concerns me a little this kernel shows a serial number in cpuinfo i’d probably like to blot that out if possible

1 Like

Why does it concern you?

BTW: it’s not directly the SoC’s serial number, it’s two CRC32 hashes over different parts of the serial combined: https://github.com/rockchip-linux/kernel/blob/develop-5.10-rt53/drivers/soc/rockchip/rockchip-cpuinfo.c#L87-L91

1 Like

@May1964. Yeah I’m with you on this. Don’t mind the usual suspects on here pushing back on your comment, they must be paid to monitor this tread and “explain” everything lol! Yet this board still struggles accomplishing the simple no brainer common sense easy to do stuff like power on and run consistently lmao!!! Nvme booting is trash. A comprehensive list of working SD cards would be helpful. I mean come on Radxa! This board came out in June and it still struggles preforming simple tasks. I also know YouTubers like Taki Udon and ETAPrime have a whole heck of a lot of more influence than these bubble heads on this thread attempting to make us believe everything is A ok with the board after several months is crazy. Wow

you need to remember that this a hobby board. It is not being marketed as open package plug in and run device. I have a windows only background and I’m liking it. Is it hard for me? yes. Do I need to research what terms like, uboot, spi, maskroom are? yes. However that’s part of the journey. The potential is there and I’ve found this board to have it.

1 Like

I think many people here are assuming the Rock 5b is just a more powerful Raspberry Pi 4. It is not, nor is it being marketed as one. This board WILL NOT work perfectly out of the box. If you are new to Single Board Computers, and ESPECIALLY if you’re new to Linux, buy a Raspberry Pi instead. You will have a much more pleasant experience. If you are willing to tinker and learn, this board is great, but do not expect it to be plug and play. For me, this is probably the best SBC I’ve ever owned and I like it a lot more than my RPi 4 boards. For the average person who has never or rarely used an SBC, this board may not be what you’re looking for.

1 Like

Mine has been running consistently for several months now without any issues. Yes, NVMe boot doesn’t work out of the box, but it does work perfectly once you flash the SPI ROM. I’ve been using it and it’s worked reliably every time. Flashing the SPI ROM isn’t a difficult task for anyone with a little in-depth knowledge of Linux, by the way. Every SD card I’ve tried has worked without a problem. This is why we’re saying that this board is ok, because it is. I am certainly not being paid to say this, I am simply providing my own experience. For a beginner, this board isn’t and will never be great, which is fine for me, because I’m not a beginner. If you are (such as if you’ve only ever used an RPi), and you are not willing to do some research, learn, and spend a few hours tinkering, this board isn’t and will likely never be for you.

We have incorporated the suggested DMC tuning to our code. It should be available in our next ROCK 5B image release.

6 Likes

ah, well I honestly didn’t mind if it was a bit slower and lower idle power, it honestly is an amazing piece of hardware for low power I/O. Currently mine appears to sit at 1 watt idle which is kinda insane.

Also alot of problems seem to be getting fixed pretty fast with armbian anyway, the first image I used seemed to have a problem with network speeds in one direction (I wasn’t the only one I saw someone made a youtube video with the exact same speed limitation) but it got fixed the next time I tried a new image

The stuff about usb dongles it’s a bit weird you can’t always blame the soc for linux usb problems, especially with wireless. Not sure what problem you have there but mediatek stuff tends to work, if it doesn’t there’s always going for a kernel recompile with the mt76 driver from the openwrt github. I haven’t had any issue with SD cards either.

LOL! Armbian does close to nothing here. Quite the opposite, if you read ROCK 5B Debug Party Invitation again you will realize the Armbian guys only whining about HW details like USB PD and them not touching anything related to the 5.10 BSP kernel majority of Rock 5B users will have to use for many many more months or even years.

But since they rely on Radxa’s kernel repo since day one everything that gets fixed there is automatically inherited in Armbian after some time.

That was just an inappropriate PCIe ASPM default in Rockchip’s kernel. Reported as first issue/suggestion here in this active device review and fixed by Radxa within days. As such once Armbian updated their kernel packages the fix arrived there too.

Next issue Armbian will automatically inherit by using Radxa’s kernel and being from the very same aforementioned list of suggestions is this here. This will then also allow Orange Pi 5 running with Armbian to perform better since currently when using Armbian and not the crappy Xunlong OS images performance is harmed by the uptreshold parameter.

In fact, this is not fixed in Armbian, because it uses a different defconfig. I’m going to go ahead and file a fix…

Update: filed https://github.com/armbian/build/pull/4835
Update2: merged. See, you can easily contribute. :slight_smile:

Which is the Best OS for you to use in Rock 5B?

Since you’re familiar with Armbian’s build system you can do this to see how much I already contributed:

git log | grep -E -c "Author: ThomasKaiser|Author: Thomas Kaiser"
541

Most probably there’s a reason why I don’t want to be associated with ‘ignorance and stupidity’ any more?

No idea since me ignoring everything around GPU/NPU and so on. For (my) headless use cases it really doesn’t matter since all the OS images base on same BSP kernel anyway.

Armbian has some abandoned tweaks more or less by accident that are sometimes ‘better’ than Radxa’s defaults but that’s all. But these tweaks are abandoned, nobody at Armbian cares about this stuff and for example as such if the kernel/scheduler sends an I/O intensive task to cpu4 it will be fast with Armbian while when the scheduler sent it to cpu7 it will be slow. And they’re not going to fix this ever judging by status of this issue/task/whateverBS: https://armbian.atlassian.net/browse/AR-1262

And the most funny part about all of this is this excercise in ignorance: my suggested code that reflects the situation with hexa and octa core SoCs like RK3588 has already be copied into the Armbian script that does all these sorts of things: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L78-L93 – But only for a fraction of devices, all the others use my old code that is sitting directly below. :rofl:

With Radxa’s OS images I/O will always be slow(er) since the usual amount of ignorance: https://github.com/radxa/kernel/commit/55f540ce97a3d19330abea8a0afc0052ab2644ef#commitcomment-79484235

2 Likes

For a layman, what are the steps to be implemented and by whom before we can see proper hw support?

The current Rockchip 5.10.110 BSP kernel provides ‘proper hw support’. You won’t get better ‘hw support’ from anywhere within the next 5 years since this BSP kernel (board support package) is the result of Rockchip software and hardware engineers working together to support their hardware as best as possible. In fact, ‘proper hw support’ will get much much worse the next months when running with an ‘upstream’ kernel.

The ‘layman TL;DR’ is: in general it’s fine.

This thread here started with 5 issues of which the 1st is just Youtube reviewers having no clue as almost always (‘Radxa 5b is slower than OrangePi5 and Mekotronic R58 despite same RK3588 CPU’) followed by the others that boil down to:

  • Radxa still hasn’t resolved USB PD powering issues (2 and 3)
  • not enabling drivers/modules in their kernel fork (4)
  • the board shipping in a shitty state if you want to boot from whatever storage (5): If they would’ve managed to flash the SPI NOR at the factory with something working to allow for booting from whatever storage as it’s default on x86 (where all of this is handled by a dystopian and horribly insecure monster called UEFI) then everybody would be fine and no more questions would be asked