Fiio M3k

[Thew]

I tried to follow the m3k native install instructions and managed to not only get my unit to a non-working state, but I can't boot over USB anymore. Any chance of help?

Have you tried over flashing with the original Fiio Firmware? i.e. having the Fiio Firmware on the SD Card and starting up with the “on” key plus “Volume+” key.

[amachronic]

dconrad, the good news is if the bootloader can display "No SD Card", the flash should be okay. If you can send me the original and patched NAND dumps then I can double check them for you.

Apologies that I didn't mention this on the wiki  , but if the machine hangs you need to hold the power button for AT LEAST 15-20 seconds to be sure you've forced a power off. It can still be powered on even if all the lights are off. If the device feels warm then let it cool down for 10-15 minutes before you try USB boot again. That might just fix the problem -- I ran into this a few times during development, but it was quite rare for me.

If "cooling down" doesn't help, you could try another SD card in case Rockbox doesn't like yours. Or assuming your original NAND dump is good, you can pull the SPL out of it and see if the original firmware boots:

Code: [Select]

dd if=boot.dump of=xloader.bin bs=1024 count=12
./usbboot -v -c x1000 -1 xloader.bin

(NB. if you're not using the XVortex build you will have to pull out the USB immediately when the backlight comes on or Fiio's player will just go straight to the charging screen.)

Let me know what happens after trying all of this. I'll be on IRC today, in case you're still having problems we can debug it further.

If you really want to, you can get into the recovery by holding "Volume Up" while booting xloader.bin, but there's a chance it'll make the problem worse. So I wouldn't advise it unless you're desperate.

[dconrad]

Thanks a bunch for the stuff to try!

I had already figured that the power button needs to be held for a long time in order to fully power it off - no change if I hold it for a full 20 seconds, so that's probably not it. As long as the keypad lights up when I plug in the USB cord while holding volume down, I figure that I got it completely powered down.

I've tried a card that works in my other rockbox device, and got the same results, so that's probably not it either.

The good news: booting the original firmware over USB kind of works! It shows the "Welcome!" screen, then the battery charging icon, then goes dead, with none of the buttons responding.

One thing I ran into early on, I discovered that the three builds you need to do (normal, bootloader, spl) need to be in their own build directories (I did rockbox/build, rockbox/build-bl, rockbox/build-xpl), is that how it's supposed to work?

I think I'm going to attempt to load the original firmware back onto it so I can have a fresh go at it, we'll see how that goes. - Putting M3K.fw on the card and booting with Vol+ held just leads to a blinking keypad. I'm not sure if it's boot cycling or actually doing something underneath. Probably the former.

I'll attach my original boot.dump and boot.install if you could peek at them. - here

[JimZipCode]

... the linux-based port will most likely be nuked from orbit.

It's the only way to be sure.   

[heyspencerb]

Hello, developer of the new M3K port here. Thought I'd chime in since somebody was enterprising enough to try the new native port already!

Hello! First of all, amazing work! The new port is so much faster to boot, run and create databases, and it actually properly shuts the unit off so the amazing battery life is back! As far as bugs, the only catastrophic ones I've found are some of the plugins causing a hard crash and segmentation fault, but I'll go through each and submit bug reports as I see which ones work and which don't. Though the worst offenders of seg faults are the games which is definitely not top priority, as fun as it would be to run DOOM on it.

Is the bare metal port working in the simulator yet? I'd love to try out some new ideas with key mapping and such, but currently I am just making a change and loading it on hardware as the test which is a pain.

[amachronic]

Is the bare metal port working in the simulator yet?

It should work now, a fix for the keys in the simulator was committed yesterday.

[dconrad]

Well, I got brave (or dumb, your call) and tried again since I had moved up to FiiO version 1.4.5 while recovering the first time, and got the same result of an unresponsive player. So I'm either not doing something correctly or something is different with my player/environment. At least recovery this time was pretty easy.

[amachronic]

I realized why you're not able to boot Rockbox over USB once you flash it... the SPL will see that the bootloader is flashed and try to load it, it'll never return to the hardware boot ROM and the USB command will time out. That's my bad, sorry for the confusion.

It seems unlikely you somehow compiled it wrong if you managed to load Rockbox, flash the bootloader, and see error messages from the bootloader. So it's probably a hardware initialization problem.

Could you try flashing the bootloader again, and boot Rockbox normally with this patch applied: https://gerrit.rockbox.org/r/c/rockbox/+/3290? If the bootloader is managing to load Rockbox at all, you should see the backlight light up. Let me know what happens.

[dconrad]

I tried that patch - it's not turning on the backlight at all. So this would indicate the bootloader can't even load Rockbox for some reason?

