Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
atomikpunk:
Just a small update to the wiki listing all the GPIOs (we know of) that are used in the firmware and their deduced usage.
I'm still thinking about how we could inject more than a couple of bytes into the OF to insert a rockbox bootloader, but I've not much progress to report so far... If you've got ideas on this, please share them! Of course, when we'll find a button we can easily read at boot, it will be WAY easier to test because we will be able to test some code without the risk of bricking (more) devices. We could try the keypad scanning algorithm, but there's a bunch of instructions in there, maybe we could clean it up a bit and use that?
Owh and just for the records, I've tried to bridge 2 I/O pins on the flash like it is suggested on S1MP3.org to make the SoC think the flash is corrupted. This was in order to load the internal bootloader. I've used a 100 ohms resistor without success so far. I also tried grounding some I/O pins, one at a time, via that same 100 ohms resistor, also without success... I'm a bit shy at trying it directly with a wire, fearing that I'd burn the chips drivers or something...
I'd like to help you guys probing the supposedly JTAG pins but on the M200 series, the LCD display is soldered directly above those pins >:( If I may suggest, probe the connector pins with every components, like resistors and capacitors... Maybe we are just missing passive components on the JTAG path...
daniel_at:
Hello all...
Had today again some time, which I spent infront of my e200-V2.
I tried for the first time to write to the partition exhibited by the special mode - and: It works!
* Just modified some bits in the "DEAD-BEEF"-areas
* unpluged the device
* started in normal mode: works.
* unplug again
* start in special-mode
* check if it is still modified: YES
(no battery was connected, so it was really modified in flash)
So if anyone has some time to provide me with modified firmwares who has no e200, I am willingly available for testing them. Just conntact me by this thread or by PM. Best would be to test the modfications via IM in "realtime".
Daniel
andva:
That's excellent, Daniel. I haven't yet gotten around to using atomikpunk's tools, but if you feel adventurous, you may try writing a different version of the firmware to the device to see if it is updated. Bagder keeps several versions in his website: http://daniel.haxx.se/sansa/v2.html
Thanks for trying, keep up the good work!
atomikpunk:
Hi Daniel,
this is great news! I'm more than willing to help you test some stuff on your e200 if we get to be online on jabber at the same time :) I'll write a couple of tests we could try... I'll also bring an wall-powered USB hub from work to see if power was the problem with my m200... If not, I'm really clueless about the problem I'm facing with this one...
Any update on the JTAG stuff? I'm about to build a wiggler JTAG interface and try to test it on my side...
Also, I've a couple of minor findings I'd like to put on the wiki, but since the graph plugin does'nt work, I'll wait a bit... But everything is minor, nothing of big interest to report yet.
BTW, I got myself another sansa from ebay but unfortunately, it's a m200 v1. I'll try to see if someone is interested in trading with a v2, maybe in the sansa v1 port forum or something... Or if someone here wish to trade, contact me via personal messages!
Francois
daniel_at:
Hello atomikpunk,
I have played a bit with motified firmwares. I use the utils/AMS/hacking tools from Dave Chapman from the svn.
I have modified the test.S:
--- Code: ---.equ AS3525_GPIO1_BASE, 0xC80B0000
.equ GPIO3_DATA, (AS3525_GPIO3_BASE+0x0000)
.equ AS3525_GPIO3_BASE, 0xC80D0000
.equ GPIO1_DATA, (AS3525_GPIO1_BASE+0x0000)
/* This value is filled in by mkamsboot */
originalentry: .word 0
/* A delay loop - just to prove we're running */
ldr r1, =GPIO1_DATA
ldrb r1, [r1] /* Load GPIOC-Data into r1 */
tst r1, #0x10 /* check if .. is set */
bne noloop
mov r1, #0x500000 /* Approximately 5 seconds */
loop: subs r1, r1, #1
bne loop
/* Now branch back to the original firmware's entry point */
noloop: ldr pc, originalentry
--- End code ---
(tried different Bit-Masks....but not all)
But I did not get any results so far - the delay always happens. Which is already a good step, which says that my sansa runs my modified code.
But i also have some strange behaviour: the first boot after a fw-update (via my "special-mode"-methode) takes about 30seconds until the "Sansa"-Bootlogo comes up. Each consecutive start takes about 7seconds (with delay) or 2 seconds (without delay, removed within code)
I tried to analyse the patched firmware in the disasm... But i have some problems to get it doing what I want... Your help would be appreciated :) Just ping me, if you see me online - would be great.
Daniel
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version