kybok Posted May 27 Posted May 27 2 часа назад, jock сказал: 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 thank you very much, please tell me how to write this command in u-boot? 0 Quote
jock Posted May 27 Author Posted May 27 1 hour ago, kybok said: thank you very much, please tell me how to write this command in u-boot? It's a linux shell command 0 Quote
kybok Posted May 27 Posted May 27 33 минуты назад, jock сказал: linux shell command The problem is that I can’t go anywhere now except to u-boot. After my manipulations with the system, armbian no longer loads. 0 Quote
jock Posted May 27 Author Posted May 27 3 hours ago, kybok said: The problem is that I can’t go anywhere now except to u-boot. After my manipulations with the system, armbian no longer loads. Put an armbian image on a sdcard and boot from there 0 Quote
kybok Posted May 28 Posted May 28 27.05.2024 в 19:14, jock сказал: Put an armbian image on a sdcard and boot from there too little knowledge in this, still can't boot via sd card 0 Quote
Socram Posted May 28 Posted May 28 Hello. I received today a "H20 4K Ultra HD Quad Core CPU" Android box, with a board labeled H20-221-V1.8-B in one sticker and H20_221_V1.8_230925 on the PCB mask. The machine has 2GB of RAM and 16GB of FLASH, on a eMCP H9TQ64AAETAC from Hynix. I can boot just fine on the multitool currently available on the main thread, and I've backed up the original Android 7.0 image (available here) and cleared the internal memory, but I cannot boot from any of the Armbian images from the SD. I've tried so far: Armbian_21.02.1_Rk322x-box_buster_current_5.10.12_minimal.img.xz Armbian_24.2.5_Rk322x-box_bookworm_current_6.6.22_minimal.img.xz Armbian_community_24.8.0-trunk.6_Rk322x-box_bookworm_current_6.6.31_minimal.img.xz To no avail. This board does not seem to have UART headers so I cannot provide more detailed information about why is that the case. All I can tell is the HDMI output is dead even after waiting for a significant amount of time (10 minutes), and the blue LED that lights up with Android stays dead (with both multitool and Armbian), only having a dimly lit red one instead. 0 Quote
RaptorSDS Posted May 29 Posted May 29 vor 5 Stunden schrieb Socram: The machine has 2GB of RAM and 16GB of FLASH this looking not as rk322x , i thing thats another main chip like rk328x or newer , we see some box that boot multitool without rk322x 1 Quote
Socram Posted May 29 Posted May 29 (edited) You're right! It's a RK3288. I thought it was a RK3228A because that's what the vendor advertised. I realized the thing was actually replying to pings, removed the MicroSD, chrooted into the machine and created an user and enabled ssh, connected to it and sure enough: [ 9.831684] rk3288-crypto 100a0000.cypto-controller: will run requests pump with realtime priority [ 9.831930] rk3288-crypto 100a0000.cypto-controller: Register ecb(aes) as ecb-aes-rk [ 9.832042] rk3288-crypto 100a0000.cypto-controller: Register cbc(aes) as cbc-aes-rk [ 9.832082] rk3288-crypto 100a0000.cypto-controller: Register ecb(des) as ecb-des-rk [ 9.832112] rk3288-crypto 100a0000.cypto-controller: Register cbc(des) as cbc-des-rk [ 9.832139] rk3288-crypto 100a0000.cypto-controller: Register ecb(des3_ede) as ecb-des3-ede-rk [ 9.832170] rk3288-crypto 100a0000.cypto-controller: Register cbc(des3_ede) as cbc-des3-ede-rk [ 9.832199] rk3288-crypto 100a0000.cypto-controller: Register sha1 as rk-sha1 [ 9.832232] rk3288-crypto 100a0000.cypto-controller: Register sha256 as rk-sha256 [ 9.832261] rk3288-crypto 100a0000.cypto-controller: Register md5 as rk-md5 I do see RK3288 references. Thanks for the tip! armbian-hardware-monitor.zip EDIT: No, I think this is actually a RK3229 based on the DTS. I also opened the device and, while I cannot read the specific part number because it is hidden under the heatsink, it's a plastic IC so it cannot be a RK3288 which was sold in a metal BGA package. An except from the multitool dmesg log regarding the DRM: [ 2.648953] [drm] Initialized drm 1.1.0 20060810 [ 2.656047] [drm] Rockchip DRM driver version: v1.0.1 [ 2.661464] rockchip-drm display-subsystem: devfreq is not set [ 2.668188] rockchip-drm display-subsystem: bound 20050000.vop (ops 0xb0d05b78) [ 2.676005] i2c i2c-0: of_i2c: modalias failure on /hdmi@200a0000/ports [ 2.682689] dwhdmi-rockchip 200a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 2.690553] dwhdmi-rockchip 200a0000.hdmi: Detected HDMI TX controller v2.01a with HDCP (inno_dw_hdmi_phy) [ 2.701808] rockchip-drm display-subsystem: bound 200a0000.hdmi (ops 0xb0cfe0d8) [ 2.709310] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2.715950] [drm] No driver support for vblank timestamp query. [ 2.722040] rockchip-drm display-subsystem: failed to parse display resources [ 3.353464] rockchip-vop 20050000.vop: [drm:vop_crtc_enable] Update mode to 1920x1080p60, type: 11 [ 3.354145] dwhdmi-rockchip 200a0000.hdmi: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13 [ 3.354154] dwhdmi-rockchip 200a0000.hdmi: colorspace: RGB [ 3.354161] dwhdmi-rockchip 200a0000.hdmi: scan mode: Underscan [ 3.354168] dwhdmi-rockchip 200a0000.hdmi: colorimetry: No Data [ 3.354174] dwhdmi-rockchip 200a0000.hdmi: picture aspect: 16:9 [ 3.354181] dwhdmi-rockchip 200a0000.hdmi: active aspect: Same as Picture [ 3.354188] dwhdmi-rockchip 200a0000.hdmi: itc: IT Content [ 3.354194] dwhdmi-rockchip 200a0000.hdmi: extended colorimetry: xvYCC 601 [ 3.354202] dwhdmi-rockchip 200a0000.hdmi: quantization range: Full [ 3.354209] dwhdmi-rockchip 200a0000.hdmi: nups: Unknown Non-uniform Scaling [ 3.354216] dwhdmi-rockchip 200a0000.hdmi: video code: 16 [ 3.354223] dwhdmi-rockchip 200a0000.hdmi: ycc quantization range: Full [ 3.354230] dwhdmi-rockchip 200a0000.hdmi: hdmi content type: Graphics [ 3.354236] dwhdmi-rockchip 200a0000.hdmi: pixel repeat: 0 [ 3.354245] dwhdmi-rockchip 200a0000.hdmi: bar top 0, bottom 0, left 0, right 0 [ 3.430974] Console: switching to colour frame buffer device 240x67 [ 3.598766] rockchip-drm display-subsystem: fb0: frame buffer device In the case of the latest version of Armbian: [ 1.557514] inno-hdmi-phy 12030000.hdmi-phy: error -ENXIO: IRQ index 0 not found [ 1.558040] inno-hdmi-phy 12030000.hdmi-phy: phy_flag is: 0 [ 1.560579] rockchip-drm display-subsystem: bound 20050000.vop (ops 0xb1179c70) [ 1.560740] dwhdmi-rockchip 200a0000.hdmi: supply avdd-0v9 not found, using dummy regulator [ 1.561045] dwhdmi-rockchip 200a0000.hdmi: supply avdd-1v8 not found, using dummy regulator [ 1.561515] dwhdmi-rockchip 200a0000.hdmi: Detected HDMI TX controller v2.01a with HDCP (inno_dw_hdmi_phy2) [ 1.563057] dwhdmi-rockchip 200a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.563492] rockchip-drm display-subsystem: bound 200a0000.hdmi (ops 0xb117d958) [ 1.564699] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0 [ 1.564912] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 1.565125] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes Seems it is unable to find the CRTC? device-dtb-and-dts.zip multitool-dmesg.zip EDIT 2: I can guarantee 100% this is a RK3228. Reading the eFuses: root@multitool:~# cat /sys/bus/nvmem/devices/rockchip-efuse0/nvmem | od -tx1 -An 52 4b 23 82 81 f0 70 55 52 4b 58 32 32 30 33 33 00 00 00 00 0c 0e 26 05 00 04 01 00 00 78 00 00 Note bytes 0x02 and 0x03 are 0x23 0x82, which indicate a RK3228 Edited May 29 by Socram 1 Quote
jock Posted May 29 Author Posted May 29 @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 2 Quote
Socram Posted May 29 Posted May 29 @jock yup, you were right! led-conf8 seems to be perfect and everything works now! Many thanks for your help! I read on the first post that these GPIO settings could affect Bluetooth, WiFi and the LEDs but didn't think it could also affect something as basic as the HDMI output. Maybe some warning bit about trying SSH if HDMI is not functioning could be added to the main post for noobs like me? 0 Quote
Sigma7 Posted May 29 Posted May 29 Currently, in Windows 11, my memory cards with Multitool installed are not opening the partition that contains the backup, images, etc, folders, only the other one, called BOOTSTRAP. Anyone else having this problem? This only occurs on Windows 11. When I plug it into an MXQ Pro with Armbian, both partitions are recognized and open normally. 0 Quote
jock Posted May 30 Author Posted May 30 9 hours ago, Sigma7 said: Currently, in Windows 11, my memory cards with Multitool installed are not opening the partition that contains the backup, images, etc, folders, only the other one, called BOOTSTRAP. Anyone else having this problem? This only occurs on Windows 11. When I plug it into an MXQ Pro with Armbian, both partitions are recognized and open normally. 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 0 Quote
Nikolay Belyaev Posted May 30 Posted May 30 Hey, Please help with wifi (sv6051p). dmesg, iwconfig, rfkill in attachment. Wifi don't work: WWAN-HW unavailable. On boot message: SSV WLAN driver ssv6200: Using SSV6051Q setting But on chip text: SV6051P. Is it possible to set correct setting in /etc/modprobe.d/ ? Thanks 0 Quote
ToShuk Posted June 1 Posted June 1 mx4 pro I tried to write to nand archive/Armbian_24.2.5_Rk322x-box_jammy_current_6.6.22.img via multitool, and get this message Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enougth?) - Missing modules (cat /proc/modules; ls /dev) ALERT! UUID=b9866ace-f260-437c-9794-8e1a363a3c71 does not exist. Dropping to a shell. I guess only legacy images is work now, how to fix this problem, who can help? 0 Quote
Hqnicolas Posted June 1 Posted June 1 (edited) 2 hours ago, ToShuk said: ALERT! UUID=b9866ace-f260-437c-9794-8e1a363a3c71 does not exist. Dropping to a shell. open the SD card on other linux computer and edit boot/armbianEnv.txt boot args to your UUID $lsblk $ blkid Edited June 1 by Hqnicolas 0 Quote
ToShuk Posted June 1 Posted June 1 1 hour ago, Hqnicolas said: open the SD card on other linux computer and edit boot/armbianEnv.txt boot args to your UUID But how can i do it via `multitool.img.xz` ? I flash NAND from multitool.img.xz 0 Quote
ToShuk Posted June 1 Posted June 1 1 hour ago, Hqnicolas said: your UUID and how to determine my UUID ? new UUID 0 Quote
Hqnicolas Posted June 1 Posted June 1 ok..... you can edit your image file before drop on multitool unzip the file and rename it to disk_image.img mount the image to a temp folder with the following commands: sudo losetup --partscan /dev/loop14 disk_image.img mkdir /tmp/disk_image sudo mount /dev/loop14p1 /tmp/disk_image ####### EDIT all files you want inside /tmp/disk_image/boot ########## sudo fstrim -v /tmp/disk_image sudo umount /tmp/disk_image sudo losetup --detach /dev/loop14 zip files back to small size and drop to muititool 0 Quote
ToShuk Posted June 1 Posted June 1 3 minutes ago, Hqnicolas said: # EDIT all files you want inside /tmp/disk_image/boot Understood, but how to determine correct UUID ? 0 Quote
Hqnicolas Posted June 1 Posted June 1 (edited) 6 minutes ago, ToShuk said: Understood, but how to determine correct UUID ? you can run the command: $lsblk $blkid when the image was mounted on your linux desktop computer and take the UUID from the loop ROOTFS partition i think the command fdisk -l disk_image.img wont return the correct UUID of partition inside Disc image Edited June 1 by Hqnicolas 0 Quote
jock Posted June 1 Author Posted June 1 3 hours ago, ToShuk said: I tried to write to nand archive/Armbian_24.2.5_Rk322x-box_jammy_current_6.6.22.img via multitool, and get this message 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. 0 Quote
Hqnicolas Posted June 1 Posted June 1 1 minute ago, jock said: mainline kernel don't work with NAND. wow! thats unespected. 0 Quote
ToShuk Posted June 1 Posted June 1 Just now, jock said: 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. So, the case with updating UUID like Hqnicolas say won`t work? 0 Quote
Hqnicolas Posted June 1 Posted June 1 (edited) 2 minutes ago, ToShuk said: So, the case with updating UUID like Hqnicolas say won`t work? no, because the kernel can't see nand devices, this is why it cant find the UUID the device dont exist for kernel mainline My opinion = SDCARD K6.6 > NAND k4.4 Edited June 1 by Hqnicolas 1 Quote
ToShuk Posted June 1 Posted June 1 Thank you so much! everything is clear for me. another question, where I can find the latest Legacy img ? i guess it is only Debian buster? 0 Quote
jock Posted June 1 Author Posted June 1 17 minutes ago, ToShuk said: So, the case with updating UUID like Hqnicolas say won`t work? 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. 1 Quote
Hqnicolas Posted June 1 Posted June 1 3 minutes ago, jock said: a Flash Translation Layer (FTL) that is embedded as assembly code into the vendor kernel this is what I call "son of a rockchip" they promess functions that contains proprietary software they make a kernel and abandon it, they don't put things in the mainline for legacy. Without Armbian developing these rockchip devices they will go down in history as industrial waste 0 Quote
Hqnicolas Posted June 1 Posted June 1 25 minutes ago, ToShuk said: i guess it is only Debian buster? Build legacy it with v22.08 armbian https://github.com/armbian/build/blob/v22.08/patch/kernel/rockchip64-legacy git clone --depth 1 --branch v22.08 https://github.com/armbian/build cd build ./compile.sh 1 Quote
jock Posted June 1 Author Posted June 1 24 minutes ago, Hqnicolas said: Without Armbian developing these rockchip devices they will go down in history as industrial waste 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. 0 Quote
Hqnicolas Posted June 1 Posted June 1 7 minutes ago, jock said: 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. nand is really necessary, but I wanted to understand why SD cards didn't suffer from the lack of FTL software. I was thinking of why we couldn't just run NAND as sdhci but SD cards have cotroller inside..... 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.