Search the Community

I guess that I have had issues with the armbian build environment I guess that I have deleted some files that I shouldnt, anyway I have removed the old environment and build armbian again. First I have tried to compile version 5.5.4 to see that all goes well and no errors, after confirm that it succeed to finish without any failures I went back to try compiling the 5.1 version. With each failure of compilation I have modified the relevant MakeFiles and removed things that are not specially for relevant for the BPI-M64 board anyway and that caused the compilation to stop. I end up with this: iff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile index f670458ae..9e5672ff7 100644 --- a/arch/arm64/boot/dts/allwinner/Makefile +++ b/arch/arm64/boot/dts/allwinner/Makefile @@ -1,29 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-amarula-relic.dtb + dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-emlid-neutis-n5-devboard.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-libretech-all-h3-cc.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2-v1.1.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo-plus2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo-core2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-k1-plus.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-m1-plus2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb -dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb + diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile index 11f80feba..cdb79e00d 100644 --- a/drivers/net/wireless/Makefile +++ b/drivers/net/wireless/Makefile @@ -4,7 +4,6 @@ # obj-$(CONFIG_WLAN_VENDOR_ADMTEK) += admtek/ -obj-$(CONFIG_RTL8189ES) += rtl8189es/ obj-$(CONFIG_WLAN_VENDOR_ATH) += ath/ obj-$(CONFIG_WLAN_VENDOR_ATMEL) += atmel/ obj-$(CONFIG_WLAN_VENDOR_BROADCOM) += broadcom/ @@ -14,7 +13,6 @@ obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/ obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/ obj-$(CONFIG_WLAN_VENDOR_MEDIATEK) += mediatek/ obj-$(CONFIG_WLAN_VENDOR_RALINK) += ralink/ -obj-$(CONFIG_WLAN_VENDOR_REALTEK) += realtek/ obj-$(CONFIG_WLAN_VENDOR_RSI) += rsi/ obj-$(CONFIG_WLAN_VENDOR_ST) += st/ obj-$(CONFIG_WLAN_VENDOR_TI) += ti/ @@ -30,8 +28,5 @@ obj-$(CONFIG_USB_NET_RNDIS_WLAN) += rndis_wlan.o obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o obj-$(CONFIG_VIRT_WIFI) += virt_wifi.o -obj-$(CONFIG_RTL8812AU) += rtl8812au/ obj-$(CONFIG_WLAN_VENDOR_XRADIO) += xradio/ -obj-$(CONFIG_RTL8821CU) += rtl8811cu/ -obj-$(CONFIG_RTL8188EU) += rtl8188eu/ -obj-$(CONFIG_RTL8822BU) += rtl88x2bu/ + diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index d1b17ddcd..5eee1d0b5 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -5,12 +5,6 @@ obj-y += media/ obj-$(CONFIG_PRISM2_USB) += wlan-ng/ obj-$(CONFIG_COMEDI) += comedi/ obj-$(CONFIG_FB_OLPC_DCON) += olpc_dcon/ -obj-$(CONFIG_RTL8192U) += rtl8192u/ -obj-$(CONFIG_RTL8192E) += rtl8192e/ -obj-$(CONFIG_RTL8723BS) += rtl8723bs/ -obj-$(CONFIG_R8712U) += rtl8712/ -obj-$(CONFIG_R8188EU) += rtl8188eu/ -obj-$(CONFIG_R8822BE) += rtlwifi/ obj-$(CONFIG_RTS5208) += rts5208/ obj-$(CONFIG_NETLOGIC_XLR_NET) += netlogic/ obj-$(CONFIG_OCTEON_ETHERNET) += octeon/ And now I am facing another issue that I cannot find the fix for it: CC [M] drivers/usb/serial/usb_wwan.o CC [M] drivers/usb/serial/ssu100.o CC [M] drivers/usb/serial/symbolserial.o CC [M] drivers/usb/serial/ti_usb_3410_5052.o CC [M] drivers/usb/serial/upd78f0730.o CC [M] drivers/usb/serial/visor.o CC [M] drivers/usb/serial/wishbone-serial.o CC [M] drivers/usb/serial/whiteheat.o LD [M] drivers/usb/usbip/usbip-vudc.o CC [M] drivers/usb/serial/xsens_mt.o LD [M] drivers/usb/serial/usbserial.o AR drivers/usb/built-in.a AR drivers/built-in.a [ error ] ERROR in function compile_kernel [ compilation.sh:378 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated Also happens with the 5.2 version.

