-----Original Message----- From: David Given [mailto:dg@cowlark.com]

Next thing is to try and get the flash code up and running; but I'm a little hesitant to play because I don't want to overwrite anything crucial and brick the device. *Is* there anything crucial in the NAND flash? I notice that the MTD partition table has a chunk marked 'Amstrad Block'. Does it matter if I overwrite this? Plus, am I right in that the e3's NAND flash pseudoaddress is 0x400000, instead of the e2's 0x8001000?

{ FSH_ALGORITHM_SMART_MEDIA, PBL_FLASH_DATA_BUS_WIDTH_8BIT, PBL_VPP_CALLBACK_NULL, 0x00400000UL, 0x01000000UL - (0x00400000UL + MFS_RESERVED_BAD_BLOCKS), 0x00000000UL, 0x00000000UL }

So, yes, 0x00400000UL

As for whether there's anything "crucial" in it or not the answer is yes and no. On the one hand the 37K PBL lives in a completely separate NOR flash (it has to so it is address/data accessible to the CPU at boot time - unlike Nand which is just serially accessed) so you can blitz the entire Nand if you like and then put it back afterwards using the PBL. So you can't "brick" the thing.

However there is something in the Nand that I'd call "crucial" myself - bad block info. When the manufacturer makes Nand they don't guarantee all sectors in the device (apart from boot block sectors at the start or end). But what they do is factory profile each device and any "unusable" sectors in it have a special pattern of a sea of 0xFFs interspersed with the odd 0x01. That's how the device comes from the factory.

On the very first occasion that the PBL tries to mount it, it looks at the sectors near 0 for a "media descriptor" that we might previously have put there if the device has already been used. If it finds a media descriptor and validates it then it continues on to provide r/w access to the device. If neither of two possible copies of MD marked "valid" (check summed and stuff) is present then the device is considered "virgin" and the PBL therefore goes into a "format" routine. The purpose of this is to scan every sector and look for those with the sparse 01's in FF's signature. As it finds them it builds a bad block map which is written into the MD sector (as with most of the important stuff in flash (MD, Block Allocation Map (BAM), directories) we keep two alternating copies of these things to provide power-removal protection during writing. A new copy is written to the "other" position and then the final "alive" byte is only written once the rest of the write has succeeded - so the MD can be found in one of two places.

When the device is mounted a copy of the bad block table is loaded to RAM and, for each entry, a "remap" sector from an area towards the end of the device is used to replace it. When the PBL writes to Nand it does the writes via bad block remapping so you may think you are writing a continuous 4MB file to adjacent sectors but odd ones are actually located out of sequence in the remap area (and those sectors themselves could be bad and will also have been remapped to other sectors!)

So if you take a complete image of the device including the bad sectors and then put it back later you should be OK. But if you just wipe the device and start writing to random sectors you may be writing to bad blocks. Now we don't ever write to the bad sectors ourselves (cos we know they are bad!!) so they will still have the factory pattern which could be scanned for but if you just loop through the device doing 0x60 commands to erase sector1, erase sector 2 then you might just wipe all know all knowledge of where the bad blocks are. If OTOH you use the PBL "erase" command then it, of course, DOES know to avoid the bad ones.

So it kind of depends on what you are planning to do. If it's to use a Linux MTD driver that "knows" the Nand then I'm guessing that it has a strategy for locating the bad blocks when it first initialises the device too so should know about the FF-01 sectors and as long as it gets access to the device while they're still there then everything should hopefully be hunky-dory.

You may wonder what happens to flash devices that have been "used" and stored user data that includes sparse 01 in FF data - we know from experience that the PBL sees these as more bad blocks (and if you keep running software that writes such data and then re-"format" the flash the amount seen a bad increases

So the idea with Nand is that you only really should "format" it the once - scan it for bad, build your avoidance tables and then never repeat the process.

Cliff

This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries.

For further information on Amstrad Plc please visit our website: www.amstrad.com

Amstrad Plc. Brentwood House 169 Kings Road Brentwood Essex CM14 4EF Registered in England : No. 955321