Re: [U-Boot] [PATCH v2 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED

[See, Chin Liang]

On Tue, 2019-06-04 at 07:13 +0200, Simon Goldschmidt wrote:
> On Tue, Jun 4, 2019 at 1:57 AM Dalon Westergreen
>  wrote:
> > 
> > 
> > From: Dalon Westergreen 
> > 
> > CONFIG_OF_EMBED was primarily enabled to support the stratix10
> > spl hex file requirements.  Since this option now produces a
> > warning during build, and the spl hex can be created using
> > alternate methods, CONFIG_OF_EMBED is no longer needed.
> > 
> > Signed-off-by: Dalon Westergreen 
> > 
> > ---
> > Changes in v2:
> >  -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex
> > ---
> >  configs/socfpga_stratix10_defconfig   | 1 -
> >  include/configs/socfpga_stratix10_socdk.h | 2 +-
> >  2 files changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/configs/socfpga_stratix10_defconfig
> > b/configs/socfpga_stratix10_defconfig
> > index fbab388b43..f27180385d 100644
> > --- a/configs/socfpga_stratix10_defconfig
> > +++ b/configs/socfpga_stratix10_defconfig
> > @@ -26,7 +26,6 @@ CONFIG_CMD_CACHE=y
> >  CONFIG_CMD_EXT4=y
> >  CONFIG_CMD_FAT=y
> >  CONFIG_CMD_FS_GENERIC=y
> > -CONFIG_OF_EMBED=y
> >  CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk"
> >  CONFIG_ENV_IS_IN_MMC=y
> >  CONFIG_NET_RANDOM_ETHADDR=y
> > diff --git a/include/configs/socfpga_stratix10_socdk.h
> > b/include/configs/socfpga_stratix10_socdk.h
> > index 39d757d737..66855ff0d8 100644
> > --- a/include/configs/socfpga_stratix10_socdk.h
> > +++ b/include/configs/socfpga_stratix10_socdk.h
> > @@ -210,6 +210,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
> > 
> >  /* SPL SDMMC boot support */
> >  #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
> > -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-
> > boot.img"
> > +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-
> > dtb.img"
> Is that really necessary? I don't have the aarch64 compiler at hand,
> but when compiling a gen5 board, "u-boot.img" and "u-boot-dtb.img"
> are the same. Changing to "u-boot-dtb.img" here only complicates
> things for the user, I think.

I would agree with Dalon since we want to make sure we use same name as
socfpga_common.h, which is for CV, A10 SoCs. This would help to
standardize our internal test infra.

Thanks
Chin Liang

> 
> Regards,
> Simon
> 
> > 
> > 
> >  #endif /* __CONFIG_H */
> > --
> > 2.21.0
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[See, Chin Liang]

On Mon, 2019-04-29 at 10:34 +0200, Marek Vasut wrote:
> On 4/26/19 8:39 AM, Simon Goldschmidt wrote:
> > 
> > On Tue, Apr 23, 2019 at 6:14 PM Marek Vasut  wrote:
> > > 
> > > 
> > > The usage of socfpga_sdram_apply_static_cfg() seems rather
> > > dubious and
> > > is confirmed to lead to a rare system hang when enabling bridges.
> > > This
> > > patch removes the socfpga_sdram_apply_static_cfg() altogether,
> > > because
> > > it's use seems unjustified and problematic.
> > > 
> > > The socfpga_sdram_apply_static_cfg() triggers write to SDRAM
> > > staticcfg
> > > register to set the applycfg bit, which according to old vendor
> > > U-Boot
> > > sources can only be written when there is no traffic between the
> > > SDRAM
> > > controller and the rest of the system. Empirical measurements
> > > confirm
> > > this, setting the applycfg bit when there is traffic between the
> > > SDRAM
> > > controller and CPU leads to the SDRAM controller accesses being
> > > blocked
> > > shortly after.
> > > 
> > > Altera originally solved this by moving the entire code which
> > > sets the
> > > staticcfg register to OCRAM [1]. The commit message claims that
> > > the
> > > applycfg bit needs to be set after write to fpgaportrst register.
> > > This
> > > is however inverted by Altera shortly after in [2], where the
> > > order
> > > becomes the exact opposite of what commit message [1] claims to
> > > be the
> > > required order. The explanation points to a possible problem in
> > > AMP
> > > use-case, where the FPGA might be sending transactions through
> > > the F2S
> > > bridge.
> > > 
> > > However, the AMP is only the tip of the iceberg here. Any of the
> > > other
> > > L2, L3 or L4 masters can trigger transactions to the SDRAM. It
> > > becomes
> > > rather non-trivial to guarantee there are no transactions to the
> > > SDRAM
> > > controller.
> > > 
> > > The SoCFPGA SDRAM driver always writes the applycfg bit in SPL.
> > > Thus,
> > > writing the applycfg again in bridge enable code seems redundant
> > > and
> > > can presumably be dropped.
> > > 
> > > [1] https://github.com/altera-opensource/u-boot-socfpga/commit/75
> > > 905816ec95b0ccd515700b922628d7aa9036f8
> > > [2] https://github.com/altera-opensource/u-boot-socfpga/commit/8b
> > > a6986b04a91d23c7adf529186b34c8d2967ad5
> > > 
> > > Signed-off-by: Marek Vasut 
> > > Cc: Chin Liang See 
> > > Cc: Dinh Nguyen 
> > > Cc: Simon Goldschmidt 
> > > Cc: Tien Fong Chee 
> > Good catch!
> > 
> > Reviewed-by: Simon Goldschmidt 
> I am still hoping that Chin might jump in and explain the discrepancy
> between those two patches in Altera U-Boot fork I linked above.
> 

Hi Marek,

We still need the sdram_apply_static_cfg to ensure correct fpga2sdram
port is enabled, based on the new FPGA designs. https://www.intel.com/c
ontent/www/us/en/programmable/hps/cyclone-
v/hps.html#topic/sfo1411577376106.html

For the AMP, I checked back the fogbugz case and the correct term
should be multi-core. In our test scenario, we use a NIOS II on FPGA to
pump transaction to FPGA2SDRAM continuously. It failed with original
code when FPGA config take place and that's why patch [2] needed.

At same time, U-Boot run in serial manner. Hence we expect all L3 or L4
masters are idle during that time. As example, tftp or fatload from
SDMMC shall be complete before next U-Boot console instruction such as
"fpga load" can take place.

Hope this explains.

Thanks
Chin Liang



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

Re: [U-Boot] [PATCH] ARM: socfpga: Assure correct ACTLR configuration

[See, Chin Liang]

On Sat, 2018-06-23 at 06:23 +0200, Marek Vasut wrote:
> On 06/23/2018 05:55 AM, Marek Vasut wrote:
> > 
> > On 06/06/2018 08:47 PM, Marek Vasut wrote:
> > > 
> > > On 05/31/2018 12:00 PM, Marek Vasut wrote:
> > > > 
> > > > On 05/31/2018 11:52 AM, See, Chin Liang wrote:
> > > > > 
> > > > > On Tue, 2018-05-29 at 18:39 +0200, Marek Vasut wrote:
> > > > > > 
> > > > > > Make sure the ARM ACTLR register has correct configuration,
> > > > > > otherwise
> > > > > > the Linux kernel refuses to boot. In particular, the "Write
> > > > > > Full Line
> > > > > > of Zeroes" bit must be cleared.
> > > > > > 
> > > > > > Signed-off-by: Marek Vasut 
> > > > > > Cc: Chin Liang See 
> > > > > > Cc: Dinh Nguyen 
> > > > > > ---
> > > > > > NOTE: This gem was well hidden in the Altera U-Boot fork
> > > > > > and is
> > > > > > really needed.
> > > > > >   What is not entirely clear to me is WHY ? So why is
> > > > > > this needed
> > > > > > ?
> > > > > I vaguely recall it's related to HW constrain. And check back
> > > > > the
> > > > > downstream U-Boot, actually we need to set the bit instead
> > > > > clearing
> > > > > it. https://github.com/altera-opensource/u-boot-socfpga/blob/
> > > > > socfpga_v2
> > > > > 014.10_arria10_bringup/arch/arm/cpu/armv7/socfpga_arria10/pl3
> > > > > 10.c
> > > > You are clearing it here:
> > > > https://github.com/altera-opensource/u-boot-socfpga/blob/socfpg
> > > > a_v2014.10_arria10_bringup/arch/arm/cpu/armv7/socfpga_arria10/l
> > > > owlevel_init.S#L35
> > > > 
> > > > The PL310 configuration is a different register. What HW
> > > > constraint ?
> > > > I'd really like to understand this problem.
> > > Bump ? I had a report the register even has to be set to 0 ,
> > > otherwise
> > > there are ethernet problems. What is going on with this register
> > > ?
> > Bump again ?
> > 
> Expanding the CC list. I am tempted to stop accepting any socfpga
> patches until this is resolved.
> 

Just realize this is not addressed as Ley Foon talked to me

We checked with HW team that the full line of zeroes is a special setup
of signals between A9 and L2 cache controller. As they recalled that
this signal is not 100% AXI compliance, it may hang the system if L2
cache is disabled while full line of zeroes is set.

In A10, one thing new is we enabled L2 cache in BootROM and this bit is
set. When entering the U-Boot, we are ensuring all cache are disabled.
At this point, we need to ensure full line of zeroes bit is cleared.
Only when U-Boot renable the cache including L2, this bit is set again.

Hope this explains.

Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ddr: altera: Drop custom dram_bank_mmu_setup() on Arria10

[See, Chin Liang]

On Tue, 2018-05-29 at 18:36 +0200, Marek Vasut wrote:
> This function was never used in SPL and the default implementation of
> dram_bank_mmu_setup() does the same thing. The only difference is the
> part which configures OCRAM as cachable, which doesn't really work as
> it covers more than the OCRAM.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> ---
>  drivers/ddr/altera/sdram_arria10.c | 25 -
>  1 file changed, 25 deletions(-)
> 


Reviewed-by: Chin Liang See 

Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Pull DRAM size from DT

[See, Chin Liang]

On Tue, 2018-05-29 at 18:37 +0200, Marek Vasut wrote:
> Pull the DRAM size from DT instead of hardcoding it into U-Boot.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> ---
>  arch/arm/mach-socfpga/misc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
> socfpga/misc.c
> index fca86507f1..bc6097cb1f 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -40,7 +40,9 @@ struct bsel bsel_str[] = {
>  
>  int dram_init(void)
>  {
> - gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1,
> PHYS_SDRAM_1_SIZE);
> + if (fdtdec_setup_memory_size() != 0)
> + return -EINVAL;
> +
>   return 0;
>  }
>  


Reviewed-by: Chin Liang See 

Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Make DRAM node available in SPL

[See, Chin Liang]

On Tue, 2018-05-29 at 18:38 +0200, Marek Vasut wrote:
> The SPL can also parse the DRAM configuration node to figure out the
> memory layout, make sure it is available.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> ---
>  arch/arm/dts/socfpga_arria10_socdk.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/dts/socfpga_arria10_socdk.dtsi
> b/arch/arm/dts/socfpga_arria10_socdk.dtsi
> index d7616dd1c5..3f59f02577 100644
> --- a/arch/arm/dts/socfpga_arria10_socdk.dtsi
> +++ b/arch/arm/dts/socfpga_arria10_socdk.dtsi
> @@ -34,6 +34,7 @@
>   name = "memory";
>   device_type = "memory";
>   reg = <0x0 0x4000>; /* 1GB */
> + u-boot,dm-pre-reloc;
>   };
>  
>   a10leds {

Reviewed-by: Chin Liang See 

Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Assure correct ACTLR configuration

[See, Chin Liang]

On Tue, 2018-05-29 at 18:39 +0200, Marek Vasut wrote:
> Make sure the ARM ACTLR register has correct configuration, otherwise
> the Linux kernel refuses to boot. In particular, the "Write Full Line
> of Zeroes" bit must be cleared.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> ---
> NOTE: This gem was well hidden in the Altera U-Boot fork and is
> really needed.
>   What is not entirely clear to me is WHY ? So why is this needed
> ?

I vaguely recall it's related to HW constrain. And check back the
downstream U-Boot, actually we need to set the bit instead clearing
it. https://github.com/altera-opensource/u-boot-socfpga/blob/socfpga_v2
014.10_arria10_bringup/arch/arm/cpu/armv7/socfpga_arria10/pl310.c

Thanks
Chin Liang

[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/5] Add DMA driver for DMA330 controller

[See, Chin Liang]

On Thu, 2018-05-31 at 11:24 +0200, Marek Vasut wrote:
> On 05/31/2018 10:08 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This patchset contains dm driver for DMA330 controller.
> > 
> > This series is working on top of u-boot-socfpga.git -
> >  http://git.denx.de/u-boot.git .
> > 
> > Tien Fong Chee (5):
> >   drivers: dma: Enable DMA-330 driver support
> >   drivers: dma: Add function to zeroes a range of destination such
> > as
> > memory
> >   drivers: dma: Factor out dma_get_device from DMA class function
> >   include: dma: Update the function description for dma_memcpy
> >   arm: dts: socfpga: stratix10: update pdma
> > 
> >  arch/arm/dts/socfpga_stratix10.dtsi |   20 +
> >  drivers/dma/Kconfig |9 +-
> >  drivers/dma/Makefile|1 +
> >  drivers/dma/dma-uclass.c|   23 +-
> >  drivers/dma/dma330.c| 1514
> > +++
> >  drivers/mtd/spi/spi_flash.c |9 +-
> >  include/dma.h   |   19 +-
> >  include/dma330.h|  136 
> >  8 files changed, 1719 insertions(+), 12 deletions(-)
> >  create mode 100644 drivers/dma/dma330.c
> >  create mode 100644 include/dma330.h
> > 
> I presume this is to zero-out the ECC RAM ? Just enable caches and
> use
> memset, it is much faster than this DMA witchcraft, at least on the
> A10.

Yes and no :) 

