Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
JdGordon:
A better solution came up in irc today that the superfloppy mode should be told which sector to start at (it does already anyway, currently always 0) instead of using the SD driver to shift it. this _should_ work but hasnt been tested yet
JdGordon:
weeee :)
time to join the party properly!
ATA error: -1
Press ON to debug
loading a real binary on my e200v2...
edit: commenting out some #ifdef BOOTLOADER lines andremoving HOTSWAP and MULTIVOLUME gets me to the logo... time to find out how much further
mc2739:
I was able to get to the main menu on my e200v2. It is still not very consistent. Sometimes, I get just a white or gray display. If you hold the player at an angle, you can sometimes still see the rockbox logo. After 10 seconds, the backlight goes off. The buttons aren't working yet, but inserting the USB cable will sometimes turn the backlight back on.
I'm starting to wonder if the shared GPIO deal is what maybe causing some of these problems (at least on the e200). The display uses GPIO B & C as do some of the buttons. The button light uses GPIO D which I believe is also used by the storage. If the various functions are not checking the status of these GPIOs, and just reading or writing under the assumption that they are still in the correct state, then who knows what will happen.
Any thoughts from the more experienced?
JdGordon:
sounds plausable :p
here is a better version of the disk sector offset patch I had up before.. this one actually works
funman:
--- Quote from: mc2739 on November 12, 2008, 12:46:12 AM ---I was able to get to the main menu on my e200v2. It is still not very consistent. Sometimes, I get just a white or gray display. If you hold the player at an angle, you can sometimes still see the rockbox logo. After 10 seconds, the backlight goes off. The buttons aren't working yet, but inserting the USB cable will sometimes turn the backlight back on.
--- End quote ---
The SD driver is broken.
It doesn't work.
It's not finished.
It reads corrupted data.
Don't use it.
It will not be fixed by modifying 2 lines of code.
The solution might be to use DMA requests to read the data from the SD controller.
The DMA controller is luckily a (documented) PrimeCell controller, so this should be easy to write code for it.
--- Quote from: mc2739 on November 12, 2008, 12:46:12 AM ---I'm starting to wonder if the shared GPIO deal is what maybe causing some of these problems (at least on the e200). The display uses GPIO B & C as do some of the buttons. The button light uses GPIO D which I believe is also used by the storage. If the various functions are not checking the status of these GPIOs, and just reading or writing under the assumption that they are still in the correct state, then who knows what will happen.
Any thoughts from the more experienced?
--- End quote ---
This is not a problem, the button light code shouldn't be called at all as far as i understand.
And if it is called, it should restore the state of the CCU_IO register which defines if XPD is used for SD/MMC (storage) or for GPIO.
Note that to avoid potential bugs, we should disable interrupts before changing this CCU_IO register, and reenable them after we have reset it to the original value, to be sure not to leave the register in the GPIO state while we need SD transfers.
---
People, is it possible to keep this forum thread development related, and not testing related ?
It is already quite hard for newcomers to follow these 30+ pages and understand what is the current status.
(For newcomers: the current status is in development, and not ready for use)
IMHO the port is not in a state where it benefits from massive testing.
Maybe the developers ask to try a feature once to see if the results are not different on another model, but no need to answer the same thing 10 times.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version