SANSA ClipZip Clip+ Fuze+ FuzeV2 Multiboot Bootloader and Firmware

[1918mute]

Hi, Bilgus,

I have rockbox previously installed on my Sansa Clip+ internal storage, I am not sure whether I need to uninstall the Rockbox firmware/bootloader from internal storage first.

I followed these instructions to install and it looks like it still boot rockbox from internal storage:

Next download MultiBoot_FW_ClipPLUS [latest date]_rockbox-full.zip and unzip to the root of your SD card
Finally create an empty file called Rockbox_main.clip+ in the root of the SD card
now put sd card in device and reboot; Under Debug menu you should have a new entry 'Bootdata' that lists the current boot drive
if not check that the Rockbox_main.clip+ file is actually empty or single slash '/'.

 

I could find the entry

Code: [Select]

Debug(Keep out) - Boot data
it shows contents like

Code: [Select]

Magic: rbmagic! There is a line says

Code: [Select]

CRC: BAD Does this mean sdcard boot failed?



Thanks very much!

[Bilgus]

Yes that means sd boot failed, you should be able to update the boot loader with rbutility

[SamoDadela]

@Bilgus: I noticed that RB 3.15 was released - release notes say "Booting from multiple volumes is now possible.". Does that mean that I can install RB on the external SD card without doing all the steps above? I can't find more info on booting from multiple volumes, Does RockBox Utility support installation to multiple volumes?

After 8 months of running RB on the external SD card it started having write problems - like before on the internal memory. From the time RB was installed I never wrote anything to the SD card. The only thing that changes is that RB updates the recently played bookmarks. Is it possible that RB is always writing to the same sector and thus wearing out that specific sector by updating the bookmarks? Does it have any anti-wear-out logic? Like always writing to a new sector and discarding the old one? If there is no such logic I'm a bit weary of letting RB update the recent bookmarks (though that's one of the best features) since it will result in wearing out of the SD card.

[SamoDadela]

Found the answer (sort of) here: http://forums.rockbox.org/index.php?topic=53154.0

Before I read the link I installed 3.15 stable - first keeping the old multiboot loader (clppa_new.bin). Installation went fine, the files were there but I could not play anything. Also Debug->Bootloader was showing some weird magic.

I then reflashed clppa_new.bin (your old one)... It was probably not needed, anyway... put the latest development build on the SD card (like indicated in the link above). This time it worked - I can play files again. Don't know what's the issue with 3.15 stable, though.

[Bilgus]

3.15 Release does not have the logic to remap the drive the DEV versions do though

Sorry I missed your previous question, short answer SD cards do wear out
Does RB do writes to the SD card when running from it YES
Will this wear it out eventually? MAYBE
Can you tell me how long that will take? NO CLUE

Here is the thing though the SD card is replaceable [ unlike the player ]
It probably has more to do with the quality of the SD card than Rockbox
Anecdotally I have been running the same SD card for ~2 years with usage 5 days a week 6 hrs a day will no ill effects and it writes several bookmarks daily
updated the music probably 5 times
Still I Can't tell you how your SD card will fare

You might be able to get those bad sectors marked and removed but I've only had marginal luck with that on USB Flash drives

[SamoDadela]

@Bilgus
Thanks for the answers.

[username_already_taken]

Firmware file is checked for boot data region.
If bootdata region is missing, firmware
image will not be loaded.

Multiboot isn't working for me on Clip+ and I suspect this is the reason.

I installed the 2020 bootloader and am using a dev firmware build but the player doesn't work unless the internal flash directory is named .rockbox, which I take to mean that the firmware in the SD card is never being used (rockbox_main.clip+ with a single / is present in root of SD card).

How can I fix this?

[Bilgus]

I don't think 2020 bootloader was released yet did you build it yourself?

check boot data in both cases CRC should be OK

but further down if internal boot then it should read 00 00 00 00 00
on sd card it should read 00 01 00 00 00 (and Boot Volume <1> on supported fw)

The final thing is to re-make the redirect file rockbox_main.clip+ either completely empty or a single /

[johnb]

username_already_taken,

try the attached redirect file. Remove the '.txt' extension and put it into the SD root directory.

[Bilgus]

I'm able to reproduce the issue it appears the bootloader is broken in the last weeks but i'll have to investigate a bit more

No I just happened to fall into the trap of using a file editor and it left a \n at the end

here are the freshly tested files I made from HEAD these worked for me

Edit -2022-
DOWNLOAD A RECENT DEV VERSION FOR YOUR DEVICE
https://www.rockbox.org/daily.shtml
http://www.mediafire.com/folder/0xagre8mhvwmb/Clip%2B2020Multiboot

[username_already_taken]

I don't think 2020 bootloader was released yet did you build it yourself?

The final thing is to re-make the redirect file rockbox_main.clip+ either completely empty or a single \

I should have mentioned my screen is dead, I need to use voice navigation.

I test that I'm not using the SD card by comparing mtimes on files in the internal and SD firmwares (the latter never updates), and by renaming the internal folder (the player stops working).

I also mispoke, I'm not using the 2020 bootloader because the latest one is from 2019, this is what I'm using:
https://download.rockbox.org/bootloader/sandisk-sansa/clipplus/
https://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot/linux-x86-64/
OF 01.02.16
Rockbox dev build with working voice file
Doing a manual installation because my Rockbox utility is outdated and the new binary doesn't run on Debian buster.

I tried both the 0 bytes and 1 byte forward slash variants, not backslash though, I assume that was a typo since everywhere else says /?

I will try the new files and report back soon, thanks for helping!

EDIT: quick update: the rockbox_main.clip+ file uploaded in that link is 2 byte with newline, I will fix it before properly testing

[Bilgus]

yes sorry it is a single forward slash, the \n won't matter if there is already a / in the file it just matters for empty ones IIRC

Go ahead and install that new bootloader just copy to the internal drive and reboot into the sansa firmware, it shuts off the device when finished so rather than risk turning it off too early just plug / unplug the USB after 15 mins and see if it boots and connects to USB
 (since your screen is out)

[username_already_taken]

Still no luck with the downloaded clppa.bin and firmware, exact same behaviour.
Works perfectly from internal flash .rockbox/, not at all when internal flash directory is renamed. The .rockbox/ on the SD card is a straight copy of the one in internal flash, and a 1 byte / rockbox_main.clip+ is present on the SD root.

Not sure if it matters any but after doing manual bootloader installation, the clppa.bin file is left on the root of internal flash after installing.
Don't know if that's supposed to happen, or if it means the bootloader wasn't installed properly and despite all these attempts I'm still running the old bootloader.

Is there an easy way to debug this with voice operation? If not, I'll give up and keep on using the internal flash, no big deal.

[username_already_taken]

Go ahead and install that new bootloader just copy to the internal drive and reboot into the sansa firmware, it shuts off the device when finished so rather than risk turning it off too early just plug / unplug the USB after 15 mins and see if it boots and connects to USB
 (since your screen is out)

I've just been copying, ejecting and powering off with gnome-disks, unplugging and waiting a minute.

Do you mean I need to boot holding left to call the OF, then wait?

EDIT: that was definitely it, rebooting into OF, waiting, then plugging in the USB cable and mounting shows a bunch of OF directories on the flash root and no more clppa.bin. And now it works, SD firmware is being used as expected!

Thanks again for the help and for your contributions to Rockbox in general.

[Bilgus]

If clppa.bin is still there then it did not update

word of warning you must rename to clppa.bin before copying it to the internal drive
if you do the rename after it will not pick it up

to update it should just be copy the file power off then hold left arrow and power on

edit:
Good to hear glad you got it working

and Thanks