I never checked, but is the sdcard encrypted? Is anyone successfully mounting the slices on sdcard, and if so how are you doing that?
Its not encrypted. At the beginning there is no GPT table but only bootloader (U-boot). Kernel and file systems are little bit later and Linux kernel takes MTD offsets, sizes and names of those filesystems from cmd boot args. That is visible from early kernel messages to uart:
[ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 coherent_pool=1m cma=257M androidboot.baseband=N/A androidboot.selinux=disabled androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(misc),0x00008000@0x00008000(resource),0x0000C000@0x00010000(kernel),0x00010000@0x0001C000(boot),0x00020000@0x0002C000(recovery),0x00038000@0x0004C000(backup),0x00040000@0x00084000(cache),0x00400000@0x000C4000(system),0x00008000@0x004C4000(metadata),0x00000040@0x004CC000(verity_mode),0x00002000@0x004CC040(baseparamer),0x00000400@0x004CE040(frp),0x000FA000@0x004CE440(rigol),-@0x00600000(userdata) storagemedia=sd androidboot.oem_unlocked=0 uboot_logo=0x02000000@0xf5c00000 loader.timestamp=2023-08-23_11:38:38 SecureBootCheckOk=0
If You have binary image file of sdcard, then You can examine it with some software like testdisk or binwalk. Testdisk gives offsets and sizes in 512 B. blocks, so eventually You need to multiply those values with this number.
You can extract those FS with dd to another file or mount them directly:
mount -t ext4 sdcard_dho924s.bin /some/empty/directory -o offset=3225419776,sizelimit=28494004224
Its easier to mount them from separate files or You can make scripts or just put it into fstab.
BTW. Some time ago... Two people asked for 924S SD card image, so here it is:
924S SD image. User: dho924s. Password is the same.
Are you planning to port out all the Android stuff to native Linux OS? This would seem like a big to-do.
Another option is to compile Qemu for your dho linux, and then just run the whole dho android in that emulator. But I am not sure what the benefits would be because all the Rigol stuff would need to run through a vm layer to get to hardware, and vice-versa.
Qemu is not any system emulator or API layer. Its just for other CPU architectures emulation. What is the point to emulate ARM64 inside ARM64?
There is something like Wine, but for Android apps. Exactly "anbox". If this works as a Linux container, then it will work almost like a on Android - maybe 1% slower. Currently Im using couple Linux containers for many years - this even can work on KVM and XEN without losing efficiency. So most probably there is no need to run another system as a guest in any way. If anbox will fail, then I will try to make real Android inside container without anbox.
Beside of Rigol app, running Linux on this scope gives opportunity to run other scope software - both for Linux and for Android. Maybe me or somebody else will find a way to get data from FPGA to give it to another existing app in real time. But now Im going to make stable system and some changes in build scripts - after that, I will make a new github repo with it and next step will be to run this app. BTW some of communication and managing FPGA is done via kernel modules compiled by Rigol - and that gives some very nice opportunities - even without decompiling it.
Right now everything works very stable with one small exception - Xorg sometimes crashes because of problems with one library - probably because of old kernel. Currently Im investigating it - I like very short error messages which tells almost nothing. I dont want to use original kernel from Rigol, but maybe I will.
BTW. Currently staff like mp4 decoding or OpenGL works like it should. Here is a little proof:
I am using Windows 10.
I'm using adb commands, but its a pain.
I didnt have any problems with adb on Debian 11 and Debian 12. Im not using Windows since XP SP2 beacuse it was always pain in the ass - especially one bug which caused to destroy all file systems on all connected disks (not only in my case)... One of my machines currently has uptime of 280 days - only one problem was temporary no free space on disk because of lack of system monitoring software (lazy me).