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. >> > > 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. I would love to hear Macronix's opinion. Cheers, ta > >>> >>>> another OS. So, there has to be *one correct* way of writing/reading >>>> these >>>> bytes. >>>> >>> >>> >> >> -- >> Regards, >> Pratyush Yadav >> Texas Instruments Inc. > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/