The patch enable DMA-330 support and also zero-out ECC RAM. 

While for the speed, DMA still faster as it has larger burst size. We
can also parallel the zero out task with other tasks such as flash
controller init.

Thanks
Chin Liang


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

Re: [U-Boot] [PATCH 1/5] ARM: socfpga: Add boot trampoline for Arria10

[See, Chin Liang]

On Tue, 2018-04-17 at 11:28 +0200, Marek Vasut wrote:
> On 04/17/2018 11:11 AM, See, Chin Liang wrote:
> > 
> > On Tue, 2018-04-17 at 11:01 +0200, Marek Vasut wrote:
> > > 
> > > On 04/17/2018 10:52 AM, See, Chin Liang wrote:
> > > > 
> > > > 
> > > > On Tue, 2018-04-17 at 10:46 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 04/17/2018 10:40 AM, See, Chin Liang wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi Marek,
> > > > > > 
> > > > > > On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The Arria10 uses slightly different boot image header
> > > > > > > than
> > > > > > > the
> > > > > > > Gen5
> > > > > > > SoCs,
> > > > > > > in particular the header itself contains an offset from
> > > > > > > the
> > > > > > > start
> > > > > > > of
> > > > > > > the
> > > > > > > header to which the Arria10 jumps. This offset must not
> > > > > > > be
> > > > > > > negative,
> > > > > > > yet
> > > > > > > the header is placed at offset 0x40 of the bootable
> > > > > > > binary.
> > > > > > > Therefore, to
> > > > > > > jump into U-Boot, add a trampoline just past the Arria10
> > > > > > > boot
> > > > > > > header
> > > > > > > and
> > > > > > > point to this trampoline at fixed offset from the header
> > > > > > > generated
> > > > > > > using
> > > > > > > the mkimage -T socfpgaimage_v1 . Note that it is not
> > > > > > > needed
> > > > > > > to
> > > > > > > jump
> > > > > > > back
> > > > > > > to offset 0x0 of the image, it is possible to jump
> > > > > > > directly
> > > > > > > at
> > > > > > > the
> > > > > > > reset
> > > > > > > label and save processing two instructions.
> > > > > > > 
> > > > > > > Signed-off-by: Marek Vasut <ma...@denx.de>
> > > > > > > Cc: Dinh Nguyen <dingu...@kernel.org>
> > > > > > > Cc: Chin Liang See <chin.liang@intel.com>
> > > > > > > ---
> > > > > > >  arch/arm/mach-socfpga/include/mach/boot0.h | 4 ++--
> > > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > > > b/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > > > index d6b9435d33..06bbe27d2c 100644
> > > > > > > --- a/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > > > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > > > @@ -18,10 +18,10 @@ _start:
> > > > > > >   .word   0xcafec0d3; /* Checksum,
> > > > > > > zero-
> > > > > > > pad */
> > > > > > >   nop;
> > > > > > >  
> > > > > > > - b reset;/* SoCFPGA jumps here */
> > > > > > > - nop;
> > > > > > > + b reset;/* SoCFPGA Gen5 jumps
> > > > > > > here
> > > > > > > */
> > > > > > >   nop;
> > > > > > >   nop;
> > > > > > > + b reset;/* SoCFPGA Gen10
> > > > > > > trampoline
> > > > > > > */
> > > > > > Our mkpimage tools from SOCEDS is using 0x14 as offset.
> > > > > > Wonder
> > > > > > can
> > > > > > we
> > > > > > standardize that by using 0x14 instead of proposed 0x18 in
> > > > > > this
> > > > > > patch?
> > > > > What difference does it make, the entire image is generated
> > > > > during
> > > > > the
> > > > > build anyway ? This patch uses offset 0x1c, but what is the
> > > > > reason
> > > > > for
> > > > > address 0x14 in your proprietary tool, is there one ?
> > > > Our A10 header ended at 0x13 today. Hence we are continuing the
> > > > code at
> > > > 0x14 without any spacing.
> > > > 
> > > > While for 0x1c, should it be 3 nop?
> > > Yes, gives enough space were the header grow for whatever reason.
> > > Mind
> > > you, the NOPs are not executed, the socfpga jumps to 0x1c
> > > directly
> > > via
> > > 0x0c -- Image entry offset
> > Ok, I don't have strong objection on this. We can claim that we
> > don't
> > support use case where we use mkpimage tools from SCOEDS to sign
> > SPL
> > binary from mainstream.
> Which you can, why wouldn't it work ?
> 

Rethinking on this, yes as the nop shall able to handle this. Just the
vice versa won't work since downstream U-Boot already have the entry
fixed at 0x14.


> What is the benefit of using mkpimage if mkimage does the same thing
> though ?

Initial thought is for having both tools compatible. But rethinking the
makefile will handle this, we just advise user directly use sfp file
directly.

Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 13/16] arm: socfpga: stratix10: Add timer support for Stratix10 SoC

[See, Chin Liang]

