Re: [U-Boot] [PATCH v2] armv8: QSPI: Add AHB bus 16MB+ size support

2016-11-30 Thread Yao Yuan 
On 12/01/2016 07:33 PM, York Sun wrote:
> On 11/29/2016 07:33 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > The default configuration for QSPI AHB bus can't support 16MB+.
> > But some flash on NXP layerscape board are more than 16MB.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Remove the CONFIG_QSPI_AHB_INIT into Kconfig.
> > ---
> 
> 
> 
> > diff --git a/scripts/config_whitelist.txt
> > b/scripts/config_whitelist.txt index d0b5e7f..8dd3e4b 100644
> > --- a/scripts/config_whitelist.txt
> > +++ b/scripts/config_whitelist.txt
> > @@ -7340,6 +7340,7 @@ CONFIG_SYS_QRIO_BASE
> CONFIG_SYS_QRIO_BASE_PHYS
> > CONFIG_SYS_QRIO_BR_PRELIM  CONFIG_SYS_QRIO_OR_PRELIM
> > +CONFIG_SYS_QSPI_ADDR
> >  CONFIG_SYS_R7780MP_OLD_FLASH
> >  CONFIG_SYS_RAMBOOT
> >  CONFIG_SYS_RAM_BASE
> >
> 
> NAK. You can't add new macro to the white list. For this macro, you can 
> convert
> it to another name space, see example 295a24b3.
> 


OK, Get it, I will send v3 soon.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

2016-11-29 Thread Yao Yuan 
On 11/15/2016 02:27 AM, York Sun wrote:
> On 11/07/2016 10:03 PM, Yao Yuan wrote:
> > On 11/08/2016 02:27 AM, York Sun wrote:
> >> On 10/25/2016 07:10 PM, Yuan Yao wrote:
> >>> From: Yuan Yao <yao.y...@nxp.com>
> >>>
> >>> The default configuration for QSPI AHB bus can't support 16MB+.
> >>> But some flash on NXP layerscape board are more than 16MB.
> >>
> >> So what do you do?
> >>
> >> Is this an erratum workaround? If yes, please refer the erratum number.
> >
> > Hi York,
> >
> > I think It's not an erratum maybe it's better to call it new feature.
> >
> > As a default configuration for QSPI AHB, the address size is 3-bytes.
> > It has a good compatibility for QSPI boot for different SPI-NOR flash.
> >
> > But if the address size is only 3-bytes, the QSPI can't access to the data 
> > that
> more than 16M+.
> >
> > So we can update the default configuration for QSPI AHB in uboot to use 4-
> bytes address.
> > So that QSPI can access to 16M+ size by AHB bus.
> 
> Let me try to understand this. With your change, 4-byte addressing is
> supported. Do all flash chips support 4-byte addressing?

No, Not all the flash.
 
> 
> >
> > Thanks.
> >>
> >>>
> >>> Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> >>> ---
> >>>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37
> >> ++
> >>>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
> >>> .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
> >>>  include/configs/ls1012a_common.h   |  1 +
> >>>  include/configs/ls1046ardb.h   |  1 +
> >>>  5 files changed, 41 insertions(+)
> >>>
> >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> index d68eeba..18d753e 100644
> >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> @@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)  }  #endif
> >>>
> >>> +#ifdef CONFIG_QSPI_AHB_INIT
> >>> +/* Enable 4bytes address support and fast read */ int
> >>> +qspi_ahb_init(void) {
> >>> + u32 *qspi_lut, lut_key, *qspi_key;
> >>> +
> >>> + qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
> >>> + qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
> >>> +
> >>> + lut_key = in_be32(qspi_key);
> >>> +
> >>> + if (lut_key == 0x5af05af0) {
> >>> + /* That means the register is BE */
> >>> + out_be32(qspi_key, 0x5af05af0);
> >>> + out_be32(qspi_key + 1, 0x0002);
> >>> + out_be32(qspi_lut, 0x0820040c);
> >>> + out_be32(qspi_lut + 1, 0x1c080c08);
> >>> + out_be32(qspi_lut + 2, 0x2400);
> >>> + out_be32(qspi_key, 0x5af05af0);
> >>> + out_be32(qspi_key + 1, 0x0001);
> >>> + } else {
> >>> + /* That means the register is LE */
> >>> + out_le32(qspi_key, 0x5af05af0);
> >>> + out_le32(qspi_key + 1, 0x0002);
> >>> + out_le32(qspi_lut, 0x0820040c);
> >>> + out_le32(qspi_lut + 1, 0x1c080c08);
> >>> + out_le32(qspi_lut + 2, 0x2400);
> >>> + out_le32(qspi_key, 0x5af05af0);
> >>> + out_le32(qspi_key + 1, 0x0001);
> >>> + }
> >>
> >> What do these sequences do?
> >
> > It used to set the AHB bus to use 4-bytes command and the corresponding
> sequence.
> > So that QSPI can access to 16M+ size by AHB bus.
> >
> >>
> >> Put a blank line before return.
> 
> You need a blank line here.

OK, get it.


> 
> >>
> >>> + return 0;
> >>> +}
> >>> +#endif
> >>> +
> >>>  #ifdef CONFIG_BOARD_LATE_INIT
> >>>  int board_late_init(void)
> >>>  {
> >>> @@ -379,6 +413,9 @@ int board_late_init(void)  #ifdef
> >>> CONFIG_CHAIN_OF_TRUST
> >>>   fsl_setenv_chain_of_trust();
> >>>  #endif
> >>> +#ifdef CONFIG_QSPI_AHB_INIT
> >>> + qspi_ahb_init();
> >>> +#endif
> >>>
> >>>   return 0;
> >>>  }
> >>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> >>&

Re: [U-Boot] [PATCH v1 1/4] sf: add ADDR_4B for 4byte address support

2016-11-29 Thread Yao Yuan 
On Wed, Oct 26, 2016 at 4:39 PM, Jagan Teki  wrote:
> On Wed, Sep 28, 2016 at 4:39 PM, Yuan Yao  wrote:
> > From: Yuan Yao 
> >
> > Some new flash don't support bar register but use 4bytes address to
> > support exceed 16MB flash size.
> > So add flash flag:
> > ADDR_4B
> > for some flash which support 4bytes address.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  drivers/mtd/spi/sf_internal.h |  4 +++-
> >  drivers/mtd/spi/sf_params.c   |  2 +-
> >  drivers/mtd/spi/spi_flash.c   | 38 +-
> >  include/spi_flash.h   |  1 +
> >  4 files changed, 30 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/sf_internal.h
> > b/drivers/mtd/spi/sf_internal.h index cde4cfb..9ae1549 100644
> > --- a/drivers/mtd/spi/sf_internal.h
> > +++ b/drivers/mtd/spi/sf_internal.h
> > @@ -26,7 +26,8 @@ enum spi_nor_option_flags {  };
> >
> >  #define SPI_FLASH_3B_ADDR_LEN  3
> > -#define SPI_FLASH_CMD_LEN  (1 + SPI_FLASH_3B_ADDR_LEN)
> > +#define SPI_FLASH_4B_ADDR_LEN  4
> > +#define SPI_FLASH_CMD_MAX_LEN  (1 + SPI_FLASH_4B_ADDR_LEN)
> >  #define SPI_FLASH_16MB_BOUN0x100
> >
> >  /* CFI Manufacture ID's */
> > @@ -130,6 +131,7 @@ struct spi_flash_params {
> >  #define RD_DUALBIT(5)
> >  #define RD_QUADIO  BIT(6)
> >  #define RD_DUALIO  BIT(7)
> > +#define ADDR_4BBIT(8)
> >  #define RD_FULL(RD_QUAD | RD_DUAL | RD_QUADIO |
> RD_DUALIO)
> >  };
> >
> > diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> > index 5b50114..9c26cc8 100644
> > --- a/drivers/mtd/spi/sf_params.c
> > +++ b/drivers/mtd/spi/sf_params.c
> > @@ -68,7 +68,7 @@ const struct spi_flash_params spi_flash_params_table[]
> = {
> > {"S25FL128S_64K",  0x012018, 0x4d01,64 * 1024,   256, RD_FULL |
> WR_QPP},
> > {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL |
> WR_QPP},
> > {"S25FL256S_64K",  0x010219, 0x4d01,64 * 1024,   512, RD_FULL |
> WR_QPP},
> > -   {"S25FS512S",  0x010220, 0x4D00,   128 * 1024,   512, RD_FULL |
> WR_QPP},
> > +   {"S25FS512S",  0x010220, 0x4D00,   128 * 1024,   512, RD_FULL |
> WR_QPP | ADDR_4B},
> 
> Sorry for the late, It's better to not relay on specific flash and do the 
> 4-byte
> addressing. So, I've sent some patches based on this [1] and will send the 
> next
> version to wind-up all these changes. Please wait some time.
> 

Hi Jagan,

May I know is there any update for those 4-bytes addressing support in uboot?
If your patch is ready, Can I get the patch set and then working for my QSPI 
64M flash support?

I think it will be very helpful.
The 64MB flash support for our QSPI is very needed.

Thanks.

Yao.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

2016-11-15 Thread Yao Yuan 
On 11/15/2016 01:47 AM, York Sun wrote:
> On 11/07/2016 10:03 PM, Yao Yuan wrote:
> > On 11/08/2016 02:27 AM, York Sun wrote:
> >> On 10/25/2016 07:10 PM, Yuan Yao wrote:
> >>> From: Yuan Yao <yao.y...@nxp.com>
> >>>
> >>> The default configuration for QSPI AHB bus can't support 16MB+.
> >>> But some flash on NXP layerscape board are more than 16MB.
> >>
> >> So what do you do?
> >>
> >> Is this an erratum workaround? If yes, please refer the erratum number.
> >
> > Hi York,
> >
> > I think It's not an erratum maybe it's better to call it new feature.
> >
> > As a default configuration for QSPI AHB, the address size is 3-bytes.
> > It has a good compatibility for QSPI boot for different SPI-NOR flash.
> >
> > But if the address size is only 3-bytes, the QSPI can't access to the data 
> > that
> more than 16M+.
> >
> > So we can update the default configuration for QSPI AHB in uboot to use 4-
> bytes address.
> > So that QSPI can access to 16M+ size by AHB bus.
> 
> Let me try to understand this. With your change, 4-byte addressing is
> supported. Do all flash chips support 4-byte addressing?
> 
> 
No, not all the flash chips support 4-byte addressing.
But the flash chips on LS1012ARDB, LS1046ARDB can support 4-byte addressing.

> >
> > Thanks.
> >>
> >>>
> >>> Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> >>> ---
> >>>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37
> >> ++
> >>>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
> >>> .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
> >>>  include/configs/ls1012a_common.h   |  1 +
> >>>  include/configs/ls1046ardb.h   |  1 +
> >>>  5 files changed, 41 insertions(+)
> >>>
> >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> index d68eeba..18d753e 100644
> >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> @@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)  }  #endif
> >>>
> >>> +#ifdef CONFIG_QSPI_AHB_INIT
> >>> +/* Enable 4bytes address support and fast read */ int
> >>> +qspi_ahb_init(void) {
> >>> + u32 *qspi_lut, lut_key, *qspi_key;
> >>> +
> >>> + qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
> >>> + qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
> >>> +
> >>> + lut_key = in_be32(qspi_key);
> >>> +
> >>> + if (lut_key == 0x5af05af0) {
> >>> + /* That means the register is BE */
> >>> + out_be32(qspi_key, 0x5af05af0);
> >>> + out_be32(qspi_key + 1, 0x0002);
> >>> + out_be32(qspi_lut, 0x0820040c);
> >>> + out_be32(qspi_lut + 1, 0x1c080c08);
> >>> + out_be32(qspi_lut + 2, 0x2400);
> >>> + out_be32(qspi_key, 0x5af05af0);
> >>> + out_be32(qspi_key + 1, 0x0001);
> >>> + } else {
> >>> + /* That means the register is LE */
> >>> + out_le32(qspi_key, 0x5af05af0);
> >>> + out_le32(qspi_key + 1, 0x0002);
> >>> + out_le32(qspi_lut, 0x0820040c);
> >>> + out_le32(qspi_lut + 1, 0x1c080c08);
> >>> + out_le32(qspi_lut + 2, 0x2400);
> >>> + out_le32(qspi_key, 0x5af05af0);
> >>> + out_le32(qspi_key + 1, 0x0001);
> >>> + }
> >>
> >> What do these sequences do?
> >
> > It used to set the AHB bus to use 4-bytes command and the corresponding
> sequence.
> > So that QSPI can access to 16M+ size by AHB bus.
> >
> >>
> >> Put a blank line before return.
> 
> You need a blank line here.

OK, I will.

> 
> >>
> >>> + return 0;
> >>> +}
> >>> +#endif
> >>> +
> >>>  #ifdef CONFIG_BOARD_LATE_INIT
> >>>  int board_late_init(void)
> >>>  {
> >>> @@ -379,6 +413,9 @@ int board_late_init(void)  #ifdef
> >>> CONFIG_CHAIN_OF_TRUST
> >>>   fsl_setenv_chain_of_trust();
> >>>  #endif
> >>> +#ifdef CONFIG_QSPI_AHB_INIT
> >>> + qspi_ahb_init();
> >>> +#endif
> >>>
> >>>   return 0;
> >&

Re: [U-Boot] [PATCH v2] armv8: fsl-layerscape: Add Readme for deploy QSPI image

2016-11-08 Thread Yao Yuan 
On 11/09/2016 02:10 AM, York Sun wrote:
> On 11/07/2016 09:44 PM, Yao Yuan wrote:
> > On 11/08/2016 12:46 PM, York Sun wrote:
> >> On 11/07/2016 07:52 PM, Yuan Yao wrote:
> >>> From: Yuan Yao <yao.y...@nxp.com>
> >>>
> >>> Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> >>> ---
> >>> Changed in v2:
> >>>   Move the readme for QSPI deploy out of only for ls2080aqds.
> >>> ---
> >>>  .../arm/cpu/armv8/fsl-layerscape/doc/README.deploy | 44
> >>> ++
> >>>  1 file changed, 44 insertions(+)
> >>>  create mode 100644
> >>> arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>>
> >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>> new file mode 100644
> >>> index 000..25813b3
> >>> --- /dev/null
> >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>> @@ -0,0 +1,44 @@
> >>> +Boot source support Overview
> >>> +---
> >>> + 1. LS1043A
> >>> + LS1043AQDS:QSPI, SD, NOR, NAND
> >>> + LS1043ARDB:SD, NOR, NAND
> >>> + 2. LS2080A
> >>> + LS2080AQDS:QSPI, SD, NOR, NAND
> >>> + LS2080ARDB:NOR, NAND
> >>> + 3. LS1012A
> >>> + LS1012AQDS:QSPI
> >>> + LS1012ARDB:QSPI
> >>> + 4. LS1046A
> >>> + LS1046AQDS:QSPI, SD, NOR, NAND
> >>> + LS1046ARDB:QSPI, SD
> >>> +
> >>
> >> If you plan to add all SD/NAND/QSPI into this document, it is OK to
> >> call it README.deploy. Otherwise it may be better to name as README.qspi.
> >>
> > I'm not be familiar with SD/NAND boot. So should I rename as README.qspi?
> > Or just keep it but waiting for some others to add SD/NAND boot in another
> patch?
> >
> 
> We already have NAND boot explained in other document. Stick with the
> procedure you are trying to explain. Keep it simple and we can expand it when
> necessary.
> York
 
Get it.
I will send v3 soon.

Thanks.

Yao.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] armv8: fsl-layerscape: Add Readme for deploy QSPI image

