Hello,
I was following instructions from the following link:
http://processors.wiki.ti.com/index.php/How_to_Flash_Linux_System_from_U-boot
On looking at the section "Run the u-boot commands to flash the NAND",
within the sequence of uboot commands entered there is "nandecc hw"
and "nandecc sw". What do these commands do and what is the difference
between "hw" and "sw" ?
Thanks,
VIjay
TheLoneJoker wrote, on 11/04/2010 06:50 PM:
Hello,
I was following instructions from the following link:6.1.6. How to Flash Linux System from U-boot — Processor SDK Linux for AM335X Documentation
On looking at the section "Run the u-boot commands to flash the NAND",
within the sequence of uboot commands entered there is "nandecc hw"
and "nandecc sw". What do these commands do and what is the difference
between "hw" and "sw" ?
ECC stands for Error Correction Code[1] - to simplify it, for x bits of data, we generate y bit code- which allows us to correct one bit flipped OR detect (but not correct) upto two bit errors. the typical s/w implementation until sometime back has been - s/w algos in MTD layer - used in both u-boot and kernel, had one ecc stored for every 256byte of data. this means that for every data we read, s/w needs to crunch it to generate the ECC code, in omap3 h/w GPMC (the controller that talks to the NAND part), has it's own ECC generator - this generates ECC for 512bytes -
Reliability comparison:
using "s/w ECC" as done by MTD, you can detect upto 2 bit errors and correct upto 1 bit per 256byte data
using "h/w ECC" as done by GPMC, you can detect upto 2 bit and correct upto 1 bit per 512byte data
Performance comparison:
s/w ECC both generation(during writes) and verification(during reads) requires intensive CPU operation - increases latencies.
h/w ECC in comparison just requires register read to collect the ECC data.
this ECC data is stored in the spare area (or in MTD terminology oob area) per page of NAND data - the amount of ECC data obviously is larger for s/w ecc in comparison to h/w ECC for a given page size of data.
Further bootrom in OMAP3 only understands h/w ECC with the ECC stored in a specific offset in spare area - so there is no option, but to use h/w ecc for x-loader. choice of ecc for u-boot and kernel now-a-days has been more to use h/w ecc for performance reasons..
[1] Error correction code - Wikipedia
Regards,
Nishanth Menon
But which component does the ECC verification ? I was of the
impression since, Uboot is the one moving around the "images", Uboot
would be responsible for the same. Please correct me, if I have a
wrong understanding of the setup.
Thanks,
tlj
But which component does the ECC verification ? I was of the
impression since, Uboot is the one moving around the “images”, Uboot
would be responsible for the same. Please correct me, if I have a
wrong understanding of the setup.
Whoever is reading the data is responsible for checking the ECC. When writing to flash U-boot generates the ECC as Nishanth explained.
Then why is it that, the “bootrom” does a “hw” ecc verification for the xloader… ? Wouldn’t Uboot while writing the xloader image verify the xloader image as well ?
Thanks,
Vijay
Then why is it that, the “bootrom” does a “hw” ecc verification for the xloader… ? Wouldn’t Uboot while writing the xloader image verify the xloader image as well ?
Because one of the lovely features of NAND flash is that it may develop bit errors later. So the reader must always check the data using the provided ECC and correct possible bit errors.
Then why is it that, the “bootrom” does a “hw” ecc verification for the xloader… ? Wouldn’t Uboot while writing the xloader image verify the xloader image as well ?
Because one of the lovely features of NAND flash is that it may develop bit errors later. So the reader must always check the data using the provided ECC and correct possible bit errors.
- Juha
This helps give me more clarity. Thank you.
Vijay
Hi
I am trying to find Sunspider benchmarks on Android OMAP any idea where to download these
|