[PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash

[liao jaime]

Hi Michael

>
> Hi,
>
> > From: JaimeLiao <jaimeliao.tw at gmail.com>
> >
> > Adding Macronix Octal flash for Octal DTR support.
> >
> > The octaflash series can be divided into the following types:
> >
> > MX25 series : Serial NOR Flash.
> > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb)
> > LM/UM series : Up to 250MHz clock frequency with both DTR/STR
> > operation.
> > LW/UW series : Support simultaneous Read-while-Write operation in
> > multiple
> >                bank architecture. Read-while-write feature which means
> > read
> >                data one bank while another bank is programing or
> > erasing.
> >
> > MX25LM : 3.0V Octal I/O
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
>
> Link: tag at the end please. But dead. Redirected to "moved to a new
> home", maybe you
> should improve on stable links :) Esp. because you have the version in
> it.
Sorry, I will update links next version of patch.

>
> > MX25UM : 1.8V Octal I/O
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf
>
> dead. I've used
>
> https://www.mxic.com.tw/Lists/Datasheet/Attachments/8967/MX25UM51245G,%201.8V,%20512Mb,%20v1.5.pdf
>
> There "For SFDP register values detail, please contact local Macronix
> sales
> channel for Application Note.". Could you please send me (privately if
> you
> like) the AppNote for the SFDP table?
Ok, I will contact with Macronix sales for this information and send to you
privately if it is available.



>
> > MX66LM : 3.0V Octal I/O with stacked die
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf
>
> dead
>
> >
> > MX66UM : 1.8V Octal I/O with stacked die
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf
>
> dead
>
> >
> > MX25LW : 3.0V Octal I/O with Read-while-Write
> > MX25UW : 1.8V Octal I/O with Read-while-Write
> > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die
> > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die
>
> So the stack die information come from SFDP? Can RWW also be read from
> the SFDP tables? Do you have vendor SFDP tables where this information
> can come from?
For this introduction, it just introduce Macronix EPN naming rules.
As I know, rww didn't include JESD216D.

>
> >
> > MX25UM51245G : 512Mb flash, with Word mode data output format when
> > Octal DTR read
> > MX25UM51345G : 512Mb flash, with Byte mode data output format when
> > Octal DTR read
> >
> > Macronix Octal flash with two types, "byte mode" and "word mode".
> > Because of word mode flash with byte swap issue when Octal DTR read,
> > adding byte mode flash in this patchset only.
> >
> > About LW/UW series, please contact us freely if you have any
> > questions. For adding Octal NOR Flash IDs, we have validated
> > each Flash on plateform zynq-picozed.
>
> Again "us" as in macronix? but then, there is no trace that this commit
> is comming from macronix.
It is relate to Macronix mail issue, so we prefer send patches on gmail.
A question, how could I mention the commit is comming from Macronix if
I still send patch from gmail?

>
> > As below are the SFDP table dump.
>
> Thanks!
>
> > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id
> > c2943c
> > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer
> > macronix
> > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname
> > mx66uw2g345gx0
> > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx66uw2g345gx0
> > zynq> hexdump mx66uw2g345gx0
> > 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00
> > 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00
> > 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00
> > 0000030 0000 0000 0000 0000 ffff ffff ffff ffff
> > 0000040 20e5 ff8a ffff 7fff ff00 ff00 ff00 ff00
> > 0000050 ffee ffff ffff ff00 ffff ff00 200c d810
> > 0000060 ff00 ff00 7987 0001 1284 e200 04cc 4667
> > 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000
> > 0000080 0000 0000 0000 237c 0048 0000 0000 8888
> > 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff
> > 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600
> > 00000b0 7172 b803 7172 b803 0000 0000 a390 8218
> > 00000c0 c000 9669 0000 0000 0000 0000 7172 9800
> > 00000d0 7172 b800 7172 9900 0000 0000 7172 9800
> > 00000e0 7172 f800 7172 9900 7172 f900 0000 0000
> > 00000f0 0000 0000 1501 d001 7172 d806 0000 5086
> > 0000100 0000 0106 0000 0000 0002 0301 0200 0000
> > 0000110 0000 0106 0000 0000 0000 0672 0200 0000
> > 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000
> > 0000130 4514 8098 0643 001f dc21 ffff ffff ffff
> > 0000140 ffff ffff ffff ffff ffff ffff ffff ffff
>
> md5sum is missing and please use either xxd or if not
> available, "hexdump -C".
Ok, I will update content of SFDP dump with md5sum and
using xxd command.

>
> > --- a/drivers/mtd/spi-nor/macronix.c
> > +++ b/drivers/mtd/spi-nor/macronix.c
> > @@ -179,6 +179,33 @@ static const struct flash_info
> > macronix_nor_parts[] = {
> >       { "mx66u2g45g",  INFO(0xc2253c, 0, 64 * 1024, 4096)
> >               NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> >               FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
> > +     { "mx66uw2g345g", INFO(0xc2843c, 0, 64 * 1024, 4096)
>
> Please use INFO(0xc2843c, 0, 0, 0)
Sorry I didn't get it.

>
> > +             FLAGS(SPI_NOR_RWW)
>
> Maybe one of your proprietary tables indicate RWW capabilites?
As I know, RWW could be got on datasheet only for now.
So that follow the existing rule using FLAGS for it.

>
> > +             NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ
> > | SPI_NOR_OCTAL_DTR_PP)
>
> No NO_SFDP_FLAGS() for new parts.
>
> > +             FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
>
> You should have a correct "4-Byte Address Instruction Table", therefore
> you don't need the FIXUPS_FLAGS.
4 bytes opcode flag could be get by parsing bfpt.
But I think it would be great if ID table include it as well.
Because of some flashes in market may not define SFDP table.

>
> -michael

Thanks
Jaime