TonyMac32

sorry I didn't see this, and you had to buy some berry trash instead 😐

unfortunately, in my experience, Samsung *in particular* does not play nice with SBC's

Fully Agree. I might have a replacement for the Helios64 on the way, if/when it arrives I'll be able to do some tests on the Helios64 as it won't be my active machine, but as you see above I haven't updated in a *long* time.

Not so far, I stuck the tree for this board in mainline and it will be available with 6.6. I haven't messed with the USB3 yet, the collabora kernel is my secondary interest for this board, and, since I don't really get anything out of it, the board isn't my first priority either outside of personal interest. I'll look at lowering the eMMC frequency, but some actual testing for errors will be needed to make sure 150 MHz is truly "good" and not just "tolerably bad" for the driver

is entirely dependant on the device tree overlays handling fixups, or is that RPi style syntax? In any case I already found an issue with the overlays for this family (spi-spidev overlay as written is in fact only applicable to rk3399 https://github.com/armbian/build/issues/5778) , I'll add one for rk3328 spidev, it will not work the way you have above though since fixups are super hacky.

Libre Computer Renegade - Boot, all USB, Gb NIC, desktop Missing audio

@Werner that device is on the Media kernel, is it not? Unless I'm mistaken it isn't going to see any updates or... ?

Le Potato -boot, hdmi audio, USB, NIC Tritium H2/3 and H5 - Boot, NIC, USB

Raspbian has it's own things going on, and is using the Libre Computer kernel, tuned for their boards. I will need to take a look and see what has disturbed the Le Potato image in our distro, it's not immediately obvious but these boards share kernels with a lot of devices and sometimes we step on each others toes.

Hello switch, While the RK3328 does have the hardware, the crypto patches have not made it into the mainline kernel yet: https://patchwork.kernel.org/project/linux-rockchip/list/?series=680902 As a result the hardware crypto won't be available. That patchset infers it is identical to the crypto module in the RK3288, so as long as the RK3399 parts of that deries don't tie it up, it should be applied soon.

hello @cyborg_fox, please try to download the image now, I believe the issue has been corrected, there was an issue with a u-boot update. New image was created as of the 7th.

I've had trouble supporting this board, a lot of "s" variant boards in particular do not like to boot using mainline ATF. The only reason there are mainline images is because I created a device tree/got a supply driver/etc. The DP over type C should work provided the device tree is updated, you can find examples on several other RK3399 boards we support.

Right, confusing is, they were correct for quite some time, so my curiosity is: What changed? Perhaps someone updated for one of the newer boards without checking for collateral damage.

uuuuuuuuugh

Are you trying to power the board via the GPIO? I don't think there is a GPIO to shut off the 5V pins from within the board itself.