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]
Date:   Mon, 24 Oct 2016 13:41:49 +0200
From:   Marek Vasut <marex@...x.de>
To:     Jagan Teki <jagan@...nedev.com>
Cc:     Cyrille Pitchen <cyrille.pitchen@...el.com>,
        Brian Norris <computersforpeace@...il.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        nicolas.ferre@...el.com, boris.brezillon@...e-electrons.com,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI
 memories

On 10/24/2016 09:41 AM, Jagan Teki wrote:
> On Sun, Oct 23, 2016 at 2:03 AM, Marek Vasut <marex@...x.de> wrote:
>> On 10/22/2016 01:00 PM, Jagan Teki wrote:
>>> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen
>>> <cyrille.pitchen@...el.com> wrote:
>>>> Hi all,
>>>>
>>>> This series extends support of SPI protocols to new protocols such as
>>>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the right
>>>> op codes, timing parameters (number of mode and dummy cycles) and erase
>>>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP)
>>>> tables, when available, as defined in the JEDEC JESD216 specifications.
>>>>
>>>> When SFDP tables are not available, legacy settings are still used for
>>>> backward compatibility (SPI and earlier QSPI memories).
>>>>
>>>> Support of SPI memories >128Mbits is also improved by using the 4byte
>>>> address instruction set, when available. Using those dedicated op codes
>>>> is stateless as opposed to enter the 4byte address mode, hence a better
>>>> compatibility with some boot loaders which expect to use 3byte address
>>>> op codes.
>>>
>>> The memories which are > 128Mbits should have 4-bytes addressing
>>> support based on my experience, do you think BAR is also required
>>> atleast from spi-nor side?
>>
>> Yes, I believe BAR is still required for broken/dumb flash chips.
>> Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-(
> 
> Do you have list for those broken chips?

No.

> because I never find any
> chips which has > 16 MiB with not support of 4-byte address opcodes
> and I've seen the controller has dependable with BAR though it can
> access > 16MiB ex: zynq qspi/

IIRC some of the 32 MiB micron chips were pretty flaky in that aspect,
they used the same opcodes for 4byte access as for 3byte access and
their behavior was switched by writing some non-volatile bit.

-- 
Best regards,
Marek Vasut

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