ROCK 5B Debug Party Invitation

#248

For me its just pure bad design that market forces push PD that has zero advantages as generally you can not use that PSU with multiple devices because its singular use and in use on your SBC.

Its steals the USB-C port for power, so we are a USB-C down which has a whole load of uses.
The upshot for me is I am wondering depending on price if I should dump that redeem code and do something I don’t usually consider as call them ‘strange fruit’.

https://www.cnx-software.com/2022/07/22/banana-pi-bpi-w3-an-rk3588-sbc-with-dual-gigabit-ethernet-pcie-x4-slot/

Or maybe not buy one and see what they do with the Rock5A

For me Radxa have just got the intended destination wrong with the RK35xx series where the RK356x ended up as general purpose SBC whilst they likely should of been specific application boards and trimmed down in cost for that application only.

The tunnel vision on PicoItx and creating a latop motherboard and not a desktop motherboard also have me wondering about the Rock5B.
Radxa probably want to showcase a design they can offer to a possible netbook/tablet market which is a shame as for me this could of been a very pro market desktop like Arm low energy version at very reasonable cost.
I haven’t seen a Rock5A but much of the current design in terms of power should maybe of gone in that and the Rock5B be more of a classic desktop design and give more differentiation between the products as well so they are not pitched in the same place so much.

That is my final thoughts and after being initially very enthusiastic I may dodge this one like I did with the RK356x boards.
Guessing a Rock5A might be more like what I expect and where I intend to use, maybe even might have the battery circuit it expects onboard.

#249

I disagree with you. In my opinion the target here is customer of low-end x86 boards. It has similar connectivity and extensions. OK it doesn’t have the barrel power plug and sacrifies a USB-C instead. There’s no awesome solution, as you can see, some are strongly for it and others strongly against. But in general I don’t see this board as ending in a tablet. However it can certainly appear in NUCs and equivalent general purpose devices that end up in media players, storage servers, small always-on desktops, ARM development machine (since native build is quite acceptable here), well, in fact about everything you normally do with a small x86 board featuring a fanless Celeron in pico-itx form factor. I think it intends to be generalist instead of elitist, but will definitely not address single use case. I too tend to prefer barrel connectors because they’re easy to duplicate without having to bring one power adapter per device and various other reasons. On the other hand, if it’s not a wide range voltage input, you can easily fry your board or get angry by not finding the suitable PSU. The best options I’ve had today were with 7-20V inputs where you can plug absolutely anything. But that’s not always possible.

1 Like
#250

I seem to have clicked the wrong “reply” button, this was intended for Stuart :slight_smile:

#251

BTW, I “finished” porting all missing 6500 fixes from 5.10.66 to 5.10.131 to the rockchip kernel. What an horror! They included some fixes but decided they would be better placed at other locations and in other files. There are also plenty of changes affecting core stuff like kernel/sched/core.c, and they even missed a number of fixes that ought to have been there in 5.10.66, which is expected for a kernel that was forked in 2.6.32. So you find fixes which fail to apply because a spinlock was expected just before, etc…

So in short, that kernel is rockchip-whatever but not linux. Of course I tried to build. I fixed some of the early build issues but I’m giving up for now. It took me 8 hours watching the patches fail and trying to figure what was missing or why some parts were modified, in order to fix them, and resolved ~120 conflicts. Of course I don’t trust my work, but I trust theirs even less. It will become urgent to get this SoC working in mainline, because for now it’s as scary as an HDMI TV stick running Android :-/

Anyway, what could I expect from a kernel differing from mainline by 10 MILLION lines and 350 MB ?

$ git diff v5.10.66 rock5 | wc 
10562537 43662094 354140459

I may try again later, by first trying to isolate non-driver stuff (and possibly revert it).

4 Likes
#252

Rock5a likely will be my choice for that. Rock5b end up in no-mans land for me.
That is what I am thinking and what I might do with my $ and said purely for feed back to Radxa.
PS you can anything from 5.1v-26 via a dumb usb-c adapter but it steals the usb-c and that is just dumb to me.

#253

Maybe we’d need a pair of DC-IN holes and either a Shottky diode or a jumper to allow to free USB-C.

1 Like
#254

