Sansa Fuze+

[Frank9321]

Hi,
I just bought a Fuze+ in order to replace my old e200 (running rockbox) that broke some weeks ago. I received the sansa today and I tested it. The firmware isn't that good so it would be very interesting to be able to port rockbox to the sansa+. Actually, I'm preparing for an exam (the french BAC) but after that, after the 22th of June,  I will be free. I know a bit C and I do program microcontrolers (ATMELs AVR) so I hope that I will be able to contribute a bit. I don't know anything about ASM and all that but I do know how µC I/O works, etc...

Meanwhile, I hope that you will be able to learn more about the fuze+.

Cheers,

[pamaury]

Hi,
we already have an ongoing port, the code is in the SVN and there is info on the wiki on how to compile/build everything. Everyone is welcome to help of course If you are interested, you might have a try at making the sound work, although I'm unsure if it needs info from the OF or not. But for now, everything is a bit difficult since we don't have the storage working !

I'm still unable to make the internal (or external) SD/MMC work but I have make some progress anyway. Since the bootloader of the fuze+ is in an i2c eeprom on the board, I wrote some hacky code to read it and it seems to work. I'll try to dump it all and study it, this way I could understand what I'm doing wrong with the SSP/SD/MMC code.

[pamaury]

Ok, I've managed to dump the rom. It uses the sb format too with a zero key just like the firmware. It consists in two parts:

• A bit of code
• A command to change boot mode (to SSP2)

I don't know yet what the code does.

I old fiddle a bit with the USB and it works in the bootloader even though it requires a few hack right now because I haven't written the code to correctly detect insertion.

[pamaury]

I've got some good news. After a bit of tweaking I finally managed to make the internal eMMC flash to work. I can reset it, do the power up sequence and read the CID so now it should be really easy to read/write from it. I will commit the commit as soon as possible.

EDIT:
I can now read the internal flash but I'm a bit puzzled by the content it. It has a MBR but it looks strange:
- all partition (except one) are of FAT12 type (even though one has size of 7.9G approx)
- one partition has type 'S' to be booted by the ROM but the starting sector doesn't match the actual data (there is an offset of 0x800 bytes of so...)
That's all very weird :-/

[pamaury]

Hello,
I finally got the storage working, so SSP, DMA and MMC is working, and the code does the necessary stuff to try to find the good partition so hopefully the bootloader will now try to find a rockbox firmware in the internal flash.
As the OF uses some weird layout, I would appreciate some testing on fuze+ with different internal flash size. Mine has 8G so testing it with 4G and 16G would be really nice.

WARNING: I change the bootloader.db file to include a third stage of the original OF, please see the change on the SansaFuzePusPort wiki page; the code will NOT work without it, it's related to voltage and frequency setting.

I need to think about where exactly I will put the bootloader: replacing the OF seems a bit aggressive and even though I could aggregate both in one file, any OF update would destroy the bootloader. There is a i2c chip on the device but it's only 64kb large and I don't know if it's write protected. Having support for dual-boot would be really nice but non-trivial it seems. Any idea is welcome
Note that somehow the OF manages to do it but I don't understand how and since I don't really have a proper documentation of the sb format, I'm stuck.

[danger355]

I would appreciate some testing on fuze+ with different internal flash size. Mine has 8G so testing it with 4G and 16G would be really nice.

Hi,

I've been following this post for a while now and noticed all the progress being made (thank you!). I wanted to be ready for when if this port became usable so I actually ordered a 16G and it's scheduled to be delivered mid next week, so I'm willing to test it out.

This will be my first time testing something so early in development, but I do have plenty of other experience in using non-stock firmwares on other small electronics - my last two phones and my nook color all run custom Android ROM's and I had an iRiver HP-120 that had rockbox on it. So don't worry, I know the risks and am willing to ignore them

Once I get it in, I'll run through the wiki and I guess I'll just post if I run into any snags?

Thanks, and cheers!

[metaphys]

Hello Pamaury,

My device is 16GB and I will test it as soon as possible. For the moment I'm travelling around so I'll will not be able to do so before a few days.

[pamaury]

Hi,
one more note about dual-booting. I finally found how the OF booted by disassembling the boot ROM. I now see a way of dual-booting provided that the i2c epprom is not write protected.

The simplest way would be to put the bootloader in the i2c chip (so 64kb at most) which would have three sections:

• first section decide which one to boot (OF or RB) and branch to the related section
• the RB section boots rockbox normally
• the OF section changes boot mode to SSP2 so that it boots normally

