ROCK 5B Debug Party Invitation

I received my M2->PCIe adapter and could test a 10G card. Well, it’s an old one (myricom) because I didn’t expect to receive it on friday evening so I didn’t have a better NIC with me at home.

It was first not detected, but it was OK after a reboot. I figured that the NIC seems to take time to boot, and since the board starts much faster than a PC, it’s likely that it tries to detect it while the NIC isn’t ready yet. That’s not a problem, though, once you know it.

The transfer reached 5.5 Gbps with HTTP traffic, and just 3.2 G under iperf3, which is still correct (BTW the board only supports PCIe 2.1 so it’s doing 5GT/s x 4).

However I was seeing lots of warnings in kernel logs, that were slowing the transfer down. Disabling GRO reduced them. I don’t know if they come from the driver or the network stack, but given that the BSP kernel lacks 6587 stable patches and possibly got other ones incorrectly merged, it’s hard to tell.

I’m currently trying to update the kernel to 5.10.131. It takes ages and I’m prepared to have to manually fix 127 conflicts :frowning:

I’ll continue testing with some intel NICs from work to see if that works better.

5 Likes

#RockchipIsNotLinux :smiley:

I dealt with this on the Tinker Board when I was maintaining the 4.4 kernel. Never again.

That is cool. Can you monitor the voltage rails during a cold power-on to see if it timing or power related on the startup issue?

We already argued with him about this in original rock5 thread. So yeah, he just straight ignores any positive thing about PD, that’s why i think he is old, because usually olds are most stubborn, when new technologies appears

Why drag it in here and make yourself look petty and derail a conversation?

Admins feel free to delete this post, and hopefully Dante here agrees to let his be garbage collected as well, it’s not beneficial to this discussion.

3 Likes

Yeah I know that rockchip is not linux, sadly. A long time ago I said “never rockchip again”, and repeated it several times. But nowadays they’re the last ones to try to produce more or less up-to-date hardware, and they’ve at least always had decent I/O. So I got tempted again, but each time it’s a nightmare. I don’t know why they’re punishing their customers like this :frowning:

Regarding the NIC, the voltage is stable because it comes from an external power supply :slight_smile:
I’ve had several large boards that were not detected initially, and given that they were all using a PCIe x8 connector, I initially thought it was related, and I tested only once then unplugged the power to replace them. But all these boards have in common that they’re slow to initialize. Two other small NICs are fine at boot.

2 Likes

Its very early days and each iteration Rockchip seem to be getting better, I quite like what they have done with the RK35 range and guess much is implementation.
Still waiting to see if they can direct and push for faster mainline kernels than almost be EOL when 100% complete :slight_smile:

By the way, for those who would like to go in that direction, there are a few things to be careful about.

First, the adapter I bought was open-ended on the photos, but was definitely not when I received it, so I had to cut one side and the result isn’t pretty at all (I slightly damaged one GND pin but it’s not shorted so there’s no harm).

Second, the board is extremely thin (probably 0.5mm or so), and as such the pins are very long on the other side:

And they almost touch the board! You cannot even think about pressing the board to connect anything, it WILL touch and bring 12V directly into the CPU’s capacitors:

Note that it’s not a design issue of the ROCK board, which seems to respect the specified clearance (and if not pressing it’s OK), it’s mostly a limitation of such cheap adapters that often need to be adjusted in field. It’s simple enough to cut them and avoid the problem, and I would really encourage anyone willing to test such a board to do that:

Also the adapter brings the 5V (or is it 3.3?) from the main board, but the molex connector is there to bring 12V for power-hungry boards, but gigabit-class devices do not need it. The 5V pin is not connected to anything, only the 12V one is used.

2 Likes

Testing USB-storage brings me lots of errors. I first tested with a Crucial X8 1TB SSD which works pretty fine everywhere else (400-450 MB/s). Here it doesn’t even appear in block devices due to USB errors. I tried a dirty USB->SATA adapter on a 64G SSD. This one is recognized but I’m seeing variable transfer rates with resets in logs:

[ 8163.656569] sd 0:0:0:0: [sda] Attached SCSI disk
[ 8322.441612] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[ 8322.459211] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s
[ 8322.459236] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 06 2e e0 00 01 00 00
[ 8322.459247] blk_update_request: I/O error, dev sda, sector 405216 op 0x0:(READ) flags 0x80700 phys_seg 7 prio class 0

When connected to a USB2 port, the Crucial SSD is recognized but doesn’t respond to a read request, which ends in a timeout. I’ve also had errors previously but I forgot to store them before upgrading the kernel. The usb->sata device works fine on the USB2 adapter though.

I thought about power issues but I’m using a USB-C input from a lenovo laptop power block which visibly delivers 12V thus I really don’t believe in powering issues:

[ 1.893510] reg-fixed-voltage vcc12v-dcin: vcc12v_dcin supplying 12000000uV

I’m far from being a USB storage specialist. I’ve switched from schedutil to performance to exclude all possible causes from too slow or sleeping CPUs, but for the rest I have no idea. I think it’s definitely a joke on the USB side. I should find a PCIe USB3 adapter to test again (I just figured that the one I had is in pure PCI, not PCIe :slight_smile:).

