Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (46/386) > >>

funman:
I am still looking at how to read from the NAND.
I had a look at the AMS3525 datasheet and firmware/target/arm/ata-nand-telechips.c but I'm not sure how to do that.

So far I suppose there is no direct mapping of the NAND into memory, and we have to issue commands to the nand.
I found the register to read unbuffered data from the ram (NAFDATA), but not how to set from which address we want to read.

EDIT: in fact we have a 16 bit register from where to read / write,
so we first use the command 0x0 (READ)
then write the columns of the memory address we want to read from,
then the rows
then we use the command 0x30 (READ, part 2),
then when the nand signals us it's ready, we read from this 16 bits register.

Hint: keep the ONFI specification handy

EDIT2:
fragilematter to generate a bigger firmware, you can modify mkamsboot.c:
line 185, replace

--- Code: ---new_paddedsize = PAD_TO_BOUNDARY(firmware_size + bootloader_size);
--- End code ---
by

--- Code: ---new_paddedsize = PAD_TO_BOUNDARY(firmware_size + bootloader_size) + 0x200;
--- End code ---

kugel.:
I just wanted to remind you guys on this task: http://www.rockbox.org/tracker/task/8843

The file contains a lot of code already (and thus information).

E.g. much of NAND driver work.

atomikpunk:
I had an idea tonight but didn't have time to implement it yet. We said we could increase the firmware block size and use this to put some more code, but why not insert our code in a low usage library block? For example on the clip, the first library block uses 0x12270 bytes out of 0x28000 allocated library block bytes. That leave's us 0x15D90, or in decimal for humans like I think I am: 89488 bytes. I think that ~90k is more than enough to pour in a bootloader ;D

The only catch is the fact we will need to load it into RAM before being able to actually use it, but hey, a library loading routine should be way smaller than a FAT-on-a-NAND library loading routine(s).

kugel: thanks for the reminder, I did take a look a long time ago but now it is much more pertinent :)

kugel.:
I think this idea came up earler and was rejected for 2 reasons:

I'd reduce capabilities to use the OF (we don't want to destroy the OF, but rather replace it and offer dual boot)
We would boot in a state where the OF already initialized the/some hardware. Booting Rockbox in such a state would make it dependent on the OF and possibly lead to unexpected behavior.

atomikpunk:
I'm sorry maybe I wasn't clear enough in my post. What I meant is to use "unused" library space in the firmware file (space filled up with 0xFF or DEADBEEF-padded junk) to put in our code. This wouldn't change anything in the OF since, to my (limited) knowledge, this space is simply not loaded at all by the firmware.

Navigation

[0] Message Index

[#] Next page

[*] Previous page