Sansa Fuze+

[pamaury]

Hello,
I finally have a fuze+ \o/ I've tried various things but I can't find a recovery mode for know.
I'm still disassembling the firmware because I need to understand how the booting process works as this is not exactly clear.

I could try to replace what I believe is the user part of the firmware and keep what I believe to be the usb/msc one but I don't want to take any useless risks for now.

[yelped]

Thanks for all the hard work you're putting in to the port.

[metaphys]

Following what I've said about this funny behaviour of the fuze+ recovering automatically, I've tried to open it again. There is no possibility to disconnect the battery from it (unless cutting). So I supposed I must have accidentaly putted in contact some part of it leading to this automatic recovery. It might be something like that :
http://www.rockbox.org/wiki/SansaAMSUnbrick

It would be good to have someone that could lead us in how those were found  assuming there is any method for it 
Of course it would not be an ideal solution but it will at least assure us that we can go pretty bad keeping the possibility to recover

thanks for your work anyway...
Post Merge: March 09, 2011, 09:20:31 AMSo I've manage to reproduce the auto update behavior but only once and every other try failed... There is definitively a way to do so but no idea how! Anyway I never managed to access the flash memory directly through USB.
Furthermore after the end of this upgrade process the firmware version is the last installed one, any setting are reseted to default ones. So I suppose some save is systematically made on every upgrade. not sure about how to go further...

[haim]

I want to buy the FUZE+, what do you say? How long will it take to get an unstable version of Rockbox for this player? (Estimated)

[[Saint]]

I want to buy the FUZE+, what do you say? How long will it take to get an unstable version of Rockbox for this player? (Estimated)

Estimated: "Anywhere from some time in the future, to never"

Estimates simply aren't given, as the future cannot be predicted.
Developers work on what they want to, when they want to, in an entirely volunteer fashion.
There is also no telling what road-blocks may be hit along the way.

For now, only a very basic disassembly has been started to my knowledge.



[St.]

[haim]

Thanks, I just wanted to know if by progress today it looks it will happen this year, of course no one would have to do anything, and I thank you for all the work you are doing

[pamaury]

Hello,
I'm giving regular updates so here is one. I'm still working on disassembly because I still don't know how exactly the fuze+ is booting but I now have a theory. Apparently, the firmware file is split into 3 parts: the first part is the actual boot part which is probably written to the flash using the format describe in the datasheet. The two other parts are probably written somewhere else and manually loaded by the boot code.
The boot code seems to have three modes: normal mode (boots "play"), usb mode (boot "host") and update mode where it reads the firmware.sb file written at the root and update the flash content with it.

I still need to confirm this but if it were the case, it means we could simple replace the "play" part and have a failsafe mechanism since the host is able to expose the filesystem through usb. I'm also unsure about the checks done to authenticate the firmware updates. I know for sure that 1.32 only accept upgrades and not downgrades.

Sorry for all this taking a long time but the code is really complicated, it is obviously not a simple OS written for the fuze+ but more a full blown RTOS. I really have no estimate for now.

[pamaury]

Hello,
I have made some big progress in the analysis of the booting process. I'm now sure sure that the last booting stage is doing something of the firmware.sb file. I've found some cryptographic primitives which suggest that it's somehow checking that the file is valid and probably writing some part of it to the flash. I'm still not done but I'm getting closer.
As suggested in the Wiki, the access to the flash is done through a SD interface which is a good point since there is no FTL and it acts as a block device. It's still unclear to me how the screen works although I've reverse engineered most of code, it's a insane mixture of code, sometimes using GPIOs directly, sometimes using the PIX IP block, without the documentation it might be quite hard to make it work.

I still have no documentation for the touchpad. The photos show it's Synaptics chip but I can't find any datasheet, any help is welcome

[casainho]

I am looking forward for your work/advances, since I can't for now have a working code for C startup file for interrupts -- I need a working interrupt code for have Rockbox kernel tick working.

Good luck!

[pamaury]

Setting up interrupts for a tick timer shouldn't be too difficult, basically you need to:

• Enable icoll block
• Setup interrupt vector base
• Enable timer interrupt
• Enable timrot block
• Setup a timer
• Enable timer irq

You just need to be careful because on this chip to enable a interrupt there are zillions of things to enable (typically you need to enable the irq AND enable to irq to interrupt path). And you perhaps need to setup a clock path somewhere (the timrot uses the crystal osc I think but I don't have the doc right now).

[casainho]

Setting up interrupts for a tick timer shouldn't be too difficult, basically you need to:

• Enable icoll block
• Setup interrupt vector base
• Enable timer interrupt
• Enable timrot block
• Setup a timer
• Enable timer irq

You just need to be careful because on this chip to enable a interrupt there are zillions of things to enable (typically you need to enable the irq AND enable to irq to interrupt path). And you perhaps need to setup a clock path somewhere (the timrot uses the crystal osc I think but I don't have the doc right now).

I also need the assembly C startup code, for setup correct interrupt stacks, etc...

[yelped]

Pamaury, can any of these documents help you on the touchpad?
http://www.synaptics.com/developers/archive

[pamaury]

Hello,
I've not yet reverse engineered any code on the touchpad but these document can prove useful, thanks. I'll tell you when'll I'll come to it but this is not my priority.

[pamaury]

Hi all,
although I haven't done much progress I have some great news: I found the USB Recovery mode ! It's all explained on the wiki page SansaFuzePlus but it would be nice if some could confirm:

• Turn off the device
• Hold down volume up and while doing so, plug in usb

The device will appear as a HID device from Sigmatel

The VID/PID is coherent with the datasheet unfortunately, it seems to use some HID reports with commands, and the commands are not listed in the datasheet ("A list of USB bootloader commands is available upon request.").
I contacted Freescale to get some information, we'll see if I get an answer. Unfortunately, I couldn't find anything useful about it on Google so ideas are welcome

[pamaury]

I figured out that there was a Windows program call MfgTools provided by freescale to download a file to the RAM using this recovery mode. I had a look at the protocol and it seems quite easy to reproduce it, TheLemonMan is on the case. This way I managed to download some code as a proof of concept since one simply need to download a normal sb file.