[U-Boot] Reg. CFI flash_init and hardware write protected devices

[Frank Svendsbøe]

On Thu, Jun 23, 2011 at 5:21 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Frank,
>
> In message <BANLkTinFMA7FN-BD7z2-ZYAT+-ubWn7S9Q at mail.gmail.com> you wrote:
>>
>> A few weeks ago, I applied this change and everything worked fine in
>> U-Boot. However, I didn't succeed doing the same hack in Linux. I've
>> done some hardcoding experiments in drivers/mtd/chips/cfi_probe.c, but
>> so far no success. After reading some CFI manuals, it seems CFI
>> will/should use bus write operations even during CFI read operations.
>
> What exactly do you mean by "CFI read operations"?
>

Good question. When reading Intels CFI manual I was referring to
something called "read array" which used bus write commands. I guess
normal byte/word read access don't utilize this then.

>> Can you confirm this? Then my next question is how come U-Boot read
>> operations works by just hardcoding the flash geometry. It seems
>> U-Boot utilize just plain localbus accesses to read flash data, ie.
>> not the "CFI protocol". What did I miss here.. ?
>
> It seems you misunderstand the different modes.  In command mode, you
> will use the specific command sequences defined in the CFI protocol to
> talk to the controller poart of the flash chip. In this mode, you can
> read for example query information, flash geometry data, status
> information, etc.  Yes, any such command sequence includes write
> operations to the flash device, even when you actually want to read
> some specific data.  In data mode, flash is working just as normal
> real-only memory. No specific protocol is used, you just use plain
> read accesses to read the user data programmed into the flash chip.
>

Right, and thanks for the explanation. What I've done to U-Boot is
bypass the probing which uses the command mode and thus avoid getting
problems with bus write accesses when flash protection is on.

> Any kind of probing, auto-identification etc. of the flash chip will
> need to use CFI command sequences, and thus write access to the
> device.  As long as you just want to read the data or execute code
> from the flash no write accesses are needed.
>
>> Now I'm considering two options: 1) Either write a custom flash map
>> driver, and access the flash the same way U-Boot does, or 2) try to
>> convince the FPGA designers that our way of forcing write protection
>> is not according the the CFI specifications, and should be done
>> otherwise. What do you think is the best solution?
>
> Linux can also read from ROM memory. You just have to make sure that
> you do not try to run the normal CFI flash drivers on your flash
> devices - these will not work, because they will try to probe the
> flash chips.
>

Yes, well I tried to fool Linux's CFI driver too, but no luck so far.
It was after this I started reading about CFI and came to the (wrong)
conclusion that CFI uses bus write operations during read accesses
too.

>> Is there anybody else out there supporting hardware write protection
>> on CFI devices?
>
> CFI flash chips with the level of write protection you implemented
> have to be dealt with in the same way as other ROM memory.  Normal CFI
> driver are not appropriate here.
>

Ok. So you recommend I stop "hacking" the CFI probing and instead
write a custom flash map driver?

Best regards,
Frank