linux-kernel - Re: mtd raw nand denali.c broken for Intel/Altera Cyclone V

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9bb2fb0e-a9e7-c389-f9b7-42367485ff83@kernel.org>
Date:   Tue, 10 Sep 2019 10:22:32 -0500
From:   Dinh Nguyen <dinguyen@...nel.org>
To:     Tim Sander <tim@...eglstein.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Vignesh Raghavendra <vigneshr@...com>,
        Richard Weinberger <richard@....at>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Marek Vasut <marek.vasut@...il.com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Brian Norris <computersforpeace@...il.com>,
        David Woodhouse <dwmw2@...radead.org>
Subject: Re: mtd raw nand denali.c broken for Intel/Altera Cyclone V



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