Re: [PATCH v3 07/15] dt-bindings: memory: ns3: update GIC LPI address

2020-07-04 Thread Rayagonda Kokatanur
Hi Simon,

On Fri, Jun 26, 2020 at 6:42 AM Simon Glass  wrote:
>
> On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur
>  wrote:
> >
> > Update NS3 GIC LPI address.
> >
> > Signed-off-by: Rayagonda Kokatanur 
> > ---
> >  include/dt-bindings/memory/bcm-ns3-mc.h | 3 +++
> >  1 file changed, 3 insertions(+)
> >
>
> Reviewed-by: Simon Glass 
>
> Lower case hex
>
> Can these be in the device tree and use a driver, like syscon maybe?

I tried using a device tree and syscon driver class (UCLASS_SYSCON)
but I am facing an issue ie

When I call syscon_get_regmap() to get regmap, I am getting zero for
regmap->ranges[0].start  and regmap->ranges[0].size.
I am passing the parent node udevice pointer to syscon_get_regmap().

I could see syscon_pre_probe() is not getting called during uboot
booting, hence regmap is not initialized.

Following are my code changes:

//dt changes:
+   gic_lpi: syscon@0x8ad7 {
+   compatible = "syscon";
+   reg = <0x0 0x8ad7 0x0 0x9>;
+   status = "okay";
+   };
+
+   scr {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x6100 0x0500>;
+
+   gic: interrupt-controller@2c0 {
+   compatible = "arm,gic-v3";
+   #interrupt-cells = <3>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   interrupt-controller;
+   reg = <0x02c0 0x01>, /* GICD */
+ <0x02e0 0x60>; /* GICR */
+   regmap = <&gic_lpi>;
+   status = "okay";
+   };
+   };
+

//driver changes
+static int gic_v3_its_get_gic_addr(struct gic_v3_its_priv *priv)
+{
+   struct udevice *dev;
+   struct regmap *regmap;
+   fdt_addr_t addr;
+   int ret;
+
+   ret = uclass_first_device_err(UCLASS_IRQ, &dev);
+   if (ret && ret != -ENODEV) {
+   pr_err("%s: Canont find irq device\n", __func__);
+   return ret;
+   }
+
+   addr = dev_read_addr_index(dev, 0);
+   if (addr == FDT_ADDR_T_NONE) {
+   pr_err("%s: Failed to get GICD address\n", __func__);
+   return -EINVAL;
+   }
+   priv->gicd_base = addr;
+
+   regmap = syscon_get_regmap(dev);
+   if (!regmap) {
+   pr_err("%s: ** unable to find gic-lpi device\n", __func__);
+   return -ENODEV;
+   }
+
+   priv->lpi_base = regmap->ranges[0].start;
+
+   return 0;
+}

//defconfig changes
 CONFIG_DM=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_DM_GPIO=y

If I call uclass_first_device_err(UCLASS_SYSCON, &dev) before
syscon_get_regmap(dev) then it works.
Do I need to explicitly call uclass_first_device_err(UCLASS_SYSCON, &dev).

Please let me know.

Best regards,
Rayagonda

>
>
> > diff --git a/include/dt-bindings/memory/bcm-ns3-mc.h 
> > b/include/dt-bindings/memory/bcm-ns3-mc.h
> > index b4f78584a5..d6e7717ba2 100644
> > --- a/include/dt-bindings/memory/bcm-ns3-mc.h
> > +++ b/include/dt-bindings/memory/bcm-ns3-mc.h
> > @@ -31,4 +31,7 @@
> >  #define BCM_NS3_MEM_CRMU_PT_START  0x88000
> >  #define BCM_NS3_MEM_CRMU_PT_LEN0x20
> >
> > +#define BCM_NS3_GIC_LPI_BASE  0x8AD7
> > +#define BCM_NS3_GIC_LPI_SIZE  0x9
> > +
> >  #endif
> > --
> > 2.17.1
> >


Re: [PATCHv4 02/16] net: fsl_mdio: Correct the MII management register block address

2020-07-04 Thread Vladimir Oltean
On Thu, Jul 02, 2020 at 12:58:43AM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> The MII management register block offset is different between
> gianfar and etsec2 compatible devices, this patch is to fix
> this issue by adding driver data for different compatible
> string.
> 
> Fixes: 2932c5a802a9 ("net: tsec: fsl_mdio: add DM MDIO support")
> Signed-off-by: Hou Zhiqiang 
> ---

Reviewed-by: Vladimir Oltean 

