Fiio M3k

[Njones]

I Updated the M3k firmware to 1.4.3 and now I can't get rockbox to work?

[swap]

Thanks, Great Port.

I have a question.

Fiio m3k Rockbox provide USB support?

Im new en Rocbox and not found howto transfer file usb.

Thanks

[diegopau]

Hi XVortex,

Are there any plans to further update the firmware for the M3k?

I posted a few issues and suggestions in these messages
http://forums.rockbox.org/index.php/topic,52952.msg245026.html#msg245026
http://forums.rockbox.org/index.php/topic,52952.msg245080.html#msg245080

I would love to know if you plan to address any of those in the future.

Thanks again for bringing Rockbox to this player.

[bbame]

I was excited to find a rockbox port for my brand new Fiio M3k.  The stock firmware lacks features I've become used to on my old (now dead) SanDisk Clip+ which ran rockbox.  So first of all, thanks very much for doing this!!!

I do have one question, though.  Fast Forward and Rewind don't work - pressing/holding the buttons just makes the screen flash rapidly - and I was wondering if there was something I could do to fix it.  Maybe revert to an earlier version or play with the settings somehow?  Since I listen to a lot of audio books and podcasts and often find myself rewinding/relistening, or fast fowarding past boring parts (or advertising), lack of FF/RW is a big deal for me.

I found other reports of FF/RW not working on this forum - someone suggested changing FF/RW Accel to "Very fast", which I did, but it had no effect.  For now I have changed "skip length" from "skip track" to "30s", but that's really irritating when I'm listening to music and want to skip a song/track.

Any advice?

Specifics: Fiio M3K, originally with stock firmware 1.4.3, now with the latest M3K rockbox version (also 1.4.3).

[speachy]

Here we go!
Rockbox for the FiiO M3K is available on my site:
http://xvtx.ru/rockbox/download.htm

P.S. source code will available later, when all settle a bit.

It's been well over six months since you posted that initial version; Have things settled sufficiently for you to toss the source code our way?  I'd love to get this integrated into the mainline.

[whiskerc]

Two quick questions for anyone using Rockbox on the M3k.

- Can the dual boot screen be bypassed or set to be very short?
- Would you recommend this player and Rockbox port?

I am a longtime (many year) user of Rockbox on the Clip+, but like many others would like to get a replacement ready for when the Clip+ is no more. 

Long live Rockbox

[speachy]

- Can the dual boot screen be bypassed or set to be very short?
- Would you recommend this player and Rockbox port?

Given that the source code for the m3k port has not been publicly released, the answer to both question is, unfortunately, no.

[sohnemann]

@XVortex

Is there any timeline on when the source will be available?
Would love to contribute to this port. 

Cheers
sohnemann

[efqw]

UPDATE: I have wiki access now, and I'll be moving important bits from my posts to the wiki page soon. Internal pictures have already been uploaded, along with links to datasheets for every single chip found in this device and disassembly instructions.
https://www.rockbox.org/wiki/FiioM3K

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.

FiiO was accidentally being incredibly helpful here by not stripping the main player binary in the stock fw (xvortex stripped them to make more room for rockbox), so I managed to get a reliable serial console on xvortex's firmware without having to open up the device. You can save this script in your MicroSD and launch it from xvortex's bootloader menu to get a serial console over USB. I've spent a few hours looking at fiio's main player program with Ghidra a while ago, it loads these modules if you connect the device to USB without a MicroSD card inserted (presumably for writing serial numbers). The main player binary immediately hangs up/unloads the kernel modules if you send something into the serial connection, so I assume we won't get a proper shell from that. Luckily busybox was compiled with getty

Code: [Select]

#!/bin/ash
insmod /lib/modules/3.10.14/kernel/driver/staging/dwc2/dwc2.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/libcomposite.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/u_serial.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/usb_f_serial.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/usb_f_acm.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/g_serial.ko
getty /dev/ttyGS0 115200



Some thoughts:

1. FiiO's buildroot is based on Ingenic's Halley2 buildroot BSP. The Halley2 BSP kernel, u-boot, buildroot and other misc files can be obtained from their FTP server. Please try to mirror it if you can, ingenic has a habit of silently removing files from their FTP server: ftp://198.13.102.99/ingenic_support/X1000_X1000E_X1500/01_SW/00_Board-Level_Consolidation_Version/Kernel3.10.14_X1000_New_Version/08_ingenic-linux-kernel3.10.14-x1000-v9.0-20191212/ingenic-linux-kernel3.10.14-x1000-v9.0-20191212.tar.bz2

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?

