Hi Jagan,
On Sun, Apr 5, 2020 at 2:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
Hi Bin,
On Mon, Nov 18, 2019 at 8:19 AM Bin Meng bmeng.cn@gmail.com wrote:
Hi Segar Kadam,
On Mon, Nov 18, 2019 at 4:59 AM Sagar Kadam sagar.kadam@sifive.com wrote:
Hello Jagan/Bin,
-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Bin Meng Sent: Monday, November 11, 2019 8:02 PM To: Jagan Teki jagan@amarulasolutions.com Cc: Palmer Dabbelt ( Sifive) palmer@sifive.com; U-Boot Mailing List <u- boot@lists.denx.de>; linux-amarula linux-amarula@amarulasolutions.com Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
Hi Jagan,
On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki jagan@amarulasolutions.com wrote:
Hi Bin,
On Tue, Oct 29, 2019 at 3:50 PM Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Tue, Oct 29, 2019 at 5:38 PM Bin Meng bmeng.cn@gmail.com
wrote:
> > Hi Jagan, > > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki
jagan@amarulasolutions.com wrote:
> > > > HiFive Unleashed A00 support is25wp256 spi-nor flash, > > So enable the same and add test result log for future > > reference. > > > > Tested on SiFive FU540 board. > > > > Signed-off-by: Jagan Teki jagan@amarulasolutions.com > > Reviewed-by: Bin Meng bmeng.cn@gmail.com > > Tested-by: Bin Meng bmeng.cn@gmail.com > > --- > > .../dts/hifive-unleashed-a00-u-boot.dtsi | 1 + > > board/sifive/fu540/Kconfig | 3 +++ > > doc/board/sifive/fu540.rst | 19 +++++++++++++++++++ > > 3 files changed, 23 insertions(+) > > > > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > index 25ec8265a5..d7a64134db 100644 > > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi > > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi > > @@ -5,6 +5,7 @@ > > > > / { > > aliases { > > + spi0 = &qspi0; > > spi2 = &qspi2; > > }; > > }; > > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig > > index 5d65080429..c5a1bca03c 100644 > > --- a/board/sifive/fu540/Kconfig > > +++ b/board/sifive/fu540/Kconfig > > @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy > > imply CMD_FS_GENERIC > > imply CMD_NET > > imply CMD_PING > > + imply CMD_SF > > imply CLK_SIFIVE > > imply CLK_SIFIVE_FU540_PRCI > > imply DOS_PARTITION > > @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy > > imply SIFIVE_SERIAL > > imply SPI > > imply SPI_SIFIVE > > + imply SPI_FLASH > > + imply SPI_FLASH_ISSI > > imply MMC > > imply MMC_SPI > > imply MMC_BROKEN_CD > > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst > > index 91b94ee06f..2e70cad02e 100644 > > --- a/doc/board/sifive/fu540.rst > > +++ b/doc/board/sifive/fu540.rst > > @@ -366,3 +366,22 @@ load uImage. > > > > Please press Enter to activate this console. > > / # > > + > > +Sample spi nor flash test > > +------------------------- > > + > > +.. code-block:: none > > + > > + => sf probe 0:2 > > The cs number can't be 2. It should be zero.
With this patch series, we got crazy duplicated flash devices created, see below:
=> sf probe unrecognized JEDEC id bytes: ff, ff, ff Failed to initialize SPI flash at 0:0 (error -2) => sf probe 0:2 SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32
MiB
=> sf probe 0:4 SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32
MiB
=> sf probe 0:6 SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32
MiB
=> dm tree Class Index Probed Driver Name
root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] generic_simple_bus |-- soc clk 0 [ + ] sifive-fu540-prci | |-- clock-controller@10000000 serial 0 [ + ] serial_sifive | |-- serial@10010000 serial 1 [ ] serial_sifive | |-- serial@10011000 spi 0 [ + ] sifive_spi | |-- spi@10040000 spi_flash 0 [ ] spi_flash_std | | |-- flash@0 spi_flash 1 [ + ] spi_flash_std | | |-- spi_flash@0:2 spi_flash 2 [ + ] spi_flash_std | | |-- spi_flash@0:4 spi_flash 3 [ + ] spi_flash_std | | `-- spi_flash@0:6
With my patch series below http://patchwork.ozlabs.org/project/uboot/list/?series=129736
the CS number check was added to the SPI flash hence we got:
=> sf probe unrecognized JEDEC id bytes: ff, ff, ff Failed to initialize SPI flash at 0:0 (error -2) => sf probe 2 Invalid cs 2 (err=-22) Invalid cs 2 (err=-22) Invalid chip select 0:2 (err=-22) Failed to initialize SPI flash at 0:2 (error -22) => sf probe 4 Invalid cs 4 (err=-22) Invalid cs 4 (err=-22) Invalid chip select 0:4 (err=-22) Failed to initialize SPI flash at 0:4 (error -22)
So we still need figure out why CS number 0 cannot work on SiFive.
The existing quad wire that driver pushing for flash seems not detecting flash at CS 0 so making cr to single wire detecting flash at
I vaguely remember someone from SiFive posted a patch that forced the SPI controller to work under single wire mode. Maybe someone from SiFive could help explain the weird behavior as you mentioned.
Sorry, I had not been closely looking into this thread. Yes, the initial patch posted was to add support for is25wp256 device. https://patchwork.ozlabs.org/patch/1146523/ but it seems it was bricking the board, and later couldn't follow-up on this. IIUC, spi_nor_scan has default reg_proto set to 1_1_1, and further parses slave mode and accordingly sets the hwcaps fields. Now since the device tree set's the slave mode to 4 bit mode based on the tx-bus-width, this creates a conflict due to which reg_read fails and so the sf probe fails too.
The strange thing is that the 'sf probe' only fails at CS 0, but succeeds at CS 2/4/6/8/...
Is this strange behavior caused by the default reg_proto set to 1_1_1 in spi_nor_scan()?
Now forcing the SPI-controller in single wire mode helped the sf probe to detect the flash. Alternatively I think if we use bitlen passed by spi_mem_exec_op and prepare spi transfer's in controller based on max of t->rx_nbits, t->tx_nbits as done in linux driver this should work. Any thoughts on this?
Maybe Jagan can comment this.
Looks like there are several issues to make this flash to work, one with a probe and others are handling cs between transfer and flash bfpt fixes.
probe failed with cs 0 (or even with other cs numbers) because of improper bitlen, spi-nor sending fast read (mean single wire) initially but the driver checks the bitlen based on slave->mode (which is from dts) ie is quad.
Thank you for looking into this. Could you please work with Sagar to come up with a new version patch that fix all these issues?
Default behaviour:
=> sf probe 0:0 sifive_spi_prep_transfer: QUAD sifive_spi_prep_transfer: QUAD unrecognized JEDEC id bytes: ff, ff, ff Failed to initialize SPI flash at 0:0 (error -2) => sf probe 0:1 Invalid cs 1 (err=-22) Invalid cs 1 (err=-22) Invalid chip select 0:1 (err=-22) Failed to initialize SPI flash at 0:1 (error -22) => sf probe 0:2 Invalid cs 2 (err=-22) Invalid cs 2 (err=-22) Invalid chip select 0:2 (err=-22) Failed to initialize SPI flash at 0:2 (error -22)
With , update the cr bits based on bitlen instead of slave->mode:
=> sf probe sifive_spi_prep_transfer: SINGLE sifive_spi_prep_transfer: SINGLE sifive_spi_prep_transfer: SINGLE sifive_spi_prep_transfer: SINGLE SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB => sf probe 0:1 Invalid cs 1 (err=-22) Invalid cs 1 (err=-22) Invalid chip select 0:1 (err=-22) Failed to initialize SPI flash at 0:1 (error -22)
Regards, Bin