tooz

hello @Frank, To set up the environment: Install docker and asus-docker-env Follow GitHub - asus-iot/asus-docker-env to run asus_docker_env_run Install necessary packages below : sudo apt-get install libgmp-dev sudo apt-get install libmpc-dev sudo apt-get install bsdmainutils sudo apt-get remove live-build git clone https://salsa.debian.org/live-team/live-build.git --depth 1 -b debian/1%20230131 cd live-build rm -rf manpages/po/ sudo make install -j8 Use build.sh to build code base

hello @Frank, sorry for the confusion, that's correct. the latest version is v.3.0.27

hello @Frank Disable auto login for the uart console and the dekstop environment. Force the user linaro to change its password at the linaro's next login Eable ROCKCHIP_EFUSE config for u-boot to set cpuid from efuse to fix the issue that all CPU has the same ID

hello @Frank, were you able to use buildroot? may i have the full log please?

if you're using a x86 wsl there might be something relates to architecture similar to: https://askubuntu.com/questions/1006846/chroot-onto-arm-based-image it's necessary to have qemu supported in aarch64/ arm64. some reference: https://www.cnx-software.com/2016/05/10/how-to-run-ubuntu-16-04-aarch64-64-bit-arm-cloud-images-on-your-intelamd-linux-computer/ the easiest way to cross compile would be having a ubuntu host machine

hello @Frank, is your host machine an x86 host? if so, the steps above is to set up the right environment as tinkerboard is arm based

hello @Frank, did this happen when you run ./build.sh? you might want to install qemu-user-static and then copy it to the mounted point e.g. /mnt/usr/bin sudo apt install qemu-usr-static sudo cp /usr/bin/qemu-arm-static /path/to/mount/usr/bin and then restart the system systemctl restart systemd-binfmt.service

hello @syse-miya, you'll need to disable it through dtoverlay, similar to: which os are you using? debian 11?

hello @Frank, yes, please refer to wiki: Developer Guide · TinkerBoard/TinkerBoard Wiki · GitHub >change the boot logo yes

hello @Frank, https://tinkerboard.github.io/docs/tinker_os-releases/tinker_board the branch is: linux4.4-rk3288-tinker_board manifest: tinker_board-debian-3.0.23.xml if you'd like to use the latest: repo init -u https://github.com/TinkerBoard-Linux/rockchip-linux-manifest.git -b REVISION

hello @robotmyst, how do you test it and what commands do you use? have you tried accessing the gpios from sysfs?

hello @HaTo, if you're using a supported lte module and it's recognised by the os, there's no extra work in order to make the module work. i tried to use a quectel em05 m.2 lte + sim to reproduce the issue and i'm not able to present the issue. (you can use command networkcli or the network manager on the top right to check if the lte is working) the design of nano sim slot connection of tinker board 3n follows the specifications of quectel lte modules. i'd recommend to check with quinton hazell for details, or try using another module that's officially supported: Tinker Board

hello @Sebastian, to compile the dtbo: dtc -@ -O dtb -o disable-gpu-wifi.dtbo disable-gpu-wifi.dts (or, you can download the dts & dtbo from this link ) once you have the dts and dtbo, move them to the /boot/overlays and modify the config.txt cp disable-gpu-wifi.dtbo /boot/overlays/ sudo vim /boot/config.txt overlay=disable-gpu-wifi sudo reboot to verify that gpu is disabled: check if the directory /sys/devices/platform/ffa30000.gpu/ exists; if it's non existent = gpu is disabled this is what in the disable-gpu-wifi.dts: /dts-v1/; /plugin/; / { compatible = "rockchip,rk3288"; fragment@0 { target = <&gpu>; __overlay__ { status = "disabled"; }; }; fragment@1 { target-path = "/wireless-wlan"; __overlay__ { status = "disabled"; }; }; };

hello @HaTo, i'm not sure if it's caused by the different design of sim pin in as it's not part of the qvl if the card is recognised, perhaps you could ask the modem vendor for at commands for setup

hello @dellfer, there's something wrong with pmic from the log, usually the boot process will set parameters for: vdd_center 900000 uV vdd_cpu_l 900000 uV vdd_log 1100000 uV it might be caused by the uboot defconfig & kernel dts changes. have these been modified? if so, what are the modifications?