cmuki

@Hqnicolas The VPU isn't working, sadly. I tried the image from @hzdm, but the HDMI behaviour that I outlined is still present. Also, I can't reboot with "sudo reboot" properly, but don't remember if that was the case previously. About the NPU - I'm not sure, but I think it was working, when I ran sbc-bench - https://0x0.st/Xvsr.bin Here's some info on the mainlining efforts - https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3576/-/blob/main/mainline-status.md?ref_type=heads

Hey, @hzdm! Congrats on the success and thank you for everything that I couldn't do! Do you also have the same problem as me with plugging/unplugging the HDMI cable (the board hangs)? I'll try your images later and report back if the problem is present on my side. Also - is it normal for the MAC address to be different every time you flash a new version of the OS? I know that some boxes have different MAC addresses for each reboot, but didn't find anything for different versions of Linux.

Hey, @Hqnicolas! I tried that, but can't seem to find "Disable mtd_vendor_storage" and also which phy0 should I disable in the dts - everything with phy0 in its name? The box crashes still when hdmi is plugged in, again with the same error - [Sep 2 14:10] dwhdmi-rockchip 27da0000.hdmi: i2c read err! When I have the display hooked in, after the Ubuntu loading screen I can see the bootlog and the display blinks 3 times and goes to a boot console (not a login console). EDIT: Also one question - I saw in dmesg this kernel command line, but I have no idea where it is setup:

Actually it turned out that the Joshua's Ubuntu was trying to boot, but failing - I hooked an HDMI cable and saw the Ubuntu loading screen, but it hangs after that. The HDMI unplug/plug hang is still here. I managed to boot into recovery through U-boot and press Enter for maintenance; got the dmesg below: EDIT: This is the message from the UART console when trying to reboot - [ 64.768385] (sd-umoun[1162]: Failed to unmount /run/shutdown/mounts/9381dc420ead2d1b: Device or resource busy [ 64.776228] shutdown[1]: Unable to finalize remaining file systems, ignoring. Maybe related to the fact that I'm running directly from emmc?

Hey, it's me again! Today I was playing around an unhealthy amount of time with the box - most of it went to trying to compile different images. Sadly, I was unsuccessful with compiling (and it took most of my time today) ubuntu-rockchip even though it has the ArmSoM Sige 5 image - the board didn't want to boot. I tried later compiling a full image with armbian/build, but I saw really late that only building from main is supported - D'OH! That's why I downloaded the Gnome image from here, changed the DTBs once again and was able to boot with a Desktop environment. Video playback (not HW accelerated) works, but fullscreen 1080p youtube video stutters. There is also sound from the HDMI! But, once again - once rebooted, the box doesn't reboot and hangs and I can't plug and unplug the HDMI for the same reason. I'm not sure what else I can do at the moment except provide some logs and files. https://paste.armbian.com/eqodoposub

How to get DB and boot into Armbian: 1. Connected to the TV box via ethernet and got the DTB through ADB - https://github.com/warpme/minimyth2/wiki/Getting-device-tree-from-TVbox-vendor-Android (couldn't get usb to work with ADB). 2. Cloned https://github.com/armbian/build, ran ./compile.sh and went with all default Options - Do not change the kernel configuration -> Show CSC/WIP/EOS/TVB -> armsom-sige5 -> vendor -> noble -> Image with console interface (server) -> Minimal image with console interface. 3. Flashed it on a USB Drive with USB Imager. 4. (On Linux) replaced the dtb file rk3576-armsom-sige5 with the Android dtb (I just did it the lazy way and renamed it the same way - rk3576-armsom-sige5). 5. Connecting to the box with UART, I was able to go to the U-boot menu this way: - while booting, spam ctrl+c and you'll see a faint console:~/ line between all the bootlog lines. If you don't see it, you need to toggle the power on the box; - typing "su" and enter - that way you gain root; - type "reboot", enter and spam ctrl+c again to interrupt the boot process. 6. Plugging in the USB Drive (and the ethernet cable at this point) in the USB 3 port, you should run "usb start" and confirm that 1 Storage device is active (if not, you can unplug and plug the drive and run "usb reset" until it shows up) and run "run bootcmd_usb0". 7. Still using UART, you can set a root password and create an account through screen and ssh in the box after that. Problems: I didn't manage to get a desktop environment going - I only saw the Ubuntu 24.04 loading screen and nothing after that. After installing something (I think related to the DE or GPU drivers) I couldn't reboot cleanly (after unbricking and reisntalling Armbian now rebooting works as expected). After reinstalling, the MAC Address of the eth0 is different. Unbrick: I managed to brick it after flying too close to the Sun and changing the kernel from armbian-config - the device was trying to boot the new kernel, but was getting stuck after ethernet and iommu. The worse thing was that the USB was not working during in the u-boot menu, meaning I couldn't boot from the USB drive. To unbrick it, from the u-boot menu I put the device in Loader mode by running "rockusb (I think it was rockusb 0 mmc 0 - there are instructions)" and reflashing the MY CUSTOM IMAGE with the correct DTB (from the Mega folder) with "rkdeveloptool write 0 rockchip.img" (there are probably better ways to do such an image, but I used ddrescue to create an img of the USB Drive). Be advised that I couldn't put the device is Maskrom mode with rkdeveloptool.

Hey, @Hqnicolas! When comparing the two files (my dts and the Armsom), maybe the bigest one is this one below: Also - the problem seems to be when plugging and unplugging the hdmi cable - with it in the box it boots and I can see an output on my display. And a question - since the box was running (allegedly) Android 14, which is using Kernel 6.1, would the difference between the DTBs be that big (Android DTB = Kernel 4.19 ≠ Mainline DTB = Kernel 6+ as you said)?

