Re: [U-Boot] [Patch v2 7/7] armv8: ls1046ardb: Add LS1046ARDB board support

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Thursday, September 01, 2016 5:43 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Mingkai Hu
> <mingkai...@nxp.com>; Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou
> <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>; Shengzhou Liu
> <shengzhou@nxp.com>
> Subject: Re: [Patch v2 7/7] armv8: ls1046ardb: Add LS1046ARDB board support
> 
> On 08/31/2016 03:17 AM, Gong Qianyu wrote:
> > From: Mingkai Hu <mingkai...@nxp.com>
> >
> > LS1046ARDB Specification:
> > -
> > Memory subsystem:
> >  * 8GByte DDR4 SDRAM (64bit bus)
> >  * 512 Mbyte NAND flash
> >  * Two 64 Mbyte high-speed SPI flash
> >  * SD connector to interface with the SD memory card
> >  * On-board 4G eMMC
> >
> > Ethernet:
> >  * Two XFI 10G ports
> >  * Two SGMII ports
> >  * Two RGMII ports
> >
> > PCIe:
> >  * PCIe1 (SerDes2 Lane0) to miniPCIe slot
> >  * PCIe2 (SerDes2 Lane1) to x2 PCIe slot
> >  * PCIe3 (SerDes2 Lane2) to x4 PCIe slot
> >
> > SATA:
> >  * SerDes2 Lane3 to SATA port
> >
> > USB 3.0: one super speed USB 3.0 type A port
> >  one Micro-AB port
> >
> > UART: supports two UARTs up to 115200 bps for console
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > Signed-off-by: Mingkai Hu <mingkai...@nxp.com>
> > ---
> > v2:
> >  - Add >60 characters' paragraph for the board help.
> >  - Fix the memory map in readme.
> >  - Remove unused flash r/w functions.
> >  - Remove DDR3 defines.
> >
> >  arch/arm/Kconfig   |  12 ++
> >  arch/arm/dts/Makefile  |   1 +
> >  arch/arm/dts/fsl-ls1046a-rdb.dts   |  44 
> >  arch/arm/dts/fsl-ls1046a.dtsi  | 220 
> > +++
> >  board/freescale/ls1046ardb/Kconfig |  16 ++
> >  board/freescale/ls1046ardb/MAINTAINERS |   8 +
> >  board/freescale/ls1046ardb/Makefile|  10 +
> >  board/freescale/ls1046ardb/README  |  77 +++
> >  board/freescale/ls1046ardb/cpld.c  | 158 ++
> >  board/freescale/ls1046ardb/cpld.h  |  49 +
> >  board/freescale/ls1046ardb/ddr.c   | 140 
> >  board/freescale/ls1046ardb/ddr.h   |  44 
> >  board/freescale/ls1046ardb/eth.c   |  77 +++
> >  board/freescale/ls1046ardb/ls1046ardb.c| 136 
> >  board/freescale/ls1046ardb/ls1046ardb_pbi.cfg  |  22 ++
> >  board/freescale/ls1046ardb/ls1046ardb_rcw_emmc.cfg |   7 +
> >  board/freescale/ls1046ardb/ls1046ardb_rcw_sd.cfg   |   7 +
> >  .../ls1046ardb/ls1046ardb_rcw_sd_1200.cfg  |   7 +
> >  .../ls1046ardb/ls1046ardb_rcw_sd_1400.cfg  |   7 +
> >  .../ls1046ardb/ls1046ardb_rcw_sd_5506.cfg  |   7 +
> 
> How are these rcw files used? I don't see any description in README.
> 

No need to use them now. I'll remove them.

> 
> 
> > diff --git a/board/freescale/ls1046ardb/README
> > b/board/freescale/ls1046ardb/README
> > new file mode 100644
> > index 000..8db0cef
> > --- /dev/null
> > +++ b/board/freescale/ls1046ardb/README
> > @@ -0,0 +1,77 @@
> > +Overview
> > +
> > +The LS1046A Reference Design Board (RDB) is a high-performance
> > +computing, evaluation, and development platform that supports the
> > +QorIQ LS1046A LayerScape Architecture processor. The LS1046ARDB
> > +provides SW development platform for the Freescale LS1046A processor
> > +series, with a complete debugging environment. The LS1046A RDB is lead-free
> and RoHS-compliant.
> > +
> > +LS1046A SoC Overview
> > +
> > +Please refer arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc for
> > +LS1046A SoC overview.
> > +
> > + LS1046ARDB board Overview
> > + ---
> > + - SERDES1 Connections, 4 lanes supporting:
> > +  - Lane0: XFI with x1 RJ45 connector
> > +  - Lane1: XFI Cage
> > +  - Lane2: SGMII.5
> > +  - Lane3: SGMII.6
> > + - SERDES2 Connections, 4 lanes supporting:
> > +  - Lane0: PCIe1 with miniPCIe slot
> > +  - Lane1: PCIe2 with PCIe x2 slot
> > +  - Lane2: PCIe3 with PCIe x4 slot
> > +  - Lane3: SATA
> > + - DDR Controller
> > + - 8GB 64bits DDR4 SDRAM. Support rates of up to 2133MT/s
> > + -IFC/Local Bus
> > +- One 512 MB NAND flash with ECC support
> 
> How is NAND used? I don't see boot from NAND. Is it supported?
> 
> York

Yes. NAND is supported on LS1046ARDB while NAND boot is not.

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

Re: [U-Boot] [PATCH 8/8] armv8: ls1046ardb: Add LS1046ARDB board support

[Qianyu Gong]

Hi Prabhakar,

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Saturday, August 27, 2016 10:21 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; york sun
> <york@nxp.com>
> Cc: Mingkai Hu <mingkai...@nxp.com>; Shaohui Xie <shaohui@nxp.com>;
> Zhiqiang Hou <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>;
> Mingkai Hu <mingkai...@nxp.com>; Qianyu Gong <qianyu.g...@nxp.com>
> Subject: RE: [PATCH 8/8] armv8: ls1046ardb: Add LS1046ARDB board support
> 
> > -Original Message-
> > From: Gong Qianyu [mailto:qianyu.g...@nxp.com]
> > Sent: Friday, August 26, 2016 6:29 AM
> > To: u-boot@lists.denx.de; york sun <york@nxp.com>
> > Cc: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Mingkai Hu
> > <mingkai...@nxp.com>; Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou
> > <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>; Mingkai Hu
> > <mingkai...@nxp.com>; Qianyu Gong <qianyu.g...@nxp.com>
> > Subject: [PATCH 8/8] armv8: ls1046ardb: Add LS1046ARDB board support
> >
> > From: Mingkai Hu <mingkai...@nxp.com>
> >
> > LS1046ARDB Specification:
> > -
> > Memory subsystem:
> >  * 8GByte DDR4 SDRAM (64bit bus)
> >  * 512 Mbyte NAND flash
> >  * Two 64 Mbyte high-speed SPI flash
> >  * SD connector to interface with the SD memory card
> >  * On-board 4G eMMC
> >
> > Ethernet:
> >  * Two XFI 10G ports
> >  * Two SGMII ports
> >  * Two RGMII ports
> >
> > PCIe:
> >  * PCIe1 (SerDes2 Lane0) to miniPCIe slot
> >  * PCIe2 (SerDes2 Lane1) to x2 PCIe slot
> >  * PCIe3 (SerDes2 Lane2) to x4 PCIe slot
> >
> > SATA:
> >  * SerDes2 Lane3 to SATA port
> >
> > USB 3.0: one super speed USB 3.0 type A port
> >  one Micro-AB port
> >
> > UART: supports two UARTs up to 115200 bps for console
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > Signed-off-by: Mingkai Hu <mingkai...@nxp.com>
> > ---
> >  arch/arm/Kconfig   |   9 +
> >  arch/arm/dts/Makefile  |   1 +
> >  arch/arm/dts/fsl-ls1046a-rdb.dts   |  44 
> >  arch/arm/dts/fsl-ls1046a.dtsi  | 220 
> > +++
> >  board/freescale/ls1046ardb/Kconfig |  16 ++
> >  board/freescale/ls1046ardb/MAINTAINERS |   8 +
> >  board/freescale/ls1046ardb/Makefile|  10 +
> >  board/freescale/ls1046ardb/README  |  67 ++
> >  board/freescale/ls1046ardb/cpld.c  | 158 ++
> >  board/freescale/ls1046ardb/cpld.h  |  49 +
> >  board/freescale/ls1046ardb/ddr.c   | 140 
> >  board/freescale/ls1046ardb/ddr.h   |  44 
> >  board/freescale/ls1046ardb/eth.c   |  77 +++
> >  board/freescale/ls1046ardb/ls1046ardb.c| 173 +++
> >  board/freescale/ls1046ardb/ls1046ardb_pbi.cfg  |  22 ++
> >  board/freescale/ls1046ardb/ls1046ardb_rcw_emmc.cfg |   7 +
> >  board/freescale/ls1046ardb/ls1046ardb_rcw_sd.cfg   |   7 +
> >  .../ls1046ardb/ls1046ardb_rcw_sd_1200.cfg  |   7 +
> >  .../ls1046ardb/ls1046ardb_rcw_sd_1400.cfg  |   7 +
> >  .../ls1046ardb/ls1046ardb_rcw_sd_5506.cfg  |   7 +
> >  configs/ls1046ardb_qspi_defconfig  |  25 +++
> >  configs/ls1046ardb_sdcard_defconfig|  26 +++
> >  include/configs/ls1046a_common.h   | 181 
> >  include/configs/ls1046ardb.h   | 237 
> > +
> >  24 files changed, 1542 insertions(+)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index aef901c..d343995 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -811,6 +811,14 @@ config TARGET_LS1043ARDB
> > help
> >   Support for Freescale LS1043ARDB platform.
> >
> > +config TARGET_LS1046ARDB
> > +   bool "Support ls1046ardb"
> > +   select ARM64
> > +   select ARMV8_MULTIENTRY
> > +   select SUPPORT_SPL
> > +   help
> > + Support for Freescale LS1046ARDB platform.
> > +
> 
> Have you run checkpatch.
> I guess we get warning if help is  < 60 characters.
> 

Will fix in v2.

> >  config TARGET_H2200
> > bool "Support h2200"
> > select CPU_PXA
> > @@ -95

Re: [U-Boot] [PATCH 1/2] net: fm: fix spi flash probe for using driver model

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Wednesday, August 03, 2016 12:08 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; 'Jagan Teki'
> <jagannadh.t...@gmail.com>
> Cc: u-boot@lists.denx.de; Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>;
> Zhiqiang Hou <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>;
> Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [PATCH 1/2] net: fm: fix spi flash probe for using 
> driver
> model
> 
> On 07/29/2016 04:00 AM, Qianyu Gong wrote:
> > Hi Jagan,
> >
> > Thanks. I'll fix it in the next version.
> >
> 
> Qianyu,
> 
> Is there anything you need to fix?
> 
> York

Yes. I just sent the v2 patch.
And I also dropped the [PATCH 2/2]. I think I should first move the related SPI 
macros to 
defconfig before removing those env defines.


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

Re: [U-Boot] [PATCH 1/2] net: fm: fix spi flash probe for using driver model

[Qianyu Gong]

Hi Jagan,

Thanks. I'll fix it in the next version.

