Hello Bin, On Tue, Aug 27, 2019 at 3:48 AM Bin Meng <bmeng...@gmail.com> wrote: > > On Wed, Aug 14, 2019 at 1:08 AM Sagar Shrikant Kadam > <sagar.ka...@sifive.com> wrote: > > > > This patch series adds support for 32MiB SPI-NOR flash (is25wp256 from > > ISSI). Many thanks to Bhargav Shah <bhargavshah1...@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?
> 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? Are you loading fsbl and U-boot from Flash or from SD Card? Thanks & BR, Sagar Kadam > Regards, > Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
