From: Peter Korsgaard <jacmet@sunsite.dk>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 6/8] omap_gpmc: BCH8 support (ELM based)
Date: Fri, 16 Nov 2012 16:59:30 +0100 [thread overview]
Message-ID: <87txspy1wd.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <50A61446.4070003@gmail.com> ("Andreas Bießmann"'s message of "Fri, 16 Nov 2012 11:24:06 +0100")
>>>>> "Andreas" == Andreas Bie?mann <andreas.devel@googlemail.com> writes:
Hi,
>> 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.
Andreas> You are right, ELM is not available in OMAP3 devices. It seems
Andreas> the ROM loader of these devices only support the 1-Bit
Andreas> Hamming, but is also different to the OOB layout used for the
Andreas> SW 1-bit hamming provided by the Kernel. So we get here a lot
Andreas> of different OOB layouts ... I wonder if we can stick to
Andreas> e.g. the generic SW BCH layout (of linux kernel) for all but
Andreas> the ROM partition (where the SPL is placed). So the SPL need
Andreas> to know just one mechanism but software modifying that place
Andreas> needs to know about the 'special' ROM layout.
No, please not. Having more than 1 OOB layout on the same NAND device
leads to all kind of complications. There has also been kernel patches
posted for the ELM, so IMHO the only sane option for am33xx is BCH8
everywhere (with the 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.
Andreas> Sorry, what does RBL mean in that context?
The ROM boot loader, E.G. the part loading the spl.
>> Actually, the only assumption the code does about the OOB layout is that
>> ECC code occupies continuous area in the OOB.
Andreas> Well, but you have defined that for example it is written in
Andreas> big endian.
Andreas> I'm currently working on a omap3 enabled device that requires
Andreas> 4-bit ECC for all but the first block. And I'm searching for a
Andreas> clean solution that would be accepted mainline. I think it
Andreas> would be best to have the same OOB layout for the whole device
Andreas> but the SPL space (cause that needs to be read by ROM). The
Andreas> layout should be chosen at compile time of the SPL. What do
Andreas> you think about?
So the only reason to not have the same OOB layout everywhere is because
of ROM restrictions and that 1bit ECC isn't good enough anymore?
E.G. you actually would have prefered to use the ROM layout if it would
have used something better like the am33xx ROM does.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2012-11-16 15:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 23:06 [U-Boot] [PATCH v2 0/8] NAND support for AM33XX Ilya Yanok
2012-11-06 23:06 ` [U-Boot] [PATCH v2 1/8] OMAP: include sys_proto.h from boot-common Ilya Yanok
2012-11-06 23:06 ` [U-Boot] [PATCH v2 2/8] am335x_evm: add nand pinmux definition Ilya Yanok
2012-11-06 23:06 ` [U-Boot] [PATCH v2 3/8] am33xx: NAND support Ilya Yanok
2012-11-08 9:33 ` Peter Korsgaard
2012-11-15 20:21 ` Ilya Yanok
2012-11-15 22:26 ` Peter Korsgaard
2012-11-21 16:59 ` Tom Rini
2012-11-06 23:06 ` [U-Boot] [PATCH v2 4/8] am335x_evm: enable " Ilya Yanok
2012-11-06 23:06 ` [U-Boot] [PATCH v2 5/8] am33xx: add ELM support Ilya Yanok
2012-11-06 23:06 ` [U-Boot] [PATCH v2 6/8] omap_gpmc: BCH8 support (ELM based) Ilya Yanok
2012-11-15 13:25 ` Andreas Bießmann
[not found] ` <CAA3CPjX0pHtU6y6kAtzVmdZq-akGAXhKcpkq92BwBJtb0HbRgw@mail.gmail.com>
2012-11-16 10:24 ` Andreas Bießmann
2012-11-16 15:59 ` Peter Korsgaard [this message]
2012-11-17 14:10 ` Andreas Bießmann
2012-11-17 19:13 ` Peter Korsgaard
2012-11-21 17:04 ` Tom Rini
2012-11-21 20:51 ` Andreas Bießmann
2012-11-06 23:06 ` [U-Boot] [PATCH v2 7/8] am33xx_spl_bch: simple SPL nand loader for AM33XX Ilya Yanok
2012-11-06 23:06 ` [U-Boot] [PATCH v2 8/8] am335x_evm: enable SPL NAND support Ilya Yanok
2012-12-10 20:18 ` [U-Boot] [PATCH v2 0/8] NAND support for AM33XX Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txspy1wd.fsf@dell.be.48ers.dk \
--to=jacmet@sunsite.dk \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox