ROCK 5B Debug Party Invitation

Yeah I would not swap the mounts to the 2007 PicoITX format as the mounts just steal I/O space and think that is one of the best features.

It would be great if they did a 1U panel as someone will do the math of how many you could fit side by side in 1U or more.
Thats why I like all the I/O on one plane as maybe I/O punch outs could be a thing but even Raspberry can not seem to keep to a singular compatible format.
Also the NVME mounts on board without some horrid riser in a bad attempt as a pseudo Pi format, is a huge plus.

Generally I like the format think its actually a big improvement on the Pi but doubt we will ever get a really universal format.
96boards was the same and also a sort of similar fail really.

Format wise apart from the cuteness of Zero type boards the Rock5B I would say is a definite fave.
That might be a Rock5A though as eagerly await whatever that maybe.

Maybe they might just do a single I/O punched out panel that is just a flat piece of thin steel with a big enough bezel (overlap) with mounting holes, that you can make a cut out and cover on any case, big enough?
More of a tidy than structural that just covers what makers may dremmel out?

I’m not disagreeing at all, I very much like the board’s layout. It just bothers me to call it Pico ITX. I can’t drill holes through a few sheets of acrylic in the same places and bolt them down, something necessary when claiming a form factor.

Exactly like the NanoPC-T4, which until now was my favorite form factor/optioned board.

Truly sticking to an existing standard beyond name alone helps. :wink:

2 Likes

Same not disagreeing, just doubting its possible as each SoC is so unique with I/O that sort of sets a format.
Maybe PicoITXish size is best we can do and have some things in the shop such as an I/O sheet maybe even a 1U multi Rock5b panel?

Generally I am loving what I see and maybe a few tweaks that are purely opinion.

Also maybe the onboard fan connector make it a more common JST 2.54mm as is it 2.0mm? My old eyes and vernier struggle.

It’s reporting the state of CC pins. AFAIK if there’s no USB PD involved CC pins can tell ‘5V @ 1.5A’ or ‘5V @ 3A’ so you need to blame your ‘DC-barrel plug to USB-C adapter’ for the state of CC pins?

Don’t you think this IC is there on all those RK3568/RK3588 thingies now since it’s part of Rockchip’s recent reference design?

And if situation with mainline kernel sucks a simple fix is needed, right?

I don’t think anything but V & Gnd is connected to anything on the DC-barrel female to USB-C as that is all they are.

There are some that go the other way and have a embeded PD chip to negotiate a voltage say 12v to a male barrel the other way but the female barrel to USB-C are just a pure hard wired adapter.
So would say that is the state reported when both CC disconnected maybe, would have to meter one out.

Done with Rock 5B for now as such I finished reviewing stuff.

Since I learned yesterday that relevant ‘development talk’ around Rock 5B is happening in closed Discord channels without any public log I simply give up.

If people babbling about ‘open source’ able to choose freely between IRC and Discord choose the latter it’s time to say goodbye. As if the Snowden revelations never happened. People seem to like surveillance and being tracked everywhere. Just insane.

I agree about IRC & Discord as the public log gets lost, choice is choice and if that is what they use, that is what they use.
Its a shame you have to act like a baby in a pram on anything ‘you’ don’t like as often the info you provide is of value.

I’m not blaming anything. The board is unaware of what is actually coming in, so the user needs to watch out for that. You are correct, the CC pins give the cable current capability, 1.5 or 3A

I’ve tried that fix, it does not solve the issue, which it actually says in the linked patch note.

Here is the discussion of the issue that I recall after trying several versions of what you linked and settling on running the board on PoE: https://lore.kernel.org/lkml/d3c847f7-2c8a-3cc0-00db-f46668fd83ca@roeck-us.net/T/

1 Like

I just got my rock 5b. I was wondering if someone can confirm the following image should work:
https://github.com/radxa/debos-radxa/releases/tag/20220717-1356

For me it seems to reboot at:

Starting version 245.4-4ubuntu3
[ 10.487112] rk-pcie fe190000.pcie: PCIe Link up, LTSSM is 0x130011
[ 10.487311] rk-pcie fe190000.pcie: PCI host bridge to bus 0004:40
[ 10.487329] pci_bus 0004:40: root bus resource [bus 40-4f]
[ 10.487343] pci_bus 0004:40: root bus resource [??? 0xf4000000-0xf40fffff flags 0x0]
[ 10.487356] pci_bus 0004:40: root bus resource [io 0x200000-0x2fffff] (bus address [0xf4100000-0xf41fffff])
[ 10.487367] pci_bus 0004:40: root bus resource [mem 0xf4200000-0xf4ffffff]
[ 10.487377] pci_bus 0004:40: root bus resource [mem 0xa00000000-0xa3fffffff pref]
[ 10.487418] pci 0004:40:00.0: [1d87:3588] type 01 class 0x060400
[ 10.487447] pci 0004:40:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[ 10.487512] pci 0004:40:00.0: supports D1 D2
[ 10.487523] pci 0004:40:00.0: PME# supported from D0 D1 D3hot
[ 10.498189] pci 0004:40:00.0: Primary bus is hard wired to 0
[ 10.498205] pci 0004:40:00.0: bridge configuration invalid ([bus 01-ff]), reconfiguring
[ 10.498447] pci 0004:41:00.0: [10ec:8125] type 00 class 0x020000
[ 10.498520] pci 0004:41:00.0: reg 0x10: [io 0x0000-0x00ff]
[ 10.498582] pci 0004:41:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit]
[ 10.498625] pci 0004:41:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit]
[ 10.498998] pci 0004:41:00.0: supports D1 D2
[ 10.499006] pci 0004:41:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 10.515079] pci_bus 0004:41: busn_res: [bus 41-4f] end is updated to 41
[ 10.515125] pci 0004:40:00.0: BAR 8: assigned [mem 0xf4200000-0xf42fffff]
[ 10.515135] pci 0004:40:00.0: BAR 6: assigned [mem 0xf4300000-0xf430ffff pref]
[ 10.515144] pci 0004:40:00.0: BAR 7: assigned [io 0x200000-0x200fff]
[ 10.515156] pci 0004:41:00.0: BAR 2: assigned [mem 0xf4200000-0xf420ffff 64bit]
[ 10.515195] pci 0004:41:00.0: BAR 4: assigned [mem 0xf4210000-0xf4213fff 64bit]
[ 10.515229] pci 0004:41:00.0: BAR 0: assigned [io 0x200000-0x2000ff]
[ 10.515245] pci 0004:40:00.0: PCI bridge to [bus 41]
[ 10.515253] pci 0004:40:00.0: bridge window [io 0x200000-0x200fff]
[ 10.515262] pci 0004:40:00.0: bridge window [mem 0xf4200000-0xf42fffff]
[ 10.517481] pcieport 0004:40:00.0: PME: Signaling with IRQ 132
[ 10.531503] r8125 2.5Gigabit Ethernet driver 9.009.00-NAPI-RSS loaded
[ 10.531552] r8125 0004:41:00.0: enabling device (0000 -> 0003)
[ 10.548563] r8125: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[ 10.550668] r8125 Copyright © 2022 Realtek NIC software team nicfae@realtek.com
[ 10.550668] This program comes with ABSOLUTELY NO WARRANTY; for details, please see http://www.gnu.org/licenses/.
[ 10.550668] This is free software, and you are welcome to redistribute it under certain conditions; see http://www.gnu.org/licenses/.
[ 10.552054] r8125 0004:41:00.0 enP4p65s0: renamed from eth0
Begin: Loading essential drivers … done.
Begin: Running /scripts/init-premount … done.
Begin: Mounting root file system … Begin: Running /scripts/local-top … done.
Begin: Running /scripts/local-premount … done.
Begin: Will now check root file system … fsck from util-linux 2.34
[/usr/sbin/fsck.ext4 (1) – /dev/mmcblk2p2] fsck.ext4 -a -C0 /dev/mmcblk2p2
rootfs: recovering journal
rootfs: clean, 53742/88352 files, 231027/353109 blocks
done.
[ 11.229335] EXT4-fs (mmcblk2p2): mounted filesystem with ordered data mode. Opts: (null)
done.
Begin: Running /scripts/local-bottom … done.
Begin: Running /scripts/init-bottom … done.
<----- REBOOT —>
DDR Version V1.07 20220412
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB

You running on pd-power? As try swapping to a Raspi5.1 or dumb psu and do an apt-get upgrade as yeah when on pd that looks like the boot loop I had wish I had copy+paste now with my memory.

I swapped out to a dumb 12v with usb-c adapter and things booted fine but also now the pd does boot fine and guess something was updated as haven’t changed anything myself as have just been running stress tests continiously

I tried several Apple laptop chargers and no luck (also using Apple cable): 29W, 87W and 96W. Those chargers work fine with Rock 3A and SSD. Rock 5b is without SSD.
I will try something else and see if I can get it to start.
Thanks for the suggestion.

If you’re using sd card, I recommand you to use emmc instead.

1 Like

@amazingfate I do not have an eMMC card.

It seems that the apple non-pd 12W got the board running. Thx for the suggestion @stuartiannaylor

1 Like

Yeah I don’t have a emmc card either I presume I would of run apt-get upgrade whilst testing and an update fixed things as now this pd works fine, but I was the same with a boot loop.

You can flash the image into emmc module from a linux/mac computer, here is the step: Nvme software support at launch of rock 5b

Mainline support is going to be a catastrophe with anyone using real PD supplies getting infinite boot loops.

If FUSB302 on mainline is a problem, then we should somehow fix the mainline, right? We do think these kind of smart power design is way better than than fixed one.

3 Likes

I think PD is great for mobile battery devices/tablets/laptops where charging might take place on multiple devices.

I am a bit mweh when it comes to PD as generally when a SBC is in place so the PSU is of fixed use and not often shared elsewhere as you lose power to the SBC.
The 5.148V - 26V buck is a great piece of silicon https://www.monolithicpower.com/en/mp8759.html as does a quite a good job of an extended efficiency vs volts/ampage curve. That is the star of the show than some negotiated multi-rail PD.

So far a cheap 5.5mm barrel to USB-C still makes a fixed 12v much more cost effective than any equivalent PD and after negotiation at a fixed volt I still fail to see any advantage of PD.

If you can reclaim the x2 CPU cooler mount holes and then have room for a 5.5mm DC jack plug then please do as that then releases the USB-C to be a USB-C.

1 Like

And there’s the reason:

Maybe someone can find a better solution, but when I wrote the code I just
could not get it to work reliably without resetting everything during
registration.

Since FUSB302 appears on all new RK boards these days (since being part of the reference design and as such copy&pasted) a fix in mainline will be needed. It might help pinging those at Rockchip dedicated to such stuff [1] early since everything that happens upstream usually takes ages.

[1] Kever Yang years ago, no idea whether he’s still in charge of community communication

1 Like

There are a lot of commits in mainline kernel after rockchip’s 5.10 vendor kernel: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/usb/typec/tcpm/tcpm.c?h=v5.18.12. I guess this commit is related: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/usb/typec/tcpm/tcpm.c?h=v5.18.12&id=90b8aa9f5b09edae6928c0561f933fec9f7a9987.
This issue is reported in 2020 on board ROC-RK3399-PC. I don’t know if this board still have this issue in 2022 using mainline kernel 5.18. Can anyone who has this board confirm that?

I have the board, the issue persists.