Regards,
Qianyu

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Thursday, July 28, 2016 9:36 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>
> Cc: york sun <york@nxp.com>; u-boot@lists.denx.de; Prabhakar Kushwaha
> <prabhakar.kushw...@nxp.com>; Zhiqiang Hou <zhiqiang@nxp.com>;
> Wenbin Song <wenbin.s...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [PATCH 1/2] net: fm: fix spi flash probe for using 
> driver
> model
> 
> On 28 July 2016 at 08:06, Qianyu Gong <qianyu.g...@nxp.com> wrote:
> >
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Thursday, July 28, 2016 1:35 AM
> >> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de;
> >> Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Mingkai Hu
> >> <mingkai...@nxp.com>
> >> Cc: Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou
> >> <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>
> >> Subject: Re: [PATCH 1/2] net: fm: fix spi flash probe for using
> >> driver model
> >>
> >> On 07/20/2016 03:51 AM, Gong Qianyu wrote:
> >> > The current code would always use the speed and mode set by
> >> > CONFIG_ENV_SPI_MAX_HZ and CONFIG_ENV_SPI_MODE. But if using SPI
> >> > driver model it should get the values from DT.
> >> >
> >> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> >> > ---
> >> >  drivers/net/fm/fm.c | 10 ++
> >> >  1 file changed, 10 insertions(+)
> >> >
> >> > diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c index
> >> > 00cdfd4..6308d22 100644
> >> > --- a/drivers/net/fm/fm.c
> >> > +++ b/drivers/net/fm/fm.c
> >> > @@ -371,8 +371,18 @@ int fm_init_common(int index, struct ccsr_fman
> *reg)
> >> > void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
> >> > int ret = 0;
> >> >
> >> > +#ifdef CONFIG_DM_SPI_FLASH
> >> > +   struct udevice *new;
> >> > +
> >> > +   /* Will get the speed and mode from Device Tree */
> 
> Below one look good phrase for me.
> /* speed and mode will be read from DT */
> 
> >> > +   ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
> >> CONFIG_ENV_SPI_CS,
> >> > +0, 0, );
> >> > +
> >> > +   ucode_flash = dev_get_uclass_priv(new); #else
> >> > ucode_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> >> CONFIG_ENV_SPI_CS,
> >> > CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
> >> > +#endif
> >> > if (!ucode_flash)
> >> > printf("SF: probe for ucode failed\n");
> >> > else {
> >> >
> >>
> >> Why not just use spi_flash_probe() with speed and mode passed as 0?
> >>
> >> York
> >
> > As Simon said spi_flash_probe() "is an old-style function and would be
> > removed when all SPI flash drivers use dm", so I think for dm
> > spi_flash_probe_bus_cs() should be used.
> 
> Correct!
> 
> Reviewed-by: Jagan Teki <jt...@openedev.com>
> 
> --
> Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if using driver model

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Wednesday, July 27, 2016 10:55 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; Simon Glass
> <s...@chromium.org>
> Cc: Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou <zhiqiang@nxp.com>;
> Wenbin Song <wenbin.s...@nxp.com>; Yao Yuan <yao.y...@nxp.com>; Mingkai
> Hu <mingkai...@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushw...@nxp.com>
> Subject: Re: [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if using 
> driver
> model
> 
> On 07/27/2016 03:00 AM, Qianyu Gong wrote:
> >
> > Hi York,
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Tuesday, July 26, 2016 12:26 PM
> >> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de;
> >> Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Mingkai Hu
> >> <mingkai...@nxp.com>
> >> Cc: Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou
> >> <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>
> >> Subject: Re: [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if
> >> using driver model
> >>
> >> On 07/25/2016 09:05 PM, Qianyu Gong wrote:
> >>> Hi York,
> >>>
> >>>
> >>> As the drivel model is a trend anyway, I just doubt if it is
> >>> necessary to support non-DM for the new platforms.
> >>>
> >>> In fact, we have discarded configurations for non-DM SPI such as SPI
> >>> mode related macros
> >>>
> >>> when doing LS1043A upstream. So the current configuration of LS1043A
> >>> doesn't support non-DM SPI.
> >>>
> >>>
> >>> LS1012A supports both ways but the code doesn't differentiate the
> >>> respective macros.
> >>>
> >>> The CONFIG_ENV_SPI_* are set for FMAN ucode at the beginning but I
> >>> just find that LS1012A doesn't have FMAN. So it's dead code if using
> >>> DM or just duplicated code that is the same with defines in
> >>> common/env_sf.c if using non-DM.
> >>
> >> Qianyu,
> >>
> >> If DM_SPI_FLASH should always be set, please select it from Kconfig.
> >>
> >> York
> >>
> >>
> >
> > For LS1043A, DM_SPI_FLASH is still defined in
> include/configs/ls1043a_common.h.
> > So I think it won't be affected by menuconfig. But it should have been 
> > moved to
> defconfig.
> >
> > As DM_SPI_FLASH doesn't depend on any platforms as per
> > "drivers/mtd/spi/Kconfig", I can just focus on solving the issue
> > caused by deselecting DM_SPI_FLASH. I also discussed with Yuan Yao.
> >
> > So how about I adding anything in Fman Kconfig like this?
> > "
> > config SYS_QE_FW_IN_SPIFLASH
> > depends on (FSL_LAYERSCAPE && DM_SPI_FLASH) || PPC "
> > But as for the existing code, it may need more efforts.
> >
> 
> I think you can add "select" for the platforms which always use DM_SPI_FLASH, 
> for
> example TARGET_LS1043AQDS.
> 
> Simon,
> 
> Please comment if this is a good practice.
> 
> York
> 

If one doesn't select DSPI/QSPI on LS1043A boards, there would be no need to 
select DM_SPI_FLASH. So to some extent it's not always used, correct? 

Regards,
Qianyu

> >
> > Regards,
> > Qianyu
> >
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Qianyu
> >>>
> >>> 
> >>> --
> >>> --
> >>> *From:* york sun
> >>> *Sent:* Tuesday, July 26, 2016 6:15:14 AM
> >>> *To:* Qianyu Gong; u-boot@lists.denx.de; Prabhakar Kushwaha; Mingkai
> >>> Hu
> >>> *Cc:* Shaohui Xie; Zhiqiang Hou; Wenbin Song
> >>> *Subject:* Re: [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_*
> >>> if using driver model
> >>>
> >>> On 07/20/2016 03:51 AM, Gong Qianyu wrote:
> >>>> When using SPI driver model, it will get the values from DT. So
> >>>> there is no need to set CONFIG_ENV_SPI_MAX_HZ and
> >>>> CONFIG_ENV_SPI_MODE any more.
> >>>>
> >>>
> >>> You indicate these macros are not needed _if_ using driver model.
> >>> You presume the driver model is always used. You have
> >>> CONFIG_DM_SPI_FLASH in defconfig, but you don't have it selected in
> >>>

Re: [U-Boot] [PATCH 1/2] net: fm: fix spi flash probe for using driver model

[Qianyu Gong]

> -Original Message-
> From: york sun
> Sent: Thursday, July 28, 2016 1:35 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; Prabhakar
> Kushwaha <prabhakar.kushw...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> Cc: Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou <zhiqiang@nxp.com>;
> Wenbin Song <wenbin.s...@nxp.com>
> Subject: Re: [PATCH 1/2] net: fm: fix spi flash probe for using driver model
> 
> On 07/20/2016 03:51 AM, Gong Qianyu wrote:
> > The current code would always use the speed and mode set by
> > CONFIG_ENV_SPI_MAX_HZ and CONFIG_ENV_SPI_MODE. But if using SPI driver
> > model it should get the values from DT.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > ---
> >  drivers/net/fm/fm.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c index
> > 00cdfd4..6308d22 100644
> > --- a/drivers/net/fm/fm.c
> > +++ b/drivers/net/fm/fm.c
> > @@ -371,8 +371,18 @@ int fm_init_common(int index, struct ccsr_fman *reg)
> > void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
> > int ret = 0;
> >
> > +#ifdef CONFIG_DM_SPI_FLASH
> > +   struct udevice *new;
> > +
> > +   /* Will get the speed and mode from Device Tree */
> > +   ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
> CONFIG_ENV_SPI_CS,
> > +0, 0, );
> > +
> > +   ucode_flash = dev_get_uclass_priv(new); #else
> > ucode_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> CONFIG_ENV_SPI_CS,
> > CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
> > +#endif
> > if (!ucode_flash)
> > printf("SF: probe for ucode failed\n");
> > else {
> >
> 
> Why not just use spi_flash_probe() with speed and mode passed as 0?
> 
> York

As Simon said spi_flash_probe() "is an old-style function and would be removed
when all SPI flash drivers use dm", so I think for dm spi_flash_probe_bus_cs()
should be used.


Regards,
Qianyu


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

Re: [U-Boot] [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if using driver model

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Tuesday, July 26, 2016 12:26 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; Prabhakar
> Kushwaha <prabhakar.kushw...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> Cc: Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou <zhiqiang@nxp.com>;
> Wenbin Song <wenbin.s...@nxp.com>
> Subject: Re: [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if using 
> driver
> model
> 
> On 07/25/2016 09:05 PM, Qianyu Gong wrote:
> > Hi York,
> >
> >
> > As the drivel model is a trend anyway, I just doubt if it is necessary
> > to support non-DM for the new platforms.
> >
> > In fact, we have discarded configurations for non-DM SPI such as SPI
> > mode related macros
> >
> > when doing LS1043A upstream. So the current configuration of LS1043A
> > doesn't support non-DM SPI.
> >
> >
> > LS1012A supports both ways but the code doesn't differentiate the
> > respective macros.
> >
> > The CONFIG_ENV_SPI_* are set for FMAN ucode at the beginning but I
> > just find that LS1012A doesn't have FMAN. So it's dead code if using
> > DM or just duplicated code that is the same with defines in
> > common/env_sf.c if using non-DM.
> 
> Qianyu,
> 
> If DM_SPI_FLASH should always be set, please select it from Kconfig.
> 
> York
> 
> 

For LS1043A, DM_SPI_FLASH is still defined in include/configs/ls1043a_common.h.
So I think it won't be affected by menuconfig. But it should have been moved to 
defconfig.

As DM_SPI_FLASH doesn't depend on any platforms as per 
"drivers/mtd/spi/Kconfig", 
I can just focus on solving the issue caused by deselecting DM_SPI_FLASH. I 
also discussed
with Yuan Yao. 

So how about I adding anything in Fman Kconfig like this?
"
config SYS_QE_FW_IN_SPIFLASH
depends on (FSL_LAYERSCAPE && DM_SPI_FLASH) || PPC
" 
But as for the existing code, it may need more efforts.


Regards,
Qianyu

> >
> >
> >
> > Regards,
> >
> > Qianyu
> >
> > --
> > --
> > *From:* york sun
> > *Sent:* Tuesday, July 26, 2016 6:15:14 AM
> > *To:* Qianyu Gong; u-boot@lists.denx.de; Prabhakar Kushwaha; Mingkai
> > Hu
> > *Cc:* Shaohui Xie; Zhiqiang Hou; Wenbin Song
> > *Subject:* Re: [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if
> > using driver model
> >
> > On 07/20/2016 03:51 AM, Gong Qianyu wrote:
> >> When using SPI driver model, it will get the values from DT. So there
> >> is no need to set CONFIG_ENV_SPI_MAX_HZ and CONFIG_ENV_SPI_MODE any
> >> more.
> >>
> >
> > You indicate these macros are not needed _if_ using driver model. You
> > presume the driver model is always used. You have CONFIG_DM_SPI_FLASH
> > in defconfig, but you don't have it selected in Kconfig for those
> > platforms. This can leave a possible configuration if one runs "make
> > menuconfig" and deselect DM_SPI_FLASH.
> >
> > York
> >
> >
> >> Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> >> ---
> >>  include/configs/ls1012a_common.h | 2 --
> >> include/configs/ls1043a_common.h | 2 --
> >>  2 files changed, 4 deletions(-)
> >>
> >> diff --git a/include/configs/ls1012a_common.h
> >> b/include/configs/ls1012a_common.h
> >> index fba2fac..1602f09 100644
> >> --- a/include/configs/ls1012a_common.h
> >> +++ b/include/configs/ls1012a_common.h
> >> @@ -52,8 +52,6 @@
> >>  #define CONFIG_SYS_FMAN_FW_ADDR  0x400d
> >>  #define CONFIG_ENV_SPI_BUS   0
> >>  #define CONFIG_ENV_SPI_CS0
> >> -#define CONFIG_ENV_SPI_MAX_HZ100
> >> -#define CONFIG_ENV_SPI_MODE  0x03
> >>  #define CONFIG_SPI_FLASH_SPANSION
> >>  #define CONFIG_FSL_SPI_INTERFACE
> >>  #define CONFIG_SF_DATAFLASH
> >> diff --git a/include/configs/ls1043a_common.h
> >> b/include/configs/ls1043a_common.h
> >> index b0d4a8d..028f7d9 100644
> >> --- a/include/configs/ls1043a_common.h
> >> +++ b/include/configs/ls1043a_common.h
> >> @@ -222,8 +222,6 @@
> >>  #define CONFIG_SYS_FMAN_FW_ADDR  0x400d
> >>  #define CONFIG_ENV_SPI_BUS   0
> >>  #define CONFIG_ENV_SPI_CS0
> >> -#define CONFIG_ENV_SPI_MAX_HZ100
> >> -#define CONFIG_ENV_SPI_MODE  0x03
> >>  #else
> >>  #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
> >>  /* FMan fireware Pre-load address */
> >>
> >

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

Re: [U-Boot] [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if using driver model

[Qianyu Gong]

Hi York,

As the drivel model is a trend anyway, I just doubt if it is necessary to 
support non-DM for the new platforms.


In fact, we have discarded configurations for non-DM SPI such as SPI mode 
related macros

when doing LS1043A upstream. So the current configuration of LS1043A doesn't 
support non-DM SPI.


LS1012A supports both ways but the code doesn't differentiate the respective 
macros.

The CONFIG_ENV_SPI_* are set for FMAN ucode at the beginning but I just find 
that LS1012A doesn't have FMAN. So it's dead code if using DM or just 
duplicated code that is the same with defines in common/env_sf.c if using 
non-DM.



Regards,

Qianyu


From: york sun
Sent: Tuesday, July 26, 2016 6:15:14 AM
To: Qianyu Gong; u-boot@lists.denx.de; Prabhakar Kushwaha; Mingkai Hu
Cc: Shaohui Xie; Zhiqiang Hou; Wenbin Song
Subject: Re: [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if using 
driver model

On 07/20/2016 03:51 AM, Gong Qianyu wrote:
> When using SPI driver model, it will get the values from DT. So
> there is no need to set CONFIG_ENV_SPI_MAX_HZ and
> CONFIG_ENV_SPI_MODE any more.
>

You indicate these macros are not needed _if_ using driver model. You
presume the driver model is always used. You have CONFIG_DM_SPI_FLASH in
defconfig, but you don't have it selected in Kconfig for those
platforms. This can leave a possible configuration if one runs "make
menuconfig" and deselect DM_SPI_FLASH.

York


> Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> ---
>  include/configs/ls1012a_common.h | 2 --
>  include/configs/ls1043a_common.h | 2 --
>  2 files changed, 4 deletions(-)
>
> diff --git a/include/configs/ls1012a_common.h 
> b/include/configs/ls1012a_common.h
> index fba2fac..1602f09 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -52,8 +52,6 @@
>  #define CONFIG_SYS_FMAN_FW_ADDR  0x400d
>  #define CONFIG_ENV_SPI_BUS   0
>  #define CONFIG_ENV_SPI_CS0
> -#define CONFIG_ENV_SPI_MAX_HZ100
> -#define CONFIG_ENV_SPI_MODE  0x03
>  #define CONFIG_SPI_FLASH_SPANSION
>  #define CONFIG_FSL_SPI_INTERFACE
>  #define CONFIG_SF_DATAFLASH
> diff --git a/include/configs/ls1043a_common.h 
> b/include/configs/ls1043a_common.h
> index b0d4a8d..028f7d9 100644
> --- a/include/configs/ls1043a_common.h
> +++ b/include/configs/ls1043a_common.h
> @@ -222,8 +222,6 @@
>  #define CONFIG_SYS_FMAN_FW_ADDR  0x400d
>  #define CONFIG_ENV_SPI_BUS   0
>  #define CONFIG_ENV_SPI_CS0
> -#define CONFIG_ENV_SPI_MAX_HZ100
> -#define CONFIG_ENV_SPI_MODE  0x03
>  #else
>  #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
>  /* FMan fireware Pre-load address */
>

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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Thursday, July 21, 2016 5:25 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; Scott Wood <o...@buserror.net>; u-
> b...@lists.denx.de
> Cc: Mingkai Hu <mingkai...@nxp.com>; Huan Wang <alison.w...@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On 07/19/2016 11:39 PM, Qianyu Gong wrote:
> > Hi York,
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Wednesday, July 20, 2016 5:58 AM
> >> To: Scott Wood <o...@buserror.net>; Qianyu Gong <qianyu.g...@nxp.com>;
> >> u- b...@lists.denx.de
> >> Cc: Mingkai Hu <mingkai...@nxp.com>
> >> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> >> with QSPI enabled
> >>
> >> On 03/30/2016 07:39 PM, Scott Wood wrote:
> >>> On Wed, 2016-03-30 at 06:20 +, Qianyu Gong wrote:
> >>
> >> 
> >>
> >>>>
> >>>> Because this muxing can't be changed at runtime.
> >>>> Two ways so far to configure it:
> >>>> 1. SW6[1-4] switches on ls1043aqds board.
> >>>> 2. Modify QIXIS board config registers and reset the board.
> >>>
> >>> These sound like runtime to me -- not compile time.
> >>>
> >>
> >> Qianyu,
> >>
> >> If one can change mux by either changing switches, or setting QIXIS
> >> registers, you should be able to read those status and run the fixup, 
> >> agree?
> >>
> >> York
> >
> > Yes, we could read QIXIS registers at runtime. But the current
> > argument is that if we need to build two rcw images to support
> > IFC or QSPI, which is already done on LS1021AQDS and LS1043AQDS. This is
> made at compile time and I just have no idea to solve the rcw issue.
> > So.. how do you think about it?
> >
> 
> Having different SPL builds is not ideal, but that's what we have.
> Without introducing another mechanism, we cannot concatenate SPL with
> different RCW files.
> 
> On the other side, if condition can be detected at run time, please do so, 
> even
> when the condition only applies to one of SPL boot method. We should reduce
> compile option as much as we can so we have less options to test.
> 
> York

OK, thanks. I'll have a try. 
Since the muxing is board-specific, I'd also like to move it to 
ft_board_setup().


Regards,
Qianyu

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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Wednesday, July 20, 2016 5:58 AM
> To: Scott Wood <o...@buserror.net>; Qianyu Gong <qianyu.g...@nxp.com>; u-
> b...@lists.denx.de
> Cc: Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On 03/30/2016 07:39 PM, Scott Wood wrote:
> > On Wed, 2016-03-30 at 06:20 +, Qianyu Gong wrote:
> 
> 
> 
> >>
> >> Because this muxing can't be changed at runtime.
> >> Two ways so far to configure it:
> >> 1. SW6[1-4] switches on ls1043aqds board.
> >> 2. Modify QIXIS board config registers and reset the board.
> >
> > These sound like runtime to me -- not compile time.
> >
> 
> Qianyu,
> 
> If one can change mux by either changing switches, or setting QIXIS 
> registers, you
> should be able to read those status and run the fixup, agree?
> 
> York

Yes, we could read QIXIS registers at runtime. But the current argument is that 
if we need to
build two rcw images to support IFC or QSPI, which is already done on 
LS1021AQDS
and LS1043AQDS. This is made at compile time and I just have no idea to solve 
the rcw issue.
So.. how do you think about it?


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

Re: [U-Boot] [Patch v2 3/4] armv8: fsl_lsch2: Add serdes 2 support

[Qianyu Gong]

Sorry...this should be put before the second patch.
I'll fix it in the next version.

Regards,
Qianyu

> -Original Message-
> From: Gong Qianyu [mailto:qianyu.g...@nxp.com]
> Sent: Friday, July 01, 2016 6:49 PM
> To: york sun <york@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushw...@nxp.com>; u-boot@lists.denx.de
> Cc: Mingkai Hu <mingkai...@nxp.com>; Zhiqiang Hou <zhiqiang@nxp.com>;
> Shaohui Xie <shaohui@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>;
> Qianyu Gong <qianyu.g...@nxp.com>
> Subject: [Patch v2 3/4] armv8: fsl_lsch2: Add serdes 2 support
> 
> This patch adds serdes 2 support for FSL_LSCH2.
> 
> Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> ---
> v2:
>  - New patch.
> 
>  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c  | 19
> +++  arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h |
> 1 +  .../arm/include/asm/arch-fsl-layerscape/immap_lsch2.h |  2 ++
>  3 files changed, 22 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> index fe3444a..f73092a 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> @@ -13,6 +13,9 @@
>  #ifdef CONFIG_SYS_FSL_SRDS_1
>  static u8 serdes1_prtcl_map[SERDES_PRCTL_COUNT];
>  #endif
> +#ifdef CONFIG_SYS_FSL_SRDS_2
> +static u8 serdes2_prtcl_map[SERDES_PRCTL_COUNT];
> +#endif
> 
>  int is_serdes_configured(enum srds_prtcl device)  { @@ -21,6 +24,9 @@ int
> is_serdes_configured(enum srds_prtcl device)  #ifdef CONFIG_SYS_FSL_SRDS_1
>   ret |= serdes1_prtcl_map[device];
>  #endif
> +#ifdef CONFIG_SYS_FSL_SRDS_2
> + ret |= serdes2_prtcl_map[device];
> +#endif
> 
>   return !!ret;
>  }
> @@ -38,6 +44,12 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl device)
>   cfg >>= FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_SHIFT;
>   break;
>  #endif
> +#ifdef CONFIG_SYS_FSL_SRDS_2
> + case FSL_SRDS_2:
> + cfg &= FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_MASK;
> + cfg >>= FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_SHIFT;
> + break;
> +#endif
>   default:
>   printf("invalid SerDes%d\n", sd);
>   break;
> @@ -114,4 +126,11 @@ void fsl_serdes_init(void)
>   FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_SHIFT,
>   serdes1_prtcl_map);
>  #endif
> +#ifdef CONFIG_SYS_FSL_SRDS_2
> + serdes_init(FSL_SRDS_2,
> + CONFIG_SYS_FSL_SERDES_ADDR,
> + FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_MASK,
> + FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_SHIFT,
> + serdes2_prtcl_map);
> +#endif
>  }
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
> b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
> index 606b667..e1b3f44 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
> @@ -140,6 +140,7 @@ enum srds_prtcl {
> 
>  enum srds {
>   FSL_SRDS_1  = 0,
> + FSL_SRDS_2  = 1,
>  };
> 
>  #endif
> 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 cbb252c..05f497c 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> @@ -228,6 +228,8 @@ struct ccsr_gur {
>  #define FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_MASK 0x3f
>  #define FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_MASK 0x
>  #define FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_SHIFT16
> +#define FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_MASK 0x
> +#define FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_SHIFT0
>  #define RCW_SB_EN_REG_INDEX  7
>  #define RCW_SB_EN_MASK   0x0020
> 
> --
> 2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 3/3] armv8/ls1046a: Add Fman support

[Qianyu Gong]

Hi Prabhakar,

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Thursday, June 30, 2016 6:32 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; york sun <york@nxp.com>; u-
> b...@lists.denx.de
> Cc: Zhiqiang Hou <zhiqiang@nxp.com>; Wenbin Song
> <wenbin.s...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> Subject: RE: [U-Boot] [PATCH 3/3] armv8/ls1046a: Add Fman support
> 
> 
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Gong
> > Qianyu
> > Sent: Thursday, June 30, 2016 3:31 PM
> > To: york sun <york@nxp.com>; u-boot@lists.denx.de
> > Cc: Zhiqiang Hou <zhiqiang@nxp.com>; Wenbin Song
> > <wenbin.s...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> > Subject: [U-Boot] [PATCH 3/3] armv8/ls1046a: Add Fman support
> >
> 
> Missing description.
> 
> This patch should be merged with previous patch.
> 
> --prabhakar

In fact this patch has just done modifications in driver code.
So not proper to be merged with SoC patch.
I think the title is confusing and will modify it. 

Regards,
Qianyu

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

Re: [U-Boot] [PATCH 2/3] armv8/fsl_lsch2: Add LS1046A SoC support

[Qianyu Gong]

Hi Prabhakar,

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Thursday, June 30, 2016 6:30 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; york sun <york@nxp.com>; u-
> b...@lists.denx.de
> Cc: Mihai Bantea <mihai.ban...@freescale.com>; Zhiqiang Hou
> <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>; Mingkai Hu
> <mingkai...@nxp.com>
> Subject: RE: [U-Boot] [PATCH 2/3] armv8/fsl_lsch2: Add LS1046A SoC support
> 
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Gong
> > Qianyu
> > Sent: Thursday, June 30, 2016 3:31 PM
> > To: york sun <york@nxp.com>; u-boot@lists.denx.de
> > Cc: Mihai Bantea <mihai.ban...@freescale.com>; Zhiqiang Hou
> > <zhiqiang@nxp.com>; Wenbin Song <wenbin.s...@nxp.com>; Mingkai Hu
> > <mingkai...@nxp.com>
> > Subject: [U-Boot] [PATCH 2/3] armv8/fsl_lsch2: Add LS1046A SoC support
> >
> > From: Mingkai Hu <mingkai...@nxp.com>
> >
> > The LS1046A processor is built on the QorIQ LS series architecture
> > combining four ARM A72 processor cores with DPAA 1.0 support.
> >
> 
> Please add SoC details in arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc
> 

Ok.

> > Signed-off-by: Hou Zhiqiang <zhiqiang@nxp.com>
> > Signed-off-by: Mihai Bantea <mihai.ban...@freescale.com>
> > Signed-off-by: Mingkai Hu <mingkai...@nxp.com>
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> >
> 
> Strange missing list of file modified :)
> 
> 
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > index eb2cbc3..4df467d 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > @@ -32,3 +32,7 @@ endif
> >  ifneq ($(CONFIG_LS1012A),)
> >  obj-$(CONFIG_SYS_HAS_SERDES) += ls1012a_serdes.o  endif
> > +
> > +ifneq ($(CONFIG_LS1046A),)
> > +obj-$(CONFIG_SYS_HAS_SERDES) += ls1046a_serdes.o endif
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> > index fe3444a..f73092a 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> > @@ -13,6 +13,9 @@
> >  #ifdef CONFIG_SYS_FSL_SRDS_1
> >  static u8 serdes1_prtcl_map[SERDES_PRCTL_COUNT];
> >  #endif
> > +#ifdef CONFIG_SYS_FSL_SRDS_2
> > +static u8 serdes2_prtcl_map[SERDES_PRCTL_COUNT];
> > +#endif
> >
> >  int is_serdes_configured(enum srds_prtcl device)  { @@ -21,6 +24,9 @@
> > int is_serdes_configured(enum srds_prtcl device)  #ifdef
> > CONFIG_SYS_FSL_SRDS_1
> > ret |= serdes1_prtcl_map[device];
> >  #endif
> > +#ifdef CONFIG_SYS_FSL_SRDS_2
> > +   ret |= serdes2_prtcl_map[device];
> > +#endif
> >
> > return !!ret;
> >  }
> > @@ -38,6 +44,12 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl
> > device)
> > cfg >>= FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_SHIFT;
> > break;
> >  #endif
> > +#ifdef CONFIG_SYS_FSL_SRDS_2
> > +   case FSL_SRDS_2:
> > +   cfg &= FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_MASK;
> > +   cfg >>= FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_SHIFT;
> > +   break;
> > +#endif
> > default:
> > printf("invalid SerDes%d\n", sd);
> > break;
> > @@ -114,4 +126,11 @@ void fsl_serdes_init(void)
> > FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_SHIFT,
> > serdes1_prtcl_map);
> >  #endif
> > +#ifdef CONFIG_SYS_FSL_SRDS_2
> > +   serdes_init(FSL_SRDS_2,
> > +   CONFIG_SYS_FSL_SERDES_ADDR,
> > +   FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_MASK,
> > +   FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_SHIFT,
> > +   serdes2_prtcl_map);
> > +#endif
> >  }
> 
> Ideally this should be separate patch. Like Adding support of SerDes2
> 

Ok.

> 
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
> > index d0dc58d..8922197 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
> > @@ -107,6 +107,12 @@ void get_sys_info(struct sys_info *sys_info)
> > case 3:
> > sys_info->freq_fman[0] = freq_c_pll[0] / 3;
> > break;
> 

Re: [U-Boot] [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is avaliable in U-Boot

[Qianyu Gong]

Hi York,

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Tuesday, May 17, 2016 12:47 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de;
> o...@buserror.net
> Cc: Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is 
> avaliable in U-
> Boot
> 
> On 04/27/2016 11:19 PM, Gong Qianyu wrote:
> > IFC is considered as a required component in Layerscape platforms' Linux.
> > But if IFC is not enabled in U-Boot on some boards, accessing IFC
> > memory space would cause kernel call trace. So disable IFC node in such 
> > cases.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > ---
> > V2:
> >  - Revised the title and message.
> >  - Used #ifndef CONFIG_FSL_IFC rather than #ifdef CONFIG_FSL_QSPI.
> >
> >  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index 1e875c4..96dab56 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -98,4 +98,9 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > CONFIG_SYS_DPAA_FMAN
> > fdt_fixup_fman_firmware(blob);
> >  #endif
> > +
> > +#ifndef CONFIG_FSL_IFC
> > +   do_fixup_by_compat(blob, "fsl,ifc",
> > +  "status", "disabled", 8 + 1, 1); #endif
> >  }
> >
> 
> Qianyu,
> 
> For the platforms you are testing, is IFC disabled/enabled at SoC level (eg.
> RCW) or board level (eg. FPGA)? Can you detect if IFC is enabled by checking
> registers?
> 
> York

For LS1043AQDS, IFC is disabled at board level(at SoC level, only IFC NOR is 
disabled).
Yes, I can detect if IFC is enabled by checking QIXIS registers.

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

Re: [U-Boot] [PATCH] armv8/ls1043ardb: fix the limitation of using 'cpld reset'

[Qianyu Gong]

Hi Mingkai,

> -Original Message-
> From: Mingkai Hu
> Sent: Saturday, April 30, 2016 8:26 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; york sun
> <york@nxp.com>
> Cc: Shaohui Xie <shaohui@nxp.com>; Zhiqiang Hou <zhiqiang@nxp.com>;
> Wenbin Song <wenbin.s...@nxp.com>; Qianyu Gong <qianyu.g...@nxp.com>
> Subject: RE: [PATCH] armv8/ls1043ardb: fix the limitation of using 'cpld 
> reset'
> 
> Qianyu,
> 
> The reset command is used to boot from the location set in the hardware 
> switch.
> 
> Regards,
> Mingkai
> 

Using 'reset' could be enough for that purpose, I think.
'cpld reset' and 'cpld reset altbank' are used to reset to boot from 
NOR(default or alternate bank).

Regards,
Qianyu

> > -Original Message-
> > From: Gong Qianyu [mailto:qianyu.g...@nxp.com]
> > Sent: Monday, April 25, 2016 4:39 PM
> > To: u-boot@lists.denx.de; york sun; Mingkai Hu
> > Cc: Shaohui Xie; Zhiqiang Hou; Wenbin Song; Qianyu Gong
> > Subject: [PATCH] armv8/ls1043ardb: fix the limitation of using 'cpld reset'
> >
> > The current 'cpld reset' will just write global_rst register but
> > couldn't switch to NOR boot if the board's switches are for NAND/SD
> > boot. So need to write rcw source registers for NOR boot as well.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > ---
> >  board/freescale/ls1043ardb/cpld.c | 26 --
> > board/freescale/ls1043ardb/cpld.h |  1 +
> >  2 files changed, 25 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/freescale/ls1043ardb/cpld.c
> > b/board/freescale/ls1043ardb/cpld.c
> > index 78c2824..c645283 100644
> > --- a/board/freescale/ls1043ardb/cpld.c
> > +++ b/board/freescale/ls1043ardb/cpld.c
> > @@ -28,10 +28,18 @@ void cpld_write(unsigned int reg, u8 value)
> >  /* Set the boot bank to the alternate bank */  void
> > cpld_set_altbank(void)  {
> > +   u16 reg = CPLD_CFG_RCW_SRC_NOR;
> > u8 reg4 = CPLD_READ(soft_mux_on);
> > +   u8 reg5 = (u8)(reg >> 1);
> > +   u8 reg6 = (u8)(reg & 1);
> > u8 reg7 = CPLD_READ(vbank);
> >
> > -   CPLD_WRITE(soft_mux_on, reg4 | CPLD_SW_MUX_BANK_SEL);
> > +   cpld_rev_bit();
> > +
> > +   CPLD_WRITE(soft_mux_on, reg4 | CPLD_SW_MUX_BANK_SEL | 1);
> > +
> > +   CPLD_WRITE(cfg_rcw_src1, reg5);
> > +   CPLD_WRITE(cfg_rcw_src2, reg6);
> >
> > reg7 = (reg7 & ~CPLD_BANK_SEL_MASK) | CPLD_BANK_SEL_ALTBANK;
> > CPLD_WRITE(vbank, reg7);
> > @@ -42,7 +50,21 @@ void cpld_set_altbank(void)
> >  /* Set the boot bank to the default bank */  void cpld_set_defbank(void)  {
> > -   CPLD_WRITE(global_rst, 1);
> > +   u16 reg = CPLD_CFG_RCW_SRC_NOR;
> > +   u8 reg4 = CPLD_READ(soft_mux_on);
> > +   u8 reg5 = (u8)(reg >> 1);
> > +   u8 reg6 = (u8)(reg & 1);
> > +
> > +   cpld_rev_bit();
> > +
> > +   CPLD_WRITE(soft_mux_on, reg4 | CPLD_SW_MUX_BANK_SEL | 1);
> > +
> > +   CPLD_WRITE(cfg_rcw_src1, reg5);
> > +   CPLD_WRITE(cfg_rcw_src2, reg6);
> > +
> > +   CPLD_WRITE(vbank, 0);
> > +
> > +   CPLD_WRITE(system_rst, 1);
> >  }
> >
> >  void cpld_set_nand(void)
> > diff --git a/board/freescale/ls1043ardb/cpld.h
> > b/board/freescale/ls1043ardb/cpld.h
> > index bd59c0e..cb175b5 100644
> > --- a/board/freescale/ls1043ardb/cpld.h
> > +++ b/board/freescale/ls1043ardb/cpld.h
> > @@ -40,6 +40,7 @@ void cpld_rev_bit(unsigned char *value);
> >  #define CPLD_SW_MUX_BANK_SEL   0x40
> >  #define CPLD_BANK_SEL_MASK 0x07
> >  #define CPLD_BANK_SEL_ALTBANK  0x04
> > +#define CPLD_CFG_RCW_SRC_NOR   0x025
> >  #define CPLD_CFG_RCW_SRC_NAND  0x106
> >  #define CPLD_CFG_RCW_SRC_SD0x040
> >  #endif
> > --
> > 2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT

[Qianyu Gong]

Hi Vignesh,

> -Original Message-
> From: Vignesh R [mailto:vigne...@ti.com]
> Sent: Thursday, April 21, 2016 12:30 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; jt...@openedev.com;
> tr...@konsulko.com
> Cc: u-boot@lists.denx.de; s...@denx.de; Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values
> from DT
> 
> Hi Qianyu,
> 
> [...]
> 
> >>>> @@ -308,6 +307,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int
> >>> speed, int
> >>>
> >>>> mode,
> >>>
> >>>>slave->dev = dev;
> >>>
> >>>> }
> >>>
> >>>>
> >>>
> >>>> +  plat = dev_get_parent_platdata(dev);
> >>>
> >>>> +  if (!speed) {
> >>>
> >>>> + speed = plat->max_hz;
> >>>
> >>>> + mode = plat->mode;
> >>>
> >>>> +  }
> >>>
> >>>> ret = spi_set_speed_mode(bus, speed, mode);
> >>>
> >>>> if (ret)
> >>>
> >>>>goto err;
> >>>
> >>>> --
> >>>
> >>>
> >>>
> >>> I just doubt if spi_set_speed_mode() has really made a difference to
> >>>
> >>> the actual transfer.
> >>>
> >>
> >> It does (see below)...
> >>
> >>> Seems that if the device is inactive, calling device_probe() would
> >>> also call
> >>>
> >>> spi_set_speed_mode() and do the data transfer. Even if it's active,
> >>> setting
> >>>
> >>> speed and mode for it again would not be necessary.
> >>
> >>
> >> Yes, spi_set_speed_mode() is called from
> >> spi_flash_probe_slave()->spi_claim_bus() as part of device_probe().
> >> spi_claim_bus() in spi-uclass.c speed & mode are appropriately passed 
> >> based on
> DT
> >> data to spi_set_speed_mode(). But that's not the issue.
> >>
> >> But in spi_get_bus_and_cs() (called from sf probe) there is a call to
> >> spi_set_speed_mode() after device_probe() for inactive devices. This call 
> >> is to
> >
> > Yes. Actually I'm thinking that the second spi_set_speed_mode()(called from
> > spi_get_bus_and_cs()) could just be removed from the end of the function.
> >
> 
> If second call to spi_set_speed_mode() is removed then how would you
> override default speed/mode specified via DT with that of cmd line args
> passed to sf probe. (else we need to change the definition of sf probe
> to not accept speed/mode in case of DT)
> 

OK, I see. Thanks.

> >> _override_ the speed set via DT with those passed as cmd line args of sf 
> >> probe.
> But,
> >> if no args are passed to sf probe, speed and mode default to
> >> CONFIG_SF_DEFAULT_SPEED/MODE (see do_spi_flash_probe() in
> >> cmd/sf.c) instead of using DT inputs.
> >>
> >
> > Yes. But notice that the speed and mode will only be replaced by
> > CONFIG_SF_DEFAULT_SPEED/MODE at the end of the calling. Every time 'sf
> probe' is
> > called, the device will be removed(if active) and thus it'll always call
> device_probe()
> > to set the speed from DT. Then the driver will use them in the actual
> transfer.
> 
> True, I see the first call and speed/mode is set to DT values
> accordingly. But, that's not the final spi_set_speed_mode() call to the
> SPI driver.
> 
> > After the transfer is finished, the speed and mode are replaced by
> > CONFIG_SF_DEFAULT_SPEED/MODE(or anything else) again but they wouldn't
> be used
> > for the transfer at all.
> >
> 
> Sorry... I don't understand. What do you mean by transfer? sf probe does
> not do any data transfer other than reading jedec id.
> The values set by the SPI driver during device_probe() will be
> overwritten by the last spi_set_speed_mode() call in
> spi_get_bus_and_cs() which happens to pass CONFIG_SF_DEFAULT_SPEED/MODE.
> 

Yes, I should say reading jedec id from flash.
   
> Here is the call sequence:
> 
> sf probe()
> ---> device_probe()
>   ---> spi_set_speed_mode(values from DT)
> ---> driver's pi_set_speed_mode() /* set to DT values */

Here reading jedec id is finished before calling the second 
spi_set_speed_mode().

> ---> spi_set_speed_mode(overridden values)
>   ---> d

Re: [U-Boot] A problem about 'sf probe' using DM_SPI

[Qianyu Gong]

Hi Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Wednesday, April 20, 2016 10:41 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>
> Cc: u-boot@lists.denx.de; Mingkai Hu <mingkai...@nxp.com>; Yao Yuan
> <yao.y...@nxp.com>; jt...@openedev.com
> Subject: Re: A problem about 'sf probe' using DM_SPI
> 
> Hi,
> 
> On 12 April 2016 at 21:13, Qianyu Gong <qianyu.g...@nxp.com> wrote:
> > Hi Simon,
> >
> >> -Original Message-
> >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> >> Sent: Saturday, April 09, 2016 3:13 AM
> >> To: Qianyu Gong <qianyu.g...@nxp.com>
> >> Cc: u-boot@lists.denx.de; Mingkai Hu <mingkai...@nxp.com>; Yao Yuan
> >> <yao.y...@nxp.com>; jt...@openedev.com
> >> Subject: Re: A problem about 'sf probe' using DM_SPI
> >>
> >> Hi Qianyu,
> >>
> >> On 25 March 2016 at 03:34, Qianyu Gong <qianyu.g...@nxp.com> wrote:
> >> > Hi Simon,
> >> >
> >> >
> >> >
> >> > I think I’m not very clear with this code in common/cmd_sf.c:
> >> >
> >> > “
> >> >
> >> > # ifdef CONFIG_DM_SPI_FLASH
> >> >
> >> >/* Remove the old device, otherwise probe will just be a nop
> >> > */
> >> >
> >> >ret = spi_find_bus_and_cs(bus, cs, _dev, );
> >> >
> >> >if (!ret) {
> >> >
> >> >   device_remove(new);
> >> >
> >> >  device_unbind(new);
> >> >
> >> >  }
> >> >
> >> > ”
> >> >
> >> > I may understand the remove but why need to unbind the device?
> >>
> >> This is because otherwise 'sf probe' would be a nop if the device
> >> already existed. The spi_flash_probe_bus_cs() call will simply return
> >> the existing device. If something has changed on the bus, it would be
> >> ignored.
> >>
> >> >
> >> > The unbind would cause a series of free operations on the device
> >> > list, correct?
> >>
> >> Yes
> >>
> >> >
> >> > Then if I probe a flash twice, at the second time the driver model
> >> > will create
> >> >
> >> > a new flash named ‘spi_flash@xx:xx’ using default settings because
> >> > it doesn’t
> >> >
> >> > find such a device in the device list and never probes it from the
> >> > board’s fdt again.
> >>
> >> Yes.
> >>
> >> >
> >> > => dm tree
> >> >
> >> > Class   Probed   Name
> >> >
> >> > 
> >> >
> >> > root[ + ]root_driver
> >> >
> >> > simple_bus  [ + ]`-- soc
> >> >
> >> > spi [ + ]   |-- dspi@210
> >> >
> >> > spi_flash   [   ]||-- n25q128a
> >> >
> >> > spi_flash   [ + ]|   |-- spi_flash@1:1
> >> >
> >> > spi_flash   [ + ]|   `-- spi_flash@1:2
> >> >
> >> > Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it
> >> > doesn’t cause
> >> >
> >> > issues on our boards. But if an SPI flash which only supports
> >> > SPI_MODE_0 is used,
> >> >
> >> > I think it wouldn’t work properly from the second probe.
> >> >
> >> > Sorry if there is something wrong with my understandings.
> >> > Just because I found my flash’s name was changed to spi-flash@xx:xx
> >> > in dm tree after several probes, I began to read something about
> >> > driver model.J
> >>
> >> Yes I think removing the unbind would be OK, except that we need a
> >> way to show the messages at the end of spi_flash_scan().
> >>
> >> Probably these messages should move out of the uclass and into a
> >> separate call. We could add a function like spi_flash_show(struct
> >> udevice *dev) and call it from do_spi_flash_probe() and perhaps
> >> saveenv().
> >>
> >> Regards,
> >> Simon
> >
> > Thanks for your explanation.
> > So you mean the flash messages? Seems that removing the unbind won't
> > affect reading ID from a real flash.
> 
> I don't really understand what you are asking here.
> 

In your first reply,
  >>
  >> Yes I think removing the unbind would be OK, except that we need a 
  >> way to show the messages at the end of spi_flash_scan().
  >>
What messages were you referring to?
I thought they were like
"SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 
16 MiB".

> > But would the unbind be needed if the dts node is modified at
> > runtime?(I'm not sure if it is necessary)
> 
> You cannot modify the dts node at run-time in U-Boot. It is not currently
> supported.
> 
OK. I just found some fdt commands in U-Boot and thought it might be modified.

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

Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT

[Qianyu Gong]

Hi Vignesh,

> -Original Message-
> From: Vignesh R [mailto:vigne...@ti.com]
> Sent: Wednesday, April 20, 2016 6:47 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; jt...@openedev.com;
> tr...@konsulko.com
> Cc: u-boot@lists.denx.de; s...@denx.de; Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values
> from DT
> 
> On 04/20/2016 03:26 PM, Qianyu Gong wrote:
> > Hi Vignesh,
> >
> >> Date: Wed, 13 Apr 2016 15:40:53 +0530
> >
> >> From: Vignesh R <vigne...@ti.com <mailto:vigne...@ti.com>>
> >
> >> To: Jagan Teki <jt...@openedev.com <mailto:jt...@openedev.com>>, Tom
> > Rini <tr...@konsulko.com <mailto:tr...@konsulko.com>>
> >
> >> Cc: u-boot@lists.denx.de <mailto:u-boot@lists.denx.de>, Stefan Roese
> > <s...@denx.de <mailto:s...@denx.de>>
> >
> >> Subject: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode
> >
> >> valuesfrom DT
> >
> >> Message-ID: <1460542253-10580-1-git-send-email-vigne...@ti.com
> > <mailto:1460542253-10580-1-git-send-email-vigne...@ti.com>>
> >
> >> Content-Type: text/plain
> >
> >>
> >
> >> In case of DT boot, don't read default speed and mode for SPI from
> >
> >> CONFIG_*, instead read from DT node. This will make sure that boards
> >
> >> with multiple SPI/QSPI controllers can be probed at different
> >
> >> bus frequencies and SPI modes.
> >
> >>
> >
> >> Signed-off-by: Vignesh R <vigne...@ti.com <mailto:vigne...@ti.com>>
> >
> >> ---
> >
> >>
> >
> >> v3: Update commit message to mention SPI mode changes
> >
> >>
> >
> >> v2: Initialize speed, mode to 0 instead of -1
> >
> >>
> >
> >>  cmd/sf.c | 2 ++
> >
> >>  drivers/spi/spi-uclass.c | 8 ++--
> >
> >>  2 files changed, 8 insertions(+), 2 deletions(-)
> >
> >>
> >
> >> diff --git a/cmd/sf.c b/cmd/sf.c
> >
> >> index 42862d9d921a..286906c3a151 100644
> >
> >> --- a/cmd/sf.c
> >
> >> +++ b/cmd/sf.c
> >
> >> @@ -88,6 +88,8 @@ static int do_spi_flash_probe(int argc, char *
> >> const
> > argv[])
> >
> >>  #ifdef CONFIG_DM_SPI_FLASH
> >
> >> struct udevice *new, *bus_dev;
> >
> >> int ret;
> >
> >> +  /* In DM mode defaults will be taken from DT */
> >
> >> +  speed = 0, mode = 0;
> >
> >>  #else
> >
> >> struct spi_flash *new;
> >
> >>  #endif
> >
> >> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> >
> >> index 5561f36762f9..5fb5630e2981 100644
> >
> >> --- a/drivers/spi/spi-uclass.c
> >
> >> +++ b/drivers/spi/spi-uclass.c
> >
> >> @@ -264,6 +264,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int
> > speed, int
> >
> >> mode,
> >
> >>   struct udevice **busp, struct
> > spi_slave **devp)
> >
> >>  {
> >
> >> struct udevice *bus, *dev;
> >
> >> +  struct dm_spi_slave_platdata *plat;
> >
> >> bool created = false;
> >
> >> int ret;
> >
> >>
> >
> >> @@ -280,8 +281,6 @@ int spi_get_bus_and_cs(int busnum, int cs, int
> > speed, int
> >
> >> mode,
> >
> >>  * SPI flash chip - we will bind to the correct driver.
> >
> >>  */
> >
> >> if (ret == -ENODEV && drv_name) {
> >
> >> - struct dm_spi_slave_platdata *plat;
> >
> >> -
> >
> >>debug("%s: Binding new device '%s',
> > busnum=%d, cs=%d,
> >
> >> driver=%s\n",
> >
> >>  __func__, dev_name, busnum, cs,
> > drv_name);
> >
> >>ret = device_bind_driver(bus, drv_name,
> > dev_name, );
> >
> >> @@ -308,6 +307,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int
> > speed, int
> >
> >> mode,
> >
> >>slave->dev = dev;
> >
> >> }
> >
> >>
> >
> >

Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT

[Qianyu Gong]

Hi Vignesh,



> Date: Wed, 13 Apr 2016 15:40:53 +0530

> From: Vignesh R >

> To: Jagan Teki >, Tom Rini 
> >

> Cc: u-boot@lists.denx.de, Stefan Roese 
> >

> Subject: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode

> valuesfrom DT

> Message-ID: 
> <1460542253-10580-1-git-send-email-vigne...@ti.com>

> Content-Type: text/plain

>

> In case of DT boot, don't read default speed and mode for SPI from

> CONFIG_*, instead read from DT node. This will make sure that boards

> with multiple SPI/QSPI controllers can be probed at different

> bus frequencies and SPI modes.

>

> Signed-off-by: Vignesh R >

> ---

>

> v3: Update commit message to mention SPI mode changes

>

> v2: Initialize speed, mode to 0 instead of -1

>

>  cmd/sf.c | 2 ++

>  drivers/spi/spi-uclass.c | 8 ++--

>  2 files changed, 8 insertions(+), 2 deletions(-)

>

> diff --git a/cmd/sf.c b/cmd/sf.c

> index 42862d9d921a..286906c3a151 100644

> --- a/cmd/sf.c

> +++ b/cmd/sf.c

> @@ -88,6 +88,8 @@ static int do_spi_flash_probe(int argc, char * const argv[])

>  #ifdef CONFIG_DM_SPI_FLASH

> struct udevice *new, *bus_dev;

> int ret;

> +  /* In DM mode defaults will be taken from DT */

> +  speed = 0, mode = 0;

>  #else

> struct spi_flash *new;

>  #endif

> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c

> index 5561f36762f9..5fb5630e2981 100644

> --- a/drivers/spi/spi-uclass.c

> +++ b/drivers/spi/spi-uclass.c

> @@ -264,6 +264,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int

> mode,

>   struct udevice **busp, struct spi_slave 
> **devp)

>  {

> struct udevice *bus, *dev;

> +  struct dm_spi_slave_platdata *plat;

> bool created = false;

> int ret;

>

> @@ -280,8 +281,6 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int

> mode,

>  * SPI flash chip - we will bind to the correct driver.

>  */

> if (ret == -ENODEV && drv_name) {

> - struct dm_spi_slave_platdata *plat;

> -

>debug("%s: Binding new device '%s', busnum=%d, 
> cs=%d,

> driver=%s\n",

>  __func__, dev_name, busnum, cs, drv_name);

>ret = device_bind_driver(bus, drv_name, dev_name, 
> );

> @@ -308,6 +307,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int

> mode,

>slave->dev = dev;

> }

>

> +  plat = dev_get_parent_platdata(dev);

> +  if (!speed) {

> + speed = plat->max_hz;

> + mode = plat->mode;

> +  }

> ret = spi_set_speed_mode(bus, speed, mode);

> if (ret)

>goto err;

> --

I just doubt if spi_set_speed_mode() has really made a difference to
the actual transfer.
Seems that if the device is inactive, calling device_probe() would also call
spi_set_speed_mode() and do the data transfer. Even if it's active, setting
speed and mode for it again would not be necessary.


Regards,
Qianyu

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

Re: [U-Boot] A problem about 'sf probe' using DM_SPI

[Qianyu Gong]

Hi Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Saturday, April 09, 2016 3:13 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>
> Cc: u-boot@lists.denx.de; Mingkai Hu <mingkai...@nxp.com>; Yao Yuan
> <yao.y...@nxp.com>; jt...@openedev.com
> Subject: Re: A problem about 'sf probe' using DM_SPI
> 
> Hi Qianyu,
> 
> On 25 March 2016 at 03:34, Qianyu Gong <qianyu.g...@nxp.com> wrote:
> > Hi Simon,
> >
> >
> >
> > I think I’m not very clear with this code in common/cmd_sf.c:
> >
> > “
> >
> > # ifdef CONFIG_DM_SPI_FLASH
> >
> >/* Remove the old device, otherwise probe will just be a nop */
> >
> >ret = spi_find_bus_and_cs(bus, cs, _dev, );
> >
> >if (!ret) {
> >
> >   device_remove(new);
> >
> >  device_unbind(new);
> >
> >  }
> >
> > ”
> >
> > I may understand the remove but why need to unbind the device?
> 
> This is because otherwise 'sf probe' would be a nop if the device
> already existed. The spi_flash_probe_bus_cs() call will simply return
> the existing device. If something has changed on the bus, it would be
> ignored.
> 
> >
> > The unbind would cause a series of free operations on the device list,
> > correct?
> 
> Yes
> 
> >
> > Then if I probe a flash twice, at the second time the driver model will
> > create
> >
> > a new flash named ‘spi_flash@xx:xx’ using default settings because it
> > doesn’t
> >
> > find such a device in the device list and never probes it from the board’s
> > fdt again.
> 
> Yes.
> 
> >
> > => dm tree
> >
> > Class   Probed   Name
> >
> > 
> >
> > root[ + ]root_driver
> >
> > simple_bus  [ + ]`-- soc
> >
> > spi [ + ]   |-- dspi@210
> >
> > spi_flash   [   ]||-- n25q128a
> >
> > spi_flash   [ + ]|   |-- spi_flash@1:1
> >
> > spi_flash   [ + ]|   `-- spi_flash@1:2
> >
> > Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it doesn’t
> > cause
> >
> > issues on our boards. But if an SPI flash which only supports SPI_MODE_0 is
> > used,
> >
> > I think it wouldn’t work properly from the second probe.
> >
> > Sorry if there is something wrong with my understandings.
> > Just because I found my flash’s name was changed to spi-flash@xx:xx in dm
> > tree
> > after several probes, I began to read something about driver model.J
> 
> Yes I think removing the unbind would be OK, except that we need a way
> to show the messages at the end of spi_flash_scan().
> 
> Probably these messages should move out of the uclass and into a
> separate call. We could add a function like spi_flash_show(struct
> udevice *dev) and call it from do_spi_flash_probe() and perhaps
> saveenv().
> 
> Regards,
> Simon

Thanks for your explanation.
So you mean the flash messages? Seems that removing the unbind won't affect
reading ID from a real flash.
But would the unbind be needed if the dts node is modified at runtime?(I'm not 
sure if
it is necessary)

Regards,
Qianyu

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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi Scott,

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, March 30, 2016 4:45 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; york sun
> <york@nxp.com>
> Cc: Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On Fri, 2016-03-11 at 10:18 +, Qianyu Gong wrote:
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; york
> > > sun <york@nxp.com>
> > > Cc: Mingkai Hu <mingkai...@nxp.com>
> > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > with QSPI enabled
> > >
> > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > enabled, IFC should be disabled.
> > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > mdio-mux will access IFC address space -- actually it accesses
> > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > in Linux device tree.
> > > >
> > > > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > index 4e4861d..5bb3048 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > #ifdef
> > > > CONFIG_FSL_LSCH3
> > > > fdt_fixup_smmu(blob);
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LS1043A
> > > > +#ifdef CONFIG_FSL_QSPI
> > > > +   do_fixup_by_compat(blob, "fsl,ifc",
> > > > +  "status", "disabled", 8 + 1, 1); #endif
> > > > #endif
> > > >  }
> > >
> > > This muxing is done at runtime, right?  It isn't a case of the board
> > > hardwiring one or the other?  In that case, it should be handled at
> > > runtime here as well.
> > >   At a
> > > minimum, allow the user to use hwconfig to choose which they want to
> > > be accessible.  Ideally there would be something in the device tree
> > > to list the reason(s) for a device being disabled, so the OS knows
> > > it can regard the device as being enabled if it knows about and
> > > enables them all.
> > >
> > > -Scott
> >
> > Sorry for the late reply. We have been asking the silicon team for the
> > details of the pin muxing these days.
> > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > long as QSPI is enabled on LS1043AQDS board.
> > As I know, this muxing won't be handled in kernel. Since IFC is
> > disabled in U-Boot, IFC node would better be disabled in kernel as
> > well.
> > Also in such cases, users have no other choice.
> 
> Why should the user not have a choice to choose IFC over QSPI?  Where is the
> muxing configured?
> 
> -Scott

Because this muxing can't be changed at runtime.
Two ways so far to configure it:
1. SW6[1-4] switches on ls1043aqds board.
2. Modify QIXIS board config registers and reset the board.


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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi Prabhakar,

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Monday, March 28, 2016 4:52 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; Scott Wood <o...@buserror.net>; u-
> b...@lists.denx.de; york sun <york@nxp.com>
> Cc: Mingkai Hu <mingkai...@nxp.com>
> Subject: RE: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Qianyu
> > Gong
> > Sent: Friday, March 11, 2016 3:49 PM
> > To: Scott Wood <o...@buserror.net>; u-boot@lists.denx.de; york sun
> > <york@nxp.com>
> > Cc: Mingkai Hu <mingkai...@nxp.com>
> > Subject: Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for
> > LS1043A with QSPI enabled
> >
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; york
> > sun
> > > <york@nxp.com>
> > > Cc: Mingkai Hu <mingkai...@nxp.com>
> > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > with QSPI enabled
> > >
> > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > enabled, IFC should be disabled.
> > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > mdio-mux will access IFC address space -- actually it accesses
> > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > in Linux device tree.
> > > >
> > > > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > index 4e4861d..5bb3048 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > #ifdef
> > > > CONFIG_FSL_LSCH3
> > > > fdt_fixup_smmu(blob);
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LS1043A
> > > > +#ifdef CONFIG_FSL_QSPI
> > > > +   do_fixup_by_compat(blob, "fsl,ifc",
> > > > +  "status", "disabled", 8 + 1, 1); #endif 
> > > > #endif
> > > >  }
> > >
> > > This muxing is done at runtime, right?  It isn't a case of the board
> > > hardwiring one or the other?  In that case, it should be handled at
> > > runtime here as well.  At a minimum, allow the user to use hwconfig
> > > to choose which they want to be accessible.  Ideally there would be
> > > something in the device tree to list the reason(s) for a device
> > > being disabled, so the OS knows it can regard the device as being
> > > enabled if it
> > knows about and enables them all.
> > >
> > > -Scott
> >
> > Sorry for the late reply. We have been asking the silicon team for the
> > details of the pin muxing these days.
> > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > long as QSPI is enabled on LS1043AQDS board.
> > As I know, this muxing won't be handled in kernel. Since IFC is
> > disabled in U- Boot, IFC node would better be disabled in kernel as well.
> > Also in such cases, users have no other choice.
> >
> 
> This may not be always true.
> 
>  In LS1088A, IFC-FPGA is available during QSPI boot.
> 
> --prabhakar
> 

Yes, you're right. That's why I added "#ifdef CONFIG_LS1043A".
So I think it only affects ls1043a so far.

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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi all,

Any comments about this patch? Thanks!

Regards,
Qianyu

> -Original Message-
> From: Gong Qianyu [mailto:qianyu.g...@nxp.com]
> Sent: Monday, February 22, 2016 6:05 PM
> To: u-boot@lists.denx.de; york sun <york@nxp.com>; o...@buserror.net
> Cc: Mingkai Hu <mingkai...@nxp.com>; Qianyu Gong <qianyu.g...@nxp.com>
> Subject: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> IFC should be disabled.
> But just disable IFC driver in LS1043A Linux is not enough because
> mdio-mux will access IFC address space -- actually it accesses FPGA
> which is connected to IFC CS3. So disable the whole IFC node in
> Linux device tree.
> 
> Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-
> layerscape/fdt.c
> index 4e4861d..5bb3048 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  #ifdef CONFIG_FSL_LSCH3
>   fdt_fixup_smmu(blob);
>  #endif
> +
> +#ifdef CONFIG_LS1043A
> +#ifdef CONFIG_FSL_QSPI
> + do_fixup_by_compat(blob, "fsl,ifc",
> +"status", "disabled", 8 + 1, 1);
> +#endif
> +#endif
>  }
> --
> 2.1.0.27.g96db324

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

[U-Boot] A problem about 'sf probe' using DM_SPI

[Qianyu Gong]

Hi Simon,

I think I'm not very clear with this code in common/cmd_sf.c:
"
# ifdef CONFIG_DM_SPI_FLASH
   /* Remove the old device, otherwise probe will just be a nop */
   ret = spi_find_bus_and_cs(bus, cs, _dev, );
   if (!ret) {
  device_remove(new);
 device_unbind(new);
 }
"
I may understand the remove but why need to unbind the device?
The unbind would cause a series of free operations on the device list, correct?

Then if I probe a flash twice, at the second time the driver model will create
a new flash named 'spi_flash@xx:xx' using default settings because it doesn't
find such a device in the device list and never probes it from the board's fdt 
again.

=> dm tree
Class   Probed   Name

root[ + ]root_driver
simple_bus  [ + ]`-- soc
spi [ + ]   |-- dspi@210
spi_flash   [   ]||-- n25q128a
spi_flash   [ + ]|   |-- spi_flash@1:1
spi_flash   [ + ]|   `-- spi_flash@1:2

Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it doesn't cause
issues on our boards. But if an SPI flash which only supports SPI_MODE_0 is 
used,
I think it wouldn't work properly from the second probe.


Sorry if there is something wrong with my understandings.
Just because I found my flash's name was changed to spi-flash@xx:xx in dm tree
after several probes, I began to read something about driver model.:)