2016-11-08 Thread Yao Yuan 
On 11/08/2016 12:46 PM, York Sun wrote:
> On 11/07/2016 07:52 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Move the readme for QSPI deploy out of only for ls2080aqds.
> > ---
> >  .../arm/cpu/armv8/fsl-layerscape/doc/README.deploy | 44
> > ++
> >  1 file changed, 44 insertions(+)
> >  create mode 100644
> > arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> > b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> > new file mode 100644
> > index 000..25813b3
> > --- /dev/null
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> > @@ -0,0 +1,44 @@
> > +Boot source support Overview
> > +---
> > +   1. LS1043A
> > +   LS1043AQDS:QSPI, SD, NOR, NAND
> > +   LS1043ARDB:SD, NOR, NAND
> > +   2. LS2080A
> > +   LS2080AQDS:QSPI, SD, NOR, NAND
> > +   LS2080ARDB:NOR, NAND
> > +   3. LS1012A
> > +   LS1012AQDS:QSPI
> > +   LS1012ARDB:QSPI
> > +   4. LS1046A
> > +   LS1046AQDS:QSPI, SD, NOR, NAND
> > +   LS1046ARDB:QSPI, SD
> > +
> 
> If you plan to add all SD/NAND/QSPI into this document, it is OK to call it
> README.deploy. Otherwise it may be better to name as README.qspi.
> 
I'm not be familiar with SD/NAND boot. So should I rename as README.qspi?
Or just keep it but waiting for some others to add SD/NAND boot in another 
patch?

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ls1021a: QSPI: update the node for QSPI support

2016-11-07 Thread Yao Yuan 
On 11/08/2016 02:27 AM, York Sun wrote:
> On 10/10/2016 11:09 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Add the address value and size value name for QSPI dts node.
> 
> This message doesn't match the change. Do you call "QuadSPI" the address
> value name?
> 

Yes, I always call QuadSPI as QSPI.
Here
<0x155 0x1 > is the QSPI register space.
<0x4000 0x400> is the QSPI memory space.

So, need I update the QSPI as QuadSPI?

Thanks for your review.

> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm/dts/ls1021a.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
> > index 119b1af..37be169 100644
> > --- a/arch/arm/dts/ls1021a.dtsi
> > +++ b/arch/arm/dts/ls1021a.dtsi
> > @@ -176,6 +176,7 @@
> > #size-cells = <0>;
> > reg = <0x155 0x1>,
> > <0x4000 0x400>;
> > +   reg-names = "QuadSPI", "QuadSPI-memory";
> > num-cs = <2>;
> > big-endian;
> > status = "disabled";
> >

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

2016-11-07 Thread Yao Yuan 
On 11/08/2016 02:17 PM, York Sun wrote:
> On 10/16/2016 08:58 PM, Yao Yuan wrote:
> > Hi York,
> >
> > It seems arch/arm/cpu/armv8/fsl-layerscape/doc/README.* is better.
> > I will update my patch and resend soon.
> >
> 
> Did you send the update? BTW, I think you meant "deploy QSPI image" in the
> subject.
> 

Thanks for your reminder.
I will send it just now,

Thanks,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

2016-11-07 Thread Yao Yuan 
On 11/08/2016 02:27 AM, York Sun wrote:
> On 10/25/2016 07:10 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > The default configuration for QSPI AHB bus can't support 16MB+.
> > But some flash on NXP layerscape board are more than 16MB.
> 
> So what do you do?
> 
> Is this an erratum workaround? If yes, please refer the erratum number.

Hi York,

I think It's not an erratum maybe it's better to call it new feature.

As a default configuration for QSPI AHB, the address size is 3-bytes.
It has a good compatibility for QSPI boot for different SPI-NOR flash.

But if the address size is only 3-bytes, the QSPI can't access to the data that 
more than 16M+.

So we can update the default configuration for QSPI AHB in uboot to use 4-bytes 
address.
So that QSPI can access to 16M+ size by AHB bus.

Thanks.
> 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37
> ++
> >  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
> > .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
> >  include/configs/ls1012a_common.h   |  1 +
> >  include/configs/ls1046ardb.h   |  1 +
> >  5 files changed, 41 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index d68eeba..18d753e 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)  }  #endif
> >
> > +#ifdef CONFIG_QSPI_AHB_INIT
> > +/* Enable 4bytes address support and fast read */ int
> > +qspi_ahb_init(void) {
> > +   u32 *qspi_lut, lut_key, *qspi_key;
> > +
> > +   qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
> > +   qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
> > +
> > +   lut_key = in_be32(qspi_key);
> > +
> > +   if (lut_key == 0x5af05af0) {
> > +   /* That means the register is BE */
> > +   out_be32(qspi_key, 0x5af05af0);
> > +   out_be32(qspi_key + 1, 0x0002);
> > +   out_be32(qspi_lut, 0x0820040c);
> > +   out_be32(qspi_lut + 1, 0x1c080c08);
> > +   out_be32(qspi_lut + 2, 0x2400);
> > +   out_be32(qspi_key, 0x5af05af0);
> > +   out_be32(qspi_key + 1, 0x0001);
> > +   } else {
> > +   /* That means the register is LE */
> > +   out_le32(qspi_key, 0x5af05af0);
> > +   out_le32(qspi_key + 1, 0x0002);
> > +   out_le32(qspi_lut, 0x0820040c);
> > +   out_le32(qspi_lut + 1, 0x1c080c08);
> > +   out_le32(qspi_lut + 2, 0x2400);
> > +   out_le32(qspi_key, 0x5af05af0);
> > +   out_le32(qspi_key + 1, 0x0001);
> > +   }
> 
> What do these sequences do?

It used to set the AHB bus to use 4-bytes command and the corresponding 
sequence.
So that QSPI can access to 16M+ size by AHB bus.

> 
> Put a blank line before return.
> 
> > +   return 0;
> > +}
> > +#endif
> > +
> >  #ifdef CONFIG_BOARD_LATE_INIT
> >  int board_late_init(void)
> >  {
> > @@ -379,6 +413,9 @@ int board_late_init(void)  #ifdef
> > CONFIG_CHAIN_OF_TRUST
> > fsl_setenv_chain_of_trust();
> >  #endif
> > +#ifdef CONFIG_QSPI_AHB_INIT
> > +   qspi_ahb_init();
> > +#endif
> >
> > return 0;
> >  }
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > index d88543d..a28b1fd 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > @@ -18,6 +18,7 @@
> >  #define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR +
> 0x0018)
> >  #define CONFIG_SYS_GIC400_ADDR (CONFIG_SYS_IMMR +
> 0x0040)
> >  #define CONFIG_SYS_IFC_ADDR(CONFIG_SYS_IMMR +
> 0x0053)
> > +#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR +
> 0x0055)
> >  #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR +
> 0x0056)
> >  #define CONFIG_SYS_FSL_CSU_ADDR
>   (CONFIG_SYS_IMMR + 0x0051)
> >  #define CONFIG_SYS_FSL_GUTS_ADDR   (CONFIG_SYS_IMMR +
> 0x00ee)
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > index 7acba27..8aefc76 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > @@ -19,6 +19,7 @@
> >  #define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR   (CONFIG_SYS_IMMR +
> 0x0030)
> >  #define CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR   (CONFIG_SYS_IMMR +
> 0x0031)
> >  #define CONFIG_SYS_FSL_CH3_CLK_CTRL_ADDR   (CONFIG_SYS_IMMR +
> 0x0037)
> > +#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR +
> 0x010c)
> >  #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR +
> 0x0114)
> >  #define

Re: [U-Boot] [PATCH] ls1021a: QSPI: update the node for QSPI support

2016-11-07 Thread Yao Yuan 
On 11/08/2016 12:46 PM, York Sun wrote:
> On 11/07/2016 07:58 PM, Yao Yuan wrote:
> > On 11/08/2016 02:27 AM, York Sun wrote:
> >> On 10/10/2016 11:09 PM, Yuan Yao wrote:
> >>> From: Yuan Yao <yao.y...@nxp.com>
> >>>
> >>> Add the address value and size value name for QSPI dts node.
> >>
> >> This message doesn't match the change. Do you call "QuadSPI" the
> >> address value name?
> >>
> >
> > Yes, I always call QuadSPI as QSPI.
> > Here
> > <0x155 0x1 > is the QSPI register space.
> > <0x4000 0x400> is the QSPI memory space.
> >
> > So, need I update the QSPI as QuadSPI?
> 
> You have QSPI register space and memory space. I can understand those.
> But your commit message says "Add address value and size value name". I can't
> match which one is which.
> 
OK, Get it.
I will update the commit message to resend it soon.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/4] sf: add ADDR_4B for 4byte address support

