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

[Biju Das]

Hi Michael Walle,

> Subject: Re: [PATCH RFC 0/4] Add set_iofv() callback
> 
> Am 2023-11-11 13:26, schrieb Biju Das:
> > Hi Michael Walle,
> >
> >> Subject: RE: [PATCH RFC 0/4] Add set_iofv() callback
> >>
> >
> >>
> >> > Subject: Re: [PATCH RFC 0/4] Add set_iofv() callback
> >> >
> >> > 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).
> >>
> >> Part is MT25QU512ABB8E12-0SIT, As per the schematic, flash has a
> >> dedicated RESET# with 10K pullup connected to SoC QSPI_RESET pin.
> >>
> >> DQ0, DQ1, W#/DQ2 and DQ3 lines on the flash are connected without any
> >> pullups to the SoC QSPI0_{0..3} pins.
> >>
> >> >
> >> > 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?
> >>
> >> I am booting from NOR flash. BootRom code reads SPI flash and
> >> executes BL2.
> >> BL2 loads BL33 and U-boot from NOR flash. If this is the case, do you
> >> think it is a Hw bug on the board?
> >>
> >> >
> >> > > 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).
> >>
> >> Thanks for the pointer, I haven't explored the uboot path.
> >
> > I have disabled RESET# bit in the Nonvolatile Configuration Register
> > (Table 7) and borad doesn't boot any more.
> >
> > By default that bit is set.
> >
> > [    2.530291] ###### Before write Read cmd=b5 val=ff
> > [    2.530431] ###### write cmd=b1 val=ef
> > [    2.535518] ###### Read cmd=b5 val=ef
> >
> >
> > NOTICE:  BL2: Built : 14:59:28, Nov 10 2023
> > ERROR:   BL2: Failed to load image id 3 (-2)
> > NOTICE:  BL2: v2.9(release):v2.5/rzg2l-1.00-3883-gc314a391c
> > NOTICE:  BL2: Built : 14:59:28, Nov 10 2023
> > ERROR:   BL2: Failed to load image id 3 (-2)
> > NOTICE:  BL2: v2.9(release):v2.5/rzg2l-1.00-3883-gc314a391c
> >
> > What is your thoughts on this? How do we proceed now?
> 
> I guessed you fixed this? Because.. if you boot from NOR the BL2 should
> come from the NOR flash too, correct? And that is actually working.

Yes, it is working.

I updated the NV settings on micron flash on the second RZ/G2L board and 
both boards seems to be working(ie, by disabling RESET# on DQ3) and using IOFV state as hiZ.

I am planning to update NV stings on micron flash for 2 more boards (RZ/G2LC and RZ/V2L).

After that I will send a patch using IOFV {3,3,3,3} for both micron and Adesto flash.

and will request the bootloader team to disable RESET# on DQ3 using NV register.

Cheers,
Biju