From: Andrea Zanotti <[email protected]>
Added support for P8P Parallel Phase Change Memory.
Added memory information (page size and sector size) as per data-
sheet information, after typos corrections.
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.
No known regressions inserted, as the patch only adds the possibility
to recognize said PCM memory inside the common spi-nor driver.
Signed-off-by: Andrea Zanotti <[email protected]>
---
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 },
};
static const struct flash_info st_parts[] = {
--
2.17.1
Hi Andrea,
Am 2021-08-31 10:13, schrieb Andrea Zanotti:
> From: Andrea Zanotti <[email protected]>
>
> 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://...
> Added memory information (page size and sector size) as per data-
> sheet information, after typos corrections.
After typos corrections?
> 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?
> 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.
>
> Signed-off-by: Andrea Zanotti <[email protected]>
> ---
> 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.
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.
> };
>
> static const struct flash_info st_parts[] = {
--
-michael
Il giorno mar 31 ago 2021 alle ore 11:09 Andrea Zanotti
<[email protected]> ha scritto:
>
> Hi Michael,
>
> Il giorno mar 31 ago 2021 alle ore 10:39 Michael Walle <[email protected]> ha scritto:
>>
>> Hi Andrea,
>>
>> Am 2021-08-31 10:13, schrieb Andrea Zanotti:
>> > From: Andrea Zanotti <[email protected]>
>> >
>> > 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 <[email protected]>
>> > ---
>> > 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?
>
>>
>> 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").
- 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.
>>
>> > };
>> >
>> > static const struct flash_info st_parts[] = {
>>
>> --
>> -michael
Hi Andrea,
Am 2021-08-31 12:11, schrieb Andrea Zanotti:
> Il giorno mar 31 ago 2021 alle ore 11:09 Andrea Zanotti
> <[email protected]> ha scritto:
>>
>> Hi Michael,
>>
>> Il giorno mar 31 ago 2021 alle ore 10:39 Michael Walle
>> <[email protected]> ha scritto:
>>>
>>> Hi Andrea,
>>>
>>> Am 2021-08-31 10:13, schrieb Andrea Zanotti:
>>> > From: Andrea Zanotti <[email protected]>
>>> >
>>> > 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 <[email protected]>
>>> > ---
>>> > 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
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
<[email protected]> 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
> > <[email protected]> ha scritto:
> >>
> >> Hi Michael,
> >>
> >> Il giorno mar 31 ago 2021 alle ore 10:39 Michael Walle
> >> <[email protected]> ha scritto:
> >>>
> >>> Hi Andrea,
> >>>
> >>> Am 2021-08-31 10:13, schrieb Andrea Zanotti:
> >>> > From: Andrea Zanotti <[email protected]>
> >>> >
> >>> > 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 <[email protected]>
> >>> > ---
> >>> > 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
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/[email protected]/
-michael