[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0719218e274bdffdf76b8689072530d3@walle.cc>
Date: Fri, 03 Sep 2021 13:47:29 +0200
From: Michael Walle <michael@...le.cc>
To: Andrea Zanotti <andreazanottifo@...il.com>
Cc: Tudor Ambarus <tudor.ambarus@...rochip.com>,
Pratyush Yadav <p.yadav@...com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: micron-st: added support for np8p128ax60
Hi Andrea,
Am 2021-09-01 13:20, schrieb Andrea Zanotti:
> 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.)
You are correct, there is no mtd layer for an eeprom device. If you
need the partitioning, the at25 won't work.
> 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.
Btw theres one from Feb 2021, but it doesn't really matter.
> STMicroelectronics should be 20
> Micron should be 2C
which matches the micron_parts[] and st_parts[].
> Intel is advertised as 89, in Table 1 "Manufacturer's Identification
> Code".
>
> How do you suggest to proceed?
I'm not sure, it this flash was originally made by intel or if its a
mistake. If its made by intel it probably should go into intel.c
Tudor is working on a larger patchset which addresses flash id
collisions [1]. If it is a mistake, then it should probably go into
the new collisions table which is introduced in this patchset.
Btw. AFAIK new flash additions are delayed until that patchset
is merged.
[1]
https://lore.kernel.org/linux-mtd/20210727045222.905056-1-tudor.ambarus@microchip.com/
-michael
Powered by blists - more mailing lists