jock

Hello! Can't say if a step is missing, normally an sdcard with multitool on it is sufficient to let it boot from sdcard. I don't know if you have an ancient version installed without the sdcard boot or a very new installation with the missing feature in u-boot. You may take a look to this:

Perhaps this helps:

Because NANDs are the raw flash memory chips as-is, while sd card (as well as emmc) are both nand flash + controller. The controller provides the FTL layer and the management things. If you only have the raw NAND chip, the FTL and management has to be done in software, hence you need a kernel driver for that. There is a brief explanation in the first topic page too (NAND vs eMMC vs eMCP) if you want a sum up of the topic. edit: "fortunately" more recent low-edge chips like rk3328 and rk3528 don't have a raw NAND controller, so in the future we won't have the necessity to deal with raw NANDs

Well, sooner or later everything become "end of support", so I would not blame them actually. Probably the assembly code is necessary to avoid some kind of patent or NDA infringment against NAND manufacturers, which use different algorithms for wear leveling and so on... I want to mean that probably it is not exactly rockchip intention to use obfuscated assembly code in there, but it is more like a tradeoff due to commercial reason to let them publish the whole source code. Anyway, raw NANDs are actually a PITA from the software point of view, because you need a software FTL and all kinds of wear leveling and cells management. eMMC chips instead have their own controller that takes care of teh management and "garbage collection" of the NAND cells, so software support is much simpler.

Nope, and the answer from @Hqnicolas is right: mainline kernel has no driver for NAND controller on rk322x. To be precise, in the mainline kernel there is a driver that is capable of access the NAND raw cells, but the mainline kernel lacks a Flash Translation Layer (FTL) that is embedded as assembly code into the vendor kernel which, in turn, has a driver which does a sort of "emulation" of a block device.

The error is what you already guessed: mainline kernel don't work with NAND. You need an image with the vendor legacy 4.4 kernel if you want to install in NAND.

There should be three partitions on the sdcard, the one with the backups and images is MULTITOOL. The reason behind the three partitions is fundamentally related to the fact that the Windows is bugged and limited

On what basis you say that? Because your previous assertions about resize and GPU rendering are not exactly right: rockchip (as other vendor socs as well) can use "direct to plane" rendering, which does not use the GPU to render frames at all and resize is done by the VOP itself, not the CPU. rk3566 video decoder is rated for 4k60fps, you don't need any "turbo" because CPU also is marginally involved in hardware video decoding

@Socram Hello, it's definitely an rk322x. Despite the kernel is the same for rk322x and rk3288, the socs are profoundly different and so are the device trees. An image for rk322x would not boot on rk3288 and viceversa. Anyway, you should run rk322x-config and use the appropriate led-conf for your board. AFAIR you should have two options: led-conf8 for h20 boards with two voltage regulators (better, looking at the board photos this should fit) and led-conf7 with r29/r2b/h20 boards with single voltage regulator (worse but more compatible). You may go with led-conf8 first, see if it is stable under load. If not, go with led-conf7. Both the configs should make HDMI work

You have to put the file in /lib/firmware/brcm directory, then reboot and see if it works

First of all, probably you're talking about the stock Android: you're in the wrong place. We don't discuss here about Android at all, we discuss about Armbian here. About the technicals, even the cheapest rockchip soc around (rk322x) is capable of driving 4k HDMI panels (but only up to 30fps) and decode 4K H.265 content (only up to 25fps AFAIR), but they are pushed to their limits. More newer and powerful socs (rk3328, rk3399, rk3528 and rk3566/68/88) should be capable of handle 60fps 4k HDMI panels and decoding 50/60fps content, but then come the optimization issues. Chinese manufacturers advertise what the soc is capable of, but the amount of data involved in 4k 60fps content to be decoded and displayed is huge and if pipeline is not perfectly optimized, you get stuttering and bad performance. Chinese manufacturers don't care at all about optimizations, because optimizing software is a lengthy process and thus costs a lot and they want profit, not costs.

Put an armbian image on a sdcard and boot from there

It's a linux shell command

