Re: [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode

[zhengxunli@xxxxxxxxxxx]

Hi all,

<Tudor.Ambarus@xxxxxxxxxxxxx> wrote on 2022/02/24 下午 06:27:57:

> <Tudor.Ambarus@xxxxxxxxxxxxx> 
> 2022/02/24 下午 06:28
> 
> To
> 
> <michael@xxxxxxxx>, <p.yadav@xxxxxx>, 
> 
> cc
> 
> <p.yadav@xxxxxx>, <broonie@xxxxxxxxxx>, <miquel.raynal@xxxxxxxxxxx>,
> <richard@xxxxxx>, <vigneshr@xxxxxx>, <linux-
> mtd@xxxxxxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <linux-
> spi@xxxxxxxxxxxxxxx>, <Nicolas.Ferre@xxxxxxxxxxxxx>, 
> <zhengxunli@xxxxxxxxxxx>, <jaimeliao@xxxxxxxxxxx>
> 
> Subject
> 
> Re: [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode
> 
> On 2/24/22 11:37, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you 
> know the content is safe
> > 
> > Am 2022-02-24 07:37, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> >> On 2/24/22 08:08, Tudor.Ambarus@xxxxxxxxxxxxx wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you 
know
> >>> the content is safe
> >>>
> >>> On 2/23/22 20:38, Pratyush Yadav wrote:
> >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
> >>>> know the content is safe
> >>>>
> >>>> Hi Tudor,
> >>>>
> >>>> On 22/02/22 02:43PM, Tudor.Ambarus@xxxxxxxxxxxxx wrote:
> >>>>> On 2/22/22 16:27, Michael Walle wrote:
> >>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
> >>>>>> know the content is safe
> >>>>>>
> >>>>>> Am 2022-02-22 15:23, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> >>>>>>> On 2/22/22 16:13, Michael Walle wrote:
> >>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless 
you
> >>>>>>>> know
> >>>>>>>> the content is safe
> >>>>>>>>
> >>>>>>>> Am 2022-02-22 14:54, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> >>>>>>>>> On 2/21/22 09:44, Michael Walle wrote:
> >>>>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless
> >>>>>>>>>> you
> >>>>>>>>>> know
> >>>>>>>>>> the content is safe
> >>>>>>>>>>
> >>>>>>>>>> Am 2022-02-18 15:58, schrieb Tudor Ambarus:
> >>>>>>>>>>> Fortunately there are controllers
> >>>>>>>>>>> that can swap back the bytes at runtime, fixing the
> >>>>>>>>>>> endiannesses.
> >>>>>>>>>>> Provide
> >>>>>>>>>>> a way for the upper layers to specify the byte order in DTR
> >>>>>>>>>>> mode.
> >>>>>>>>>>
> >>>>>>>>>> Are there any patches for the atmel-quadspi yet? What happens
> >>>>>>>>>> if
> >>>>>>>>>
> >>>>>>>>> not public, but will publish them these days.
> >>>>>>>>>
> >>>>>>>>>> the controller doesn't support it? Will there be a software
> >>>>>>>>>> fallback?
> >>>>>>>>>
> >>>>>>>>> no need for a fallback, the controller can ignore
> >>>>>>>>> op->data.dtr_bswap16
> >>>>>>>>> if
> >>>>>>>>> it can't swap bytes.
> >>>>>>>>
> >>>>>>>> I don't understand. If the controller doesn't swap the 16bit
> >>>>>>>> values,
> >>>>>>>> you will read the wrong content, no?
> >>>>>>>>
> >>>>>>>
> >>>>>>> In linux no, because macronix swaps bytes on a 2 byte boundary
> >>>>>>> both on
> >>>>>>> reads and on page program. The problem is when you mix 8D-8D-8D
> >>>>>>> mode
> >>>>>>> and
> >>>>>>> 1-1-1 mode along the boot stages. Let's assume you write all 
boot
> >>>>>>> binaries
> >>>>>>> in 1-1-1 mode. When reaching u-boot if you enable 8D-8D-8D mode,
> >>>>>>> when
> >>>>>>> u-boot
> >>>>>>> will try to get the kernel it will fail, as the flash swaps the
> >>>>>>> bytes
> >>>>>>> compared
> >>>>>>> to what was written with 1-1-1 mode. You write D0 D1 D2 D3 in
> >>>>>>> 1-1-1
> >>>>>>> mode and
> >>>>>>> when reaching u-boot you will read D1 D0 D3 D2 and it will mess
> >>>>>>> the
> >>>>>>> kernel image.
> >>>>>>
> >>>>>> But you have to consider also 3rd parties, like an external
> >>>>>> programmer
> >>>>>> or
> >>>>>
> >>>>> Why? If you use the same mode when reading and writing, everything
> >>>>> is fine.
> >>>>> I'm not sure what's your suggestion here.
> >>>>
> >>>> So our stance here is that we don't care about external programs?>
> >>>> If that is the case then why bother with all this anyway? Since the
> >>>> swap
> >>>> happens at both page program and read, what you write is what you
> >>>> read
> >>>> back. Who cares the order stored in the actual flash memory as long
> >>>> as
> >>>> the data read is correct?
> >>>>
> >>>> If we do care about external programs, then what would happen if 
the
> >>>> external program writes data in 8D-8D-8D mode _without_ swapping 
the
> >>>> bytes? This would also cause data corruption. You can't control 
what
> >>>> they mode they use, and you can't detect it later either.
> >>>>
> >>>> I think there is no winning here. You just have to say that 
external
> >>>> programs should write in 8D-8D-8D mode or it won't boot.
> > 
> > IMHO it should just work that you can use 1S-1S-1S mode and 8D-8D-8D 
on
> > the
> > same flash. After all, that is Tudor's use case. The ROM access the
> > flash
> > in single bit mode and linux in 8D-8D-8D mode. Maybe u-boot will use
> > quad
> > mode in between. All of these accesses should return the same flash
> > content.
> > 
> >>> How about swapping the bytes just at user request? Maybe with a
> >>> Kconfig
> >>> option.
> >>
> >> Michael has suggested on #irc to always swap the bytes: if the SPI
> >> controller
> >> can't do it, to do it in software at SPI NOR level. I don't know what
> >> to say
> >> about this, because JEDEC216 just informs the reader I guess:
> >> "Byte order of 16-bit words is swapped when read in 8D-8D-8D mode
> >> compared to
> >> 1-1-1 mode.", this doesn't look like a hard request. The downside to
> >> doing
> >> the swapping in software is performance penalty which will make
> >> macronix
> >> users have second thoughts. I don't have a strong opinion, but I lean
> >> towards
> >> doing the swap just at user request, regardless if I do it via the 
SPI
> >> controller
> >> or in software.
> > 
> > Just having and opt-in will be a mess in the future with flashes
> > containing
> > byte swapped content and we can't even fix it and we will have to live
> > with
> > that forever. IMHO right now is the best time to circumvent that
> > scenario.
> > I don't have anything against make it user configurable, but it should
> > be
> > an opt-out.
> > 
> 
> sounds good to me
> 
> > I haven't looked at any controllers who can do 8D-8D-8D accesses, 
maybe
> > most
> > of them can do the swapping on their own? So if you don't want to
> > support a
> > software fallback, then we should just say this mode isn't supported 
if
> > the controller can't do the byte swapping and we fall back to a slower
> > mode.
> 
> Software fallback or mode downgrade - both are good ideas.
> Pratyush, can your Octal SPI controller swap bytes on a 16 bit boundary?
> 
> The only debate that we have is whether to always swap (or downgrade),
> thus to have the same byte order as in 1-1-1, or to introduce a Kconfig 
option
> that will opt-out the swap, isn't it? Kconfig is a bit uglier, but 
> more flexible,
> and we still don't know for sure if the swap is mandatory or not. 
> Can someone from
> macronix shed some light on this topic?

The macronix in 8D-8D-8D mode always has to swap data during read and 
program
operations. Unfortunately this is our limitation, swap data at the flash 
layer
reduces performance and does not support dirmap mode. If the SPI 
controllers
all support swap data, everything is fine, but as far as I know, this is 
rare.

All in all, your opinions and comments are valuable. Moreover the learned 
lessons
could be input to next generation of OctaFlash.

Thanks,
Zhengxun


CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=====================================================================



============================================================================

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=====================================================================