TonyMac32

Please provide logs/dmesg/ armbianmonitor -u output so we can have some idea of what if anything is going on in the kernel. If it's U-boot related and you have a serial UART for debug, that would also be helpful information.

Right. The C2 doesn't put as much effort into the Pi header compatibility as a lot of other boards. I haven't used one for GPIO partly for that reason. I need to add some of my other boards to this but: https://docs.google.com/spreadsheets/d/1dJq7MM1_zA5HtXywDMZ9HMKyPaNgGmkxnuz3wYuk4s8/edit?usp=sharing

I checked bluetooth recently, I'll have to look again.

https://github.com/torvalds/linux/blob/09688c0166e76ce2fb85e86b9d99be8b0084cdf9/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts#L294 all the GPIO on the headers should be there.

Awesome, I didn't notice this before, I have no fewer than 3 I.MX8M boards I'd like to have builds for. I will take a look at this.

The device tree file name and the compatible do not and almost never are the same. This may be a bug in the scripting, but it has nothing to do with an error in the device tree.

The "Invalid" tag is cancer. That needs to be "Off-topic", "Out of scope", "needs clarification" or something else. Honestly we are actively rebranding ourselves as a toxic community at a terrifying rate.

The RAM controller was being starved for voltage. I have recently rectified this problem and moved to the official mainline USB3 driver for this board. The GPU and DMC share the same regulator, so there was conflict. https://github.com/armbian/build/commit/ee610096bc5d252307789c3818aa8b59147bf1d5

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 useful for anyone not wanting to run the display, and it conforms to the state of the Rockchip codebase. As I'm about to dig back into all the other boards that implement the expected configuration I'll see if any progress was made on this front. Without the board it's really hard to debug such an edge case though.

@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) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall. The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design. Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade. I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.

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 Each has a theoretical 32 pins, grouped A0-7, B0-7, C0-7, and D0-7 Linux will assign these a scalar value, IO 0- whatever the top number is. That's where my knowledge ends. In short, your hat should work, assuming you have the drivers for it and can extract the proper pin numbers out of the documentation. [Edit] and on second look ,that display is HDMI, but I assume you were thinking of SPI LCD's. A GPIO TFT LCD will not be compatible as the Rockchip pins for parallel LCD are not sent to the same places.

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?

power delivery through USB-C. Oh and mode switching. So if it set to the mode you want by default it should be ok, but the better question is why was it eating clock cycles

burning an image for test [Edit] H3 boots fine H2+ as well As an aside, is it an H5 board? that will require a different image than the H3 (The Tritium came in H2+, H3 and H5 variants)