> V4:
>  - No change.
> 
>  drivers/net/fsl_mdio.c | 28 ++--
>  include/fsl_mdio.h |  4 
>  2 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
> index e52daa214d..5b615d50f6 100644
> --- a/drivers/net/fsl_mdio.c
> +++ b/drivers/net/fsl_mdio.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_DM_MDIO
>  struct tsec_mdio_priv {
> @@ -190,17 +191,30 @@ static const struct mdio_ops tsec_mdio_ops = {
>   .reset = tsec_mdio_reset,
>  };
>  
> +static struct fsl_pq_mdio_data etsec2_data = {
> + .mdio_regs_off = TSEC_MDIO_REGS_OFFSET,
> +};
> +
> +static struct fsl_pq_mdio_data gianfar_data = {
> + .mdio_regs_off = 0x0,
> +};
> +
> +static struct fsl_pq_mdio_data fman_data = {
> + .mdio_regs_off = 0x0,
> +};
> +
>  static const struct udevice_id tsec_mdio_ids[] = {
> - { .compatible = "fsl,gianfar-tbi" },
> - { .compatible = "fsl,gianfar-mdio" },
> - { .compatible = "fsl,etsec2-tbi" },
> - { .compatible = "fsl,etsec2-mdio" },
> - { .compatible = "fsl,fman-mdio" },
> + { .compatible = "fsl,gianfar-tbi", .data = (ulong)&gianfar_data },
> + { .compatible = "fsl,gianfar-mdio", .data = (ulong)&gianfar_data },
> + { .compatible = "fsl,etsec2-tbi", .data = (ulong)&etsec2_data },
> + { .compatible = "fsl,etsec2-mdio", .data = (ulong)&etsec2_data },
> + { .compatible = "fsl,fman-mdio", .data = (ulong)&fman_data },
>   {}
>  };
>  
>  static int tsec_mdio_probe(struct udevice *dev)
>  {
> + struct fsl_pq_mdio_data *data;
>   struct tsec_mdio_priv *priv = (dev) ? dev_get_priv(dev) : NULL;
>   struct mdio_perdev_priv *pdata = (dev) ? dev_get_uclass_priv(dev) :
>NULL;
> @@ -213,7 +227,9 @@ static int tsec_mdio_probe(struct udevice *dev)
>   printf("dev_get_priv(dev %p) = NULL\n", dev);
>   return -1;
>   }
> - priv->regs = dev_remap_addr(dev);
> +
> + data = (struct fsl_pq_mdio_data *)dev_get_driver_data(dev);
> + priv->regs = dev_remap_addr(dev) + data->mdio_regs_off;
>   debug("%s priv %p @ regs %p, pdata %p\n", __func__,
> priv, priv->regs, pdata);
>  
> diff --git a/include/fsl_mdio.h b/include/fsl_mdio.h
> index 8857d50910..cd612c0954 100644
> --- a/include/fsl_mdio.h
> +++ b/include/fsl_mdio.h
> @@ -55,6 +55,10 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, 
> int dev_addr,
>   int regnum);
>  int memac_mdio_reset(struct mii_dev *bus);
>  
> +struct fsl_pq_mdio_data {
> + u32 mdio_regs_off;
> +};
> +
>  struct fsl_pq_mdio_info {
>   struct tsec_mii_mng __iomem *regs;
>   char *name;
> -- 
> 2.25.1
> 


Re: [PATCHv4 06/16] powerpc: mpc8xxx: Don't compile cpu_eth_init() when DM_ETH enabled

2020-07-04 Thread Vladimir Oltean
On Thu, Jul 02, 2020 at 12:58:47AM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> The cpu_eth_init() is only used by the legacy ethernet driver framework.
> 
> Signed-off-by: Hou Zhiqiang 
> ---

Reviewed-by: Vladimir Oltean 

> V4:
>  - No change.
> 
>  arch/powerpc/cpu/mpc8xxx/cpu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/cpu/mpc8xxx/cpu.c b/arch/powerpc/cpu/mpc8xxx/cpu.c
> index da0a80e6fc..b904943b0e 100644
> --- a/arch/powerpc/cpu/mpc8xxx/cpu.c
> +++ b/arch/powerpc/cpu/mpc8xxx/cpu.c
> @@ -347,6 +347,7 @@ int fixup_cpu(void)
>   * Initializes on-chip ethernet controllers.
>   * to override, implement board_eth_init()
>   */
> +#ifndef CONFIG_DM_ETH
>  int cpu_eth_init(bd_t *bis)
>  {
>  #if defined(CONFIG_ETHER_ON_FCC)
> @@ -370,3 +371,4 @@ int cpu_eth_init(bd_t *bis)
>  #endif
>   return 0;
>  }
> +#endif
> -- 
> 2.25.1
> 


Re: [PATCHv4 09/16] dts: powerpc: p1020rdb: Add eTSEC DT nodes

2020-07-04 Thread Vladimir Oltean
On Thu, Jul 02, 2020 at 12:58:50AM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> P1020RDB implements 3 enhanced three-speed Ethernet controllers,
> and the connection is shown below:
> eTSEC1: Connected to RGMII switch VSC7385
> eTSEC2: Connected to SGMII PHY VSC8221
> eTSEC3: Connected to SGMII PHY AR8021
> 
> Signed-off-by: Hou Zhiqiang 
> ---

Reviewed-by: Vladimir Oltean 

> V4:
>  - Remove the ptp_clock node.
>  - Modify the change log slightly.
> 
>  arch/powerpc/dts/p1020-post.dtsi| 20 -
>  arch/powerpc/dts/p1020rdb-pc.dts|  1 +
>  arch/powerpc/dts/p1020rdb-pc.dtsi   | 55 +
>  arch/powerpc/dts/p1020rdb-pc_36b.dts|  1 +
>  arch/powerpc/dts/p1020rdb-pd.dts| 45 
>  arch/powerpc/dts/pq3-etsec2-0.dtsi  | 35 
>  arch/powerpc/dts/pq3-etsec2-1.dtsi  | 35 
>  arch/powerpc/dts/pq3-etsec2-2.dtsi  | 35 
>  arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi | 16 +++
>  arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi | 16 +++
>  arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi | 16 +++
>  11 files changed, 273 insertions(+), 2 deletions(-)
>  create mode 100644 arch/powerpc/dts/p1020rdb-pc.dtsi
>  create mode 100644 arch/powerpc/dts/pq3-etsec2-0.dtsi
>  create mode 100644 arch/powerpc/dts/pq3-etsec2-1.dtsi
>  create mode 100644 arch/powerpc/dts/pq3-etsec2-2.dtsi
>  create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi
>  create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi
>  create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi
> 
> diff --git a/arch/powerpc/dts/p1020-post.dtsi 
> b/arch/powerpc/dts/p1020-post.dtsi
> index 1dce8e86e9..c73539ad5c 100644
> --- a/arch/powerpc/dts/p1020-post.dtsi
> +++ b/arch/powerpc/dts/p1020-post.dtsi
> @@ -44,10 +44,26 @@
>   clock-frequency = <0>;
>   };
>  
> - /include/ "pq3-i2c-0.dtsi"
> - /include/ "pq3-i2c-1.dtsi"
> +/include/ "pq3-i2c-0.dtsi"
> +/include/ "pq3-i2c-1.dtsi"
> +
> +/include/ "pq3-etsec2-0.dtsi"
> + enet0: enet0_grp2: ethernet@b {
> + };
> +
> +/include/ "pq3-etsec2-1.dtsi"
> + enet1: enet1_grp2: ethernet@b1000 {
> + };
> +
> +/include/ "pq3-etsec2-2.dtsi"
> + enet2: enet2_grp2: ethernet@b2000 {
> + };
>  };
>  
> +/include/ "pq3-etsec2-grp2-0.dtsi"
> +/include/ "pq3-etsec2-grp2-1.dtsi"
> +/include/ "pq3-etsec2-grp2-2.dtsi"
> +
>  /* PCIe controller base address 0x9000 */
>  &pci1 {
>   compatible = "fsl,pcie-p1_p2", "fsl,pcie-fsl-qoriq";
> diff --git a/arch/powerpc/dts/p1020rdb-pc.dts 
> b/arch/powerpc/dts/p1020rdb-pc.dts
> index 7ebaa619df..715330dc50 100644
> --- a/arch/powerpc/dts/p1020rdb-pc.dts
> +++ b/arch/powerpc/dts/p1020rdb-pc.dts
> @@ -32,4 +32,5 @@
>   };
>  };
>  
> +/include/ "p1020rdb-pc.dtsi"
>  /include/ "p1020-post.dtsi"
> diff --git a/arch/powerpc/dts/p1020rdb-pc.dtsi 
> b/arch/powerpc/dts/p1020rdb-pc.dtsi
> new file mode 100644
> index 00..6bf424fd3f
> --- /dev/null
> +++ b/arch/powerpc/dts/p1020rdb-pc.dtsi
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * P1020 RDB-PC Device Tree Source stub (no addresses or top-level ranges)
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + * Copyright 2020 NXP
> + */
> +
> +&soc {
> + mdio@24000 {
> + phy0: ethernet-phy@0 {
> + interrupt-parent = <&mpic>;
> + interrupts = <3 1 0 0>;
> + reg = <0x0>;
> + };
> +
> + phy1: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <2 1 0 0>;
> + reg = <0x1>;
> + };
> +
> + tbi0: tbi-phy@11 {
> + device_type = "tbi-phy";
> + reg = <0x11>;
> + };
> + };
> +
> + mdio@25000 {
> + tbi1: tbi-phy@11 {
> + reg = <0x11>;
> + device_type = "tbi-phy";
> + };
> + };
> +
> + enet0: ethernet@b {
> + phy-connection-type = "rgmii-id";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +
> + };
> +
> + enet1: ethernet@b1000 {
> + phy-handle = <&phy0>;
> + tbi-handle = <&tbi1>;
> + phy-connection-type = "sgmii";
> + };
> +
> + enet2: ethernet@b2000 {
> + phy-handle = <&phy1>;
> + phy-connection-type = "rgmii-id";
> + };
> +};
> diff --git a/arch/powerpc/dts/p1020rdb-pc_36b.dts 
> b/arch/powerpc/dts/p1020rdb-pc_36b.dts
> index c0e5ef4cf4..7680b7c7e1 100644
> --- a/arch/powerpc/dts/p1020rdb-pc_36b.dts
> +++ b/arch/powerpc/dts/p1020rdb-pc_36b.dts
> @@ -32,4 +32,5 @@
>   };
>  };
>  
> +/include/ "p1020rdb-pc.dtsi"
>  /include/ "p1020-post.dtsi"
> diff --git a/arch/powerpc/dts/p1020rdb-pd.dts 
> b/arch/powerpc/dts/p1020rdb-p