2016-10-26 Thread Yao Yuan 
On Wed, Oct 26, 2016 at 3:39 PM, Jagan Teki wrote:
> On Wed, Sep 28, 2016 at 4:39 PM, Yuan Yao  wrote:
> > From: Yuan Yao 
> >
> > Some new flash don't support bar register but use 4bytes address to
> > support exceed 16MB flash size.
> > So add flash flag:
> > ADDR_4B
> > for some flash which support 4bytes address.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  drivers/mtd/spi/sf_internal.h |  4 +++-
> >  drivers/mtd/spi/sf_params.c   |  2 +-
> >  drivers/mtd/spi/spi_flash.c   | 38 +-
> >  include/spi_flash.h   |  1 +
> >  4 files changed, 30 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/sf_internal.h
> > b/drivers/mtd/spi/sf_internal.h index cde4cfb..9ae1549 100644
> > --- a/drivers/mtd/spi/sf_internal.h
> > +++ b/drivers/mtd/spi/sf_internal.h
> > @@ -26,7 +26,8 @@ enum spi_nor_option_flags {  };
> >
> >  #define SPI_FLASH_3B_ADDR_LEN  3
> > -#define SPI_FLASH_CMD_LEN  (1 + SPI_FLASH_3B_ADDR_LEN)
> > +#define SPI_FLASH_4B_ADDR_LEN  4
> > +#define SPI_FLASH_CMD_MAX_LEN  (1 + SPI_FLASH_4B_ADDR_LEN)
> >  #define SPI_FLASH_16MB_BOUN0x100
> >
> >  /* CFI Manufacture ID's */
> > @@ -130,6 +131,7 @@ struct spi_flash_params {
> >  #define RD_DUALBIT(5)
> >  #define RD_QUADIO  BIT(6)
> >  #define RD_DUALIO  BIT(7)
> > +#define ADDR_4BBIT(8)
> >  #define RD_FULL(RD_QUAD | RD_DUAL | RD_QUADIO |
> RD_DUALIO)
> >  };
> >
> > diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> > index 5b50114..9c26cc8 100644
> > --- a/drivers/mtd/spi/sf_params.c
> > +++ b/drivers/mtd/spi/sf_params.c
> > @@ -68,7 +68,7 @@ const struct spi_flash_params spi_flash_params_table[]
> = {
> > {"S25FL128S_64K",  0x012018, 0x4d01,64 * 1024,   256, RD_FULL |
> WR_QPP},
> > {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL |
> WR_QPP},
> > {"S25FL256S_64K",  0x010219, 0x4d01,64 * 1024,   512, RD_FULL |
> WR_QPP},
> > -   {"S25FS512S",  0x010220, 0x4D00,   128 * 1024,   512, RD_FULL |
> WR_QPP},
> > +   {"S25FS512S",  0x010220, 0x4D00,   128 * 1024,   512, RD_FULL |
> WR_QPP | ADDR_4B},
> 
> Sorry for the late, It's better to not relay on specific flash and do the 
> 4-byte
> addressing. So, I've sent some patches based on this [1] and will send the 
> next
> version to wind-up all these changes. Please wait some time.
> 

Ok, hope for it. We need change a lot and prepare for embrace more.
BTW, I'm working on a QSPI NAND flash support, a lot of the differences with 
NOR flash.

Do you think is it better to have a drivers/mtd/spi/spi_nand_flash.c ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/4] spi: fsl_qspi: Add 4bytes address support

2016-10-26 Thread Yao Yuan 
On Wed, Oct 26, 2016 at 3:39 PM, Jagan Teki wrote:
> On Wed, Sep 28, 2016 at 4:39 PM, Yuan Yao  wrote:
> > From: Yuan Yao 
> >
> > The QSPI support the direct 4bytes address command for flash
> > read/write/erase.
> > And the address can cover the whole QSPI memory space.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  drivers/spi/fsl_qspi.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> > 2144fca..119b782 100644
> > --- a/drivers/spi/fsl_qspi.c
> > +++ b/drivers/spi/fsl_qspi.c
> > @@ -25,7 +25,8 @@ DECLARE_GLOBAL_DATA_PTR;
> >  #define TX_BUFFER_SIZE 0x40
> >  #endif
> >
> > -#define OFFSET_BITS_MASK   GENMASK(23, 0)
> > +#define OFFSET_BITS_MASK   ((FSL_QSPI_FLASH_SIZE  > SZ_16M) ? \
> > +   GENMASK(27, 0) :  GENMASK(23,
> > +0))
> >
> >  #define FLASH_STATUS_WEL   0x02
> >
> > @@ -760,7 +761,10 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int
> bitlen,
> > if (dout) {
> > if (flags & SPI_XFER_BEGIN) {
> > priv->cur_seqid = *(u8 *)dout;
> > -   memcpy(, dout, 4);
> > +   if (FSL_QSPI_FLASH_SIZE  > SZ_16M)
> > +   memcpy(, dout + 1, 4);
> > +   else
> > +   memcpy(, dout, 4);
> 
> This driver has lot of flash hacks, and I am completely unhappy about this
> please try to write new driver on flash side (mtd/spi).
> 
Hi Jagan,

Yes, I think so, I also think I need rewrite this driver now.
In fact, I'm working on this. But need more time, So I have to send those patch 
set to support 16M+ support.

Thanks for your support.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

2016-10-17 Thread Yao Yuan 
On 10/14/2016 11:36 PM, York Sun wrote:
> On 10/13/2016 11:45 PM, Yao Yuan wrote:
> > On 10/12/2016 08:00 PM, York Sun wrote:
> >> On 10/11/2016 08:00 PM, Yao Yuan wrote:
> >>>>
> >>>> Yuan Yao,
> >>>>
> >>>> I think the procedure can be applied to many of our boards with
> >>>> QSPI, right? It may be better to move this information out of ls2080aqds.
> >>>>
> >>>
> >>> Hi York,
> >>>
> >>> Yes, but a little difference for "CCSR  write" for different boards.
> >>> But the "CCSR write" should be wrote into uboot code or cw.
> >>> So, should I remove the notes for "CCSR  write" and then move this
> >>> information for  all the boards which support QSPI boot?
> >>>
> >>
> >> I think you can put the common practice together with specific
> >> examples for LS2080A, and other SoCs.
> >>
> >
> > Hi York,
> >
> > If move this information out of ls2080aqds.
> > Do you think where can I put the procedure for all the boards?
> > In every board's README or somewhere for the common procedure?
> >
> 
> Yao,
> 
> Take a look at these locations and decide which one fits best.
> 
> arch/arm/cpu/armv8/fsl-layerscape/doc/README.*
> doc/README.fsl-qspi (you can create this)
> 

Hi York,

It seems arch/arm/cpu/armv8/fsl-layerscape/doc/README.* is better.
I will update my patch and resend soon.

Thanks for your help.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

2016-10-14 Thread Yao Yuan 
On 10/12/2016 08:00 PM, York Sun wrote:
> On 10/11/2016 08:00 PM, Yao Yuan wrote:
> >>
> >> Yuan Yao,
> >>
> >> I think the procedure can be applied to many of our boards with QSPI,
> >> right? It may be better to move this information out of ls2080aqds.
> >>
> >
> > Hi York,
> >
> > Yes, but a little difference for "CCSR  write" for different boards.
> > But the "CCSR write" should be wrote into uboot code or cw.
> > So, should I remove the notes for "CCSR  write" and then move this
> > information for  all the boards which support QSPI boot?
> >
> 
> I think you can put the common practice together with specific examples for
> LS2080A, and other SoCs.
> 

Hi York,

If move this information out of ls2080aqds.
Do you think where can I put the procedure for all the boards?
In every board's README or somewhere for the common procedure?

Thanks.

Yao.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

2016-10-12 Thread Yao Yuan 
On 10/11/2016 11:04 PM, york sun wrote:
> On 10/10/2016 11:04 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  board/freescale/ls2080aqds/README | 35
> > +++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/board/freescale/ls2080aqds/README
> > b/board/freescale/ls2080aqds/README
> > index f288750..0f7446a 100644
> > --- a/board/freescale/ls2080aqds/README
> > +++ b/board/freescale/ls2080aqds/README
> > @@ -188,3 +188,38 @@ DPMAC14 -> PHY4-P1
> >  DPMAC15 -> PHY4-P2
> >  DPMAC16 -> PHY4-P3
> >
> > +
> > +Booting from QSPI
> > +---
> > +Booting from QSPI requires two images, RCW and u-boot-dtb.bin.
> > +The difference between QSPI boot RCW image and NOR boot image is the
> > +PBI command sequence. Below is the setting for PBI commands for QDS
> > +which boot on QSPI flash device.
> > +
> > +1) CCSR 4-byte write to 0x00e00404, data=0x
> > +2) CCSR 4-byte write to 0x00e00400, data=0x2001 The above two
> > +commands set bootloc register to 0x_2001 where the u-boot
> > +code will be running in QSPI flash.
> > +
> > +RCW image should be written to the beginning of QSPI flash device.
> > +Example of using u-boot command
> > +
> > +=> sf probe 0:0
> > +SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64
> > +KiB, total 32 MiB => sf erase 0 +
> > +SF: 65536 bytes @ 0x0 Erased: OK
> > +=> sf write  0 
> > +SF: 164 bytes @ 0x0 Written: OK
> > +
> > +To get the QSPI image, build u-boot with QSPI config, for example,
> > +ls2080aqds_qspi_defconfig. The image needed is u-boot-dtb.bin.
> > +The u-boot image should be written to 0x1.
> > +
> > +=> sf probe 0:0
> > +SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64
> > +KiB, total 32 MiB => sf erase 1 +
> > +SF: 589824 bytes @ 0x1 Erased: OK => sf write  > +memory> 1 
> > +SF: 580966 bytes @ 0x1 Written: OK
> > +
> > +With these two images in QSPI flash device, the board can boot from QSPI.
> >
> 
> Yuan Yao,
> 
> I think the procedure can be applied to many of our boards with QSPI, right? 
> It
> may be better to move this information out of ls2080aqds.
> 

Hi York,

Yes, but a little difference for "CCSR  write" for different boards.
But the "CCSR write" should be wrote into uboot code or cw.
So, should I remove the notes for "CCSR  write" and then move this information 
for
 all the boards which support QSPI boot?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

