@Suly rtl8703bs works with 8723cs driver, but the proprietary driver has been disabled so far in newer kernels because maintenance was becoming more and more complex. Actually I don't remember if it works with the mainline kernel driver. Probably it works, but I don't know if it is enable in rockchip64 kernel; it is surely enabled in rockchip armhf family.

Howdy. if you have the tf uart adapter thingy, by the time it shows that on screen you are at the u-boot prompt where you can do what you want. e.g. start fastboot. I believe this tablet cannot be bricked because you can always enter FEL mode and use phoenixsuit. It can be maddeningly difficult to phoenixsuit to flash cold tablet but i recall it was like this: press and hold vol+ and power, plug usb cable with phoenixsuite ready to flash. release power button and vol+ few seconds later.

Problem remains the same. i have cloned a new build repos and patch with pr-9626 and rebuild image. console output result remains: U-Boot SPL 2026.01_armbian-2026.01-S127a-Pa547-Hc6a9-V2b7c-Bd0d2-R448a (May 18 2026 - 10:12:32 +0200) DRAM: 1024 MiB Something wrong with the uboot timing of the dram etc.? i can supplied the timing and trimming of the board with the funtional debian bootloader saved to spi. Setting of voltage regulators etc. see attached file. Regards Rolf hardcopy.0

Been doing some RK3588 board porting and kept running into the same category of bug — dtc compiles clean, dtbs_check passes, but the board either panics on suspend or a peripheral silently fails to probe. Stuff like: Peripheral on the EE supply wired to something that only stays alive in the AO domain → suspend-resume panic Copy-pasted a GPIO bank with 32 pins, used pin 35 → kernel panic at driver probe SPI clock request exceeds PLL maximum → silent bus hang Two nodes sharing the same GIC SPI interrupt line None of these are schema violations — they require knowing the actual cross-domain constraints of the SoC, which dtc has no idea about. So I wrote a Python tool that builds an in-memory model of the power tree, clock tree, and pin assignments, then runs constraint rules against it: $ pip install soc-consistency $ socc check board.dts --soc rk3588 error[PD-001] Power domain crossing — i2c@fe2b0000 uses vcc_3v3 (EE domain) but is connected to vcc_1v8 (AO domain). Will panic on suspend. error[GP-003] GPIO index out of bounds — gpio1 pin 35 on a 32-pin bank. warn[CK-003] Clock rate mismatch — spi0 requests 50 MHz from pll_cpll (max 24 MHz). There's also a decompile command that runs dtc on a binary blob and annotates the output with peripheral names from the SoC database — useful when you're staring at a vendor DTB and have no idea which block is at which address: $ socc decompile vendor.dtb --soc rk3588 gpio0@fd8a0000 /* GPIO0 (32-pin, 3.3V) */ { cru@fd7c0000 /* CRU — Clock and Reset Unit */ { RK3588 has the most complete constraint coverage right now. The constraint format is a simple YAML file — happy to accept PRs for other SoCs. GitHub: https://github.com/gahingwoo/SoC-Consistency Docs/rules reference: in the README If you hit false positives on a real BSP DTS, open an issue — BSP files from vendors tend to have a lot of "intentional" violations that I'm still tuning the rules around.

@Nick A TY very much for your reply, I've managed to create my first build but I am a bit confused because it made an IMG with a FAT32 boot partition, is it right or did I miss something?