[U-Boot] Problem with attaching UBI partition

[Jagan Teki]

+ Marek

On 29 February 2016 at 22:14, Bakhvalov, Denis (Nokia - PL/Wroclaw)
<denis.bakhvalov at 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.