I to have problem with unreliable NAND-flash. I noticed that my board producer had changed the NAND-flash from
Toshiba TC58NVG1S3ETA00 to
Micron mt29F2G08abaeawp
but I am not sure this has led to increased number of defect boards.

My board only has 2 ECC bits per 512 bytes. The NAND data sheet says 4 ECC bits is minimum. I would like to change the ECC bits to 8 but I don't know how. At what point is the number of ECC bits set?
I have a sama5d3 xplained board. Is there somewhere instructions on how to increase the number of ECC bytes from 4 to 8 for that board?

The nand flash is defined in the following way in the dts file, sama5d3.dtsi.

Can anyone point me to any documentation about these parameters?
Or please explain the following parameters:
/* ROM code */ in reg <>
atmel,pmecc-lookup-table-offset
/* NFC Command Registers */
I am not sure my parameters are correct.

Replying to my own post. Should have found out earlier but it is in fact pretty easy to change number of ECC bits from 2 to 4 but I don't know how to change the number to 8.
At https://www.at91.com/linux4sam/bin/view ... 1Bootstrap I read that for 8 bit ECC the OOB should be set to 224 bytes and the offset to 120 but Sam-ba gives me an error of
"-E- Script error: -E- Pmecc header configuration failed!".
Is it possible to change the number of ECC bits to 8?

You seem to be exaggerating when you claim there is "a lot", but that article probably has the answer(s) you're looking for.

BTW that scheme by Ronetix does not include DTB images (although the DTB can be appended to the kernel with a penalty to flexibility). That omission plus the limitation/hassle of multiple kernel partitions can be solved by storing the kernel and DTB images within the root filesystem (i.e. the /boot/ directory), since U-Boot has the capability of reading files from UBIFS or JFFS2.
Ideally you want as much of the NAND to be part of the filesystem (or UBI volume) as possible (rather than as raw partitions) so that wear-leveling (and bad-block management) can be more effective.
Buildroot has the capability of installing the kernel and dtb in the rootfs image for you.

gudjon wrote:At what point is the number of ECC bits set?

AFAIK each program that uses the NFC (NAND Flash Controller) can/will configure the NFC for the PMECC parameters.
By "each program", I mean RomBOOT, AT91Bootstrap, U-Boot, the Linux kernel, and SAM-BA.

gudjon wrote:I have a sama5d3 xplained board.

This could be part of your problem.
You claim to be using an Atmel board, yet also state that you have NAND chips that are not used by the Atmel reference board.
Both claims cannot be true!
Nor will a specific solution work for all cases.

If you have a custom board or a board that is not 100% compatible with an Atmel reference board design, then stop calling it an Atmel board. Do not use an Atmel .dts file as your Device Tree. Instead write a new .dts file for your board.

gudjon wrote:Is there somewhere instructions on how to increase the number of ECC bytes from 4 to 8 for that board?

Did you study the Ronetix instructions?

gudjon wrote:The nand flash is defined in the following way in the dts file, sama5d3.dtsi.

(You're conflating the .dts file type with the .dtsi file type, which is sloppy thinking. A .dts is like a .c that contains main(), whereas .dtsi are included files like .h.)
That particular .dtsi file is the description for the generic SAMA5D3x SoC, and usable by any board that has that SoC installed.
The lines you show are for the NAND interface and the NAND Controller of the SoC, not a specific NAND storage chip installed on a board.
PMECC parameters would be properties associated with a specific NAND storage chip, which would be declared in a board-level DT file.

gudjon wrote:Can anyone point me to any documentation about these parameters?

Look in the kernel source: Documentation/devicetree/bindings/mtd/atmel-nand.txt
Beware that this documentation does not bother to distinguish between SoC-level properties and board-level properties.

gudjon wrote:Is it possible to change the number of ECC bits to 8?

Since I have not actually done it, I don't have a definitive answer.
But if you claim you have an Atmel reference board, but you actually do not, then SAM-BA is probably not going to do the right thing for you.
I don't know for sure, but to me, it looks like SAM-BA has hardcoded the NAND Header Value for each (Atmel) board.
You probably need to study section 11.4.4.1 NAND Flash Boot: NAND Flash Detection / NAND Flash Specific Header Detection in the SAMA5D3 Series datasheet, this section of the link you mentioned, and this thread.

In my production system I use Shiratech AT-501 board but I also have a Sama5d3_xplained to play with. Shiratech changed the NAND flash from Toshiba to Micron. As far as I can see the Micron NAND flash is exactly the same as in sama5d3_xplained but the pullup resistors in the Shiratech card are 470kOhms instead of 100kOhms which I think is irrelevant.
I mentioned the Xplained board because there is a larger probability that somebody has made 8 bit PMECC on that board.

The NAND definitions from sama5d3.dtsi seem to be the ones that are used. These have changed since kernel 3.10, I am using version 4.4.

gudjon wrote:The definition from 3.10 is:
...
Do both definitions apply to the Micron mt29F2G08abaeawp chip?

That looks to be the same DT nodes as your previous post, therefore I would have the same response as before.

gudjon wrote:1. Is there any documentation on how to boot from a kernel within the ubifs? I have tried and failed.

Don't go off-topic; start a new thread for a new topic.

gudjon wrote:Has anyone managed to use 8 ECC bits on sama5d3_xplained? Changing between 2 and 4 is no problem but using 8 doesn't work. I guess the OOB area must be resized but I don't know how to do that.

U-Boot can dump the OOB bytes.
That's what I used the last time I had to figure out the proper offset.

While looking at AT91Bootstrap for another question, I noticed that you probably have to do some custom configuration, i.e. use `make menuconfig`. Since you want to use more than the minimum number of ECC bits, then you probably have to disable "Auto-detect ONFI minimum error requirement", which then allows specification of "PMECC Error Correction Bits".

If I was doing this, I would divide and conquer the problems. First build a custom version of AT91Bootstrap (with 8 bits of ECC) to load U-Boot from NAND, but install the boot.bin binary on SDcard instead of NAND. Use SAM-BA with modified PMECC configuration to write the U-Boot image to NAND. Then focus on getting AT91Bootstrap (from SDcard) to load U-Boot (from NAND). Once you have a working AT91Bootstrap, then work on booting it from NAND.

BTW the NAND on the SAMA5D4 XULT uses 8 bits of ECC, but that's the chip's minimum requirement.

gudjon wrote:But I get the following error message in Sam-Ba (version 2.18).

You could look at the source code for SAM-BA to determine why you're getting that message.

If I was doing this, I would divide and conquer the problems (and abandon SAM-BA).
First build custom versions of AT91Bootstrap (to load a U-Boot from SDcard) and U-Boot (with 8-bit ECC capability and CONFIG_CMD_NAND_TRIMFFS enabled), and install the boot.bin and u-boot.bin binaries on SDcard.
Boot from SDcard and get this U-Boot with modified PMECC configuration to erase, write, read and verify NAND flash.
Then use this custom U-Boot to install another new AT91Bootstrap (with 8-bit ECC capability and to load U-Boot from NAND) and U-Boot to NAND.
First focus on booting AT91Bootstrap (from NAND) to load U-Boot (from NAND).
Once you have that working, then use U-Boot to install the rest of the images to NAND flash.

For installing the AT91Bootstrap image to NAND flash using U-Boot, see these instructions.