[HTC Wildfire S] Antagonist42:
Erm could it? maybe?

This is just going to blurt out as it's skimming through my head so hold on tight :D

NAND - pages/blocks etc are a fixed size, the erasesize is set to NAND usable/addressable size so if a page.... this -->>> The 12-bit column address is capable of addressing from 0 to 4,095 bytes on a x8 device;

however, only bytes 0 through 2,111 are valid. Bytes 2,112 through 4,095 of each page are “out of bounds,” do not exist in the device, and cannot be addressed. <<<-- or can they? maybe not addressed but written in and read out as a NAND bit location through either mARM as this is running a lower system OS (no need for us mere humans to interfere) or as with hboot etc a page size may be set to 4096 but the actual erasesize remains 2048 - 2049 to 4096 there may be no need for ECC, if there is then it's for the badblock addressing written to the oob area or other.... sooo would it not be possible to set the erase size to 2048 then write in 4096 would the extra 2045-4096 be written to the oob area even if the 2048 to be flashed was given the 2048 NAND area to flash would it continue to write to the oob area and not the NAND's next sequential address?

A bit like your file is 4096....NAND area is 2048 (+ oob 2048)

we specify address area to flash ONLY for the 2048

then send the file that is 2048 along with 2048 we want in oob

if the NAND reports it didn't write then do we assume it didn't or just that it doesn't know as it can't address the area but could maybe still write to it?

1 Page = 2048 + 64

You also have ......

2048 + 64 Data Register

2048 + 64 Cache Register

Unless I got the description wrong then it would only be 2 or 1 of the 2048 as above :confused: but as I read it there is actually 3X the amount of memory but only 1/3 as usable addressable Data for the consumer, the rest is used for registers and cache probably by the NAND MMU otherwise how can the amount of memory remain as in this -->>> This NAND Flash device is specified to have the minimum number of valid blocks (NVB) of the total available blocks per die shown in Table 21. This means the devices may have blocks that are invalid when shipped from the factory. An invalid block is one that contains at least one page that has more bad bits than can be corrected by the minimum required ECC. Additional bad blocks may develop with use. However, the total number of available blocks will not fall below NVB during the endurance life of the product. <<<-- :( sooooo unless there is more memory available to keep this ratio then it would fail at the factory wouldn't it if it had enough bad blocks? Or set it to 1 then once you only have 1 block left then you've had it even though you could still have most pages ok it's the blocks it's counting as bad not pages:confused:

and makes me think this way as with this -->>> Nand interface:

For yaffs to function, it must be able to be the only code that writes to the oob area on the NAND device.

The existing NAND driver in kernel 2.4.19 assumes that it will do the ecc/oob management for the host fs. For yaffs, this is quite wrong.

You can disable ecc/oob calculations either by hand patching the mtd code to bypass ecc calculations or by merging the latest mtd cvs. <<<-- from here.

Otherwise where would the badblock pointer/address (whatever the appropriate term) reside so Joe Blogs can't corrupt it? and where better than the least amount of used (write-erased area) NAND :rolleyes:

Question - Can yaffs/yaffs2 be run by REX? or can yaffs be ran as it's own thing before OS kicks in?

This makes me think that....

1. Flashing NAND could be done indirectly by flashing to what would be oob, running ECC against USER NAND area and updating USERS area from the oob area we flash in so essentially we FLASH the CACHE then write the CACHE back into NAND then on reboot CACHE verifies NAND (CACHE as in either in RAM or NAND AREA or oob wherever it resides).

2. aARM and mARM need to access NAND and if those addresses fall maybe not in an area they are allowed to access unlike say mnt - mtdblock then passing a request from say aARM to NAND, NAND to IMEM, mARM didn't make the request so access' the required location in IMEM (for mARM's point of view just a 1 or 0 answer not what it is for) and mARM passes the result back to NAND as 1 or 0, the NAND processes and allows or doesn't, aARM receives 1 or 0 - do or don't.