Re: [PATCHv4 10/16] powerpc: p1_p2_rdb: Don't compile board_eth_init() when DM_ETH enabled

2020-07-04 Thread Vladimir Oltean
On Thu, Jul 02, 2020 at 12:58:51AM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> The board_eth_init() is only used by legacy ethernet driver framework,
> so do not compile it when DM_ETH config has been selected.
> 
> Signed-off-by: Hou Zhiqiang 
> ---

Reviewed-by: Vladimir Oltean 

> V4:
>  - No change.
> 
>  board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
> b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
> index 3dd6178708..41585cf342 100644
> --- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
> +++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
> @@ -359,6 +359,7 @@ int board_early_init_r(void)
>   return 0;
>  }
>  
> +#ifndef CONFIG_DM_ETH
>  int board_eth_init(bd_t *bis)
>  {
>   struct fsl_pq_mdio_info mdio_info;
> @@ -406,6 +407,7 @@ int board_eth_init(bd_t *bis)
>  
>   return pci_eth_init(bis);
>  }
> +#endif
>  
>  #if defined(CONFIG_QE) && \
>   (defined(CONFIG_TARGET_P1025RDB) || defined(CONFIG_TARGET_P1021RDB))
> -- 
> 2.25.1
> 


Re: [PATCHv4 13/16] powerpc: p1010rdb: Compile legacy ethernet init function when no DM_ETH

