Sansa Fuze (and perhaps others) - How to avoid wearing out internal flash?

[meyertime]

I understand that these devices are prone to have their internal flash stop functioning, at which point, it won't take any more writes.  This happened to my Sansa Clip+.  This makes sense due to the way flash memory works, the fact that these devices are so old now, and considering that flash memory technology was not as advanced back then.

I have a Sansa Fuze that I want to make sure this doesn't happen to, so I want to avoid any and all writes to the internal flash once it is set up how I want it.

Firstly, I know that it's possible to boot Rockbox from the microSD card once there's a new enough version of the Rockbox bootloader installed on the internal flash.  I also know how to set the recording directory so that recordings go directly to the microSD card.  So my remaining question is this:

Is there anything else that Rockbox will write to internal flash memory if it is booted from the microSD card?

[7o9]

If you use the multi boot bootloader and redirect to run Rockbox from the sd card, there is nothing writing to the flash anymore.

I would install the multi boot bootloader as soon as possible while the flash is still writeable.

[meyertime]

That's good news. However, I did discover one case where it still writes to the internal flash: FM preset. At least by default, and I haven't tried overriding the path to go to the SD card. Are you maybe talking about the daily dev build? I'm using the 3.15 official release.

What about settings in general? Where do they get saved when booting from the SD card?

[meyertime]

For the record, Rockbox still writes its config and other stuff to the internal flash, at least in the latest stable release v3.15.  I have modified my fork of Rockbox to redirect everything to the microSD card.

https://github.com/meyertime/rockbox

[Bilgus]

If you run a multiboot capable player it does all its config writes to whatever drive its actually booting the firmware from (you can change it in some cases though)

now if you run a build (on the SD card) from the file browser while booted to internal it would still write to the internal drive or conversely
say you booted from the sd card then browsed for a firmware on the internal drive and ran it it will likely write its data to the sd card /rockbox

[meyertime]

I'm running on a Sansa Fuze v2 booting from the microSD card automatically by having a `rockbox_main.fuze2` file on the microSD card.  (I didn't even know you could load firmware through the file browser, so I'm definitely not doing anything wonky like that.)  I am running v3.15, however, not the daily dev build.  Looking at the `config.cfg` file on the internal flash and the microSD card, only the one on the internal flash changes and contains the actual settings used.  Further, if I run a "rock" such as the credits viewer, it reads it from internal flash; changes to it on the microSD card have no effect.

I can further prove this by looking at the code.  The path to the config file is defined by the `CONFIGFILE` preprocessor definition, so its value is determined at compile time and cannot vary at runtime; it always has the value `/.rockbox/config.cfg`.  This value is passed without modification into `settings_load_config`, then `open_utf8`, then `open`, then `open_internal_locked`, then `open_internal_inner1`, then `open_internal_inner2`, then `path_strip_volume`, where it is used to determine the volume to open the path from.  That function returns volume `0` (internal flash) unless there is a volume specification in the path, such as `/<microSD1>`, which there isn't.  Therefore, there is no way in the code for v3.15 for the config file to be loaded from anywhere but `/.rockbox/config.cfg` in the internal storage.  Not unless a special build of the code was made specifying a different Rockbox path, which is essentially what I did in my fork.

[speachy]

To quote the instructions in https://www.rockbox.org/wiki/MultibootBootloader :

"Multiboot features generally require support from both the Rockbox firmware and the bootloader, and both of them need to be new enough to support a feature for it to work."

v3.15 is about 3.5 years old at this point.  Before complaining that something doesn't work and arguing about the state of the source code from back then, it seems logical to try with something more recent?

Meanwhile, while you are correct in that CONFIGFILE is hardcoded, but what you're missing is that the filesystem root is not.

[bluebrother]