Ah another point I’ve just connected it via a USB power meter that shows me 5.15V. Now it appears in USB2 (since USB3 lanes are not routed) but still freezes when attempting to read.

Yeah as I would prefer otherwise but likely what I would use, my preference would be an additional barrel or whatever power connector that isn’t on the main IO plane maybe a vert connector that is useful for enclosure mounted psu’s.
Just a wish and yeah I did mention I had reservations about PD, but do really like the idea of also having a 12v rail, which I can with be certain of irrespective of software even if it means a pretty sh itty barrel to usb-c adapter.

1 Like

It’s a great preference when things work as expected. Probably a bad time when they won’t.

Travel with your SBCs frequently?

or sometimes their experience makes them less responsive to the sirens of marketing and all those who want to sell you upgrades you don’t need in general and that you regret later :wink:

Well. It’s actually is, because if there is only one opinion - there is no progress. So I’m on PD side and providing argument purely from customer side. PD (and Type-C by extension) is universal (you can use notebook charger for this sbc, or your phone charger), popular in mass market and stable. Stua provide opinion about DC barrel, which is have different types of barrel, unpopular in mass market and stable. Stua continues to push DC barrel, which is provides nothing. It was already said:

So, finish. No need for further investigation regarding it, unless you are a kernel coder. But welp. Stua didn’t stopped, so here i am. Going in circles.

Thankfully, PD is one of the thing that actually useful, available in mass market and allows you to get multiple kind of voltage from one brick. So it’s clearly not the case here

Every 3-4 months or so. The UPS for mini web-server and torrent share is also good, since sometimes i get power outrage and I can still get my router (zyxel) + SBC (5tb ssd) powered on with ZMI usb UPS

There is more context in the thread if you go further backwards. Keyword FUSB302

TLDR is there’s a lot of pain assuring graceful negotiation of USB-pd voltages at power on and THEN handing it off control of FUSB302 to the Linux kernel at the later part of the boot stage.

Resets, boot loops, low voltage handshakes etc are all things that have been witnessed.

Above things are what can happen when one approaches the present situation with “it’s USB-PD it should work.”

2 Likes

Willy, regarding m.2 to pcie - maybe something like this will do better job:

Link is just example of what i used, they are not that cheap, but really good for SBC with m.2 slot

Yes, I do read whole thread before answering it. That’s exactly why i mentioned “kernel coder”.

And it was mentioned, that FUSB302 is part of reference design:

So, yeah, your proposal is stepping out of reference design? Following reference design = more likely to be accepted in kernel, since that’s how thing get supported. Unless you are someone like Apple and can create your own OS from scratch and support it.

Does FUSB302 is problem? Maybe. Can it be fixed software wise? Yes. Does PD is problem? Clearly not. Is it simpler to buy 35W PD charger over 12v charger in mass market? Yes.

Rockchip’s reference design for what?

a tablet?
A chromebook?
A single board computer without a charge controller that’s meant continuously attached to a wall-connected power source?

1 Like

Precisely.

Nope.

Just because some SoC vendor decided to make a faulty reference design and an SBC vendor followed it faithfully does not overcome the fact it is a faulty design. There is no chance of it being accepted upstream if Radxa themselves do not do the work, and if the maintainers decide a fundamental change to the tcpm state machine is in line with their philosophy. This same topology has been in the field with another SBC with no progress for years. No one cares about “yet another SBC”. Another prominent vendor has a separate chip running the FUSB302 to avoid the entire kernel nonsense. I could begin up streaming it tomorrow. This one? No chance, even with the SoC support merged. The mainline support would be “plug your 12V barrel jack into your Type C adapter or this board will not function”, which I think we both agree is suboptimal at best.

Yes.

Maybe.

Philosophically irrelevant. The board can’t use it as it stands. Once it can then your seemingly religious interest in it can be discussed at length. Until then it is like complaining that solar is the superior power generation technology during monsoon season at night when someone starts a gas generator.

The discussion is done. It needs redesigned, or Radxa needs to invest in a new tcpm and fusb302 driver for upstream. I will get an adapter plug in the mean time to use a bench supply. My other FUSB302 based power delivery SBC is powered via PoE because the type C implementation is a failure.

2 Likes

Plus it’s less trivial to produce or extract power following that standard. With the barrel connector, you just connect a battery to the wires and you’re done. With USB-pd, you need one negotiation board on the consumption side, and when you want to produce it gets much more complicated with DC-DC converters and components that are not easy to find. I made a small UPS for my ADSL modem which, thankfully, uses a barrel connector. I couldn’t have done that as easily if it were relying on USB-pd.

2 Likes

I agree, I’ll probably order a similar one. I have a PCIe x1->x16 adapter with a soft cable but didn’t want to use it here for obvious reasons. I thought I could buy an x4->x16 but that’s useless for anything else, so it’s more interesting to pick one like the one above, dedicated to M.2.