On Thu, 2018-04-19 at 04:59 +0200, Marek Vasut wrote:
> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
> > 
> > Add timer support for Stratix SoC
> Is this really custom timer or is that some armv8 thing you're adding
> here ? Don't we already have a generic implementation for that ? If
> not,
> that's what we should do here.

Yes but not the init function. It's left with platform specific code to
init it.

Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 05/16] arm: socfpga: misc: Add CONFIG_SYS_L2_PL310 switch

[See, Chin Liang]

On Thu, 2018-04-19 at 04:47 +0200, Marek Vasut wrote:
> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
> > 
> > Add CONFIG_SYS_L2_PL310 conditional build.
> Why ?
> 

In ARM64, L2 cache controller is accessed through processor registers.
Hence we shall make this conditional in order this file can be shared
across SOCFPGAs.

Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] ARM: socfpga: Add boot trampoline for Arria10

[See, Chin Liang]

On Tue, 2018-04-17 at 11:01 +0200, Marek Vasut wrote:
> On 04/17/2018 10:52 AM, See, Chin Liang wrote:
> > 
> > On Tue, 2018-04-17 at 10:46 +0200, Marek Vasut wrote:
> > > 
> > > On 04/17/2018 10:40 AM, See, Chin Liang wrote:
> > > > 
> > > > 
> > > > Hi Marek,
> > > > 
> > > > On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > The Arria10 uses slightly different boot image header than
> > > > > the
> > > > > Gen5
> > > > > SoCs,
> > > > > in particular the header itself contains an offset from the
> > > > > start
> > > > > of
> > > > > the
> > > > > header to which the Arria10 jumps. This offset must not be
> > > > > negative,
> > > > > yet
> > > > > the header is placed at offset 0x40 of the bootable binary.
> > > > > Therefore, to
> > > > > jump into U-Boot, add a trampoline just past the Arria10 boot
> > > > > header
> > > > > and
> > > > > point to this trampoline at fixed offset from the header
> > > > > generated
> > > > > using
> > > > > the mkimage -T socfpgaimage_v1 . Note that it is not needed
> > > > > to
> > > > > jump
> > > > > back
> > > > > to offset 0x0 of the image, it is possible to jump directly
> > > > > at
> > > > > the
> > > > > reset
> > > > > label and save processing two instructions.
> > > > > 
> > > > > Signed-off-by: Marek Vasut <ma...@denx.de>
> > > > > Cc: Dinh Nguyen <dingu...@kernel.org>
> > > > > Cc: Chin Liang See <chin.liang@intel.com>
> > > > > ---
> > > > >  arch/arm/mach-socfpga/include/mach/boot0.h | 4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > b/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > index d6b9435d33..06bbe27d2c 100644
> > > > > --- a/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h
> > > > > @@ -18,10 +18,10 @@ _start:
> > > > >   .word   0xcafec0d3; /* Checksum, zero-
> > > > > pad */
> > > > >   nop;
> > > > >  
> > > > > - b reset;/* SoCFPGA jumps here */
> > > > > - nop;
> > > > > + b reset;/* SoCFPGA Gen5 jumps here
> > > > > */
> > > > >   nop;
> > > > >   nop;
> > > > > + b reset;/* SoCFPGA Gen10 trampoline
> > > > > */
> > > > Our mkpimage tools from SOCEDS is using 0x14 as offset. Wonder
> > > > can
> > > > we
> > > > standardize that by using 0x14 instead of proposed 0x18 in this
> > > > patch?
> > > What difference does it make, the entire image is generated
> > > during
> > > the
> > > build anyway ? This patch uses offset 0x1c, but what is the
> > > reason
> > > for
> > > address 0x14 in your proprietary tool, is there one ?
> > Our A10 header ended at 0x13 today. Hence we are continuing the
> > code at
> > 0x14 without any spacing.
> > 
> > While for 0x1c, should it be 3 nop?
> Yes, gives enough space were the header grow for whatever reason.
> Mind
> you, the NOPs are not executed, the socfpga jumps to 0x1c directly
> via
> 0x0c -- Image entry offset

Ok, I don't have strong objection on this. We can claim that we don't
support use case where we use mkpimage tools from SCOEDS to sign SPL
binary from mainstream.

Acked-By: Chin Liang See <chin.liang@intel.com>


Thanks
Chin Liang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] spl: socfpga: Generate Arria10 SFP header V1

[See, Chin Liang]

On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote:
> Generate SoCFPGA boot header version 1 instead of version 0 for
> Arria10.
> 
> Signed-off-by: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> ---
>  scripts/Makefile.spl | 4 
>  1 file changed, 4 insertions(+)
> 

Acked-by: Chin Liang See 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] ARM: socfpga: Add boot trampoline for Arria10

[See, Chin Liang]

On Tue, 2018-04-17 at 10:46 +0200, Marek Vasut wrote:
> On 04/17/2018 10:40 AM, See, Chin Liang wrote:
> > 
> > Hi Marek,
> > 
> > On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote:
> > > 
> > > The Arria10 uses slightly different boot image header than the
> > > Gen5
> > > SoCs,
> > > in particular the header itself contains an offset from the start
> > > of
> > > the
> > > header to which the Arria10 jumps. This offset must not be
> > > negative,
> > > yet
> > > the header is placed at offset 0x40 of the bootable binary.
> > > Therefore, to
> > > jump into U-Boot, add a trampoline just past the Arria10 boot
> > > header
> > > and
> > > point to this trampoline at fixed offset from the header
> > > generated
> > > using
> > > the mkimage -T socfpgaimage_v1 . Note that it is not needed to
> > > jump
> > > back
> > > to offset 0x0 of the image, it is possible to jump directly at
> > > the
> > > reset
> > > label and save processing two instructions.
> > > 
> > > Signed-off-by: Marek Vasut <ma...@denx.de>
> > > Cc: Dinh Nguyen <dingu...@kernel.org>
> > > Cc: Chin Liang See <chin.liang@intel.com>
> > > ---
> > >  arch/arm/mach-socfpga/include/mach/boot0.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h
> > > b/arch/arm/mach-socfpga/include/mach/boot0.h
> > > index d6b9435d33..06bbe27d2c 100644
> > > --- a/arch/arm/mach-socfpga/include/mach/boot0.h
> > > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h
> > > @@ -18,10 +18,10 @@ _start:
> > >   .word   0xcafec0d3; /* Checksum, zero-pad */
> > >   nop;
> > >  
> > > - b reset;/* SoCFPGA jumps here */
> > > - nop;
> > > + b reset;/* SoCFPGA Gen5 jumps here */
> > >   nop;
> > >   nop;
> > > + b reset;/* SoCFPGA Gen10 trampoline */
> > Our mkpimage tools from SOCEDS is using 0x14 as offset. Wonder can
> > we
> > standardize that by using 0x14 instead of proposed 0x18 in this
> > patch?
> What difference does it make, the entire image is generated during
> the
> build anyway ? This patch uses offset 0x1c, but what is the reason
> for
> address 0x14 in your proprietary tool, is there one ?

Our A10 header ended at 0x13 today. Hence we are continuing the code at
0x14 without any spacing.

While for 0x1c, should it be 3 nop?

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH 3/5] tools: socfpga: Stop using global struct socfpga_image

[See, Chin Liang]

On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote:
> The structure is passed around correctly, create local instances
> where necessary and zap the global struct socfpga_image instance.
> 
> Signed-off-by: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> ---
>  tools/socfpgaimage.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 

Acked-by: Chin Liang See 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] image: socfpga: Add SFP image version 1 definition

[See, Chin Liang]

On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote:
> Add support for the SoCFPGA header v1, which is used on Arria 10.
> The layout of the v0 and v1 header is similar, yet there are a few
> differences which make it incompatible with previous v0 header, so
> add a new entry.
> 
> Signed-off-by: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> ---
>  common/image.c  | 3 ++-
>  include/image.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 

Acked-by: Chin Liang See 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] ARM: socfpga: Add boot trampoline for Arria10

[See, Chin Liang]

Hi Marek,

On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote:
> The Arria10 uses slightly different boot image header than the Gen5
> SoCs,
> in particular the header itself contains an offset from the start of
> the
> header to which the Arria10 jumps. This offset must not be negative,
> yet
> the header is placed at offset 0x40 of the bootable binary.
> Therefore, to
> jump into U-Boot, add a trampoline just past the Arria10 boot header
> and
> point to this trampoline at fixed offset from the header generated
> using
> the mkimage -T socfpgaimage_v1 . Note that it is not needed to jump
> back
> to offset 0x0 of the image, it is possible to jump directly at the
> reset
> label and save processing two instructions.
> 
> Signed-off-by: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> ---
>  arch/arm/mach-socfpga/include/mach/boot0.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h
> b/arch/arm/mach-socfpga/include/mach/boot0.h
> index d6b9435d33..06bbe27d2c 100644
> --- a/arch/arm/mach-socfpga/include/mach/boot0.h
> +++ b/arch/arm/mach-socfpga/include/mach/boot0.h
> @@ -18,10 +18,10 @@ _start:
>   .word   0xcafec0d3; /* Checksum, zero-pad */
>   nop;
>  
> - b reset;/* SoCFPGA jumps here */
> - nop;
> + b reset;/* SoCFPGA Gen5 jumps here */
>   nop;
>   nop;
> + b reset;/* SoCFPGA Gen10 trampoline */

Our mkpimage tools from SOCEDS is using 0x14 as offset. Wonder can we
standardize that by using 0x14 instead of proposed 0x18 in this patch?

Thanks
Chin Liang

>  #endif
>  
>  #endif /* __BOOT0_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: gen5: Enabling cache and TLB maintenance broadcast