I'm running on a Sansa Fuze v2 booting from the microSD card automatically by having a `rockbox_main.fuze2` file on the microSD card.  (I didn't even know you could load firmware through the file browser, so I'm definitely not doing anything wonky like that.)  I am running v3.15, however, not the daily dev build.  Looking at the `config.cfg` file on the internal flash and the microSD card, only the one on the internal flash changes and contains the actual settings used.  Further, if I run a "rock" such as the credits viewer, it reads it from internal flash; changes to it on the microSD card have no effect.

Looking at your fork you change the path to "/<MicroSD1>", but according to the manual you need to put the path on the SD card into the rockbox_main.fuze2:

If instead you wanted to run the Rockbox from SD card /mybuild/.rockbox then your /rockbox_main.fuze2 file should contain: “/mybuild/”

So without knowing the details on what exactly you have in that rockbox_main.fuze2 file I'm suspecting that you put in the wrong path, then assuming it didn't work. This works fine on my clip+. Also, Rockbox completely swaps the drives, to now the internal memory becomes <MicroSD1>. Unless your SD card has the exact same size as the internal memory that makes it easy to tell where you're running from.

https://download.rockbox.org/daily/manual/rockbox-sansafuzev2/rockbox-buildch13.html#x16-41800013.4.2

[meyertime]

v3.15 is about 3.5 years old at this point.  Before complaining that something doesn't work and arguing about the state of the source code from back then, it seems logical to try with something more recent?

Indeed.  First of all, it was not my intent to complain.  Rather, I wanted to stop the spread of misinformation in case anyone else comes upon this thread in the future.  I did try the latest dev build at first, but at the time, the FM radio was completely broken on the Fuze.  That did not inspire confidence.  Plus, if the developers aren't even confident enough in the code to release it as "stable", then why should I be?  I need to be able to rely on these devices for recording, so I decided to use the "stable" version.  I think it's reasonable to conclude that many users would make the same choice, and might mistakenly assume that we're all talking about the latest stable version here.

So I might just as well wonder, why hasn't there been a stable release in 3.5 years?  Again, not complaining.  If you don't want to do a release, or do any work on it for that matter, that's your prerogative.  This is a free, community-driven project, and I'm super happy with it and thankful to all the devs.  I write software for a living, so I probably understand the situation better than most.  Typically, there are two reasons that I've seen why there might be a lack of official releases: 1) no significant work has been done since the last release, or 2) the developers are in the midst of a major overhaul of the code, and therefore it really isn't stable enough to release yet.  I know that the first reason is not true in the case of Rockbox.  As for the second, actions speak louder than words.  I've heard that the latest dev build is good for regular use, but that claim has not been backed up with an official release yet.

Looking at your fork you change the path to "/<MicroSD1>", but according to the manual you need to put the path on the SD card into the rockbox_main.fuze2:

If instead you wanted to run the Rockbox from SD card /mybuild/.rockbox then your /rockbox_main.fuze2 file should contain: “/mybuild/”

So without knowing the details on what exactly you have in that rockbox_main.fuze2 file I'm suspecting that you put in the wrong path, then assuming it didn't work. This works fine on my clip+. Also, Rockbox completely swaps the drives, to now the internal memory becomes <MicroSD1>. Unless your SD card has the exact same size as the internal memory that makes it easy to tell where you're running from.

My `rockbox_main.fuze2` file is empty, which causes the bootloader to load from `/.rockbox` on the microSD card.  However, when the firmware loaded from the microSD card is v3.15, it still uses internal storage for config and other things.  That's why my fork, which is based on the v3.15 code, changes the Rockbox path to `/<microSD1>/.rockbox`.  This works for my purposes.

But yes, looking at the latest dev code and trying it out, I see that it does redirect the root to a different volume when booting from the microSD card.  So ideally, I could base my version on that and not have to do my hacky workaround of specifying a different Rockbox directory.  However, I think people should know that in the latest stable release, v3.15, they are not getting everything redirected to the microSD card out-of-the-box as they might expect.

[Bilgus]

OK?