Fiio M3k

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

[dconrad]

It is indeed just an old 2 gig card, I pulled it out of the small handful I have. Is the bootloader explicitly expecting Fat32?

My plan right now is to try updated g#3290 and see what happens, then reformat the card with gparted if it still doesn't work. I did git reset --hard origin/master, git pull --rebase, and then cherrypicked g#3290 on top of the most recent master (c77cd7027f35, lua print_table add ability to draw a line separator)

So with the updated debugging bootloader and the card formatted as FAT32 from macos, I'm getting:

Code: [Select]

Booting...
Loading firmware...
Open: /.rockbox/rockbox.m3k
file size = 685012
try to read checksum
Read: 685004 @ 800811C4
Verify checksum
Success

But it doesn't actually boot, it just sits there. I'll try formatting it with linux and reinstall the same debugging bootloader and build of rockbox. --> exact same result, down to the counts and address.

I'll try the big card out of my main mp3 player, a modern(ish) 64 gig Sandisk, that I actually bought at a store (wow!), haha usually I just kind of end up with these cards somehow. I'mnNot going to reinstall the bootloader, I'll just plop .rockbox on there and see what happens. --> exact same result again.

What on earth could this be? It's probably some dumb thing, but...

Looks like it's hanging when trying to close the file??

[amachronic]

That's strange. I'm turning in for the night but this has got me stumped. I've been unable to reproduce despite testing all these g#3290 revisions locally, they boot fine for me. The SD card is probably a red herring.

Could you upload all the *.elf *.m3k and *.map files from your rockbox, bootloader, and SPL builds (be careful since the SPL elf and map files are also called 'bootloader' due to a deficiency in the build system, you need to rename them first). Let me know the commit they're built from, and I'll flash the same binaries tomorrow on my M3K and see what happens. Many thanks for your patience with all the testing!

Btw the bootloader should not care about FAT32 vs FAT16, it uses standard Rockbox filesystem code which is supposed to handle both.