[See, Chin Liang]

On Thu, 2018-03-01 at 17:17 +0100, Marek Vasut wrote:
> On 02/28/2018 06:12 AM, chin.liang@intel.com wrote:
> > 
> > From: Chin Liang See 
> > 
> > Enabling cache and TLB maintenance broadcast through ACTLR as
> > required
> > by Linux.
> This needs far more clarification. What is the problem you're fixing
> here ? How does it fix the problem ?

Sure. When the 2 processors is enabled with SMP, popen operation would
fail as content are different after the copy. This issue goes away when
we force Linux to run with 1 core only. Checked with ARM, this bit is
required by Linux when running SMP.

Chin Liang

> 
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  arch/arm/mach-socfpga/misc_gen5.c | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-socfpga/misc_gen5.c b/arch/arm/mach-
> > socfpga/misc_gen5.c
> > index a7dcacc..7c7a708 100644
> > --- a/arch/arm/mach-socfpga/misc_gen5.c
> > +++ b/arch/arm/mach-socfpga/misc_gen5.c
> > @@ -239,7 +239,7 @@ static u32 iswgrp_handoff[8];
> >  
> >  int arch_early_init_r(void)
> >  {
> > -   int i;
> > +   int i, val;
> >  
> >     /*
> >      * Write magic value into magic register to unlock support
> > for
> > @@ -285,6 +285,15 @@ int arch_early_init_r(void)
> >     socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
> >  #endif
> >  
> > +   /* Enable cache and TLB maintainance broadcast as required
> > by Linux */
> > +   /* Read auxiliary control register */
> > +   asm volatile ("mrc p15, 0, %0, c1, c0, 1\n\t" :
> > "=r"(val));
> > +   val |= (1 << 0);
> > +   /* Write auxiliary control register */
> > +   asm volatile ("mcr p15, 0, %0, c1, c0, 1\n\t" : :
> > "r"(val));
> > +   CP15DSB;
> > +   CP15ISB;
> > +
> >     return 0;
> >  }
> >  
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] arm: socfpga: cyclone5: Enable Macronix flash support

[See, Chin Liang]

On Thu, 2018-02-22 at 11:45 +0100, Marek Vasut wrote:
> On 02/22/2018 07:29 AM, See, Chin Liang wrote:
> > 
> > On Wed, 2018-02-21 at 20:23 +0100, Marek Vasut wrote:
> > > 
> > > On 02/21/2018 08:39 AM, chin.liang@intel.com wrote:
> > > > 
> > > > 
> > > > From: Chin Liang See <chin.liang@intel.com>
> > > > 
> > > > Enable Macronix flash support for Cyclone5 SoC
> > > Do these boards actually have a macronix flash ? Most of the ones
> > > I
> > > know
> > > of do not.
> > Good question. 
> > 
> > Actually they are pin compatible and customer can replace the
> > existing
> > one. FYI, there seems a NOR flash shortage worldwide which lead to
> > requests by customer to change the BOM list.
> I'm quite sure better half of those boards won't . If you want to
> enable
> the SPI NORs on the devkits, fine, but the is1, sr1500 and vining are
> unlikely to get a replacement memory type.

Actually the way the code works is detecting JEDEC ID and associate it
with correct flash drivers like Micron, Spansion or Macronix. Hence it
would not yield any issue except slightly larger code. But I can take
out sr1500 and vining if it yield a concern.

Thanks
Chin Liang



> 
> [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] arm: socfpga: cyclone5: Enable Macronix flash support

[See, Chin Liang]

On Wed, 2018-02-21 at 20:23 +0100, Marek Vasut wrote:
> On 02/21/2018 08:39 AM, chin.liang@intel.com wrote:
> > 
> > From: Chin Liang See 
> > 
> > Enable Macronix flash support for Cyclone5 SoC
> Do these boards actually have a macronix flash ? Most of the ones I
> know
> of do not.

Good question. 

Actually they are pin compatible and customer can replace the existing
one. FYI, there seems a NOR flash shortage worldwide which lead to
requests by customer to change the BOM list.

Thanks
Chin Liang

> 
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  configs/socfpga_cyclone5_defconfig| 1 +
> >  configs/socfpga_is1_defconfig | 1 +
> >  configs/socfpga_sockit_defconfig  | 1 +
> >  configs/socfpga_socrates_defconfig| 1 +
> >  configs/socfpga_sr1500_defconfig  | 1 +
> >  configs/socfpga_vining_fpga_defconfig | 1 +
> >  6 files changed, 6 insertions(+)
> > 
> > diff --git a/configs/socfpga_cyclone5_defconfig
> > b/configs/socfpga_cyclone5_defconfig
> > index 6ebd8a9..aa535c6 100644
> > --- a/configs/socfpga_cyclone5_defconfig
> > +++ b/configs/socfpga_cyclone5_defconfig
> > @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> > diff --git a/configs/socfpga_is1_defconfig
> > b/configs/socfpga_is1_defconfig
> > index 08628ab..7be720a 100644
> > --- a/configs/socfpga_is1_defconfig
> > +++ b/configs/socfpga_is1_defconfig
> > @@ -48,6 +48,7 @@ CONFIG_SYS_I2C_DW=y
> >  # CONFIG_MMC is not set
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  CONFIG_PHY_MICREL=y
> >  CONFIG_PHY_MICREL_KSZ90X1=y
> > diff --git a/configs/socfpga_sockit_defconfig
> > b/configs/socfpga_sockit_defconfig
> > index 8ebe394..6edb47f 100644
> > --- a/configs/socfpga_sockit_defconfig
> > +++ b/configs/socfpga_sockit_defconfig
> > @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> > diff --git a/configs/socfpga_socrates_defconfig
> > b/configs/socfpga_socrates_defconfig
> > index 9f42481..7c2428a 100644
> > --- a/configs/socfpga_socrates_defconfig
> > +++ b/configs/socfpga_socrates_defconfig
> > @@ -54,6 +54,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  CONFIG_PHY_MICREL=y
> > diff --git a/configs/socfpga_sr1500_defconfig
> > b/configs/socfpga_sr1500_defconfig
> > index f9ed1a3..df1ee31 100644
> > --- a/configs/socfpga_sr1500_defconfig
> > +++ b/configs/socfpga_sr1500_defconfig
> > @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> >  CONFIG_DM_ETH=y
> > diff --git a/configs/socfpga_vining_fpga_defconfig
> > b/configs/socfpga_vining_fpga_defconfig
> > index 6670b9f..512d701 100644
> > --- a/configs/socfpga_vining_fpga_defconfig
> > +++ b/configs/socfpga_vining_fpga_defconfig
> > @@ -69,6 +69,7 @@ CONFIG_LED_STATUS_CMD=y
> >  CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm: socfpga: cyclone5: Ensure spi-flash in the compatible string

[See, Chin Liang]

On Wed, 2018-02-21 at 10:34 +0100, Simon Goldschmidt wrote:
> On 21.02.2018 08:40, chin.liang@intel.com wrote:
> > 
> > From: Chin Liang See 
> > 
> > Ensure "spi-flash" is added into compatible string when there is
> > NOR flash being instantiated in DTS. Discovered "sf probe" command
> > without argument would hit error if spi-flash compatible string
> > is missing.
> This has already been fixed 5 days ago.
> 

Nice and thanks for the patch.
I was pulling from the source few days back for enabling the Macronix
flash and bumping into this same issue.

Thanks
Chin Liang

> Simon
> 
> > 
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >   arch/arm/dts/socfpga_cyclone5_is1.dts  | 2 +-
> >   arch/arm/dts/socfpga_cyclone5_socdk.dts| 2 +-
> >   arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 +-
> >   3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts
> > b/arch/arm/dts/socfpga_cyclone5_is1.dts
> > index 2e2b71f..549024c 100644
> > --- a/arch/arm/dts/socfpga_cyclone5_is1.dts
> > +++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
> > @@ -87,7 +87,7 @@
> >     u-boot,dm-pre-reloc;
> >     #address-cells = <1>;
> >     #size-cells = <1>;
> > -   compatible = "n25q00";
> > +   compatible = "n25q00","spi-flash";
> >     reg = <0>;  /* chip select */
> >     spi-max-frequency = <1>;
> >     m25p,fast-read;
> > diff --git a/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > b/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > index 95a8e65..e30bf9a 100644
> > --- a/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > +++ b/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > @@ -98,7 +98,7 @@
> >     u-boot,dm-pre-reloc;
> >     #address-cells = <1>;
> >     #size-cells = <1>;
> > -   compatible = "n25q00";
> > +   compatible = "n25q00","spi-flash";
> >     reg = <0>;  /* chip select */
> >     spi-max-frequency = <1>;
> >     m25p,fast-read;
> > diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > b/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > index e3ae8a8..3e78038 100644
> > --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > @@ -68,7 +68,7 @@
> >     flash0: n25q00@0 {
> >     #address-cells = <1>;
> >     #size-cells = <1>;
> > -   compatible = "n25q00";
> > +   compatible = "n25q00","spi-flash";
> >     reg = <0>;  /* chip select */
> >     spi-max-frequency = <5000>;
> >     m25p,fast-read;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 02/14] arm: dts: Add dts for Stratix10 SoC

[See, Chin Liang]

