RFC: initial Rock 5B+ edge kernel support

[fridtjof]

Description

The Rock 5B+ does not have an upstream device tree, but is of course very similar to Rock 5B.

Starting from mainline's rock-5b.dts, and cross referencing vendor device trees for the 5B+ I arrived at a device tree that ~works with an edge kernel.

As with the Rock 5B, U-Boot mainline is used to boot said kernel. I also already bumped the tree/version to mainline 2024.10 according to #7135.

How Has This Been Tested?

Image built with:

./compile.sh build BOARD=rock-5b-plus BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=noble

• Board boots up fine from an SD card, other boot methods not tested
• USB ports ~work, however:
  • Type-C port only works in one orientation right now
  • Top USB3 Type-A port only seems to work at USB2 speeds. No idea here.
• Ethernet works at 1GBit/s and 2.5Gbit/s
• Wifi scans, connects, works
• Bluetooth works (finds devices, no connection testing)
• Video I/O (HDMI0/1, HDMI IN, DisplayPort) not tested
• M.2/PCIe not tested

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings (not sure, CI will tell me i guess?)

[fridtjof]

fyi, here's a diff of rock-5b (as patched by armbian-build) vs rock-5b+ DTS:

5b-5bp.txt

(Github wouldn't let me upload as .patch, right before listing that extension as supported. shrug)

[EvilOlaf]

I suggest to test this against 6.12 as well since the rollover to that version might happen soon
#7455
#7372

[fridtjof]

I suggest to test this against 6.12 as well since the rollover to that version might happen soon #7455 #7372

Good point, putting that on the todo list.

Of note, because I forgot to mention this before; Currently, there seems to be a problem with mmc?

dwmmc_rockchip fe2c0000.mmc: swiotlb buffer is full (sz: 1048576 bytes), total 32768 (slots), used 3087 (slots)

Not sure what to do about this; the vendor kernel does not show these messages, but i'm not sure if it's just not logging this or if the problem is actually gone there.

[fridtjof]

Tested with #7455.

Boots fine, and there's no regressions vs. what I tested on 6.11

I did briefly test HDMI0 by plugging in a 4K monitor and installing ubuntu-desktop (to avoid having to build yet another image). The output, unfortunately is pretty garbled. Best i can describe it is colors are broken, and the dimensions are off (too wide, not tall enough).
Is that considered a blocker for merging? (I personally don't need HDMI output urgently, so I'd defer that to some other time)

[igorpecovnik]

Is that considered a blocker for merging?

No, that is probably common. Here, for desktop, its better to start with desktop image. As its assembled right. Upgrade from CLI is not working well, also our desktop. This part we need to work on.

[igorpecovnik]

Tested with #7455.

Merged, so you can proceed on this one.

[fridtjof]

Rebased the PR.

I also added SBU GPIOs to the usbdp PHY from the vendor DT which didn't really change anything but they're in there now.

[HeyMeco]

@fridtjof have you tried booting from the second m.2 slot? (The one that would be in the middle of the board)
At least setting up everything on the upper and then putting the m.2 to the lower resulted in me not being able to boot (with vendor) but I assume the mainline u-boot change as is would also not be helpful in having both m.2 slots work for boot

[fridtjof]

@fridtjof have you tried booting from the second m.2 slot?

haven't tested m.2 at all so far. I don't have any spare m.2 SSDs unfortunately

[HeyMeco]

haven't tested m.2 at all so far. I don't have any spare m.2 SSDs unfortunately

I'll look at making a rock5b+ defconfig/dt for mainline u-boot this week then.