Third Party > Unsupported Builds

SANSA ClipZip Clip+ Fuze+ FuzeV2 Multiboot Bootloader and Firmware

<< < (7/8) > >>

bahus:
> you can also redirect the firmware to a different directory on the sdcard with Redirect file

It doesn't seem to work for me on my Sansa Clip Zip. I'm trying to load firmware (latest daily build) from /rbclipzip/.rockbox folder on my SD card.
On loading it gives me splashes "No .rockbox directory" then "Installation is incomplete" and then loads in failsafe mode.
Boot 9de8993af6

Boot data:
Bootdata RAW:
Boot Volume: <1
CRC: 1b6947cc
CRC: OK!
00: 01 00 00 00 00

If .rockbox is placed in root of SD Card everything works smoothly

Bilgus:
Unfortunately I broke the patch that was supposed to do that functionality so it only works from the root of the card till I get back to it

odel:
I had problems getting my clip zip to boot from SD until I formatted it as Fat32.

Now it works great!

bahus:
> you can also redirect the firmware to a different directory on the sdcard with Redirect file

Bilgus
Just noticed that this feature is fixed with https://github.com/Rockbox/rockbox/commit/c9857098ac0a3173d5d03baa3c32d9a8e29faec8
Cool!

My tests result:
1) It doesn't work with `/rbclipzip` in redirect file. But does work with shorter folder name `/rbcz`. Is it expected restriction on folder length?
2) With .rockbox placed in the root directory of SD card, I see content of SD card right inside Files menu (folders and files). But now additional entry is appeared mircorSD0 (for internal) and microSD1(for SD card). Not sure if this change is related to your changes but it was only single microSD0 (for internal) before. microSD1 entry is redundant here.

And with `/rbcz/.rockbox` I see only 2 entries microSD0 (for internal) and mircorSD1 (for actual SD) in Files menu. Would be cool to see content of SD card right inside Files menu (basically behave in the same way when it's placed in root of SD)

Bilgus:
I'll have to look into the name length, shouldn't be an issue.. IIRC its MAX_PATH @ 260 chrs and testing it I see it boots the file just fine but it appears to lose the last 2 chars once booted so yeah def a bug

Yes SD<0> and SD<1> are related to this patch, I'll have to see about the best way to hide them, not sure that enumerating everything in the root is the best idea as it could get pretty confusing but i'll try it

thanks for the report

Edit:
Oh nevermind I see the issue the buffer is too small in the redirect

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version