Thank You for your continued support and contributions!
Here we go!Rockbox for the FiiO M3K is available on my site:http://xvtx.ru/rockbox/download.htmP.S. source code will available later, when all settle a bit.
- Can the dual boot screen be bypassed or set to be very short?- Would you recommend this player and Rockbox port?
#!/bin/ashinsmod /lib/modules/3.10.14/kernel/driver/staging/dwc2/dwc2.koinsmod /lib/modules/3.10.14/kernel/driver/usb/gadget/libcomposite.koinsmod /lib/modules/3.10.14/kernel/driver/usb/gadget/u_serial.koinsmod /lib/modules/3.10.14/kernel/driver/usb/gadget/usb_f_serial.koinsmod /lib/modules/3.10.14/kernel/driver/usb/gadget/usb_f_acm.koinsmod /lib/modules/3.10.14/kernel/driver/usb/gadget/g_serial.kogetty /dev/ttyGS0 115200
/proc/mtd:dev: size erasesize namemtd0: 00020000 00020000 "uboot"mtd1: 00400000 00020000 "kernel"mtd2: 00500000 00020000 "recovery"mtd3: 05000000 00020000 "rootfs"mtd4: 026e0000 00020000 "data"/proc/version:Linux version 3.10.14-g60d92e8-dirty (fiio64@ubuntu) (gcc version 4.7.2 (Ingenic 2016.11) ) #3 PREEMPT Fri Sep 27 11:46:20 CST 2019/proc/cpuinfo:system type : halley2_v10machine : Unknownprocessor : 0cpu model : Ingenic Xburst V4.15 FPU V0.0BogoMIPS : 1001.88wait instruction : yesmicrosecond timers : notlb_entries : 32extra interrupt vector : yeshardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]isa : mips32r1ASEs implemented :shadow register sets : 1kscratch registers : 0core : 0VCED exceptions : not availableVCEI exceptions : not availableHardware : halley2Serial : 00000000 00000000 00000000 00000000/proc/meminfo:MemTotal: 58140 kBMemFree: 43032 kBBuffers: 476 kBCached: 2944 kBSwapCached: 0 kBActive: 2940 kBInactive: 1500 kBActive(anon): 1024 kBInactive(anon): 4 kBActive(file): 1916 kBInactive(file): 1496 kBUnevictable: 0 kBMlocked: 0 kBSwapTotal: 0 kBSwapFree: 0 kBDirty: 8 kBWriteback: 0 kBAnonPages: 1024 kBMapped: 1308 kBShmem: 8 kBSlab: 3444 kBSReclaimable: 1060 kBSUnreclaim: 2384 kBKernelStack: 352 kBPageTables: 156 kBNFS_Unstable: 0 kBBounce: 0 kBWritebackTmp: 0 kBCommitLimit: 29068 kBCommitted_AS: 35264 kBVmallocTotal: 1048372 kBVmallocUsed: 2096 kBVmallocChunk: 1045868 kB/proc/mount_points:rootfs on / type rootfs (rw)ubi0:rootfs on / type ubifs (rw,relatime)proc on /proc type proc (rw,relatime)sysfs on /sys type sysfs (rw,relatime)tmpfs on /dev type tmpfs (rw,relatime,size=10240k)tmpfs on /tmp type tmpfs (rw,relatime,size=10240k)mdev on /dev type tmpfs (rw,relatime)devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)tmpfs on /dev/shm type tmpfs (rw,relatime,size=5120k)ubi1_0 on /data type ubifs (rw,relatime)/dev/mmcblk0p1 on /mnt type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=936,iocharset=utf8,shortname=mixed,errors=remount-ro)/proc/cmdline:mem=64M@0x0 no_console_suspend console=ttyS2,115200n8 lpj=5009408 ip=off init=/linuxrc ubi.mtd=3 root=ubi0:rootfs ubi.mtd=4 rootfstype=ubifs rw loglevel=8/etc/os-release:NAME=BuildrootVERSION=2014.05-00055-g03a0bb5ID=buildrootVERSION_ID=2014.05PRETTY_NAME="Buildroot 2014.05"
First of all, it seems like xvortex somehow has access to FiiO's firmware signing keys? The firmware is a zip archive containing around 66 1MB chunks (kernel and rootfs), and every single part is individually signed with apksign!!! The recovery partition is what verifies (I have not tested unsigned/self-signed chunks yet) the individual chunks and writes them to the internal SPI NAND. You can decompress all of the individual parts, concatenate all the rootfs segments together, and you'll have a regular UBI image to play with.
2. Regardless of whether xvortex ends up releasing the source (I certainly hope they do), we need a soulution for generating update packages that doesn't involve FiiO's signing keys. Getting a signed intermediary package would be interesting, and then perhaps we can patch the recovery to disable signature verification?
# ubinfo /dev/ubi0ubi0Volumes count: 1Logical eraseblock size: 126976 bytes, 124.0 KiBTotal amount of logical eraseblocks: 640 (81264640 bytes, 77.5 MiB)Amount of available logical eraseblocks: 0 (0 bytes)Maximum count of volumes 128Count of bad physical eraseblocks: 0Count of reserved physical eraseblocks: 20Current maximum erase counter value: 15Minimum input/output unit size: 2048 bytesCharacter device major/minor: 250:0Present volumes: 0# ubinfo /dev/ubi1ubi1Volumes count: 1Logical eraseblock size: 126976 bytes, 124.0 KiBTotal amount of logical eraseblocks: 311 (39489536 bytes, 37.7 MiB)Amount of available logical eraseblocks: 0 (0 bytes)Maximum count of volumes 128Count of bad physical eraseblocks: 0Count of reserved physical eraseblocks: 3Current maximum erase counter value: 11Minimum input/output unit size: 2048 bytesCharacter device major/minor: 249:0Present volumes: 0
The main player application is aggressively logging to /data/userfs/app.log. I'm really concerned about this wearing out my NAND, so I deleted it and made a symlink to /dev/null
rm /data/userfs/app.logln -s /dev/null /data/userfs/app.log
Page created in 0.172 seconds with 20 queries.