We are working on bring up EFI (http://www.uefi.org) on Beagleboard
rev C board. I am able perform read/write/erase operations on NAND.
Now, I would like to implement ECC mechanism. I have configured
GPMC_ECC_CONFIG, GPMC_ECC_CONTROL and GPMC_ECC_SIZE_CONFIG before each
read and write request. After actual read happens, I am reading
GPMC_ECC_RESULT register. Now, I am not sure how to calculate 3 bytes
ECC code for each 512 bytes data. I believe once I have 12 bytes of
ECC code (4 x 3 bytes for each 512-bytes), I have to write that data
to the spare area of that page. Can someone help me figure that out? I
checked OMAP3530 documentation from TI but it looks like it has some
high level information..
Thanks for your help and feel free to ask me more questions.
We are working on bring up EFI (http://www.uefi.org) on Beagleboard
rev C board. I am able perform read/write/erase operations on NAND.
Now, I would like to implement ECC mechanism. I have configured
GPMC_ECC_CONFIG, GPMC_ECC_CONTROL and GPMC_ECC_SIZE_CONFIG before each
read and write request. After actual read happens, I am reading
GPMC_ECC_RESULT register. Now, I am not sure how to calculate 3 bytes
ECC code for each 512 bytes data. I believe once I have 12 bytes of
ECC code (4 x 3 bytes for each 512-bytes), I have to write that data
to the spare area of that page. Can someone help me figure that out? I
checked OMAP3530 documentation from TI but it looks like it has some
high level information..
Hi Hardik,
You are right - This info is actually rather hard to find unless you want to
deduce it yourself from an already flashed working X-loader, by reading a
page and comparing the calculated ECC to the ECC stored in the spare area.
However, for every 512 bytes the relation goes like:
In case further help is needed I think you should ask TI for the OMAP ROM
Code Spec, which documents the format in every detail - Unfortunately it's
AFAIK not part of the TRM nor available to the public in general...
Søren Steen Christensen said the following on 05/28/2009 09:12 AM:
We are working on bring up EFI (http://www.uefi.org) on Beagleboard
rev C board. I am able perform read/write/erase operations on NAND.
Now, I would like to implement ECC mechanism. I have configured
GPMC_ECC_CONFIG, GPMC_ECC_CONTROL and GPMC_ECC_SIZE_CONFIG before each
read and write request. After actual read happens, I am reading
GPMC_ECC_RESULT register. Now, I am not sure how to calculate 3 bytes
ECC code for each 512 bytes data. I believe once I have 12 bytes of
ECC code (4 x 3 bytes for each 512-bytes), I have to write that data
to the spare area of that page. Can someone help me figure that out? I
checked OMAP3530 documentation from TI but it looks like it has some
high level information..
Hi Hardik,
You are right - This info is actually rather hard to find unless you want to
deduce it yourself from an already flashed working X-loader, by reading a
page and comparing the calculated ECC to the ECC stored in the spare area.
However, for every 512 bytes the relation goes like:
In case further help is needed I think you should ask TI for the OMAP ROM
Code Spec, which documents the format in every detail - Unfortunately it's
AFAIK not part of the TRM nor available to the public in general...
In case of further questions or comments please don't hesitate to ask
just posting off line comments i send to Hardik on this:
There are three stages:
a) ECC generation -> for each 512byte chunk 32 bit long ECC is generated
-> the actual ecc data though is 32 - 8 bits long - this is what you see
in ECC1 to ECC4 result regs. This generation is done by the GPMC
automatically based on ecc config configuration. for 2048 byte page,
you'd use ecc regs1-4 and ecc regs 5-8 will be used when you have page
size >2048 bytes. Another trick you can do is to reset the ecc for every
512 byte of data so you'd only use a single reg -> this is what i did
for u-boot code.
b) ECC storage - for rom code to understand the ECC, it finds that
storying 4 byte is a waste when the actual data is 3 byte long, so the
data you get from ecc regs need to be re-arranged to store in "OMAP rom
code format" when being written to spare area - this is what the
pointers I provided does. I hope this is the conversion you are talking
about. see [1] and [2]
c) ECC correction -> this is a simple hamming code correction logic
here. Also see: [3]
Thanks a lot to Soren & Nishanth for providing me good pointers.
I was able to generate the same HW ECC values as what x-loader currently has. Initially I was enabling HW ecc before I started sending address cycles and I was getting different ECC results but then I realized that I should have put this right before reading data from GPMC_DATA register and it worked… After reading 2K data, I can see GPMC_ECC1-4_RESULT registers are getting populated with right ECC contents as what x-loader currently has in its spare area.
Now, I have another question.
In my current setup, I am taking help from u-boot to flash EFI image (Replacing U-boot location on NAND (offset 0x80000) with EFI image) and because u-boot has flashed correct ECC values, x-loader is able to locate EFI image and booting it. Is u-boot using HW ECC when it flashes u-boot flash image? I think answer may be SW ECC because if I see the serial prints coming out when recovery happens, it prints SW ECC selected.
Hardik Doshi said the following on 05/28/2009 07:17 PM:
2) If it is using SW ECC then how do you calculate SW ECC? Any
pointers on that would be useful.
We follow a 2 stage boot process ->x-loader loads up u-boot. not that it
is necessary[1].. but then legacy things is a tough habit to get rid of
for a community :P.. anyways, s/w ecc is completely up in the air..
u-boot method is not same as anyone else's (except maybe - linux kernel,
since both u-boot and kernel use mtd[2] layer)..
For the specific logic on nand s/w ecc as used by u-boot, see [3]
[1]
