[U-Boot] Problem with attaching UBI partition
Dear U-Boot support,
I have problems while running following commands in U-Boot:
U-Boot => sf probe 0 0 0 SF: Detected S25FL512S with page size 512, total: 67108864
U-Boot => mtdparts device nor0 <snor0>, # parts = 4 #: name size offset mask_flags 0: boot 0x00100000 0x00000000 0 1: bootenv 0x00080000 0x00100000 0 2: SomeInfo 0x01980000 0x00180000 0 3: ubifspart 0x02500000 0x01b00000 0
U-Boot => ubi part ubifspart mtd: Giving out device 1 to mtd=3 ubi0: attaching mtd1 UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48 UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20 UBI DBG gen (pid 1): min_io_size 1 UBI DBG gen (pid 1): max_write_size 512 UBI DBG gen (pid 1): hdrs_min_io_size 1 UBI DBG gen (pid 1): ec_hdr_alsize 64 UBI DBG gen (pid 1): vid_hdr_alsize 64 UBI DBG gen (pid 1): vid_hdr_offset 64 UBI DBG gen (pid 1): vid_hdr_aloffset 64 UBI DBG gen (pid 1): vid_hdr_shift 0 UBI DBG gen (pid 1): leb_start 128 UBI DBG gen (pid 1): max_erroneous 16 UBI DBG gen (pid 1): process PEB 0 UBI DBG bld (pid 1): scan PEB 0 UBI DBG io (pid 1): read EC header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:0 ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead of 55424923 Erase counter header dump: magic 0xff554249 version 35 ec 0 vid_hdr_offset 16777216 data_offset 1073741824 image_seq -2142856561 hdr_crc 0xe046ed erase counter header hexdump: UBI DBG bld (pid 1): bad magic number at PEB 0: ff554249 instead of 55424923 UBI DBG io (pid 1): read VID header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:64 UBI DBG bld (pid 1): no VID header found at PEB 0, only 0xFF bytes UBI DBG bld (pid 1): add to erase: PEB 0, EC -1
... // this warning goes for all PEBs from 1 to 147
ubi0: scanning is finished UBI DBG gen (pid 1): max. sequence number: 0 ubi0 error: ubi_read_volume_table: the layout volume was not found ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22 UBI error: cannot attach mtd1 UBI error: cannot initialize UBI, error -22 UBI init error 22 UBI init error 22
For me it looks like this magic number is shifted one byte right, although I can't understand why.
Here is how I create UBI partition in Linux env:
Linux Env #> mtdinfo -a
mtd5 Name: data Type: nor Eraseblock size: 262144 bytes, 256.0 KiB Amount of eraseblocks: 148 (38797312 bytes, 37.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:10 Bad blocks are allowed: false Device is writable: true
Linux Env #> ubiformat /dev/mtd5
ubiformat: mtd5 (nor), size 38797312 bytes (37.0 MiB), 148 eraseblocks of 262144 bytes (256.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 147 -- 100 % complete ubiformat: 148 eraseblocks are supposedly empty ubiformat: formatting eraseblock 147 -- 100 % complete 797312
Linux Env #> ubiattach -m 5 /dev/ubi_ctrl
UBI: attaching mtd5 to ubi0 UBI: scanning is finished UBI: attached mtd5 (name "part5", size 37 MiB) to ubi0 UBI: PEB size: 262144 bytes (256 KiB), LEB size: 262016 bytes UBI: min./max. I/O unit sizes: 1/256, sub-page size 1 UBI: VID header offset: 64 (aligned 64), data offset: 128 UBI: good PEBs: 148, bad PEBs: 0, corrupted PEBs: 0 UBI: user volume: 0, internal volumes: 1, max. volumes count: 128 UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1371523162 UBI: available PEBs: 144, total reserved PEBs: 4, PEBs reserved for bad PEB handling: 0 UBI: background thread "ubi_bgt0d" started, PID 1003
Linux Env #> ubimkvol -N data -m /dev/ubi0
Linux Env #> mount -t ubifs ubi0:data /mnt
Linux Env #> mount -t ubifs ubi0:data /mnt
UBIFS: default file-system created UBIFS: background thread "ubifs_bgt0_0" started, PID 1010 UBIFS: mounted UBI device 0, volume 0, name "data" UBIFS: LEB size: 262016 bytes (255 KiB), min./max. I/O unit sizes: 8 bytes/256 bytes UBIFS: FS size: 35110144 bytes (33 MiB, 134 LEBs), journal size 2096129 bytes (1 MiB, 7 LEBs) UBIFS: reserved for root: 1658338 bytes (1619 KiB) UBIFS: media format: w4/r0 (latest is w4/r0), UUID 696FFD7B-1957-4ABD-9FDC-ED0EEB674D9D, small LPT model
It's perfectly working from Linux env, however U-Boot don't want to attach UBI partition.
Please help me identify the problem!
Best regards, Denis Bakhvalov
Hello Dennis,
Am 22.02.2016 um 15:17 schrieb Bakhvalov, Denis (Nokia - PL/Wroclaw):
Dear U-Boot support,
I have problems while running following commands in U-Boot:
Which U-Boot version? Which board?
U-Boot => sf probe 0 0 0 SF: Detected S25FL512S with page size 512, total: 67108864
U-Boot => mtdparts device nor0 <snor0>, # parts = 4 #: name size offset mask_flags 0: boot 0x00100000 0x00000000 0 1: bootenv 0x00080000 0x00100000 0 2: SomeInfo 0x01980000 0x00180000 0 3: ubifspart 0x02500000 0x01b00000 0
U-Boot => ubi part ubifspart mtd: Giving out device 1 to mtd=3 ubi0: attaching mtd1 UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48 UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20 UBI DBG gen (pid 1): min_io_size 1 UBI DBG gen (pid 1): max_write_size 512 UBI DBG gen (pid 1): hdrs_min_io_size 1 UBI DBG gen (pid 1): ec_hdr_alsize 64 UBI DBG gen (pid 1): vid_hdr_alsize 64 UBI DBG gen (pid 1): vid_hdr_offset 64 UBI DBG gen (pid 1): vid_hdr_aloffset 64 UBI DBG gen (pid 1): vid_hdr_shift 0 UBI DBG gen (pid 1): leb_start 128 UBI DBG gen (pid 1): max_erroneous 16 UBI DBG gen (pid 1): process PEB 0 UBI DBG bld (pid 1): scan PEB 0 UBI DBG io (pid 1): read EC header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:0 ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead of 55424923 Erase counter header dump: magic 0xff554249
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
I am currently on the EW 2016 in nuernberg, I could not look deeper here... I think try to check your spi nor flash driver...
bye, Heiko
version 35 ec 0 vid_hdr_offset 16777216 data_offset 1073741824 image_seq -2142856561 hdr_crc 0xe046ederase counter header hexdump: UBI DBG bld (pid 1): bad magic number at PEB 0: ff554249 instead of 55424923 UBI DBG io (pid 1): read VID header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:64 UBI DBG bld (pid 1): no VID header found at PEB 0, only 0xFF bytes UBI DBG bld (pid 1): add to erase: PEB 0, EC -1
... // this warning goes for all PEBs from 1 to 147
ubi0: scanning is finished UBI DBG gen (pid 1): max. sequence number: 0 ubi0 error: ubi_read_volume_table: the layout volume was not found ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22 UBI error: cannot attach mtd1 UBI error: cannot initialize UBI, error -22 UBI init error 22 UBI init error 22
For me it looks like this magic number is shifted one byte right, although I can't understand why.
Here is how I create UBI partition in Linux env:
Linux Env #> mtdinfo -a
mtd5 Name: data Type: nor Eraseblock size: 262144 bytes, 256.0 KiB Amount of eraseblocks: 148 (38797312 bytes, 37.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:10 Bad blocks are allowed: false Device is writable: true
Linux Env #> ubiformat /dev/mtd5
ubiformat: mtd5 (nor), size 38797312 bytes (37.0 MiB), 148 eraseblocks of 262144 bytes (256.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 147 -- 100 % complete ubiformat: 148 eraseblocks are supposedly empty ubiformat: formatting eraseblock 147 -- 100 % complete 797312
Linux Env #> ubiattach -m 5 /dev/ubi_ctrl
UBI: attaching mtd5 to ubi0 UBI: scanning is finished UBI: attached mtd5 (name "part5", size 37 MiB) to ubi0 UBI: PEB size: 262144 bytes (256 KiB), LEB size: 262016 bytes UBI: min./max. I/O unit sizes: 1/256, sub-page size 1 UBI: VID header offset: 64 (aligned 64), data offset: 128 UBI: good PEBs: 148, bad PEBs: 0, corrupted PEBs: 0 UBI: user volume: 0, internal volumes: 1, max. volumes count: 128 UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1371523162 UBI: available PEBs: 144, total reserved PEBs: 4, PEBs reserved for bad PEB handling: 0 UBI: background thread "ubi_bgt0d" started, PID 1003
Linux Env #> ubimkvol -N data -m /dev/ubi0
Linux Env #> mount -t ubifs ubi0:data /mnt
Linux Env #> mount -t ubifs ubi0:data /mnt
UBIFS: default file-system created UBIFS: background thread "ubifs_bgt0_0" started, PID 1010 UBIFS: mounted UBI device 0, volume 0, name "data" UBIFS: LEB size: 262016 bytes (255 KiB), min./max. I/O unit sizes: 8 bytes/256 bytes UBIFS: FS size: 35110144 bytes (33 MiB, 134 LEBs), journal size 2096129 bytes (1 MiB, 7 LEBs) UBIFS: reserved for root: 1658338 bytes (1619 KiB) UBIFS: media format: w4/r0 (latest is w4/r0), UUID 696FFD7B-1957-4ABD-9FDC-ED0EEB674D9D, small LPT model
It's perfectly working from Linux env, however U-Boot don't want to attach UBI partition.
Please help me identify the problem!
Best regards, Denis Bakhvalov
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
Best regards, Denis Bakhvalov
Hello Denis,
Am 24.02.2016 um 09:59 schrieb Bakhvalov, Denis (Nokia - PL/Wroclaw):
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
Sorry, I have no such similiar HW ... You have to look into the flashs datasheet and your RM for your SoC and find out whats the problem ...
added Jagan (SPI custodian) maybe he has an idea...
bye, Heiko
Hi Denis,
On 24 February 2016 at 14:29, Bakhvalov, Denis (Nokia - PL/Wroclaw) denis.bakhvalov@nokia.com wrote:
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase S25FL512S is already been added u-boot. Pls- check the same and let me know if you find any issues while detecting the flash.
Whether the driver detecting flash or not with RDID, please define DEBUG on drivers/mtd/spi/spi_flash.c
thanks!
Hi Jagan, Heiko,
Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase S25FL512S is already been added u-boot. Pls- check the same and let me know if you find any issues while detecting the flash.
Whether the driver detecting flash or not with RDID, please define DEBUG on drivers/mtd/spi/spi_flash.c
I had no problems with detecting the flash. It was detected like this: SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB
Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board).
Actually, today I solved the problem, although in not very clean way, I think.
As I mentioned in previous mail I had problems with reading from the flash. Some bytes were read incorrectly. I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version there were no such issue. I found out that there was some workaround introduced in order to fix this.
So, I just apply some part of that workaround to mainline U-Boot and now it works.
Here is the problem in more detail:
On previous version (2013): U-BOOT # sf read 0x1B000000 0x03800000 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x3800000 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x800000b cadence_qspi_apb_indirect_read_setup. device size = 0x101003
U-BOOT # md 0x1B000000 1 1b000000: 55424923
But on mainline U-Boot(2016.03-rc1) I had: U-BOOT # sf read 0x1B000000 0x03800000 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x800000 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b cadence_qspi_apb_indirect_read_setup. device size = 0x101002
U-BOOT # md 0x1B000000 1 1b000000: 554249ff
You can see the difference in the register values that were written in QSPI registers. In case with mainline U-Boot I had address value not properly set.
Here is the workaround that I've made:
Index: drivers/mtd/spi/spi_flash.c =================================================================== --- drivers/mtd/spi/spi_flash.c (revision 608) +++ drivers/mtd/spi/spi_flash.c (revision 609) @@ -29,6 +29,17 @@ cmd[3] = addr >> 0; }
+#ifdef CONFIG_DBRRH_WORKAROUND +static void spi_flash_addr32(u32 addr, u8 *cmd) +{ + /* cmd[0] is actual command */ + cmd[1] = (addr >> 24) & 0xFF; + cmd[2] = (addr >> 16) & 0xFF; + cmd[3] = (addr >> 8) & 0xFF; + cmd[4] = (addr >> 0) & 0xFF; +} +#endif + static int read_sr(struct spi_flash *flash, u8 *rs) { int ret; @@ -510,8 +521,14 @@ else read_len = remain_len;
+#ifdef CONFIG_DBRRH_WORKAROUND + spi_flash_addr32(read_addr, cmd); +#else spi_flash_addr(read_addr, cmd); +#endif
ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len); if (ret < 0) { debug("SF: read failed\n");
Index: drivers/spi/cadence_qspi_apb.c =================================================================== --- drivers/spi/cadence_qspi_apb.c (revision 608) +++ drivers/spi/cadence_qspi_apb.c (revision 609) @@ -30,6 +30,10 @@ #include <asm/errno.h> #include "cadence_qspi.h"
+#ifdef CONFIG_DBRRH_WORKAROUND + #define CMD_OPTION_DUMMY_CYCLES 0x7F /* Dummy Cycles for Read Command */ +#endif + @@ -706,9 +710,25 @@ #endif
/* Get address */ +#ifdef CONFIG_DBRRH_WORKAROUND + addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], 4); +#else addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes); +#endif
+#ifdef CONFIG_DBRRH_WORKAROUND + /* Setting Dummy Clock Cycle */ + dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES); + if (dummy_clk) + { + rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) + << CQSPI_REG_RD_INSTR_DUMMY_LSB; + } +#else + /* The remaining lenght is dummy bytes. */ dummy_bytes = cmdlen - addr_bytes - 1; if (dummy_bytes) { @@ -731,7 +751,9 @@ rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) << CQSPI_REG_RD_INSTR_DUMMY_LSB; } +#endif
With this correction I can read contents of the flash properly. However, I'm a bit surprised that I was forced to make such correction like storing 4 bytes of address (see spi_flash_addr32() above). On the other hand I haven't found any switch that could be turned on to fix my problem in a clean and nice way.
With 24 bytes we can address only 16 MB. How cadence driver is supposed to work for larger spaces? Is this 4th byte comes from somewhere else?
Jagan, Heiko, please evaluate my correction.
Best regards, Denis Bakhvalov
+ Marek
On 29 February 2016 at 22:14, Bakhvalov, Denis (Nokia - PL/Wroclaw) denis.bakhvalov@nokia.com wrote:
Hi Jagan, Heiko,
Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase S25FL512S is already been added u-boot. Pls- check the same and let me know if you find any issues while detecting the flash.
Whether the driver detecting flash or not with RDID, please define DEBUG on drivers/mtd/spi/spi_flash.c
I had no problems with detecting the flash. It was detected like this: SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB
So, the flash size is > 32MiB means, your config enabled BAR(Bank address register) which means accessing flash more than 16MiB using 3-byte addressing support.
Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board).
Actually, today I solved the problem, although in not very clean way, I think.
As I mentioned in previous mail I had problems with reading from the flash. Some bytes were read incorrectly. I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version there were no such issue. I found out that there was some workaround introduced in order to fix this.
So, I just apply some part of that workaround to mainline U-Boot and now it works.
Here is the problem in more detail:
On previous version (2013): U-BOOT # sf read 0x1B000000 0x03800000 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x3800000 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x800000b cadence_qspi_apb_indirect_read_setup. device size = 0x101003
U-BOOT # md 0x1B000000 1 1b000000: 55424923
But on mainline U-Boot(2016.03-rc1) I had: U-BOOT # sf read 0x1B000000 0x03800000 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x800000 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b cadence_qspi_apb_indirect_read_setup. device size = 0x101002
U-BOOT # md 0x1B000000 1 1b000000: 554249ff
You can see the difference in the register values that were written in QSPI registers. In case with mainline U-Boot I had address value not properly set.
Here is the workaround that I've made:
Index: drivers/mtd/spi/spi_flash.c
--- drivers/mtd/spi/spi_flash.c (revision 608) +++ drivers/mtd/spi/spi_flash.c (revision 609) @@ -29,6 +29,17 @@ cmd[3] = addr >> 0; }
+#ifdef CONFIG_DBRRH_WORKAROUND +static void spi_flash_addr32(u32 addr, u8 *cmd) +{
/* cmd[0] is actual command */cmd[1] = (addr >> 24) & 0xFF;cmd[2] = (addr >> 16) & 0xFF;cmd[3] = (addr >> 8) & 0xFF;cmd[4] = (addr >> 0) & 0xFF;+} +#endif
static int read_sr(struct spi_flash *flash, u8 *rs) { int ret; @@ -510,8 +521,14 @@ else read_len = remain_len;
+#ifdef CONFIG_DBRRH_WORKAROUND
spi_flash_addr32(read_addr, cmd);+#else spi_flash_addr(read_addr, cmd); +#endif
ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len); if (ret < 0) { debug("SF: read failed\n");Index: drivers/spi/cadence_qspi_apb.c
--- drivers/spi/cadence_qspi_apb.c (revision 608) +++ drivers/spi/cadence_qspi_apb.c (revision 609) @@ -30,6 +30,10 @@ #include <asm/errno.h> #include "cadence_qspi.h"
+#ifdef CONFIG_DBRRH_WORKAROUND
#define CMD_OPTION_DUMMY_CYCLES 0x7F /* Dummy Cycles for Read Command */+#endif
@@ -706,9 +710,25 @@ #endif
/* Get address */+#ifdef CONFIG_DBRRH_WORKAROUND
addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], 4);+#else addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes); +#endif
+#ifdef CONFIG_DBRRH_WORKAROUND
/* Setting Dummy Clock Cycle */dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES);if (dummy_clk){rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)<< CQSPI_REG_RD_INSTR_DUMMY_LSB;}+#else
/* The remaining lenght is dummy bytes. */ dummy_bytes = cmdlen - addr_bytes - 1; if (dummy_bytes) {@@ -731,7 +751,9 @@ rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) << CQSPI_REG_RD_INSTR_DUMMY_LSB; } +#endif
With this correction I can read contents of the flash properly. However, I'm a bit surprised that I was forced to make such correction like storing 4 bytes of address (see spi_flash_addr32() above).
Instead of 4-byte addressing, u-boot using only 3-byte addressing with BAR support for accessing flash's more than 16MiB.
- Which version of u-boot works for you with this flash? - Does your driver supports or handling BAR? Since CONFIG_SPI_FLASH_BAR is already enabled in config files I think some one might have verified > 16MiB flash's as well.
Marek - Did you verified > 16MiB flash before with cadence_qspi driver?
On the other hand I haven't found any switch that could be turned on to fix my problem in a clean and nice way.
With 24 bytes we can address only 16 MB. How cadence driver is supposed to work for larger spaces? Is this 4th byte comes from somewhere else?
See above.
Jagan, Heiko, please evaluate my correction.
thanks!
On 02/29/2016 05:44 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Jagan, Heiko,
Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase S25FL512S is already been added u-boot. Pls- check the same and let me know if you find any issues while detecting the flash.
Whether the driver detecting flash or not with RDID, please define DEBUG on drivers/mtd/spi/spi_flash.c
I had no problems with detecting the flash. It was detected like this: SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB
Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board).
Actually, today I solved the problem, although in not very clean way, I think.
As I mentioned in previous mail I had problems with reading from the flash. Some bytes were read incorrectly. I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version there were no such issue. I found out that there was some workaround introduced in order to fix this.
So, I just apply some part of that workaround to mainline U-Boot and now it works.
Here is the problem in more detail:
On previous version (2013): U-BOOT # sf read 0x1B000000 0x03800000 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x3800000 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x800000b cadence_qspi_apb_indirect_read_setup. device size = 0x101003
U-BOOT # md 0x1B000000 1 1b000000: 55424923
But on mainline U-Boot(2016.03-rc1) I had: U-BOOT # sf read 0x1B000000 0x03800000 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x800000 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b cadence_qspi_apb_indirect_read_setup. device size = 0x101002
U-BOOT # md 0x1B000000 1 1b000000: 554249ff
You can see the difference in the register values that were written in QSPI registers. In case with mainline U-Boot I had address value not properly set.
Here is the workaround that I've made:
Index: drivers/mtd/spi/spi_flash.c
--- drivers/mtd/spi/spi_flash.c (revision 608) +++ drivers/mtd/spi/spi_flash.c (revision 609) @@ -29,6 +29,17 @@ cmd[3] = addr >> 0; }
+#ifdef CONFIG_DBRRH_WORKAROUND +static void spi_flash_addr32(u32 addr, u8 *cmd) +{
- /* cmd[0] is actual command */
- cmd[1] = (addr >> 24) & 0xFF;
- cmd[2] = (addr >> 16) & 0xFF;
- cmd[3] = (addr >> 8) & 0xFF;
- cmd[4] = (addr >> 0) & 0xFF;
+} +#endif
static int read_sr(struct spi_flash *flash, u8 *rs) { int ret; @@ -510,8 +521,14 @@ else read_len = remain_len;
+#ifdef CONFIG_DBRRH_WORKAROUND
spi_flash_addr32(read_addr, cmd);+#else spi_flash_addr(read_addr, cmd); +#endif
ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len); if (ret < 0) { debug("SF: read failed\n");Index: drivers/spi/cadence_qspi_apb.c
--- drivers/spi/cadence_qspi_apb.c (revision 608) +++ drivers/spi/cadence_qspi_apb.c (revision 609) @@ -30,6 +30,10 @@ #include <asm/errno.h> #include "cadence_qspi.h"
+#ifdef CONFIG_DBRRH_WORKAROUND
- #define CMD_OPTION_DUMMY_CYCLES 0x7F /* Dummy Cycles for Read Command */
+#endif
@@ -706,9 +710,25 @@ #endif
/* Get address */ +#ifdef CONFIG_DBRRH_WORKAROUND
- addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], 4);
+#else addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes); +#endif
+#ifdef CONFIG_DBRRH_WORKAROUND
- /* Setting Dummy Clock Cycle */
- dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES);
- if (dummy_clk)
- {
rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)<< CQSPI_REG_RD_INSTR_DUMMY_LSB;- }
+#else
- /* The remaining lenght is dummy bytes. */ dummy_bytes = cmdlen - addr_bytes - 1; if (dummy_bytes) {
@@ -731,7 +751,9 @@ rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) << CQSPI_REG_RD_INSTR_DUMMY_LSB; } +#endif
With this correction I can read contents of the flash properly. However, I'm a bit surprised that I was forced to make such correction like storing 4 bytes of address (see spi_flash_addr32() above). On the other hand I haven't found any switch that could be turned on to fix my problem in a clean and nice way.
With 24 bytes we can address only 16 MB. How cadence driver is supposed to work for larger spaces? Is this 4th byte comes from somewhere else?
Jagan, Heiko, please evaluate my correction.
Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-)
I normally use the cadence QSPI driver with N25Q00AA, which is 128MiB part. I also had the 4-byte addressing support in the works for a while, but never got around to cleaning that up. It'd be real nice if you could send a proper patch.
Hi Denis,
On 1 March 2016 at 18:34, Bakhvalov, Denis (Nokia - PL/Wroclaw) denis.bakhvalov@nokia.com wrote:
Hi Marek,
Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-)
That solved my issue. Thank you very much. I removed workaround from the code.
Sorry, I couldn't understand the issue nor what you solved? because, socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled and even sf probe looks no warning for enabling the same. If you haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give warning while doing 'sf probe'
+ SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB
this will show something like
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR
thanks!
Hi Jagan,
Sorry, I couldn't understand the issue nor what you solved? because, socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled and even sf probe looks no warning for enabling the same. If you haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give warning while doing 'sf probe'
I can see that for 2016.03-rc1 CONFIG_SPI_FLASH_BAR is not present in socfpga_arria5_defconfig.
Best regards, Denis Bakhvalov
On 03/01/2016 02:53 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Jagan,
Sorry, I couldn't understand the issue nor what you solved? because, socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled and even sf probe looks no warning for enabling the same. If you haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give warning while doing 'sf probe'
I can see that for 2016.03-rc1 CONFIG_SPI_FLASH_BAR is not present in socfpga_arria5_defconfig.
Best regards, Denis Bakhvalov
It's I belive in socfpga_common.h and it should be migrated to socfpga_*_defconfig where it makes sense. Do you want to submit a patch for this ?
Hi Marek,
It's I belive in socfpga_common.h and it should be migrated to socfpga_*_defconfig where it makes sense. Do you want to submit a patch for this ?
I put it in my todo list. Once I will finish with u-boot bringup I will submit the patch. Currently I have Ethernet not working :(
Best regards, Denis Bakhvalov
On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Hi,
It's I belive in socfpga_common.h and it should be migrated to socfpga_*_defconfig where it makes sense. Do you want to submit a patch for this ?
I put it in my todo list. Once I will finish with u-boot bringup I will submit the patch. Currently I have Ethernet not working :(
OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.
Hi Marek,
Currently I have Ethernet not working :(
OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.
Yes. I didn't changed that. It is gmac1: ethernet@ff702000.
I already started new topic for that problem here: http://lists.denx.de/pipermail/u-boot/2016-March/247290.html Let's continue discussion there. :)
Best regards, Denis Bakhvalov
MBB Radio Platforms, RFSW
-----Original Message----- From: EXT Marek Vasut [mailto:marex@denx.de] Sent: Friday, March 04, 2016 13:20 To: Bakhvalov, Denis (Nokia - PL/Wroclaw) denis.bakhvalov@nokia.com; EXT Jagan Teki jteki@openedev.com Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Problem with attaching UBI partition
On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Hi,
It's I belive in socfpga_common.h and it should be migrated to socfpga_*_defconfig where it makes sense. Do you want to submit a patch for this ?
I put it in my todo list. Once I will finish with u-boot bringup I will submit the patch. Currently I have Ethernet not working :(
OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.
On 03/04/2016 01:24 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Hi,
Currently I have Ethernet not working :(
OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.
Yes. I didn't changed that. It is gmac1: ethernet@ff702000.
I already started new topic for that problem here: http://lists.denx.de/pipermail/u-boot/2016-March/247290.html Let's continue discussion there. :)
OK
Best regards, Marek Vasut
Hi
It's I belive in socfpga_common.h and it should be migrated to socfpga_*_defconfig where it makes sense. Do you want to submit a patch for this ?
I put it in my todo list. Once I will finish with u-boot bringup I will submit the patch. Currently I have Ethernet not working :(
Patch was submitted: http://lists.denx.de/pipermail/u-boot/2016-March/249392.html
Best regards, Denis Bakhvalov
On 03/22/2016 02:18 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi
It's I belive in socfpga_common.h and it should be migrated to socfpga_*_defconfig where it makes sense. Do you want to submit a patch for this ?
I put it in my todo list. Once I will finish with u-boot bringup I will submit the patch. Currently I have Ethernet not working :(
Patch was submitted: http://lists.denx.de/pipermail/u-boot/2016-March/249392.html
Thanks, next time please CC me on the patches, otherwise I might miss them.
On 03/01/2016 02:04 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-)
That solved my issue. Thank you very much. I removed workaround from the code.
Best regards, Denis Bakhvalov
Yay :-)
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem.
For now, try doing "dcache off" before using the QSPI NOR.
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem.
For now, try doing "dcache off" before using the QSPI NOR.
We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps
Thanks Chin Liang
On 01.03.2016 07:53, Chin Liang See wrote:
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem.
For now, try doing "dcache off" before using the QSPI NOR.
We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps
This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline.
Could you please explain in more details what exactly you did to solve this issue on SPI NOR?
Thanks, Stefan
On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
On 01.03.2016 07:53, Chin Liang See wrote:
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem.
For now, try doing "dcache off" before using the QSPI NOR.
We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps
This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline.
Could you please explain in more details what exactly you did to solve this issue on SPI NOR?
Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined.
In this case, wonder any details on the failure? Intermittent?
Thanks Chin Liang
Thanks, Stefan
Hi!
(adding Marek to Cc again)
On 01.03.2016 14:38, Chin Liang See wrote:
On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
On 01.03.2016 07:53, Chin Liang See wrote:
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hello Heiko,
Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
Where does this leading 0xff come from? There seems a problem with your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem.
For now, try doing "dcache off" before using the QSPI NOR.
We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps
This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline.
Could you please explain in more details what exactly you did to solve this issue on SPI NOR?
Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined.
In this case, wonder any details on the failure? Intermittent?
I think we are talking about different things here. I'm referring to Marek mentioning the cache problem (S-bit related) on current SoCFPGA U-Boot mainline. With caches enabled you can experience problems on QSPI and on USB (reported from Marek - I didn't test USB yet).
So do you have any updated on this cache / S-bit problem? Or can you use QSPI NOR without any issues on current mainline U-Boot with caches enabled on your platforms?
Thanks, Stefan
On Tue, 2016-03-01 at 16:35 +0100, Stefan Roese wrote:
Hi!
Hi Stefan,
(adding Marek to Cc again)
On 01.03.2016 14:38, Chin Liang See wrote:
On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
On 01.03.2016 07:53, Chin Liang See wrote:
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hello Heiko,
> Which U-Boot version? Which board?
This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard.
> Where does this leading 0xff come from? There seems a > problem > with > your spi nor flash driver?
Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted.
How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot?
I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem.
For now, try doing "dcache off" before using the QSPI NOR.
We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps
This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline.
Could you please explain in more details what exactly you did to solve this issue on SPI NOR?
Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined.
In this case, wonder any details on the failure? Intermittent?
I think we are talking about different things here. I'm referring to Marek mentioning the cache problem (S-bit related) on current SoCFPGA U-Boot mainline. With caches enabled you can experience problems on QSPI and on USB (reported from Marek - I didn't test USB yet).
For QSPI, wonder the issue is on the read or write?
So do you have any updated on this cache / S-bit problem?
I am still debugging this as I notice the hub is not able to detect the mass storage. This is only for certain pen drive.
Or can you use QSPI NOR without any issues on current mainline U-Boot with caches enabled on your platforms?
The issue I have is on USB only. For NOR, I can ubifsmount and ubifsload with Micron NOR flash without issue. This is with dcache enabled
Thanks Chin Liang
Thanks, Stefan
Hi Chin Liang,
On 02.03.2016 13:24, Chin Liang See wrote:
On 01.03.2016 14:38, Chin Liang See wrote:
On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
On 01.03.2016 07:53, Chin Liang See wrote:
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hello Heiko, > >> Which U-Boot version? Which board? > > This is U-Boot v2016.03-rc1. I have custom board with > socfpga > Arria5 > onboard. > >> Where does this leading 0xff come from? There seems a >> problem >> with >> your spi nor flash driver? > > Yes, you're right. I have problems with the driver. As I > mentioned > in > previous mail when I read the contents from the flash some > data > is > corrupted. > > How to find out if the problem is because U-Boot has no > support > for > my flash (Spansion S25FL512S NOR flash with SPI) or I have > not > proper > configured SPI in U-Boot?
I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem.
For now, try doing "dcache off" before using the QSPI NOR.
We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps
This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline.
Could you please explain in more details what exactly you did to solve this issue on SPI NOR?
Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined.
In this case, wonder any details on the failure? Intermittent?
I think we are talking about different things here. I'm referring to Marek mentioning the cache problem (S-bit related) on current SoCFPGA U-Boot mainline. With caches enabled you can experience problems on QSPI and on USB (reported from Marek - I didn't test USB yet).
For QSPI, wonder the issue is on the read or write?
I'm not 100% sure here if this never happens on read. But it definitely happens on write. saveeenv to SPI NOR causes serious problems here for example.
So do you have any updated on this cache / S-bit problem?
I am still debugging this as I notice the hub is not able to detect the mass storage. This is only for certain pen drive.
Or can you use QSPI NOR without any issues on current mainline U-Boot with caches enabled on your platforms?
The issue I have is on USB only. For NOR, I can ubifsmount and ubifsload with Micron NOR flash without issue. This is with dcache enabled
Strange. I have Micron here on the SR1500 as well:
=> sf probe SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Thanks, Stefan
On 03/03/2016 12:51 PM, Stefan Roese wrote:
Hi Chin Liang,
On 02.03.2016 13:24, Chin Liang See wrote:
On 01.03.2016 14:38, Chin Liang See wrote:
On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
On 01.03.2016 07:53, Chin Liang See wrote:
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: > On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) > wrote: >> Hello Heiko, >> >>> Which U-Boot version? Which board? >> >> This is U-Boot v2016.03-rc1. I have custom board with >> socfpga >> Arria5 >> onboard. >> >>> Where does this leading 0xff come from? There seems a >>> problem >>> with >>> your spi nor flash driver? >> >> Yes, you're right. I have problems with the driver. As I >> mentioned >> in >> previous mail when I read the contents from the flash some >> data >> is >> corrupted. >> >> How to find out if the problem is because U-Boot has no >> support >> for >> my flash (Spansion S25FL512S NOR flash with SPI) or I have >> not >> proper >> configured SPI in U-Boot? > > I believe there is a problem with caches , which we still > didn't > identify. CCing Dinh and Chin, as they were the last ones > looking > into this problem. > > For now, try doing "dcache off" before using the QSPI NOR. >
We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps
This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline.
Could you please explain in more details what exactly you did to solve this issue on SPI NOR?
Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined.
In this case, wonder any details on the failure? Intermittent?
I think we are talking about different things here. I'm referring to Marek mentioning the cache problem (S-bit related) on current SoCFPGA U-Boot mainline. With caches enabled you can experience problems on QSPI and on USB (reported from Marek - I didn't test USB yet).
For QSPI, wonder the issue is on the read or write?
I'm not 100% sure here if this never happens on read. But it definitely happens on write. saveeenv to SPI NOR causes serious problems here for example.
So do you have any updated on this cache / S-bit problem?
I am still debugging this as I notice the hub is not able to detect the mass storage. This is only for certain pen drive.
Or can you use QSPI NOR without any issues on current mainline U-Boot with caches enabled on your platforms?
The issue I have is on USB only. For NOR, I can ubifsmount and ubifsload with Micron NOR flash without issue. This is with dcache enabled
Strange. I have Micron here on the SR1500 as well:
=> sf probe SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Thanks, Stefan
The testcase is that you write some 8 MiB or so of data into the SPI NOR. Upon read-back, you will notice that the last two or so bytes of some sectors were not written completely and are corrupted.
participants (7)
-
Bakhvalov, Denis (Nokia - PL/Wroclaw) -
Chin Liang See -
Heiko Schocher -
Jagan Teki -
Marek Vasut -
Marek Vasut -
Stefan Roese