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
another OS. So, there has to be *one correct* way of writing/reading
these
bytes.
-michael