On Tue, 2017-09-26 at 16:37 -0500, Dinh Nguyen wrote:
> On Tue, Sep 19, 2017 at 4:22 AM,   wrote:
> > 
> > From: Chin Liang See 
> > 
> > Device tree for Stratix10 SoC
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  arch/arm/dts/Makefile|   3 +-
> >  arch/arm/dts/socfpga_stratix10_socdk.dts | 141
> > +++
> >  2 files changed, 143 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/dts/socfpga_stratix10_socdk.dts
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index fee4680..4cf5fd0 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -171,7 +171,8 @@ dtb-$(CONFIG_ARCH_SOCFPGA)
> > +=   \
> > socfpga_cyclone5_sockit.dtb \
> > socfpga_cyclone5_socrates.dtb   \
> > socfpga_cyclone5_sr1500.dtb \
> > -   socfpga_cyclone5_vining_fpga.dtb
> > +   socfpga_cyclone5_vining_fpga.dtb\
> > +   socfpga_stratix10_socdk.dtb
> > 
> >  dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb  \
> > dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb
> > diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
> > b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > new file mode 100644
> > index 000..484c630
> > --- /dev/null
> > +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > @@ -0,0 +1,141 @@
> > +/*
> > + * Copyright (C) 2016-2017 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +/dts-v1/;
> > +#include "skeleton.dtsi"
> > +#include 
> > +
> > +/ {
> > +   model = "Intel SOCFPGA Stratix 10 SoC Development Kit";
> > +   compatible = "altr,socfpga-stratix10", "altr,socfpga";
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   chosen {
> > +   bootargs = "console=ttyS0,115200";
> > +   };
> > +
> > +   aliases {
> > +   ethernet0 = 
> > +   spi0 = 
> > +   };
> > +
> > +   memory {
> > +   name = "memory";
> > +   device_type = "memory";
> > +   reg = <0x0 0x8000>; /* 2GB */
> > +   };
> > +
> > +   regulator_3_3v: 3-3-v-regulator {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "3.3V";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   };
> > +
> > +   soc {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "simple-bus";
> > +   device_type = "soc";
> > +   ranges;
> > +   u-boot,dm-pre-reloc;
> > +
> > +   rst: rstmgr@ffd11000 {
> > +   #reset-cells = <1>;
> > +   compatible = "altr,rst-mgr";
> > +   reg = <0xffd11000 0x100>;
> > +   altr,modrst-offset = <0x20>;
> > +   };
> Where are the cpu nodes?

yes, need to be added

CHin Liang
> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 02/14] arm: dts: Add dts for Stratix10 SoC

[See, Chin Liang]

