Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
atomikpunk:
--- Quote from: funman on September 03, 2008, 01:24:41 PM ---When it's done no need to look in the library blocks, since we have access to the whole NAND and its FAT32 filesystem.
--- End quote ---
Well it all depends on if we can grow the firmware size or if we can fit the NAND driver in the (little) space we have at the end of the firmware block... 'Cause I suspect it (the NAND driver) to be too large but that a library copy routine be small enough to fit in.
Or maybe there is something that's allows different ROM "pages" to be mapped in and out on demand?
funman: In the mail I sent you yesterday night, you should have the address of the library routine in the clip firmware, you may want to look at that...
funman:
I was more interested by the gpio function ;)
Now that I took a look at this function it looks like strcpy(), do I miss something ?
EDIT: sorry I was reading disassembly in thumb, and the function just branched to another offset which is strcpy, I'll disassemble it as 32 bits instructions.
fragilematter:
I've finally managed to map GPIOB on e200v2's. It looks like this:
--- Code: ---GPIOB_pin0 #0
GPIOB_pin1 #1
GPIOB_pin2 #0
GPIOB_pin3 #0
GPIOB_pin4 power
GPIOB_pin5 #0
GPIOB_pin6 #0
GPIOB_pin7 #1
--- End code ---
I was starting to think there was something wrong with the way I tested, because I didn't find any buttons by now, but it seems that it's OK. I'll post the rest of the GPIOs when I'll finish testing.
Edit:
--- Code: ---GPIOC_pin0 #1
GPIOC_pin1 #0
GPIOC_pin2 #1
GPIOC_pin3 #1
GPIOC_pin4 #1
GPIOC_pin5 #1
GPIOC_pin6 #1
GPIOC_pin7 #0
--- End code ---
The GPIOs that are !=0 are consistent with the ones identified as DBOP (LCD display) in the M200 V2 version 4.1.8a firmware analysis from the wiki (http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware#GPIOs_Usage).
Edit2:
--- Code: ---GPIOD_pin0 #1
GPIOD_pin1 #1
GPIOD_pin2 #1
GPIOD_pin3 #1
GPIOD_pin4 #1
GPIOD_pin5 #0
GPIOD_pin6 #0
GPIOD_pin7 #0
--- End code ---
It looks like the e200v2's only have the power button directly on the GPIO. Either that or my tests were flawed somehow.
funman:
Hi guys
I have found a way to extend the allowed size for the bootloader: use memory areas filled with the same word.
I quickly checked for 0x200 sized blocks, and only the Clip firmwares show 1 or 2, so you need to
verify that first.
EDIT:
I also attach a tool to check the size and location of the biggest memory area filled with the same byte, it seems there is room in every firmware :)
Also I attach a new version of test.S without a bug in button check: the result was stored in r2 but calling clean would modify it (luckily it didn't brick my clip)
/EDIT
We don't know if they are important for the OF, so we memset it before giving it the hand.
I attached test.S tested on Clip firmware v17, the size won is 0x3CC bytes where we can put functions, data, etc ..
Of course before doing that we have to map the RAM at 0x0 because at init only the ROM is mapped.
Note this is a bit hacky to use because you have to write separate assembly code, assemble it and merge it manually at the needed offset, and hardcode the offset/size/value in test.S ... but this will do for now.
Maybe we can modify mkamsboot/Makefile to assemble 2 different files, and look in the memory for a block large enough, then insert the value/size/address in known (by the assembly code) memory locations, like the original entry point is stored now.
By the way I'm still writing a basic driver for the NAND flash, but now I'm stuck on delays: we need to command the WE bit (write enable) and keep it high for minimum 50 ns
The interface for this bit in the AMS3525 is 4 bits which will keep it high for x+2 PCLK# cycles where x is the 4 bits value.
But I've read that the PCLK is 65Mhz, so that means keeping WE high for 17 cycles would last less 0.3 ns ..
I think we need to use a divider for the pclk, but a big divider means reduced CPU clock??
atomic punk: I have found the function which load library blocks; it takes 4 arguments: block name (string), base address, end address, size. But it was not at the same offset, maybe we are not reading the same firmware ?
I am disassembling v29 for Clip
atomikpunk:
Ok well I guess it's time for me to write :P
That's a good idea funman, I like. Even though it is risky, we now have at least one valid solution. I'm pretty sure that that needs to be set back to their original value giving the OF firmware the hand because they may be variable initialization values.
As for the button detection stuff, I strongly suggest that we don't make any change to it, at least for now. We wouldn't want to brick any more device, don't we?
For the NAND driver, I would reiterate what kugel said about that task on the bug tracker (http://www.rockbox.org/tracker/task/8843). Most of the NAND driver should be there, ready for us to use.
And hmm, how come you're speaking about a 65MHz clock? Isn't the oscillator a 24MHz? Or is there a frequency multiplier circuit in the SoC?
And about that library loading routine, would you mind refreshing my memory as to its address? I have probably looked at the wrong routine as I did not put much time yet into the clip firmware. Owh, and are you sure that the RAM isn't mapped at boot? If not, there is probably a simple way to map it. There seems to be a "remap" register somewhere I just can't remember where for now, I'll read back the doc.
Great progress guys, I hope for a nice bootloader in the upcoming days or weeks ;D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version