Fiio M3k

[alexs]

Well it turned out to be quite easy, although I wouldn't call Rockbox usable at this point.

Tool attached. Put the modified M3K.fw together with rockbox-fiiom3k.zip on an SD card and update the player.
The modified M3K.fw can be reused as long as .rockbox/rockbox.m3k path in the zip remains the same.

Edit: "No Rockbox directory, installation incomplete". Well that would explain things.

Edit 2: DON'T USE this script it is wrong, see below.

[bahus]

Well it turned out to be quite easy, although I wouldn't call Rockbox usable at this point.

Are you saying it's less usable than builds provided by XVortex? https://mega.nz/folder/0wckiIIZ#o_-7wp3aT_ob-EoxsteNqw/folder/EpVAQQ7K (M3K_v1.3.0_eef591e-190901.zip is less buggy than latest)

Can you share modified M3K.fw (using google drive or some free file sharing services like https://gofile.io/ or https://mega.nz)

[alexs]

Nah, I got it playing and it looks much better now.

This build wants the .rockbox directory to be on the SD card. Not in the internal rootfs where I tried to put it initially.

[alexs]

Ok so if the idea was to keep Rockbox completely on the SD, I can see how that could work, but I'll need some time to think how to set it up in way that would make any sense. SD cards are removable and hot-pluggable on this device.

[bahus]

I'll need some time to think how to set it up in way that would make any sense. SD cards are removable and hot-pluggable on this device.

That's also true for all recent Chinese targets (all xDuoo and Aigo ports, Agptek Rocker, ...) where internal memory is not exposed. All of them load rockbox from external SD - that makes rockbox update pretty easy... So I see nothing to worry about it...

[speachy]

Ok so if the idea was to keep Rockbox completely on the SD, I can see how that could work, but I'll need some time to think how to set it up in way that would make any sense. SD cards are removable and hot-pluggable on this device.

General approach:

1) updated rockbox launcher copied to onboard flash, and startup script modified to launch it.
2) mdev rules updated to auto mount/unmount filesystems upon hotplug.
3) fix bugs as they come up.


As an example of what we care about with (1) and (2), see https://git.rockbox.org/cgit/rockbox.git/tree/tools/hiby_patcher.pl starting around line 137.

EDIT:   The stuff targeting the m3k specifically starts on line 229.  It is _very_ incomplete.

[alexs]

alexs, I thought it should have a trick action to get fastboot mode and then use "Clone tool".

It might be implemented in the recovery tool. I poked around a lot with Ghidra there, but it's a pretty large piece of code and I wasn't looking for input related things. It does seem to have some input handling code even though it doesn't appear interactive at all. You might be on to something here. Or it might be just some stray code from their GUI library. Either way, it will likely take some time to find out.

I can tell for sure that the 2nd stage bootloader (x-loader) does not support fastboot, and cannot re-activate the bootrom USB mode. The only choice it makes is between the main kernel and the recovery kernel. The USB mode I was talking about is not fastboot either, it's Ingenic specific and it's much simpler than fastboot. I assumed Ingenic tools would use it over fastboot, but now that I think of it, the recovery tool was probably developed by Ingenic as well, so who knows.

[alexs]

Updated scripts. Should properly run rockbox from SD by copying the loader to internal storage.

Booting without SD card in the slot = USB console.
Booting with SD but no .rockbox there = FiiO player.
Booting with SD and .rockbox is there = RockBox.

Modified M3K.fw: https://gofile.io/d/giokMw

Do not forget to unpack rockbox-fiiom3k.zip onto the SD, there are no Rockbox parts in that M3K.fw.

[bahus]

Should properly run rockbox from SD by copying to loader to internal storage.

Cool! Thanks! I gave a quick look... Noticed issues: Shutdown doesn't work properly - button backlight is on after shutdown (need to keep power button pressed longer - backlight will be off too) ; USB storage mode doesn't work - only charges on USB insertion...

[whiskerc]

>Updated scripts. Should properly run rockbox from SD by copying to loader to internal storage.

Yes, clear instructions.  The M3K starts up right to Rockbox when the SD card is loaded.  Will wait to do more testing but wanted to pass on the news that it does work on another M3K.

[vitt13]

It might be implemented in the recovery tool.

I've just found the IRC https://www.rockbox.org/irc/log-20200706 messages from efqw_

With Ingenic's USB Cloner tool, the entire flash can be overwritten without disassembling the device. I have already tried erasing the entire NAND and flashing back my own NAND dumps and it worked perfectly fine.

From what I can see, it loads a ~6kB u-boot SPL into the memory which does memory initialization, and then loads a pre-built u-boot binary, and this is what interacts with the cloner device from now on.

So we can replace the bootloader with u-boot or even re-partition the NAND in theory, but I'm not sure if that's worth the effort to be honest.

Unfortunately there is no detail how he got own NAND dumps.

But I still have not complete understanding how efqw_ did that. I read the X1000/E DS and flow chart shows that USB boot takes part after fail with SFC boot and MSC1 (not presented in FiiO M3K obviously) boot. It seems like SFC boot fails with presented USB connections, or he found magical button pressing set, other than

Darn it. I was trying to find the boot select pins on the FiiO M3K, and looks like I won't be able to find it unless I pull the SoC off.

boot_sel[0] (PB28) is tied to Volume Down, which is nice I guess

What I wanted was PB29, which is not defined in the source unfortunately. I could make it boot from mmc if I pull down PB29.

[alexs]

From what I can see, it loads a ~6kB u-boot SPL into the memory which does memory initialization

Oh ok so this what I was messing with. It can only be done if the device is in the USB boot mode. Then it would allow you to upload the SPL.

boot_sel[0] (PB28) is tied to Volume Down, which is nice I guess

OMFG I'm an idiot. Bingo! That's all you need to flash the device. No need for my unzip hack. No need for Ghidra.
It might take some work to get u-boot working and/or write something custom but it's a clear and straighforward task now.

Power the device down, then plug it into a USB host while holding vol-down button.
It will light up the buttons and enumerate as Ingenic x1000. That's the USB boot mode.

Code: [Select]

[3114458.858415] usb 1-3: new high-speed USB device number 86 using xhci_hcd
[3114459.000769] usb 1-3: New USB device found, idVendor=a108, idProduct=1000, bcdDevice= 1.00
[3114459.000775] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[3114459.000778] usb 1-3: Product: X\x10
[3114459.000781] usb 1-3: Manufacturer: Ingenic
Just for reference, I got to this mode by wiping the header of the NAND bootloader from Linux.
If the header is invalid, SFC boot always fails, so it proceeds to the next option which is USB.

Edit: and I was trying hold-button-power-up with each button! But apparently messed up somewhere.

[alexs]

What I wanted was PB29, which is not defined in the source unfortunately. I could make it boot from mmc if I pull down PB29.

Really no need for this by the way. An SPL/TPL capable of loading the next stage from SD card would be enough.

Ingenic x-loader seems to support MMC boot by the way. So it might be really easy.
u-boot is another option, although I don't think this device needs u-boot.

[vitt13]

That's all you need to flash the device. No need for my unzip hack. No need for Ghidra.
It might take some work to get u-boot working and/or write something custom but it's a clear and straighforward task now.

It's clear for me now, thanks.

So, generally, running M3K port has to be close to AGPTEK Rocker port (X1000 based), right?

Let me elaborate a bit to clarify situation (please refer to https://www.rockbox.org/wiki/AgptekRocker for additional info). Agptek first loads tiny bit of binary code (SPL) into cold cache which main role is to configure PLL (aka clocks) and RAM controller. Then it loads bootloader (uboot) into ram and passes control to it. Uboot loads linux kernel either from mtd2 or mtd3 (normal kernel or recovery kernel) and passes control to linux. If it is normal boot, kernel mounts UBIFS rootfs from mtd4, if it is recovery boot, kernel loads rootfs from concatenated to itself image. Kernel (both normal and recovery) calls init process (the parent of all processes). Init runs startup scripts to run various services and finally runs hiby player binary which presents GUI for the user.

Now after this lengthy introduction - we patch normal rootfs to call rockbox bootloader binary instead of hiby player binary. So from the technical point of view we DO NOT patch bootloader (uboot) and we do not touch recovery image. This makes all process pretty safe.

And another difference is how OF file is packed.

efqw_   This device is very similar to the AGPTEK ROCKER in terms of hardware spec (no radio, X1000E instead of X1000, different I2S DAC, same PMU, I2C touch controls instead of a D-PAD).
efqw_   Additionally, this device is using X-Loader instead of U-Boot, and system updates are performed with a recovery partition instead.
efqw_   Firmware packages are split into ~1MB chunks and signed individually with apksign, and then zipped together along with a manifest file.
efqw_   This setup is drastically different from the hiby stuff, where the .upt file is an ISO9660 volume and the blobs are not signed.

So, XVortex has the signature cert. from FiiO Tech.Support but we have not. alexs, your unzip hack is genius and quite useful to have access on system console.

I hope my a bit off-topic messages about possible repairing/recovering are not such distracting from main target.

[bahus]

Hm... And only now I've noticed that XVortex also provided a way to update rockbox right from boot menu. Go to Tools -> Update rockbox (and script copies .rockbox folder from SD card to internal player storage).

Compared to XVortex latest build has following flaws (no matter how it's been installed via alexs firmware or via Tools):
1) XVortex standard theme is better adjusted (bigger fonts, playing track info in lists etc)
2) Strange shutdown behavior. In latest build you need to press shutdown button way longer. It looks like it's now two stage shutdown (first screen then backlight)
3) It looks like there is power drain when player is shut down by Idle power off or Sleep timer. Noticed few times that after full charge it's been almost dead next day when it's been shut down by idle power off after only few minutes of real use.