On Tue, 2017-09-26 at 16:34 -0500, Dinh Nguyen wrote:
> On Tue, Sep 19, 2017 at 4:22 AM,   wrote:
> > 
> > From: Chin Liang See 
> > 
> > Device tree for Stratix10 SoC
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  arch/arm/dts/Makefile|   3 +-
> >  arch/arm/dts/socfpga_stratix10_socdk.dts | 141
> > +++
> >  2 files changed, 143 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/dts/socfpga_stratix10_socdk.dts
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index fee4680..4cf5fd0 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -171,7 +171,8 @@ dtb-$(CONFIG_ARCH_SOCFPGA)
> > +=   \
> > socfpga_cyclone5_sockit.dtb \
> > socfpga_cyclone5_socrates.dtb   \
> > socfpga_cyclone5_sr1500.dtb \
> > -   socfpga_cyclone5_vining_fpga.dtb
> > +   socfpga_cyclone5_vining_fpga.dtb\
> > +   socfpga_stratix10_socdk.dtb
> > 
> >  dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb  \
> > dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb
> > diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
> > b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > new file mode 100644
> > index 000..484c630
> > --- /dev/null
> > +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > @@ -0,0 +1,141 @@
> > +/*
> > + * Copyright (C) 2016-2017 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +/dts-v1/;
> > +#include "skeleton.dtsi"
> > +#include 
> You don't add the patch for this include file until patch 4/14, which
> means
> the build will fail until patch 4 is applied. You need to move this
> patch
> after 4/14.

Yes, good catch. Let shuffle this

> 
> > 
> > +
> > +/ {
> > +   model = "Intel SOCFPGA Stratix 10 SoC Development Kit";
> > +   compatible = "altr,socfpga-stratix10", "altr,socfpga";
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   chosen {
> > +   bootargs = "console=ttyS0,115200";
> > +   };
> > +
> > +   aliases {
> > +   ethernet0 = 
> > +   spi0 = 
> > +   };
> > +
> > +   memory {
> > +   name = "memory";
> > +   device_type = "memory";
> > +   reg = <0x0 0x8000>; /* 2GB */
> > +   };
> > +
> > +   regulator_3_3v: 3-3-v-regulator {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "3.3V";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   };
> > +
> > +   soc {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "simple-bus";
> > +   device_type = "soc";
> > +   ranges;
> > +   u-boot,dm-pre-reloc;
> > +
> > +   rst: rstmgr@ffd11000 {
> > +   #reset-cells = <1>;
> > +   compatible = "altr,rst-mgr";
> > +   reg = <0xffd11000 0x100>;
> > +   altr,modrst-offset = <0x20>;
> > +   };
> > +
> > +   gmac0: ethernet@ff80 {
> > +   compatible = "altr,socfpga-stmmac",
> > "snps,dwmac-3.74a", "snps,dwmac";
> > +   reg = <0xff80 0x2000>;
> > +   interrupts = <0 90 4>;
> > +   interrupt-names = "macirq";
> > +   mac-address = [00 00 00 00 00 00];
> > +   resets = < EMAC0_RESET>;
> > +   reset-names = "stmmaceth";
> > +   phy-mode = "rgmii";
> > +   phy-addr = <0x>; /* probe for phy
> > addr */
> > +   max-speed = <1000>;
> > +   txd0-skew-ps = <0>; /* -420ps */
> > +   txd1-skew-ps = <0>; /* -420ps */
> > +   txd2-skew-ps = <0>; /* -420ps */
> > +   txd3-skew-ps = <0>; /* -420ps */
> > +   rxd0-skew-ps = <420>; /* 0ps */
> > +   rxd1-skew-ps = <420>; /* 0ps */
> > +   rxd2-skew-ps = <420>; /* 0ps */
> > +   rxd3-skew-ps = <420>; /* 0ps */
> > +   txen-skew-ps = <0>; /* -420ps */
> > +   txc-skew-ps = <1860>; /* 960ps */
> > +   rxdv-skew-ps = <420>; /* 0ps */
> > +   rxc-skew-ps = <1680>; /* 780ps */
> These are PHY properties, which should be in a separate PHY node.

Let me check on the PHY driver

Chin Liang

> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH 03/14] arm: socfpga: stratix10: Add Clock Manager driver for Stratix10 SoC

[See, Chin Liang]

On Tue, 2017-09-26 at 17:04 -0500, Dinh Nguyen wrote:
> On Tue, Sep 19, 2017 at 4:22 AM,   wrote:
> > 
> > From: Chin Liang See 
> > 
> > Add Clock Manager driver support for Stratix SoC
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  arch/arm/mach-socfpga/Makefile |   4 +
> >  arch/arm/mach-socfpga/clock_manager.c  |   4 +-
> >  arch/arm/mach-socfpga/clock_manager_s10.c  | 359
> > +
> >  arch/arm/mach-socfpga/include/mach/clock_manager.h |   2 +
> >  .../mach-socfpga/include/mach/clock_manager_s10.h  | 202
> > 
> >  arch/arm/mach-socfpga/include/mach/handoff_s10.h   |  29 ++
> >  arch/arm/mach-socfpga/wrap_pll_config_s10.c|  46 +++
> >  7 files changed, 644 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/arm/mach-socfpga/clock_manager_s10.c
> >  create mode 100644 arch/arm/mach-
> > socfpga/include/mach/clock_manager_s10.h
> >  create mode 100644 arch/arm/mach-
> > socfpga/include/mach/handoff_s10.h
> >  create mode 100644 arch/arm/mach-socfpga/wrap_pll_config_s10.c
> > 
> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > socfpga/Makefile
> > index 286bfef..e5f9dd7 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -30,6 +30,10 @@ obj-y+= pinmux_arria10.o
> >  obj-y  += reset_manager_arria10.o
> >  endif
> > 
> > +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> > +obj-y  += clock_manager_s10.o
> > +obj-y  += wrap_pll_config_s10.o
> > +endif
> >  ifdef CONFIG_SPL_BUILD
> >  obj-y  += spl.o
> >  ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > diff --git a/arch/arm/mach-socfpga/clock_manager.c b/arch/arm/mach-
> > socfpga/clock_manager.c
> > index cb6ae03..f9450a4 100644
> > --- a/arch/arm/mach-socfpga/clock_manager.c
> > +++ b/arch/arm/mach-socfpga/clock_manager.c
> > @@ -21,7 +21,7 @@ void cm_wait_for_lock(u32 mask)
> > do {
> >  #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > inter_val = readl(_manager_base->inter) &
> > mask;
> > -#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > +#else
> > inter_val = readl(_manager_base->stat) &
> > mask;
> >  #endif
> > /* Wait for stable lock */
> > @@ -52,7 +52,7 @@ int set_cpu_clk_info(void)
> > 
> >  #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > gd->bd->bi_ddr_freq = cm_get_sdram_clk_hz() / 100;
> > -#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > +#else
> > gd->bd->bi_ddr_freq = 0;
> >  #endif
> > 
> > diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c
> > b/arch/arm/mach-socfpga/clock_manager_s10.c
> > new file mode 100644
> > index 000..a9f9b07
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/clock_manager_s10.c
> > @@ -0,0 +1,359 @@
> > +/*
> > + * Copyright (C) 2016-2017 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static const struct socfpga_clock_manager *clock_manager_base =
> > +   (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
> > +
> > +/*
> > + * function to write the bypass register which requires a poll of
> > the
> > + * busy bit
> > + */
> > +static void cm_write_bypass_mainpll(uint32_t val)
> > +{
> > +   writel(val, _manager_base->main_pll.bypass);
> > +   cm_wait_for_fsm();
> > +}
> Add a new line..
> 
> > 
> > +static void cm_write_bypass_perpll(uint32_t val)
> > +{
> > +   writel(val, _manager_base->per_pll.bypass);
> > +   cm_wait_for_fsm();
> > +}
> > +
> > +/* function to write the ctrl register which requires a poll of
> > the busy bit */
> > +static void cm_write_ctrl(uint32_t val)
> > +{
> > +   writel(val, _manager_base->ctrl);
> > +   cm_wait_for_fsm();
> > +}
> > +
> > +/*
> > + * Setup clocks while making no assumptions about previous state
> > of the clocks.
> > + *
> Remove extra line
> 
> > 
> > + */
> > +void cm_basic_init(const struct cm_config * const cfg)
> > +{
> > +   uint32_t mdiv, refclkdiv, mscnt, hscnt, vcocalib;
> > +
> > +   if (cfg == 0)
> > +   return;
> > +
> > +   /* Put all plls in bypass */
> > +   cm_write_bypass_mainpll(CLKMGR_BYPASS_MAINPLL_ALL);
> > +   cm_write_bypass_perpll(CLKMGR_BYPASS_PERPLL_ALL);
> > +
> > +   /* setup main PLL dividers */
> > +   /* calculate the vcocalib value */
> Move the above comment to where vcocalib is getting calculated, or
> remove.
> 
> > 
> > +   mdiv = (cfg->main_pll_fdbck >> CLKMGR_FDBCK_MDIV_OFFSET) &
> > +   CLKMGR_FDBCK_MDIV_MASK;
> > +   refclkdiv = (cfg->main_pll_pllglob >>
> > CLKMGR_PLLGLOB_REFCLKDIV_OFFSET) &
> > +CLKMGR_PLLGLOB_REFCLKDIV_MASK;
> > +   mscnt = 200 / (6 + mdiv) / refclkdiv;
> Where are these values, 200 and 6 coming from? Should they be a
> #define?
> 

Yes, I can improve the 

Re: [U-Boot] [PATCH 04/14] arm: socfpga: stratix10: Add Reset Manager driver for Stratix10 SoC

[See, Chin Liang]

On Tue, 2017-09-26 at 17:08 -0500, Dinh Nguyen wrote:
> On Tue, Sep 19, 2017 at 4:22 AM,   wrote:
> > 
> > From: Chin Liang See 
> > 
> > Add Reset Manager driver support for Stratix SoC
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  arch/arm/mach-socfpga/Makefile |   1 +
> >  arch/arm/mach-socfpga/include/mach/reset_manager.h |   2 +
> >  .../mach-socfpga/include/mach/reset_manager_s10.h  | 116
> > +
> >  arch/arm/mach-socfpga/reset_manager.c  |   5 +
> >  arch/arm/mach-socfpga/reset_manager_s10.c  | 140
> > +
> I don't see why you need to add a new file for S10? The functionality
> between
> Gen 5 and Stratix10 is identical for the reset manager.

Not really, they have same functions name but sequences are difference
due to diff interconnect technology. Hence, try to avoid too much #if
#else

Chin Liang

> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 06/14] arm: socfpga: stratix10: Add misc support for Stratix10 SoC

[See, Chin Liang]

On Tue, 2017-09-26 at 17:46 -0500, Dinh Nguyen wrote:
> On Tue, Sep 19, 2017 at 4:22 AM,   wrote:
> > 
> > From: Chin Liang See 
> > 
> > Add misc support for Stratix SoC
> Just because the file is call misc.c doesn't mean you can just keep
> the commit
> message that simple. Can you add what functions are you adding?
> 

Definitely can add more details here

> > 
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  arch/arm/mach-socfpga/Makefile   |   1 +
> >  arch/arm/mach-socfpga/misc.c |   4 +
> >  arch/arm/mach-socfpga/misc_s10.c | 165
> > +++
> >  3 files changed, 170 insertions(+)
> >  create mode 100644 arch/arm/mach-socfpga/misc_s10.c
> > 
> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > socfpga/Makefile
> > index 910eb6f..b253914 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -32,6 +32,7 @@ endif
> > 
> >  ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> >  obj-y  += clock_manager_s10.o
> > +obj-y  += misc_s10.o
> >  obj-y  += reset_manager_s10.o
> >  obj-y  += system_manager_s10.o
> >  obj-y  += wrap_pinmux_config_s10.o
> > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
> > socfpga/misc.c
> > index 00eff90..2ea94bc 100644
> > --- a/arch/arm/mach-socfpga/misc.c
> > +++ b/arch/arm/mach-socfpga/misc.c
> > @@ -23,8 +23,10 @@
> > 
> >  DECLARE_GLOBAL_DATA_PTR;
> > 
> > +#ifdef CONFIG_SYS_L2_PL310
> >  static const struct pl310_regs *const pl310 =
> > (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> > +#endif
> > 
> >  struct bsel bsel_str[] = {
> > { "rsvd", "Reserved", },
> > @@ -53,6 +55,7 @@ void enable_caches(void)
> >  #endif
> >  }
> > 
> > +#ifdef CONFIG_SYS_L2_PL310
> >  void v7_outer_cache_enable(void)
> >  {
> > /* Disable the L2 cache */
> > @@ -73,6 +76,7 @@ void v7_outer_cache_disable(void)
> > /* Disable the L2 cache */
> > clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
> >  }
> > +#endif
> > 
> >  #if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) && \
> >  defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
> > diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-
> > socfpga/misc_s10.c
> > new file mode 100644
> > index 000..b84f055
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/misc_s10.c
> This misc_s10.c look very similar to the Gen5 stuff, can you re-use
> it?

Yes, its true.
Let me move eth stuff to common.

Chin Liang

> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/14] arm: socfpga: stratix10: Add base address map for Statix10 SoC

[See, Chin Liang]

On Tue, 2017-09-19 at 11:51 +0200, Marek Vasut wrote:
> On 09/19/2017 11:22 AM, chin.liang@intel.com wrote:
> > 
> > From: Chin Liang See 
> > 
> > Add the base address map for Statix10 SoC
> > 
> > Signed-off-by: Chin Liang See 
> Add only the stuff which is not obtainable from DT please.
> 

Sure, let me remove the SDMMC, EMAC and QSPI since they are extracted
from DT today

Thanks
Chin Liang

> > 
> > ---
> >  arch/arm/mach-socfpga/include/mach/base_addr_s10.h | 58
> > ++
> >  1 file changed, 58 insertions(+)
> >  create mode 100644 arch/arm/mach-
> > socfpga/include/mach/base_addr_s10.h
> > 
> > diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > new file mode 100644
> > index 000..feb1881
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > @@ -0,0 +1,58 @@
> > +/*
> > + * Copyright (C) 2016-2017 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +#ifndef _SOCFPGA_S10_BASE_HARDWARE_H_
> > +#define _SOCFPGA_S10_BASE_HARDWARE_H_
> > +
> > +#define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
> > +#define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xf801
> > +#define SOCFPGA_SDR_ADDRESS0xf8011000
> > +#define SOCFPGA_SMMU_ADDRESS   0xfa00
> > +#define SOCFPGA_EMAC0_ADDRESS  0xff80
> > +#define SOCFPGA_EMAC1_ADDRESS  0xff802000
> > +#define SOCFPGA_EMAC2_ADDRESS  0xff804000
> > +#define SOCFPGA_SDMMC_ADDRESS  0xff808000
> > +#define SOCFPGA_QSPIREGS_ADDRESS   0xff8d2000
> > +#define SOCFPGA_QSPIDATA_ADDRESS   0xff90
> > +#define SOCFPGA_MAILBOX_ADDRESS0xffA3
> > +#define SOCFPGA_USB0_ADDRESS   0xffb0
> > +#define SOCFPGA_USB1_ADDRESS   0xffb4
> > +#define SOCFPGA_NANDREGS_ADDRESS   0xffb8
> > +#define SOCFPGA_NANDDATA_ADDRESS   0xffb9
> > +#define SOCFPGA_UART0_ADDRESS  0xffc02000
> > +#define SOCFPGA_UART1_ADDRESS  0xffc02100
> > +#define SOCFPGA_I2C0_ADDRESS   0xffc02800
> > +#define SOCFPGA_I2C1_ADDRESS   0xffc02900
> > +#define SOCFPGA_I2C2_ADDRESS   0xffc02a00
> > +#define SOCFPGA_I2C3_ADDRESS   0xffc02b00
> > +#define SOCFPGA_I2C4_ADDRESS   0xffc02c00
> > +#define SOCFPGA_SPTIMER0_ADDRESS   0xffc03000
> > +#define SOCFPGA_SPTIMER1_ADDRESS   0xffc03100
> > +#define SOCFPGA_GPIO0_ADDRESS  0xffc03200
> > +#define SOCFPGA_GPIO1_ADDRESS  0xffc03300
> > +#define SOCFPGA_SYSTIMER0_ADDRESS  0xffd0
> > +#define SOCFPGA_SYSTIMER1_ADDRESS  0xffd00100
> > +#define SOCFPGA_L4WD0_ADDRESS  0xffd00200
> > +#define SOCFPGA_L4WD1_ADDRESS  0xffd00300
> > +#define SOCFPGA_L4WD2_ADDRESS  0xffd00400
> > +#define SOCFPGA_L4WD3_ADDRESS  0xffd00500
> > +#define SOCFPGA_GTIMER_SEC_ADDRESS 0xffd01000
> > +#define SOCFPGA_GTIMER_NSEC_ADDRESS0xffd02000
> > +#define SOCFPGA_CLKMGR_ADDRESS 0xffd1
> > +#define SOCFPGA_RSTMGR_ADDRESS 0xffd11000
> > +#define SOCFPGA_SYSMGR_ADDRESS 0xffd12000
> > +#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS0xffd13000
> > +#define SOCFPGA_DMANONSECURE_ADDRESS   0xffda
> > +#define SOCFPGA_DMASECURE_ADDRESS  0xffda1000
> > +#define SOCFPGA_SPIS0_ADDRESS  0xffda2000
> > +#define SOCFPGA_SPIS1_ADDRESS  0xffda3000
> > +#define SOCFPGA_SPIM0_ADDRESS  0xffda4000
> > +#define SOCFPGA_SPIM1_ADDRESS  0xffda5000
> > +#define SOCFPGA_OCRAM_ADDRESS  0xffe0
> > +#define GICD_BASE  0xfffc1000
> > +#define GICC_BASE  0xfffc2000
> > +
> > +#endif /* _SOCFPGA_S10_BASE_HARDWARE_H_ */
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[See, Chin Liang]

On Sel, 2016-12-06 at 10:54 +0530, Vignesh R wrote:
> 
> Hi,
> 
> On Thursday 01 December 2016 09:41 AM, Vignesh R wrote:
> [...]
> > 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > Data slave port does accept byte, half-word and word access,
> > > > there
> > > > are
> > > > no data aborts. But indirect write controller seems to have
> > > > limitation(as documented in section 11.15.4.9.2) couping with
> > > > non 32-
> > > > bit
> > > > data writes on TI platform. For example with current driver if
> > > > I try:
> > > > 
> > > > fatload mmc 0 0x8200 zImage
> > > > sf erase 0x0 0x50
> > > > sf write 0x8200 0x0 0x35
> > > > sf read 0xA000 0x0 0x35
> > > > 
> > > > 
> > > > md.b 0xA000
> > > > a000: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00
> > > > a010: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00
> > > > a020: 03 00 00 00 18 28 6f 00 00 00 00 00 d8 5b 35 00
> > > > a030: 01 02 03 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > md.b 0x8200
> > > > 8200: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1
> > > > 8210: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1
> > > > 8220: 03 00 00 ea 18 28 6f 01 00 00 00 00 d8 5b 35 00
> > > > 8230: 01 02 03 04 00 90 0f e1 88 07 00 eb 01 70 a0 e1
> > > > 
> > > > 
> > > > As you can see, every fourth byte turn out to be 0x00.
> > > > Therefore this
> > > > patch is required.
> > > Thanks Vignesh
> > > 
> > > Interesting to know that the newer version of controller has this
> > > constrain. Let me pull out my board to ensure this patch doesn't
> > > break
> > > the SOCFPGA
> > > 
> Did you get a chance to test this patch? There is also a similar
> patch
> for indirect read as well[1], it would be great if you could give
> your
> Tested-by for both the patches. Thanks!
> 
> [1]https://patchwork.ozlabs.org/patch/700990/

Actually I was bumping into sf probe error. This is happen at mainline
even without your patch. Let me continue the troubelshooting at my side
and test out your patch asap.

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

Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[See, Chin Liang]

On Jum, 2016-11-25 at 17:51 +0100, Marek Vasut wrote:
> On 11/24/2016 06:35 AM, Vignesh R wrote:
> > 
> > According to Section 11.15.4.9.2 Indirect Write Controller of K2G
> > SoC
> > TRM SPRUHY8D[1], the external master is only permitted to issue 32-
> > bit
> > data interface writes until the last word of an indirect transfer
> > otherwise indirect writes is known to fails sometimes. So, make
> > sure
> > that QSPI indirect writes are 32 bit sized except for the last
> > write. If
> > the txbuf is unaligned then use bounce buffer to avoid data aborts.
> > 
> > So, now that the driver uses bounce_buffer, enable
> > CONFIG_BOUNCE_BUFFER
> > for all boards that use Cadence QSPI driver.
> > 
> > [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
> > 
> > Signed-off-by: Vignesh R 
> > ---
> Reviewed-by: Marek Vasut 
> 
> I'd like to have at least Dinh's/Chin's ack on this.

THanks Marek

Hmmm... From 11.15.4.1.1, the data slave port should able to accept
only byte, half-word and word access. This should not create any data
abort but probably bad performance. But it should insignificant as
access time for the flash is longer than the data port access itself.

Thanks
Chin Liang

> 
> btw don't you need BB for READ as well ?
> 
> > 
> > v2:
> >  - Use bounce buffer
> >  - Link to v1: https://patchwork.ozlabs.org/patch/693069/
> > 
> >  drivers/spi/cadence_qspi_apb.c   | 26 --
> >  include/configs/k2g_evm.h|  1 +
> >  include/configs/socfpga_common.h |  1 +
> >  include/configs/stv0991.h|  1 +
> >  4 files changed, 23 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/spi/cadence_qspi_apb.c
> > b/drivers/spi/cadence_qspi_apb.c
> > index e285d3c1e761..6ce98acf747d 100644
> > --- a/drivers/spi/cadence_qspi_apb.c
> > +++ b/drivers/spi/cadence_qspi_apb.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include "cadence_qspi.h"
> > 
> >  #define CQSPI_REG_POLL_US(1) /* 1us */
> > @@ -741,6 +742,17 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> >   unsigned int remaining = n_tx;
> >   unsigned int write_bytes;
> >   int ret;
> > + struct bounce_buffer bb;
> > + u8 *bb_txbuf;
> > +
> > + /*
> > +  * Handle non-4-byte aligned accesses via bounce buffer to
> > +  * avoid data abort.
> > +  */
> > + ret = bounce_buffer_start(, (void *)txbuf, n_tx,
> > GEN_BB_READ);
> > + if (ret)
> > + return ret;
> > + bb_txbuf = bb.bounce_buffer;
> > 
> >   /* Configure the indirect read transfer bytes */
> >   writel(n_tx, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
> > @@ -751,11 +763,11 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> > 
> >   while (remaining > 0) {
> >   write_bytes = remaining > page_size ? page_size :
> > remaining;
> > - /* Handle non-4-byte aligned access to avoid data
> > abort. */
> > - if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
> > - writesb(plat->ahbbase, txbuf, write_bytes);
> > - else
> > - writesl(plat->ahbbase, txbuf, write_bytes >>
> > 2);
> > + writesl(plat->ahbbase, bb_txbuf, write_bytes >> 2);
> > + if (write_bytes % 4)
> > + writesb(plat->ahbbase,
> > + bb_txbuf + rounddown(write_bytes, 4),
> > + write_bytes % 4);
> > 
> >   ret = wait_for_bit("QSPI", plat->regbase +
> > CQSPI_REG_SDRAMLEVEL,
> >  CQSPI_REG_SDRAMLEVEL_WR_MASK <<
> > @@ -765,7 +777,7 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> >   goto failwr;
> >   }
> > 
> > - txbuf += write_bytes;
> > + bb_txbuf += write_bytes;
> >   remaining -= write_bytes;
> >   }
> > 
> > @@ -776,6 +788,7 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> >   printf("Indirect write completion error (%i)\n",
> > ret);
> >   goto failwr;
> >   }
> > + bounce_buffer_stop();
> > 
> >   /* Clear indirect completion status */
> >   writel(CQSPI_REG_INDIRECTWR_DONE_MASK,
> > @@ -786,6 +799,7 @@ failwr:
> >   /* Cancel the indirect write */
> >   writel(CQSPI_REG_INDIRECTWR_CANCEL_MASK,
> >  plat->regbase + CQSPI_REG_INDIRECTWR);
> > + bounce_buffer_stop();
> >   return ret;
> >  }
> > 
> > diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
> > index a14544526c71..1d603e0c002f 100644
> > --- a/include/configs/k2g_evm.h
> > +++ b/include/configs/k2g_evm.h
> > @@ -79,6 +79,7 @@
> >  #define CONFIG_CADENCE_QSPI
> >  #define CONFIG_CQSPI_REF_CLK 38400
> >  #define CONFIG_CQSPI_DECODER 0x0
> > +#define 

Re: [U-Boot] [PATCH v2 8/8] spi: cadence_qspi: Support specifying the sample edge used

[See, Chin Liang]

Hi Phil,

On Jum, 2016-11-25 at 14:38 +, Phil Edworthy wrote:
> Whilst at it, move the code to read the "sram-size" property
> into the other code that reads properties from the node, rather
> than the SF subnode.
> 
> Also change the code to use a bool for the bypass arg.
> 
> Signed-off-by: Phil Edworthy 
> 
> ---
> v2:
>  Change name of DT prop and provide details of what it does.
>  Whilst at it, move the code to read the "sram-size" property
>  into the other code that reads properties from the node, rather
>  than the SF subnode.
> 
>  Also change the code to use a bool for the bypass arg.
> ---
>  doc/device-tree-bindings/spi/spi-cadence.txt |  2 ++
>  drivers/spi/cadence_qspi.c   | 13 +
>  drivers/spi/cadence_qspi.h   |  3 ++-
>  drivers/spi/cadence_qspi_apb.c   |  8 +++-
>  4 files changed, 20 insertions(+), 6 deletions(-)
> 

[..]

> diff --git a/drivers/spi/cadence_qspi_apb.c
> b/drivers/spi/cadence_qspi_apb.c
> index 56ad952..e43973c 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -98,6 +98,7 @@
>  #defineCQSPI_REG_RD_DATA_CAPTURE_BYPASSBIT(0)
>  #defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB 1
>  #defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK0xF
> +#defineCQSPI_REG_RD_DATA_CAPTURE_EDGE  BIT(5)


Actually we don't have this edge bit at SOCFPGA.
But no harm as its unused bit at SOCFPGA today

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH v2 7/8] spi: cadence_qspi: Fix CS timings

[See, Chin Liang]

Hi Phil,

On Jum, 2016-11-25 at 14:38 +, Phil Edworthy wrote:
> 
> The Cadence QSPI controller has specified overheads for the various
> CS
> times that are in addition to those programmed in to the Device Delay
> register. The overheads are different for the delays.
> 
> In addition, the existing code does not handle the case when the
> delay
> is less than a SCLK period.
> 
> This change accurately calculates the additional delays in Ref
> clocks.
> 
> Signed-off-by: Phil Edworthy 
> ---
> v2:
>  Was "spi: cadence_qspi: Fix CQSPI_CAL_DELAY calculation"
>  Note only did the existing code not cope with the delay less than
>  an SCLK period, but the calculation didn't round properly, and
>  didn't take into account the delays that the QSPI Controller adds
>  to those programmed into the Device Delay reg.
> ---
>  drivers/spi/cadence_qspi_apb.c | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c
> b/drivers/spi/cadence_qspi_apb.c
> index 1cd636a..56ad952 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -169,9 +169,6 @@
> ((readl(base + CQSPI_REG_CONFIG) >> \
> CQSPI_REG_CONFIG_IDLE_LSB) & 0x1)
> 
> -#define CQSPI_CAL_DELAY(tdelay_ns, tref_ns, tsclk_ns)  \
> -   tdelay_ns) - (tsclk_ns)) / (tref_ns)))
> -
>  #define CQSPI_GET_RD_SRAM_LEVEL(reg_base)  \
> (((readl(reg_base + CQSPI_REG_SDRAMLEVEL)) >>   \
> CQSPI_REG_SDRAMLEVEL_RD_LSB) & CQSPI_REG_SDRAMLEVEL_RD_MASK)
> @@ -357,16 +354,20 @@ void cadence_qspi_apb_delay(void *reg_base,
> cadence_qspi_apb_controller_disable(reg_base);
> 
> /* Convert to ns. */
> -   ref_clk_ns = (10) / ref_clk;
> +   ref_clk_ns = DIV_ROUND_UP(10, ref_clk);
> 
> /* Convert to ns. */
> -   sclk_ns = (10) / sclk_hz;
> -
> -   /* Plus 1 to round up 1 clock cycle. */
> -   tshsl = CQSPI_CAL_DELAY(tshsl_ns, ref_clk_ns, sclk_ns) + 1;
> -   tchsh = CQSPI_CAL_DELAY(tchsh_ns, ref_clk_ns, sclk_ns) + 1;
> -   tslch = CQSPI_CAL_DELAY(tslch_ns, ref_clk_ns, sclk_ns) + 1;
> -   tsd2d = CQSPI_CAL_DELAY(tsd2d_ns, ref_clk_ns, sclk_ns) + 1;
> +   sclk_ns = DIV_ROUND_UP(10, sclk_hz);
> +
> +   /* The controller adds additional delay to that programmed in
> the reg */
> +   if (tshsl_ns >= sclk_ns + ref_clk_ns)
> +   tshsl_ns -= sclk_ns + ref_clk_ns;
> +   if (tchsh_ns >= sclk_ns + 3 * ref_clk_ns)
> +   tchsh_ns -= sclk_ns + 3 * ref_clk_ns;
Any reason we need this?
The DIV_ROUND_UP or previous + 1 in algo will ensure its more than a
SCLK period.

Thanks
Chin Liang

> 
> +   tshsl = DIV_ROUND_UP(tshsl_ns, ref_clk_ns);
> +   tchsh = DIV_ROUND_UP(tchsh_ns, ref_clk_ns);
> +   tslch = DIV_ROUND_UP(tslch_ns, ref_clk_ns);
> +   tsd2d = DIV_ROUND_UP(tsd2d_ns, ref_clk_ns);
> 
> reg = ((tshsl & CQSPI_REG_DELAY_TSHSL_MASK)
> << CQSPI_REG_DELAY_TSHSL_LSB);
> --
> 2.7.4
> 
> 
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 01/12] arm: socfpga: stratix10: Add SOCFPGA Stratix10 base address