2020-07-04 Thread Vladimir Oltean
On Thu, Jul 02, 2020 at 12:58:54AM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> The board_eth_init() is only used by legacy ethernet driver framework,
> so do not compile it when DM_ETH config has been selected.
> 
> Signed-off-by: Hou Zhiqiang 
> ---

Reviewed-by: Vladimir Oltean 

> V4:
>  - No change.
> 
>  board/freescale/p1010rdb/p1010rdb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/board/freescale/p1010rdb/p1010rdb.c 
> b/board/freescale/p1010rdb/p1010rdb.c
> index 66ccc0bd1e..309f4daa88 100644
> --- a/board/freescale/p1010rdb/p1010rdb.c
> +++ b/board/freescale/p1010rdb/p1010rdb.c
> @@ -484,6 +484,7 @@ int checkboard(void)
>   return 0;
>  }
>  
> +#ifndef CONFIG_DM_ETH
>  int board_eth_init(bd_t *bis)
>  {
>  #ifdef CONFIG_TSEC_ENET
> @@ -524,6 +525,7 @@ int board_eth_init(bd_t *bis)
>  
>   return pci_eth_init(bis);
>  }
> +#endif
>  
>  #if defined(CONFIG_OF_BOARD_SETUP)
>  void fdt_del_flexcan(void *blob)
> -- 
> 2.25.1
> 


Re: [PATCH] rockchip: rk3288: Add OF board setup