I think I have made my mind up and likely will just pass and see how the Rock5a is, as for a micro server think I may use something else.
I like the rk3588 though and rockchip have done a great job.

#255

I hope you’re aware how crappy USB3-A connectors are. It’s probably the most shitty connector ever invented due to the tiny SuperSpeed data lines on the edge of the connector (ensuring even slightly bent cables resulting in data errors/corruption).

Hardkernel had some QA issues half a decade ago where users were asked to clean contacts with an alcohol tinctured Q-tip. Maybe that already helps.

#256

What should’ve been done at Rockchip to prevent this?

It’s time to market and upstreaming stuff in the ARM Linux domain takes years even if the SoC vendor is willing to contribute. The whole process is a shit show and everyone involved knows this. See André’s presentation years ago

Upstreaming is broken. Period.

At least for a SoC vendor interested in the ‘Android e-waste’ world trying to sell millions of chips and not just a few for another target audience willing to pay the price.

#257

I can try, but I doubt it given that the exact same connector works fine on all other machines. I was wondering if that could be caused by an incompatibility with UAS, but since it’s compiled-in I can’t unload a module and am not sure I can disable it at runtime to test. Thanks for the tip anyway :slight_smile:

#258

Edit: Sorry I first read “what should have been done at Radxa”. New response instead:

They should at least maintain their kernel up to date. Rebasing new major versions instead of merging would automatically get rid of all merge mistakes of the past so that they don’t drag a 10-years history of failures that will never ever be fixed since the mistakes were what was committed as the way to resolve merge conflicts. It would show them that a number of their patches are unnecessarily painful to rebase and would deserve being upstreamed. That’s how everyone else proceeds, including distros. For sure it’s more work at new major releases, but it’s the price to pay when you don’t want to upstream your work. Instead, any bugfix that fails to properly apply is definitely lost in their current kernel, which is very likely vulnerable to plenty of bugs that were fixed years ago.

And their customers (board vendors) can’t do anything about it. We’re at the end of the customer chain and may be happy or unhappy and complain, but they’re in the middle in an even worse situation since they’ll collect customer complaints for instabilities and kernel bugs and vulnerabilities without being able to do much, just like any other rockchip-based SBC vendor.

That’s clearly the point. The only way to fix it is if everyone was refusing to buy hardware not running on mainline, to put the pressure on SBC vendors to reject SoCs that don’t have good software support yet. But as you say, there’s always the Android e-waste channel to spread unfinished products to the market without ever having to care about finishing the job. And again, Rockchip is not the worst one here, at least they have datasheets.

This crap wouldn’t exist in the x86 world because everyone expects the default ubuntu/fedora/whatever image to boot fine. Even just having to add a non-mainline network driver is sufficient to discourage many customers.

In the ARM world this may only change when some vendors can boot the standard distro while others still require their own variant. This will create some pressure. But we’re stil far from being there.

3 Likes
#259

In this silly SBC world everyone is prepared to blame UAS but AFAIK only some drive firmwares are really broken. The ones I added to Armbian years ago you can find here. Maybe Crucial has to be added but I highly doubt it based on the error message you report.

You can provide USB storage quirks as part of kernel cmdline as can be seen in the link (the way I added this to Armbian relies on a config file that gets expanded over time to UAS blacklist external Seagate and WD USB3 disk enclosures asides the static Norelsys definitions that might be irrelevant today since they got their quirks as part of more recent kernel releases).

1 Like
#260

Vendors are releasing for mainline but the preference is mainline android and not linux as the potential market dwarfs linux.
Android 12’s latest LTS is 5.10 and hence why we have a 5.10 BSP and its messy in the context of Linux as really its just a fudge of an Android 12 base kernel.

Everything is due to the size of the herd be it user or market and if the herd is small often resources are and the road long.
If you look at what has happened with the new Apple silicon that has a sizeable herd so that the likes of Asahi Linux who are already at work on the M2 and pushing much to mainline.

Rockchip obviously sees a larger herd on Linux than before as over the last 2/3 years Linux is getting more billing even though Android still has main focus.
Finally even rkvpu & vga arrived and it should be interesting how long the rk35xx range takes to go mainline but apparently the likes of Collabora have just received hardware and there are various sources all just recently released.

