LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: linux-mtd@lists.infradead.org,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Pratyush Yadav <p.yadav@ti.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: mt25qu: Ignore 6th ID byte
Date: Mon, 22 Nov 2021 16:05:56 +0100	[thread overview]
Message-ID: <e9589af968d7b9dafbce17325dbf8472@walle.cc> (raw)
In-Reply-To: <1e133bc6-5edb-c4ce-ad44-3de77048acf2@nokia.com>

Hi,

Am 2021-11-22 08:06, schrieb Alexander Sverdlin:
> On 19/11/2021 22:19, Michael Walle wrote:
>>> Ignore 6th ID byte, secure version of mt25qu256a has 0x73 as 6th 
>>> byte.
>> 
>> What is the secure version? What is the difference? Do you have some
>> links to datasheets for both?
> 
> For instance:
> https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25qu256aba1ew7-0sit
> https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-a/mt25q_qljs_u_256_aba_0.pdf?rev=594079234c1b496496b062c21ce162d6
> 
> https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25qu256aba8e12-1sit
> https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-a/mt25q_qljs_u_256_aba_0.pdf?rev=594079234c1b496496b062c21ce162d6
> 
> But the differences are in "MT25Q Security Addendum":
> "The additional protection features available on the secure MT25Q
> device include a
> lock status register bit, top/bottom block address protection lock, 
> volatile
> configuration lock register at power up, protection management register 
> lock,
> and a nonvolatile configuration lock register."
> This is only available under NDA from Micron.

So I take a wild guess here. There are lock bits (either in OTP or
maybe until the next power cycle), to lock the corresponding
top/bottom, block protection bits, right?

> However as long as one doesn't use these security features, it appears
> compatible with
> non-secure version. That's why just ignoring the non-standard
> configuration allows
> to support it.

But if we ever support it, then we have to distiguish them. Thus,
I was asking.

>> Also please provide the SFDP data for this flash, see [1].
> 
> sfdp:
> 53464450060101ff00060110300000ff84000102800000ffffffffffffff
> ffffffffffffffffffffffffffffffffffffe520fbffffffff0f29eb276b
> 273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e
> 03d4ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff
> ffffffffffffffffffe7ffff21dcffff
> 
> md5sum:
> 5ea738216f68c9f98987bb3725699a32
> 
> jedec_id:
> 20bb191044
> 
> partname:
> mt25qu256a
> 
> manufacturer:
> st
> 
> (But last 3 do not make sense to me, as they come from the table I 
> modify,
> not from the chip itself). Further, I don't have 512Mbit chip to 
> provide
> SFDP for it.

Thanks, so that's the SFDP data for the mt25qu256aba8e12-1sit part. and 
the
jedec id is 20bb19104473, correct?

You don't have the non-security part by chance?

Mh, I'm undecided whether we should just duplicate the entry or if we
should ignore the last byte ("Device configuration information", where 
00h
is standard). The commit which introduced the flash was 7f412111e276b.
Vingesh?

Can you elaborate on the 0x73? Is that a bitmask? If it was an 
enumeration,
I'd assumed it would be 01h (or some smaller value).

-michael

  reply	other threads:[~2021-11-22 15:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19  8:04 Alexander A Sverdlin
2021-11-19 21:19 ` Michael Walle
2021-11-22  7:06   ` Alexander Sverdlin
2021-11-22 15:05     ` Michael Walle [this message]
2021-11-23  7:45       ` Alexander Sverdlin
2021-11-23  8:14         ` Michael Walle
2021-11-23 12:40           ` Alexander Sverdlin
2021-11-23 14:01             ` Michael Walle
2021-11-23 16:14               ` Tudor.Ambarus
2021-11-23 12:13       ` Alexander Sverdlin
2021-11-23 17:42         ` Pratyush Yadav
2021-11-25  7:26           ` Alexander Sverdlin
2021-11-30  9:49             ` Pratyush Yadav
2022-07-18 15:03 ` Tudor.Ambarus

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=e9589af968d7b9dafbce17325dbf8472@walle.cc \
    --to=michael@walle.cc \
    --cc=alexander.sverdlin@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@microchip.com \
    --cc=vigneshr@ti.com \
    --subject='Re: [PATCH] mtd: spi-nor: mt25qu: Ignore 6th ID byte' \
    /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

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