[E3-hacking] Config / content filesystem

Wed Apr 24 19:23:56 BST 2019

I  think it needs the OOB data in the image.
Just looked on the net about ,it say…

How does this combination of nandsim, nandwrite and nandddump decide which ECC scheme to use? The flash is from a TI AM335 system, and as far as I know, the ECC scheme is decided by a combination of the processor and OS. How do these utilities know what to do?

First of all the ECC scheme used does not necessarily have to be for all the flash erase blocks. There are ususally 3 different types of flash partitions used and for every type the method to specify the used ECC code differs:

  1.  The one that are accessed by the ROM bootcode
  2.  The ones that are accessed by the bootloader (usually u-boot)
  3.  The ones that are accessed by the operating system (assuming you are using Linux)

In general the use of a specific ECC method is limited by the OOB size of the flash. The AM335x_U-Boot_User's_Guide (cannot post link here because of reputation) explains it in sections BCH Flash OOB Layout and the example matches to the flash chip you are using. The 64 bytes per 2k page effectively limit the usable ECC algorithms to BCH8, BCH4 or HAMMING codes.

BCH Flash OOB Layout

For any ECC scheme we need to add some extra data while writing so as to detect and correct (if possible) the errors introduced by the NAND part. In case of BCH scheme some bytes are needed to store the ECC related info.

The section of NAND memory where addition info like ECC data is stored is referred to as Out Of Band or OOB section.

The first 2 bytes are used for Bad block marker – 0xFFFF => Good block

The next ‘N’ bytes is used for BCH bytes

N = B * Number of 512-byte sectors in a page

B = 8 bytes per 512 byte sector in BCH4 B = 14 bytes per 512 byte sector in BCH8 B = 26 bytes per 512 byte sector in BCH16

So for a 2k page-size NAND flash with 64-byte OOB size, we will use BCH8. This will consume 2 + (14*4) = 58 bytes out of 64 bytes available.

ECC used by ROM bootcode

The AM335x processor's ROM bootcode decides which ECC scheme to use for NAND flash depending on the mechanism expalined in the AM335x technical reference manual chapter 26.1.7.4 NAND

ECC Correction The default ECC correction applied is BCH 8b/sector using the GPMC and ELM hardware. For device ID codes D3h, C3h, D5h, C5h, D7h, C7h, DEh, CEh when manufacturer code (first ID byte) is 98h the Cell type information is checked in the 4th byte of ID data. If it is equal to 10b then the ECC correction applied is BCH 16b/sector. In addition ECC computation done by the ROM can be turned off completely by using SYSBOOT[9]. This is particularly useful when interfacing with NAND devices that have built in ECC engines.

Other ways to control the ECC behavior are ONFI or and I2C EEPROM but the H27U1G8F2BTR datasheet does not mention ONFI so I guess it is not supported by the flash chip.

So basically BCH8 or BCH16 or no ECC mechanism is used for the first 128K the ROM bootloader reads from NAND flash.

ECC used by the bootloader

The bootloader decides this on his own. For example for U-boot this information is compiled into u-boot and the first level bootloader (SPL/MLO) as well. The information is controlled by U-Boot configuration settings set at compile time. Recent versions of U-boot can switch the ecc at runtime using the nandecc command.

ECC used by the OS

The selection is completely OS specific. For Linux embedded systems using AM335x processors I know that this information is passed into the kernel using the device tree.

Which ECC method does nandsim use

There is a parameter called bch which can be passed to the nandsim module to select an ecc code. From the code I guess It is initialized to zero so it won't use any ECC code. So it seems that nandsim can use BCH8 and BCH16 but only one for the whole flash that is simulated.

modprobe nandsim bch=8 first_id_byte=0xad second_id_byte=0xf1 third_id_byte=0x00 fourth_id_byte=0x1d

Which ECC method does nanddump/nandwrite use

Again, this depends on the OS/Linux you used to dump the flash. Similar to the nandsim module real mtd drivers have ways to specify the used ECC scheme (kernel parameters, device tree). But you can instruct nanddump to ignore the ECC information, too.

References

  *   AM335x technical reference manual http://www.ti.com/lit/gpn/am3359
  *   bch Linux Kernel parameter for nandsim http://lxr.free-electrons.com/source/drivers/mtd/nand/nandsim.c#L175
  *   The AM335x_U-Boot_User's_Guide

Spanner..

http://amstrad-e3-hacking.freeforums.net

From: Ralph Corderoy<mailto:ralph at inputplus.co.uk>
Sent: ‎Wednesday‎, ‎24‎ ‎April‎ ‎2019 ‎18‎:‎30
To: Discussion of the Amstrad E3 emailer hardware/software<mailto:e3-hacking at earth.li>

Hi Nick,

> I copied it twice not

What's the output of copying it once?

> Amstrad Delta - PBL V4.9 Build:1311 Assert Debug ICE
> PBL 32MB NAND
> 0MB.-->MEMv01.00.002,CopyLim=00220000h,CodeEnd=01400000h-->PBL......1MB.......2MB*

What if you try reading out the flash.  Do you get what you put in?
`cmp foo bar' compares all the bytes in those two files and complains if
any differ.

Otherwise, I think you'll have to wait for someone that knows mtd to
come along and offer suggestions.

--
Cheers, Ralph.

_______________________________________________
e3-hacking mailing list
e3-hacking at earth.li
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.earth.li%2Fmailman%2Flistinfo%2Fe3-hacking&data=02%7C01%7C%7C7e771ee689d44d2e2a3708d6c8da91b3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917238407255934&sdata=9aSwi%2FcYoSJiQxT3YOnLEpBnflwfq4pKUlBKp8J2rus%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.earth.li/pipermail/e3-hacking/attachments/20190424/9b68c63b/attachment-0001.html>