
Dear Ilya Yanok,
On 15.11.2012 21:08, Ilya Yanok wrote:
Dear Andreas,
On Thu, Nov 15, 2012 at 2:25 PM, Andreas Bießmann <andreas.devel@googlemail.com mailto:andreas.devel@googlemail.com> wrote:
Dear Ilya Yanok, On 07.11.2012 00:06, Ilya Yanok wrote: > From: Mansoor Ahamed <mansoor.ahamed@ti.com <mailto:mansoor.ahamed@ti.com>> > > This patch adds support for BCH8 error correction code to omap_gpmc > driver. We use GPMC to generate codes/syndromes but we need ELM to find > error locations from given syndrome. > first of all, I wonder why this is so different than the kernel implementation for BCH. I mean the API (and content) of this and commit 8d602cf50d3bba864bc1438f486b626df69c87b3 mainline linux seems to differ. The main question coming to mind is: Is the resulting OOB layout compatible then?
Please note that these patches are AM33XX-specific (as we are using ELM that, I think, just isn't available on OMAP3) so we use OOB layout that is compatible with AM33xx ROM boot code.
You are right, ELM is not available in OMAP3 devices. It seems the ROM loader of these devices only support the 1-Bit Hamming, but is also different to the OOB layout used for the SW 1-bit hamming provided by the Kernel. So we get here a lot of different OOB layouts ... I wonder if we can stick to e.g. the generic SW BCH layout (of linux kernel) for all but the ROM partition (where the SPL is placed). So the SPL need to know just one mechanism but software modifying that place needs to know about the 'special' ROM layout.
It's likely that this layout doesn't match with the current kernel layout as RBL uses strange 14th byte for BCH8 while only 13 bytes are needed.
Sorry, what does RBL mean in that context?
There are some patches for the kernel that make it use the same layout too but I don't if they are going to be accepted soon.
Ok, that would be required to write the SPL to flash.
Actually, the only assumption the code does about the OOB layout is that ECC code occupies continuous area in the OOB.
Well, but you have defined that for example it is written in big endian.
I'm currently working on a omap3 enabled device that requires 4-bit ECC for all but the first block. And I'm searching for a clean solution that would be accepted mainline. I think it would be best to have the same OOB layout for the whole device but the SPL space (cause that needs to be read by ROM). The layout should be chosen at compile time of the SPL. What do you think about?
Best regards
Andreas Bießmann