Hi Sagar,
On Wed, Aug 28, 2019 at 1:46 PM Sagar Kadam sagar.kadam@sifive.com wrote:
Hello Bin,
On Tue, Aug 27, 2019 at 3:48 AM Bin Meng bmeng.cn@gmail.com wrote:
On Wed, Aug 14, 2019 at 1:08 AM Sagar Shrikant Kadam sagar.kadam@sifive.com wrote:
This patch series adds support for 32MiB SPI-NOR flash (is25wp256 from ISSI). Many thanks to Bhargav Shah bhargavshah1988@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