2020-07-04 Thread Jagan Teki
On Fri, Jul 3, 2020 at 7:34 PM Jagan Teki  wrote:
>
> On Fri, Jul 3, 2020 at 6:09 PM Robin Murphy  wrote:
> >
> > On 2020-07-03 11:10, Jagan Teki wrote:
> > > On Thu, Jul 2, 2020 at 7:26 PM Robin Murphy  wrote:
> > >>
> > >> On 2020-07-02 09:48, Jagan Teki wrote:
> > >>> The new rk3288 revision rk3288w has some changes with respect
> > >>> to legacy rk3288 like hclk_vio and usb host0 ohci.
> > >>>
> > >>> In order to work these on the same in Linux kernel update the
> > >>> compatible the root compatible with rockchip,rk3288w before
> > >>> booting.
> > >>>
> > >>> So, this support during of board setup code of rk3288.
> > >>>
> > >>> Signed-off-by: Jagan Teki 
> > >>> ---
> > >>>arch/arm/mach-rockchip/Kconfig |  1 +
> > >>>arch/arm/mach-rockchip/rk3288/rk3288.c | 26 
> > >>> ++
> > >>>2 files changed, 27 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm/mach-rockchip/Kconfig 
> > >>> b/arch/arm/mach-rockchip/Kconfig
> > >>> index b1008a5058..822d8d4e9c 100644
> > >>> --- a/arch/arm/mach-rockchip/Kconfig
> > >>> +++ b/arch/arm/mach-rockchip/Kconfig
> > >>> @@ -98,6 +98,7 @@ config ROCKCHIP_RK322X
> > >>>config ROCKCHIP_RK3288
> > >>>bool "Support Rockchip RK3288"
> > >>>select CPU_V7A
> > >>> + select OF_BOARD_SETUP
> > >>>select SUPPORT_SPL
> > >>>select SPL
> > >>>select SUPPORT_TPL
> > >>> diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
> > >>> b/arch/arm/mach-rockchip/rk3288/rk3288.c
> > >>> index 804abe8a1b..8a682675e6 100644
> > >>> --- a/arch/arm/mach-rockchip/rk3288/rk3288.c
> > >>> +++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
> > >>> @@ -115,6 +115,32 @@ int rk_board_late_init(void)
> > >>>return rk3288_board_late_init();
> > >>>}
> > >>>
> > >>> +#ifdef CONFIG_OF_BOARD_SETUP
> > >>> +
> > >>> +#define RK3288_HDMI_PHYS 0xff98
> > >>> +#define RK3288W_HDMI_REV 0x1A
> > >>> +#define HDMI_CONFIG0_ID  0x04
> > >>> +
> > >>> +int ft_board_setup(void *blob, bd_t *bd)
> > >>> +{
> > >>> + u8 config0;
> > >>> + int ret;
> > >>> +
> > >>> + config0 = readb(RK3288_HDMI_PHYS + HDMI_CONFIG0_ID);
> > >>> + if (config0 == RK3288W_HDMI_REV) {
> > >>> + ret = fdt_setprop_string(blob, 0,
> > >>> +  "compatible", 
> > >>> "rockchip,rk3288w");
> > >>
> > >> Does this end up replacing the entire top-level compatible property?
> > >> i.e. from:
> > >>
> > >>  compatible = "vendor,board\0rockchip,rk3288";
> > >>
> > >> to just:
> > >>
> > >>  compatible = "rockchip,rk3288w";
> > >>
> > >> If so, that's a bit of a problem for various drivers that care about the
> > >> actual board compatible rather than the SoC.
> > >
> > > Yes, It looks replacing the entire compatible. I think the root
> > > compatible is mostly untouchable because of this reason.
> > >
> > > But, if we skip the root compatible and trying to replace individual
> > > nodes for W revision then it requires extra registration code on in
> > > the Linux drivers like Linux clock driver is registering the clock
> > > with rockchip,rk3288-cru but updating this compatible with
> > > rockchip,rk3288w-cru will require another registration code. Having
> > > common rockchip,rk3288w can be possible to check any code in the tree.
> >
> > Right, it's definitely reasonable to update the top-level SoC
> > compatible, we just need to be prepared to deal with a whole string list
> > here. It looks like libfdt doesn't offer any nice helpers for
> > inserting/removing/updating in string lists, but given that the SoC
> > should be the last entry here we might be able to cheat a bit - just get
> > the whole raw property, check that the final characters are exactly
> > "rockchip,rk3288", and if so append a "w" to the end and write it back.
>
> Look like exiting fdt helper does print the compatible up to \0
> instead of whole root compatible, at least I have checked with
> fdt_getpro and fdt_get_property.

Look like we didn't have any requirement to change the root compatible
at this point since disabling ohci driver for legacy rk3288 revision
chips of no use.


Jagan.


[PATCH v2 1/2] rockchip: Add SoC detection helper

2020-07-04 Thread Jagan Teki
Rockchip SoC's has a new revision chip for rk3288, rk3308
based SoCs.

RK3288 has a new revision chip called RK3288W which is relevantly
similar but different hclk_vio clock and working ohci host.

Add common rockchip SoC detection helper to support this rk3288w
detection.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- new patch

 arch/arm/include/asm/arch-rockchip/cpu.h | 49 
 1 file changed, 49 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rockchip/cpu.h

diff --git a/arch/arm/include/asm/arch-rockchip/cpu.h 
b/arch/arm/include/asm/arch-rockchip/cpu.h
new file mode 100644
index 00..d0d22e4967
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/cpu.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0+  */
+/*
+ * Rockchip Electronics Co., Ltd.
+ */
+
+#ifndef __ASM_ARCH_CPU_H
+#define __ASM_ARCH_CPU_H
+
+#include 
+
+#define ROCKCHIP_CPU_MASK   0x
+#define ROCKCHIP_CPU_RK3288 0x3288
+
+#define ROCKCHIP_SOC_MASK  (ROCKCHIP_CPU_MASK | 0xff)
+#define ROCKCHIP_SOC_RK3288 (ROCKCHIP_CPU_RK3288 | 0x00)
+#define ROCKCHIP_SOC_RK3288W(ROCKCHIP_CPU_RK3288 | 0x01)
+
+#define RK3288_HDMI_PHYS   0xff98
+#define HDMI_CONFIG0_ID0x4
+#define RK3288W_HDMI_REVID 0x1a
+
+static inline int rockchip_soc_id(void)
+{
+   u8 reg;
+
+#if defined(CONFIG_ROCKCHIP_RK3288)
+   reg = readb(RK3288_HDMI_PHYS + HDMI_CONFIG0_ID);
+   if (reg == RK3288W_HDMI_REVID)
+   return ROCKCHIP_SOC_RK3288W;
+   else
+   return ROCKCHIP_SOC_RK3288;
+#else
+   return 0;
+#endif
+}
+
+#define ROCKCHIP_SOC(id, ID) \
+static inline bool soc_is_##id(void) \
+{ \
+   int soc_id = rockchip_soc_id(); \
+   if (soc_id) \
+   return ((soc_id & ROCKCHIP_SOC_MASK) == ROCKCHIP_SOC_ ##ID); \
+   return false; \
+}
+
+ROCKCHIP_SOC(rk3288, RK3288)
+ROCKCHIP_SOC(rk3288w, RK3288W)
+
+#endif
-- 
2.25.1



[PATCH v2 2/2] rockchip: rk3288: Add OF board setup

2020-07-04 Thread Jagan Teki
The new rk3288 revision rk3288w has some changes with respect
to legacy rk3288 like hclk_vio in cru and usb host0 ohci.

Linux clock driver already handle this via rockchip,rk3288w-cru
compatible.

USB ohci host can enable via dts for rk3288w based boards.

So, add fdt board setup code to update cru compatible with
rk3288w-cru compatible if the SOC revision is RK3288W.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- use soc detection helper
- add cru compatible change for rk3288w

 arch/arm/mach-rockchip/Kconfig |  1 +
 arch/arm/mach-rockchip/rk3288/rk3288.c | 33 ++
 2 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index b1008a5058..822d8d4e9c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -98,6 +98,7 @@ config ROCKCHIP_RK322X
 config ROCKCHIP_RK3288
bool "Support Rockchip RK3288"
select CPU_V7A
+   select OF_BOARD_SETUP
select SUPPORT_SPL
select SPL
select SUPPORT_TPL
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index 804abe8a1b..9c873d2b6a 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -115,6 +116,38 @@ int rk_board_late_init(void)
return rk3288_board_late_init();
 }
 
+#if defined(CONFIG_OF_BOARD_SETUP)
+
+static int ft_rk3288w_setup(void *blob)
+{
+   const char *path;
+   int offs, ret;
+
+   path = "/clock-controller@ff76";
+   offs = fdt_path_offset(blob, path);
+   if (offs < 0) {
+   debug("failed to found fdt path %s\n", path);
+   return offs;
+   }
+
+   ret = fdt_setprop_string(blob, offs, "compatible", 
"rockchip,rk3288w-cru");
+   if (ret) {
+   printf("failed to set rk3288w-cru compatible (ret=%d)\n", ret);
+   return ret;
+   }
+
+   return ret;
+}
+
+int ft_board_setup(void *blob, bd_t *bd)
+{
+   if (soc_is_rk3288w())
+   return ft_rk3288w_setup(blob);
+
+   return 0;
+}
+#endif
+
 static int do_clock(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
 {
-- 
2.25.1



Pull request for UEFI sub-system for efi-2020-10-rc1

2020-07-04 Thread Heinrich Schuchardt
The following changes since commit bcfe764ee925d0820e82c69ccf75b71d142644c7:

  Merge tag 'efi-2020-07-rc6-2' of
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-30 17:15:39
-0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2020-10-rc1

for you to fetch changes up to 93f6201af71d9a0a521c99212e6066778270a357:

  efi_loader: imply FAT, FAT_WRITE (2020-07-03 18:03:56 +0200)


Pull request for UEFI sub-system for efi-2020-10-rc1

This series comprises error corrections for the UEFI subsystem:

* correct consideration of timestamps for variable authentication
* correct collection of data regions for code authentication
* correct unit tests to test loading dbx
* enable FAT_WRITE as required by the UEFI spec

The boot manager uses log functions instead of printf() and debug().

The UEFI intialization state is exported.


AKASHI Takahiro (7):
  efi_loader: change efi objects initialization order
  Revert "test: stabilize test_efi_secboot"
  efi_loader: signature: replace debug to EFI_PRINT
  efi_loader: variable: replace debug to EFI_PRINT
  efi_loader: image_loader: replace debug to EFI_PRINT
  test/py: efi_secboot: remove all "re.search"
  test/py: efi_secboot: fix test case 1g of test_authvar

Heinrich Schuchardt (9):
  test: correct time stamps for UEFI authentication
  efi_loader: fix efi_image_region_add()
  test: provide tests for efi_image_region_add()
  efi_loader: add missing validation of timestamp
  efi_loader: time based authentication
  efi_loader: use log function in boot manager
  efi_loader: rtc_mktime() called twice
  efi_loader: export initialization state
  efi_loader: imply FAT, FAT_WRITE

 MAINTAINERS |   1 +
 include/efi_loader.h|   3 +
 lib/efi_loader/Kconfig  |   2 +
 lib/efi_loader/efi_bootmgr.c|  26 ++--
 lib/efi_loader/efi_image_loader.c   |  64 +-
 lib/efi_loader/efi_setup.c  |   9 +-
 lib/efi_loader/efi_signature.c  | 152
+++---
 lib/efi_loader/efi_variable.c   |  52 +---
 test/lib/Makefile   |   1 +
 test/lib/efi_image_region.c | 163

 test/py/tests/test_efi_secboot/conftest.py  |  16 +--
 test/py/tests/test_efi_secboot/test_authvar.py  |  91 +++--
 test/py/tests/test_efi_secboot/test_signed.py   |  38 +++---
 test/py/tests/test_efi_secboot/test_unsigned.py |  38 +++---
 14 files changed, 420 insertions(+), 236 deletions(-)
 create mode 100644 test/lib/efi_image_region.c



[PATCH 1/1] arm-freescale-mx6sx: Fix imx6sx UART5 wrong iomux register configuration

2020-07-04 Thread Antonio Tessarolo
This patch fixes a wrong IOMUX configuration for UART5_TX of NXP’s IMX6SX

---
 arch/arm/include/asm/arch-mx6/mx6sx_pins.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
b/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
index a18e08f65c..f5c8bbf0a1 100644
--- a/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
@@ -1615,7 +1615,7 @@ enum {

  MX6_PAD_SD4_DATA5__USDHC4_DATA5=
IOMUX_PAD(0x05DC, 0x0294, 0, 0x, 0, 0),
  MX6_PAD_SD4_DATA5__RAWNAND_CE2_B   =
IOMUX_PAD(0x05DC, 0x0294, 1, 0x, 0, 0),
- MX6_PAD_SD4_DATA5__UART5_TX=
IOMUX_PAD(0x05DC, 0x0294, 2, 0x0850, 1, 0),
+ MX6_PAD_SD4_DATA5__UART5_TX=
IOMUX_PAD(0x05DC, 0x0294, 2, 0x, 0, 0),
  MX6_PAD_SD4_DATA5__ECSPI3_MOSI =
IOMUX_PAD(0x05DC, 0x0294, 3, 0x0738, 0, 0),
  MX6_PAD_SD4_DATA5__LCDIF2_DATA_7   =
IOMUX_PAD(0x05DC, 0x0294, 4, 0x, 0, 0),
  MX6_PAD_SD4_DATA5__GPIO6_IO_19 =
IOMUX_PAD(0x05DC, 0x0294, 5, 0x, 0, 0),
-- 
2.26.2


Re: [maemo-leste] [PATCH] mmc: omap_hsmmc: Set 3.3V for IO voltage on all places

2020-07-04 Thread Pavel Machek
On Fri 2020-07-03 22:58:23, Pali Rohár wrote:
> In commit commit d2c05f50e12f ("mmc: omap_hsmmc: Set 3.3V for IO voltage")
> was changed 3.0V IO voltage to 3.3V but it was not done on all places in
> omap_hsmmc driver. That commit broke eMMC support on Nokia N900.
> 
> This patch fixes that problematic commit and changes 3.0V to 3.3V on all
> remaining places in omap_hsmmc driver.
> 
> Fixes: d2c05f50e12f ("mmc: omap_hsmmc: Set 3.3V for IO voltage")
> Signed-off-by: Pali Rohár 

Acked-by: Pavel Machek 

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


signature.asc
Description: Digital signature


Re: [PATCH 1/1] arm-freescale-mx6sx: Fix imx6sx UART5 wrong iomux register configuration

2020-07-04 Thread Fabio Estevam
Hi Antonio,

Thanks for your patch.

On Sat, Jul 4, 2020 at 8:43 AM Antonio Tessarolo
 wrote:
>
> This patch fixes a wrong IOMUX configuration for UART5_TX of NXP’s IMX6SX
>
> ---

You missed your Signed-off-by tag.

>  arch/arm/include/asm/arch-mx6/mx6sx_pins.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
> b/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
> index a18e08f65c..f5c8bbf0a1 100644
> --- a/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
> +++ b/arch/arm/include/asm/arch-mx6/mx6sx_pins.h
> @@ -1615,7 +1615,7 @@ enum {
>
>   MX6_PAD_SD4_DATA5__USDHC4_DATA5=
> IOMUX_PAD(0x05DC, 0x0294, 0, 0x, 0, 0),
>   MX6_PAD_SD4_DATA5__RAWNAND_CE2_B   =
> IOMUX_PAD(0x05DC, 0x0294, 1, 0x, 0, 0),
> - MX6_PAD_SD4_DATA5__UART5_TX=
> IOMUX_PAD(0x05DC, 0x0294, 2, 0x0850, 1, 0),
> + MX6_PAD_SD4_DATA5__UART5_TX=
> IOMUX_PAD(0x05DC, 0x0294, 2, 0x, 0, 0),

In the kernel we have:

#define MX6SX_PAD_SD4_DATA5__UART5_DCE_TX
0x0294 0x05DC 0x 0x2 0x0
#define MX6SX_PAD_SD4_DATA5__UART5_DTE_RX
0x0294 0x05DC 0x0850 0x2 0x1

In mx6sx_pins.h there is only the DTE definition.

I would suggest to add the DCE definition and keep the DTE one.


[PATCH] x86: remove unused setup_pcat_compatibility() stub

2020-07-04 Thread Masahiro Yamada
'git grep' did not find any user of this stub.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/include/asm/u-boot-x86.h |  2 --
 arch/x86/lib/zimage.c | 10 --
 2 files changed, 12 deletions(-)

diff --git a/arch/x86/include/asm/u-boot-x86.h 
b/arch/x86/include/asm/u-boot-x86.h
index 3e5d56d075..054203584b 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -75,8 +75,6 @@ int default_print_cpuinfo(void);
 /* Set up a UART which can be used with printch(), printhex8(), etc. */
 int setup_internal_uart(int enable);
 
-void setup_pcat_compatibility(void);
-
 void isa_unmap_rom(u32 addr);
 u32 isa_map_rom(u32 bus_addr, int size);
 
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 64d14e8911..d2b6002008 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -304,13 +304,6 @@ int setup_zimage(struct boot_params *setup_base, char 
*cmd_line, int auto_boot,
return 0;
 }
 
-void setup_pcat_compatibility(void)
-   __attribute__((weak, alias("__setup_pcat_compatibility")));
-
-void __setup_pcat_compatibility(void)
-{
-}
-
 int do_zboot(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
struct boot_params *base_ptr;
@@ -323,9 +316,6 @@ int do_zboot(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
 
disable_interrupts();
 
-   /* Setup board for maximum PC/AT Compatibility */
-   setup_pcat_compatibility();
-
if (argc >= 2) {
/* argv[1] holds the address of the bzImage */
s = argv[1];
-- 
2.25.1



Re: [PATCH v3 07/15] dt-bindings: memory: ns3: update GIC LPI address

2020-07-04 Thread Rayagonda Kokatanur
Hi Simon,

On Sat, Jul 4, 2020 at 1:20 PM Rayagonda Kokatanur
 wrote:
>
> Hi Simon,
>
> On Fri, Jun 26, 2020 at 6:42 AM Simon Glass  wrote:
> >
> > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur
> >  wrote:
> > >
> > > Update NS3 GIC LPI address.
> > >
> > > Signed-off-by: Rayagonda Kokatanur 
> > > ---
> > >  include/dt-bindings/memory/bcm-ns3-mc.h | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> >
> > Reviewed-by: Simon Glass 
> >
> > Lower case hex
> >
> > Can these be in the device tree and use a driver, like syscon maybe?
>
> I tried using a device tree and syscon driver class (UCLASS_SYSCON)
> but I am facing an issue ie
>
> When I call syscon_get_regmap() to get regmap, I am getting zero for
> regmap->ranges[0].start  and regmap->ranges[0].size.
> I am passing the parent node udevice pointer to syscon_get_regmap().
>
> I could see syscon_pre_probe() is not getting called during uboot
> booting, hence regmap is not initialized.
>
> Following are my code changes:
>
> //dt changes:
> +   gic_lpi: syscon@0x8ad7 {
> +   compatible = "syscon";
> +   reg = <0x0 0x8ad7 0x0 0x9>;
> +   status = "okay";
> +   };
> +
> +   scr {
> +   compatible = "simple-bus";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges = <0x0 0x0 0x6100 0x0500>;
> +
> +   gic: interrupt-controller@2c0 {
> +   compatible = "arm,gic-v3";
> +   #interrupt-cells = <3>;
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +   interrupt-controller;
> +   reg = <0x02c0 0x01>, /* GICD */
> + <0x02e0 0x60>; /* GICR */
> +   regmap = <&gic_lpi>;
> +   status = "okay";
> +   };
> +   };
> +
>
> //driver changes
> +static int gic_v3_its_get_gic_addr(struct gic_v3_its_priv *priv)
> +{
> +   struct udevice *dev;
> +   struct regmap *regmap;
> +   fdt_addr_t addr;
> +   int ret;
> +
> +   ret = uclass_first_device_err(UCLASS_IRQ, &dev);
> +   if (ret && ret != -ENODEV) {
> +   pr_err("%s: Canont find irq device\n", __func__);
> +   return ret;
> +   }
> +
> +   addr = dev_read_addr_index(dev, 0);
> +   if (addr == FDT_ADDR_T_NONE) {
> +   pr_err("%s: Failed to get GICD address\n", __func__);
> +   return -EINVAL;
> +   }
> +   priv->gicd_base = addr;
> +
> +   regmap = syscon_get_regmap(dev);
> +   if (!regmap) {
> +   pr_err("%s: ** unable to find gic-lpi device\n", __func__);
> +   return -ENODEV;
> +   }
> +
> +   priv->lpi_base = regmap->ranges[0].start;
> +
> +   return 0;
> +}
>
> //defconfig changes
>  CONFIG_DM=y
> +CONFIG_REGMAP=y
> +CONFIG_SYSCON=y
>  CONFIG_DM_GPIO=y
>
> If I call uclass_first_device_err(UCLASS_SYSCON, &dev) before
> syscon_get_regmap(dev) then it works.
> Do I need to explicitly call uclass_first_device_err(UCLASS_SYSCON, &dev).
>
> Please let me know.

I used uclass_get_device_by_driver() api and it's working.
Please ignore the above question.

Thank you,
Rayagonda

>
>
> Best regards,
> Rayagonda
>
> >
> >
> > > diff --git a/include/dt-bindings/memory/bcm-ns3-mc.h 
> > > b/include/dt-bindings/memory/bcm-ns3-mc.h
> > > index b4f78584a5..d6e7717ba2 100644
> > > --- a/include/dt-bindings/memory/bcm-ns3-mc.h
> > > +++ b/include/dt-bindings/memory/bcm-ns3-mc.h
> > > @@ -31,4 +31,7 @@
> > >  #define BCM_NS3_MEM_CRMU_PT_START  0x88000
> > >  #define BCM_NS3_MEM_CRMU_PT_LEN0x20
> > >
> > > +#define BCM_NS3_GIC_LPI_BASE  0x8AD7
> > > +#define BCM_NS3_GIC_LPI_SIZE  0x9
> > > +
> > >  #endif
> > > --
> > > 2.17.1
> > >


Re: Chainloading U-Boot from Fastboot on Tegra30

2020-07-04 Thread Simon Glass
Hi Peter,

On Fri, 3 Jul 2020 at 06:33, Peter Geis  wrote:
>
> Good Morning,
>
> I am attempting to expand on the work for chainloading U-Boot on the
> nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from 
> fastboot.
> I have so far been unsuccessful at getting any output from U-Boot
> through this method.
>
> I'm building the cardhu board with tweaks for Ouya's specifications
> similar to my work for the linux kernel.
> I build the image using mkbootimg --kernel u-boot.bin --ramdisk
> /dev/null --output u-boot-android.bin.
> I then fastboot boot u-boot-android.bin.
>
> I've tried tweaking the text base and tried both standard debug and
> low level debug.
>
> Do you think you could give me some insight into where I'm going wrong?

Is it possible that fastboot expects a relocatable image? If you set
up the debug UART very early you might be able to output a character
in start.S ?

BTW does U-Boot have support for the fastboot protocol? Perhaps you
could just use U-Boot?

Regards,
Simon


efi_loader: secure mode transitions, VendorKeys

2020-07-04 Thread Heinrich Schuchardt
Hello Takahiro,

in the current code you have left a comment:

    /*
 * TODO:
 * Since there is currently no "platform-specific" installation
 * method of Platform Key, we can't say if VendorKeys is 0 or 1
 * precisely.
 */

We do not supply vendor keys. So currently any secure boot setup is
defined by a user and not by the vendor. So we should keep this variable
at zero.

EDK2's way to keep track of changes to Secure Boot Policy Variables is a
non-volatile variable VendorKeysNv which is set to 1 when first created
and to 0 (in VendorKeyIsModified()) upon the first relevant change. EDK2
ignores changes in setup mode.

According to the UEFI specification Secure Boot Policy Variables are:

* PK, KEK, OsRecoveryOrder, OsRecovery
* variables with EFI_IMAGE_SECURITY_DATABASE_GUID

efi_set_secure_state() currently sets all mode variables to read-only.
This should only be the case in Audit Mode and Deployed Mode, see figure
90 "Secure Modes" in the 2.8A spec.

Best regards

Heinrich