Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
atomikpunk:
Hi again peeps,
Yeah I'm wondering, anyone knows more than I do about "metal ECO redesign"? Because the only way everything we've found about the NAND SD interface up to now suppose that a "spare" register, described as being "used for metal ECO redesign if needed" is used just prior to using the NAND flash register as we would with the Arm PrimeCell PL180... And this is quite surprising since this register should not have been like the PL180 at all, so this is what makes me think that the NAND registers on the sandisk AMS3525 SoC could have been "upgraded" with a second PL180 interface which would be selectable by using one of those spare register...
As for the FAT driver, well yes, we would need a very compact and truncated version, simply allowing one to find a specified file name and read it. We probably wouldn't need directory support, write support nor anything like that. The idea is to load a minimal bootloader that can load a full-blown rockbox firmware from the NAND, nothing fancy since we are quite short (for the moment?) on code space. And about this limitation, we should think about switching to thumb mode soon...
funman: I did some more analysis tonight and found that the NAND supply voltage is 3.0V, selected in the power register using the power value 0xA. In fact, the formula is: voltage = 2.0V + power_value * 0.1V.
About your try to work with the flash, maybe you can send me your code so I can take a look?
Have fun peeps, more to come when we'll have more time ;D
dan_a:
--- Quote from: funman on September 18, 2008, 02:25:18 PM ---
--- Quote from: Bagder on September 18, 2008, 01:53:17 PM ---Rockbox already has all the fat32 filesystem code you need of course...
--- End quote ---
I am not sure it fits in the 1kB of our code segment, aside with the sd driver, so I think we must go we the minimum.
I don't know filesystems but I think we can remote at least write support, recursive directories traversal, and maybe more ..
--- End quote ---
I've just done a very simple stripping out of the write functions from fat.c, and that reduced its size when compiled from 22k down to 9.7k. Getting down to 1k including the SD driver will be quite challenging.
Bagder:
Regarding the need for small code sizes.
Can't we just decide on a part of the OF that we can "sacrifice" (at least for now) and overwrite with bootloader code and jump to that from the tiny snippet we inject?
funman:
Not really since we only have 128kB in ROM and e200 testers showed that we can't use the last bytes of the ROM, but only the last bytes of the 0x200 bytes block of the firmware
EDIT: I forgot to mention that the code in ROM contains the basis of OF and I think we just can't 'sacrifice' this code.
If we modify the parts past 128kB, they stay on NAND and are loaded afterwards by the code present in the ROM.
Maybe the Sandisk logo we see at boot can be modified to contain code? 128x64 / 8 = 1 more kB
But I don't even know if it's in ROM or in upper parts of the OF.
EDIT2 (I shouldn't press Post that fast):
I have thought about something else in the last days: if full FAT support can not be made, we could use a tool to modify the filesystem, and then in our bootloader assume a fixed location on the hard disk for the firmware (i.e. allocate a file at the very beginning of the partition for our rockbox firmware).
EDIT3 : or we can partition the disk and put a magic word in the first partition, so we know exactly at which offset to look for our firmware : much simpler because we avoid FAT
atomikpunk:
I know this may look a bit stubborn (ok, it is a lot...) but what about trying your mkamsboot patch (see this message) not using 0x100 blocks of 0x200 bytes, but 0xFF blocks instead. Because I really feel like the "firmware block size" field may be a byte and not a word...
As for the sandisk logo, well in the m200 version it was in a (far away) library block, so probably the same for all V2s. This means nope, not available until the NAND is accessed...
As for the filesystem hacks, well yes that could work. I'd rather go with a "more elegant" approach if we can, but that could do the trick. We must take care however not to overwrite the firmware (that is located somewhere on the NAND).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version