Success! Yesterday late in the evening I managed to boot from usb. What I did was burn Armbian-unofficial_24.11.0-trunk_Armsom-sige5_noble_vendor_6.1.75_minimal to a USB drive, replace the dtb with the one from Android and boot with the commands "usb start" and "run bootcmd_usb0". I couldn't get ROC's image nor Multiboot (with the replaced dtb) to boot this way. EDIT: Installed it to eMMC and ran sbc-bench - results https://0x0.st/Xvsr.bin When I plug in the HDMI, it crashes Will have to investigate. dwhdmi-rockchip 27da0000.hdmi: i2c read err!

@Vincenzo Dentamaro work in progress! @Hqnicolas - Why don't we need the dtb from the box? I finally managed to get it from Android through adb. The backup with the loader from Mekotronics was also successful and I can still boot in Android, so I think it should be usable. Can I boot from USB or should I nuke the eMMC and try to flash a custom compiled image (that said, I'll have to check out if I can do it myself or I would need your help)? fdisk -l returns this for the exported image: box.dtb box.dts

Hey! Firstly, I wanted to create a backup for the box so that @El308 can unbrick it and if I screwed something up, I wanted to create a backup. I found the Miniloader on Mekotronics' website, uplodaded it below. Currently doing a full backup with RKDevTool, but will get back to you to ask if I did something incorrectly. RK3576_MiniLoaderAll.bin

@Hqnicolas, thanks for all the resources, I'm going through them, but just hitting potholes along the way. I managed to grab the output for fdt from u-boot, would that be helpful here? I tried several more things, but to no avail. screenlog.txt

Hmm, I think I didn't do the backup correctly, because the baseparamter file is full of "cc" when opening it in Hex editor. Also the backup that I create is 200 MB and the one from mvpwar is 64 GB. For additional info - VID and PID: DevNo=1 Vid=0x2207,Pid=0x350e,LocationID=303 Loader

It's me again. Below are actually the testpoints that I used to get the bootlog. Be advised that they are too narrow for a conventional jumper cable, that's why I had to hold them down while booting. I also used one of the screwholes as a GND. Here's the dump with rkdeveloptool - https://mega.nz/folder/GAo2DToY#b2LLSVPliw2iH6-fvDCcqw I used the pinenote-backup for automation since I didn't want to do it manually - https://github.com/talpadk/pinenote-backup and it seems it's successful. Can I also create an image from the dump? Let me know if I did something incorrectly and have to redo it again. EDIT: Ran rkdeveloptool rl 0 244285440 dump_h96max9.img, added it to the MEGA folder. The device is in Loader mode; also usb 3.0 needs to be used to connect the device to the computer.

Hello to all! Today my box arrived and I took some photos of it. I'm currently checking the testpoints since I couldn't dump the firmware, but I'll update this comment once I succeed. I'll post a bootlog once available. Be careful not to damage the WiFi antenna when opening the box. EDIT 1: Added 3 bootlogs, because I couldn't capture everything at once with Putty. boot2.txt boot3.txt boot1.txt

Dear @jock, Today I managed to buy a UART converter - sadly, these are the first rows of the boot log (copy-pasted the output from Putty window to a txt file): DDR version 1.16 20190713 ID:0xFFF In DDR3 333MHz Bus Width=32 Col=11 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=2048MB ddrconfig:2 OUT It seems that the RAM is, as Armbian was able to detect, 2 GB. Only this ddrconfig: 2 value is peculiar. I've attached the whole output, but don't know if there is something else relevant, which is missing from it Thank you once again for your support! If I can provide any further information, I'm available. Best regards! EDIT: Using the DDR Version I was able to find this comment from chess12 and there are three differences between our outputs : 1. Row=16 instead of 15 2. Size=4096 3. ddrconfig:3 boot log.txt

@jock, thank you for you swift reply! I'll try to get my hands on a UART module in the next couple of weeks and report back. Hopefully the information will be helpful for other members of the forum as well!

Hello, guys! This would be my first post in the forum and I want to thank everyone contributing to the Armbian effort - I haven't had that much fun tinkering since forever! My question is related to the RAM detection - I've scoured this thread as well as the possible other places for information, but couldn't find quite the same case, even though it's referenced at least 3 times inside this thread: Multitool and Armbian only pick up 2 GB of ram; I've opened the box and there are 8 total K4B4G0446C chips on it (4 on each side). According to other posts, the data in the datasheet is shown in Gb instead of GB and, if my calcualtions are correct, it has 4 x 4 Gb, two on each side = 32 Gb = 4 GB RAM. Is it possible that only one half is operational? If these are binned chips, is it possible for them to be halved? In all other cases regarding the RAM capacity that I've read about here the TV box already came with the wrong RAM size. In another forum users reported halving of the RAM after an Android firmware update, but there was an (Android) image that fixed the issue (I wouldn't know if it was fake or fixed a software bug). The board is X88 PRO-B-RK3318-D4-V1.2 4 GB RAM (allegedly)/ 32GB ROM model (even though 64 ROM was ordered). As you can probably guess, before installing Armbian, Android reported 4 GB RAM/64 GB ROM, but all apps for filling up the RAM couldn't be installed. Images of the board can be found here - https://imgur.com/a/wTQqXO5; armbian hardware log - http://ix.io/3XvN; dmesg: I tried extracting the device tree file, but was able to get 11 different files; if they would be of help, I can also provide them here. Unfortunately, I do not have a UART module, but am willing to search for one locally. Thank you in advance and have a nice day!