Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
ecrips:
I recently got a Fuze V2 and I thought I'd report on my findings:
The GPIO inputs for USB detect and Left button are the same as the Fuze V1 (using http://github.com/ecrips/Rockbox-FuzeV2/commit/8a9030bbd1f895958b5c455e398cf1ab499c27b5 I successfully get a delay only when holding Left and without USB connected). I limited the RAM to 0.5Mb not because I know it's correct, simply because I don't know for sure I have any more.
I then attempted to cobble together the ClipV2 support that funman has done with bits of Fuze V1 code, but didn't get anything to boot.
So I thought I'd go for something simple and attempted to simply turn the button wheel on and spin in an infinite loop. At which point my Fuze appeared bricked. No amount of holding the power button/plugging into USB etc got it working.
However, once the battery was flat, plugging it into USB got it booting the original firmware again! So I've recovered my device, but I'm a little wary of running random code on it now :)
It does appear that it's possible to disable the "reset" operation on the power switch on Fuze V2s which could make testing interesting!
funman:
--- Quote from: ecrips on June 03, 2009, 08:46:17 AM ---I recently got a Fuze V2 and I thought I'd report on my findings:
The GPIO inputs for USB detect and Left button are the same as the Fuze V1 (using http://github.com/ecrips/Rockbox-FuzeV2/commit/8a9030bbd1f895958b5c455e398cf1ab499c27b5 I successfully get a delay only when holding Left and without USB connected).
--- End quote ---
Cool!
Did you try to control the button light, so at least you have some output before we write a lcd driver?
--- Quote from: ecrips on June 03, 2009, 08:46:17 AM ---I limited the RAM to 0.5Mb not because I know it's correct, simply because I don't know for sure I have any more.
--- End quote ---
Hum I don't remember why I did that: a packed Clip bootloader + packed Clipv2 OF largely fits in 0x5000 = 327680 bytes (384kB, not 0.5MB):
[INFO] Original firmware size: 391804 bytes
[INFO] Packed OF size: 90807 bytes
[INFO] Bootloader size: 45464 bytes
[INFO] Packed bootloader size: 22987 bytes
[INFO] Dual-boot function size: 272 bytes
[INFO] UCL unpack function size: 168 bytes
[INFO] Total size of new image: 114234 bytes
And the bootloader size can even be shortened by removing -mlong-calls option from gcc.
However I suppose that you have plenty of RAM behind that, since on Clipv2 & Fuzev2 the DRAM is mapped at 0x0 (the OF firmware block doesn't fit in 0x50000 bytes, so I suppose that the IRAM size didn't change between AS3525 and this newer SoC believed to be AS3531)
--- Quote from: ecrips on June 03, 2009, 08:46:17 AM ---I then attempted to cobble together the ClipV2 support that funman has done with bits of Fuze V1 code, but didn't get anything to boot.
So I thought I'd go for something simple and attempted to simply turn the button wheel on and spin in an infinite loop. At which point my Fuze appeared bricked. No amount of holding the power button/plugging into USB etc got it working.
However, once the battery was flat, plugging it into USB got it booting the original firmware again! So I've recovered my device, but I'm a little wary of running random code on it now :)
It does appear that it's possible to disable the "reset" operation on the power switch on Fuze V2s which could make testing interesting!
--- End quote ---
You should be able to use the unmodified power_off() function, so you could test your code with a finite number of loops, and then power off to avoid having to empty the battery.
This thing also happened to me with a Clip while developping the bootloader but I don't remember why exactly (perhaps reading/writing from some GPIO pin).
Also note that on Clipv2 you have to press the power button for much longer than for Clipv1 (something like 20seconds)
I'll try to find the LCD code in the OF, since I know a bit the Sansa AMS firmwares and they all are _very_ similar (even between AMS v1 & v2!).
matsch:
--- Quote ---Can you confirm that you have no radio chip (radio not detected by rockbox) ?
You can check in debug menu -> FM radio.
Perhaps this is the way to detect the Clips which needs this special screen powering.
--- End quote ---
My clip has no radio chip. Submitted patch to flyspray.
http://www.rockbox.org/tracker/task/10273
ecrips:
--- Quote from: funman on June 03, 2009, 10:54:57 AM ---Did you try to control the button light, so at least you have some output before we write a lcd driver?
--- End quote ---
I have attempted to turn it on using the following code:
--- Code: --- ldr r0, =GPIOA
ldr r1, [r0, #0x400]
orr r1, r1, #0xFF
str r1, [r0, #0x400]
mov r1, #0xFF
str r1, [r0, #(0xFF<<2)]
mov r0, #0x3000000
1: subs r0, r0, #1
bne 1b
b boot_of
--- End code ---
(repeating for GPIOs B, C and D) I'd expect that to configure all pins as outputs and output a 1 on each pin. But I haven't managed to turn the button light on with that code. Although it has just now occurred to me that it's possible the button light is on when a 0 is output... I shall have a go later.
funman:
What if you try only GPIOA_PIN4 ?
By the way if you want to come on IRC we could discuss this "live" (i'm in CEST timezone)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version