[See, Chin Liang]

On Min, 2016-10-16 at 17:31 +0200, Marek Vasut wrote:
> On 10/13/2016 10:32 AM, Chin Liang See wrote:
> > 
> > Add base address header file for Stratix10 SoC
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > Cc: Tien Fong Chee 
> > Acked-by: Marek Vasut 
> > ---
> >  arch/arm/mach-socfpga/include/mach/base_addr_s10.h | 48
> > ++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 arch/arm/mach-
> > socfpga/include/mach/base_addr_s10.h
> > 
> OK, V3 patch, but where's the changelog ? ;-)
> 

Oh I just added the changelog if particular patch is modified. For this
patch 1/12, no change for v2 to v3 :)

Thanks
Chin Liang


> --
> Best regards,
> Marek Vasut
> 
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/12] arm: socfpga: fpgamgr: Disable FPGA Manager for Stratix 10

[See, Chin Liang]

On Min, 2016-10-16 at 17:34 +0200, Marek Vasut wrote:
> On 10/13/2016 10:33 AM, Chin Liang See wrote:
> > 
> > Disable the FPGA Manager for Stratix 10 SoC as we are not
> > using this for SOCVP
> If it's not used on SoCVP, then shouldn't this be disabled only for
> SoCVP instead of S10 ?
> 