3. My attempts on opening this device non-destructively have not been successful because it was glued shut. Applying heat doesn't seem to do much good as the screen still can't be pulled off with a suction cup clamp. Without access to the PCB (native UART), I won't be able to easily recover the device if something goes wrong with the recovery partition, so I can't tinker with the recovery for now.


Finally, here is some system info. Let me know if you have any questions.

Code: [Select]

/proc/mtd:
dev:    size   erasesize  name
mtd0: 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_v10
machine : Unknown
processor : 0
cpu model : Ingenic Xburst V4.15  FPU V0.0
BogoMIPS : 1001.88
wait instruction : yes
microsecond timers : no
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
isa : mips32r1
ASEs implemented :
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available

Hardware : halley2
Serial : 00000000 00000000 00000000 00000000

/proc/meminfo:
MemTotal:          58140 kB
MemFree:           43032 kB
Buffers:             476 kB
Cached:             2944 kB
SwapCached:            0 kB
Active:             2940 kB
Inactive:           1500 kB
Active(anon):       1024 kB
Inactive(anon):        4 kB
Active(file):       1916 kB
Inactive(file):     1496 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 8 kB
Writeback:             0 kB
AnonPages:          1024 kB
Mapped:             1308 kB
Shmem:                 8 kB
Slab:               3444 kB
SReclaimable:       1060 kB
SUnreclaim:         2384 kB
KernelStack:         352 kB
PageTables:          156 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       29068 kB
Committed_AS:      35264 kB
VmallocTotal:    1048372 kB
VmallocUsed:        2096 kB
VmallocChunk:    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=Buildroot
VERSION=2014.05-00055-g03a0bb5
ID=buildroot
VERSION_ID=2014.05
PRETTY_NAME="Buildroot 2014.05"


[speachy]

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.

This comes as a suprise; none of the other hiby-based players I've seen require signed firmware images.

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?

This package generation mechanism already exists, but it relies on tooling that is Linux-specific (and also requires superuser permissions).  That said, once a suitably-patched package is generated, we can use that to generate binary patches that can be distributed from download.rockbox.org and automagically applied using rbutil.

[efqw]

Some updates that I forgot to mention in my last post:

1. 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 

2. ubinfo:

Code: [Select]

# ubinfo /dev/ubi0
ubi0
Volumes count:                           1
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     640 (81264640 bytes, 77.5 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  20
Current maximum erase counter value:     15
Minimum input/output unit size:          2048 bytes
Character device major/minor:            250:0
Present volumes:                         0
# ubinfo /dev/ubi1
ubi1
Volumes count:                           1
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     311 (39489536 bytes, 37.7 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  3
Current maximum erase counter value:     11
Minimum input/output unit size:          2048 bytes
Character device major/minor:            249:0
Present volumes:                         0

3. It's possible that FiiO simply used some stock test keys to sign the packages, but the keys in ingenic-linux-kernel3.10.14-x1000-v9.0-20191212.tar.bz2 don't match. Maybe they have different test keys in older releases?

[diegopau]

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

Hi, now that you explained this I am concerned too. Would you mind posting some details about how I could do this myself?

[efqw]

Code: [Select]

rm /data/userfs/app.log
ln -s /dev/null /data/userfs/app.log


[diegopau]

Sorry, I am a complete noob at this. I never started a serial console before so that's where I am stuck:

On the M3K:

1. I created a file named "serial_connection.sh" with the script:

Code: [Select]

#!/bin/ash
insmod /lib/modules/3.10.14/kernel/driver/staging/dwc2/dwc2.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/libcomposite.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/u_serial.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/usb_f_serial.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/usb_f_acm.ko
insmod /lib/modules/3.10.14/kernel/driver/usb/gadget/g_serial.ko
getty /dev/ttyGS0 115200
2. I placed the file in the root folder of the MicroSD.
3. Now with the M3K connected through USB and the MicroSD inside the M3K I turn it on and on the boot menu I go to TOOLS -> Run script. I select "serial_connection.sh" and I see a message "Running serial_connectio" that lasts around 5 seconds, then it's back to the boot menu.

On the computer I tried installing termite for windows https://www.compuphase.com/software_termite.htm and with the following settings: https://dl.dropboxusercontent.com/s/g2tr7ezcjxnjz7i/vivaldi_7Zpj9Vw9SW.png
I don't have more options than COM1.

It doesn't work and I don't know what else to try.

[efqw]

You'll be able to see a new serial port pop up on your computer after you launch the script, and the script is blocking, which means it won't quit unless you actually hang up in the serial terminal. I've never tried this in windows, maybe you could use a Linux vm?