Hmmm, what you describe seems a regression from latest u-boot upgrade to v2024.01, even though I did not notice any issue like that before; anyway you can easily trigger the boot from sdcard removing the bootloader from the emmc with dd if=/dev/zero of=/dev/mmcblk2 bs=32k seek=1 count=40 Once you do that, the board will boot multitool from sdcard

Nand options were not removed at all from latest multitool. Those options are just hidden if the NAND is not detected. You should check lsblk and dmesg to see if rknand device appears and maybe post dmesg log here too.

It should autodetect the device if it is properly working and enable the dtb overlay in /boot/armbianEnv.txt automatically; you should not need to select anything. You mileage may vary, though.

Thanks for your experience, did you try to run rk322x-config again and let it enable the proper overlay? realtek bluetooth is a bit quirky, especially on newer kernels

@helix ff510000.mmc is disabled in led-conf3 because led-conf3 is for MXQ-RK3328-D4 board, which accidentally has rk805 PMIC and fixes something. But clearly led-conf3 is not tailored for your board, hence not all the hardware works.

@helix afaik, no tool for that. phandles are the way how kernel navigates the device tree. BTW, you may wish to try to enable box-wlan-ap6330 or box-wlan-ap6334 device tree overlay in /boot/armbianEnv.txt and see if you advance in getting bluetooth: broadcom chips have the need for some bits in the device tree to load the driver and attach the communication "bus" (which is usually a simple UART port). Also they are very similar chips. the driver is usually capable of handling the detection of features despite you declare a different chip in device tree. You can see the source of the ap6330 overlay here And yes, you definitely need to enable the led-conf3 because the dtb declares that your board definitely has a rk805 PMIC: that's why the photo of the board is heavily suggested in the first page to get help.

Most of the patches are in the kernel mailing lists. ffmpeg patches have been taken from mainline LibreELEC project.

You should first try to disable xfce compositing, which is very taxing and pretty useless. Without composition, videos should be much smoother, but take note that rk3228 is very limited in terms of resources so windowed playback is acceptable perhaps up to 1080p25/1080p30, anything above won't work well and even 1080p may have some smoothness issues. 8bit/10bit should not matter though.

@helix hello, those "errors" are actually ok for brcmfmac driver. The clm blob is not always necessary and not available for some chips, the .bin file error is an attempt to look for a nvram file, but the driver will later look for other alternative nvram files and does not tell you that finally has found one.

Tested Debian Bookworm on Radxa Rockpi-E - RK3328: Systems boots HDMI N/A eMMC N/A sdcard ok USB 3.0 ok Gigabit Ethernet ok, throughput ok (> 900mbps) Fast Ethernet ok, throughput ok (> 90mbps) Wireless ok (rtl8821), throughtput satisfying but not at best (~30 mbps on 2.4ghz 802.11n network) Bluetooth untested Analog audio codec ok dmesg is clean

Tested Noble XFCE on ASUS Tinkerboard S - RK3288: System boots HDMI ok eMMC ok sdcard ok USB2.0 ok Ethernet ok, throughput ok (> 900mbps) Wireless ok (rtl8723bs), throughput ok (~70 mbps on 2.4ghz 802.11n network) Bluetooth ok, streamed same music from same smartphone as opi4 lts; some occasional hiccups but link is stable Analog audio codec ok dmesg is lamenting: ff540000.usb device "Waiting for Host Mode timed out", USB 2.0 host ports yet works fine ff580000.usb softreset failed, but USB OTG port is occupied by PSU SPI device is not found (there is no SPI device on my tinkerboard) mmc1 (wifi) incurs in an issue on first initialization, but succeeds on next attempt and wifi/bt seems to work pretty fine

Tested Noble XFCE on Orange Pi 4 LTS - RK3399: System boots HDMI ok eMMC ok Sdcard ok USB 2.0 and USB 3.0 ok Ethernet ok, throughtput ok (> 900mbps) Wireless ok, throughput ok (~80 mbps on 2.4ghz 802.11n network) Bluetooth ok, streamed some music from smartphone Analog Audio codec is fine dmesg is clean with no particular errors