Re: [PATCH v3 07/15] dt-bindings: memory: ns3: update GIC LPI address
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
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
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
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
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
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
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
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
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
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
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
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
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
'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
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
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
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