All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dinh Nguyen <dinguyen@kernel.org>
To: Tim Sander <tim@krieglstein.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: 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: Tue, 10 Sep 2019 10:22:32 -0500	[thread overview]
Message-ID: <9bb2fb0e-a9e7-c389-f9b7-42367485ff83@kernel.org> (raw)
In-Reply-To: <3020870.hsMMj5ogRZ@dabox>



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
>>
>>
>> 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.

Dinh

WARNING: multiple messages have this Message-ID (diff)
From: Dinh Nguyen <dinguyen@kernel.org>
To: Tim Sander <tim@krieglstein.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: 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: Tue, 10 Sep 2019 10:22:32 -0500	[thread overview]
Message-ID: <9bb2fb0e-a9e7-c389-f9b7-42367485ff83@kernel.org> (raw)
In-Reply-To: <3020870.hsMMj5ogRZ@dabox>



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
>>
>>
>> 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.

Dinh

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2019-09-10 15:22 UTC|newest]

Thread overview: 28+ 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-06 12:38 ` Tim Sander
2019-09-10  7:16 ` Masahiro Yamada
2019-09-10  7:16   ` Masahiro Yamada
2019-09-10 13:48   ` Tim Sander
2019-09-10 13:48     ` Tim Sander
2019-09-10 15:22     ` Dinh Nguyen [this message]
2019-09-10 15:22       ` Dinh Nguyen
2019-09-11  2:37       ` Masahiro Yamada
2019-09-11  2:37         ` Masahiro Yamada
2019-09-11  7:27         ` Tim Sander
2019-09-11  7:27           ` Tim Sander
2019-09-26  9:10         ` Tim Sander
2019-09-26  9:10           ` Tim Sander
2019-09-26 17:47           ` Masahiro Yamada
2019-09-26 17:47             ` Masahiro Yamada
2020-01-10 16:46             ` Tim Sander
2020-01-10 16:46               ` Tim Sander
2020-01-10 17:13               ` Marek Vasut
2020-01-10 17:13                 ` Marek Vasut
2020-01-10 19:05               ` Masahiro Yamada
2020-01-10 19:05                 ` Masahiro Yamada
2020-01-10 22:38                 ` Tim Sander
2020-01-10 22:38                   ` Tim Sander
2020-01-11  2:38                   ` Masahiro Yamada
2020-01-11  2:38                     ` Masahiro Yamada
2020-01-13 10:22                     ` Tim Sander
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=9bb2fb0e-a9e7-c389-f9b7-42367485ff83@kernel.org \
    --to=dinguyen@kernel.org \
    --cc=computersforpeace@gmail.com \
    --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 \
    --cc=yamada.masahiro@socionext.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.