Regards,
Qianyu

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

Re: [U-Boot] [PATCH 2/2] armv8/ls1043aqds: use configuarable clock for non-QSPI boot

[Qianyu Gong]

Hi York，

在 2016年3月19日，上午12:53，york sun > 写道：

On 03/14/2016 03:06 AM, Gong Qianyu wrote:
For QSPI boot and SD boot with QSPI, we could only read from FPGA
through I2C to get the system clock and DDR clock info. However in
U-Boot booting flow, I2C is not initialized when get_clocks() is
called and thus it couldn't get correct value of the clocks.
So the configuarable clock is only supported by non-QSPI boot.

Signed-off-by: Gong Qianyu >
---
include/configs/ls1043aqds.h | 5 +
1 file changed, 5 insertions(+)

diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h
index 158cf02..93671f0 100644
--- a/include/configs/ls1043aqds.h
+++ b/include/configs/ls1043aqds.h
@@ -29,8 +29,13 @@ unsigned long get_board_sys_clk(void);
unsigned long get_board_ddr_clk(void);
#endif

+#if defined(CONFIG_QSPI_BOOT) || (CONFIG_SD_BOOT_QSPI)
#define CONFIG_SYS_CLK_FREQ 1
#define CONFIG_DDR_CLK_FREQ 1
+#else
+#define CONFIG_SYS_CLK_FREQ get_board_sys_clk()
+#define CONFIG_DDR_CLK_FREQ get_board_ddr_clk()
+#endif