2016-06-22 Thread Yao Yuan 
On 06/22/2016 06:08 PM, Michael Trimarchi wrote:
> On Wed, Jun 22, 2016 at 10:00:49AM +0000, Yao Yuan wrote:
> > On 06/22/2016 03:59 PM, Michael Trimarchi wrote:
> > > The S25FS128 is part of S25FS-S family physical sectors may be
> > > configured as a hybrid combination of eight 4-kB parameter sectors
> > > at the top or bottom of the address space with all but one of the
> > > remaining sectors being uniform size. This rework a bit commit
> > >
> > > 80c1bfd2332e71dfe669cac53ba06b7435a7ca39
> > >
> > > and add this jedec part number
> > >
> > > Signed-off-by: Michael Trimarchi <mich...@amarulasolutions.com>
> > > ---
> > >  drivers/mtd/spi/spi_flash.c | 18 --
> > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mtd/spi/spi_flash.c
> > > b/drivers/mtd/spi/spi_flash.c index
> > > 64d4e0f..c993588 100644
> > > --- a/drivers/mtd/spi/spi_flash.c
> > > +++ b/drivers/mtd/spi/spi_flash.c
> > > @@ -972,6 +972,21 @@ int spi_flash_decode_fdt(const void *blob,
> > > struct spi_flash *flash)  #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
> > >
> > >  #ifdef CONFIG_SPI_FLASH_SPANSION
> > > +
> > > +inline int is_spansion_s25fss_family(u16 jedec, u16 ext_jedec) {
> > > + switch (jedec) {
> > > + case 0x0219:
> > > + case 0x0220:
> > > + case 0x2018:
> > > + if ((ext_jedec & 0xff00) == 0x4d00)
> > > + return 1;
> > > + default:;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > >  static int spansion_s25fss_disable_4KB_erase(struct spi_slave *spi)  {
> > >   u8 cmd[4];
> > > @@ -1072,8 +1087,7 @@ int spi_flash_scan(struct spi_flash *flash)
> > >* sector that is not overlaid by the parameter sectors.
> > >* The uniform sector erase command has no effect on parameter
> > > sectors.
> > >*/
> > > - if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> > > - (ext_jedec & 0xff00) == 0x4d00) {
> > > + if (is_spansion_s25fss_family(jedec, ext_jedec)) {
> > >   int ret;
> > >   u8 id[6];
> > >
> > > --
> >
> > Hi Michael,
> > From some datasheet for spansion flash, it seems all the spansion
> > S25FS family should disable 4kb.
> > So how about just judge the idcode[0]?
> >
> 
> I understand your point but I don't have enough part number and I can only to
> test on this one. I will verify this patch too and put my review and drop my
> personal one. Anyway can you ask if the first 0x8000 are considered by boot
> rom? I'm trying to boot from qspi an imx7d board and I create the parameter
> using the files/qspi-nor-spansion-s25fl128s-config but not sure if I need to 
> flash
> from 0x400 or from 0x8400. And then I think that bootloader should go from
> 0x1000 or from 0x9000 correct?
> Then from BOOT_FROM I choose qspi but what is the DEFAULT_ADDRESS
> 0x1000 or 0x400?
> 

I'm not sure what's the offset for imx7d, but for NXP LS series SOC.
The RCW_PBI offset: 0x0
The Uboot offset is defined by RCW_PBI code.(Such as 0x1)

> > Like:
> > diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> > index 64d4e0f..cfe3649 100644
> > --- a/drivers/mtd/spi/spi_flash.c
> > +++ b/drivers/mtd/spi/spi_flash.c
> > @@ -1072,8 +1072,7 @@ int spi_flash_scan(struct spi_flash *flash)
> >  * sector that is not overlaid by the parameter sectors.
> >  * The uniform sector erase command has no effect on parameter 
> > sectors.
> >  */
> > -   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> > -   (ext_jedec & 0xff00) == 0x4d00) {
> > +   if (idcode[0] == SPI_FLASH_CFI_MFR_SPANSION) {
> > int ret;
> > u8 id[6];
> >
> >
> > How about your think?
> 
> For me is fine if you are sure
> 
> Michael
> 
> >
> >
> >
> 
> --
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO  -  Founder  Cruquiuskade 47 |
> | +31(0)851119172 Amsterdam 1018 AM NL |
> |  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

2016-06-22 Thread Yao Yuan 
On 06/22/2016 03:59 PM, Michael Trimarchi wrote:
> The S25FS128 is part of S25FS-S family physical sectors may be configured as a
> hybrid combination of eight 4-kB parameter sectors at the top or bottom of the
> address space with all but one of the remaining sectors being uniform size. 
> This
> rework a bit commit
> 
> 80c1bfd2332e71dfe669cac53ba06b7435a7ca39
> 
> and add this jedec part number
> 
> Signed-off-by: Michael Trimarchi 
> ---
>  drivers/mtd/spi/spi_flash.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index
> 64d4e0f..c993588 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -972,6 +972,21 @@ int spi_flash_decode_fdt(const void *blob, struct
> spi_flash *flash)  #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
> 
>  #ifdef CONFIG_SPI_FLASH_SPANSION
> +
> +inline int is_spansion_s25fss_family(u16 jedec, u16 ext_jedec) {
> + switch (jedec) {
> + case 0x0219:
> + case 0x0220:
> + case 0x2018:
> + if ((ext_jedec & 0xff00) == 0x4d00)
> + return 1;
> + default:;
> + }
> +
> + return 0;
> +}
> +
>  static int spansion_s25fss_disable_4KB_erase(struct spi_slave *spi)  {
>   u8 cmd[4];
> @@ -1072,8 +1087,7 @@ int spi_flash_scan(struct spi_flash *flash)
>* sector that is not overlaid by the parameter sectors.
>* The uniform sector erase command has no effect on parameter
> sectors.
>*/
> - if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> - (ext_jedec & 0xff00) == 0x4d00) {
> + if (is_spansion_s25fss_family(jedec, ext_jedec)) {
>   int ret;
>   u8 id[6];
> 
> --

Hi Michael, 
>From some datasheet for spansion flash,
it seems all the spansion S25FS family should disable 4kb.
So how about just judge the idcode[0]?

Like:
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 64d4e0f..cfe3649 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1072,8 +1072,7 @@ int spi_flash_scan(struct spi_flash *flash)
 * sector that is not overlaid by the parameter sectors.
 * The uniform sector erase command has no effect on parameter sectors.
 */
-   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
-   (ext_jedec & 0xff00) == 0x4d00) {
+   if (idcode[0] == SPI_FLASH_CFI_MFR_SPANSION) {
int ret;
u8 id[6];


How about your think?



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 04/10] configs: ls2080aqds: disable IFC NOR & QIXIS when QSPI enable

2016-06-07 Thread Yao Yuan 
On 06/08/2016 01:24 AM, York Sun wrote:
> On 06/07/2016 01:26 AM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > When QSPI is enabled, NOR flash and QIXIS can't be accessed through
> > IFC due to pin mux.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  include/configs/ls2080aqds.h | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/include/configs/ls2080aqds.h
> > b/include/configs/ls2080aqds.h index 4b27114..a14b465 100644
> > --- a/include/configs/ls2080aqds.h
> > +++ b/include/configs/ls2080aqds.h
> > @@ -17,8 +17,18 @@ unsigned long get_board_ddr_clk(void);  #endif
> >
> >  #define CONFIG_SYS_FSL_CLK
> > +
> > +#ifdef CONFIG_FSL_QSPI
> > +#define CONFIG_SYS_NO_FLASH
> > +#undef CONFIG_CMD_IMLS
> > +#define CONFIG_SYS_CLK_FREQ1
> > +#define CONFIG_DDR_CLK_FREQ1
> 
> The whole point of using i2c early init is to remove the hard-coded clocks, 
> isn't it?
> 
> York

Yes, I have missed to remove this patch. I will remove this patch and test 
again.
Will resend this patch set soon.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 00/11] armv8: ls2080aqds: Enable QSPI boot support

2016-06-06 Thread Yao Yuan 
On 06/07/2016 02:41 AM, York Sun wrote:
> On 06/06/2016 03:53 AM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > This patch adds QSPI boot support for LS2080AQDS board.
> > The QSPI boot image need to be programmed into the QSPI flash first.
> > Then we can switch to booting from QSPI memory space.
> >
> > Yuan Yao (11):
> >   armv8: ls2080aqds: Select QSPI CLK div via SCFG
> >   configs: ls2080a_common: Remove duplicate NOR configs
> >   configs: ls2080aqds: disable IFC NOR & QIXIS when QSPI enable
> >   configs: ls2080aqds: Enable QSPI flash support
> >   dm: dts: ls2080aqds: Add QSPI dts node
> >   armv8: ls2080aqds: Config QSPI pin mux via FPGA in NAND boot
> >   configs: ls2080a: Increase load image len in NAND boot
> >   ls2080aqds_nand_defconfig: Enable QSPI & its dependence
> >   armv8: ls2080aqds: Enable QSPI boot support
> > Rebase in v3.
> >   drivers: i2c: mxc: Add early init
> > New add in v3.
> >   board: freescale: ls2080aqds: Enable early I2C access for QSPI boot
> > New add in v3.
> 
> Yuan,
> 
> Do you think you can reorder these patches so that early i2c init can be in 
> front
> of disabling IFC? Then you don't have to use fixed clk at all. I am thinking 
> if we
> run git bisect and this set could break QSPI boot if sys clk is other than 
> 100MHz.
> 
Sorry for the mistake, it's a good suggestion.
I will resend the patch soon.
Thanks for your review.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/5] Add QSPI support for LS2080A

2016-05-24 Thread Yao Yuan 
On 05/25 2016 AM, York Sun wrote:
> On 03/14/2016 11:44 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > There is the spansion S25FS-S family flash: s25fs256s1 on LS2080QDS
> > QSPI.
> >
> > Yuan Yao (5):
> >   spi: fsl_qspi: Fix issues on arm64
> >   spi: fsl_qspi: Assign AMBA mem according CS num in dts
> >   spi: fsl_qspi: Enable Spansion S25FS-S family flashes
> >   sf: Disable 4-KB erase command for SPANSION S25FS-S family
> >   armv8/ls1043a: update the node for QSPI support
> >
> >  arch/arm/dts/fsl-ls1043a.dtsi |   5 +-
> >  drivers/mtd/spi/sf_internal.h |   5 ++
> >  drivers/mtd/spi/spi_flash.c   |  72 +++
> >  drivers/spi/fsl_qspi.c| 159 -
> -
> >  4 files changed, 202 insertions(+), 39 deletions(-)
> >
> 
> Minor adjustment to commit messages.
> Applied to u-boot-fsl-qoriq master, awaiting upstream.
> 
> Thanks.
> 

Thanks for your review and helps.

Yao.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] spi: fsl_qspi: Fix issues on arm64

2016-05-18 Thread Yao Yuan 
On 05/18/2016 12:32 PM, York Sun wrote:
> On 03/14/2016 11:45 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > The address value and size value get from dts "reg" property have type
> > of u64 on arm64.
> > If we assign those values to "u32" variables, driver can't work correctly.
> > Converting the type of those variables to fdt_xxx_t.
> >
> > Signed-off-by: Yuan Yao 
> > Signed-off-by: Prabhakar Kushwaha 
> > Signed-off-by: Yuan Yao 
> > ---
> 
> Yuan,
> 
> Did you mean to put both your legacy freescale email id and your nxp email id
> in the signature lines? I can remove your freescale id if it was added by 
> mistake.
> I need to reformat your commit message anyway because some lines are too
> long.
> 
> York

Yes, you can remove the Freescale id.
Thanks for your review and helps.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/11] armv8: ls2080aqds: Enable QSPI boot support

2016-03-23 Thread Yao Yuan 
On 03/23/2016 03:09 AM, York Sun wrote:
> On 03/06/2016 11:56 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > This series add support for QSPI boot on LS2080AQDS.
> >
> > Yuan Yao (11):
> >   armv8: ls2080aqds: Select QSPI CLK div via SCFG
> >   configs: ls2080a_common: Remove duplicate NOR configs
> >   configs: ls2080aqds: disable IFC NOR & QIXIS when QSPI enable
> >   configs: ls2080aqds: Enable QSPI flash support
> >   dm: dts: ls2080aqds: Add QSPI dts node
> >   armv8: ls2080aqds: Config QSPI pin mux via FPGA in NAND boot
> >   configs: ls2080a: Increase load image len in NAND boot
> >   ls2080aqds_nand_defconfig: Enable QSPI & its dependence
> >   armv8: ls2080aqds: Enable QSPI boot support
> > Changed in v2:
> >  merged the patch:
> >  0009-armv8-ls2080aqds-Enable-QSPI-boot-support.patch
> >  0010-ls2080aqds-Enable-support-for-boot-from-QSPI.patch
> >  0012-LS2080QDS-QSPI-boot-fix-issues.patch
> >  in this patch.
> >   board/ls2080qds: add the procedure to deply QSPI image.
> > New add in v2.
> >   freescale: cmd: qixis: tidy up the duplicated code
> >
> >  arch/arm/dts/fsl-ls2080a-qds.dts   | 14 +++
> >  arch/arm/dts/fsl-ls2080a.dtsi  | 10 +
> >  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  4 ++
> >  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  3 ++
> >  board/freescale/common/qixis.c | 12 ++
> >  board/freescale/ls2080aqds/README  | 35 ++
> >  board/freescale/ls2080aqds/ls2080aqds.c| 16 
> >  common/board_f.c   |  6 +--
> >  configs/ls2080aqds_nand_defconfig  |  9 +
> >  configs/ls2080aqds_qspi_defconfig  | 10 +
> >  include/configs/ls2080a_common.h   | 11 ++
> >  include/configs/ls2080a_simu.h |  7 
> >  include/configs/ls2080aqds.h   | 43 
> > +-
> >  13 files changed, 159 insertions(+), 21 deletions(-)  create mode
> > 100644 configs/ls2080aqds_qspi_defconfig
> >
> 
> Yuan,
> 
> This set was sent before Jagan's comment on your v1 patch. Please let me
> know if you need to update your patches.
> 

Yes, I will update this patch set.
But from some review and comments there is a lot of the changes for this patch 
set.
So I need some time to confirm and test it.
I will resend this patch set as soon as possible.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/12] armv8: ls2080aqds: Enable QSPI boot support

2016-03-06 Thread Yao Yuan 
On 03/04/2016 12:49 AM, York Sun wrote:
> On 03/02/2016 06:30 PM, Yao Yuan wrote:
> > On 03/03/2016 12:52 AM, York Sun wrote:
> >> On 03/02/2016 02:41 AM, Yuan Yao wrote:
> >>> From: Yuan Yao <yao.y...@nxp.com>
> >>>
> >>> This patch adds QSPI boot support for LS2080AQDS board.
> >>> The QSPI boot image need to be programmed into the QSPI flash first.
> >>> Then the booting will start from QSPI memory space.
> >>>
> >>> Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> >>> ---
> >>
> >> Please update the README file to include procedure to deply QSPI image.
> >>
> >> York
> >
> > Hi York,
> >
> > Thanks for your review.
> > So where should I put the README file?
> >
> 
> board/freescale/ls2080aqds/README
> 
> York

Hi York,

Do you know is there any example exist in uboot that I can take reference?
Or is there any format and content requirement for the procedure to deply QSPI 
image?

Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 12/12] LS2080QDS: QSPI boot: fix issues.

2016-03-02 Thread Yao Yuan 
On 03/03/2016 10:58AM, Prabhakar Kushwaha wrote:
> > -Original Message-
> > From: Yuan Yao [mailto:yao.y...@freescale.com]
> > Sent: Wednesday, March 02, 2016 4:02 PM
> > To: york sun <york@nxp.com>
> > Cc: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>;
> > pratiyush.srivast...@freescale.com; u-boot@lists.denx.de; Yunhui Cui
> > <yunhui@nxp.com>; Yao Yuan <yao.y...@nxp.com>
> > Subject: [PATCH 12/12] LS2080QDS: QSPI boot: fix issues.
> >
> > From: Yuan Yao <yao.y...@nxp.com>
> >
> > This patch is used for fix the bug below:
> > /***/
> > "Synchronous Abort" handler, esr 0x86000210
> > ELR: fff6cfb4
> > LR:  fff6d3f0
> > x0 : 0022 x1 : fff78c6f
> > x2 : ffd0ecb0 x3 : 
> > x4 : ffd0ecd0 x5 : 
> > x6 : ffc8 x7 : 3fe0
> > x8 : 0083ffe0 x9 : 000c
> > x10: 0084 x11: 000c
> > x12: 0015 x13: 4000
> > x14: 0020 x15: 0001
> > x16: 1800f188 x17: 0001
> > x18: ffd11d78 x19: ffd0f010
> > x20: ffd0ed39 x21: fff80935
> > x22: fff78c6f x23: 0001
> > x24: ffd0f010 x25: ffd0ed38
> > x26: fff738e0 x27: fff72460
> > x28: fff92000 x29: ffd0ebd0
> >
> > Resetting CPU ...
> > /***/
> >
> 
> Can you please share more detail about error

Sorry, what do you means? 
I will update the commit message as York suggested before.

Thanks.
 
> 
> > Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> > ---
> >  arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 4 
> >  board/freescale/ls2080aqds/ls2080aqds.c| 2 ++
> >  common/board_f.c   | 6 +++---
> >  3 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > index 15ade84..794b764 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > @@ -120,6 +120,8 @@ static const struct sys_mmu_table
> > early_mmu_table[] = {
> >   PMD_SECT_NON_SHARE | PMD_SECT_PXN | PMD_SECT_UXN },
> > { CONFIG_SYS_FSL_OCRAM_BASE, CONFIG_SYS_FSL_OCRAM_BASE,
> >   CONFIG_SYS_FSL_OCRAM_SIZE, MT_NORMAL,
> PMD_SECT_NON_SHARE },
> > +   { CONFIG_SYS_FSL_QSPI_BASE1, CONFIG_SYS_FSL_QSPI_BASE1,
> > + CONFIG_SYS_FSL_QSPI_SIZE1,  MT_NORMAL,
> > PMD_SECT_NON_SHARE},
> > /* For IFC Region #1, only the first 4MB is cache-enabled */
> > { CONFIG_SYS_FSL_IFC_BASE1, CONFIG_SYS_FSL_IFC_BASE1,
> >   CONFIG_SYS_FSL_IFC_SIZE1_1, MT_NORMAL,
> PMD_SECT_NON_SHARE }, @@
> > -172,6 +174,8 @@ static const struct sys_mmu_table final_mmu_table[] =
> > {
> > { CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
> >   CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL,
> >   PMD_SECT_OUTER_SHARE | PMD_SECT_NS },
> > +   { CONFIG_SYS_FSL_QSPI_BASE1, CONFIG_SYS_FSL_QSPI_BASE1,
> > + CONFIG_SYS_FSL_QSPI_SIZE1,  MT_NORMAL,
> > PMD_SECT_NON_SHARE},
> > { CONFIG_SYS_FSL_QSPI_BASE2, CONFIG_SYS_FSL_QSPI_BASE2,
> >   CONFIG_SYS_FSL_QSPI_SIZE2, MT_DEVICE_NGNRNE,
> >   PMD_SECT_NON_SHARE | PMD_SECT_PXN | PMD_SECT_UXN }, diff -
> -git
> > a/board/freescale/ls2080aqds/ls2080aqds.c
> > b/board/freescale/ls2080aqds/ls2080aqds.c
> > index 7e09f11..8e174c3 100644
> > --- a/board/freescale/ls2080aqds/ls2080aqds.c
> > +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> > @@ -80,6 +80,8 @@ int checkboard(void)
> > puts("PromJet\n");
> > else if (sw == 0x9)
> > puts("NAND\n");
> > +   else if (sw == 0xf)
> > +   puts("QSPI\n");
> 
> This fix is nowhere related to the error you are fixing?
Yes, I will rewrite my commit for those patch.
This patch is used to fix two issue when QSPI boot.

> 
> > else if (sw == 0x15)
> > printf("IFCCard\n");
> > else
> > diff --git a/common/board_f.c b/common/board_f.c index
> > 622093a..1af1b4b
> > 100644
> > --- a/common/board_f.c
> > +++ b/common/board_f.c
> > @@ -912,9 +912,6 @@ static init_fnc_t init_sequence_f[] = {  #if
> > defined(CONFIG_MP

Re: [U-Boot] [PATCH 02/12] configs: ls2080a_common: Remove duplicate NOR configs

2016-03-02 Thread Yao Yuan 
On 03/03/2016 10:58AM, Prabhakar Kushwaha wrote:
> > -Original Message-
> > From: Yuan Yao [mailto:yao.y...@freescale.com]
> > Sent: Wednesday, March 02, 2016 4:02 PM
> > To: york sun <york@nxp.com>
> > Cc: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>;
> > pratiyush.srivast...@freescale.com; u-boot@lists.denx.de; Yunhui Cui
> > <yunhui@nxp.com>; Yao Yuan <yao.y...@nxp.com>
> > Subject: [PATCH 02/12] configs: ls2080a_common: Remove duplicate NOR
> > configs
> >
> > From: Yuan Yao <yao.y...@nxp.com>
> >
> > The NOR flash related configure options also appear in ls2080aqds.h
> > and ls2080ardb.h, and the two files all have included ls2080a_common.h.
> > This patch remove the duplicated options in ls2080a_common.h.
> >
> > Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> > ---
> >  include/configs/ls2080a_common.h | 7 ---
> >  include/configs/ls2080a_simu.h   | 7 +++
> >  2 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/configs/ls2080a_common.h
> > b/include/configs/ls2080a_common.h
> > index 64b82e8..82af464 100644
> > --- a/include/configs/ls2080a_common.h
> > +++ b/include/configs/ls2080a_common.h
> > @@ -148,13 +148,6 @@
> >  #define CONFIG_SYS_FLASH1_BASE_PHYS0xC000
> >  #define CONFIG_SYS_FLASH1_BASE_PHYS_EARLY  0x800
> >
> > -#ifndef CONFIG_SYS_NO_FLASH
> > -#define CONFIG_FLASH_CFI_DRIVER
> > -#define CONFIG_SYS_FLASH_CFI
> > -#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE -#define
> > CONFIG_SYS_FLASH_QUIET_TEST -#endif
> > -
> >  #ifndef __ASSEMBLY__
> >  unsigned long long get_qixis_addr(void);  #endif diff --git
> > a/include/configs/ls2080a_simu.h b/include/configs/ls2080a_simu.h
> > index 2c2ce7b..6a59afe 100644
> > --- a/include/configs/ls2080a_simu.h
> > +++ b/include/configs/ls2080a_simu.h
> > @@ -38,6 +38,13 @@
> >  #define CONFIG_SYS_NOR0_CSPR_EXT   (0x0)
> >  #define CONFIG_SYS_NOR_AMASK   IFC_AMASK(128*1024*1024)
> >
> > +#ifndef CONFIG_SYS_NO_FLASH
> > +#define CONFIG_FLASH_CFI_DRIVER
> > +#define CONFIG_SYS_FLASH_CFI
> > +#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE #define
> > +CONFIG_SYS_FLASH_QUIET_TEST #endif
> > +
> >  /*
> >   * NOR Flash Timing Params
> >   */
> > --
> 
> I will suggest other way around-->. Remove above defines from qds, rdb, simu
> header file and put in ls2080a_common.h.
> 
> --prabhakar
> 
> 

Hi Prabhakar,

Because of the macro CONFIG_SYS_NO_FLASH
Is must be define or not define in different board config file.
So the 
#ifndef CONFIG_SYS_NO_FLASH
can't put in ls2080a_common.h.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/12] configs: ls2080aqds: Disable IFC NOR & QIXIS when QSPI

2016-03-02 Thread Yao Yuan 
On 03/03/2016 10:58AM, Prabhakar Kushwaha wrote:
> > -Original Message-
> > From: Yuan Yao [mailto:yao.y...@freescale.com]
> > Sent: Wednesday, March 02, 2016 4:02 PM
> > To: york sun <york@nxp.com>
> > Cc: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>;
> > pratiyush.srivast...@freescale.com; u-boot@lists.denx.de; Yunhui Cui
> > <yunhui@nxp.com>; Yao Yuan <yao.y...@nxp.com>
> > Subject: [PATCH 03/12] configs: ls2080aqds: Disable IFC NOR & QIXIS
> > when QSPI
> >
> > From: Yuan Yao <yao.y...@nxp.com>
> >
> > When QSPI is enabled, NOR Flash and QIXIS can’t be accessed through
> > IFC due to pin muxing.
> >
> > Enable QIXIS accessing through I2C.
> >
> > Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> > ---
> >  include/configs/ls2080aqds.h | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/include/configs/ls2080aqds.h
> > b/include/configs/ls2080aqds.h index dab3820..3edb0b9 100644
> > --- a/include/configs/ls2080aqds.h
> > +++ b/include/configs/ls2080aqds.h
> > @@ -17,8 +17,18 @@ unsigned long get_board_ddr_clk(void);  #endif
> >
> >  #define CONFIG_SYS_FSL_CLK
> > +
> > +#ifdef CONFIG_FSL_QSPI
> > +#define CONFIG_SYS_NO_FLASH
> > +#undef CONFIG_CMD_IMLS
> > +#define CONFIG_SYS_CLK_FREQ1
> > +#define CONFIG_DDR_CLK_FREQ1
> > +#define CONFIG_QIXIS_I2C_ACCESS
> 
> If we are accessing QIXIS via I2c then why hard-coding SYSCLK and DDRCLK?
> 

If we aren't hard-coding SYSCLK and DDRCLK. We don't have any other way to get 
the
SYSCLK and DDRCLK.
We can't get it by read FPGA before config I2C.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/12] armv8: ls2080aqds: Enable QSPI boot support

2016-03-02 Thread Yao Yuan 
On 03/03/2016 12:52 AM, York Sun wrote:
> On 03/02/2016 02:41 AM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > This patch adds QSPI boot support for LS2080AQDS board.
> > The QSPI boot image need to be programmed into the QSPI flash first.
> > Then the booting will start from QSPI memory space.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> 
> Please update the README file to include procedure to deply QSPI image.
> 
> York

Hi York,

Thanks for your review.
So where should I put the README file? 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/12] armv8: ls2080aqds: Config QSPI pin mux via FPGA in NAND boot

2016-03-02 Thread Yao Yuan 
On 03/03/2016 12:52 AM, York Sun wrote:
> On 03/02/2016 02:41 AM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > If we want to access QSPI flash when boot from NAND,
> 
> Is this "either this or that" choice? Is there any limitation after 
> configuring pin
> mux?

No, there is no any limitation.
Just make a distinction between the different NAND source.
And deasserted unused ISO will approve the performance.

Such as for LS2080AQDS, the last three bits for brdcfg[9] should be set to 
0b'001.

> > we need below board configuration:
> > Boot Source ISO1ISO2IBOOT
> > On-board NAND   1   0   0
> > IFCCARD NAND0   0   1
> 
> This should be added to README file.
> 

So I need remove it from the uboot code?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 12/12] LS2080QDS: QSPI boot: fix issues.

2016-03-02 Thread Yao Yuan 
On 03/03/2016 12:52 AM, York Sun wrote: 
> On 03/02/2016 02:41 AM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > This patch is used for fix the bug below:
> > /***/
> > "Synchronous Abort" handler, esr 0x86000210
> > ELR: fff6cfb4
> > LR:  fff6d3f0
> > x0 : 0022 x1 : fff78c6f
> > x2 : ffd0ecb0 x3 : 
> > x4 : ffd0ecd0 x5 : 
> > x6 : ffc8 x7 : 3fe0
> > x8 : 0083ffe0 x9 : 000c
> > x10: 0084 x11: 000c
> > x12: 0015 x13: 4000
> > x14: 0020 x15: 0001
> > x16: 1800f188 x17: 0001
> > x18: ffd11d78 x19: ffd0f010
> > x20: ffd0ed39 x21: fff80935
> > x22: fff78c6f x23: 0001
> > x24: ffd0f010 x25: ffd0ed38
> > x26: fff738e0 x27: fff72460
> > x28: fff92000 x29: ffd0ebd0
> >
> > Resetting CPU ...
> > /***/
> 
> This commit message is not appropriate. It doesn't match the change either.
> You should explain why a new entry was added to MMU table, and why you
> moved "show_board_info" down.
> 

Ok, I will update the commit message in the next version. 
Thanks.
 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 4 
> >  board/freescale/ls2080aqds/ls2080aqds.c| 2 ++
> >  common/board_f.c   | 6 +++---
> >  3 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > index 15ade84..794b764 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > @@ -120,6 +120,8 @@ static const struct sys_mmu_table early_mmu_table[]
> = {
> >   PMD_SECT_NON_SHARE | PMD_SECT_PXN | PMD_SECT_UXN },
> > { CONFIG_SYS_FSL_OCRAM_BASE, CONFIG_SYS_FSL_OCRAM_BASE,
> >   CONFIG_SYS_FSL_OCRAM_SIZE, MT_NORMAL,
> PMD_SECT_NON_SHARE },
> > +   { CONFIG_SYS_FSL_QSPI_BASE1, CONFIG_SYS_FSL_QSPI_BASE1,
> > + CONFIG_SYS_FSL_QSPI_SIZE1,  MT_NORMAL,
> PMD_SECT_NON_SHARE},
> > /* For IFC Region #1, only the first 4MB is cache-enabled */
> > { CONFIG_SYS_FSL_IFC_BASE1, CONFIG_SYS_FSL_IFC_BASE1,
> >   CONFIG_SYS_FSL_IFC_SIZE1_1, MT_NORMAL,
> PMD_SECT_NON_SHARE }, @@
> > -172,6 +174,8 @@ static const struct sys_mmu_table final_mmu_table[] = {
> > { CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
> >   CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL,
> >   PMD_SECT_OUTER_SHARE | PMD_SECT_NS },
> > +   { CONFIG_SYS_FSL_QSPI_BASE1, CONFIG_SYS_FSL_QSPI_BASE1,
> > + CONFIG_SYS_FSL_QSPI_SIZE1,  MT_NORMAL,
> PMD_SECT_NON_SHARE},
> > { CONFIG_SYS_FSL_QSPI_BASE2, CONFIG_SYS_FSL_QSPI_BASE2,
> >   CONFIG_SYS_FSL_QSPI_SIZE2, MT_DEVICE_NGNRNE,
> >   PMD_SECT_NON_SHARE | PMD_SECT_PXN | PMD_SECT_UXN }, diff -
> -git
> > a/board/freescale/ls2080aqds/ls2080aqds.c
> > b/board/freescale/ls2080aqds/ls2080aqds.c
> > index 7e09f11..8e174c3 100644
> > --- a/board/freescale/ls2080aqds/ls2080aqds.c
> > +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> > @@ -80,6 +80,8 @@ int checkboard(void)
> > puts("PromJet\n");
> > else if (sw == 0x9)
> > puts("NAND\n");
> > +   else if (sw == 0xf)
> > +   puts("QSPI\n");
> > else if (sw == 0x15)
> > printf("IFCCard\n");
> > else
> > diff --git a/common/board_f.c b/common/board_f.c index
> > 622093a..1af1b4b 100644
> > --- a/common/board_f.c
> > +++ b/common/board_f.c
> > @@ -912,9 +912,6 @@ static init_fnc_t init_sequence_f[] = {  #if
> > defined(CONFIG_MPC5xxx)
> > prt_mpc5xxx_clks,
> >  #endif /* CONFIG_MPC5xxx */
> > -#if defined(CONFIG_DISPLAY_BOARDINFO)
> > -   show_board_info,
> > -#endif
> > INIT_FUNC_WATCHDOG_INIT
> >  #if defined(CONFIG_MISC_INIT_F)
> > misc_init_f,
> > @@ -923,6 +920,9 @@ static init_fnc_t init_sequence_f[] = {  #if
> > defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C)
> > init_func_i2c,
> >  #endif
> > +#if defined(CONFIG_DISPLAY_BOARDINFO)
> > +   show_board_info,
> > +#endif
> >  #if defined(CONFIG_HARD_SPI)
> > init_func_spi,
> >  #endif
> >
> 
> 
> York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/12] ls2080aqds: Enable support for boot from QSPI

2016-03-02 Thread Yao Yuan 
On 03/03/2016 12:52 AM, York Sun wrote: 
> On 03/02/2016 02:41 AM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  include/configs/ls2080aqds.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/include/configs/ls2080aqds.h
> > b/include/configs/ls2080aqds.h index 513a2e3..064e341 100644
> > --- a/include/configs/ls2080aqds.h
> > +++ b/include/configs/ls2080aqds.h
> > @@ -183,11 +183,13 @@ unsigned long get_board_ddr_clk(void);
> >  #define QIXIS_LBMAP_DFLTBANK   0x00
> >  #define QIXIS_LBMAP_ALTBANK0x04
> >  #define QIXIS_LBMAP_NAND   0x09
> > +#define QIXIS_LBMAP_QSPI   0x0f
> >  #define QIXIS_RST_CTL_RESET0x31
> >  #define QIXIS_RCFG_CTL_RECONFIG_IDLE   0x20
> >  #define QIXIS_RCFG_CTL_RECONFIG_START  0x21
> >  #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE  0x08
> >  #define QIXIS_RCW_SRC_NAND 0x107
> > +#define QIXIS_RCW_SRC_QSPI 0x62
> >  #defineQIXIS_RST_FORCE_MEM 0x01
> >
> >  #define CONFIG_SYS_CSPR3_EXT   (0x0)
> >
> 
> Why wasn't this patch squashed with the 9th patch in this set?
> 
> York

This patch is just adding the command:
qixis_reset qspi
support on LS2080AQDS.

9th patch is used for add the QSPI Boot support.

The function is different.
But I can also merge them into one patch. It seems more tidy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V5 2/4] spi: fsl_qspi: Fix qspi_op_rdid memcpy issue

2016-01-24 Thread Yao Yuan 
On 01/25/2016 04:16 AM, York Sun wrote:
> On 01/22/2016 07:43 AM, Scott Wood wrote:
> > On 01/21/2016 09:35 PM, Qianyu Gong wrote:
> >>
> >>> -Original Message-
> >>> From: Scott Wood
> >>> Sent: Friday, January 22, 2016 3:30 AM
> >>> To: Qianyu Gong ; u-boot@lists.denx.de;
> >>> r58...@freescale.com
> >>> Cc: mingkai...@freescale.com; jt...@openedev.com;
> >>> b48...@freescale.com; shaohui@freescale.com;
> >>> wenbin.s...@freescale.com; Scott Wood ; Gong
> >>> Qianyu 
> >>> Subject: Re: [Patch V5 2/4] spi: fsl_qspi: Fix qspi_op_rdid memcpy
> >>> issue
> >>>
> >>> On 01/20/2016 09:43 PM, Gong Qianyu wrote:
>  From: Gong Qianyu 
> 
>  In current driver everytime we memcpy 4 bytes to the dest memory
>  regardless of the remaining length.
>  This patch adds checking the remaining length before memcpy.
>  If the length is shorter than 4 bytes, memcpy the actual length of
>  data to the dest memory.
> 
>  Signed-off-by: Gong Qianyu 
>  ---
>  V2-V5:
>   - No change.
> 
>   drivers/spi/fsl_qspi.c | 5 -
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
>  diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
>  38e5900..f178857 100644
>  --- a/drivers/spi/fsl_qspi.c
>  +++ b/drivers/spi/fsl_qspi.c
>  @@ -500,7 +500,10 @@ static void qspi_op_rdid(struct fsl_qspi_priv
>  *priv, u32
> >>> *rxbuf, u32 len)
>   if (rbsr_reg & QSPI_RBSR_RDBFL_MASK) {
>   data = qspi_read32(priv->flags, >rbdr[i]);
>   data = qspi_endian_xchg(data);
>  -memcpy(rxbuf, , 4);
>  +if (size < 4)
>  +memcpy(rxbuf, , size);
>  +else
>  +memcpy(rxbuf, , 4);
> >>>
> >>> memcpy(rxbuf, , min(size, 4));
> >>>
>   rxbuf++;
>   size -= 4;
>   i++;
> >>>
> >>> size -= 4 even if size was < 4?
> >>>
> >>> -Scott
> >>
> >> Yes.. The following is complete code:
> >>
> >> i = 0;
> >> size = len;
> >> while ((RX_BUFFER_SIZE >= size) && (size > 0)) {
> >> rbsr_reg = qspi_read32(priv->flags, >rbsr);
> >> if (rbsr_reg & QSPI_RBSR_RDBFL_MASK) {
> >> data = qspi_read32(priv->flags, >rbdr[i]);
> >> data = qspi_endian_xchg(data);
> >> memcpy(rxbuf, , min(size, 4));
> >> rxbuf++;
> >> size -= 4;
> >> i++;
> >> }
> >> }
> >
> > I'm not saying it doesn't work (assuming i is signed, which the
> > "complete code" above doesn't show).  I'm saying it looks weird, and
> > it would be better to have a variable that holds min(size, 4) and pass
> > that to both memcpy and the subtraction.
> >
> 
> Qianyu,
> 
> Previously I said it looked weird for doing this. Please fix.
> 
> "size" is declared as "int".
> "len" is declared as u32. That's not "int". If you trace back the functions, 
> you
> may see it came from DIV_ROUND_UP(bitlen, 8) where bitlen is "unsigned int".
> So technically the code is safe. But it is _confusing_. We don't want to 
> confuse
> ourselves when reading the code later. And the fix is easy, isn't it?
> 
> York
> 

How about like this?

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index feec3e8..13bba09 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -477,8 +477,8 @@ static void qspi_op_rdbank(struct fsl_qspi_priv *priv, u8 
*rxbuf, u32 len)
 static void qspi_op_rdid(struct fsl_qspi_priv *priv, u32 *rxbuf, u32 len)
 {
struct fsl_qspi_regs *regs = priv->regs;
-   u32 mcr_reg, rbsr_reg, data;
-   int i, size;
+   u32 mcr_reg, rbsr_reg, data, size;
+   int i;

mcr_reg = qspi_read32(priv->flags, >mcr);
qspi_write32(priv->flags, >mcr,
@@ -495,14 +495,14 @@ static void qspi_op_rdid(struct fsl_qspi_priv *priv, u32 
*rxbuf, u32 len)

i = 0;
size = len;
-   while ((RX_BUFFER_SIZE >= size) && (size > 0)) {
+   while ((RX_BUFFER_SIZE >= size) && (size != 0)) {
rbsr_reg = qspi_read32(priv->flags, >rbsr);
if (rbsr_reg & QSPI_RBSR_RDBFL_MASK) {
data = qspi_read32(priv->flags, >rbdr[i]);
data = qspi_endian_xchg(data);
-   memcpy(rxbuf, , 4);
+   memcpy(rxbuf, , min(size, 4));
+   size = (size < 4) ? 0 : ( size - 4);
rxbuf++;
-   size -= 4;
i++;
}
}

Re: [U-Boot] [PATCH 3/5] ls102xa: Enable snoop and DVM message requests.

2015-12-14 Thread Yao Yuan 
Hi York,

Thanks for your review and modified.

Best Regards,
Yuan Yao

> -Original Message-
> From: Sun York-R58495
> Sent: Tuesday, December 15, 2015 9:00 AM
> To: Yuan Yao-B46683 
> Cc: Wang Huan-B18965 ; u-boot@lists.denx.de
> Subject: Re: [PATCH 3/5] ls102xa: Enable snoop and DVM message requests.
> 
> 
> 
> On 12/05/2015 02:59 PM, Yuan Yao wrote:
> > Signed-off-by: Yuan Yao 
> > ---
> >
> >  arch/arm/cpu/armv7/ls102xa/soc.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> 
> Modified subject, added commit message.
> Applied to fsl-qoriq master. Awaiting upstream.
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] ls102xa: Enable snoop and DVM message requests.

2015-12-14 Thread Yao Yuan 
Hi York,

I'm sorry I'm late replies.

Thanks for reminding me.
We have some investigates and then depend on the document we think both snoop 
request and DVM are supported on those port.
So we think the setting should be ok in here.

Best Regards,
Yuan Yao

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Tuesday, December 08, 2015 12:58 AM
> To: Yuan Yao-B46683 
> Cc: Wang Huan-B18965 ; u-boot@lists.denx.de
> Subject: Re: [PATCH 3/5] ls102xa: Enable snoop and DVM message requests.
> 
> 
> 
> On 12/04/2015 10:59 PM, Yuan Yao wrote:
> > Signed-off-by: Yuan Yao 
> > ---
> >
> >  arch/arm/cpu/armv7/ls102xa/soc.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c
> > b/arch/arm/cpu/armv7/ls102xa/soc.c
> > index 6036473..97ba6d5 100644
> > --- a/arch/arm/cpu/armv7/ls102xa/soc.c
> > +++ b/arch/arm/cpu/armv7/ls102xa/soc.c
> > @@ -40,8 +40,14 @@ int arch_soc_init(void)
> >
> > /*
> >  * Enable snoop requests and DVM message requests for
> > -* Slave insterface S4 (A7 core cluster)
> > +* All the slave insterfaces.
> >  */
> > +   out_le32(>slave[0].snoop_ctrl,
> > +CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN);
> > +   out_le32(>slave[1].snoop_ctrl,
> > +CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN);
> > +   out_le32(>slave[2].snoop_ctrl,
> > +CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN);
> > out_le32(>slave[4].snoop_ctrl,
> >  CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN);
> >
> >
> 
> Yuan,
> 
> I'm not sure both snoop request and DVM are supported on every port. Do you
> need to check them before setting?
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] move erratum a008336 and a008514 to soc specific file

2015-12-04 Thread Yao Yuan 
On 12/05/2015 01:12 AM, York Sun wrote:
> On 12/04/2015 01:37 AM, Yuan Yao wrote:
> > As the errata A008336 and A008514 do not apply to all LS series SoCs
> > (such as LS1021A, LS1043A) we move them to an soc specific file
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Update the patch commit message.
> > ---
> >
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c | 37
> +
> >  drivers/ddr/fsl/fsl_ddr_gen4.c  | 34 --
> >  2 files changed, 37 insertions(+), 34 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index 8896b70..738b113 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -14,6 +14,41 @@
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> >  #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> > +/*
> > + * This erratum requires setting a value to eddrtqcr1 to
> > + * optimal the DDR performance.
> > + */
> > +static void erratum_a008336(void)
> > +{
> > +   u32 *eddrtqcr1;
> > +
> > +#ifdef CONFIG_SYS_FSL_ERRATUM_A008336 #ifdef
> > +CONFIG_SYS_FSL_DCSR_DDR_ADDR
> > +   eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR_ADDR + 0x800;
> > +   out_le32(eddrtqcr1, 0x63b30002);
> > +#endif
> > +#ifdef CONFIG_SYS_FSL_DCSR_DDR2_ADDR
> > +   eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR2_ADDR + 0x800;
> > +   out_le32(eddrtqcr1, 0x63b30002);
> > +#endif
> > +#endif
> > +}
> > +
> > +/*
> > + * This erratum requires a register write before being Memory
> > + * controller 3 being enabled.
> > + */
> > +static void erratum_a008514(void)
> > +{
> > +   u32 *eddrtqcr1;
> > +
> > +#ifdef CONFIG_SYS_FSL_ERRATUM_A008514 #ifdef
> > +CONFIG_SYS_FSL_DCSR_DDR2_ADDR
> 
> I believe this is a typo. It should be CONFIG_SYS_FSL_DCSR_DDR3_ADDR.
> 
Thanks  york,
Yes, it's a typo. It should be CONFIG_SYS_FSL_DCSR_DDR3_ADDR. 
Sorry for the mistake. I will update it soon.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] move the erratum_a008336_a008514 from general ddr file to soc file

2015-11-29 Thread Yao Yuan 
Hi Sinan Akman,

Thanks for your review, I will update my commit message in the next version.

Best Regards,

Yuan Yao

On 27/11/2015 12:04 AM, Sinan Akman wrote:
   Hi Yuan

On 26/11/15 02:58 AM, Yuan Yao wrote:
> Both of the erratum:A008336 and A008514 are not apply to all the soc 
> like:LS1021A, LS1043A.

   nitpick : perhaps you could reword the commit message to make it a bit more 
clear. A suggestion :

   "As the errata A008336 and A008514 do not apply to all LS series SoCs (such 
as LS1021A, LS1043A) we move them to an soc specific file"

> So it seems better to move those erratum codes form the general ddr 
> file to the private soc file.
>
> Signed-off-by: Yuan Yao 
> ---
>   arch/arm/cpu/armv8/fsl-layerscape/soc.c | 37 
> +
>   drivers/ddr/fsl/fsl_ddr_gen4.c  | 34 --
>   2 files changed, 37 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 8896b70..738b113 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c

   Not exactly related to this patch but at this point we have :

   armv7/ls102xa
   armv8/fsl-layerscape

   I think ls102x is also considered a layerscape SoC and this is potentially 
confusing. Perhaps in another patch we can come up with better naming.

   Regards
   Sinan Akman

> @@ -14,6 +14,41 @@
>   DECLARE_GLOBAL_DATA_PTR;
>
>   #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> +/*
> + * This erratum requires setting a value to eddrtqcr1 to
> + * optimal the DDR performance.
> + */
> +static void erratum_a008336(void)
> +{
> + u32 *eddrtqcr1;
> +
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A008336 #ifdef 
> +CONFIG_SYS_FSL_DCSR_DDR_ADDR
> + eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR_ADDR + 0x800;
> + out_le32(eddrtqcr1, 0x63b30002);
> +#endif
> +#ifdef CONFIG_SYS_FSL_DCSR_DDR2_ADDR
> + eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR2_ADDR + 0x800;
> + out_le32(eddrtqcr1, 0x63b30002);
> +#endif
> +#endif
> +}
> +
> +/*
> + * This erratum requires a register write before being Memory
> + * controller 3 being enabled.
> + */
> +static void erratum_a008514(void)
> +{
> + u32 *eddrtqcr1;
> +
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A008514 #ifdef 
> +CONFIG_SYS_FSL_DCSR_DDR2_ADDR
> + eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR3_ADDR + 0x800;
> + out_le32(eddrtqcr1, 0x63b20002);
> +#endif
> +#endif
> +}
>   #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
>   #define PLATFORM_CYCLE_ENV_VAR  "a009635_interval_val"
>
> @@ -118,6 +153,8 @@ void fsl_lsch3_early_init_f(void)
>   erratum_rcw_src();
>   init_early_memctl_regs();   /* tighten IFC timing */
>   erratum_a009203();
> + erratum_a008514();
> + erratum_a008336();
>   }
>
>   #elif defined(CONFIG_LS1043A)
> diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c 
> b/drivers/ddr/fsl/fsl_ddr_gen4.c index 50f4671..d7cbf34 100644
> --- a/drivers/ddr/fsl/fsl_ddr_gen4.c
> +++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
> @@ -48,10 +48,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t 
> *regs,
>   u32 temp_sdram_cfg;
>   u32 total_gb_size_per_controller;
>   int timeout;
> -#if defined(CONFIG_SYS_FSL_ERRATUM_A008336) || \
> - defined(CONFIG_SYS_FSL_ERRATUM_A008514)
> - u32 *eddrtqcr1;
> -#endif
>   #ifdef CONFIG_SYS_FSL_ERRATUM_A008511
>   u32 temp32, mr6;
>   u32 vref_seq1[3] = {0x80, 0x96, 0x16};  /* for range 1 */
> @@ -69,36 +65,20 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t 
> *regs,
>   switch (ctrl_num) {
>   case 0:
>   ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR; -#if 
> defined(CONFIG_SYS_FSL_ERRATUM_A008336) || \
> - defined(CONFIG_SYS_FSL_ERRATUM_A008514)
> - eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR_ADDR + 0x800;
> -#endif
>   break;
>   #if defined(CONFIG_SYS_FSL_DDR2_ADDR) && (CONFIG_NUM_DDR_CONTROLLERS > 1)
>   case 1:
>   ddr = (void *)CONFIG_SYS_FSL_DDR2_ADDR; -#if 
> defined(CONFIG_SYS_FSL_ERRATUM_A008336) || \
> - defined(CONFIG_SYS_FSL_ERRATUM_A008514)
> - eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR2_ADDR + 0x800;
> -#endif
>   break;
>   #endif
>   #if defined(CONFIG_SYS_FSL_DDR3_ADDR) && (CONFIG_NUM_DDR_CONTROLLERS > 2)
>   case 2:
>   ddr = (void *)CONFIG_SYS_FSL_DDR3_ADDR; -#if 
> defined(CONFIG_SYS_FSL_ERRATUM_A008336) || \
> - defined(CONFIG_SYS_FSL_ERRATUM_A008514)
> - eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR3_ADDR + 0x800;
> -#endif
>   break;
>   #endif
>   #if defined(CONFIG_SYS_FSL_DDR4_ADDR) && (CONFIG_NUM_DDR_CONTROLLERS > 3)
>   case 3:
>   ddr = (void *)CONFIG_SYS_FSL_DDR4_ADDR; -#if 
> defined(CONFIG_SYS_FSL_ERRATUM_A008336) || \
> - defined(CONFIG_SYS_FSL_ERRATUM_A008514)
> - eddrtqcr1 = (void *)CONFIG_SYS_FSL_DCSR_DDR4_ADDR + 0x800;
> -#endif
>

Re: [U-Boot] [PATCH 5/6] LS102XA:workaround:disable priorities within DDR

2015-11-25 Thread Yao Yuan 
Hi Sinan Akman,

Thanks for your review.
There should not cause any problem with Rev1.0.
The workaround should also apply to rev1.0.

Best Regards,
Yuan Yao

> -Original Message-
> From: Sinan Akman [mailto:si...@writeme.com]
> Sent: Wednesday, November 25, 2015 12:10 AM
> To: Yuan Yao-B46683 ; Sun York-R58495
> 
> Cc: u-boot@lists.denx.de; Wang Huan-B18965 
> Subject: Re: [U-Boot] [PATCH 5/6] LS102XA:workaround:disable priorities
> within DDR
> 
> 
>Hi Yuan
> 
> On 24/11/15 05:45 AM, Yuan Yao wrote:
> > Erratum number: ERR008514
> > EDDRTQCFG Registers are Integration Strap values which controls
> > performance parameters for DDR Controller.
> >
> > The bit 25 is used to disable priorities within DDR since DDR are
> > connected backwards on Rev2.0 silicon for LS1021A.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >   arch/arm/cpu/armv7/ls102xa/soc.c | 13 -
> >   1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c
> > b/arch/arm/cpu/armv7/ls102xa/soc.c
> > index b15cd60..98d4acd 100644
> > --- a/arch/arm/cpu/armv7/ls102xa/soc.c
> > +++ b/arch/arm/cpu/armv7/ls102xa/soc.c
> > @@ -25,7 +25,7 @@ int arch_soc_init(void)
> >   {
> > struct ccsr_scfg *scfg = (struct ccsr_scfg
> *)CONFIG_SYS_FSL_SCFG_ADDR;
> > struct ccsr_cci400 *cci = (struct ccsr_cci400
> *)CONFIG_SYS_CCI400_ADDR;
> > -   unsigned int major;
> > +   unsigned int major, reg;
> >
> >   #ifdef CONFIG_FSL_QSPI
> > out_be32(>qspi_cfg, SCFG_QSPI_CLKSEL); @@ -86,5 +86,16 @@
> int
> > arch_soc_init(void)
> >  */
> > out_be32(>eddrtqcfg, 0x63b20002);
> >
> > +   /*
> > +* EDDRTQCFG Registers are Integration Strap values which controls
> > +* performance parameters for DDR Controller.
> > +* The bit 25 is used for disable priorities within DDR.
> > +* This is a workaround because of the DDR are connected backwards
> > +* on Rev2.0.
> 
>Would this cause any problem with Rev1.0 ?
> If it does, should we check the revision here.
> 
>Regards
>Sinan Akman
> 
> > +*/
> > +   reg = in_be32(>eddrtqcfg);
> > +   reg |= 1 << 6;
> > +   out_be32(>eddrtqcfg, reg);
> > +
> > return 0;
> >   }
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum A008514

2015-11-15 Thread Yao Yuan 
Hi York,

Thanks,
And is there any other comments for this set of patches?
Or could I send v3 for review?

Best Regards,

Yuan Yao

From: York Sun 
Sent: Wednesday, November 11, 2015 0:43
To: Yuan Yao-B46683
Cc: Wang Huan-B18965; u-boot@lists.denx.de
Subject: Re: [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum 
A008514

On 11/10/2015 05:18 AM, Yuan Yao-B46683 wrote:
> Thanks york,
>
> So it seems I should moving the workaround out of DDR driver in "gen4" to SoC.
> I think the workaround is not just only for ddr4.
> And It should be as a workaround for the SOC.

Please make the patch if you are comfortable. Please gate the code with the
macro CONFIG_SYS_FSL_ERRATUM_A008514.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum A008514

2015-11-10 Thread Yao Yuan 
Thanks york,

So it seems I should moving the workaround out of DDR driver in "gen4" to SoC.
I think the workaround is not just only for ddr4.
And It should be as a workaround for the SOC.


From: York Sun 
Sent: Tuesday, November 10, 2015 1:01
To: Yuan Yao-B46683
Cc: Wang Huan-B18965; u-boot@lists.denx.de
Subject: Re: [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum 
A008514

On 11/09/2015 01:30 AM, Yuan Yao-B46683 wrote:
> Hi york,
>
> Is it for DDR4?
> LS1021A doesn't use this file.

LS1021A support both DDR3 and DDR4. DDR4 mode uses this driver, doesn't it?
My concern is if the workaround is implemented in different places, it will be
harder to maintain in future versions fix this erratum. Maybe moving the
workaround out of DDR driver to SoC is not a bad idea.

York


>
> Best Regards,
> Yuan Yao
>
>> -Original Message-
>> From: York Sun [mailto:york...@freescale.com]
>> Sent: Friday, November 06, 2015 2:05 AM
>> To: Yuan Yao-B46683 
>> Cc: Wang Huan-B18965 ; u-boot@lists.denx.de
>> Subject: Re: [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum
>> A008514
>>
>>
>>
>> On 11/05/2015 02:26 AM, Yuan Yao wrote:
>>> This is a workaround for hardware erratum.
>>> Write the value of 63b2_0002h to EDDRTQCFG will optimal the memory
>>> controller performance.
>>>
>>> The value: 63b2_0002h comes from the hardware team.
>>>
>>> Signed-off-by: Yuan Yao 
>>> ---
>>> Changes in v2:
>>> Rewrite the commit message to explain why and what this patch does.
>>> ---
>>>  arch/arm/cpu/armv7/ls102xa/soc.c  | 10 ++
>>>  arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h |  2 +-
>>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> Workaround for A008514 is already implemented in DDR driver
>> drivers/ddr/fsl/fsl_ddr_gen4.c. Please see if you can merge your workaround
>> into it.
>>
>> York
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum A008514

2015-11-09 Thread Yao Yuan 
Hi york,

Is it for DDR4?
LS1021A doesn't use this file.

Best Regards,
Yuan Yao

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Friday, November 06, 2015 2:05 AM
> To: Yuan Yao-B46683 
> Cc: Wang Huan-B18965 ; u-boot@lists.denx.de
> Subject: Re: [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum
> A008514
> 
> 
> 
> On 11/05/2015 02:26 AM, Yuan Yao wrote:
> > This is a workaround for hardware erratum.
> > Write the value of 63b2_0002h to EDDRTQCFG will optimal the memory
> > controller performance.
> >
> > The value: 63b2_0002h comes from the hardware team.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changes in v2:
> > Rewrite the commit message to explain why and what this patch does.
> > ---
> >  arch/arm/cpu/armv7/ls102xa/soc.c  | 10 ++
> >  arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h |  2 +-
> >  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> Workaround for A008514 is already implemented in DDR driver
> drivers/ddr/fsl/fsl_ddr_gen4.c. Please see if you can merge your workaround
> into it.
> 
> York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] LS102XA:workaround:disable priorities within DDR

2015-11-04 Thread Yao Yuan 
Yes, it's an erratum. But I don't have the erratum  number from the document. I 
will connect the hardware team to check whether there is an erratum number.

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Thursday, November 05, 2015 2:49 AM
> To: Yuan Yao-B46683 ; Wang Huan-B18965
> 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH 5/5] LS102XA:workaround:disable priorities within DDR
> 
> 
> 
> On 10/21/2015 03:14 AM, Yuan Yao wrote:
> > EDDRTQCFG Registers are Integration Strap values which controls
> > performance parameters for DDR Controller.
> >
> > The bit 25 is used to disable priorities within DDR since DDR are
> > connected backwards on Rev2.0.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm/cpu/armv7/ls102xa/soc.c | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c
> > b/arch/arm/cpu/armv7/ls102xa/soc.c
> > index b15cd60..98d4acd 100644
> > --- a/arch/arm/cpu/armv7/ls102xa/soc.c
> > +++ b/arch/arm/cpu/armv7/ls102xa/soc.c
> > @@ -25,7 +25,7 @@ int arch_soc_init(void)  {
> > struct ccsr_scfg *scfg = (struct ccsr_scfg
> *)CONFIG_SYS_FSL_SCFG_ADDR;
> > struct ccsr_cci400 *cci = (struct ccsr_cci400
> *)CONFIG_SYS_CCI400_ADDR;
> > -   unsigned int major;
> > +   unsigned int major, reg;
> >
> >  #ifdef CONFIG_FSL_QSPI
> > out_be32(>qspi_cfg, SCFG_QSPI_CLKSEL); @@ -86,5 +86,16 @@
> int
> > arch_soc_init(void)
> >  */
> > out_be32(>eddrtqcfg, 0x63b20002);
> >
> > +   /*
> > +* EDDRTQCFG Registers are Integration Strap values which controls
> > +* performance parameters for DDR Controller.
> > +* The bit 25 is used for disable priorities within DDR.
> > +* This is a workaround because of the DDR are connected backwards
> > +* on Rev2.0.
> > +*/
> 
> Is there an erratum number for this? If not, please be specific about rev 2.0.
> Is it SoC version, or something else?
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD boot

2015-10-20 Thread Yao Yuan 
Hi york,

I have tested the patch on Rev1.0.

It seems there is no effect for Rev1.0.
Just the ID EEPROM can't work and will print some error info for I2C1.
There isn't any effect for others.
Is it acceptable?

Best Regards,
Yuan Yao

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Monday, October 19, 2015 11:02 PM
> To: si...@writeme.com; Yuan Yao-B46683 <yao.y...@freescale.com>; Wang
> Huan-B18965 <alison.w...@freescale.com>
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD
> boot
> 
> 
> 
> On 10/19/2015 04:14 AM, Sinan Akman wrote:
> >
> >Hi Yuan
> >
> > On 19/10/15 05:21 AM, Yao Yuan wrote:
> >> Hi Sinan Akman,
> >>
> >> Yes, I mean the Rev 1.0 silicon.
> >> Sorry, I can't guarantee that there aren't any boards with Rev1.0 silicon 
> >> are
> in user's hands.
> >> Because we have also delivery very little board with Rev1.0 silicon to
> customer  or developer for developing, assessing and verifying in the early
> stages.
> >
> >Thanks for the follow up on this, but I don't think that there were
> > only very few rev1.0 boards delivered. These were the boards bought
> > from distributor and during the time span of many weeks.
> >
> >I don't know the details and the impact of this patch exactly but
> > if the patch will break any rev1.0 board I don't think this would be
> > acceptable. There are definitely enough number of rev1.0 boards made
> > generally available (not specifically for early adapters etc) that we
> > should not break u-boot running on them.
> >
> >> Also we haven't support Rev1.0 in our SDK now.
> >
> >Sorry, but this is a bit irrelevant here. I'd expect u-boot
> > mainline does not necessarily follow what your SDK stops supporting.
> > If u-boot supported rev1.0 boards and if there are still many of
> >   them out there I see no reason to break this.
> >
> 
> Yuan,
> 
> Please test the patch on rev 1.0 SoC and make changes if needed. This feature
> has been disabled for rev 1.0.
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD boot

2015-10-19 Thread Yao Yuan 
Hi Sinan Akman,

Yes, I mean the Rev 1.0 silicon.
Sorry, I can't guarantee that there aren't any boards with Rev1.0 silicon are 
in user's hands.  
Because we have also delivery very little board with Rev1.0 silicon to  
customer  or developer for developing, assessing and verifying in the early 
stages. 
Also we haven't support Rev1.0 in our SDK now.

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: Sinan Akman [mailto:si...@writeme.com]
> Sent: Friday, October 16, 2015 3:37 AM
> To: Sun York-R58495 ; Yuan Yao-B46683
> ; Wang Huan-B18965 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD
> boot
> 
> 
>Hi Yuan
> 
> On 15/10/15 12:40 PM, York Sun wrote:
> >
> >
> > On 10/15/2015 12:55 AM, Yuan Yao-B46683 wrote:
> >> Hi york,
> >>
> >> The earlier SoC is just LS1021a rev1.0, but rev1.0 haven't delivery to the
> customer.
> >> Also the rev1.0 has since gone out of production.
> >> So we don't have necessary to support rev1.0 because no one will or
> possibly to use rev1.0.
> 
>Just to make this clear, the boards we bought all show :
> 
> CPU:   Freescale LayerScape LS1021E, Version: 1.0, (0x87081110)
> 
>When you mention "rev1.0 haven't delivery to the customer" are you not
> referring to Rev 1.0 silicon ?
> 
>Regards
>Sinan Akman
> 
> >>
> >
> > OK.
> >
> > York
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD boot

2015-10-15 Thread Yao Yuan 
Hi york,

The earlier SoC is just LS1021a rev1.0, but rev1.0 haven't delivery to the 
customer.
Also the rev1.0 has since gone out of production.
So we don't have necessary to support rev1.0 because no one will or possibly to 
use rev1.0.

Best Regards,
Yuan Yao

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Thursday, October 15, 2015 5:22 AM
> To: Yuan Yao-B46683 ; Wang Huan-B18965
> 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD boot
> 
> On 09/23/2015 12:48 AM, Yuan Yao wrote:
> > I2C1 can work on ls102xa rev2.0 SD boot, so add ID EEPROM for SD boot.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  include/configs/ls1021atwr.h | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/include/configs/ls1021atwr.h
> > b/include/configs/ls1021atwr.h index 7dcb719..59e704e 100644
> > --- a/include/configs/ls1021atwr.h
> > +++ b/include/configs/ls1021atwr.h
> > @@ -278,7 +278,6 @@
> >  #define CONFIG_SYS_I2C_MXC_I2C3/* enable I2C bus 3 */
> >
> >  /* EEPROM */
> > -#ifndef CONFIG_SD_BOOT
> >  #define CONFIG_ID_EEPROM
> >  #define CONFIG_SYS_I2C_EEPROM_NXID
> >  #define CONFIG_SYS_EEPROM_BUS_NUM  1
> > @@ -286,7 +285,6 @@
> >  #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
> >  #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  3
> >  #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
> > -#endif
> >
> >  /*
> >   * MMC
> >
> 
> What would happen if you run the new u-boot image on earlier SoC? Do you
> need to check SVR in function mac_read_from_eeprom()?
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] armv7/fsl-ls102xa: Workaround for DDR erratum A008514

2015-08-17 Thread Yao Yuan 
Hi Sinan,

Thanks for your review.
Please see my comments.

Best Regards,
Yuan Yao

 -Original Message-
 From: Sinan Akman [mailto:si...@writeme.com]
 Sent: Saturday, August 15, 2015 12:28 AM
 To: Yuan Yao-B46683; Sun York-R58495; Wang Huan-B18965
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH 1/3] armv7/fsl-ls102xa: Workaround for DDR
 erratum A008514
 
 
Hi Yuan
 
 On 14/08/15 02:54 AM, Yuan Yao wrote:
  Affects: DDR
  Description: Memory controller performance is not optimal with default
  internal target queue register values.
  Impact: Memory controller performance is not optimal.
  Workaround: Write a value of 63b2_0002h to address: 157_020Ch.
 
  Signed-off-by: Yuan Yao yao.y...@freescale.com
  ---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h |  2 +-
board/freescale/ls1021aqds/ls1021aqds.c   | 10 ++
board/freescale/ls1021atwr/ls1021atwr.c   | 10 ++
3 files changed, 21 insertions(+), 1 deletion(-)
 
  diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
  b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
  index d34044a..21bd65b 100644
  --- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
  +++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
  @@ -221,7 +221,7 @@ struct ccsr_scfg {
  u32 scfgrevcr;
  u32 coresrencr;
  u32 pex2pmrdsr;
  -   u32 ddrc1cr;
  +   u32 eddrtqcfg;
 
Is this a simple name change on the register, that ddrc1cr is not 
 needed/used
 anywhere else ?

[Yuan Yao] 
Yes, there is no ddrc1cr in ls102xa, the register on 0x157020c is named 
eddrtqcfg.

  u32 ddrc2cr;
  u32 ddrc3cr;
  u32 ddrc4cr;
  diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
  b/board/freescale/ls1021aqds/ls1021aqds.c
  index d6ef6ba..52bffc8 100644
  --- a/board/freescale/ls1021aqds/ls1021aqds.c
  +++ b/board/freescale/ls1021aqds/ls1021aqds.c
  @@ -299,6 +299,16 @@ int board_early_init_f(void)
  out_be32(scfg-endiancr, SCFG_ENDIANCR_LE);
 
  /*
  +* Memory controller require a register write before being enabled.
  +* Affects: DDR
  +* Register: EDDRTQCFG
  +* Description: Memory controller performance is not optimal with
  +*  default internal target queue register values.
  +* Workaround: Write a value of 63b2_0002h to address: 157_020Ch.
  +*/
  +   out_be32(scfg-eddrtqcfg, 0x63b20002);
 
Can you perhaps bring the comment from your 2/3 patch that explains
 EDDRTQCFG Registers are so that the reader sees it before its first usage.
 
Also, is it possible to explain here what that magic value 0x63b20002
 corresponds to and perhaps use a #define that explains its function ?

[Yuan Yao] 
Sorry for here, I also don't sure what's the means of the magic value about 
0x63b20002.
Also I'm not suggest to use the #define. Because the 0x63b20002 is just a 
silicon erratum workaround.
I just get the information for the document for silicon erratum. There is no 
more information for software.
The register eddrtqcfg is a reserve register for software. It should not open 
for developer as silicon team said.

  +
  +   /*
   * Enable snoop requests and DVM message requests for
   * Slave insterface S4 (A7 core cluster)
   */
  diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
  b/board/freescale/ls1021atwr/ls1021atwr.c
  index b7458a9..c565e91 100644
  --- a/board/freescale/ls1021atwr/ls1021atwr.c
  +++ b/board/freescale/ls1021atwr/ls1021atwr.c
  @@ -501,6 +501,16 @@ int board_early_init_f(void)
  out_be32(scfg-endiancr, SCFG_ENDIANCR_LE);
 
  /*
  +* Memory controller require a register write before being enabled.
  +* Affects: DDR
  +* Register: EDDRTQCFG
  +* Description: Memory controller performance is not optimal with
  +*  default internal target queue register values.
  +* Workaround: Write a value of 63b2_0002h to address: 157_020Ch.
  +*/
  +   out_be32(scfg-eddrtqcfg, 0x63b20002);
 
Same here.

[Yuan Yao] 
The same here.

  +
  +   /*
   * Enable snoop requests and DVM message requests for
   * Slave insterface S4 (A7 core cluster)
   */
 
 
Regards
Sinan Akman
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot