Re: [PATCH] hw/block: m25p80: Fix fast read for SST flashes

[Bin Meng]

Hi Francisco,

On Wed, Dec 16, 2020 at 6:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Francisco,
>
> On Wed, Dec 16, 2020 at 12:40 AM Francisco Iglesias
> <frasse.iglesias@gmail.com> wrote:
> >
> > Hello Bin,
> >
> > On [2020 Dec 12] Sat 17:44:27, Bin Meng wrote:
> > > Hi Francisco,
> > >
> > > On Sat, Dec 12, 2020 at 5:24 PM Francisco Iglesias
> > > <frasse.iglesias@gmail.com> wrote:
> > > >
> > > > Hi bin,
> > > >
> > > > On [2020 Dec 12] Sat 16:16:59, Bin Meng wrote:
> > > > > Hi Francisco,
> > > > >
> > > > > On Sat, Dec 12, 2020 at 12:11 AM Francisco Iglesias
> > > > > <frasse.iglesias@gmail.com> wrote:
> > > > > >
> > > > > > Hello Bin,
> > > > > >
> > > > > > On [2020 Dec 11] Fri 23:29:16, Bin Meng wrote:
> > > > > > > Hi Francisco,
> > > > > > >
> > > > > > > On Fri, Dec 11, 2020 at 11:16 PM Francisco Iglesias
> > > > > > > <frasse.iglesias@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hello Bin,
> > > > > > > >
> > > > > > > > On [2020 Dec 11] Fri 14:07:21, Bin Meng wrote:
> > > > > > > > > Hi Francisco,
> > > > > > > > >
> > > > > > > > > On Fri, Dec 4, 2020 at 7:28 PM Francisco Iglesias
> > > > > > > > > <frasse.iglesias@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hello Bin,
> > > > > > > > > >
> > > > > > > > > > On [2020 Dec 04] Fri 18:52:50, Bin Meng wrote:
> > > > > > > > > > > Hi Francisco,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Dec 4, 2020 at 6:46 PM Francisco Iglesias
> > > > > > > > > > > <frasse.iglesias@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hello Bin,
> > > > > > > > > > > >
> > > > > > > > > > > > On [2020 Dec 04] Fri 15:52:12, Bin Meng wrote:
> > > > > > > > > > > > > Hi Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Dec 3, 2020 at 4:38 PM Francisco Iglesias
> > > > > > > > > > > > > <frasse.iglesias@gmail.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Bin and Alistair,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On [2020 Dec 02] Wed 11:40:11, Alistair Francis 
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > On Sun, Nov 29, 2020 at 6:55 PM Bin Meng 
> > > > > > > > > > > > > > > <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > SST flashes require a dummy byte after the 
> > > > > > > > > > > > > > > > address bits.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I couldn't find a datasheet that says this... But 
> > > > > > > > > > > > > > > the actual code
> > > > > > > > > > > > > > > change looks fine, so:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Acked-by: Alistair Francis 
> > > > > > > > > > > > > > > <alistair.francis@wdc.com>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Alistair
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >  hw/block/m25p80.c | 3 +++
> > > > > > > > > > > > > > > >  1 file changed, 3 insertions(+)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > diff --git a/hw/block/m25p80.c 
> > > > > > > > > > > > > > > > b/hw/block/m25p80.c
> > > > > > > > > > > > > > > > index 483925f..9b36762 100644
> > > > > > > > > > > > > > > > --- a/hw/block/m25p80.c
> > > > > > > > > > > > > > > > +++ b/hw/block/m25p80.c
> > > > > > > > > > > > > > > > @@ -825,6 +825,9 @@ static void 
> > > > > > > > > > > > > > > > decode_fast_read_cmd(Flash *s)
> > > > > > > > > > > > > > > >      s->needed_bytes = get_addr_length(s);
> > > > > > > > > > > > > > > >      switch (get_man(s)) {
> > > > > > > > > > > > > > > >      /* Dummy cycles - modeled with bytes 
> > > > > > > > > > > > > > > > writes instead of bits */
> > > > > > > > > > > > > > > > +    case MAN_SST:
> > > > > > > > > > > > > > > > +        s->needed_bytes += 1;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1 dummy clk cycle is modelled as 1 byte write (see 
> > > > > > > > > > > > > > the comment above), so 1
> > > > > > > > > > > > > > dummy byte (8 dummy clk cycles) will need +8 above.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think you were confused by the WINBOND codes. The 
> > > > > > > > > > > > > comments are
> > > > > > > > > > > > > correct. It is modeled with bytes instead of bits, so 
> > > > > > > > > > > > > we should +=1.
> > > > > > > > > > > >
> > > > > > > > > > > > What the comment says is (perhaps not superclear) that 
> > > > > > > > > > > > 1 dummy clock cycle
> > > > > > > > > > > > is modeled as one 1 byte write into the flash (meaining 
> > > > > > > > > > > > that 8 byte writes
> > > > > > > > > > > > are needed for 1 dummy byte). Perhaps it is easier to 
> > > > > > > > > > > > understand
> > > > > > > > > > > > looking into how the controllers issue the command 
> > > > > > > > > > > > towards the flash model
> > > > > > > > > > > > (for example the xilinx_spips), the start of the 
> > > > > > > > > > > > FAST_READ cmd is issued
> > > > > > > > > > > > as writing the following into the flash: 1 byte (cmd), 
> > > > > > > > > > > > 3 bytes (address),
> > > > > > > > > > > > 8 bytes (8 dummy cycles -> 1 dummy byte).
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > My interpretation of the comments are opposite: one cycle 
> > > > > > > > > > > is a bit,
> > > > > > > > > > > but we are not using bits, instead we are using bytes.
> > > > > > > > > >
> > > > > > > > > > Yes, the mentioning of 'bits' in the comment makes it not 
> > > > > > > > > > very clear at first read.
> > > > > > > > > > Maybe just bellow would have been better:
> > > > > > > > > >
> > > > > > > > > > /* Dummy clock cycles - modeled with bytes writes */
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Testing shows that +=1 is the correct way with the 
> > > > > > > > > > > imx_spi controller,
> > > > > > > > > > > and with my SiFive SPI model in my local tree (not 
> > > > > > > > > > > upstreamed yet)
> > > > > > > > > >
> > > > > > > > > > Perhaps an option could be to look into how the aspeed_smc, 
> > > > > > > > > > xilinx_spips or the
> > > > > > > > > > npcm7xx_fiu generate dummy clock cycles and see if a 
> > > > > > > > > > similar solution to one of
> > > > > > > > > > those could work aswell for the imx_spi?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks for pointing this out. So there is some inconsistency 
> > > > > > > > > among
> > > > > > > > > different SPI controller modeling.
> > > > > > > >
> > > > > > > > I'm not sure I understand you correctly but the controllers 
> > > > > > > > supporting
> > > > > > > > commands with dummy clock cycles can only do it following the 
> > > > > > > > modeled
> > > > > > > > approach, so I would rather say it is pretty consistent across 
> > > > > > > > the
> > > > > > > > controllers (not all controllers support these commands though).
> > > > > > >
> > > > > > > I mean there are 2 approaches to emulate the dummy cycles for
> > > > > >
> > > > > > There is currently only 1 way of modeling dummy clock cycles. All 
> > > > > > commands that
> > > > > > require / support them in m25p80 goes with that approach. An the 
> > > > > > controllers
> > > > > > that support dummy clock cycles uses that approach.
> > > > >
> > > > > No, there are 2 ways. One way is how aspeed_smc, xilinx_spips and
> > > > > npcm7xx do for dummy cycles. For these controllers, there are hardware
> > > > > registers for dummy cycles, and software does not need to write
> > > > > anything into the tx fifo. These models emulate one dummy cycle by
> > > > > transferring one byte one the SPI line so we see there are actually a
> > > > > number of (bit * 8) bytes needed in decode_fast_read_cmd(). The other
> > > > > way is how imx_spi, mss-spi, pl022, stm32f2xx_spi and xilinx_spi. For
> > > > > these controllers, they just transfer whatever is written by guest
> > > > > software to tx fifo without any special awareness of dummy cycles.
> > > >
> > > >
> > > > The xilinx_spips supports above way of transferring a command so you 
> > > > can look
> > > > into that one for an example of how to handle a command pushed into a 
> > > > txfifo
> > > > with regards to the dummy clock cycles. Not all controllers support 
> > > > generating
> > > > dummy clock cycles, meaning that not all do the dummy byte -> dummy 
> > > > clock cycle
> > > > conversion. The controllers that do not do this currently does not 
> > > > support
> > > > issuing commands requiring them towards m25p80 (as FAST_READ, DOR, QOR 
> > > > etc..).
> > >
> > > No, I don't think inspecting tx fifo to decode the SPI command, and to
> > > insert dummy cycles when seeing FAST_READ is the correct way for these
> > > SPI controllers like imx_spi. The real hardware does not do this and
> > > we should not make them behave like xilinx_spips.
> >
> > Above is not correct, the xilinx_spips does not insert dummy clock cycles, 
> > it
> > converts the dummy bytes in the txfifo into the correct amount of dummy 
> > clock
> > cycles needed to be generated for the dummy byte based on the command and 
> > state
>
> I was referring to aspeed_smc codes. It multiplies the dummy cycles by
> 8 and calls ssi_transfer(). This to me is wrong. However I am not
> familiar with xilinx-spips and I surely could be wrong, like you said.
>
> > of the controller. For example if the command (as DOR) uses 2 lines when
> > transmitting the dummy byte it will issue 4 dummy clock cycles, if the 
> > command
> > uses 4 lines (example QIOR) it converts the dummy bytes into 2 dummy clock
> > cycles each.
>
> I will take some time to check the xilinx-spips spec. This might need some 
> time.
>
> >
> > How the hardware really works and how QEMU models it is not necessarly the
> > same, for the FAST_READ command the hardware will generate 8 dummy cycles of
>
> Agree, they should not be necessarily the same but for this case I was
> saying that type of hardware has no way to inspect the content being
> transferred hence for QEMU it's impossible to do that either.
>
> > the dummy byte (probably by shifting out the byte), currently the only way 
> > to
> > model this in QEMU is by making the controller convert the dummy
> > byte into 8 byte writes into m25p80 (there's no command in m25p80 modeling
> > this differently). If you would like to change this I think it is better if 
> > you
> > post a patch series demonstrating a solution that is better and also solves 
> > all
> > problems currently solved by the current one. Example problems (but not all)
> > are the ones mentioned above.
> >
>
> Anyway I will take a look at the xilinx_spips and propose something later.

It looks like the xilinx_spips.c supports 3 types of SPI controllers:

static void xilinx_spips_register_types(void)
{
    type_register_static(&xilinx_spips_info);
    type_register_static(&xilinx_qspips_info);
    type_register_static(&xlnx_zynqmp_qspips_info);
}

Dummy cycle handling happens in xilinx_qspips and xilinz_zynqmp_qspips codes.

Could you please provide some instructions on how to test these 2
controllers with upstream U-Boot or Linux?
I tried Zynqmp upstream U-Boot but it does not boot on QEMU. I
probably missed something.

Regards,
Bin