#define CONFIG_SKIP_LOWLEVEL_INIT


Qianyu,

Please work with Yuan Yao on qixis access. We may have a solution to get the
clocks on QSPI boot.

York

Yes. I have been discussing with Yuan Yao these days.
Yesterday we tried to initialize i2c by writing several related registers and 
finally
verified on LS2080AQDS board. Seems that this way is feasible and simple
enough for us to read FPGA earlier.
Then I’ll send a new version of this patch.


Regards,
Qianyu



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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Qianyu Gong]

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Tuesday, March 15, 2016 7:18 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; Huan Wang <alison.w...@nxp.com>
> Cc: york sun <york@nxp.com>; Tom Rini <tr...@konsulko.com>; Siva Durga
> Prasad Paladugu <siva...@xilinx.com>; Michal Simek <michal.si...@xilinx.com>;
> u-boot@lists.denx.de; Stefan Roese <s...@denx.de>; Mingkai Hu
> <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
> 
> On 9 March 2016 at 13:37, Qianyu Gong <qianyu.g...@nxp.com> wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Tuesday, March 08, 2016 12:46 AM
> >> To: Jagan Teki <jt...@openedev.com>; Huan Wang <alison.w...@nxp.com>;
> >> Qianyu Gong <qianyu.g...@nxp.com>
> >> Cc: u-boot@lists.denx.de; Siva Durga Prasad Paladugu
> >> <siva...@xilinx.com>; Stefan Roese <s...@denx.de>; Michal Simek
> >> <michal.si...@xilinx.com>; Tom Rini <tr...@konsulko.com>
> >> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
> >>
> >> On 03/03/2016 01:06 PM, york sun wrote:
> >> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
> >> >> Hi York,
> >> >>
> >> >> On 27 February 2016 at 02:14, york sun <york@nxp.com> wrote:
> >> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
> >>
> >> 
> >>
> >> >>>>
> >> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
> >> >>>>
> >> >>> Jagan,
> >> >>>
> >> >>> I am getting there. Will test sf probe/read/write and probably
> >> >>> boot on selected platforms. Is there any specific platform/test in 
> >> >>> your mind?
> >> >>
> >> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
> >> >>
> >> >
> >> > Jagan,
> >> >
> >> > Sorry for the delay. I am having issue with both ls1021aqds and
> >> > ls1043aqds. Need to work with internal team to sort it out.
> >> >
> >> > My understanding the tests you need are for spi-nor, in my case,
> >> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I
> >> > only have ls1021aqds and ls1043aqds with such support.
> >> >
> >>
> >> Jagan,
> >>
> >> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There
> >> were some issues. They will post their findings (and possible fix) to this 
> >> thread.
> >>
> >> York
> >
> > I tested on LS1043AQDS board based on your spi-nor branch. The
> 'spi_flash_probe'
> > failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is
> > not defined for the board but it could be selected if CONFIG_MTD &&
> CONFIG_DM_SPI, correct?
> >
> > So after I moved CONFIG_MTD to the defconfig file, the probing could work 
> > now.
> >
> > And there is another small effect on our Fman driver. It would like to
> > read ucode blob from the QSPI flash. As the 'spi_flash_read' interface
> > is changed, I've modified the address value to an offset value in flash.
> 
> Qianyu,
> 
> > Here are my patches:
> > http://patchwork.ozlabs.org/patch/594872/
> > http://patchwork.ozlabs.org/patch/594873/
> > http://patchwork.ozlabs.org/patch/594874/
> 
> I have applied 3rd patch on my test branch, and remaining two will go in 
> another
> time like once spi-nor got merged.
> 
> Qianyu/Alison Wang,
> 
> Please test this[1] branch for your new changes and let me know for any 
> issues.
> 
> [1] 
> http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor-
> next
> 
> --
> Jagan.