That is an extremely chicken & egg statement and say take that into the context of the new apple silicon as good luck in getting everyone to refuse to buy it.
Mainline has always followed product not the other way round ever since wintel ruled the roost and product is always likely to arrive before mainline and only product with sizeable herds will get accelerated adoption where smaller herds get to a point where they may be partial or never adopted.

Current litmus will be the RK35xx range and the speed of input from Collabora & Rockchip.

#261

Excellent, exactly what I was looking for. I’m not even trying to blame UAS, I’m just trying to bisect the problem. I suspect the USB controller doesn’t work fine, but given that there remains this specificity, I first want to retry without it. Thanks!

#262

So that worked, it could indeed disable UAS and allowed the test to start, around 240 MB/s:

[82424.008416] usb 8-1: UAS is ignored for this device, using usb-storage instead
[82424.008428] usb-storage 8-1:1.0: USB Mass Storage device detected
[82424.009484] usb-storage 8-1:1.0: Quirks match for vid 0634 pid 5600: 800000

But it didn’t last long, after 3 seconds it stalled and I got again these errors:

[82443.984389] usb 8-1: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[82444.001871] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s
[82444.001963] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 10 42 e0 00 01 00 00
[82444.002002] blk_update_request: I/O error, dev sda, sector 1065696 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0

Thus this confirms that UAS has nothing to do with the problem, at best it’s more sensitive and emphasizes it by not working at all, but there’s definitely an issue with the USB implementation there. I’ll eventually look at the kernel to see if there are any recent patches applied to the USB controller, as this SSD works fine on the RK3568 in the stationPC-M2 which I suspect uses a similar USB controller.

#263

About PD, this seem not a driver problem but a wrong hardware choice. Fusb302b is set to not working at reset, and PD charger cannot detect fusb302 when power is plugged. And only after kernel finishes booting when fusb 302 is configured. It’s too late for PD negotiation. This causes kernel choose to send hard reset signal to charger. Hard reset would make charger to reset power output causing a temporary power loss. And capacitors on board cannot hold this power loss. Though rockchip has integrated fusb302’s driver into uboot, but according to @amazingfate this couldn’t completely avoid board’s reset during booting.

1 Like
#264

Seems that changing to a PD controller with external flash support might help, but only ti ‘s tps659xx could support this and it might be a pain to migrate for radxa, since its designed for notebooks’ typec port which needs dedicated typec mux for dp/usb3.

#265

After checking for schematic of 5b, I found that radxa is not using raspberry pi’s CSI and DSI ports. A converter is needed when using rpi’s camera and screen. Radxa has added some power supply pins of different voltage and synchronization clock pins for dual-eye cameras. I think it would be better to add another fpc connector for those extensions with raspberry pi compatible CSI and DSI ports rather than current port.

1 Like
#266

The design is expecting a battery but as a usb-c and charging port it works great, just not so great the way its been implemented.
Trying to force the board into this non existent Pico-Itx format that it isn’t totally compliant is the boards Achilles heel.
For me it seems crazy to cause all these problems purely for might be a 10-20mm size increase for a better CPU mount & external power and not robbing all the great functionality of the USB-C for input power.
Radxa are going to end up with 2x rk3588 boards of the Rock5a & Rock5b in a very similar sales space so much so that my opinion is to dodge the Rock5b and wait out for a Rock5a as the loss of PCIe3 isn’t that a big a deal (for most parts a pcie x4 nvme is still a miss match to the level of the cpu) for the low cost. low energy mini desktop role it will provide extremely well.
Rock5b just lacks that touch of micro-server functionality and its a shame as its very close but what it does miss has big effect, so yeah my redeem code was only $5 but I am not going to bother.
Rock5b aint bad but for my use I am thinking the Rock5a with a guestimate of what it might be is a much better option.
PS Radxa with the Rock5A having a battery connector and circuitry instead of capacitors would be amazing and also the gpio maybe have it at 90’ than vertical?

2 Likes
#267

Seems what is blocking 5b’s release version is just typec. It cannot boot at all on some pd chargers. What I cannot accept are non-standard CSI and DSI ports. There aren’t much CSI/DSI devices to use in the market and most of them are using raspberry pi’s ports. This means we need to convert port for almost every device.

1 Like