[U-Boot] Problem with attaching UBI partition

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

Hi,

I found that I have problem with reading flash contents:

When dumping the flash from Linux env:

$ cat /dev/mtd5 > /tmp/flash.bin

00000000: 55424923 01000000 00000000 00000003

But when I dump the flash contents from U-Boot I see this:

=> sf read 0x1B000000 0x01B00000 0x1000
=> md 0x1B000000

1b000000: 494255ff 00000123 00000000 00000000

So, that's why I see this print:

ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead of 55424923

I will investigate why data was read from flash incorrectly.

Best regards,
Denis Bakhvalov

[U-Boot] Problem with attaching UBI partition

[Heiko Schocher]

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        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
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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

[U-Boot] Problem with attaching UBI partition

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Problem with attaching UBI partition

[Jagan Teki]

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!
-- 
Jagan.

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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

[U-Boot] Problem with attaching UBI partition

[Jagan Teki]

+ 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!
-- 
Jagan.

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

[U-Boot] Problem with attaching UBI partition

[Chin Liang See]

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

[U-Boot] Problem with attaching UBI partition

[Stefan Roese]

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

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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

[U-Boot] Problem with attaching UBI partition

[Jagan Teki]

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!
-- 
Jagan.

[U-Boot] Problem with attaching UBI partition

[Chin Liang See]

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
> 

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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 :-)

-- 
Best regards,
Marek Vasut

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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 ?

-- 
Best regards,
Marek Vasut

[U-Boot] Problem with attaching UBI partition

[Stefan Roese]

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

[U-Boot] Problem with attaching UBI partition

[Chin Liang See]

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
> 

[U-Boot] Problem with attaching UBI partition

[Stefan Roese]

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

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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 at 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 at 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 at 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.

-- 
Best regards,
Marek Vasut

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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 at 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

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis]

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

[U-Boot] Problem with attaching UBI partition

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut