From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Tim Sander <tim@krieglstein.org>
Cc: Dinh Nguyen <dinguyen@kernel.org>,
Vignesh Raghavendra <vigneshr@ti.com>,
Richard Weinberger <richard@nod.at>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Marek Vasut <marek.vasut@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: mtd raw nand denali.c broken for Intel/Altera Cyclone V
Date: Fri, 27 Sep 2019 02:47:33 +0900 [thread overview]
Message-ID: <CAK7LNASG+b03NDhrenB9yfvgYDVpYSnb2vSCu_-DB8dh70boMg@mail.gmail.com> (raw)
In-Reply-To: <23083624.r2bJSIadJk@dabox>
Hi Tim,
On Thu, Sep 26, 2019 at 6:10 PM Tim Sander <tim@krieglstein.org> wrote:
>
> Hi
>
> Am Mittwoch, 11. September 2019, 04:37:46 CEST schrieb Masahiro Yamada:
> > Hi Dinh,
> >
> > On Wed, Sep 11, 2019 at 12:22 AM Dinh Nguyen <dinguyen@kernel.org> wrote:
> > > On 9/10/19 8:48 AM, Tim Sander wrote:
> > > > Hi
> > > >
> > > > I have noticed that my SPF records where not in place after moving the
> > > > server, so it seems the mail didn't go to the mailing list. Hopefully
> > > > that's fixed now.> >
> > > > Am Dienstag, 10. September 2019, 09:16:37 CEST schrieb Masahiro Yamada:
> > > >> On Fri, Sep 6, 2019 at 9:39 PM Tim Sander <tim@krieglstein.org> wrote:
> > > >>> Hi
> > > >>>
> > > >>> I have noticed that there multiple breakages piling up for the denali
> > > >>> nand
> > > >>> driver on the Intel/Altera Cyclone V. Unfortunately i had no time to
> > > >>> track
> > > >>> the mainline kernel closely. So the breakage seems to pile up. I am a
> > > >>> little disapointed that Intel is not on the lookout that the kernel
> > > >>> works
> > > >>> on the chips they are selling. I was really happy about the state of
> > > >>> the
> > > >>> platform before concerning mainline support.
> > > >>>
> > > >>> The failure starts with kernel 4.19 or stable kernel release 4.18.19.
> > > >>> The
> > > >>> commit is ba4a1b62a2d742df9e9c607ac53b3bf33496508f.
> > > >>
> > > >> Just for clarification, this corresponds to
> > > >> 0d55c668b218a1db68b5044bce4de74e1bd0f0c8 upstream.
> > > >>
> > > >>> The problem here is that
> > > >>> our platform works with a zero in the SPARE_AREA_SKIP_BYTES register.
> > > >>
> > > >> Please clarify the scope of "our platform".
> > > >> (Only you, or your company, or every individual using this chip?)
> > > >
> > > > The company i work for uses this chip as a base for multiple products.
> > > >
> > > >> First, SPARE_AREA_SKIP_BYTES is not the property of the hardware.
> > > >> Rather, it is about the OOB layout, in other words, this parameter
> > > >> is defined by software.
> > > >>
> > > >> For example, U-Boot supports the Denali NAND driver.
> > > >> The SPARE_AREA_SKIP_BYTES is a user-configurable parameter:
> > > >> https://github.com/u-boot/u-boot/blob/v2019.10-rc3/drivers/mtd/nand/raw
> > > >> /Kcon fig#L112
> I am using barebox for booting. I looked at the code and found a comment in
> denali_hw_init:
> * tell driver how many bit controller will skip before
> * writing ECC code in OOB, this register may be already
> * set by firmware. So we read this value out.
> * if this value is 0, just let it be.
>
> I have checked the barebox code and the denali register SPARE_AREA_SKIP_BYTES
> (offset 0x230) is read only once on booting. I have not found any occurrence of
> the register being set by barebox. So i would concur as the value is zero in
> my case that the boot ROM seems not to set the value. The code in barebox is
> mostly imported from linux in 2015 which is before the reorganization which
> happened on the linux side later on.
>
> > > >>
> > > >>
> > > >> Your platform works with a zero in the SPARE_AREA_SKIP_BYTES register
> > > >> because the NAND chip on the board was initialized with a zero
> > > >> set to the SPARE_AREA_SKIP_BYTES register.
> > > >>
> > > >> If the NAND chip had been initialized with 8
> > > >> set to the SPARE_AREA_SKIP_BYTES register, it would have
> > > >> been working with 8 to the SPARE_AREA_SKIP_BYTES.
> > > >>
> > > >> The Boot ROM is the only (semi-)software that is unconfigurable by
> > > >> users,
> > > >> so the value of SPARE_AREA_SKIP_BYTES should be aligned with
> > > >> the boot ROM.
> > > >> I recommend you to check the spec of the boot ROM.
> > > >
> > > > We boot from NOR flash. That's why i didn't see a problem booting
> > > > probably.
> > > >
> > > >> (The maintainer of the platform, Dihn is CC'ed,
> > > >> so I hope he will jump in)
> > > >
> > > > Yes i hope so too.
> > >
> > > I don't have access to a NAND device at the moment. I'll try to find one
> > > and debug.
> I have hardware available to me, so i would be happy to test any ideas/
> guesses.
You previously mentioned,
"We boot from NOR flash. That's why i didn't see a problem booting probably."
Could you try the NAND device as the boot source?
- Flash the boot image into the NAND device,
changing the value for SPARE_AREA_SKIP_BYTES.
- Please find out the appropriate value for SPARE_AREA_SKIP_BYTES
for booting successfully.
--
Best Regards
Masahiro Yamada
next prev parent reply other threads:[~2019-09-26 17:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 12:38 mtd raw nand denali.c broken for Intel/Altera Cyclone V Tim Sander
2019-09-10 7:16 ` Masahiro Yamada
2019-09-10 13:48 ` Tim Sander
2019-09-10 15:22 ` Dinh Nguyen
2019-09-11 2:37 ` Masahiro Yamada
2019-09-11 7:27 ` Tim Sander
2019-09-26 9:10 ` Tim Sander
2019-09-26 17:47 ` Masahiro Yamada [this message]
2020-01-10 16:46 ` Tim Sander
2020-01-10 17:13 ` Marek Vasut
2020-01-10 19:05 ` Masahiro Yamada
2020-01-10 22:38 ` Tim Sander
2020-01-11 2:38 ` Masahiro Yamada
2020-01-13 10:22 ` Tim Sander
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=CAK7LNASG+b03NDhrenB9yfvgYDVpYSnb2vSCu_-DB8dh70boMg@mail.gmail.com \
--to=yamada.masahiro@socionext.com \
--cc=computersforpeace@gmail.com \
--cc=dinguyen@kernel.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=tim@krieglstein.org \
--cc=vigneshr@ti.com \
/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;
as well as URLs for NNTP newsgroup(s).