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.
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.
-michael