Hi Jagan,

Both DSPI and QSPI work well on LS1043ARDB/LS1043AQDS board.
Thanks!

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

Re: [U-Boot] [PATCH 1/2] armv8/ls1043aqds: fix print info for QSPI boot

[Qianyu Gong]

Please ignore this patch.. sent out for mistake:(

> -Original Message-
> From: Gong Qianyu [mailto:qianyu.g...@nxp.com]
> Sent: Monday, March 14, 2016 5:57 PM
> To: u-boot@lists.denx.de; york sun <york@nxp.com>; Mingkai Hu
> <mingkai...@nxp.com>
> Cc: o...@buserror.net; Qianyu Gong <qianyu.g...@nxp.com>
> Subject: [PATCH 1/2] armv8/ls1043aqds: fix print info for QSPI boot
> 
> according to the Reference manual.
> 
> Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> ---
>  board/freescale/ls1043aqds/ls1043aqds.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
> b/board/freescale/ls1043aqds/ls1043aqds.c
> index a72fe52..bd73e4f 100644
> --- a/board/freescale/ls1043aqds/ls1043aqds.c
> +++ b/board/freescale/ls1043aqds/ls1043aqds.c
> @@ -47,7 +47,7 @@ enum {
>  int checkboard(void)
>  {
>   char buf[64];
> -#if !defined(CONFIG_SD_BOOT) && !defined(CONFIG_QSPI_BOOT)
> +#ifndef CONFIG_SD_BOOT
>   u8 sw;
>  #endif
> 
> @@ -55,8 +55,6 @@ int checkboard(void)
> 
>  #ifdef CONFIG_SD_BOOT
>   puts("SD\n");
> -#elif defined(CONFIG_QSPI_BOOT)
> - puts("QSPI\n");
>  #else
>   sw = QIXIS_READ(brdcfg[0]);
>   sw = (sw & QIXIS_LBMAP_MASK) >> QIXIS_LBMAP_SHIFT; @@ -67,8 +65,8
> @@ int checkboard(void)
>   puts("PromJet\n");
>   else if (sw == 0x9)
>   puts("NAND\n");
> - else if (sw == 0x15)
> - printf("IFCCard\n");
> + else if (sw == 0xF)
> + printf("QSPI\n");
>   else
>   printf("invalid setting of SW%u\n", QIXIS_LBMAP_SWITCH);
> #endif
> --
> 2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 3/3] armv8/ls1043a: move CONFIG_MTD to defconfig

[Qianyu Gong]

Hi Jagan,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Saturday, March 12, 2016 1:37 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>
> Cc: york sun <york@nxp.com>; Mingkai Hu <mingkai...@nxp.com>; u-
> b...@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 3/3] armv8/ls1043a: move CONFIG_MTD to
> defconfig
> 
> On Mar 9, 2016 1:31 PM, "Gong Qianyu" <qianyu.g...@nxp.com> wrote:
> 
> >
> > To make it take effect to enable MTD driver model for SPI-NOR.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > ---
> >  configs/ls1043aqds_defconfig | 1 +
> >  configs/ls1043aqds_lpuart_defconfig  | 1 +
> >  configs/ls1043aqds_nand_defconfig| 1 +
> >  configs/ls1043aqds_nor_ddr3_defconfig| 1 +
> >  configs/ls1043aqds_qspi_defconfig| 1 +
> >  configs/ls1043aqds_sdcard_ifc_defconfig  | 1 +
> > configs/ls1043aqds_sdcard_qspi_defconfig | 1 +
> > configs/ls1043ardb_SECURE_BOOT_defconfig | 1 +
> >  configs/ls1043ardb_defconfig | 1 +
> >  configs/ls1043ardb_nand_defconfig| 1 +
> >  configs/ls1043ardb_sdcard_defconfig  | 1 +
> >  include/configs/ls1043a_common.h | 1 -
> >  12 files changed, 11 insertions(+), 1 deletion(-
> 
> Look like all these files using this ls*_common.h, then why this patch moving 
> MTD
> to all defconfigs?
> 
> --
> Jagan.

According to ./drivers/mtd/spi-nor/Kconfig, CONFIG_DM_MTD_SPI_NOR needs 
CONFIG_MTD and CONFIG_DM_SPI to select it.
Then only when CONFIG_MTD is moved to defconfigs can CONFIG_DM_MTD_SPI_NOR
be defined. Or else, we have to define CONFIG_DM_MTD_SPI_NOR manually.

Regards,
Qianyu

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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi Prabhakar,

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Monday, February 22, 2016 7:51 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; york sun
> <york@nxp.com>; o...@buserror.net
> Cc: Qianyu Gong <qianyu.g...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> Subject: RE: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> with QSPI enabled
> 
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Gong
> > Qianyu
> > Sent: Monday, February 22, 2016 3:35 PM
> > To: u-boot@lists.denx.de; york sun <york@nxp.com>;
> > o...@buserror.net
> > Cc: Qianyu Gong <qianyu.g...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> > Subject: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for
> > LS1043A with QSPI enabled
> >
> > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> > IFC should be disabled.
> > But just disable IFC driver in LS1043A Linux is not enough because
> > mdio-mux will access IFC address space -- actually it accesses FPGA
> > which is connected to IFC CS3. So disable the whole IFC node in Linux 
> > device tree.
> >
> 
> FPGA and NAND access are valid use-case during QSPI boot
> 
> So why IFC controller is being disabled from device tree.
> 

As Mingkai explained, neither FGPA nor NAND is valid when QSPI is enabled on 
LS1043AQDS.

> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index 4e4861d..5bb3048 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > CONFIG_FSL_LSCH3
> > fdt_fixup_smmu(blob);
> >  #endif
> > +
> > +#ifdef CONFIG_LS1043A
> 
> I will suggest to avoid SoC specific defines
> 
> --prabhakar

I think only LS1043A needs this fixup for the moment.
So if there's any change on new chips, it wouldn't affect them.


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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi Scott,

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Tuesday, February 23, 2016 8:12 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de; york sun
> <york@nxp.com>
> Cc: Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> > IFC should be disabled.
> > But just disable IFC driver in LS1043A Linux is not enough because
> > mdio-mux will access IFC address space -- actually it accesses FPGA
> > which is connected to IFC CS3. So disable the whole IFC node in Linux
> > device tree.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index 4e4861d..5bb3048 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > CONFIG_FSL_LSCH3
> > fdt_fixup_smmu(blob);
> >  #endif
> > +
> > +#ifdef CONFIG_LS1043A
> > +#ifdef CONFIG_FSL_QSPI
> > +   do_fixup_by_compat(blob, "fsl,ifc",
> > +  "status", "disabled", 8 + 1, 1); #endif #endif
> >  }
> 
> This muxing is done at runtime, right?  It isn't a case of the board 
> hardwiring one
> or the other?  In that case, it should be handled at runtime here as well.  
> At a
> minimum, allow the user to use hwconfig to choose which they want to be
> accessible.  Ideally there would be something in the device tree to list the 
> reason(s)
> for a device being disabled, so the OS knows it can regard the device as being
> enabled if it knows about and enables them all.
> 
> -Scott

Sorry for the late reply. We have been asking the silicon team for the details 
of the pin 
muxing these days. 
The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as long as 
QSPI is 
enabled on LS1043AQDS board. 
As I know, this muxing won't be handled in kernel. Since IFC is disabled in 
U-Boot, 
IFC node would better be disabled in kernel as well.
Also in such cases, users have no other choice.


Regards,
Qianyu

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Qianyu Gong]

Hi Jagan,

> -Original Message-
> From: york sun
> Sent: Tuesday, March 08, 2016 12:46 AM
> To: Jagan Teki <jt...@openedev.com>; Huan Wang <alison.w...@nxp.com>;
> Qianyu Gong <qianyu.g...@nxp.com>
> Cc: u-boot@lists.denx.de; Siva Durga Prasad Paladugu <siva...@xilinx.com>;
> Stefan Roese <s...@denx.de>; Michal Simek <michal.si...@xilinx.com>; Tom Rini
> <tr...@konsulko.com>
> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
> 
> On 03/03/2016 01:06 PM, york sun wrote:
> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
> >> Hi York,
> >>
> >> On 27 February 2016 at 02:14, york sun <york@nxp.com> wrote:
> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
> 
> 
> 
> >>>>
> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
> >>>>
> >>> Jagan,
> >>>
> >>> I am getting there. Will test sf probe/read/write and probably boot
> >>> on selected platforms. Is there any specific platform/test in your mind?
> >>
> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
> >>
> >
> > Jagan,
> >
> > Sorry for the delay. I am having issue with both ls1021aqds and
> > ls1043aqds. Need to work with internal team to sort it out.
> >
> > My understanding the tests you need are for spi-nor, in my case,
> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only
> > have ls1021aqds and ls1043aqds with such support.
> >
> 
> Jagan,
> 
> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some
> issues. They will post their findings (and possible fix) to this thread.
> 
> York

I tested on LS1043AQDS board based on your spi-nor branch. The 'spi_flash_probe'
failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is not defined
for the board but it could be selected if CONFIG_MTD && CONFIG_DM_SPI, correct? 

So after I moved CONFIG_MTD to the defconfig file, the probing could work now.

And there is another small effect on our Fman driver. It would like to read 
ucode blob 
from the QSPI flash. As the 'spi_flash_read' interface is changed, I've 
modified the address
value to an offset value in flash.

Here are my patches:
http://patchwork.ozlabs.org/patch/594872/
http://patchwork.ozlabs.org/patch/594873/
http://patchwork.ozlabs.org/patch/594874/


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

Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman driver code

[Qianyu Gong]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, February 17, 2016 5:23 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; york sun <york@nxp.com>; u-
> b...@lists.denx.de
> Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman
> driver code
> 
> On Mon, 2016-02-15 at 05:44 +, Qianyu Gong wrote:
> > > -Original Message-
> > > From: york sun
> > > Sent: Friday, February 12, 2016 1:39 AM
> > > To: Scott Wood <o...@buserror.net>; Qianyu Gong
> > > <qianyu.g...@nxp.com>; u- b...@lists.denx.de
> > > Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup
> > > to Fman driver code
> > >
> > > On 02/08/2016 11:25 AM, Scott Wood wrote:
> > > > On Mon, 2016-02-08 at 19:22 +, york sun wrote:
> > > > > On 02/08/2016 11:18 AM, Scott Wood wrote:
> > > > > > On Mon, 2016-02-08 at 19:03 +, york sun wrote:
> > > > > > > On 02/01/2016 09:06 AM, york sun wrote:
> > > > > > > > On 01/25/2016 09:40 PM, Qianyu Gong wrote:
> > > > > > > > >
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > > > > > > Sent: Tuesday, January 26, 2016 1:17 AM
> > > > > > > > > > To: Qianyu Gong <qianyu.g...@nxp.com>;
> > > > > > > > > > u-boot@lists.denx.de
> > > > > > > > > > Cc: b07...@freescale.com; Shaohui Xie
> > > > > > > > > > <shaohui@nxp.com>
> > > > > > > > > > Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move
> > > > > > > > > > fman ucode fixup to Fman driver code
> > > > > > > > > >
> > > > > > > > > > On Mon, 2016-01-25 at 19:37 +0800, Gong Qianyu wrote:
> > > > > > > > > > > Both Freescale Layerscape and powerpc/mpc85xx
> > > > > > > > > > > platforms are using
> > > > > > > > > > > fdt_fixup_fman_firmware() to insert Fman ucode blob
> > > > > > > > > > > into the device tree. So move the function to driver
> > > > > > > > > > > code.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > > > > > > > > > > ---
> > > > > > > > > > > V3:
> > > > > > > > > > >  - Remove file changes about "qe.h".
> > > > > > > > > > >(Should be put in the first patch of this
> > > > > > > > > > > patchset)
> > > > > > > > > > > V2:
> > > > > > > > > > >  - New patch.
> > > > > > > > > > >
> > > > > > > > > > >  arch/powerpc/cpu/mpc85xx/fdt.c | 125
> > > > > > > > > > > ++
> > > > > > > > > > > -
> > > > > > > > > > >  drivers/net/fm/Makefile|   1 +
> > > > > > > > > > >  drivers/net/fm/fdt.c   | 129
> > > > > > > > > > > +
> > > > > > > > > > >  include/fsl_fman.h |   1 +
> > > > > > > > > > >  4 files changed, 136 insertions(+), 120
> > > > > > > > > > > deletions(-)
> > > > > > > > > >
> > > > > > > > > > Again, pass -M -C to git format-patch.
> > > > > > > > > >
> > > > > > > > > > -Scott
> > > > > > > > >
> > > > > > > > > I don't understand but I've already used "git
> > > > > > > > > format-patch -M -C
> > > > > > > > > - -stat ...".
> > > > > > > > >
> > > > > > > >
> > > > > > > > Scott means using -M and -C, git should detect the moving
> > > > > > > > instead of adding and deleting the same code. Try to add
> > > > > > > > --find-copies-harder to see if it generates a smaller
> > > > > > > > patch.
> > > > > > > >
> > > > > > >
> > > > > > > Qianyu,
> > > > > > >
> > > > > > > Since you are on holiday, I tried it for you. Adjusting "-M -C"
> > > > > > > doesn't
> > > > > > > work.
> > > > > > > Even you are moving the function from one file to another,
> > > > > > > "git format -patch"
> > > > > > > cannot detect the moving because both files exist before and
> > > > > > > after this change, and the change set is not significant
> > > > > > > enough to be detected.
> > > > > >
> > > > > > It looks like the patch is creating drivers/net/fm/fdt.c...
> > > > > >
> > >
> > > Actually you were right. This patch creates a new file. There are
> > > also other small changes here and there. Maybe that's the reason git
> > > doesn't detect the move.
> > >
> > > Anyway, let me know if you have further comment. I am testing these
> > > patches.
> > >
> > > York
> >
> > Hi York,
> >
> > Thanks! I did make small changes in the function to make it work for
> > both powerpc and arm platforms.
> 
> Those changes should have been a separate patch -- otherwise it's a lot of 
> work to
> see what those changes are and review them.
> 
> -Scott

OK.. Thanks for your reminder.

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

Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman driver code

[Qianyu Gong]

