Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Hillshum:
I'm only on in afternoons (UTC-6 till daylight wasting ends, then UTC-7).
funman:
Now that we exchanged our IM we'll get in touch, I hope better doc attracts new hackers ;)
As for the bootloader, I'm still blocked on the nand driver
I had a look at various drivers (in rockbox, Linux and U-Boot) and especially at the patches for U-Boot & Linux mentioned in this post http://forums.rockbox.org/index.php?topic=14064.msg117283#msg117283
I also read the ONFI 1.0 & 2.0 specifications (http://www.onfi.org)
But I can not get the signal that the NAND is ready for operation
I attach my stage2.S , if you run it it will just blink the led forever, so I advise you to not use it.
Reverse engineering the OF shows no direct references to the nand registers, but atomipunk found a location in the code where these registers are calculated (by an offset to the base address) and stored in RAM, to be later used by other routines.
This renders analyzing & understanding how the OF interacts with the NAND quite complex.
Note that the patches for Linux have still not been applied, maybe they were buggy or written for a target different from the SansaV2 ? (like in AS3525-1 or AS3525-2)
We could try to contact AMS and ask them for the Linux patches, maybe they have evolved since the patches sent to the linux-arm mailing list.
NEW POST:
I have found new buttons for the Clip:
* b2 is the 'home' button
* b1 is the 'volume down' button, once you have configured b4 & b5 as OUTPUT
The list is growing up :)
atomikpunk:
After (much) hacking into the firmware, I found it very hard to find any NAND registers references, and a lot too much SD interface registers references. As my analysis went by, I bended more and more to the idea that the flash could be in fact accessed using the SD interface instead of the NAND interface we previously suspected.
And after re-reading some docs on Daniel's site, I found out that v1 e200 players used the SD interface for the (primary) flash. So well I'll invest more time now on the SD interface as it seems to be the most promising avenue at the moment.
That's no big news for today except that on the analysis side, it is much clearer now what we're looking for ;)
Just a reminder: once we're able to load a custom firmware from the flash, we're free for _much_ more hacking since it'll be much easier to drop firmware files on the player and test stuff. So that's pretty much the last tricky part before things goes more roundly.
funman:
Very good news !
Now we can continue study the OF with a clearer mind and start writing a SD driver.
I think that we must use the SD driver with the nand base address instead of the sd mci base address to access the nand, SanDisk may have wired the ams3525 differently.
Or maybe we must use the SD base address and load a specific "bank" to access the nand chip, testing will tell ...
Also don't forget when we have access to the raw nand content we must write a minimal fat32 driver to fit in the bootloader, but I hope the fat32 filesystem is quite simple.
Back to hacking ;)
Bagder:
--- Quote from: funman on September 18, 2008, 08:44:37 AM ---Also don't forget when we have access to the raw nand content we must write a minimal fat32 driver to fit in the bootloader, but I hope the fat32 filesystem is quite simple.
--- End quote ---
Rockbox already has all the fat32 filesystem code you need of course...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version