The only annoying point here is that the bootloader would be limited to 64kb which will require to rewrite to the OF init code for EMI (memory), voltages and frequencies but it shouldn't be a major problem.

[pamaury]

Hum, in fact I made an error while reading: the i2c eeprom chip is only 8kb large
This means that dual-booting will be a little bit more tricky than expected.

On the positive side, I found out the pins used by the FM radio chip which is a si7403 as expected. It seems that it is RDS capable but rockbox doesn't handle this yet. I'm now focusing on the audio part: recording and playing.

[danger355]

hi,

i'm in the process of building the bootloader, and keep running into an issue with the sbtoelf tool.

it seems no matter how i try and run it, i always get a 'command not found' error.

i'm running the code shown here in the SansaFuzePlusPort page after building a regular bootloader using the cross compiler:

Code: [Select]

sbtoelf firmware.sb fuze+_key_file.txt OUT.
from the wiki after the code:

where the sbtoelf tool can be found in the trunk in utils/sbtools/ along with fuze+_key_file.txt; this should produce lots of output and several files:

does this mean that all three files (the sbtoelf.c tool, the firmware, and the fuze+_key_file) need to be in the same file folder? I've tried that and i get the error above.

any help would be appreciated. thanks.

[saratoga]

it seems no matter how i try and run it, i always get a 'command not found' error.

Sounds like you didn't build sbtoelf.  Theres a makefile in utils/sbtools.  That will build the tool for your system, then you can run it like any other executable.

does this mean that all three files (the sbtoelf.c tool, the firmware, and the fuze+_key_file) need to be in the same file folder? I've tried that and i get the error above.

Are you familiar with command line programs?  Generally nothing ever has to be in any particular folder provided you have the right paths.  Once you build the executable, you can run it with no arguments to see what inputs it takes:

Code: [Select]

mike@biosgroup-desktop:~/rockbox/codeclib/utils/sbtools$ ./sbtoelf
Usage: ./sbtoelf <firmware> <key file> [<out prefix>]

So the actual folder locations shouldn't matter so long as you give correct paths for each file. 

[danger355]

Sounds like you didn't build sbtoelf.  Theres a makefile in utils/sbtools.  That will build the tool for your system, then you can run it like any other executable.

there is already an 'sbtoelf.c' in the folder. is there another sbtoelf file i need? by 'build', do you mean use the make command? i tried that too and i get the error "*** No rule to make target `sbtoelf.c', needed by `sbtoelf'.  Stop."

Are you familiar with command line programs?  Generally nothing ever has to be in any particular folder provided you have the right paths.  Once you build the executable, you can run it with no arguments to see what inputs it takes:

not intimately familiar, but i can usually get by. i've run into a few minor roadblocks so far, but this is the only one i haven't been able to google my way out of. i realize it should work, i just can't see/figure out what i'm doing wrong.

[saratoga]

Sounds like you didn't build sbtoelf.  Theres a makefile in utils/sbtools.  That will build the tool for your system, then you can run it like any other executable.

there is already an 'sbtoelf.c' in the folder. is there another sbtoelf file i need? by 'build', do you mean use the make command? i tried that too and i get the error "*** No rule to make target `sbtoelf.c', needed by `sbtoelf'.  Stop."

The command is "make" with no arguments.  Are you sure you typed that and not "make sbtoelf.c"?  make is a tool for handling dependencies, but it doesn't understand c files so it'll fail if you point it at code. 

[danger355]

The command is "make" with no arguments.  Are you sure you typed that and not "make sbtoelf.c"?  make is a tool for handling dependencies, but it doesn't understand c files so it'll fail if you point it at code. 

yes i'm sure. i also tried others earlier, glad to know i at least got that right.

Code: [Select]

ubuntu@ubuntu:~$ cd rockbox/utils/sbtools
ubuntu@ubuntu:~/rockbox/utils/sbtools$ make
make: *** No rule to make target `sbtoelf.c', needed by `sbtoelf'.  Stop.
ubuntu@ubuntu:~/rockbox/utils/sbtools$

just to make sure, i've gone as far as creating the bootloader.elf file. there was nothing in the wiki about putting this file in the /rockbox/utils/sbtools directory, so i placed it in a newly created /build-dir (as suggested in the make prompt while creating the bootloader)

is there anything that i missed that i still need to do?

[pamaury]

Hello,
the normal steps to build sbtoelf is to have an up to date svn checkout and to type make in utils/sbtools. You error definitely indicate something wrong; are you sure you have the sbtoelf.c ?
Then you should follow the steps in the wiki SansaFuzePlusPort page, everything is written. The directory in which is happen is not important, a fresh one will do.