> -Original Message-
> From: york sun
> Sent: Friday, February 12, 2016 1:39 AM
> To: Scott Wood <o...@buserror.net>; Qianyu Gong <qianyu.g...@nxp.com>; u-
> b...@lists.denx.de
> Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman
> driver code
> 
> On 02/08/2016 11:25 AM, Scott Wood wrote:
> > On Mon, 2016-02-08 at 19:22 +, york sun wrote:
> >> On 02/08/2016 11:18 AM, Scott Wood wrote:
> >>> On Mon, 2016-02-08 at 19:03 +, york sun wrote:
> >>>> On 02/01/2016 09:06 AM, york sun wrote:
> >>>>> On 01/25/2016 09:40 PM, Qianyu Gong wrote:
> >>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: Scott Wood [mailto:o...@buserror.net]
> >>>>>>> Sent: Tuesday, January 26, 2016 1:17 AM
> >>>>>>> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> >>>>>>> Cc: b07...@freescale.com; Shaohui Xie <shaohui@nxp.com>
> >>>>>>> Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode
> >>>>>>> fixup to Fman driver code
> >>>>>>>
> >>>>>>> On Mon, 2016-01-25 at 19:37 +0800, Gong Qianyu wrote:
> >>>>>>>> Both Freescale Layerscape and powerpc/mpc85xx platforms are
> >>>>>>>> using
> >>>>>>>> fdt_fixup_fman_firmware() to insert Fman ucode blob into the
> >>>>>>>> device tree. So move the function to driver code.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> >>>>>>>> ---
> >>>>>>>> V3:
> >>>>>>>>  - Remove file changes about "qe.h".
> >>>>>>>>(Should be put in the first patch of this patchset)
> >>>>>>>> V2:
> >>>>>>>>  - New patch.
> >>>>>>>>
> >>>>>>>>  arch/powerpc/cpu/mpc85xx/fdt.c | 125
> >>>>>>>> ++
> >>>>>>>> -
> >>>>>>>>  drivers/net/fm/Makefile|   1 +
> >>>>>>>>  drivers/net/fm/fdt.c   | 129
> >>>>>>>> +
> >>>>>>>>  include/fsl_fman.h |   1 +
> >>>>>>>>  4 files changed, 136 insertions(+), 120 deletions(-)
> >>>>>>>
> >>>>>>> Again, pass -M -C to git format-patch.
> >>>>>>>
> >>>>>>> -Scott
> >>>>>>
> >>>>>> I don't understand but I've already used "git format-patch -M -C
> >>>>>> - -stat ...".
> >>>>>>
> >>>>>
> >>>>> Scott means using -M and -C, git should detect the moving instead of
> >>>>> adding and
> >>>>> deleting the same code. Try to add --find-copies-harder to see if it
> >>>>> generates a
> >>>>> smaller patch.
> >>>>>
> >>>>
> >>>> Qianyu,
> >>>>
> >>>> Since you are on holiday, I tried it for you. Adjusting "-M -C" doesn't
> >>>> work.
> >>>> Even you are moving the function from one file to another, "git format
> >>>> -patch"
> >>>> cannot detect the moving because both files exist before and after this
> >>>> change,
> >>>> and the change set is not significant enough to be detected.
> >>>
> >>> It looks like the patch is creating drivers/net/fm/fdt.c...
> >>>
> 
> Actually you were right. This patch creates a new file. There are also other
> small changes here and there. Maybe that's the reason git doesn't detect the 
> move.
> 
> Anyway, let me know if you have further comment. I am testing these patches.
> 
> York

Hi York,

Thanks! I did make small changes in the function to make it work for both 
powerpc 
and arm platforms.

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

Re: [U-Boot] [PATCH] pci: gate print info of reading vender id with CONFIG_DM_PCI

[Qianyu Gong]

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, January 28, 2016 4:02 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] pci: gate print info of reading vender id with
> CONFIG_DM_PCI
> 
> On Thu, Jan 28, 2016 at 3:43 PM, Qianyu Gong <qianyu.g...@nxp.com> wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Bin Meng [mailto:bmeng...@gmail.com]
> >> Sent: Thursday, January 28, 2016 3:30 PM
> >> To: Qianyu Gong <qianyu.g...@nxp.com>
> >> Cc: U-Boot Mailing List <u-boot@lists.denx.de>
> >> Subject: Re: [U-Boot] [PATCH] pci: gate print info of reading vender
> >> id with CONFIG_DM_PCI
> >>
> >> On Thu, Jan 28, 2016 at 3:15 PM, Gong Qianyu <qianyu.g...@nxp.com> wrote:
> >> > From: Mingkai Hu <mingkai...@freescale.com>
> >> >
> >> > Referring to 'commit ff3e077bd23c ("dm: pci: Add a uclass for PCI")'.
> >> >
> >> > For legacy PCIe driver, it needs loop to read the vender_id from
> >> > devie
> >> > 0 to devie 255 to check if there is device available.
> >> > Reading non-existen device will trigger the "Cannot read bus
> >> > configuration: -1" information.
> >> >
> >> > Signed-off-by: Mingkai Hu <mingkai...@freescale.com>
> >> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> >> > ---
> >>
> >> Which pci controller are you testing?
> >>
> >> [snip]
> >>
> >> Regards,
> >> Bin
> >
> > Designware PCIe controller on LS2085A.
> >
> 
> Please check commit 7ba34ff09f1ef105521f914e4ad4e4ac19975bac "pci:
> layerscape: Adjust the return value when ls_pcie_addr_valid() fails"
> which is already in mainline.
> 
> Regards,
> Bin

Ok. That's nice of you. 
And we also find another commit cab24b3407189a12 "dm: pci: Convert 'pci' 
command to driver model" submitted by Simon has fixed the issue. So no 
need of this patch.
Thanks a lot.

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

Re: [U-Boot] [PATCH] pci: gate print info of reading vender id with CONFIG_DM_PCI

[Qianyu Gong]

Hi,

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, January 28, 2016 3:30 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>
> Cc: U-Boot Mailing List <u-boot@lists.denx.de>
> Subject: Re: [U-Boot] [PATCH] pci: gate print info of reading vender id with
> CONFIG_DM_PCI
> 
> On Thu, Jan 28, 2016 at 3:15 PM, Gong Qianyu <qianyu.g...@nxp.com> wrote:
> > From: Mingkai Hu <mingkai...@freescale.com>
> >
> > Referring to 'commit ff3e077bd23c ("dm: pci: Add a uclass for PCI")'.
> >
> > For legacy PCIe driver, it needs loop to read the vender_id from devie
> > 0 to devie 255 to check if there is device available.
> > Reading non-existen device will trigger the "Cannot read bus
> > configuration: -1" information.
> >
> > Signed-off-by: Mingkai Hu <mingkai...@freescale.com>
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > ---
> 
> Which pci controller are you testing?
> 
> [snip]
> 
> Regards,
> Bin

Designware PCIe controller on LS2085A.


Regards,
Qianyu

___
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

[Qianyu Gong]

> -Original Message-
> From: york sun
> Sent: Tuesday, January 26, 2016 1:02 AM
> To: Scott Wood <scott.w...@nxp.com>; Yao Yuan <yao.y...@nxp.com>;
> Qianyu Gong <qianyu.g...@nxp.com>
> Cc: b48...@freescale.com; u-boot@lists.denx.de; wenbin.s...@freescale.com;
> jt...@openedev.com
> Subject: Re: [U-Boot] [Patch V5 2/4] spi: fsl_qspi: Fix qspi_op_rdid memcpy 
> issue
> 
> On 01/25/2016 09:01 AM, Scott Wood wrote:
> > On 01/25/2016 10:47 AM, york sun wrote:
> >> On 01/24/2016 08:09 PM, Yao Yuan wrote:
> >>> 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 <qianyu.g...@nxp.com>; 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 <o...@buserror.net>; Gong
> >>>>>>> Qianyu <qianyu.g...@freescale.com>
> >>>>>>> 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 <qianyu.g...@freescale.com>
> >>>>>>>>
> >>>>>>>> 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 <qianyu.g...@freescale.com>
> >>>>>>>> ---
> >>>>>>>> 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);
> >&

Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman driver code

[Qianyu Gong]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Tuesday, January 26, 2016 1:17 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: b07...@freescale.com; Shaohui Xie <shaohui@nxp.com>
> Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman
> driver code
> 
> On Mon, 2016-01-25 at 19:37 +0800, Gong Qianyu wrote:
> > Both Freescale Layerscape and powerpc/mpc85xx platforms are using
> > fdt_fixup_fman_firmware() to insert Fman ucode blob into the device
> > tree. So move the function to driver code.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > ---
> > V3:
> >  - Remove file changes about "qe.h".
> >(Should be put in the first patch of this patchset)
> > V2:
> >  - New patch.
> >
> >  arch/powerpc/cpu/mpc85xx/fdt.c | 125
> > ++
> > -
> >  drivers/net/fm/Makefile|   1 +
> >  drivers/net/fm/fdt.c   | 129
> > +
> >  include/fsl_fman.h |   1 +
> >  4 files changed, 136 insertions(+), 120 deletions(-)
> 
> Again, pass -M -C to git format-patch.
> 
> -Scott

I don't understand but I've already used "git format-patch -M -C --stat ...".

Regards,
Qianyu

___
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

[Qianyu Gong]

> -Original Message-
> From: Scott Wood
> Sent: Friday, January 22, 2016 3:30 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; 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
> <o...@buserror.net>; Gong Qianyu <qianyu.g...@freescale.com>
> 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 <qianyu.g...@freescale.com>
> >
> > 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 <qianyu.g...@freescale.com>
> > ---
> > 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++;
}
}


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

Re: [U-Boot] [Patch V5 1/4] spi: fsl_qspi: fix compile warning for 64-bit platform

[Qianyu Gong]

> -Original Message-
> From: Scott Wood
> Sent: Friday, January 22, 2016 3:28 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; 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
> <o...@buserror.net>; Gong Qianyu <qianyu.g...@freescale.com>
> Subject: Re: [Patch V5 1/4] spi: fsl_qspi: fix compile warning for 64-bit 
> platform
> 
> On 01/20/2016 09:42 PM, Gong Qianyu wrote:
> > From: Gong Qianyu <qianyu.g...@freescale.com>
> >
> > This patch fixes the following compile warning:
> > drivers/spi/fsl_qspi.c: In function 'fsl_qspi_probe':
> > drivers/spi/fsl_qspi.c:937:15:
> >   warning: cast to pointer from integer of different size
> >  [-Wint-to-pointer-cast]
> >   priv->regs = (struct fsl_qspi_regs *)plat->reg_base;
> >^
> > Just make the cast explicit.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> > ---
> > V5:
> >  - Use uintptr_t instead of unsigned long.
> > V4:
> >  - Revise the commit message.
> > V2-V3:
> >  - No change.
> >
> >  drivers/spi/fsl_qspi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> > 542b6cf..38e5900 100644
> > --- a/drivers/spi/fsl_qspi.c
> > +++ b/drivers/spi/fsl_qspi.c
> > @@ -936,7 +936,7 @@ static int fsl_qspi_probe(struct udevice *bus)
> >
> > dm_spi_bus->max_hz = plat->speed_hz;
> >
> > -   priv->regs = (struct fsl_qspi_regs *)plat->reg_base;
> > +   priv->regs = (struct fsl_qspi_regs *)(uintptr_t)plat->reg_base;
> > priv->flags = plat->flags;
> >
> > priv->speed_hz = plat->speed_hz;
> >
> 
> Use phys_to_virt().
> 
> -Scott

The function seems to be dropped in U-Boot? 
I just find it in arch/arm/include/asm/memory.h with ''#if 0''.

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

Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support

[Qianyu Gong]

Hi Scott,

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Friday, January 22, 2016 6:50 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: b48...@freescale.com; wenbin.s...@freescale.com; Mingkai Hu
> <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support
> 
> On Thu, 2016-01-14 at 04:26 +, Qianyu Gong wrote:
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Thursday, January 14, 2016 8:21 AM
> > > To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> > > Cc: b07...@freescale.com; b48...@freescale.com;
> > > wenbin.s...@freescale.com; Mingkai Hu <mingkai...@nxp.com>
> > > Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot
> > > support
> > >
> > > On Tue, 2016-01-12 at 03:14 +, Qianyu Gong wrote:
> > > > > -Original Message-
> > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > Sent: Tuesday, January 12, 2016 1:47 AM
> > > > > To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> > > > > Cc: b07...@freescale.com; b48...@freescale.com;
> > > > > wenbin.s...@freescale.com; Mingkai Hu <mingkai...@nxp.com>
> > > > > Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI
> > > > > boot support
> > > > >
> > > > > On Mon, 2016-01-11 at 10:17 +0800, Gong Qianyu wrote:
> > > > > > diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > b/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > index d6696ca..770b79f 100644
> > > > > > --- a/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > +++ b/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > @@ -43,15 +43,19 @@ enum {
> > > > > >
> > > > > >  int checkboard(void)
> > > > > >  {
> > > > > > +#ifndef CONFIG_QSPI_BOOT
> > > > > > char buf[64];
> > > > > >  #ifndef CONFIG_SD_BOOT
> > > > > > u8 sw;
> > > > > >  #endif
> > > > > > +#endif
> > > > > >
> > > > > > puts("Board: LS1043AQDS, boot from ");
> > > > > >
> > > > > >  #ifdef CONFIG_SD_BOOT
> > > > > > puts("SD\n");
> > > > > > +#elif defined(CONFIG_QSPI_BOOT)
> > > > > > +   puts("QSPI\n");
> > > > > >  #else
> > > > > > sw = QIXIS_READ(brdcfg[0]);
> > > > > > sw = (sw & QIXIS_LBMAP_MASK) >> QIXIS_LBMAP_SHIFT; @@
> > > > > > -68,12
> > > > > +72,15
> > > > > > @@ int checkboard(void)
> > > > > > printf("invalid setting of SW%u\n",
> QIXIS_LBMAP_SWITCH);
> > > > > #endif
> > > > > >
> > > > > > +#ifndef CONFIG_QSPI_BOOT
> > > > > > +   /* For QSPI boot, here I2C is not ready yet. */
> > > > > > printf("Sys ID: 0x%02x, Sys Ver: 0x%02x\n",
> > > > > >QIXIS_READ(id), QIXIS_READ(arch));
> > > > > >
> > > > > > printf("FPGA:  v%d (%s), build %d\n",
> > > > > >(int)QIXIS_READ(scver), qixis_read_tag(buf),
> > > > > >(int)qixis_read_minor());
> > > > > > +#endif
> > > > >
> > > > > Why isn't i2c ready?  How is DDR inited without it?
> > > > >
> > > > > -Scott
> > > >
> > > > Hi Scott,
> > > >
> > > > The calling sequence in U-Boot is :
> > > > checkboard() -> init_func_i2c() -> dram_init()
> > > >
> > > > So I2C is not ready in checkboard() but is ready for DDR initialization.
> > >
> > > Can you move the prints later in the boot sequence?
> > >
> > > In any case, the relevant variable is whether qixis uses i2c, not
> > > whether you're booting from qspi (even if they are correlated).
> > >
> > > -Scott
> >
> > Yes. Only with QSPI it needs I2C to access QIXIS.
> > But if defining CONFIG_DISPLAY_BOARDINFO_LATE, the print layout will
> > look really uncomfortable.. So we just comment out the FPGA prints for QSPI
> boo

Re: [U-Boot] [Patch V4 1/4] spi: fsl_qspi: fix compile warning for 64-bit platform

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Thursday, January 21, 2016 4:23 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: Mingkai Hu <mingkai...@nxp.com>; jt...@openedev.com; Yao Yuan
> <yao.y...@nxp.com>; r58...@freescale.com; Gong Qianyu
> <qianyu.g...@freescale.com>
> Subject: Re: [Patch V4 1/4] spi: fsl_qspi: fix compile warning for 64-bit 
> platform
> 
> On 01/19/2016 08:03 PM, Qianyu Gong wrote:
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Wednesday, January 20, 2016 2:42 AM
> >> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> >> Cc: Mingkai Hu <mingkai...@nxp.com>; jt...@openedev.com; Yao Yuan
> >> <yao.y...@nxp.com>; r58...@freescale.com; Gong Qianyu
> >> <qianyu.g...@freescale.com>
> >> Subject: Re: [Patch V4 1/4] spi: fsl_qspi: fix compile warning for
> >> 64-bit platform
> >>
> >> On 01/10/2016 06:14 PM, Gong Qianyu wrote:
> >>> From: Gong Qianyu <qianyu.g...@freescale.com>
> >>>
> >>> This patch fixes the following compile warning:
> >>> drivers/spi/fsl_qspi.c: In function 'fsl_qspi_probe':
> >>> drivers/spi/fsl_qspi.c:937:15:
> >>>   warning: cast to pointer from integer of different size
> >>>[-Wint-to-pointer-cast]
> >>>   priv->regs = (struct fsl_qspi_regs *)plat->reg_base;
> >>>^
> >>> Just make the cast explict.
> >>>
> >>> Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> >>> ---
> >>> V4:
> >>>  - Revise the commit message.
> >>> V2-V3:
> >>>  - No change.
> >>>
> >>>  drivers/spi/fsl_qspi.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> >>> feec3e8..9f23c10 100644
> >>> --- a/drivers/spi/fsl_qspi.c
> >>> +++ b/drivers/spi/fsl_qspi.c
> >>> @@ -936,7 +936,7 @@ static int fsl_qspi_probe(struct udevice *bus)
> >>>
> >>>   dm_spi_bus->max_hz = plat->speed_hz;
> >>>
> >>> - priv->regs = (struct fsl_qspi_regs *)plat->reg_base;
> >>
> >> The reg_base is u32. Is it always correct on 64-bit SoC?
> >>
> >
> > So far it's always a u32 type of CCSR address.
> >
> >>> + priv->regs = (struct fsl_qspi_regs *)(unsigned
> >>> +long)plat->reg_base;
> >>
> >> How about (struct fsl_qspi_regs *)(uintptr_t)plat->reg_base?
> >>
> >> York
> >>
> >
> > The size of ''unsigned long'' depends on compilers. It works well with GCC.
> >
> > Looks the same. But not sure what is defining CONFIG_USE_STDIN for.
> >
> > #ifdef CONFIG_USE_STDIN
> > /* Provided by gcc. */
> > #include 
> > #else
> > /* Type for `void *' pointers. */
> > typedef unsigned long int uintptr_t;
> > #endif
> >
> 
> uintptr_t is specifically defined for this type of use. You can grep it in 
> u-boot to see
> examples.
> 
> York
> 

Thanks! I've sent out a new version of the patch set.

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

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

[Qianyu Gong]

> -Original Message-
> From: york sun
> Sent: Wednesday, January 20, 2016 2:47 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: Mingkai Hu <mingkai...@nxp.com>; jt...@openedev.com; Yao Yuan
> <yao.y...@nxp.com>; r58...@freescale.com; Gong Qianyu
> <qianyu.g...@freescale.com>
> Subject: Re: [Patch V4 2/4] spi: fsl_qspi: Fix qspi_op_rdid memcpy issue
> 
> On 01/10/2016 06:15 PM, Gong Qianyu wrote:
> > From: Gong Qianyu <qianyu.g...@freescale.com>
> >
> > 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 <qianyu.g...@freescale.com>
> > ---
> > V2-V4:
> >  - 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
> > 9f23c10..4d58211 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);
> > rxbuf++;
> > size -= 4;
> > i++;
> >
> 
> Doesn't the line "size -= 4" need a fix as well? I guess it runs OK for 
> checking (size >
> 0), but it looks odd.
> 
> York

I paste the related code. It checks (size > 0) in the while loop:

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);
if (size < 4)
memcpy(rxbuf, , size);
else
memcpy(rxbuf, , 4);
rxbuf++;
size -= 4;
i++;
}
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V4 1/4] spi: fsl_qspi: fix compile warning for 64-bit platform

[Qianyu Gong]