https://github.com/armbian/build/pull/1759/files#diff-309b3186e3060abd0485d767eefb324eR431 force-hpd just tells the display driver (panel simple) which pin is used for hotplug dedtection which is obviously not implemented in the pinebook (you can't remove the edp) and therefore likely also needed in 5.5. there you go: https://gitlab.manjaro.org/tsys/linux-pinebook-pro/blob/v5.5/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts#L445 at least display timings landed in mainline 3 days ago... The pinebook dts itslef didn't. add my repo as remote: https://github.com/chwe17/build/tree/rk3399_pinebook pull the pinebook branch and update boot.cmd (config->bootscripts->boot-rockchip64.cmd) with the one attached (cause I didn't push this upstream yet). And then build with ./compile.sh LIB_TAG=rk3399_pinebook boot-rockchip64.cmd

@Icenowy Thanks, success! Pinebook works now, but Teres don't. I don't get u-boot prompt on Teres at all - but we had it on previous version ... dunno what was changed, while Pinebook properly detects and prompt which panel its used. Huh?

@Igor seems that you are at a 5.6 base now. Thus try my patches on 5.6? https://github.com/Icenowy/linux/commit/8df6da42f1244573edd3d22d39dbe8fc66a01cbd This fixes supply name issue for anx6345, should fixes TERES https://github.com/Icenowy/linux/commit/b68d225323c9a479b26ee22a2cb4bf4eefe13cc5 This adds ANX6345 node to Pinebook.

Our dirty patches doesn't apply and work anymore ... I remove them and replace with a driver from 5.6. No one shows anything on the screen. sun50i-a64.dtsi pinebook teres

If you have Pinebook in mind and the one from Olimex, they both use anx6345 IIRC. Driver for that chip was merged in kernel some time ago, but it doesn't consider "panel-supply" property. I guess that's what's wrong. @Icenowy?

small update: it looks like this is mostly a kernel not kernel-config issue, using tobias kernel (v5.5) for majaro with our kernelconfig without any patches and the pinebook shows display output in mainline.. Either we patch something needed not into the kernel, or we patch something needed out... Note, I currently use a slightly adjusted boot.cmd but I tested this one before and with our current kernel it doesn't do the trick.

Hi all. May I know which branch of https://github.com/armbian/build can be used to work on the pinebook pro builds? I'm new to armbian and I want to try out some changes using the rockchip's github repos for video to test out some theory I think but got lost in discovering which branch would have the pinebook pro part.

@chwe, Try this (on manjaro pinebook-pro dts) to get sound and uart: I think I got it from mrfixit2001, if not it was ayufan.... This now works for me-- just giving "patch" form so you can see where the changes are.... -- 5.5.rk3399-pinebook-pro.dts 2020-02-05 11:06:24.354098350 -0500 +++ my.v5.5-rc7-panfrost-fixes.rk3399-pinebook-pro.dts 2020-02-05 10:58:51.545953609 - @@ -197,10 +197,12 @@ simple-audio-card,cpu { sound-dai = <&i2s1>; + system-clock-frequency = <12288000>; }; simple-audio-card,codec { sound-dai = <&es8316>; + system-clock-frequency = <12288000>; }; }; @@ -838,7 +840,7 @@ status = "okay"; bt656-supply = <&vcc1v8_dvp>; - audio-supply = <&vcca1v8_codec>; + audio-supply = <&vcca3v0_codec>; sdmmc-supply = <&vcc_sdio>; gpio1830-supply = <&vcc_3v0>; };

