Sansa Fuze+

[metaphys]

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

I can confirm it even with last firmware:

[16553.669075] usb 1-1: new high speed USB device using ehci_hcd and address 4
[16553.783791] usb 1-1: New USB device found, idVendor=066f, idProduct=3780
[16553.783799] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[16553.783806] usb 1-1: Product: ROM Recovery
[16553.783810] usb 1-1: Manufacturer: Sigmatel, Inc.
[16554.210234] generic-usb: probe of 0003:066F:3780.0001 failed with error -22
[16554.210261] usbcore: registered new interface driver usbhid
[16554.210264] usbhid: USB HID core driver

Anyway did you saw that :
http://mympxplayer.org/sigmatel-recovery-guide-updated-vt8150.html ?

[pamaury]

The link you provide apply to older versions of the stmp chips (35xx and 36xx iirc) which used a different recovery mechanism (basically a DFU mode and a much simpler sb file format).

Anyway, I got an answer from Freescale and it was the same as TheLemonMan got: the bootloader commands are under a NDA. Anyway, both of us managed to reverse engineer the part of the protocol we needed, here is a link to the short program to download some code on the device:
https://github.com/pamaury/pa-tools/tree/master/fuze+/recovery_hid
There might be a conflict with usbhid so one perhaps to unload it (a problem TheLemonMan encountered).
Here is the link to his code (and there quick description of the protocol):
https://github.com/LemonBoy/OpenBLTC
There might a subtle difference here because he uses a reset to end the transfer and I wait for the interrupt transfer on my side. Since we do not have the same device and the same chip (3700 vs 3780), there might a difference here too.

[pamaury]

I didn't have much time last week but this week-end I fixed some bugs in sbinfo (now called sbtoelf) and wrote an open-source version of elftosb. All this can be found in the SVN.

[pamaury]

Since I've begun writing some code for the recovery mode of the fuze+, I thought it would be good to publish it somewhere before it's ready. Everything can be found here: https://github.com/pamaury/pa-tools/tree/master/fuze+
The recovery_hid is the tool to download the sb file to the device. To build the sb file, one need elftosb, the current Makefile uses the syntax of the one found in Rockbox trunk but with minor tweaks it can be made to use Freescale's one.

[pamaury]

Hello,
I've got some good news: I've managed to make USB work (wasn't too hard) so using another tool in my repo (usb_debug) I can output debug strings ! I've started to write some code for the LCD and it appears that there might be two models available out there. Unfortunately, my current code currently doesn't work, the LCD is not responding I hope to have LCD working soon.

[pamaury]

Good,
I've finally reverse engineered the whole lcd init/enable/disable sequence for one model and I know how to tweak backlight more or less. Now I'm wondering if there are actually are two kinds of LCD in the nature. Producing the binary for the recovery mode is not exactly trivial so I can provide the binary. Do people out there are able to build the recovery_hid tool in my repository (https://github.com/pamaury/pa-tools/tree/master/fuze+/recovery_hid, linux only) and are willing to test some binary to see if the LCD is of the same kind as me ?

[metaphys]

Yes i'm on a debian 64 bits and I could try this if you explain how...  

I've tried a basic 'make' & 'make install' but it doesn't seems to be that simple...  

edit : ok  I have to execute Makefile... and I need a few dev lib... Is it suppose to be cross-compiling already? Do I already need a whole cross compiling environment?

[pamaury]

It's rather simple: you "make" into the recovery_hid (there is not "make install" target) and it should produce a recovery_hid tool (you will need libusb-dev version 1.0), then download this file: http://amaury.pouly.free.fr/recovery.sb and put it in the same directory. Then plug the fuze+ in recovery mode (holding volume up) and run as root:
recovery_hid 1024 recovery.sb

EDIT: you don't need a cross compiler, the recovery_hid is a pure host tool. You only need a cross compiler if you want to build recovery.sb yourself
EDIT2: to check that the code is actually working (in case the lcd doesn't light), you can use the usb_debug tool in my repository ("make" and then run it as root), it will output the debug message logged by the device

[metaphys]

WAAAOOOHH!  

As I type de command the screen of the fuze+ turn white, then it disconected itself and go back to mass storage device mode

Is it what was expected?

Edit ok i will try debug now
Edit2 : wait it did light up, do you still need debug?

[pamaury]

Yes, the screen turns on and off two types (when off with backlight on, that's garbage) and after 10 sec it turns off (and reboot if still plugged). Ok so it means you have the same lcd controller as mine Thanks for testing ! I still to work a bit to know how to display pixels but this is nearly it.

[pamaury]

I finally got the LCD working, that's wasn't too easy finally but it works.
I took a picture http://amaury.pouly.free.fr/SSL22450.JPGbut it looks much more nicer on the device
There are still a few things I nice to understand, I think the LCD supports partial blits but I'll investigate later.

[metaphys]

nice indeed 
Let me know if you need some more test...

[metaphys]

I'm thinking about leaving a message asking for tester on the sansa forum dedicated to the Fuze+ (especially about this lcd other kind issue. Obviously we are both french and althrough I'm living in austria, it's not so suprising that we got the same kind... it's still EU)
But I wonder if this would please the sansa team ...  Any history about that? Is there any policy principle when dealing with official company and Rockbox?

[pamaury]

No idea, I think I saw some comments asking whether Rockbox would be supported in the Sansa forums But moderators could well delete that message.
When I'll have time I'll reverse engineer the second sequence and implement it. By carefully checking, it should be ok and if it's not, people will hopefully post to the bug tracker.
By the way you're right that the second type of screen might have to do with the location.

[metaphys]

ok so I guess there is no urge for tester about this other lcd kind just right now...