> -Original Message-
> From: york sun
> Sent: Wednesday, January 20, 2016 2:42 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: Mingkai Hu <mingkai...@nxp.com>; jt...@openedev.com; Yao Yuan
> <yao.y...@nxp.com>; r58...@freescale.com; Gong Qianyu
> <qianyu.g...@freescale.com>
> Subject: Re: [Patch V4 1/4] spi: fsl_qspi: fix compile warning for 64-bit 
> platform
> 
> On 01/10/2016 06:14 PM, Gong Qianyu wrote:
> > From: Gong Qianyu <qianyu.g...@freescale.com>
> >
> > This patch fixes the following compile warning:
> > drivers/spi/fsl_qspi.c: In function 'fsl_qspi_probe':
> > drivers/spi/fsl_qspi.c:937:15:
> >   warning: cast to pointer from integer of different size
> >  [-Wint-to-pointer-cast]
> >   priv->regs = (struct fsl_qspi_regs *)plat->reg_base;
> >^
> > Just make the cast explict.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> > ---
> > V4:
> >  - Revise the commit message.
> > V2-V3:
> >  - No change.
> >
> >  drivers/spi/fsl_qspi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> > feec3e8..9f23c10 100644
> > --- a/drivers/spi/fsl_qspi.c
> > +++ b/drivers/spi/fsl_qspi.c
> > @@ -936,7 +936,7 @@ static int fsl_qspi_probe(struct udevice *bus)
> >
> > dm_spi_bus->max_hz = plat->speed_hz;
> >
> > -   priv->regs = (struct fsl_qspi_regs *)plat->reg_base;
> 
> The reg_base is u32. Is it always correct on 64-bit SoC?
> 

So far it's always a u32 type of CCSR address.

> > +   priv->regs = (struct fsl_qspi_regs *)(unsigned long)plat->reg_base;
> 
> How about (struct fsl_qspi_regs *)(uintptr_t)plat->reg_base?
> 
> York
> 

The size of ''unsigned long'' depends on compilers. It works well with GCC.

Looks the same. But not sure what is defining CONFIG_USE_STDIN for.

#ifdef CONFIG_USE_STDIN
/* Provided by gcc. */
#include 
#else
/* Type for `void *' pointers. */
typedef unsigned long int uintptr_t;
#endif


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

Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support

[Qianyu Gong]

> -Original Message-
> From: Calvin Johnson
> Sent: Tuesday, January 19, 2016 2:13 PM
> To: Qianyu Gong <qianyu.g...@nxp.com>; Scott Wood <o...@buserror.net>; u-
> b...@lists.denx.de
> Cc: b48...@freescale.com; Mingkai Hu <mingkai...@nxp.com>;
> wenbin.s...@freescale.com
> Subject: RE: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support
> 
> Hi Qianyu,
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Qianyu
> > Gong
> > Sent: Thursday, January 14, 2016 9:57 AM
> > To: Scott Wood <o...@buserror.net>; u-boot@lists.denx.de
> > Cc: b48...@freescale.com; Mingkai Hu <mingkai...@nxp.com>;
> > wenbin.s...@freescale.com
> > Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot
> > support
> >
> >
> > > -----Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Thursday, January 14, 2016 8:21 AM
> > > To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> > > Cc: b07...@freescale.com; b48...@freescale.com;
> > > wenbin.s...@freescale.com; Mingkai Hu <mingkai...@nxp.com>
> > > Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot
> > > support
> > >
> > > On Tue, 2016-01-12 at 03:14 +, Qianyu Gong wrote:
> > > > > -Original Message-
> > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > Sent: Tuesday, January 12, 2016 1:47 AM
> > > > > To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> > > > > Cc: b07...@freescale.com; b48...@freescale.com;
> > > > > wenbin.s...@freescale.com; Mingkai Hu <mingkai...@nxp.com>
> > > > > Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI
> > > > > boot support
> > > > >
> > > > > On Mon, 2016-01-11 at 10:17 +0800, Gong Qianyu wrote:
> > > > > > diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > b/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > index d6696ca..770b79f 100644
> > > > > > --- a/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > +++ b/board/freescale/ls1043aqds/ls1043aqds.c
> > > > > > @@ -43,15 +43,19 @@ enum {
> > > > > >
> > > > > >  int checkboard(void)
> > > > > >  {
> > > > > > +#ifndef CONFIG_QSPI_BOOT
> > > > > > char buf[64];
> > > > > >  #ifndef CONFIG_SD_BOOT
> > > > > > u8 sw;
> > > > > >  #endif
> > > > > > +#endif
> > > > > >
> > > > > > puts("Board: LS1043AQDS, boot from ");
> > > > > >
> > > > > >  #ifdef CONFIG_SD_BOOT
> > > > > > puts("SD\n");
> > > > > > +#elif defined(CONFIG_QSPI_BOOT)
> > > > > > +   puts("QSPI\n");
> > > > > >  #else
> > > > > > sw = QIXIS_READ(brdcfg[0]);
> > > > > > sw = (sw & QIXIS_LBMAP_MASK) >> QIXIS_LBMAP_SHIFT; @@
> > -68,12
> > > > > +72,15
> > > > > > @@ int checkboard(void)
> > > > > > printf("invalid setting of SW%u\n",
> > QIXIS_LBMAP_SWITCH);
> > > > > #endif
> > > > > >
> > > > > > +#ifndef CONFIG_QSPI_BOOT
> > > > > > +   /* For QSPI boot, here I2C is not ready yet. */
> > > > > > printf("Sys ID: 0x%02x, Sys Ver: 0x%02x\n",
> > > > > >QIXIS_READ(id), QIXIS_READ(arch));
> > > > > >
> > > > > > printf("FPGA:  v%d (%s), build %d\n",
> > > > > >(int)QIXIS_READ(scver), qixis_read_tag(buf),
> > > > > >(int)qixis_read_minor());
> > > > > > +#endif
> > > > >
> 
> It will be useful, if the above FPGA prints are available for QSPI boot as 
> well.
> 
Hi Calvin,

Yes, I know. But it's not easy to adjust the sequence of common code.
So I have to leave it alone.

Regards,
Qianyu

> > > > > Why isn't i2c ready?  How is DDR inited without it?
> > > > >
> > > > > -Scott
> > > >
> > > > Hi Scott,
> > > >
> > > > The calling sequence in U-Boot is :
> > > > checkboard() -> init_func_i2c() -> dram_init()
> > > >
> > > > So I2C is not ready in checkboard() but is ready for DDR initialization.
> > >
> > > Can you move the prints later in the boot sequence?
> > >
> > > In any case, the relevant variable is whether qixis uses i2c, not
> > > whether you're booting from qspi (even if they are correlated).
> > >
> > > -Scott
> >
> > Yes. Only with QSPI it needs I2C to access QIXIS.
> > But if defining CONFIG_DISPLAY_BOARDINFO_LATE, the print layout will
> > look really uncomfortable.. So we just comment out the FPGA prints for QSPI
> boot.
> >
> > Regards,
> > Qianyu
> 
> Thanks
> Calvin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support

[Qianyu Gong]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Thursday, January 14, 2016 8:21 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: b07...@freescale.com; b48...@freescale.com;
> wenbin.s...@freescale.com; Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support
> 
> On Tue, 2016-01-12 at 03:14 +, Qianyu Gong wrote:
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Tuesday, January 12, 2016 1:47 AM
> > > To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> > > Cc: b07...@freescale.com; b48...@freescale.com;
> > > wenbin.s...@freescale.com; Mingkai Hu <mingkai...@nxp.com>
> > > Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot
> > > support
> > >
> > > On Mon, 2016-01-11 at 10:17 +0800, Gong Qianyu wrote:
> > > > diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
> > > > b/board/freescale/ls1043aqds/ls1043aqds.c
> > > > index d6696ca..770b79f 100644
> > > > --- a/board/freescale/ls1043aqds/ls1043aqds.c
> > > > +++ b/board/freescale/ls1043aqds/ls1043aqds.c
> > > > @@ -43,15 +43,19 @@ enum {
> > > >
> > > >  int checkboard(void)
> > > >  {
> > > > +#ifndef CONFIG_QSPI_BOOT
> > > > char buf[64];
> > > >  #ifndef CONFIG_SD_BOOT
> > > > u8 sw;
> > > >  #endif
> > > > +#endif
> > > >
> > > > puts("Board: LS1043AQDS, boot from ");
> > > >
> > > >  #ifdef CONFIG_SD_BOOT
> > > > puts("SD\n");
> > > > +#elif defined(CONFIG_QSPI_BOOT)
> > > > +   puts("QSPI\n");
> > > >  #else
> > > > sw = QIXIS_READ(brdcfg[0]);
> > > > sw = (sw & QIXIS_LBMAP_MASK) >> QIXIS_LBMAP_SHIFT; @@ -68,12
> > > +72,15
> > > > @@ int checkboard(void)
> > > > printf("invalid setting of SW%u\n", QIXIS_LBMAP_SWITCH);
> > > #endif
> > > >
> > > > +#ifndef CONFIG_QSPI_BOOT
> > > > +   /* For QSPI boot, here I2C is not ready yet. */
> > > > printf("Sys ID: 0x%02x, Sys Ver: 0x%02x\n",
> > > >QIXIS_READ(id), QIXIS_READ(arch));
> > > >
> > > > printf("FPGA:  v%d (%s), build %d\n",
> > > >(int)QIXIS_READ(scver), qixis_read_tag(buf),
> > > >(int)qixis_read_minor());
> > > > +#endif
> > >
> > > Why isn't i2c ready?  How is DDR inited without it?
> > >
> > > -Scott
> >
> > Hi Scott,
> >
> > The calling sequence in U-Boot is :
> > checkboard() -> init_func_i2c() -> dram_init()
> >
> > So I2C is not ready in checkboard() but is ready for DDR initialization.
> 
> Can you move the prints later in the boot sequence?
> 
> In any case, the relevant variable is whether qixis uses i2c, not whether 
> you're
> booting from qspi (even if they are correlated).
> 
> -Scott

Yes. Only with QSPI it needs I2C to access QIXIS. 
But if defining CONFIG_DISPLAY_BOARDINFO_LATE, the print layout will look
really uncomfortable.. So we just comment out the FPGA prints for QSPI boot.

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

Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support

[Qianyu Gong]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Tuesday, January 12, 2016 1:47 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: b07...@freescale.com; b48...@freescale.com;
> wenbin.s...@freescale.com; Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [Patch V3 3/3] armv8/ls1043aqds: add QSPI boot support
> 
> On Mon, 2016-01-11 at 10:17 +0800, Gong Qianyu wrote:
> > diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
> > b/board/freescale/ls1043aqds/ls1043aqds.c
> > index d6696ca..770b79f 100644
> > --- a/board/freescale/ls1043aqds/ls1043aqds.c
> > +++ b/board/freescale/ls1043aqds/ls1043aqds.c
> > @@ -43,15 +43,19 @@ enum {
> >
> >  int checkboard(void)
> >  {
> > +#ifndef CONFIG_QSPI_BOOT
> > char buf[64];
> >  #ifndef CONFIG_SD_BOOT
> > u8 sw;
> >  #endif
> > +#endif
> >
> > puts("Board: LS1043AQDS, boot from ");
> >
> >  #ifdef CONFIG_SD_BOOT
> > puts("SD\n");
> > +#elif defined(CONFIG_QSPI_BOOT)
> > +   puts("QSPI\n");
> >  #else
> > sw = QIXIS_READ(brdcfg[0]);
> > sw = (sw & QIXIS_LBMAP_MASK) >> QIXIS_LBMAP_SHIFT; @@ -68,12
> +72,15
> > @@ int checkboard(void)
> > printf("invalid setting of SW%u\n", QIXIS_LBMAP_SWITCH);
> #endif
> >
> > +#ifndef CONFIG_QSPI_BOOT
> > +   /* For QSPI boot, here I2C is not ready yet. */
> > printf("Sys ID: 0x%02x, Sys Ver: 0x%02x\n",
> >QIXIS_READ(id), QIXIS_READ(arch));
> >
> > printf("FPGA:  v%d (%s), build %d\n",
> >(int)QIXIS_READ(scver), qixis_read_tag(buf),
> >(int)qixis_read_minor());
> > +#endif
> 
> Why isn't i2c ready?  How is DDR inited without it?
> 
> -Scott

Hi Scott,

The calling sequence in U-Boot is :
checkboard() -> init_func_i2c() -> dram_init()

So I2C is not ready in checkboard() but is ready for DDR initialization.

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

Re: [U-Boot] [Patch V3 4/4] dm: env_sf: fix saveenv() to use driver model

[Qianyu Gong]

> -Original Message-
> From: Jagan Teki [mailto:jt...@openedev.com]
> Sent: Saturday, January 09, 2016 1:07 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>
> Cc: u-boot@lists.denx.de; Gong Qianyu <qianyu.g...@freescale.com>; Yao Yuan
> <yao.y...@nxp.com>; Mingkai Hu <mingkai...@nxp.com>
> Subject: Re: [U-Boot] [Patch V3 4/4] dm: env_sf: fix saveenv() to use driver 
> model
> 
> On 8 January 2016 at 12:57, Gong Qianyu <qianyu.g...@nxp.com> wrote:
> > From: Gong Qianyu <qianyu.g...@freescale.com>
> >
> > It might be missed when converting spi_flash_probe() in cmd_sf.c.
> >
> > This commit refers to fbb099183e3a53f77a975964cdf2e73d11e565af.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> > ---
> > V3:
> >  - Remove redundant operations for saveenv()
> > V2:
> >  - New patch.
> >
> >  common/env_sf.c | 35 +++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/common/env_sf.c b/common/env_sf.c index 9409831..fd0c82a
> > 100644
> > --- a/common/env_sf.c
> > +++ b/common/env_sf.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #ifndef CONFIG_ENV_SPI_BUS
> >  # define CONFIG_ENV_SPI_BUS0
> > @@ -51,6 +52,22 @@ int saveenv(void)
> > char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
> > u32 saved_size, saved_offset, sector = 1;
> > int ret;
> > +#ifdef CONFIG_DM_SPI_FLASH
> > +   struct udevice *new;
> > +   unsigned int bus = CONFIG_SF_DEFAULT_BUS;
> > +   unsigned int cs = CONFIG_SF_DEFAULT_CS;
> > +   unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
> > +   unsigned int mode = CONFIG_SF_DEFAULT_MODE;
> 
> non-dm uses CONFIG_ENV_ *  may be we can use the same?
> 

Yes, you're right.

> > +
> > +   ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
> 
> Call the macros directly instead of assigning with variables since there is no
> updates on these further.
> 

There is really a problem to match it with non-dm code.
I will also adjust the printf format below.

Qianyu

> > +   if (ret) {
> > +   printf("Failed to initialize SPI flash at %u:%u (error 
> > %d)\n",
> > +  bus, cs, ret);
> > +   return 1;
> > +   }
> > +
> > +   env_flash = dev_get_uclass_priv(new); #else
> >
> > if (!env_flash) {
> > env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> > @@ -61,6 +78,7 @@ int saveenv(void)
> > return 1;
> > }
> > }
> > +#endif
> >
> > ret = env_export(_new);
> > if (ret)
> > @@ -227,6 +245,22 @@ int saveenv(void)
> > char*saved_buffer = NULL;
> > int ret = 1;
> > env_t   env_new;
> > +#ifdef CONFIG_DM_SPI_FLASH
> > +   struct udevice *new;
> > +   unsigned int bus = CONFIG_SF_DEFAULT_BUS;
> > +   unsigned int cs = CONFIG_SF_DEFAULT_CS;
> > +   unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
> > +   unsigned int mode = CONFIG_SF_DEFAULT_MODE;
> > +
> > +   ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
> > +   if (ret) {
> > +   printf("Failed to initialize SPI flash at %u:%u (error 
> > %d)\n",
> > +  bus, cs, ret);
> > +   return 1;
> > +   }
> > +
> > +   env_flash = dev_get_uclass_priv(new); #else
> >
> > if (!env_flash) {
> > env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> > @@ -237,6 +271,7 @@ int saveenv(void)
> > return 1;
> > }
> > }
> > +#endif
> >
> > /* Is the sector larger than the env (i.e. embedded) */
> > if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
> > --
> > 2.1.0.27.g96db324
> >
> 
> --
> Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model

[Qianyu Gong]

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Friday, January 08, 2016 11:34 AM
> To: Gong Qianyu 
> Cc: U-Boot Mailing List ; Mingkai Hu
> ; r58...@freescale.com; yao.y...@freescale.com;
> Jagan Teki 
> Subject: Re: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model
> 
> Hi,
> 
> On 15 December 2015 at 03:32, Gong Qianyu 
> wrote:
> > It might be missed when converting spi_flash_probe() in cmd_sf.c.
> >
> > This commit refers to fbb099183e3a53f77a975964cdf2e73d11e565af.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> > V2:
> >  - New Patch.
> >
> >  common/env_sf.c | 49
> > +
> >  1 file changed, 49 insertions(+)
> >
> > diff --git a/common/env_sf.c b/common/env_sf.c index 9409831..31d96a7
> > 100644
> > --- a/common/env_sf.c
> > +++ b/common/env_sf.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #ifndef CONFIG_ENV_SPI_BUS
> >  # define CONFIG_ENV_SPI_BUS0
> > @@ -51,6 +52,29 @@ int saveenv(void)
> > char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
> > u32 saved_size, saved_offset, sector = 1;
> > int ret;
> > +#ifdef CONFIG_DM_SPI_FLASH
> > +   struct udevice *new, *bus_dev;
> > +   unsigned int bus = CONFIG_SF_DEFAULT_BUS;
> > +   unsigned int cs = CONFIG_SF_DEFAULT_CS;
> > +   unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
> > +   unsigned int mode = CONFIG_SF_DEFAULT_MODE;
> > +
> > +   /* Remove the old device, otherwise probe will just be a nop */
> > +   ret = spi_find_bus_and_cs(bus, cs, _dev, );
> > +   if (!ret) {
> > +   device_remove(new);
> > +   device_unbind(new);
> > +   }
> > +   env_flash = NULL;
> 
> You should be abve to avoid the above code and just have the code below:
> 
> > +   ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
> > +   if (ret) {
> > +   printf("Failed to initialize SPI flash at %u:%u (error 
> > %d)\n",
> > +  bus, cs, ret);
> > +   return 1;
> > +   }
> > +
> > +   env_flash = dev_get_uclass_priv(new);
> 
> The reason why 'sf probe' removes the old device is to ensure that it is 
> probed
> again, in case something has changed. Even that is suspect, but in the env 
> case it
> seems plain wrong.
> 
> However, you must always do this with driver model. Even if env_flash is non-
> NULL, you must get it again (with driver model).
> 
Hi Simon,

Ok, I see. Thanks for the explanation. 
I'll send a new version of it then.

Regards,
Qianyu

> > +#else
> >
> > if (!env_flash) {
> > env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> > @@ -61,6 +85,7 @@ int saveenv(void)
> > return 1;
> > }
> > }
> > +#endif
> >
> > ret = env_export(_new);
> > if (ret)
> > @@ -227,6 +252,29 @@ int saveenv(void)
> > char*saved_buffer = NULL;
> > int ret = 1;
> > env_t   env_new;
> > +#ifdef CONFIG_DM_SPI_FLASH
> > +   struct udevice *new, *bus_dev;
> > +   unsigned int bus = CONFIG_SF_DEFAULT_BUS;
> > +   unsigned int cs = CONFIG_SF_DEFAULT_CS;
> > +   unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
> > +   unsigned int mode = CONFIG_SF_DEFAULT_MODE;
> > +
> > +   /* Remove the old device, otherwise probe will just be a nop */
> > +   ret = spi_find_bus_and_cs(bus, cs, _dev, );
> > +   if (!ret) {
> > +   device_remove(new);
> > +   device_unbind(new);
> > +   }
> > +   env_flash = NULL;
> > +   ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
> > +   if (ret) {
> > +   printf("Failed to initialize SPI flash at %u:%u (error 
> > %d)\n",
> > +  bus, cs, ret);
> > +   return 1;
> > +   }
> > +
> > +   env_flash = dev_get_uclass_priv(new); #else
> >
> > if (!env_flash) {
> > env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> > @@ -237,6 +285,7 @@ int saveenv(void)
> > return 1;
> > }
> > }
> > +#endif
> >
> > /* Is the sector larger than the env (i.e. embedded) */
> > if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
> > --
> > 2.1.0.27.g96db324
> >
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model

