• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Applications
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kugel. - 2008-10-29
Last edited by fg - 2008-11-07

FS#9512 - Sansa fuze in the rockbox tree

This patch adds the sansa fuze target.

It includes a building bootloader (untested!!), a keymap and a simulator build (half-baked, using the h300 background).

Some stuff is just copied from arm/as3525/e200v2 (e.g. backlight-e200v2.c). So, they’re not meant to be usable. Of course this files could be removed or replaced by a file only dummy’ing functions.

Comments are welcome.

Closed by  fg
2008-11-07 23:26
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Sim work will go to a new task

This is the scan I made of my fuze for the simulator. Quite bad quality, so I decided to not use it for now.

You’ll need to modify also mkamsboot (add a dummy case for the Fuze since A3 is the only button we know and it is checked anyway)

I think lcd file can be empty for now since according to disassembly the controller isn’t the same than the e200v2.
Also you have put code for a button wheel (maybe from e200v1?) : it should be left empty since the fuze, like its little brother the clip, has no wheel ;)

For the picture, I mentioned it on irc: a good picture for the Clip would serve also for the Fuze (and the reverse is true).

How come you think the Fuze doesn’t have a wheel? It has a wheel, and it’s turning around nicely. I haven’t modified mkamsboot since I’m not as up to the progress as you, so it’d probably better if you just insert something before committing.

If you do so, implement something which I can use to find out the button light gpio pin :)

Sorry, I only know the fuze by pictures, and I supposed the similarity with the clip would extend to the buttons (aka no wheel).
Here is a patch to mkamsboot.

To find the button light pin (if it really is on a gpio), you can do something like that in the bootloader’s main():

GPIOA_DIR = 0xff; /* all pins output */
GPIOA_PIN(0) = (1«0);
GPIOA_PIN(1) = (1«1);

etc .. and try pins one by one

Well, trying pins one by one isn’t hard. I’ve could done that myself :) I wasn’t clear but I searched for a loop that tries every pin on A(B,C,D) every second or so :)

int delay;

GPIOA_DIR = 0xff;

GPIOA_PIN(0) = (1«0);
delay = 0×100000;

GPIOA_PIN(1) = (1«1);
delay = 0×100000;


I can’t think of something else, especially if you have no output at all, I think each pin one by one is the best solution (there is “only” 32 of them)

This patch fixes some of linuxstb’s work. Correcting firmware/sources and button-target.h.

It still adds a preliminary version of a simulator.

Working buttonlight, backlight and lcd.

The meaning of the GPIO D7 (supposedly buttonlight pin) needs to be investigated though. Backlight didn’t work without that pin. Possibly lcd didn’t too, but I can’t tell if the lcd is working without backlight.

update: _buttonlight_on() isn’t actually needed.

Now with correct colors and a loop which shows brightness level and buttonlight change is working. Also commented storage_init() out, since it’s broken.

Ok, scratch that patch. svn diff doesn’t recognize if I “svn mv’d” a file…


Available keyboard shortcuts


Task Details

Task Editing