TonyMac32

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?

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)

I just did a quick test on Le Potato, increasing CMA to 512 MB was very easy following the above instructions with the /boot/dtb/amlogic/meson-gxl-s905x-libretech-cc.dtb device tree. The property yo uwant to change is right at the top of the file as a handle under "reserved-memory" Any value that is 0x400000 aligned should be valid, so you can experiment.

Thankfully the kernel does not need recompiled for this, only the device tree. See the post below, I b elieve this is still accurate as far as device tree decompile/recompile method, can be done on the device (use the correct device tree for your board )