Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
bertrik:
Last night I tried to see if anything else was present on the audio master i2c bus of my clip. No luck, I only got the codec at address 0x46 to respond, no response at any other addresses. Tried the same on the master/slave bus and no response at all either (I did make sure that the master/slave i2c interface was enabled in the CCU_IO register and that the i/o pins were not configured for display use). I was hoping to find the fm radio chip.
I looked at the fuze firmware and it seems it does "bit-banged" i2c on some pins (i.e. doing i2c by wiggling GPIO pins). It might be worth looking into devices on this bus. The generic GPIO i2c driver already present in the rockbox sources could make this easier.
Domonoky:
I just detected that, at least on the m200v4 the sd-driver doesnt need the CCU_IO bits modified.
So at least for the internal storage it doesnt use gpio d.
When i dont modify the CCU_IO i get my backlight back working. And as a added bonus the sd-driver is running much better in rockbox, i can now browse files in rockbox :-)
Could people with other sansa v2 players test if the CCU_IO bits also arnt need in the sd-driver ? (especially external sd-mem on e200v2 would be interesting).
funman:
It's not needed on the Clip, but I didn't try to make the difference between modifying or not.
According to the as3525 datasheet, it should only matter when using the 'original' PL180 controller, the one used with a SD slot (on Fuze and e200, I don't know if the c200 has an SD slot).
Note that I have applied the diff of domonoky and modified it a bit, but we both still have strange results, especially panics in the fat driver, that might result from incorrect data transfers which are not reported by the DATA_CRC_FAIL in the PL180's STATUS register.
EDIT:
Disabling the irq before the data transfer gives perfect results: no overrun, no delay...
But this still causes panics in the fat driver, so the data transferred may have been corrupted.
Another problem with this approach is that we don't give back the control of the CPU to other threads or the kernel tick interrupt until the transfer has been made.
If we can fix or understand the remaining problem we might do precise timings (perhaps with a TIMER) and decide if this approach is worthwhile.
I attach a patch which disable interrupts, and does no retries if a problem happened (instead it will happily panic).
Please report if you see problems other than a panic "Updating size on empty dir entry %d"
EDIT2: the remaining problem has been fixed with a suggestion of Frank Gevaerts: the write function returned success. Making it return a failure fix the problems, I'll commit a fix shortly.
yapper:
--- Quote from: funman on November 16, 2008, 01:03:32 PM ---...I don't know if the c200 has an SD slot
--- End quote ---
It does
Llorean:
Hi, I've just played with the clip simulator and noticed the keymap.
Is there a particular reason it's so drastically different than existing keymaps (especially the e200, which could be 1:1 mapped if you used the volume buttons in place of the wheel)?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version