[PATCH RFC 0/4] Add set_iofv() callback

[Michael Walle]

Hi Biju,

>> >> >> Thus I was saying, that we probably wont support that and the
>> >> >> easiest fix should be to disable this behavior for the atmel flash
>> >> >> (there was nv setting).
>> >> >
>> >> > The fix up is invoked only for quad mode, I believe it is safe to
>> >> > add fixup for micron flash As it is the one deviating from normal
>> >> > according to you, rather than adding fixup for generic flash like
>> >> > ATMEL flash(Now Renesas flash)
>> >>
>> >> Could you please try setting bit 4 in the Nonvolatile Configuration
>> >> Register (Table 7) and see if the problem goes away?
>> >
>> > You mean, if it works, we need to disable reset for all the boards,
>> > maybe at bootloader level??
>> 
>> Not necessarily. First, just to confirm that it is actually the reset
>> circuit. You can also compare the part numbers of the flash. There is 
>> a
>> flash with IO3/RESET# and IO3/HOLD# (and a flash with a dedicated 
>> reset
>> pin).
>> 
>> If that's the case, it looks like a hardware bug on your board. You 
>> left
>> the reset pin floating. So you'd also not be able to boot from the NOR
>> flash, right?
>> 
>> > OK, I will check that. Currently I have read that register and it is
>> > showing a value Of 0xffbb. I need to do write operation. Before that
>> > how do we recover flash, if something goes wrong during writing for NV
>> > register?
>> 
>> You should always be able to write that register from the bootloader.
>> Maybe also through raw commands (like sspi in uboot).
> 
> Just an update, now clearing bit4 on Micron flash, I am able to test 
> erase/read/write
> Micron flash with IOFV state {3,3,3,3}. Not sure what went wrong 
> previously.
> only thing I changed is related to enabling the QUAD spi mode by 
> disabling bit 2 and 3 on NV register.

This enables QPI mode, that is the command is also expected to be
transferred over the four IO lines. That's not something linux supports.

We'll always send the command in single bit mode (the only exception is
octal DTR mode).

> This again result in boot failure as boot ROM expects extended SPI 
> mode.
> Then restored the extended SPI mode by sending the command FFh (Power 
> Loss and Interface Rescue)
> by booting from eMMC.
> 
> At least one board with micron flash is now working with IOFV state 
> {3,3,3,3}.
> I need to test more boards to confirm the behaviour.

I'm still trying to make sense of this (and trying to figure out
if we need something or not).

So you have a MT25QU512ABB8E12-0SIT, which according to to Figure 4 and
Figure 5 has a dedicated RESET# line and the IO3 is multiplexed with 
HOLD#.
Thus, it seems the flash will go into hold mode if IO3 is not high 
during
command phase. Wether this is a hardware bug? I'd tend to say yes. As 
with
the RESET# you depend on the software/bootROM whatever to set the state 
of
IO3 correctly. But it might depend on the SPI controller used etc. Maybe
it will already drive IO3 high by default?! (and esp. what the bootROM 
is doing
if that SoC is able to load the first stage bootloader from NOR).

I still see two possible fixes here:
(1) Disable HOLD#, either during board production, in your 
bootloader/TFA
     or by introducing a fixup for this flash in linux.
     (And configure your SPI controller to use IOFV state 3,3,3,3 as that
     should be the sane default).
(2) Introduce a mechanism to spi_mem_op to control the unused bits (as
     explained in an earlier reply). Then somehow integrate that into
     the spi-nor micron driver to set IO3 to this pariticular value for
     this operation.

Alternatively, fix your board to have a weak pull-up on IO3 so the IOFV
state 3,3,3,3 will work.

HTH,
-michael