qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bin Meng <bmeng.cn@gmail.com>
To: "Alistair Francis" <alistair.francis@wdc.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Francisco Iglesias" <frasse.iglesias@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-block@nongnu.org,
	Marcin Krzeminski <marcin.krzeminski@nokia.com>,
	Bin Meng <bin.meng@windriver.com>,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Joe Komlodi <komlodi@xilinx.com>
Subject: [PATCH 2/9] hw/block: m25p80: Fix the number of dummy bytes needed for Numonyx/Micron flashes
Date: Thu, 14 Jan 2021 23:08:55 +0800	[thread overview]
Message-ID: <20210114150902.11515-3-bmeng.cn@gmail.com> (raw)
In-Reply-To: <20210114150902.11515-1-bmeng.cn@gmail.com>

From: Bin Meng <bin.meng@windriver.com>

Unfortunately the dummy cycle/bytes calculation for Numonyx/Micron
flashes is still wrong, even though there were fixes before that
tried to fix it.

First of all, the default number of dummy cycles is only related to
the SPI protocol mode. For QSPI it is 10, otherwise it is 8.

Secondly, per the datasheet [1], it's clear that in Quad I/O or Dual
I/O mode, the dummy bits show up on 4 or 2 lines.

The tricky part is the standard mode (extended mode). For such mode,
the dummy bits are not like other flashes that they show up on the
same lines as the address bits, but on the same lines as the data
bits, so for a Quad Output Fast Read command (6Bh), the dummy bits
must be sent on all the 4 IO lines. IOW, the total number of dummy
bits depend on the command.

The datasheet does not state crystal clearly how many lines are used
for 6Bh in the standard mode. We may only tell from figure 19 that is
showing the command sequence and interpret that dummy cycles need to
be on 4 lines for 6Bh.

Note as of today, both spi-nor drivers in U-Boot v2021.01 and Linux
v5.10 has the wrong assumption for all flashes that dummy cycle bus
width is the same as the address bits bus width, which is not true
for the Numonyx/Micron flash in the standard mode.

Last if the total number of dummy bits is not multiple of 8, log an
unimplemented message to notify user, and round it up. Right now the
QEMU ssi_transfer() API transfers one byte each time to the flash.
Leaving such as unimplemented will not cause any issue because as of
today both spi-nor drivers in U-Boot and Linux have the assumption
that the total number of dummy bits must be multiple of 8.

[1] https://media-www.micron.com/-/media/client/global/documents/products/
    data-sheet/nor-flash/serial-nor/n25q/n25q_512mb_1ce_3v_65nm.pdf

Fixes: 23af26856606 ("hw/block/m25p80: Fix Numonyx fast read dummy cycle count")
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---

 hw/block/m25p80.c | 62 +++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 57 insertions(+), 5 deletions(-)

diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index c947716f99..c8cd12a6d3 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -856,19 +856,71 @@ static uint8_t numonyx_extract_cfg_num_dummies(Flash *s)
     mode = numonyx_mode(s);
     num_dummies = extract32(s->volatile_cfg, 4, 4);
 
+    /*
+     * The default nubmer of dummy cycles is only related to the SPI
+     * protocol mode. For QSPI it is 10, otherwise it is 8.
+     */
     if (num_dummies == 0x0 || num_dummies == 0xf) {
+        num_dummies = (mode == MODE_QIO) ? 10 : 8;
+    }
+
+    /*
+     * Convert the number of dummy cycles to bytes
+     *
+     * Per the datasheet, it's clear that in Quad I/O or Dual I/O mode,
+     * the dummy bits show up on 4 or 2 lines.
+     *
+     * The tricky part is the standard mode (extended mode). For such
+     * mode, the dummy bits are not like other flashes that they show up
+     * on the same lines as the address bits, but on the same lines as
+     * the data bits, so for a Quad Output Fast Read command (6Bh), the
+     * dummy bits must be sent on all the 4 IO lines. IOW, the total
+     * number of dummy bits depend on the command.
+     *
+     * The datasheet does not state crystal clearly how many lines are
+     * used for 6Bh in the standard mode. We may only tell from figure 19
+     * that is showing the command sequence and interpret that dummy cycles
+     * need to be on 4 lines for 6Bh.
+     *
+     * Note as of today, both spi-nor drivers in U-Boot v2021.01 and Linux
+     * v5.10 has the wrong assumption for all flashes that dummy cycle bus
+     * width is the same as the address bits bus width, which is not true
+     * for the Numonyx/Micron flash in the standard mode.
+     */
+
+    if (mode == MODE_QIO) {
+        num_dummies *= 4;
+    } else if (mode == MODE_DIO) {
+        num_dummies *= 2;
+    } else {
         switch (s->cmd_in_progress) {
+        case QOR:
+        case QOR4:
         case QIOR:
         case QIOR4:
-            num_dummies = 10;
+            num_dummies *= 4;
             break;
-        default:
-            num_dummies = (mode == MODE_QIO) ? 10 : 8;
+        case DOR:
+        case DOR4:
+        case DIOR:
+        case DIOR4:
+            num_dummies *= 2;
             break;
-        }
+         }
+    }
+
+    /*
+     * If the total number of dummy bits is not multiple of 8, log an
+     * unimplemented message to notify user, and round it up.
+     */
+    if (num_dummies % 8) {
+        qemu_log_mask(LOG_UNIMP,
+                      "M25P80: the number of dummy bits is not multiple of 8");
+        num_dummies = ROUND_UP(num_dummies, 8);
     }
 