I had time to test my newly written DT for the orangepi4: sound still doesn't work (even when I replaced the bits to use rt5651) I guess some of the mic/headphone definitions in the DT are still wrong.. wifi works with network manager ethernet works as well both USB2 are tested and working (I've the NPU version so I didn't try to look at USB3 atm, may or may not work who knows) dmesg shows still some errors to wifi but I've no idea if this is related to the opi at all or just fall out from the normal driver situation here hdmi is untested yet (i've no spare device for doing it) actually the DT should also support eDP over USB-C as far as I've saw in the schematics the opi4 should do it as well.. this should be possible and it's done similar to the pinebook, obviously I've also no spare eDP over usb-c display... so for @piter75 if you want to mess with it.. here is an updated version of it.. And for the less experienced ones.. you might not wanna mess with it yet.. at least on the powertree there's nothing horrible wrong so that the board would not boot up.. opi4b_dts_v1.dts

it got slightly better.. E.g. pinebook uses the lpddr4 driver from u-boot let's see if we can/should move some other too.. most blobs are used to boot may it be SPL or whatever.. It's then up to you to decide that you trust that they only do what they should.. e.g. we had this discussion for amlogic devices where the blobs did much more than just bringing the SoC in a state where u-boot linux can fully control iirc linux had never fully control over CPU clockspeed.. No idea if this changed in between I'm not interested in amlogic at all atm. Some sort of a bootrom will always be there and mostly if not ever this isn't opensource nor upgradable/replaceable. Same counts for every wifi chip as well.. some pieces of 'firmware' will always be there.. otherwise there you go: https://www.cnx-software.com/2019/12/16/openwifi-is-an-open-source-linux-wifi-stack-running-on-fpga-hardware/ IMO arm was never about being as much as possible opensource, if you look for that maybe you find your luck with a risc-V SoC, but even there it's likely that 'full free' isn't the goal of most SoC makers build something based on it. Same counts then for displays etc. They may or may not contain some sort of firmware which is closed source and can't be replaced.

the newer kernel will just be worse for that at the moment.. cw2015 (the charger driver) didn't land upstream yet and the first iterations from Tobias at manjaro currently throw some errors in dmesg. Pinebook is wip and IMO early wip so don't expect the nice features to be done soon. Btw camera is another one I simply refuse to work on until basic stuff is sorted out.. So if you want it, you've to figure it out on your own. I know.. and I don't really get why ours refuse to work... nope at the moment no display output in mainline with armbian. You're happily invited to solve this: https://github.com/armbian/build/pull/1759 adding the eDP to the kernel bootargs btw didn' help for me. But I'm quite sure we had something like video=eDP-1:1920x1080@60 to the bootargs, either over DT or with armbianEnv.txt or bootscript.. ( adding @martinayotte and @TonyMac32 ). And for u-boot, if we don't use the the 2017 bsp u-boot I don't think we see display output soon for the pinebook, as far as I'm aware the edp driver didn't make into upstream u-boot yet and at least I don't try to forward port this mess from u-boot 2017 into upstream.

IMO there's no reason to rush here.. before we haven't cleaned some of the mess in bootloaders I don't see much of a reason to change things. Yes the boards run surprisingly stable, but there are still odds here and there. I think most of the overlay features are not fully tested (compile log at least indicates that some of them might need some inspection as well) and we still have various kernel sources for the bsp kernel which needs to be cleaned first, and as just noticed, the odds regarding rebooting starting again with the pinebook.. There isn't much of a difference between the bugtracker forums and the dev forum at all. And 4.4 kernel gets old (no matter it is supported well or not), so might hit the fallout of this with the next versions of debian/ubuntu. So the same thing happened with 3.4 on sunxi shouldn't bite us again (kernel to old for recent ubuntu/debian but a bunch of interesting features are only available there). they could be marked, "potential harmful to your family" and people would still use it productive... our "supported" definition is so generic (https://docs.armbian.com/#what-is-supported) that it means in fact nothing.. (I'll burn in hell for that statement I know).. At least when people run into problems they should be aware that things are working progress right now. Most basic seem to work without major issues, but for everything a bit more fancy (camera, display etc) there's not much tested and proved to work right now. Multimedia works only on half of the boards (those belong to rk3399).

well I'll fire up the pinebook now with the rk3399 4.4 kernel (e.g. integrate it into friendly arms fork) and see if this works. If that works we would at least have 4.4 and likely @JMCC multimedia stuff working. I don't get why the driver doesn't even try to probe the display.. so something must be fishy here.. Someone would then need to test if this works with stock image on eMMC cause I removed eMMC and I don't want to open and close the pinebook for a 100 times during development (I don't see a reason for not, but I didn't expect the display fooling me that hard either). But hey we have a new rk3399 SBC with it's own UPS working..

well you've no chance I already set up the pinebook in rk3399 with u-boot 2020: U-Boot 2020.01-armbian (Jan 21 2020 - 23:08:47 +0100) Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Pine64 Pinebook Pro ## Error: Can't overwrite "serial#" ## Error inserting "serial#" variable, errno=1 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 6 ms (478.5 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 143 bytes read in 6 ms (22.5 KiB/s) 7118384 bytes read in 752 ms (9 MiB/s) 20722176 bytes read in 2178 ms (9.1 MiB/s) 72693 bytes read in 17 ms (4.1 MiB/s) 2698 bytes read in 9 ms (292 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7118320 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5853000, end f5f1cdf0 ... OK Loading Device Tree to 00000000f57d8000, end 00000000f5852fff ... OK Starting kernel ... [ 2.647157] Internal error: Oops: 96000004 [#1] PREEMPT SMP it seems it doesn't like my new DT.. but u-boot works fine and blobfree..

