From: "Andreas Bießmann" <andreas.devel@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Antw: [PATCH v11 3/4] mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme
Date: Fri, 11 Jul 2014 12:08:29 +0200 [thread overview]
Message-ID: <53BFB79D.6080603@gmail.com> (raw)
In-Reply-To: <53BFBBFD0200007D000131FA@sensopart.de>
Dear Steffen Arendt,
you could test the tricorder configuration. It does work with Pekon's
patchset mentioned in your mail.
I haven't tested Pekon's changes when they where included. But my
regular tests before each U-Boot release showed a change in OOB layout,
therefore commit 1b82491ee6ee1e986e5521b33692a00e1f38fe75 was generated.
It seems my first attempt to implement OMAP3 HW supported BCH in u-boot
was buggy :( Sorry for that!
On 07/11/2014 10:27 AM, Steffen Arendt wrote:
> Dear Pekon,
>
> thanks for your mail. This ECC topic is of some complexity. :(
>
> I am close to solve a huge problem here, switching boards from
> 1bit-SW-ECC to BCH4.
> The only missing part is, that OMAP xloader and uboot calculates the
> BCH4 ECC values than Sitara XLoader
> (although the x-loader binaries are identical).
> Main problem is not that this is different to Linux - this is not nice,
> but not a problem. I solved this by implementing a
> second linux compatible BCH4 in uboot (which works on both platforms).
> Problem is, that BCH4 (as it is implemented in aragos xloader) seems
> not to work on OMAP3503.
> And it is not understood by me, why this is not working, or what can
> the reason for this.
There is an issue in GPMC for AM37xx up to revision 1.0 (Advisory 1.54
'GPMC Has Incorrect ECC Computation for 4-Bit BCH Mode'). I think this
includes the OMAP35xx variants.
> You suggestions address kernel/uboot changes. For this I have already
> a solution.
> I am running into other troubles if I shift to your suggestions, and I
> can't see an improvement for
> the xloader problem.
> I know, nowadays the xloader is SPL and is derived from uboot. But I
> haven't the power to completely change everything again.
> Frankly speaking, I afraid another nightmare here.
> Unfortunatly TI doesn't have an newer SDK for OMAP3503/AM3703.
> Is it true, that in this Arago or TI SDK the only functional ECC scheme
> are 1 bit SW and 1 bit HW (for xloader)?
U-Boot had also only 1 bit Hamming with two different OOB-schemes before
my attempt to support BCH. Since X-Loader is outdated I think nobody
cared to port these changes. Sorry, I never worked with X-Loader so I
can't tell anything about it. You should really migrate to U-Boot!
> For me it seems (if you check my logs) that in xloader the
> omap_calculate_ecc_bch4() uses hardware GPMC registers.
> Main question: why this doens't work or give different results in
> OMAP?
I think it is because of the errata mentioned above. You should switch
to BCH8 on OMAP3 devices in favor of BCH4.
> The version I take over for uboot and kernel (according to Technical
> Note from Micron tn2971_software_bch_ecc_on_linux.pdf),
> this functions. The counterpart for this seems to me in bch.c
> encode_bch(), which seems to run completly independent on hardware.
>
> Please understand my situation. At TI forum I asked since monthes with
> no real help. So I started my work and succeeded 90%.
U-Boot BCH8 support for OMAP3 is working, one example is tricorder board.
Best regards
Andreas Bie?mann
prev parent reply other threads:[~2014-07-11 10:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 8:27 [U-Boot] Antw: [PATCH v11 3/4] mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme Steffen Arendt
2014-07-11 10:08 ` Andreas Bießmann [this message]
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=53BFB79D.6080603@gmail.com \
--to=andreas.devel@googlemail.com \
--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