TonyMac32

I don't have the board either, but here is the detail: The miniDP is usually (exclusively other than this specific board) routed through a TypeC port controller. As a result, the driver relies on an ext-con node and endpoint to assign the display port. A patch was submitted that was a bit of a hack to mainline to create a 'virtual' power delivery controller that was permanently stuck in "type-c miniDP alt mode". This patch did not apply/work for me and the person who was testing it at the time. They should have just stuck with a TypeC with fusb302, it would have been more usefu

@ning I just caught up with the forums, I've not been on them in a long time. Please keep all political discussion off of these boards. Also, please stick to English for the benefit of the community in general. @axzxc1236 You could use something like this https://www.amazon.com/MakerFocus-Raspberry-Expansion-DockerPi-Compatible/dp/B07VK5L164/ Just double check it has no special connection that only works with the Pi 4. There are a lot of these available from various vendors.

So far my Jetson Nano won't get to desktop using the images on the download site. I have the original one, is this a device tree issue?

I'll have to take a look at it, I also have to implement this on a couple other RK3399 boards so I'll review the T4 first to make sure my example is still working

I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU. I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver. Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant. @JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R

This is true. However, I see little value in another kernel for any single board. The Station boards do not warrant that much special attention, let them exist without wifi until support can be properly managed by the vendor if they want Armbian. The world is overflowing with RK3328 and RK3399 boards. 🤷🏼‍♂️

Right, an overlay was added for the 2 GHz OPP, it is not stable on all boards, there are a lot of rk3399's out there.

I need to check the legacy kernel and see if it has the DRAM issues mainline had, that might account for all of these issues. [edit] I've verified the DRAM timings on legacy do not mach those I pulled from the vendor kernel and applied to mainline. I'll take a look.

I just ran into this as well, if you download the server image you can install the desktop through armbian-config. I just did it on Tinkerboard about 20 minutes ago, watching "The Italian Job" on Kodi right now.

Are the kernel config differences unable to be added to our current ones? Same with the wifi, is there some kind of incompatibility?

we need to talk about this commit history...

I did this differently, I simply used zfs-dkms and then set up my pool. no containers or anything needed.

Hello @joey99, This is a bit of a complicated question, I'll give it my best shot. The Raspberry Pi GPIO's are tied to the Broadcom SoC and as such are named accordingly. This will not be the numbering found on any other board with an open market SoC. So the numbers will never line up on anything else, since no one is allowed to buy the processors used by the RPi foundation. To the GPIO on the RK3328 (The SoC found in the Rock64), Rockchip arranges it's GPIO thusly: Bank ---> Group ---> Pin The RK3328 has GPIO0,1,2,3

Checking Sent from my Pixel using Tapatalk

I just received my Helios64, I immediately checked it for the Magjack center point to ground concern, and mine tests that it is connected. Is there a revision number on the board which can be used to identify the clean point between the pre and post fix boards?