We will be enhancing this code to support the hardware / emulation in
later phase. In another word, will switch the support from SOCVP to
hardware once its available.

Thanks
Chin Liang

> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > Cc: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/Makefile | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > socfpga/Makefile
> > index 809cd47..a8ea277 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -8,12 +8,13 @@
> >  #
> > 
> >  obj-y+= misc.o timer.o reset_manager.o system_manager.o
> > clock_manager.o \
> > -fpga_manager.o board.o
> > +board.o
> > 
> >  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> > 
> >  # QTS-generated config file wrappers
> > -obj-$(CONFIG_TARGET_SOCFPGA_GEN5)+= scan_manager.o
> > wrap_pll_config.o
> > +obj-$(CONFIG_TARGET_SOCFPGA_GEN5)+= scan_manager.o
> > wrap_pll_config.o \
> > +fpga_manager.o
> >  obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o
> > wrap_pinmux_config.o  \
> >  wrap_sdram_config.o
> >  CFLAGS_wrap_iocsr_config.o   += -I$(srctree)/board/$(BOARDDIR)
> > 
> 
> --
> Best regards,
> Marek Vasut
> 
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 04/12] arm: socfpga: clkmgr: Separate the Clock Manager for Stratix 10

[See, Chin Liang]

On Min, 2016-10-16 at 17:33 +0200, Marek Vasut wrote:
> On 10/13/2016 10:33 AM, Chin Liang See wrote:
> > 
> > Separate the Clock Manager to support both GEN5 SoC and
> > Stratix 10 SoC.
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > Cc: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/clock_manager.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm/mach-socfpga/clock_manager.c b/arch/arm/mach-
> > socfpga/clock_manager.c
> > index aa71636..0d67b3c 100644
> > --- a/arch/arm/mach-socfpga/clock_manager.c
> > +++ b/arch/arm/mach-socfpga/clock_manager.c
> > @@ -10,6 +10,7 @@
> > 
> >  DECLARE_GLOBAL_DATA_PTR;
> > 
> > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> >  static const struct socfpga_clock_manager *clock_manager_base =
> >   (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
> > 
> > @@ -446,9 +447,11 @@ unsigned int cm_get_l4_sp_clk_hz(void)
> > 
> >   return clock;
> >  }
> > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > 
> >  unsigned int cm_get_mmc_controller_clk_hz(void)
> >  {
> > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> >   uint32_t reg, clock = 0;
> > 
> >   /* identify the source of MMC clock */
> > @@ -475,8 +478,12 @@ unsigned int
> > cm_get_mmc_controller_clk_hz(void)
> >   /* further divide by 4 as we have fixed divider at wrapper */
> >   clock /= 4;
> >   return clock;
> > +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > + return 2500;
> Is this always gonna be the case or is this S10VP specific ?
> 
> > 
> > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> >  }
> > 
> > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> >  unsigned int cm_get_qspi_controller_clk_hz(void)
> >  {
> >   uint32_t reg, clock = 0;
> > @@ -556,3 +563,4 @@ U_BOOT_CMD(
> >   "display clocks",
> >   ""
> Why does the clock display not work on S10 ? Are some functions
> missing?

Not for SOCVP. But will be added in later stage when testing against
emulation

> 
> Maybe we should split the clock manager into common part and then
> gen5
> and gen10 specific parts ?

Ok, we can do that as initially we were worried too many files created
within mach-socfpga.

Thanks
Chin Liang

> 
> > 
> >  );
> > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > 
> 
> --
> Best regards,
> Marek Vasut
> 
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot