Messages in this thread | | | Date | Tue, 22 Feb 2022 15:27:44 +0100 | From | Michael Walle <> | Subject | Re: [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode |
| |
Am 2022-02-22 15:23, schrieb Tudor.Ambarus@microchip.com: > 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@microchip.com: >>> 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 another OS. So, there has to be *one correct* way of writing/reading these bytes.
-michael
| |