release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Search | Go
Wiki > Main > SansaFuzePlus > SansaFuzePlusPort (r11)

Port Status

driver status comments
LCD 80% One kind of LCD is working, the other one has been implemented solely by reverse engineering but remains untested. Still lacking partial updates, lcd sleep, inversion, ...
Keys 70% Physical keys are handled (see (1)). Touch pad RMI driver has been implemented but there remains a bit of work to map the gestures to some virtual keys as a first step.
Music playback 0% Not implemented.
FM Radio 0% Not implemented.
Recording 0% Not implemented.
Power Management 0% No battery readout yet
DMA 100% DMA works
SSP 100% SSP works
MMC 100% MMC works, I can switch the internal flash to 8-bit bit @48 MHz
SD 40% A few commands implementeds, only the general SD part is missing, detection works
Clock/voltage 70% The code works but we are still lacking code to handle voltage; also switch cpu speed is non-trivial and requires careful switching of clock and voltages
USB 100% Everything is implemented and should work

  • (1) The volume down key is wired to a GPIO but volume up and power button are wired to the PSWITCH pin for power up/down/recovery. The detection is made by the chip and is voltage based which means that one can detect when either one of those is down but it's impossible to distinguish between when volume up is down and when both are down. Is there another way to handle this ?

Building the bootloader

To build the bootloader, you first need to have a cross compiler (see: HowToCompile choose "e" for cpu target option). Then do a regular bootloader build which will produce a bootloader.bin file. (see: HowToCompile, sansa fuze+'s build is number 64). Then you need to get a Fuze+ firmware update from sandisk, decompress it and run the following command:

sbtoelf firmware.sb fuze+_key_file.txt OUT.

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:

OUT.____.0.elf, OUT.____.1.elf, OUT.____.2.elf, OUT.____.3.elf, OUT.____.4.elf, OUT.host.0.elf, OUT.play.0.elf and OUT.play.1.elf

Delete all files except OUT.____.0.elf, OUT.____.1.elf and OUT.____.2.elf and copy your bootloader.bin file in the same directory. Then create a file named bootloader.db with the following content

sources
{
    stage0 = "OUT.____.0.elf";
    stage1 = "OUT.____.1.elf";
    stage2 = "OUT.____.2.elf";
    bootloader_bin = "bootloader.bin";
}

section('init')
{
    load stage0;
    call stage0;
    load stage1;
    call stage1;
    load stage2;
    call stage2;
    load bootloader_bin > 0x40000000;
    jump 0x40000000;
}

Finally run the following command:

elftosb bootloader.db fuze+_key_file.txt bootloader.sb

It should produce a bootloader.sb file which you can send to the device using the imx_hid_recovery_tool which can be found in the trunk using the following command (device in recovery mode, see SansaFuzePlus):

imx_hid_recovery 1024 bootloader.sb

this way no modification will be made to the device and original firmware, but you will be able to test the current port's state

-- AmauryPouly - 01 May 2011
Edit | Attach | Print version | History: r77 | r12 < r11 < r10 < r9 | Backlinks | View wiki text | More topic actions...
r11 - 31 Jul 2011 - 20:38:38 - AmauryPouly

Parents: SansaFuzePlus
Copyright by the contributing authors.