On Tue, Jul 24 2018, Brian Norris wrote: > Hi, > > On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote: >> On Tue, Jul 24 2018, Boris Brezillon wrote: >> > On Tue, 24 Jul 2018 08:46:33 +1000 >> > NeilBrown <[email protected]> wrote: >> >> One possibility that occurred to me when I was exploring this issue is >> >> to revert to 3-byte mode whenever 4-byte was not actively in use. >> >> So any access beyond 16Meg is: >> >> switch-to-4-byte ; perform IO ; switch to 3-byte >> >> or similar. On my hardware it would be more efficient to >> >> use the 4-byte opcode to perform the IO, then reset the cached >> >> 4th address byte that the NOR chip transparently remembered. > > Do these chips cache the last 4th-byte used? I don't recall reading > that, but that would be interesting. It also sounds like that would make > things even more difficult to do robustly.
That is how the Winbond W25Q256FV appears to behave in my experiments.
Any time you use a 4-byte address, the high byte is saved. Any time you
use a 3-byte address, the saved high-byte is used.
The data sheet seems to support this understanding, as detailed in
Commit: f134fbbb4ff8 ("mtd: spi-nor: clear Winbond Extended Address Reg on
switch to 3-byte addressing.")
>
>> >> This adds a little overhead, but should be fairly robust.
>> >> It doesn't help if something goes terribly wrong while IO is happening,
>> >> but I don't think any other software solution does either.
>> >>
>> >> How would you see that approach?
>> >
>> > I think the problem stands: people that have proper HW mitigation for
>> > this problem (NOR chip is reset when the Processor is reset) don't want
>> > to pay the overhead. So, even if we go for this approach, we probably
>> > want to only do that for broken HW.
>
> If it actually saves bytes on the wire to stay in 3-byte mode more
> often, then that could be helpful to all systems. But otherwise, yes, it
> doesn't really belong on a properly-designed system.
I'm not sure exactly what you encompass by the term "properly-designed",
but with the SOC that I have (mt7621) and the flash chip (Winbond
W25Q256FV) it is not possible to wire them up in any way that will work
reliably without software support for leaving 3-byte mode.
The SOC does not have an out-going reset line that signals a general
system reset - it only has one that signals watchdog reset.
The flash chip has an incoming reset line, but it shares a pin with
"hold", and that is the default use. So we would need to program the
flash to listen for reset, and it would only catch a watchdog reset.
For any other reset, the CPU is (should be) in complete control (even
after a panic!) and it needs to reprogram the flash chip before
resetting the system.
But maybe you think either the SOC and/or the flash chip is not
"properly-designed" - and you may be correct..
Thanks,
NeilBrown
>
>> I agree that a "my-hardware-is-suboptimal" flag is appropriate.
>> I was addressing the suggestion that the current approach doesn't handle
>> all corner cases and was suggesting a different approach that might
>> handle more corner-cases. I should have been more explicit about that.
>
> If you want to talk about optimizing the broken-hardware hack, then
> fine. That's not my interest at all.
>
> Brian
signature.asc
Description: PGP signature
