LKML Archive on
help / color / mirror / Atom feed
From: "Rafał Miłecki" <>
To: Vivek Unune <>
Cc:, Hauke Mehrtens <>,
	Jon Mason <>,
	bcm-kernel-feedback-list <>,
	Rob Herring <>,
	Mark Rutland <>,
	Russell King <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera
Date: Wed, 25 Apr 2018 10:51:33 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20180311100313.znonhesgh462rz65@osboxes>

On 11 March 2018 at 11:03, Vivek Unune <> wrote:
> Hi Rafał,
> On Sat, Mar 10, 2018 at 10:41:04PM +0100, Rafał Miłecki wrote:
>> On 10 March 2018 at 18:12, Vivek Unune <> wrote:
>> > Using BCH8 gives ecc errors and makes the router unsuable.
>> > Switching to BCH1 fixes these errors.
>> Can you provide CFE's log messages starting with
>> "Decompressing...done" and up to the "Press Ctrl+C to stop in CFE"
>> please? I'd like to see what NAND info CFE prints there.
> See below. It does say BCH-8, however I can't get it to work.
> CFE log:
> Decompressing...done
> Found a Toshiba NAND flash:
> Total size:  128MB
> Block size:  128KB
> Page Size:   2048B
> OOB Size:    64B
> Sector size: 512B
> Spare size:  16B
> ECC level:   8 (8-bit)
> Device ID: 0x98 0xf1 0x80 0x15 0xf2 0x16
> find_devinfo: devinfo block found at 0x00180000!
> Press Ctrl+C to stop in CFE

This means that:
1) Default mode for your NAND controller is BCH8 (setup at hw level)
2) CFE uses BCH8 when programming flash with provided firmware

For maximum compatibility DTS should describe ECC as using BCH8 and
Linux should use BCH8.

I spent whole day yesterday experimenting with BCM47094 and NAND
controller to understand your case better.

As crazy as it sounds, my NAND controller working in BCH4 mode is
reading flash data programmed using BCH8 perfectly fine! I was testing
& verifying that behavior multiple times for hours. It really works.

I noticed that on my BCM47094 board with CFE working in BCH8:
1) Flashing firmware with CFE results in using BCH8 (expected)
2) Linux with NAND controller in BCH4 can read flash data (unexpected!)
3) Writing flash data results in using BCH4

Above write test proves that NAND controller is really setup into BCH4
mode correctly. How is it possible it reads flash data programmed
using BCH8 is out of my imagination.

Long story short I believe your patch is wrong. DTS should describe
hardware and by default this board uses BCH8 (and so the bootloader).
Current DTS is correct.

As it happens your patch doesn't break anything directly because of
unexpected NAND controller behavior. It's just a matter of "luck"
though due to some weird hardware behavior.


      parent reply	other threads:[~2018-04-25  8:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-10 17:12 Vivek Unune
2018-03-10 21:41 ` Rafał Miłecki
2018-03-11 10:03   ` Vivek Unune
2018-03-12 22:52     ` Florian Fainelli
2018-03-13  1:02       ` Vivek Unune
2018-04-25  9:02         ` Rafał Miłecki
2018-04-27 14:05           ` Vivek Unune
2018-04-28  4:19             ` Vivek Unune
2018-04-28  6:44               ` Rafał Miłecki
2018-04-25  8:51     ` Rafał Miłecki [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).