Edit: I did try both FAT16 and FAT32, no difference.

Edit 2: I could try it again tomorrow just to be sure.

[dconrad]

Ok, I'm trying again now that I can be fully focused (work went long yesterday...)

And just because I always believed it's important to show your work:

• Formatted card to FAT32 with macos diskutility:
  

Code: [Select]

sudo diskutil eraseDisk FAT32 M3K MBRFormat /dev/disk2

• downloaded patch, backlight_init() is directly after kernel_init()
• built rockbox, bootloader, and spl all in their own build directories
• extracted .rockbox from zip onto card root
• booted rockbox over usb with (as root):

Code: [Select]

# ./usbboot -v -c x1000 -1 ../../build-spl/spl.m3k --wait 1 -2 ../../build-m3k/rockbox.bin

• dumped bootloader and rebooted to OF
• build bootloader with

Code: [Select]

$ ./nand_patcher.py boot.dump ../../build-bl/bootloader.m3k ../../build-spl/spl.m3k boot.installThe result is SPL size 8632, Boot size 77704
   

• - put boot.install on the card and booted over usb again, installed bootloader.

Result is a single keypad flash, and the backlight never comes on. If I remove the SD card and try to boot, I do get "No SD card present", so the bootloader is definitely installed.

[amachronic]

Thank you for the detailed post, dconrad. You're doing everything right, so no issue there. I discovered a simple bug in the bootloader today, which might be causing the hang.

Can you try again when you have the opportunity? Do a build with just this bugfix applied to master (https://gerrit.rockbox.org/r/c/rockbox/+/3301). It might already be merged by the time you get around to it, and fingers crossed it will solve your problem.

In case you're still getting a hang, flash a build with the new version of https://gerrit.rockbox.org/r/c/rockbox/+/3290 and we'll go from there. Make sure you apply it on top of the bootloader bugfix.

[dconrad]

Thank you for the detailed post, dconrad. You're doing everything right, so no issue there. I discovered a simple bug in the bootloader today, which might be causing the hang.

Can you try again when you have the opportunity? Do a build with just this bugfix applied to master (https://gerrit.rockbox.org/r/c/rockbox/+/3301). It might already be merged by the time you get around to it, and fingers crossed it will solve your problem.

In case you're still getting a hang, flash a build with the new version of https://gerrit.rockbox.org/r/c/rockbox/+/3290 and we'll go from there. Make sure you apply it on top of the bootloader bugfix.

Thanks a bunch for keeping going with this issue! #3301 has already been merged into master at this point, so I just did git pull --rebase to get the latest changes. Unfortunately it didn't have any effect on the behavior, I still get a single flash of the keypad and that's it.

However! I cherry-picked #3290 on top of current master, which at the time of writing is at commit 1b82ebc6e, "Fix: Directory stream not closed in Shortcuts menu". The result is it gets to Loading firmware... and sits like that forever.

[amachronic]

Okay... that's a little unexpected, but I guess it confirms my original suspicion that the filesystem is somehow to blame.

I understand you're using Mac. I don't have access to a Mac, so I cannot test myself, but I suspect that it must format the filesystem differently and this triggers a bug in the M3K's SD driver. Can you try reformatting the SD card using Linux or Windows, and flash a clean build of Rockbox from master? If that makes it magically boot, then we've found the problem.

You also mentioned you've got another Rockbox device where the SD card works -- what model is it? native or hosted port?

I'll have a think about how to debug further and upload another version of g#3290 later today.

[dconrad]

Yeah I can do that. I'm using my linux box to build rockbox, but my laptop makes it easy to make the filesystem so I was just doing that. I'll have to go download gparted I think.

By the way, is FAT32 necessary, or is FAT16 ok? I had to do some runaround to get it to do FAT32.

Edit: my other rockbox device is an Eros Q (well, a Hifi Walker H2). Unfortunately it has an audio bug that makes it unusable for me at the moment, but it reads SD cards just fine.

[amachronic]

The weird thing here is, if you managed to get a flash dump, the SD driver must work in Rockbox, even with the Mac formatting... the bootloader uses the same code so not sure why it is having trouble loading the firmware. I updated g#3290 with extra logging anyway so we can figure out which part of the firmware load hangs, before delving into the SD driver guts.

It could be that the machine is powering up too fast and your card draws too much current. It seems somewhat unlikely, but I chose the power-up delay pretty close to the minimum that worked in order to keep the boot time down. I've extended it to 500ms in g#3290.

Your comment about fat32 runaround made me think: Are you using an old SDSC card, <= 2 GB? 2 GB is the max size for fat16, I think, which might explain why the formatter tries to force it on you.