[U-Boot] [U-BOOT PATCH 0/3] add support for spi-nor device on HiFive Unleashed board

Bin Meng bmeng.cn at gmail.com
Wed Aug 28 06:18:47 UTC 2019


Hi Sagar,

On Wed, Aug 28, 2019 at 1:46 PM Sagar Kadam <sagar.kadam at sifive.com> wrote:
>
> Hello Bin,
>
> On Tue, Aug 27, 2019 at 3:48 AM Bin Meng <bmeng.cn at gmail.com> wrote:
> >
> > On Wed, Aug 14, 2019 at 1:08 AM Sagar Shrikant Kadam
> > <sagar.kadam at sifive.com> wrote:
> > >
> > > This patch series adds support for 32MiB SPI-NOR flash (is25wp256 from
> > > ISSI). Many thanks to Bhargav Shah <bhargavshah1988 at gmail.com> for
> > > porting the spi-nor patches from linux to U-boot in order to support
> > > this device.
> > > Ref: linux patches which are under review
> > > https://lkml.org/lkml/2019/7/2/859
> > >
> > > Linux has an option of registering post-bfpt fixups in order to over-ride
> > > the incorrect configuration of flash devices due to wrong SFDP entries read
> > > from the flash device during nor scan phase. The 1st patch introduces this
> > > support to register post bfpt fixup hook similar to that done in linux.
> > >
> > > The second patch in the series enables support for the flash device in
> > > single I/O mode. A post bfpt fixup is registered because the flash device
> > > gets BFPT_DWORD1_ADDRESS_BYTES_3_ONLY from BFPT table for address width,
> > > whereas the flash can support 4 byte address width.
> > > The SPI_NOR_HAS_BP3 bit indicates that the flash protection block has BP0
> > > to BP3 bits.
> > >
> > > Lock/Unlock mechanism:
> > > The implementation is based on stm_lock/unlock scheme and is validated for
> > > different number of blocks passed to sf command. Unlock scheme unilateraly
> > > clears all the protection bits of all blocks in the status register.
> > >
> > > The series is based on the master branch of[1]
> > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-riscv
> > >
> > > and is available in dev/sagark/hifive-spi-nor_v2 branch of[2]
> > > [2] https://github.com/sagsifive/u-boot.
> > >
> > > Flash operations like erase/read/write lock/unlock are verified and
> > > data integrity is checked using sf commands as follows:
> > >
> > > => sf write 0x80600000 0x0 0x2000000
> > > device 0 whole chip
> > > SF: 33554432 bytes @ 0x0 Written: OK
> > > => sf read 0x82700000 0x0 0x2000000
> > > device 0 whole chip
> > > SF: 33554432 bytes @ 0x0 Read: OK
> > > => cmp.b 0x80600000 0x82700000 0x2000000
> > > Total of 33554432 byte(s) were the same
> > >
> > > => sf protect lock 0x1000000 0x1000000
> > > => mw 0x80600000 0x12345678 0x2000000
> > > => sf write 0x80600000 0x0 0x2000000
> > >    Reset the board to flush out data from memory
> > > => sf probe
> > > => sf read 0x80600000 0x0 0x2000000
> > >    In memory dump after sf read from address 0x80600000 we can see that
> > >    upper 16MiB flash section is protected.
> > >
> > >
> > > Sagar Shrikant Kadam (3):
> > >   spi: nor: add spi-nor-fixup handlers for nor devices
> > >   spi: nor: add support for is25wp256
> > >   spi: riscv: use single bit mode for spi transfers
> > >
> > >  board/sifive/fu540/Kconfig     |   5 +
> > >  drivers/mtd/spi/sf_internal.h  |  23 +++
> > >  drivers/mtd/spi/spi-nor-core.c | 373 +++++++++++++++++++++++++++++++++++------
> > >  drivers/mtd/spi/spi-nor-ids.c  |   5 +
> > >  drivers/spi/spi-sifive.c       |   7 +-
> > >  include/linux/mtd/spi-nor.h    |   8 +
> > >  6 files changed, 363 insertions(+), 58 deletions(-)
> > >
> > > --
> >
> > Warning! This patch series will brick the HiFive Unleashed board.
> >
> > What I did was only:
> > => sf probe
> >
> > everything looks good as long as you don't power off the board.
> >
> > But when you power off the board and power on, there is no console
> > output anymore.
> >
> Does disconnecting and connecting back the terminal emulator work here?

No.

>
> > I then re-flashed the board using SD card rescue image, and confirmed
> > that this single "sf probe" command will brick the board (once again!)
> >
> I would like to understand the situation here can you please elaborate it, so
> that I can reproduce it at my end.
> What is the boot mode you are using to test these patches?

MSEL = 1111

> Are you loading fsbl and U-boot from Flash or from SD Card?

FSBL in SPI, and OpenSBI/U-Boot in SD.

Regards,
Bin


More information about the U-Boot mailing list