[E3-hacking] PBL and flash access on the E3

[Cliff Lawson]

> -----Original Message-----
> From: David Given [mailto:dg at 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