Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
funman:
The driver is there but the way to control the nand pins is not exactly the same, plus the driver is in C and it's too big to fit, so I try to squeeze it a bit :)
I saw the 65Mhz clock in the datasheet section 7.3.12.7 but didn't see a 24 Mhz clock
The routine I saw is at 0x8598, you will probably have noticed it.
About the mapping, I tried writing a value in memory (offset < 0x20000) and read it back, but the comparison failed.
The code I posted maps RAM at 0x0, it's really simple, and I just setup a stack and use it to store registers like lr in function calls, and it works fine.
So next step is to finish the nand driver and put all the (position independant) functions in a block that I can memset() before returning to the OF.
Then FAT32, and winner ;)
atomikpunk:
Hmm are you sure your code works ???
Maybe I didn't see something or what, but I see at least 2 problems (please correct me if I'm wrong): 1) You did not copy the ROM content into ram before mapping RAM at 0x00000000, and 2) you execute code from the addresses you swap in the memory map and didn't change the PC or anything before doing so. This will result in: 1) PC eventually pointing to uninitialized RAM, and while the copy process 2) PC pointing to a "copy-in-progress" memory area.
The only reason I think it works for now (and this is absolutely risky as you will see) is either: a) the RAM was previously initialized with the firmware by a "proper" load of the OF, or b) code cache is active and for whatever reason it continues to give valid code even though ROM isn't mapped anymore...
And worst of all: you should check for buttons and choose whether or not to boot custom firmware before anything else. You did changed the memory map register before that check you bad boy. ;)
For the clock, you can clearly see it here between the SoC and the mike.
Indeed about the LoadLibrary routine. In fact I did a little more disassembly of the clip firmware and found everything I already found in the m200 firmware so I feel like home now :P I'll gladly share my work files if you would like to have a look.
As for the NAND driver, way to go mate.
funman:
--- Quote from: atomikpunk on September 04, 2008, 11:34:32 PM ---Hmm are you sure your code works ???
Maybe I didn't see something or what, but I see at least 2 problems (please correct me if I'm wrong): 1) You did not copy the ROM content into ram before mapping RAM at 0x00000000, and 2) you execute code from the addresses you swap in the memory map and didn't change the PC or anything before doing so. This will result in: 1) PC eventually pointing to uninitialized RAM, and while the copy process 2) PC pointing to a "copy-in-progress" memory area.
The only reason I think it works for now (and this is absolutely risky as you will see) is either: a) the RAM was previously initialized with the firmware by a "proper" load of the OF, or b) code cache is active and for whatever reason it continues to give valid code even though ROM isn't mapped anymore...
And worst of all: you should check for buttons and choose whether or not to boot custom firmware before anything else. You did changed the memory map register before that check you bad boy. ;)
--- End quote ---
The code works (blinks) on my clip and on the e200 of fragilematter.
EDIT3:
I attach proof of concept of a 1st stage bootloader which will run code stored in a hardcoded location. binary is 140 bytes, and may even be reduced to 136 if we remove the possibility for our 2nd stage to return to OF so it should fit in most firmwares.
Note: this code doesn't do anything useful yet except branching to a location where no valid code is so you don't want to run it, but I confirm it works on the Clip: I wrote a BX R1 instruction in this block before branching to it and OF booted.
/EDIT3
1) Yes I don't copy the ROM into RAM, I just assumed it was preloaded and it booted fine, but we may have to copy the whole OF.
2) It's just the best solution because writing code that overwrites the location of the PC would be a bit tricky. I assume after and before the mapping of RAM, the first 128kB are exactly the same data.
Maybe the soc bootloader copy ROM content into RAM at boot ?
I have booted my clip fine after sleeping the whole night, so I'm sure the RAM didn't keep its state :)
Also I didn't find a way to map both the RAM and the ROM at the same time (at different locations to be able to copy from ROM to RAM)
EDIT: in fact the ROM is mapped at 0x80000000 and 0xC0000000 so we can branch to this location, enable the RAM, copy the firmware to RAM, and continue, but if we an avoid it it's better.
EDIT2: simpler solution, the RAM is mapped at 0x81000000, I attach a proof of concept which copies the whole ROM into RAM before remapping RAM to 0x0.
Finally you think it's the worst thing to change the memory map before returning to OF but I remind you this code is meant to run with a potential bricking OF, and we have to put it in the right state before returning to OF (clear the memory area where we inserted the 2nd part of our code).
I know this is dangerous and this is why I commented the functions called by this first stage : "DO NOT TOUCH"
About the NAND & clock, I will assume that the pclk is 65Mhz and loop over the code that puts WE / RE nand pins to 1 long enough to ensure the minimal delay required by ONFI spec (mode 0)
Thanks for showing me the clock on the pcb btw, I'll go to sleep less stupid tonigh ^^
kugel.:
It was mentioned earlier in this thread, that most buttons are possibly on ADC, and not GPIO. Maybe we should also have a look at that.
BTW: My Fuze arrived, so I'll hopefully be able to help a bit. It'd be nice if I get can one of you into chat (I use pidgin, so nearly any protocol will be fine), so that I can get faster into this and be able to catch up a bit.
Edit: I'm failing to use linuxstb's amsinfo tool on the Fuze firmware. While the header is dumped without problems, the library blocks are messed up and cause a segfault. Either the tool is broken, or the Fuze firmware format differs. I fear it could be the latter one. Could you guys have a look on the fuze firmware (downloadable at Bagder's site)?
atomikpunk:
Yes sorry I was away for the day but I wanted to tell you that I'll have a look tomorrow. Until then, good night ;)
Edit: I looked at the fuze firmware. It looks like a valid firmware to me and with the same format as other V2. I'll give a look at amsinfo to see what the problem is :) But rest reassured, it IS (and its firmware IS) a v2 like all the others ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version