Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp523882pxb; Wed, 1 Sep 2021 04:28:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwho5p/FUIJFs+hD2BRQUJjcfhHyFEfIrA9vXZS7An9cJHAU6F14Dwfv6R4pWrqwcRZcuBL X-Received: by 2002:a17:906:7154:: with SMTP id z20mr36520556ejj.547.1630495722618; Wed, 01 Sep 2021 04:28:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630495722; cv=none; d=google.com; s=arc-20160816; b=KMqSKj/KhrLpL4H/c0sAmwx07+8pDWHXjWujifgQu4rFWN9xeH1I0AahqLJIJkJBwj Aj9kKIYQ8kEkgBwjB8Fp2RQcbliml9ksqgCUkAFbC2vEzYlp9l7iHR1PPe+GNSU1Xp0v cOSJTf3shXGzcToZlOCBECwekaFBjhvxIE5qjhkczP3IyIGpfG82yPPgQQdmvt+rus38 zBx5Yl4AeNXqHb1iAq0nyv0HbfK6XQt5UpASdhlhxo3KdI/Pn5h1BCe3ul9TOd0uN8+E eKHA2WBMFdkLgd3T8vPM377ZC1Ea25ndF5Pt8hnRHPMKavqLJ+k9zFBaknTBGNdJnwQk 2YhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=wDU05qyMlurEptD3ge36yt8avgElKgTA+xLedQ2wfFk=; b=cgvNxWyO0JcqScthSHZZsqrj0VKhPp6vssm2/h7QDlNAAEoUsI0w5neiSpEKqjFTad NY8GC+llQ827g6RTRxTNMInumfqb8RGOhxNxtH4lCvmEo1oqJqVz9kjUsb4WNJUTMXty rlrY0pSwneeUlPz0xjTMWVQc+AcgxiZBva+UiyeULZTd6n8T58RifvR+wQr3sViYYVrf 2CeyJSieIYVscFEmq8sEi6PCqW5mTrbeIVaaDTpiVWQAJuCzGZNYDLqEfhufhi1SBmc8 p5O7PwcyNfxWIwQ4jWv43UqP5m06vkk7fN+a/6RFM/XEEggcLV9HPVi8gWsqasGE0WCS ZJpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=d3iPtE+8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de36si24560193ejc.582.2021.09.01.04.27.40; Wed, 01 Sep 2021 04:28:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=d3iPtE+8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242657AbhIALVe (ORCPT + 99 others); Wed, 1 Sep 2021 07:21:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234678AbhIALVd (ORCPT ); Wed, 1 Sep 2021 07:21:33 -0400 Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE81FC061575 for ; Wed, 1 Sep 2021 04:20:36 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id l24so1139081uai.1 for ; Wed, 01 Sep 2021 04:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wDU05qyMlurEptD3ge36yt8avgElKgTA+xLedQ2wfFk=; b=d3iPtE+8EirxpSiyPZfwSsP4vl5ksOU/K9JVtv7lP1YwvGYcu7u+l11xedPfNP1NqM 43MhyetoOho0fRureNOZUS4EySrAjYF0/nctPVmGqNuGHwK78YTwvqnBJj0IGDqiHRuD jrx0zSYw385aRaPHhaXrAeJ4bkm4kfJhglz2LpQYEf++Cdd7EitJgZnQ/YBqVGBlmh72 klQ1T7GkB1XiZzk8yQZF+uzGPaTyGWY7CcS+z3pDKHPuGPl6LYvmlGE49yCvkgNP6kpt tSkEk8/UcNSQe8SE/55l0Go4FjETBqmvAeDBzO5UD8tO/YUmA/TnF67XrW5PukTg/pKW GoVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wDU05qyMlurEptD3ge36yt8avgElKgTA+xLedQ2wfFk=; b=pW1KODCnoE+BnzKW4KjeDr1vkIPcYQ3lqInJ6CxQUhqeU9MjDa/PMOou4rcEIybDNl UTT6GKf7XxBdDGBf1JPpeHodUXTEurLLnGadgre9ZqK7aQ6p6EY3/k6DzJWIanPC257v Lsp6NWVwN2DU9erkoHVFVaMz64ddwBGIcRLnKaQNTysw7cie1UeKgNnmxMwSl7eJSJQV UR1pEGxTNIFSFoH7xfAtS9td+xqA0MO49EVTthZL5vs23GAyIlzXopaXF/NuiNK8++r+ QTFgfp0NGScP61RHF13pL2ApFP5ohy55MOfnmd1GKcpg0UnhpebxXo6Nnv32ccg6mF7T HB4Q== X-Gm-Message-State: AOAM533DhaEgTyJZ/EdwmzZNu8mjW0I2UEuAN/V7T7Ki7zJpKj7I5vYQ AO+KYgQd4aQ9xBScs+0Y6ZMia6ekYN/BJO+v1xj45M4n+2/dSg== X-Received: by 2002:ab0:3c5:: with SMTP id 63mr22621397uau.106.1630495235937; Wed, 01 Sep 2021 04:20:35 -0700 (PDT) MIME-Version: 1.0 References: <20210831081329.27420-1-andrea.zanotti@tyvak.eu> <3462300528bbe71207ef2164411e34d2@walle.cc> <4bf9396505975e3fee2cc6396a6eeff7@walle.cc> In-Reply-To: <4bf9396505975e3fee2cc6396a6eeff7@walle.cc> From: Andrea Zanotti Date: Wed, 1 Sep 2021 13:20:25 +0200 Message-ID: Subject: Re: [PATCH] mtd: spi-nor: micron-st: added support for np8p128ax60 To: Michael Walle Cc: Tudor Ambarus , Pratyush Yadav , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michael, I performed the test with drivers/misc/eeprom/at25.c. I configured the DTS as such: spi_pcm@0 { compatible = "atmel,at25"; reg = <0>; spi-max-frequency = <50000000>; size = <16777216>; pagesize = <64>; address-width = <24>; label = "micron_pcm"; }; and activated the driver itself in the kernel configuration. I think the system is recognizing it: # ls -l /sys/bus/spi/devices/spi0.0/eeprom -rw------- 1 root root 16777216 Jan 1 00:01 /sys/bus/spi/devices/spi0.0/eeprom However, if I am not wrong (again, please correct me if I am wrong) this driver does not work with the MTD layer (I am booting with the following cmdline bootargs: mtdparts=micron_pcm:128k(bootstrap),128k(fdt),10M(kernel/rootfs),-(spare) and I expected to have the same partitions as before, but of course they are missing.) I am checking the Company ID on the document "JEP106BC", revisioned on June 2020, downloaded from here https://www.jedec.org/system/files/docs/JEP106BC.pdf. STMicroelectronics should be 20 Micron should be 2C Intel is advertised as 89, in Table 1 "Manufacturer's Identification Code". How do you suggest to proceed? Andrea Il giorno mar 31 ago 2021 alle ore 17:05 Michael Walle ha scritto: > > Hi Andrea, > > Am 2021-08-31 12:11, schrieb Andrea Zanotti: > > Il giorno mar 31 ago 2021 alle ore 11:09 Andrea Zanotti > > ha scritto: > >> > >> Hi Michael, > >> > >> Il giorno mar 31 ago 2021 alle ore 10:39 Michael Walle > >> ha scritto: > >>> > >>> Hi Andrea, > >>> > >>> Am 2021-08-31 10:13, schrieb Andrea Zanotti: > >>> > From: Andrea Zanotti > >>> > > >>> > Added support for P8P Parallel Phase Change Memory. > >>> > >>> Please use present tense, eg "add support..." > >>> > >>> Is there a public datasheet? If so, please include it above > >>> your SoB like so: > >>> Datasheet: https://... > >>> > >> > >> I will format the header as per your suggestions. I used the same > >> datasheet > >> linked by you at the end of the email > >> > >>> > >>> > Added memory information (page size and sector size) as per data- > >>> > sheet information, after typos corrections. > >>> > >>> After typos corrections? > >>> > >> > >> The one specified in the following paragraph. I'll better write this. > >> (What I meant > >> is that there are some typos in the datasheet itself) > >> > >>> > >>> > At page 37, paragraph 'SPI Memory Organization', it is written > >>> > down that the memory is organized as: > >>> > * 16.772.216 bytes (typo here, there 16.777.216 bytes) > >>> > * 128 sectors of 128 Kbytes each (correct) > >>> > * 131.072 pages of 64 bytes each (typo here, as the total would be > >>> > 64Mbit, but the total memory is actually 128Mbit, correct value > >>> > is 262.144 pages) > >>> > > >>> > Patch tested against the aforementioned PCM memory. > >>> > >>> What SPI host controller was used? > >>> > >> > >> I used an AT91SAM9G20 processor, SPI controller "atmel,at91rm9200-spi" > >> (spi-atmel.c) > >> > >>> > >>> > No known regressions inserted, as the patch only adds the possibility > >>> > to recognize said PCM memory inside the common spi-nor driver. > >>> > >>> Please drop this. If there were any regressions, the patch wouldn't > >>> be picked up anyway. > >>> > >> > >> It will be dropped. > >> > >>> > > >>> > Signed-off-by: Andrea Zanotti > >>> > --- > >>> > drivers/mtd/spi-nor/micron-st.c | 1 + > >>> > 1 file changed, 1 insertion(+) > >>> > > >>> > diff --git a/drivers/mtd/spi-nor/micron-st.c > >>> > b/drivers/mtd/spi-nor/micron-st.c > >>> > index c224e59820a1..c78331451082 100644 > >>> > --- a/drivers/mtd/spi-nor/micron-st.c > >>> > +++ b/drivers/mtd/spi-nor/micron-st.c > >>> > @@ -128,6 +128,7 @@ static const struct flash_info micron_parts[] = { > >>> > { "mt35xu02g", INFO(0x2c5b1c, 0, 128 * 1024, 2048, > >>> > SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | > >>> > SPI_NOR_4B_OPCODES) }, > >>> > + { "np8p128ax60", {0x89, 0xda, 0x18}, 3, 128 * 1024, 128, 64, 0, 0 }, > >>> > >>> Eh? Please use INFO(). And why isn't this 0x20 for micron. > >>> > >> > >> With INFO() macro I am locked in with .page_size = 256 (I would need > >> 64), or am I missing something? > > Ok I see. Mh, then maybe there should be a new macro where you can > set the page_size? > > >>> > >>> I found this datasheet: > >>> https://media.digikey.com/pdf/Data%20Sheets/Micron%20Technology%20Inc%20PDFs/NP8P128Ax60E_Rev_K.pdf > >>> > >>> According to that datasheet, the manuf id is 0x20. And the device id > >>> should be either 0x88e1 or 0x8821. > >>> > >> > >> You are right, checking it right now. > >> > > > > - As per datasheet, table 10 on page 18, Manufacturer code is 0x89 > > (column "data" for parameter "Manufacturer Code"). > > That is for the command 90h (which is for the parallel interface?). We > issue 9Fh and according to the "READ IDENTIFICATION (RDID)" chapter: > > The manufacturer identification is assigned by JEDEC and has the > value 20h for Micron. > > And in fact it is assigned by JEDEC, see below. > > > - On the datasheet, I agree with you that the device code is > > advertised as either 0x88e1 or 0x8821. I changed the byte array > > to something wrong in order to have the debug warning on the JEDEC id > > bytes, and this is the log: > > > > spi-nor spi0.0: unrecognized JEDEC id bytes: 89 da 18 00 00 00 > > > > Second and third byte are "0xda" and "0x18". I am not an expert in the > > spi-nor driver, but from my understanding > > (if it's wrong, please correct me) the spi-nor driver tries to match > > the the read bytes from the memory with the ones > > in the tables. I don't know if the datasheet is wrong also in that > > cell of the table, or if I am interpreting the data wrongly. > > Looks like the datasheet is wrong or something is broken here. Yes > you are correct in assuming that these are in fact the ID bytes. > > We'd need to check what vendor 0x89 is to avoid collisions with other > vendors/flashes. > > Btw this "flash" has no need for an erase, just like the MRAM or an > SPI EEPROM. Could you have a look at drivers/misc/eeprom/at25.c if > that will work for you? > > -michael