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).
Also could you have a look at the schematics, does the IO3/RESET# have
a
pull-up? If not, who is in control of driving the correct value here?
If
it has a pull-up, I'm puzzled why you need any other setting than HiZ.
Unfortunately, there is no pullup on IO3 line and also there is no SoC
pullup.
See above.
-michael
The correct fix would be to the information about the missing IO state
in
the "struct spi_mem_op". That is, what should be the default values of
all
the IO lines which are unused. For example if we have a 1s1s4s
transaction, what should be the state of IO0,
IO2 and IO3 during the command and address phase. If we have a 1s2s2s,
what should be the state of IO0 during the command phase etc.
That can then be used within your driver to set the corresponding IOFV
values (for each spi-mem op).
But I'm not sure if other SPI controllers will support that, though.
Currently driving SoC IOFV register, it fixes the issue and it is just
one time
operation during post sfdp. I take this as a SoC feature which other
controllers
don't have.
Cheers,
Biju