-    return num_dummies;
+    /* return the number of dummy bytes */
+    return num_dummies / 8;
 }
 
 static void decode_fast_read_cmd(Flash *s)
-- 
2.25.1



  parent reply	other threads:[~2021-01-14 15:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 15:08 [PATCH 0/9] hw/block: m25p80: Fix the mess of dummy bytes needed for fast read commands Bin Meng
2021-01-14 15:08 ` [PATCH 1/9] hw/block: m25p80: Fix the number of dummy bytes needed for Windbond flashes Bin Meng
2021-01-14 15:08 ` Bin Meng [this message]
2021-01-14 15:08 ` [PATCH 3/9] hw/block: m25p80: Fix the number of dummy bytes needed for Macronix flashes Bin Meng
2021-01-14 15:08 ` [PATCH 4/9] hw/block: m25p80: Fix the number of dummy bytes needed for Spansion flashes Bin Meng
2021-01-14 15:08 ` [PATCH 5/9] hw/block: m25p80: Support fast read for SST flashes Bin Meng
2021-01-14 15:08 ` [PATCH 6/9] hw/ssi: xilinx_spips: Fix generic fifo dummy cycle handling Bin Meng
2021-01-14 15:09 ` [PATCH 7/9] Revert "aspeed/smc: Fix number of dummy cycles for FAST_READ_4 command" Bin Meng
2021-01-14 15:09 ` [PATCH 8/9] Revert "aspeed/smc: snoop SPI transfers to fake dummy cycles" Bin Meng
2021-01-14 15:09 ` [PATCH 9/9] hw/ssi: npcm7xx_fiu: Correct the dummy cycle emulation logic Bin Meng
2021-01-14 17:12   ` Havard Skinnemoen via
2021-01-14 15:59 ` [PATCH 0/9] hw/block: m25p80: Fix the mess of dummy bytes needed for fast read commands Cédric Le Goater
2021-01-14 16:12 ` no-reply
2021-01-14 18:13 ` Francisco Iglesias
2021-01-15  2:07   ` Bin Meng
2021-01-15  3:29     ` Havard Skinnemoen via
2021-01-15 13:54       ` Bin Meng
2021-01-15 12:26     ` Francisco Iglesias
2021-01-15 14:38       ` Bin Meng
2021-01-18 10:05         ` Francisco Iglesias
2021-01-18 12:32           ` Bin Meng
2021-01-19 13:01             ` Francisco Iglesias
2021-01-20 14:20               ` Bin Meng
2021-01-21  8:50                 ` Francisco Iglesias
2021-01-21  8:59                   ` Bin Meng
2021-01-21 10:01                     ` Francisco Iglesias
2021-01-21 14:18                     ` Francisco Iglesias
2021-02-08 14:41                       ` Bin Meng
2021-02-08 15:30                         ` Edgar E. Iglesias
2021-02-09  9:35                           ` Francisco Iglesias
2021-04-23  6:45                         ` Bin Meng
2021-04-27  5:56                           ` Alistair Francis
2021-04-27  8:54                             ` Francisco Iglesias
2021-04-27 14:32                               ` Cédric Le Goater
2021-04-28 13:12                                 ` Bin Meng
2021-04-28 13:54                                   ` Cédric Le Goater

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210114150902.11515-3-bmeng.cn@gmail.com \
    --to=bmeng.cn@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=bin.meng@windriver.com \
    --cc=f4bug@amsat.org \
    --cc=frasse.iglesias@gmail.com \
    --cc=komlodi@xilinx.com \
    --cc=kwolf@redhat.com \
    --cc=marcin.krzeminski@nokia.com \
    --cc=mreitz@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).