Hi Sagar, On Wed, Aug 28, 2019 at 1:46 PM Sagar Kadam <[email protected]> wrote: > > Hello Bin, > > On Tue, Aug 27, 2019 at 3:48 AM Bin Meng <[email protected]> wrote: > > > > On Wed, Aug 14, 2019 at 1:08 AM Sagar Shrikant Kadam > > <[email protected]> wrote: > > > > > > This patch series adds support for 32MiB SPI-NOR flash (is25wp256 from > > > ISSI). Many thanks to Bhargav Shah <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
