Fiio M3k

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

[dconrad]

Try here

I kind of wonder if I have the wrong compiler version somehow, or if it's due to the fact that I also have the cross-compiler built for the Hifiwalker H2, which I understand is different because it's a hosted target. I've built loads of working rockbox builds for that, but never a bootloader.

Man, I've been using my neocities account more for transferring files than actually making a website lately...

[dconrad]

... maybe a silly question, but should I be running "make" or "make -j"? I got started playing with the eros q which apparently is supposed to be built with "make -j", so that's what I've been doing...

[speachy]

'-j' refers to the number of parallel jobs Make should try to execute at the same time.  '-j2' means two jobs in parallel, '-j4' is 4, etc.  '-j1' is the same as not specifying the argument at all.  Now '-j' with no number is a special case, it actually means 'no limit', and is rarely a good idea.

Usually it's recommended that you'd use a number of jobs no greater than the number of threads your system can run simultaneously.  Under linux, this is reported by running 'nproc'. 

[amachronic]

dconrad, I flashed your build and it booted just fine... must be hardware issues. I'll do another version of g#3290.

[dconrad]

Now '-j' with no number is a special case, it actually means 'no limit', and is rarely a good idea.

So does that mean that this page is incorrect then? It specifically says to use "make -j" unless on a really old machine - which I suppose mine could be, depending on your definition of old.

[whiskerc]

Just wanted to weigh in and say that today I was able to successfully follow the instructions on the wiki page, compile and install.  The M3K boots directly to Rockbox.   Very exciting to see how much work has been done.

I haven't done any testing yet, but will be monitoring this thread and am available to check things as needed.

[whiskerc]

Thew, would you be willing to share your theme? 

[amachronic]

dconrad, I pushed another update to g#3290. This one is more complicated and I included instructions in the commit message. If anything's unclear then please ask. If you have the time and inclination this weekend, we could get on IRC and maybe figure this out faster.

[dconrad]

dconrad, I pushed another update to g#3290. This one is more complicated and I included instructions in the commit message. If anything's unclear then please ask. If you have the time and inclination this weekend, we could get on IRC and maybe figure this out faster.

Sure thing. I can get on IRC whatever time works for you this weekend, I'm in US Central time. Probably tomorrow mid/late morning?

I think I get the gist of your instructions, I might just take video of it so I can go scroll through it again.

I'll try the patch right now, on top of commit 13dbcab6c, "erosq: When mucking with the clickwheel, ensure we keep the screen awake!"

Looks like it's the simplest (well, simplest for me to report) option, t simply stops counting. We end up with:

Code: [Select]

Passed close()
load_firmware: ret=683948
load_firmware: exit
Jumping...

ipr0:00000000 ipr1:00000000
irq epc:8000FF28
t = 15130638

What's interesting is that it now can actually get to the "Jumping" printout, whereas before it couldn't?

ELFs: here
Just for fun: youtube vid: here

[amachronic]

Looks like you're running into a bug due to some hardware/SD card/filesystem differences and it happens to overwrite memory/stack that is critical to the boot. Trashing memory etc can happen in the background but not cause an obvious problem if whatever gets trashed is not used, until code changes cause the memory layout to change and suddenly something important is overwritten.

I'll be on IRC in the next hour or so, we'll have to try a bunch of builds until we can find out what is being corrupted.

[amachronic]

dconrad, I've updated g#3290 again; compile SPL, bootloader, and Rockbox from that and unzip Rockbox to the SD card. Boot by running bootloader.bin over USB. If we're lucky you should see the logo and get a blinking keypad.

Unfortunately I feel we haven't solved much, despite making some progress in narrowing down a point of failure. We still don't know why the bootloader was hanging on 'Load firmware...' before and we didn't find any memory corruption. The HW being picky about getting re-initialized twice without proper shutdown in between might be a thing, but it wouldn't really explain the prior behavior of the bootloader.

One thing you can try, is to cherry pick patchset 21 of g#3290, and dump 2 other functions in the same way you checked system_init earlier today. I forgot that clk_set_ccr_mux and clk_set_ccr_div are not inlined into system_init so there is still a possibility that one of those two functions got corrupted. (Since patchset 16 didn't flash lights and patchset 17 did, we know that those two are the only functions that need checking.)

You can get the disassembly listing using mipsel-elf-objdump -D rockbox.elf. (That is, the objdump from the toolchain you use to compile for the M3K). Search for <clk_set_ccr_mux>: and <clk_set_ccr_div>: to find the listings of those functions, and then edit bootloader/fiiom3k.c, changing the address in the code below to the address of the function you're going to dump:

Code: [Select]

    /* On line 111... */
    uint32_t* addr = (uint32_t*)(loadbuffer + (0x8007f3d0/*<< change this */ - 0x80004000));
    while(1) {
        lcd_fillrect(0, LCD_HEIGHT - 48, LCD_WIDTH, 12);
    ....

In patchset 21, the address on screen will match the assembly listing, so it's a bit easier to work with. If you are motivated enough to try this, let me know if you spot any corruption.

Now I'm sorry to say this, but -- things are getting out of hand with the level of debugging we're getting to, and I have to give up on you for now. I'm going to focus on polishing up the bootloader installation, get dual boot working, and improve debuggability of the early boot. Those 3 things should have a positive impact on any potential HW problems. There are some other random bugs I am aware of, which if I track down and fix might "accidentally" end up fixing the root cause of the problem you're suffering. At a minimum, it will be easier to localize problems, without going through the trouble of these hacky patches. (As you've seen, it literally takes dozens of edit-compile-test cycles doing it the hacky way...)

A bit longer term, when the Rockbox USB driver is working for this device, I should be able to implement a GDB stub on the machine -- then we can use GDB to make debugging way faster & easier. But let's hope it won't be necessary.

So good luck with this round of testing, and thanks for your excellent cooperation! I'll post again when there's something worthwhile to test with.

[dconrad]

Thanks amachronic, I'll give all that a shot and see what I can find out. I didn't get a chance to try actually using the device yesterday to see if it would do something weird, we had some washing machine issues I had to deal with all afternoon. I'll get to that soon though! I totally understand moving on to actual improvements - at least we know where the issue might be now, if not what it is.

[KatsuoHana]

Any further progress on a native port? I've seem to ran into the same problem as dconrad, havcing my player only light up touch buttons once after flashing the freshly-built rockbox.
Surprisingly, after replacing rockbox on SD card with one build with patchset 3290, it boots and flashes light just fine, even without doing anything to bootloader and/or SPL. If I revert all changes to apps/main.c from that patchset, it manages to boot into the system that is somewhat usable (touchpad is a bit unresponsive and even MP3 playback stutters). With that, I think I should be able to revert to stock bootloader and flash the Linux-based version, but it interprets touchpad button and play button as the same one, which makes it either unusable in jeans pocket, or uncontrollable without unlocking keys every time you want to pause the track.