[Qianyu Gong]

Hi Jagan and Simon,

Do you have any comments on the patch set? 
Or could you please help to merge them? Thank you.

Regards,
Qianyu

> -Original Message-
> From: Qianyu Gong
> Sent: Monday, December 21, 2015 2:01 PM
> To: Simon Glass <s...@chromium.org>
> Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Mingkai Hu
> <mingkai...@freescale.com>; r58...@freescale.com; yao.y...@freescale.com;
> Jagan Teki <jt...@openedev.com>
> Subject: RE: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model
> 
> 
> 
> > -Original Message-
> > From: Qianyu Gong
> > Sent: Monday, December 21, 2015 1:25 PM
> > To: 'Simon Glass'; Gong Qianyu
> > Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> > yao.y...@freescale.com; Jagan Teki
> > Subject: RE: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver
> > model
> >
> >
> >
> > > -Original Message-
> > > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon
> > > Glass
> > > Sent: Saturday, December 19, 2015 10:51 AM
> > > To: Gong Qianyu
> > > Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> > > yao.y...@freescale.com; Jagan Teki
> > > Subject: Re: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver
> > > model
> > >
> > > Hi Gong,
> > >
> > > On 15 December 2015 at 03:32, Gong Qianyu
> > > <qianyu.g...@freescale.com>
> > > wrote:
> > > >
> > > > It might be missed when converting spi_flash_probe() in cmd_sf.c.
> > > >
> > > > This commit refers to fbb099183e3a53f77a975964cdf2e73d11e565af.
> > > >
> > > > Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> > > > ---
> > > > V2:
> > > >  - New Patch.
> > > >
> > > >  common/env_sf.c | 49
> > > > +
> > > >  1 file changed, 49 insertions(+)
> > >
> > > The 'saveenv' command seems to work OK for me with driver model. Can
> > > you please explain what problem this patch solves?
> > >
> > > Regards,
> > > Simon
> >
> > Hi Simon,
> >
> > The saveenv() always keeps the latest 'sf probe' value of env_flash.
> > So if I run 'sf probe'
> > a few more times till it returns a different value, saveenv() will
> > then get into sync abort.
> >
> > Actually the problem I met is:
> > => saveenv
> > Saving Environment to SPI Flash...
> > SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64
> > KiB, total 16MiB Erasing SPI flash...Writing to SPI flash...done => sf
> > probe
> > SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64
> > KiB, total 16MiB => saveenv Saving Environment to SPI Flash...
> > "Synchronous Abort" handler, esr 0x0200
> > ELR: fffa8520
> > LR:  fff6fd28
> > x0 : ffe44850 x1 : 00102000
> > x2 : e000 x3 : ffe6a670
> > x4 : fffa8520 x5 : fffa89c0
> > x6 : fffa8340 x7 : 0053
> > x8 :  x9 : 000c
> > x10: ffe6a660 x11: fff9
> > x12: 000f x13: 4000
> > x14: 0020 x15: fff490d0
> > x16: fff4984c x17: 0064
> > x18: ffe43da0 x19: fffb7000
> > x20: ffe6a670 x21: fffb7000
> > x22: fffb7000 x23: 0001
> > x24: fffb6db0 x25: 
> > x26:  x27: 
> > x28:  x29: ffe3f4d0
> >
> > Resetting CPU ...
> >
> > resetting ...
> >
> >
> 
> This patch makes 'saveenv' probes the flash every time like 'sf probe'. Maybe 
> there
> is a better way to solve this. I'm also confused why the current 'sf probe' 
> may
> return different values for the same SPI flash(the same cs and bus)..Isn't it 
> freed
> cleanly?
> 
> Regards,
> Qianyu

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

Re: [U-Boot] [Patch V3] i2c: mxc: add a condition in case the parameter is NULL

[Qianyu Gong]

Hi Stefano,

Could you please help to merge this patch? Thanks very much.

Regards,
Qianyu

> -Original Message-
> From: Qianyu Gong
> Sent: Monday, December 21, 2015 1:42 PM
> To: h...@denx.de; Gong Qianyu-B52263 <qianyu.g...@freescale.com>
> Cc: u-boot@lists.denx.de; Stefano Babic <sba...@denx.de>
> Subject: RE: [U-Boot] [Patch V3] i2c: mxc: add a condition in case the 
> parameter is
> NULL
> 
> 
> 
> > -Original Message-
> > From: Heiko Schocher [mailto:h...@denx.de]
> > Sent: Friday, December 18, 2015 6:24 PM
> > To: Gong Qianyu-B52263
> > Cc: u-boot@lists.denx.de; Stefano Babic
> > Subject: Re: [U-Boot] [Patch V3] i2c: mxc: add a condition in case the
> > parameter is NULL
> >
> > Hello Gong Qianyu,
> >
> > added Stefano Babic to cc as he is the imx maintainer.
> >
> > Am 18.12.2015 um 10:38 schrieb Gong Qianyu:
> > > This could avoid executing the code that only applies to i.MX platforms.
> > >
> > > The bus_i2c_init() is called before relocation and will assgin value
> > > to a static variable. If U-Boot is then still running in a flash
> > > device, it's theoretically not allowed to write data to flash
> > > without an erasing operation. For i.MX platforms, the U-Boot is
> > > always running in DDR.
> > >
> > > Actually it causes asynchronous error when the ARM64 system error
> > > report is enabled and the flash write protect is set.
> > >
> > > Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> > > ---
> > > V3:
> > >   - Sorry..Remove an unrelated line in other file.
> > >
> > >   drivers/i2c/mxc_i2c.c | 12 ++--
> > >   1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > Ok, from my side, but it would be better to switch your board(s) to
> > support DM and get rid of this old stuff from this driver.
> >
> > Reviewed-by: Heiko Schocher <h...@denx.de>
> >
> > bye,
> > Heiko
> 
> Thanks. But I have no control over this driver. Maybe they are considering to
> convert it later.
> 
> Regards,
> Qianyu
> 
> > >
> > > diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index
> > > fa4c82f..b2d15c9 100644
> > > --- a/drivers/i2c/mxc_i2c.c
> > > +++ b/drivers/i2c/mxc_i2c.c
> > > @@ -581,8 +581,16 @@ void bus_i2c_init(int index, int speed, int unused,
> > >   return;
> > >   }
> > >
> > > - mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn;
> > > - mxc_i2c_buses[index].idle_bus_data = idle_bus_data;
> > > + /*
> > > +  * Warning: Be careful to allow the assignment to a static
> > > +  * variable here. This function could be called while U-Boot is
> > > +  * still running in flash memory. So such assignment is equal
> > > +  * to write data to flash without erasing.
> > > +  */
> > > + if (idle_bus_fn)
> > > + mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn;
> > > + if (idle_bus_data)
> > > + mxc_i2c_buses[index].idle_bus_data = idle_bus_data;
> > >
> > >   ret = enable_i2c_clk(1, index);
> > >   if (ret < 0) {
> > >
> >
> > --
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] armv8/ls1043aqds: add QSPI support in SD boot

[Qianyu Gong]

> -Original Message-
> From: Scott Wood [mailto:scottw...@freescale.com]
> Sent: Tuesday, December 29, 2015 5:52 AM
> To: Qianyu Gong <qianyu.g...@nxp.com>; u-boot@lists.denx.de
> Cc: Mingkai Hu <mingkai...@nxp.com>; r58...@freescale.com;
> b48...@freescale.com; shaohui@freescale.com;
> wenbin.s...@freescale.com; b07...@freescale.com; Gong Qianyu
> <qianyu.g...@freescale.com>
> Subject: Re: [PATCH 2/3] armv8/ls1043aqds: add QSPI support in SD boot
> 
> On Thu, 2015-12-24 at 16:40 +0800, Gong Qianyu wrote:
> > From: Gong Qianyu <qianyu.g...@freescale.com>
> >
> > QSPI and IFC are pin-multiplexed on LS1043A. So we use
> > ls1043aqds_sdcard_ifc_defconfig to support IFC in SD boot and
> > ls1043aqds_sdcard_qspi_defconfig to support QSPI in SD boot. If QSPI
> > is enabled, IFC should be disabled in kernel as well.
> >
> > Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> > Signed-off-by: Gong Qianyu <qianyu.g...@nxp.com>
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/fdt.c|  5 +
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  3 +++
> >  arch/arm/dts/fsl-ls1043a-qds.dts   | 14 +
> >  arch/arm/dts/fsl-ls1043a.dtsi  | 11 +++
> >  board/freescale/ls1043aqds/MAINTAINERS |  1 +
> >  .../ls1043aqds/ls1043aqds_rcw_sd_qspi.cfg  |  8 
> >  configs/ls1043aqds_sdcard_qspi_defconfig   | 10 ++
> >  include/configs/ls1043a_common.h   | 13 
> >  include/configs/ls1043aqds.h   | 23
> > ++
> >  9 files changed, 88 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index eafdd71..a247510 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -201,4 +201,9 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > CONFIG_FSL_LSCH3
> > fdt_fixup_smmu(blob);
> >  #endif
> > +
> > +#ifdef CONFIG_FSL_QSPI
> > +   do_fixup_by_compat(blob, "fsl,ifc",
> > +  "status", "disabled", 8 + 1, 1); #endif
> 
> This needs to only happen on LS1043A (and any other chips that have the same
> muxing).
> 
Hi Scott,

Yes, LS1046A and LS1088A also have the same muxing and it's only different on 
LS2085A.
Or we can just remove this fixup in U-Boot and make kernel deal with it 
respectively.
Which do you prefer?

> >  }
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index 23d6b73..4b1f792 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -219,6 +219,9 @@ void fsl_lsch2_early_init_f(void)
> > init_early_memctl_regs();   /* tighten IFC timing */
> >  #endif
> >
> > +#ifdef CONFIG_FSL_QSPI
> > +   out_be32(>qspi_cfg, SCFG_QSPI_CLKSEL); #endif
> 
> Likewise.
> 
> -Scott

fsl_lsch2_early_init_f() isn't called on LS2085A. 
I think currently it's ok with known chips.

Regards,
Qianyu

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

Re: [U-Boot] [Patch V3] i2c: mxc: add a condition in case the parameter is NULL

[Qianyu Gong]

> -Original Message-
> From: Heiko Schocher [mailto:h...@denx.de]
> Sent: Friday, December 18, 2015 6:24 PM
> To: Gong Qianyu-B52263
> Cc: u-boot@lists.denx.de; Stefano Babic
> Subject: Re: [U-Boot] [Patch V3] i2c: mxc: add a condition in case the
> parameter is NULL
> 
> Hello Gong Qianyu,
> 
> added Stefano Babic to cc as he is the imx maintainer.
> 
> Am 18.12.2015 um 10:38 schrieb Gong Qianyu:
> > This could avoid executing the code that only applies to i.MX platforms.
> >
> > The bus_i2c_init() is called before relocation and will assgin value
> > to a static variable. If U-Boot is then still running in a flash
> > device, it's theoretically not allowed to write data to flash without
> > an erasing operation. For i.MX platforms, the U-Boot is always running
> > in DDR.
> >
> > Actually it causes asynchronous error when the ARM64 system error
> > report is enabled and the flash write protect is set.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> > V3:
> >   - Sorry..Remove an unrelated line in other file.
> >
> >   drivers/i2c/mxc_i2c.c | 12 ++--
> >   1 file changed, 10 insertions(+), 2 deletions(-)
> 
> Ok, from my side, but it would be better to switch your board(s) to
> support DM and get rid of this old stuff from this driver.
> 
> Reviewed-by: Heiko Schocher 
> 
> bye,
> Heiko

Thanks. But I have no control over this driver. Maybe they are considering to 
convert it later.

Regards,
Qianyu

> >
> > diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index
> > fa4c82f..b2d15c9 100644
> > --- a/drivers/i2c/mxc_i2c.c
> > +++ b/drivers/i2c/mxc_i2c.c
> > @@ -581,8 +581,16 @@ void bus_i2c_init(int index, int speed, int unused,
> > return;
> > }
> >
> > -   mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn;
> > -   mxc_i2c_buses[index].idle_bus_data = idle_bus_data;
> > +   /*
> > +* Warning: Be careful to allow the assignment to a static
> > +* variable here. This function could be called while U-Boot is
> > +* still running in flash memory. So such assignment is equal
> > +* to write data to flash without erasing.
> > +*/
> > +   if (idle_bus_fn)
> > +   mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn;
> > +   if (idle_bus_data)
> > +   mxc_i2c_buses[index].idle_bus_data = idle_bus_data;
> >
> > ret = enable_i2c_clk(1, index);
> > if (ret < 0) {
> >
> 
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model

[Qianyu Gong]

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Saturday, December 19, 2015 10:51 AM
> To: Gong Qianyu
> Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> yao.y...@freescale.com; Jagan Teki
> Subject: Re: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model
> 
> Hi Gong,
> 
> On 15 December 2015 at 03:32, Gong Qianyu 
> wrote:
> >
> > It might be missed when converting spi_flash_probe() in cmd_sf.c.
> >
> > This commit refers to fbb099183e3a53f77a975964cdf2e73d11e565af.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> > V2:
> >  - New Patch.
> >
> >  common/env_sf.c | 49
> > +
> >  1 file changed, 49 insertions(+)
> 
> The 'saveenv' command seems to work OK for me with driver model. Can you
> please explain what problem this patch solves?
> 
> Regards,
> Simon

Hi Simon,

The saveenv() always keeps the latest 'sf probe' value of env_flash. So if I 
run 'sf probe' 
a few more times till it returns a different value, saveenv() will then get 
into sync abort.

Actually the problem I met is:
=> saveenv
Saving Environment to SPI Flash...
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 
16MiB
Erasing SPI flash...Writing to SPI flash...done
=> sf probe
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 
16MiB
=> saveenv
Saving Environment to SPI Flash...
"Synchronous Abort" handler, esr 0x0200
ELR: fffa8520
LR:  fff6fd28
x0 : ffe44850 x1 : 00102000
x2 : e000 x3 : ffe6a670
x4 : fffa8520 x5 : fffa89c0
x6 : fffa8340 x7 : 0053
x8 :  x9 : 000c
x10: ffe6a660 x11: fff9
x12: 000f x13: 4000
x14: 0020 x15: fff490d0
x16: fff4984c x17: 0064
x18: ffe43da0 x19: fffb7000
x20: ffe6a670 x21: fffb7000
x22: fffb7000 x23: 0001
x24: fffb6db0 x25: 
x26:  x27: 
x28:  x29: ffe3f4d0

Resetting CPU ...

resetting ...



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

Re: [U-Boot] [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model

[Qianyu Gong]

> -Original Message-
> From: Qianyu Gong
> Sent: Monday, December 21, 2015 1:25 PM
> To: 'Simon Glass'; Gong Qianyu
> Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> yao.y...@freescale.com; Jagan Teki
> Subject: RE: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model
> 
> 
> 
> > -Original Message-
> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> > Sent: Saturday, December 19, 2015 10:51 AM
> > To: Gong Qianyu
> > Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> > yao.y...@freescale.com; Jagan Teki
> > Subject: Re: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver
> > model
> >
> > Hi Gong,
> >
> > On 15 December 2015 at 03:32, Gong Qianyu <qianyu.g...@freescale.com>
> > wrote:
> > >
> > > It might be missed when converting spi_flash_probe() in cmd_sf.c.
> > >
> > > This commit refers to fbb099183e3a53f77a975964cdf2e73d11e565af.
> > >
> > > Signed-off-by: Gong Qianyu <qianyu.g...@freescale.com>
> > > ---
> > > V2:
> > >  - New Patch.
> > >
> > >  common/env_sf.c | 49
> > > +
> > >  1 file changed, 49 insertions(+)
> >
> > The 'saveenv' command seems to work OK for me with driver model. Can
> > you please explain what problem this patch solves?
> >
> > Regards,
> > Simon
> 
> Hi Simon,
> 
> The saveenv() always keeps the latest 'sf probe' value of env_flash. So
> if I run 'sf probe'
> a few more times till it returns a different value, saveenv() will then
> get into sync abort.
> 
> Actually the problem I met is:
> => saveenv
> Saving Environment to SPI Flash...
> SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB,
> total 16MiB Erasing SPI flash...Writing to SPI flash...done => sf probe
> SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB,
> total 16MiB => saveenv Saving Environment to SPI Flash...
> "Synchronous Abort" handler, esr 0x0200
> ELR: fffa8520
> LR:  fff6fd28
> x0 : ffe44850 x1 : 00102000
> x2 : e000 x3 : ffe6a670
> x4 : fffa8520 x5 : fffa89c0
> x6 : fffa8340 x7 : 0053
> x8 :  x9 : 000c
> x10: ffe6a660 x11: fff9
> x12: 000f x13: 4000
> x14: 0020 x15: fff490d0
> x16: fff4984c x17: 0064
> x18: ffe43da0 x19: fffb7000
> x20: ffe6a670 x21: fffb7000
> x22: fffb7000 x23: 0001
> x24: fffb6db0 x25: 
> x26:  x27: 
> x28:  x29: ffe3f4d0
> 
> Resetting CPU ...
> 
> resetting ...
> 
> 

This patch makes 'saveenv' probes the flash every time like 'sf probe'. Maybe 
there is a better way
to solve this. I'm also confused why the current 'sf probe' may return 
different 
values for the same SPI flash(the same cs and bus)..Isn't it freed cleanly?

Regards,
Qianyu

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