right that one is on my todo list as well.. I got fooled by their documentation which mentioned a way to reset clock of eMMC to enter maskroom but then I couldn't erase it.. @piter75 wrote how he did it with the buttons so that I'm soon ready to test it. I've the patches for integrating it into rockchip64 family (u-boot and 4v4 kenel) laying around since days.. (if we will base it on nanopi m4v2 we would have to change them a bit cause different bsp kernel and u-boot) but not tested cause the stock firmware didn't try do boot SD card for me. Will be tested once pinebooks display doesn't fool me anymore.. btw @TonyMac32 I might switch to upstram 2020 u-boot with the pinebook if you don't mind. orangepi4_uboot.patch orangepi4_kernel.patch

Yes, but its just Android which is booting off at that time. But its on the table ... @chwe I meant Orangepi 4 Don't have Pinebook PRO. Yet.

kernel boots, the charger driver and display settings were added (obviously display doesn't work yet), dmesg looks quite smooth (don't have it anymore - my notebook is on low diskspace the whole time so I've to throw out non fully working images). The DT taken for this was from manjaro. Sound was disabled cause it polutes debug UART for whatever reason. So this guy should boot: kernel-rockchip64-current (copy).patch but it's not a proper device tree, especially this node here: + vcc3v3_s0: vcc3v3-s0-regulator { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + regulator-name = "vcc3v3_s0"; + regulator-always-on; + }; needs some love.. we've the same node with a different name too (this one is present in the manjaro DT the other one was added by myself and taken out of PMIC cause it has nothing to do with REG2 in PMIC, that's not how things are wired according to schematics): + vcc_lcd_en: vcc-lcd-en-regulator { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>; +// pinctrl-names = "default"; +// pinctrl-0 = <&vcc_lcd_en_drv>; + regulator-name = "vcc_lcd_en"; + regulator-enable-ramp-delay = <100000>; + vin-supply = <&vcc3v3_sys>; + regulator-always-on; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; so in PMIC this node was killed: + unused: SWITCH_REG2 { + regulator-name = "SWITCH_REG2"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-off-in-suspend; + }; maybe just diff the two DT files (ours and the one from manjaro: https://gitlab.manjaro.org/tsys/linux-pinebook-pro/blob/master/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts) to get a clue. And sound was disabled yet: + es8316-sound { + status = "disabled"; + compatible = "simple-audio-card"; + simple-audio-card,name = "rockchip,es8316-codec"; + simple-audio-card,format = "i2s"; + simple-audio-card,mclk-fs = <256>; + + simple-audio-card,widgets = + "Microphone", "Mic Jack", + "Headphone", "Headphones", + "Speaker", "Speaker"; + simple-audio-card,routing = + "MIC1", "Mic Jack", + "Headphones", "HPOL", + "Headphones", "HPOR", + "Speaker Amplifier INL", "HPOL", + "Speaker Amplifier INR", "HPOR", + "Speaker", "Speaker Amplifier OUTL", + "Speaker", "Speaker Amplifier OUTR"; + + simple-audio-card,hp-det-gpio = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>; + simple-audio-card,aux-devs = <&speaker_amp>; + + simple-audio-card,cpu { + sound-dai = <&i2s1>; + }; + + simple-audio-card,codec { + sound-dai = <&es8316>; + }; + }; I simply don't care about sound yet, but working debug UART is a must atm.

let's see if we get the pinebook pro with mainline and the orange pi 4 in a working state til then.. Still struggle with display (some of the available DTs for mainline are wrong regarding to regulators so my display gets likely not powered, sound polutes debug UART and so on).. Maybe we send the display then as a bugfix. I mean a non working display for a notebook is a bug, a working one isn't a feature right?..

Incomplete Tasks Targeted For Release AR-42 Merge packaging patches Moved to 20.05 AR-45 Make first login more user friendly Moved to 20.05 AR-50 Optimise armbian-config dependencies Moved to 20.05 AR-128 Adding support for Pinebook PRO <-- Is there anything in git repo for this.. i know its in a WIP state at least AR-87 Network manager randomizing wireless adaptor MAC Move out. Not sure if this is bug at all. AR-151 Integrate @JMCC 's multimedia script . moved to 20.05 AR-152 Display issues with Bionic Mesa update critical bug

The serial cable i got from Pine always worked for me in u-boot (some of the distros seem to disable serial output in the kernel, or have it mis-configured) I did not have the problems some people have mentioned. The cable was not very well put together, however, and was too short for my comfortable use. I got one of these EZsync.021, it was pricey, but much more substantially made with a 1.8 meter cable. I will try to build first by using the Manjaro kerne lsource for mainline (since I already know that that runs well) and mainline u-boot (cuurent--20.1)with ATF (master--some changes were made in December which fix some power issues on the rk3399 chip) . If I can get that going, I'll see what patches need to be generated for vanilla mainline build. I believe some of the changes have been submitted already for inclusion in mainline. The rockpro64 is running fine for me on the "current" kernel with an experimental current uboot that will boot (from SPI ) the NVME. I believe much of the work for the pinebook has actually been done, it's a matter of getting into the build system. In general, I am very happy with the notebook. In some areas, though, I don't think the build quality was great. Using tiny m2 screws for the bottom, having an sd card reader into which it is difficult to insert the card (and which will shoot the card across the room if you are not careful while removing it) and sending an NVME adapter which actually can't be used as is with a 2280 size NVME (I had to take a hacksaw to mine) sometimes make usage difficult , especially for people like me with not great manual dexterity.

My Serial Debug cable is a custom made one built more than 2 years ago when I got my old Pinebook. It is using a stereo plug along with a normal 3V CH340 USB-TTL Serial adaptor.

Just received my Pinebook Pro this week. I get roughly 8 to 10 hours of battery life out of it with moderate usage. It can be charged/powered from a micro USB-C port, so a power bank will extend battery life. Performance is actually good, especially for the price.

so a small update for those being impatient... well there's not much to tell as long as there aren't any results yet... Yes I do have the board and started to integrate it.. but currently fail. For those who want to join the board bring up party: UART2 is on the 3 pin pinheader as normally used by RK3399 for debugging.. It seems xunlongs buildscript points to the evb board for the 2017 u-boot when building images. I never used their buildscript, I don't plan to change this and I don't know if images built with it work. It looks cleaner than stuff I saw before but still room for improvements. The devicetree is clearly based on the evb board (nodes which aren't used are commented out e.g. evb's eDP node). Likely not the newest version (see example pin naming just as examples for naming convention. One can be compared with the schematics without even thinking.. the other one is a pain (you can guess on your own which one I prefer).. OrangePi 4 node for LED: led@1 { gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; label = "status_led"; linux,default-trigger = "heartbeat"; linux,default-trigger-delay-ms = <0> Pinebook node for LED: green-led { gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; linux,default-trigger = "disk-activity-inverted"; default-state = "on"; mode = <0x23>; The u-boot on the board is a 2014 based one (I guess there's a android preloaded on the boards eMMC? - no idea I never connected it to a HDMI screen to actually see what happens). I tried to erase eMMC with the rkdevel tool from command line but it fails (it recognizes maskroom mode when clock of eMMC is shorted - see in documentation of xunlong how to short eMMC, not recommended if you don't know what you're doing!) but somehow I can't erase eMMC then (it worked on a TV box back then but not here). At least rockchips android bsp uses a 2014 u-boot iirc. at least I can't interrupt the 2014 u-boot from a serial debugger connected (15000000 baud) boottime is set to 0 seconds and it's not able or not set as default to boot from SD-card (i tried to build a first image but this one is either nor bootable or the 2014 u-boot just ignores SD card images - an empty eMMC would force brom to fire up SD card and I would see where it fails). after all there's still work to do to get this board running and a not preloaded eMMC would've been nice. @martinayotte if I short eMMC clk to ground does it enter maskroom directly or does it just skip eMMC and tries SD card then? I think you had the same for their first rk3399 based board back then or was it for the firefly? I don't remember anymore. @Jack953 even when first images are here. This will still be early wip cause some cleaning is needed to get the board properly working. Board bring up needs time and it doesn't get better when we rush here...

Patch to log the errno when EDID fails to be read from device tree (patch/kernel/sunxi-current/board-pinebook-a64): anx6345-log-errno-on-edid-device-tree-read-err.patch