[PATCH] rockchip: px30: Define variables for compressed image support

[Paul Kocialkowski]

The standard boot path expects the kernel_comp_addr_r and kernel_comp_size
variables for booting compressed kernel images. Define them using the previous
kernel_addr_c value (likely initially meant for this purpose) and usual size.

This was tested on the PX30 EVB to successfully boot compressed Linux kernel
images.

Signed-off-by: Paul Kocialkowski 
---
 include/configs/px30_common.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/configs/px30_common.h b/include/configs/px30_common.h
index 6fbd2679f099..13ed9011764b 100644
--- a/include/configs/px30_common.h
+++ b/include/configs/px30_common.h
@@ -21,8 +21,9 @@
"pxefile_addr_r=0x0060\0" \
"fdt_addr_r=0x0830\0" \
"kernel_addr_r=0x0028\0" \
-   "kernel_addr_c=0x03e8\0" \
-   "ramdisk_addr_r=0x0a20\0"
+   "ramdisk_addr_r=0x0a20\0" \
+   "kernel_comp_addr_r=0x03e8\0" \
+   "kernel_comp_size=0x200\0"
 
 #define CFG_EXTRA_ENV_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
-- 
2.41.0

Re: [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB

[Paul Kocialkowski]

Hi Andre,

Le Wed 26 May 21, 01:57, Andre Przywara a écrit :
> From: Paul Kocialkowski 
> 
> Recent Allwinner platforms (starting with the H3) only use the MUSB
> controller for peripheral mode and use HCI for host mode. As a result,
> extra steps need to be taken to properly route USB signals to one or
> the other. More precisely, the following is required:
> * Routing the pins to either HCI/MUSB (controlled by PHY);
> * Enabling USB PHY passby in HCI mode (controlled by PMU).
> 
> The current code will enable passby for each PHY and reroute PHY0 to
> MUSB, which is inconsistent and results in broken USB host support
> for port 0.
> 
> Passby on PHY0 must only be enabled when we want to use HCI. Since
> host/device mode detection is not available from the PHY code and
> because U-Boot does not support changing the mode dynamically anyway,
> we can just mux the controller to MUSB if it is enabled and mux it to
> HCI otherwise.
> 
> This fixes USB host support for port 0 on platforms with PHY0 dual-route,
> especially on boards like Pine64 (with only USB-A host ports) and
> TV boxes without OTG ports.
> 
> Signed-off-by: Paul Kocialkowski 
> [Andre: tweak commit message, use IS_ENABLED()]
> Signed-off-by: Andre Przywara 
> ---
> Hi,
> 
> for H6 boards to work this requires a DT update (to get the < 0>
> links between HCI and PHY), which I will send later.
> Tested on Pine H64, Pine64-LTS, OrangePi Zero, OrangePi PC 2, BananaPi M64,
> BananaPi M1.

Thanks for resending this, I've also had to revive this patch lately to get
USB working on the V3 so I definitely second that it's still relevant!

Paul

> Cheers,
> Andre
> 
>  drivers/phy/allwinner/phy-sun4i-usb.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 5723c980323..e6ceafc7648 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -313,9 +313,21 @@ static int sun4i_usb_phy_init(struct phy *phy)
>   data->cfg->disc_thresh, PHY_DISCON_TH_LEN);
>   }
>  
> - sun4i_usb_phy_passby(phy, true);
> + if (IS_ENABLED(CONFIG_USB_MUSB_SUNXI)) {
> + /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */
> + if (usb_phy->id != 0)
> + sun4i_usb_phy_passby(phy, true);
> +
> + /* Route PHY0 to MUSB to allow USB gadget */
> + if (data->cfg->phy0_dual_route)
> + sun4i_usb_phy0_reroute(data, true);
> + } else {
> + sun4i_usb_phy_passby(phy, true);
>  
> - sun4i_usb_phy0_reroute(data, true);
> + /* Route PHY0 to HCI to allow USB host */
> + if (data->cfg->phy0_dual_route)
> + sun4i_usb_phy0_reroute(data, false);
> + }
>  
>   return 0;
>  }
> -- 
> 2.17.5
> 

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


signature.asc
Description: PGP signature

Re: [PATCH 1/2] rockchip: misc: Only assign serial# variable if unset

[Paul Kocialkowski]

Hi Heiko,

On Tue 03 Dec 19, 20:50, Heiko Stuebner wrote:
> Hi Paul,
> 
> On 03.12.19 16:46, Paul Kocialkowski wrote:
> > The serial# environment variable is a read-only special variable, that
> > can only be set once. As a result, if the environment was saved to a
> > persistent storage location, attempting to set it again in
> > rockchip_cpuid_set will fail and halt the boot with the following error:
> > 
> > Solve this by checking whether the variable is already set before.
> > 
> > Signed-off-by: Paul Kocialkowski 
> 
> it looks like we're fixing the same problems a lot. Yesterday I
> also got a patch from Miquel about the px30 iommu clocks ;-) .
> 
> Here it's the same as "rockchip: misc: protect serial# from getting
> overwritten"
> from november 29 ;-)

Hehe good catch! We'll try to keep better track of the list before sending
fixes next time ;)

Cheers,

Paul

> Heiko
> 
> > ---
> >   arch/arm/mach-rockchip/misc.c | 14 +-
> >   1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
> > index bed4317f7ece..a0c6a1c0b266 100644
> > --- a/arch/arm/mach-rockchip/misc.c
> > +++ b/arch/arm/mach-rockchip/misc.c
> > @@ -108,12 +108,16 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32 
> > cpuid_length)
> > high[i] = cpuid[i << 1];
> > }
> > -   serialno = crc32_no_comp(0, low, 8);
> > -   serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
> > -   snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
> > -
> > env_set("cpuid#", cpuid_str);
> > -   env_set("serial#", serialno_str);
> > +
> > +   if (!env_get("serial#")) {
> > +   serialno = crc32_no_comp(0, low, 8);
> > +   serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
> > +   snprintf(serialno_str, sizeof(serialno_str), "%016llx",
> > +serialno);
> > +
> > +   env_set("serial#", serialno_str);
> > +   }
> > return 0;
> >   }
> 
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH 1/2] rockchip: misc: Only assign serial# variable if unset

[Paul Kocialkowski]

The serial# environment variable is a read-only special variable, that
can only be set once. As a result, if the environment was saved to a
persistent storage location, attempting to set it again in
rockchip_cpuid_set will fail and halt the boot with the following error:

Solve this by checking whether the variable is already set before.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/mach-rockchip/misc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index bed4317f7ece..a0c6a1c0b266 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -108,12 +108,16 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32 
cpuid_length)
high[i] = cpuid[i << 1];
}
 
-   serialno = crc32_no_comp(0, low, 8);
-   serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
-   snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
-
env_set("cpuid#", cpuid_str);
-   env_set("serial#", serialno_str);
+
+   if (!env_get("serial#")) {
+   serialno = crc32_no_comp(0, low, 8);
+   serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
+   snprintf(serialno_str, sizeof(serialno_str), "%016llx",
+serialno);
+
+   env_set("serial#", serialno_str);
+   }
 
return 0;
 }
-- 
2.24.0

[PATCH 2/2] rockchip: misc: Don't fail if ethaddr is already set

[Paul Kocialkowski]

rockchip_setup_macaddr will return -1 if ethaddr is already set, which
gets propagated to misc_init_r and eventually halts the boot process.

While checking that the variable is not already set before attempting to
setit  is legitimate (it's a set-once variable), this is no good reason
to halt the boot process.

Return the success return code if the variable is already set instead.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/mach-rockchip/misc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index a0c6a1c0b266..bce10bb04f8f 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -29,7 +29,7 @@ int rockchip_setup_macaddr(void)
 
/* Only generate a MAC address, if none is set in the environment */
if (env_get("ethaddr"))
-   return -1;
+   return 0;
 
if (!cpuid) {
debug("%s: could not retrieve 'cpuid#'\n", __func__);
-- 
2.24.0

[U-Boot] [PATCH v2 3/3] rockchip: px30: Add support for using UART3 as debug UART

[Paul Kocialkowski]

Some generic PX30 SoMs found in the wild use UART3 as their debug output
instead of UART2 (used for MMC) and UART5.

Make it possible to use UART3 as early debug output, with the associated
clock and pinmux configuration. Two sets of output pins are supported (M0/M1).

Future users should also note that the pinmux default in the dts is to use
the M1 pins while the Kconfig option takes M0 as a default.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Kever Yang 
Reviewed-by: Heiko Stuebner 
---
 arch/arm/include/asm/arch-rockchip/cru_px30.h | 19 +
 arch/arm/mach-rockchip/px30/px30.c| 77 +++
 2 files changed, 96 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_px30.h 
b/arch/arm/include/asm/arch-rockchip/cru_px30.h
index 7d9fd181aca2..798444ae49f5 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_px30.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_px30.h
@@ -357,6 +357,25 @@ enum {
UART2_DIVNP5_SHIFT  = 0,
UART2_DIVNP5_MASK   = 0x1f << UART2_DIVNP5_SHIFT,
 
+   /* CRU_CLK_SEL40_CON */
+   UART3_PLL_SEL_SHIFT = 14,
+   UART3_PLL_SEL_MASK  = 3 << UART3_PLL_SEL_SHIFT,
+   UART3_PLL_SEL_GPLL  = 0,
+   UART3_PLL_SEL_24M,
+   UART3_PLL_SEL_480M,
+   UART3_PLL_SEL_NPLL,
+   UART3_DIV_CON_SHIFT = 0,
+   UART3_DIV_CON_MASK  = 0x1f << UART3_DIV_CON_SHIFT,
+
+   /* CRU_CLK_SEL41_CON */
+   UART3_CLK_SEL_SHIFT = 14,
+   UART3_CLK_SEL_MASK  = 3 << UART3_PLL_SEL_SHIFT,
+   UART3_CLK_SEL_UART3 = 0,
+   UART3_CLK_SEL_UART3_NP5,
+   UART3_CLK_SEL_UART3_FRAC,
+   UART3_DIVNP5_SHIFT  = 0,
+   UART3_DIVNP5_MASK   = 0x1f << UART3_DIVNP5_SHIFT,
+
/* CRU_CLK_SEL46_CON */
UART5_PLL_SEL_SHIFT = 14,
UART5_PLL_SEL_MASK  = 3 << UART5_PLL_SEL_SHIFT,
diff --git a/arch/arm/mach-rockchip/px30/px30.c 
b/arch/arm/mach-rockchip/px30/px30.c
index a2241cfc608d..5014ee83d748 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -37,6 +37,7 @@ static struct mm_region px30_mem_map[] = {
 struct mm_region *mem_map = px30_mem_map;
 
 #define PMU_PWRDN_CON  0xff18
+#define PMUGRF_BASE0xff01
 #define GRF_BASE   0xff14
 #define CRU_BASE   0xff2b
 #define VIDEO_PHY_BASE 0xff2e
@@ -49,6 +50,23 @@ struct mm_region *mem_map = px30_mem_map;
 
 #define QOS_PRIORITY_LEVEL(h, l)   h) & 3) << 8) | ((l) & 3))
 
+/* GRF_GPIO1BH_IOMUX */
+enum {
+   GPIO1B7_SHIFT   = 12,
+   GPIO1B7_MASK= 0xf << GPIO1B7_SHIFT,
+   GPIO1B7_GPIO= 0,
+   GPIO1B7_FLASH_RDN,
+   GPIO1B7_UART3_RXM1,
+   GPIO1B7_SPI0_CLK,
+
+   GPIO1B6_SHIFT   = 8,
+   GPIO1B6_MASK= 0xf << GPIO1B6_SHIFT,
+   GPIO1B6_GPIO= 0,
+   GPIO1B6_FLASH_CS1,
+   GPIO1B6_UART3_TXM1,
+   GPIO1B6_SPI0_CSN,
+};
+
 /* GRF_GPIO1CL_IOMUX */
 enum {
GPIO1C1_SHIFT   = 4,
@@ -128,6 +146,23 @@ enum {
GPIO3A1_UART5_RX= 4,
 };
 
+/* PMUGRF_GPIO0CL_IOMUX */
+enum {
+   GPIO0C1_SHIFT   = 2,
+   GPIO0C1_MASK= 0x3 << GPIO0C1_SHIFT,
+   GPIO0C1_GPIO= 0,
+   GPIO0C1_PWM_3,
+   GPIO0C1_UART3_RXM0,
+   GPIO0C1_PMU_DEBUG4,
+
+   GPIO0C0_SHIFT   = 0,
+   GPIO0C0_MASK= 0x3 << GPIO0C0_SHIFT,
+   GPIO0C0_GPIO= 0,
+   GPIO0C0_PWM_1,
+   GPIO0C0_UART3_TXM0,
+   GPIO0C0_PMU_DEBUG3,
+};
+
 int arch_cpu_init(void)
 {
static struct px30_grf * const grf = (void *)GRF_BASE;
@@ -175,6 +210,11 @@ int arch_cpu_init(void)
 #ifdef CONFIG_DEBUG_UART_BOARD_INIT
 void board_debug_uart_init(void)
 {
+#if defined(CONFIG_DEBUG_UART_BASE) && \
+   (CONFIG_DEBUG_UART_BASE == 0xff168000) && \
+   (CONFIG_DEBUG_UART_CHANNEL != 1)
+   static struct px30_pmugrf * const pmugrf = (void *)PMUGRF_BASE;
+#endif
static struct px30_grf * const grf = (void *)GRF_BASE;
static struct px30_cru * const cru = (void *)CRU_BASE;
 
@@ -191,6 +231,43 @@ void board_debug_uart_init(void)
 GPIO1C1_MASK | GPIO1C0_MASK,
 GPIO1C1_UART1_TX << GPIO1C1_SHIFT |
 GPIO1C0_UART1_RX << GPIO1C0_SHIFT);
+#elif defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff168000)
+   /* GRF_IOFUNC_CON0 */
+   enum {
+   CON_IOMUX_UART3SEL_SHIFT= 9,
+   CON_IOMUX_UART3SEL_MASK = 1 << CON_IOMUX_UART3SEL_SHIFT,
+   CON_IOMUX_UART3SEL_M0   = 0,
+   CON_IOMUX_UART3SEL_M1,
+   };
+
+   /* uart_sel_clk default select 24MHz */
+   rk_clrsetreg(>clksel_con[40],
+UART3_PLL_

[U-Boot] [PATCH v2 1/3] rockchip: px30: Fixup PMUGRF registers layout order

[Paul Kocialkowski]

According to the PX30 TRM, the iomux registers come first, before the pull
and strength control registers.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Kever Yang 
Reviewed-by: Heiko Stuebner 
---
 arch/arm/include/asm/arch-rockchip/grf_px30.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_px30.h 
b/arch/arm/include/asm/arch-rockchip/grf_px30.h
index c167bb42fac9..3d2a8770322e 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_px30.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_px30.h
@@ -112,18 +112,18 @@ struct px30_grf {
 check_member(px30_grf, mac_con1, 0x904);
 
 struct px30_pmugrf {
-   unsigned int gpio0a_e;
-   unsigned int gpio0b_e;
-   unsigned int gpio0c_e;
-   unsigned int gpio0d_e;
-   unsigned int gpio0a_p;
-   unsigned int gpio0b_p;
-   unsigned int gpio0c_p;
-   unsigned int gpio0d_p;
unsigned int gpio0al_iomux;
unsigned int gpio0bl_iomux;
unsigned int gpio0cl_iomux;
unsigned int gpio0dl_iomux;
+   unsigned int gpio0a_p;
+   unsigned int gpio0b_p;
+   unsigned int gpio0c_p;
+   unsigned int gpio0d_p;
+   unsigned int gpio0a_e;
+   unsigned int gpio0b_e;
+   unsigned int gpio0c_e;
+   unsigned int gpio0d_e;
unsigned int gpio0l_sr;
unsigned int gpio0h_sr;
unsigned int gpio0l_smt;
-- 
2.24.0

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

[U-Boot] [PATCH v2 2/3] rockchip: px30: Rename CONFIG_DEBUG_UART2_CHANNEL to CONFIG_DEBUG_UART_CHANNEL

[Paul Kocialkowski]

UART3 also has two sets of pins that can be selected.

Rename the config option to a common name, to allow it to be used for both
UART2 and UART3.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/mach-rockchip/px30/Kconfig | 6 +++---
 arch/arm/mach-rockchip/px30/px30.c  | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-rockchip/px30/Kconfig 
b/arch/arm/mach-rockchip/px30/Kconfig
index 109a37be15ad..9f3ad4f623b0 100644
--- a/arch/arm/mach-rockchip/px30/Kconfig
+++ b/arch/arm/mach-rockchip/px30/Kconfig
@@ -27,12 +27,12 @@ config TPL_MAX_SIZE
 config TPL_STACK
default 0xff0e4fff
 
-config DEBUG_UART2_CHANNEL
-   int "Mux channel to use for debug UART2"
+config DEBUG_UART_CHANNEL
+   int "Mux channel to use for debug UART2/UART3"
depends on DEBUG_UART_BOARD_INIT
default 0
help
- UART2 can use two different set of pins to route the output.
+ UART2 and UART3 can use two different set of pins to route the output.
  For using the UART for early debugging the route to use needs
  to be declared (0 or 1).
 
diff --git a/arch/arm/mach-rockchip/px30/px30.c 
b/arch/arm/mach-rockchip/px30/px30.c
index bacdcc0b938d..a2241cfc608d 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -222,7 +222,7 @@ void board_debug_uart_init(void)
 UART2_CLK_SEL_MASK,
 UART2_CLK_SEL_UART2 << UART2_CLK_SEL_SHIFT);
 
-#if (CONFIG_DEBUG_UART2_CHANNEL == 1)
+#if (CONFIG_DEBUG_UART_CHANNEL == 1)
/* Enable early UART2 */
rk_clrsetreg(>iofunc_con0,
 CON_IOMUX_UART2SEL_MASK,
@@ -241,7 +241,7 @@ void board_debug_uart_init(void)
 GPIO1D3_MASK | GPIO1D2_MASK,
 GPIO1D3_UART2_RXM0 << GPIO1D3_SHIFT |
 GPIO1D2_UART2_TXM0 << GPIO1D2_SHIFT);
-#endif /* CONFIG_DEBUG_UART2_CHANNEL == 1 */
+#endif /* CONFIG_DEBUG_UART_CHANNEL == 1 */
 
 #endif /* CONFIG_DEBUG_UART_BASE && CONFIG_DEBUG_UART_BASE == ... */
 }
-- 
2.24.0

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

Re: [U-Boot] [PATCH 2/2] rockchip: px30: Add support for using UART3 as debug UART

[Paul Kocialkowski]

Hi Heiko,

On Thu 28 Nov 19, 10:44, Heiko Stuebner wrote:
> On 27.11.19 11:12, Paul Kocialkowski wrote:
> > Some generic PX30 SoMs found in the wild use UART3 as their debug output
> > instead of UART2 (used for MMC) and UART5.
> > 
> > Make it possible to use UART3 as early debug output, with the associated
> > clock and pinmux configuration. Two sets of output pins are supported 
> > (M0/M1)
> > so a Kconfig option to select between the two is introduced like it's done
> > for UART2.
> > 
> > Future users should also note that the pinmux default in the dts is to use
> > the M1 pins while the Kconfig option takes M0 as a default.
> > 
> > Signed-off-by: Paul Kocialkowski 
> 
> Reviewed-by: Heiko Stuebner 
> 
> with one small question below
> 
> > diff --git a/arch/arm/mach-rockchip/px30/Kconfig 
> > b/arch/arm/mach-rockchip/px30/Kconfig
> > index 109a37be15ad..167517bbd63f 100644
> > --- a/arch/arm/mach-rockchip/px30/Kconfig
> > +++ b/arch/arm/mach-rockchip/px30/Kconfig
> > @@ -36,6 +36,15 @@ config DEBUG_UART2_CHANNEL
> >   For using the UART for early debugging the route to use needs
> >   to be declared (0 or 1).
> > +config DEBUG_UART3_CHANNEL
> > +   int "Mux channel to use for debug UART3"
> > +   depends on DEBUG_UART_BOARD_INIT
> > +   default 0
> > +   help
> > + UART3 can use two different set of pins to route the output.
> > + For using the UART for early debugging the route to use needs
> > + to be declared (0 or 1).
> > +
> >   source "board/rockchip/evb_px30/Kconfig"
> 
> Would it make sense to rename DEBUG_UART3_CHANNEL to just
> DEBUG_UART_CHANNEL and reuse it, so that we don't collect similar
> options for each uart?

Yes I like that better too. Will craft a v2 with that.

And thanks for the review!

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


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

[U-Boot] [PATCH 2/2] rockchip: px30: Add support for using UART3 as debug UART

[Paul Kocialkowski]

Some generic PX30 SoMs found in the wild use UART3 as their debug output
instead of UART2 (used for MMC) and UART5.

Make it possible to use UART3 as early debug output, with the associated
clock and pinmux configuration. Two sets of output pins are supported (M0/M1)
so a Kconfig option to select between the two is introduced like it's done
for UART2.

Future users should also note that the pinmux default in the dts is to use
the M1 pins while the Kconfig option takes M0 as a default.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/include/asm/arch-rockchip/cru_px30.h | 19 +
 arch/arm/mach-rockchip/px30/Kconfig   |  9 +++
 arch/arm/mach-rockchip/px30/px30.c| 77 +++
 3 files changed, 105 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_px30.h 
b/arch/arm/include/asm/arch-rockchip/cru_px30.h
index 7d9fd181aca2..798444ae49f5 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_px30.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_px30.h
@@ -357,6 +357,25 @@ enum {
UART2_DIVNP5_SHIFT  = 0,
UART2_DIVNP5_MASK   = 0x1f << UART2_DIVNP5_SHIFT,
 
+   /* CRU_CLK_SEL40_CON */
+   UART3_PLL_SEL_SHIFT = 14,
+   UART3_PLL_SEL_MASK  = 3 << UART3_PLL_SEL_SHIFT,
+   UART3_PLL_SEL_GPLL  = 0,
+   UART3_PLL_SEL_24M,
+   UART3_PLL_SEL_480M,
+   UART3_PLL_SEL_NPLL,
+   UART3_DIV_CON_SHIFT = 0,
+   UART3_DIV_CON_MASK  = 0x1f << UART3_DIV_CON_SHIFT,
+
+   /* CRU_CLK_SEL41_CON */
+   UART3_CLK_SEL_SHIFT = 14,
+   UART3_CLK_SEL_MASK  = 3 << UART3_PLL_SEL_SHIFT,
+   UART3_CLK_SEL_UART3 = 0,
+   UART3_CLK_SEL_UART3_NP5,
+   UART3_CLK_SEL_UART3_FRAC,
+   UART3_DIVNP5_SHIFT  = 0,
+   UART3_DIVNP5_MASK   = 0x1f << UART3_DIVNP5_SHIFT,
+
/* CRU_CLK_SEL46_CON */
UART5_PLL_SEL_SHIFT = 14,
UART5_PLL_SEL_MASK  = 3 << UART5_PLL_SEL_SHIFT,
diff --git a/arch/arm/mach-rockchip/px30/Kconfig 
b/arch/arm/mach-rockchip/px30/Kconfig
index 109a37be15ad..167517bbd63f 100644
--- a/arch/arm/mach-rockchip/px30/Kconfig
+++ b/arch/arm/mach-rockchip/px30/Kconfig
@@ -36,6 +36,15 @@ config DEBUG_UART2_CHANNEL
  For using the UART for early debugging the route to use needs
  to be declared (0 or 1).
 
+config DEBUG_UART3_CHANNEL
+   int "Mux channel to use for debug UART3"
+   depends on DEBUG_UART_BOARD_INIT
+   default 0
+   help
+ UART3 can use two different set of pins to route the output.
+ For using the UART for early debugging the route to use needs
+ to be declared (0 or 1).
+
 source "board/rockchip/evb_px30/Kconfig"
 
 endif
diff --git a/arch/arm/mach-rockchip/px30/px30.c 
b/arch/arm/mach-rockchip/px30/px30.c
index bacdcc0b938d..6b12f4f6a502 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -37,6 +37,7 @@ static struct mm_region px30_mem_map[] = {
 struct mm_region *mem_map = px30_mem_map;
 
 #define PMU_PWRDN_CON  0xff18
+#define PMUGRF_BASE0xff01
 #define GRF_BASE   0xff14
 #define CRU_BASE   0xff2b
 #define VIDEO_PHY_BASE 0xff2e
@@ -49,6 +50,23 @@ struct mm_region *mem_map = px30_mem_map;
 
 #define QOS_PRIORITY_LEVEL(h, l)   h) & 3) << 8) | ((l) & 3))
 
+/* GRF_GPIO1BH_IOMUX */
+enum {
+   GPIO1B7_SHIFT   = 12,
+   GPIO1B7_MASK= 0xf << GPIO1B7_SHIFT,
+   GPIO1B7_GPIO= 0,
+   GPIO1B7_FLASH_RDN,
+   GPIO1B7_UART3_RXM1,
+   GPIO1B7_SPI0_CLK,
+
+   GPIO1B6_SHIFT   = 8,
+   GPIO1B6_MASK= 0xf << GPIO1B6_SHIFT,
+   GPIO1B6_GPIO= 0,
+   GPIO1B6_FLASH_CS1,
+   GPIO1B6_UART3_TXM1,
+   GPIO1B6_SPI0_CSN,
+};
+
 /* GRF_GPIO1CL_IOMUX */
 enum {
GPIO1C1_SHIFT   = 4,
@@ -128,6 +146,23 @@ enum {
GPIO3A1_UART5_RX= 4,
 };
 
+/* PMUGRF_GPIO0CL_IOMUX */
+enum {
+   GPIO0C1_SHIFT   = 2,
+   GPIO0C1_MASK= 0x3 << GPIO0C1_SHIFT,
+   GPIO0C1_GPIO= 0,
+   GPIO0C1_PWM_3,
+   GPIO0C1_UART3_RXM0,
+   GPIO0C1_PMU_DEBUG4,
+
+   GPIO0C0_SHIFT   = 0,
+   GPIO0C0_MASK= 0x3 << GPIO0C0_SHIFT,
+   GPIO0C0_GPIO= 0,
+   GPIO0C0_PWM_1,
+   GPIO0C0_UART3_TXM0,
+   GPIO0C0_PMU_DEBUG3,
+};
+
 int arch_cpu_init(void)
 {
static struct px30_grf * const grf = (void *)GRF_BASE;
@@ -175,6 +210,11 @@ int arch_cpu_init(void)
 #ifdef CONFIG_DEBUG_UART_BOARD_INIT
 void board_debug_uart_init(void)
 {
+#if defined(CONFIG_DEBUG_UART_BASE) && \
+   (CONFIG_DEBUG_UART_BASE == 0xff168000) && \
+   (CONFIG_DEBUG_UART3_CHANNEL != 1)
+   static struct px30_pmugrf * const pmugrf = (void *)PMUGRF_BASE;

[U-Boot] [PATCH 1/2] rockchip: px30: Fixup PMUGRF registers layout order

[Paul Kocialkowski]

According to the PX30 TRM, the iomux registers come first, before the pull
and strength control registers.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/include/asm/arch-rockchip/grf_px30.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_px30.h 
b/arch/arm/include/asm/arch-rockchip/grf_px30.h
index c167bb42fac9..3d2a8770322e 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_px30.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_px30.h
@@ -112,18 +112,18 @@ struct px30_grf {
 check_member(px30_grf, mac_con1, 0x904);
 
 struct px30_pmugrf {
-   unsigned int gpio0a_e;
-   unsigned int gpio0b_e;
-   unsigned int gpio0c_e;
-   unsigned int gpio0d_e;
-   unsigned int gpio0a_p;
-   unsigned int gpio0b_p;
-   unsigned int gpio0c_p;
-   unsigned int gpio0d_p;
unsigned int gpio0al_iomux;
unsigned int gpio0bl_iomux;
unsigned int gpio0cl_iomux;
unsigned int gpio0dl_iomux;
+   unsigned int gpio0a_p;
+   unsigned int gpio0b_p;
+   unsigned int gpio0c_p;
+   unsigned int gpio0d_p;
+   unsigned int gpio0a_e;
+   unsigned int gpio0b_e;
+   unsigned int gpio0c_e;
+   unsigned int gpio0d_e;
unsigned int gpio0l_sr;
unsigned int gpio0h_sr;
unsigned int gpio0l_smt;
-- 
2.24.0

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

Re: [U-Boot] [linux-sunxi] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB

[Paul Kocialkowski]

Hi,

On Mon 15 Jul 19, 12:55, Jagan Teki wrote:
> On Mon, May 27, 2019 at 5:21 AM André Przywara  wrote:
> >
> > On 17/04/2019 12:28, Jagan Teki wrote:
> > > On Mon, Apr 15, 2019 at 1:52 PM Paul Kocialkowski
> > >  wrote:
> >
> > Hi,
> >
> > >> Le vendredi 12 avril 2019 à 14:49 +0530, Jagan Teki a écrit :
> > >>> On Thu, Mar 14, 2019 at 4:08 PM Paul Kocialkowski
> > >>>  wrote:
> > >>>> Recent Allwinner platforms (starting with the H3) only use the MUSB
> > >>>> controller for peripheral mode and use HCI for host mode. As a result,
> > >>>> extra steps need to be taken to properly route USB signals to one or
> > >>>> the other. More precisely, the following is required:
> > >>>> * Routing the pins to either HCI/MUSB (controlled by PHY);
> > >>>> * Enabling USB PHY passby in HCI mode (controlled by PMU).
> > >>>>
> > >>>> The current code will enable passby for each PHY and reroute PHY0 to
> > >>>> MUSB, which is inconsistent and results in broken USB peripheral 
> > >>>> support.
> > >>>>
> > >>>> Passby on PHY0 must only be enabled when we want to use HCI. Since
> > >>>> host/device mode detection is not available from the PHY code and
> > >>>> because U-Boot does not support changing the mode dynamically anyway,
> > >>>> we can just mux the controller to MUSB if it is enabled and mux it to
> > >>>> HCI otherwise.
> > >>>>
> > >>>> This fixes USB peripheral support for platforms with PHY0 dual-route,
> > >>>> especially H3/H5 and V3s.
> > >>>>
> > >>>> Signed-off-by: Paul Kocialkowski 
> > >>>> ---
> > >>>>  drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
> > >>>>  1 file changed, 13 insertions(+), 1 deletion(-)
> > >>>>
> > >>>> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> > >>>> b/drivers/phy/allwinner/phy-sun4i-usb.c
> > >>>> index f206fa3f5d48..4f1c7e519d71 100644
> > >>>> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > >>>> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > >>>> @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy)
> > >>>> data->cfg->disc_thresh, 
> > >>>> PHY_DISCON_TH_LEN);
> > >>>> }
> > >>>>
> > >>>> +#ifdef CONFIG_USB_MUSB_SUNXI
> > >>>> +   /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */
> > >>>> +   if (usb_phy->id != 0)
> > >>>> +   sun4i_usb_phy_passby(phy, true);
> > >>>> +
> > >>>> +   /* Route PHY0 to MUSB to allow USB gadget */
> > >>>> +   if (data->cfg->phy0_dual_route)
> > >>>> +   sun4i_usb_phy0_reroute(data, true);
> > >>>> +#else
> > >>>> sun4i_usb_phy_passby(phy, true);
> > >>>>
> > >>>> -   sun4i_usb_phy0_reroute(data, true);
> > >>>> +   /* Route PHY0 to HCI to allow USB host */
> > >>>> +   if (data->cfg->phy0_dual_route)
> > >>>> +   sun4i_usb_phy0_reroute(data, false);
> > >>>> +#endif
> > >>>
> > >>> I think we can manage this route and passby dynamically by detecting
> > >>> id since we have dr_mode verify the MUSB host or peripheral via
> > >>> usb_get_dr_mode, any chance to try that way?
> > >>
> > >> Oh, I didn't know that U-Boot has support for usb_get_dr_mode these
> > >> days. Thanks!
> > >>
> > >> So far, the sunxi port has been using Kconfig to distinguish between
> > >> host/device (unless I'm mistaken?) so I feel like this should be a
> > >> separate follow-up patch to convert the sunxi MUSB glue + PHY to
> > >> detecting dr_mode using usb_get_dr_mode. This feels like a significant
> > >> rework, too.
> > >
> > > Yes.
> > >
> > >>
> > >> Also, how should we handle the OTG case? I'm not sure we can support
> > >> having both musb host and gadget built-in at this point. But that would
> > >> certainly be welcome as part of the rework, 

Re: [U-Boot] [linux-sunxi] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB

[Paul Kocialkowski]

Hi,

On Mon 27 May 19, 00:50, André Przywara wrote:
> On 17/04/2019 12:28, Jagan Teki wrote:
> > On Mon, Apr 15, 2019 at 1:52 PM Paul Kocialkowski
> >  wrote:
> 
> Hi,
> 
> >> Le vendredi 12 avril 2019 à 14:49 +0530, Jagan Teki a écrit :
> >>> On Thu, Mar 14, 2019 at 4:08 PM Paul Kocialkowski
> >>>  wrote:
> >>>> Recent Allwinner platforms (starting with the H3) only use the MUSB
> >>>> controller for peripheral mode and use HCI for host mode. As a result,
> >>>> extra steps need to be taken to properly route USB signals to one or
> >>>> the other. More precisely, the following is required:
> >>>> * Routing the pins to either HCI/MUSB (controlled by PHY);
> >>>> * Enabling USB PHY passby in HCI mode (controlled by PMU).
> >>>>
> >>>> The current code will enable passby for each PHY and reroute PHY0 to
> >>>> MUSB, which is inconsistent and results in broken USB peripheral support.
> >>>>
> >>>> Passby on PHY0 must only be enabled when we want to use HCI. Since
> >>>> host/device mode detection is not available from the PHY code and
> >>>> because U-Boot does not support changing the mode dynamically anyway,
> >>>> we can just mux the controller to MUSB if it is enabled and mux it to
> >>>> HCI otherwise.
> >>>>
> >>>> This fixes USB peripheral support for platforms with PHY0 dual-route,
> >>>> especially H3/H5 and V3s.
> >>>>
> >>>> Signed-off-by: Paul Kocialkowski 
> >>>> ---
> >>>>  drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
> >>>>  1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> >>>> b/drivers/phy/allwinner/phy-sun4i-usb.c
> >>>> index f206fa3f5d48..4f1c7e519d71 100644
> >>>> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> >>>> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> >>>> @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy)
> >>>> data->cfg->disc_thresh, 
> >>>> PHY_DISCON_TH_LEN);
> >>>> }
> >>>>
> >>>> +#ifdef CONFIG_USB_MUSB_SUNXI
> >>>> +   /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */
> >>>> +   if (usb_phy->id != 0)
> >>>> +   sun4i_usb_phy_passby(phy, true);
> >>>> +
> >>>> +   /* Route PHY0 to MUSB to allow USB gadget */
> >>>> +   if (data->cfg->phy0_dual_route)
> >>>> +   sun4i_usb_phy0_reroute(data, true);
> >>>> +#else
> >>>> sun4i_usb_phy_passby(phy, true);
> >>>>
> >>>> -   sun4i_usb_phy0_reroute(data, true);
> >>>> +   /* Route PHY0 to HCI to allow USB host */
> >>>> +   if (data->cfg->phy0_dual_route)
> >>>> +   sun4i_usb_phy0_reroute(data, false);
> >>>> +#endif
> >>>
> >>> I think we can manage this route and passby dynamically by detecting
> >>> id since we have dr_mode verify the MUSB host or peripheral via
> >>> usb_get_dr_mode, any chance to try that way?
> >>
> >> Oh, I didn't know that U-Boot has support for usb_get_dr_mode these
> >> days. Thanks!
> >>
> >> So far, the sunxi port has been using Kconfig to distinguish between
> >> host/device (unless I'm mistaken?) so I feel like this should be a
> >> separate follow-up patch to convert the sunxi MUSB glue + PHY to
> >> detecting dr_mode using usb_get_dr_mode. This feels like a significant
> >> rework, too.
> > 
> > Yes.
> > 
> >>
> >> Also, how should we handle the OTG case? I'm not sure we can support
> >> having both musb host and gadget built-in at this point. But that would
> >> certainly be welcome as part of the rework, too.
> >>
> >> What do you think?
> > 
> > You mean handling dr_mode at runtime.
> > 
> > If yes, It is bit new where we can register the musb as UCLASS_MISC
> > wrapper and decide to bind driver for host and peripheral by decoding
> > dr_mode. and indeed host should register with UCLASS_USB and
> > peripheral with UCLASS_USB_GADGET_GENERIC.
> > 
> > I tried this wrapper before, not placed in-between because

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Paul Kocialkowski]

Hi,

On Fri, 2019-06-21 at 14:52 +0200, Mark Kettenis wrote:
> > From: Heiko Stuebner 
> > Maybe we could give this some sort of time limitation like
> > "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> > to give people the chance to do things piece by piece but still force them
> > to actually work on improving the situation.
> > 
> > As driver-side changes will generally benefit more socs/boards potential
> > removal after the time limit would only affect the board+dts itself.
> > 
> > So somewhat similar to what the kernel does with "staging", if you
> > keep working on improving it, it is allowed to stay.
> > 
> > This could be also applied to already included boards, like
> > "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> > to how Tom handles devicemanager conversions currently
> 
> Still doesn't make sense to me unless you're going to enforce such a
> rule for all included boards that lack usable open-source DRAM
> initialization code.  Otherwise you're just punishing Rockchip for
> having a partial DRAM initialization code and are potentially sending
> the message that it's better not to attempt create open source DRAM
> drivers.

I'm not following this at all. Rockchip has a particular situation
where almost all the boards have free DRAM init, which is not the case
on every platform. I don't see why this decision has to be harmonized
on the whole project since I believe it only makes sense for the
specific case of Rockchip.

Seeing this as some sort of punishment feels like a gross
misinterpretation of our intent. If we are clear and communicate about
the motivations why we think this is important and why this rule is
applied, then there is nothing we can do about mis-judgments. I don't
think it's fair or rational to not take action because of that.

Whatever we do, there is always a chance that people will mis-interpret 
things and throw shit at us for taking political decisions. That's too
bad, but there is only so much we can do about that. And rest asured
that people (including myself) can also throw shit at the project for
maintaining a weak status-quo and not contribute to moving things
forward on political aspects when it is in a power position to do so.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Paul Kocialkowski]

Hi,

On Fri, 2019-06-21 at 13:34 +0200, Heiko Stuebner wrote:
> Hi,
> 
> Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> > On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> > > > On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > > > > From: Paul Kocialkowski 
> > > > > > Date: Tue, 18 Jun 2019 14:47:33 +0200
> > > > > > On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > > > > > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > > > > > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > > > > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > > > > > >  wrote:
> > > > > > > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqin...@gmail.com 
> > > > > > > > > > wrote:
> > > > > > > > > > > From: Nick Xie 
> > > > > > > > > > Was this tested with SPL support? I don't see DRAM 
> > > > > > > > > > configuration here
> > > > > > > > > > so it seems that it relies on the non-free rockchip loader.
> > > > > > > > > > 
> > > > > > > > > > If that is the case, could you please indicate that in the 
> > > > > > > > > > commit
> > > > > > > > > > message?
> > > > > > > > > > 
> > > > > > > > > > To maintainers: please do not merge this series before DRAM 
> > > > > > > > > > init and
> > > > > > > > > > SPL support is available for these boards.
> > > > > > > > > > 
> > > > > > > > > > It seems that other RK3399 boards were merged without SPL 
> > > > > > > > > > support and
> > > > > > > > > > sofar, I have the feeling that nobody cared to explain how 
> > > > > > > > > > we got into
> > > > > > > > > > this broken situation. Please don't merge any more such 
> > > > > > > > > > board.
> > > > > > > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were 
> > > > > > > > > merged
> > > > > > > > > with TPL-enabled (which was discussed on the threads, if you 
> > > > > > > > > remember)
> > > > > > > > > with below boot chain.
> > > > > > > > > 
> > > > > > > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > > > > > > > 
> > > > > > > > > Same case for this board as well.
> > > > > > > > Here is a quote from Philipp Tomsich on the thread we discussed 
> > > > > > > > this:
> > > > > > > > 
> > > > > > > > " On some boards, there will be no TPL and only a SPL stage 
> > > > > > > > that will
> > > > > > > > initialise DRAM (as the move to having TPL on the RK3399 is 
> > > > > > > > optional).
> > > > > > > > 
> > > > > > > > I agree with Paul that the DRAM init should be part of U-Boot 
> > > > > > > > whenever
> > > > > > > > we add new boards and make an open DRAM init a prerequisite. "
> > > > > > > > 
> > > > > > > > So even if I frequently confuse SPL and TPL, it doesn't change 
> > > > > > > > the fact
> > > > > > > > that no board should be merged without proper DRAM init.
> > > > > > > > 
> > > > > > > > Please stop pushing for merging these boards. I'm not sure what 
> > > > > > > > we
> > > > > > > > should do about the boards that were merged already without 
> > > > > > > > DRAM init,
> > > > > > > > but maybe they should be reverted.
> > > > > > > I don't think we have to have full DRAM init source code for each
> > > > > > > board before we can merge it, I believe most of the board on 
> > > > > > > U-Boot
> > > > > > > mainline need to remov

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Paul Kocialkowski]

Hi Kever,

Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> Hi Paul,
> 
> 
> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > From: Paul Kocialkowski 
> > > Date: Tue, 18 Jun 2019 14:47:33 +0200
> > > 
> > > Hi Kever,
> > > 
> > > On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > > Hi Paul,
> > > > 
> > > > 
> > > > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > > > Hi,
> > > > > 
> > > > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > > >  wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqin...@gmail.com wrote:
> > > > > > > > From: Nick Xie 
> > > > > > > Was this tested with SPL support? I don't see DRAM configuration 
> > > > > > > here
> > > > > > > so it seems that it relies on the non-free rockchip loader.
> > > > > > > 
> > > > > > > If that is the case, could you please indicate that in the commit
> > > > > > > message?
> > > > > > > 
> > > > > > > To maintainers: please do not merge this series before DRAM init 
> > > > > > > and
> > > > > > > SPL support is available for these boards.
> > > > > > > 
> > > > > > > It seems that other RK3399 boards were merged without SPL support 
> > > > > > > and
> > > > > > > sofar, I have the feeling that nobody cared to explain how we got 
> > > > > > > into
> > > > > > > this broken situation. Please don't merge any more such board.
> > > > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > > > with TPL-enabled (which was discussed on the threads, if you 
> > > > > > remember)
> > > > > > with below boot chain.
> > > > > > 
> > > > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > > > > 
> > > > > > Same case for this board as well.
> > > > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > > > 
> > > > > " On some boards, there will be no TPL and only a SPL stage that will
> > > > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > > > 
> > > > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > > > we add new boards and make an open DRAM init a prerequisite. "
> > > > > 
> > > > > So even if I frequently confuse SPL and TPL, it doesn't change the 
> > > > > fact
> > > > > that no board should be merged without proper DRAM init.
> > > > > 
> > > > > Please stop pushing for merging these boards. I'm not sure what we
> > > > > should do about the boards that were merged already without DRAM init,
> > > > > but maybe they should be reverted.
> > > > I don't think we have to have full DRAM init source code for each
> > > > board before we can merge it, I believe most of the board on U-Boot
> > > > mainline need to removed due to this rule. There are so many boards
> > > > from different vendor need a binary loader before U-Boot, and I can
> > > > see only very few drivers for dram at driver/ram/, and I believe 
> > > > rockchip
> > > > is already the most open vendor on this area.
> > > Well, I am not talking about full DRAM init source code as in dynamic
> > > link training. I am talking about having at least static DRAM register
> > > configuration values, 
> 
> I can tell you that this is no work for all the boards, you can see how
> rockchip lpddr4(WIP, send by Jagan) driver works.

I thought that LPDDR4 works the same as other types of DRAM where we
have a dtsi array with timings configuration. Of course, some more
registers need to be set up, but we already have support for that or
it's quite close (for LPDDR4).

> > > which is present for a good number of rockchip
> > > boards.
> 
> No, there is no rockchip board only have static DRAM register
> configuration values, that maybe happens in other vendor.

I was implying that, as far as I know, it is the case

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Paul Kocialkowski]

Hi Kever,

On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> Hi Paul,
> 
> 
> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Mon, 2019-06-17 at 15:24 +0800, xieqin...@gmail.com wrote:
> > > > > From: Nick Xie 
> > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > so it seems that it relies on the non-free rockchip loader.
> > > > 
> > > > If that is the case, could you please indicate that in the commit
> > > > message?
> > > > 
> > > > To maintainers: please do not merge this series before DRAM init and
> > > > SPL support is available for these boards.
> > > > 
> > > > It seems that other RK3399 boards were merged without SPL support and
> > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > this broken situation. Please don't merge any more such board.
> > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > with below boot chain.
> > > 
> > > rkbin (TPL) -> SPL -> U-Boot proper
> > > 
> > > Same case for this board as well.
> > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > 
> > " On some boards, there will be no TPL and only a SPL stage that will
> > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > 
> > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > we add new boards and make an open DRAM init a prerequisite. "
> > 
> > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > that no board should be merged without proper DRAM init.
> > 
> > Please stop pushing for merging these boards. I'm not sure what we
> > should do about the boards that were merged already without DRAM init,
> > but maybe they should be reverted.
>
> I don't think we have to have full DRAM init source code for each
> board before we can merge it, I believe most of the board on U-Boot
> mainline need to removed due to this rule. There are so many boards
> from different vendor need a binary loader before U-Boot, and I can
> see only very few drivers for dram at driver/ram/, and I believe rockchip
> is already the most open vendor on this area.

Well, I am not talking about full DRAM init source code as in dynamic
link training. I am talking about having at least static DRAM register
configuration values, which is present for a good number of rockchip
boards.

Of course, it would be best if Rockchip would consider releasing this
source code, which would be the easiest and friendliest solution
towards the community here. Are there internal discussions ongoing
about this? If not, it would be greatly appreciated to start such
discussions and clearly identify what the blocking points are.

> I won't use this rule to stop developers contribute there source code,

This is really sad and I think that Philipp was, like me, inclined to
go towards the other direction.

> for a board support, we only need the board to have the full documentation
> about how to setup and boot with upstream U-Boot. and I think the
> most of people cares more about features in U-Boot proper. Everything
> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> from vendor, as you can see all over the U-Boot mainline now, although
> we encourage people to use full open source TPL/SPL.
> Specifically for U-Boot Rockchip platform, I would like people to
> support not only U-Boot
> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> features)
> support. And for DRAM init,
> - if this belongs to SPL for this board, you must implement it or else
> SPL won't work;
> - if this does not belong to SPL for this board, you need implement full
> function SPL;
> and you can either to have full function TPL with DRAM init(which is
> prefered)
> or alternatively use binary loader from vendor.

This is not really a technical argument here, more of a policy argument
that ensures we have full free software support for the boards we
support, and not only half-cooked support (that will most likely never
be completed as soon as something that works gets merged). So it is a
strategical decision, not a strictly pragmatic one.

I think reverting patches adding support for boards with no DRAM
configuration at all would send a mess

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Paul Kocialkowski]

Hi,

On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Mon, 2019-06-17 at 15:24 +0800, xieqin...@gmail.com wrote:
> > > From: Nick Xie 
> > 
> > Was this tested with SPL support? I don't see DRAM configuration here
> > so it seems that it relies on the non-free rockchip loader.
> > 
> > If that is the case, could you please indicate that in the commit
> > message?
> > 
> > To maintainers: please do not merge this series before DRAM init and
> > SPL support is available for these boards.
> > 
> > It seems that other RK3399 boards were merged without SPL support and
> > sofar, I have the feeling that nobody cared to explain how we got into
> > this broken situation. Please don't merge any more such board.
> 
> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> with TPL-enabled (which was discussed on the threads, if you remember)
> with below boot chain.
> 
> rkbin (TPL) -> SPL -> U-Boot proper
> 
> Same case for this board as well.

Here is a quote from Philipp Tomsich on the thread we discussed this:

" On some boards, there will be no TPL and only a SPL stage that will
initialise DRAM (as the move to having TPL on the RK3399 is optional).

I agree with Paul that the DRAM init should be part of U-Boot whenever
we add new boards and make an open DRAM init a prerequisite. "

So even if I frequently confuse SPL and TPL, it doesn't change the fact
that no board should be merged without proper DRAM init.

Please stop pushing for merging these boards. I'm not sure what we
should do about the boards that were merged already without DRAM init,
but maybe they should be reverted.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Paul Kocialkowski]

rt {
> + phy-supply = <_host>;
> + status = "okay";
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + u2phy1_otg: otg-port {
> + status = "okay";
> + };
> +
> + u2phy1_host: host-port {
> + phy-supply = <_host>;
> + status = "okay";
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_xfer _rts _cts>;
> + status = "okay";
> +
> + bluetooth {
> + compatible = "brcm,bcm43438-bt";
> + clocks = < 1>;
> + clock-names = "lpo";
> + device-wakeup-gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
> + host-wakeup-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
> + shutdown-gpios = < RK_PD3 GPIO_ACTIVE_HIGH>;
> + max-speed = <400>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_reg_on_h _host_wake_l _wake_l>;
> + vbat-supply = <_3v3>;
> + vddio-supply = <_1v8>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_host0_ehci {
> + status = "okay";
> +};
> +
> +_host0_ohci {
> + status = "okay";
> +};
> +
> +_host1_ehci {
> + status = "okay";
> +};
> +
> +_host1_ohci {
> + status = "okay";
> +};
> +
> +_0 {
> + status = "okay";
> +};
> +
> +_dwc3_0 {
> + status = "okay";
> + dr_mode = "otg";
> +};
> +
> +_1 {
> + status = "okay";
> +};
> +
> +_dwc3_1 {
> + status = "okay";
> + dr_mode = "host";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_mmu {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_mmu {
> + status = "okay";
> +};
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS 
> b/board/rockchip/evb_rk3399/MAINTAINERS
> index 3308b35..d9711ab 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -6,6 +6,24 @@ F:  include/configs/evb_rk3399.h
>  F:  configs/evb-rk3399_defconfig
>  F:  configs/firefly-rk3399_defconfig
>  
> +KHADAS-EDGE
> +M:   Nick Xie 
> +S:   Maintained
> +F:   configs/khadas-edge-rk3399_defconfig
> +F:   arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> +
> +KHADAS-EDGE-CAPTAIN
> +M:   Nick Xie 
> +S:   Maintained
> +F:   configs/khadas-edge-captain-rk3399_defconfig
> +F:   arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> +
> +KHADAS-EDGE-V
> +M:   Nick Xie 
> +S:   Maintained
> +F:   configs/khadas-edge-v-rk3399_defconfig
> +F:   arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> +
>  NANOPC-T4
>  M:   Jagan Teki 
>  S:   Maintained
> diff --git a/configs/khadas-edge-captain-rk3399_defconfig 
> b/configs/khadas-edge-captain-rk3399_defconfig
> new file mode 100644
> index 000..306b1b9
> --- /dev/null
> +++ b/configs/khadas-edge-captain-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x8
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-captain"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-rk3399_defconfig 
> b/configs/khadas-edge-rk3399_defconfig
> new file mode 100644
> index 000..0e33911
> --- /dev/null
> +++ b/configs/khadas-edge-rk3399_defconfig
> @@ -0,0 +1,65 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x8
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-v-rk3399_defconfig 
> b/configs/khadas-edge-v-rk3399_defconfig
> new file mode 100644
> index 000..59bf5ca
> --- /dev/null
> +++ b/configs/khadas-edge-v-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x8
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-v"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v8 2/3] rockchip: rk3399: Add Rockpro64 board support

[Paul Kocialkowski]

+ fcs,suspend-voltage-selector = <1>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_gpio>;
> > > + regulator-name = "vdd_cpu_b";
> > > + regulator-min-microvolt = <712500>;
> > > + regulator-max-microvolt = <150>;
> > > + regulator-ramp-delay = <1000>;
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + vin-supply = <_sys>;
> > > +
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +
> > > + vdd_gpu: regulator@41 {
> > > + compatible = "silergy,syr828";
> > > + reg = <0x41>;
> > > + fcs,suspend-voltage-selector = <1>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_gpio>;
> > > + regulator-name = "vdd_gpu";
> > > + regulator-min-microvolt = <712500>;
> > > + regulator-max-microvolt = <150>;
> > > + regulator-ramp-delay = <1000>;
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + vin-supply = <_sys>;
> > > +
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> > > + };
> > > +};
> > > +
> > > + {
> > > + i2c-scl-rising-time-ns = <300>;
> > > + i2c-scl-falling-time-ns = <15>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + i2c-scl-rising-time-ns = <450>;
> > > + i2c-scl-falling-time-ns = <15>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + i2c-scl-rising-time-ns = <600>;
> > > + i2c-scl-falling-time-ns = <20>;
> > > + status = "okay";
> > > +
> > > + fusb0: typec-portc@22 {
> > > + compatible = "fcs,fusb302";
> > > + reg = <0x22>;
> > > + interrupt-parent = <>;
> > > + interrupts = ;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_int>;
> > > + vbus-supply = <_typec>;
> > > + status = "okay";
> > > + };
> > > +};
> > > +
> > > + {
> > > + rockchip,playback-channels = <8>;
> > > + rockchip,capture-channels = <8>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + rockchip,playback-channels = <2>;
> > > + rockchip,capture-channels = <2>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > +_domains {
> > > + status = "okay";
> > > +
> > > + bt656-supply = <_dvp>;
> > > + audio-supply = <_codec>;
> > > + sdmmc-supply = <_sdio>;
> > > + gpio1830-supply = <_3v0>;
> > > +};
> > > +
> > > +_io_domains {
> > > + pmu1830-supply = <_3v0>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + buttons {
> > > + pwrbtn: pwrbtn {
> > > + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO _pull_up>;
> > > + };
> > > + };
> > > +
> > > + fusb302x {
> > > + fusb0_int: fusb0-int {
> > > +     rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO _pull_up>;
> > > + };
> > > + };
> > > +
> > > + leds {
> > > + work_led_gpio: work_led-gpio {
> > > + rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO _pull_none>;
> > > + };
> > > +
> > > + diy_led_gpio: diy_led-gpio {
> > > + rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO _pull_none>;
> > > + };
> > > + };
> > > +
> > > + pcie {
> > > + pcie_pwr_en: pcie-pwr-en {
> > > + rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO _pull_none>;
> > > + };
> > > + };
> > > +
> > > + pmic {
> > > + pmic_int_l: pmic-int-l {
> > > + rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO _pull_up>;
> > > + };
> > > +
> > > + vsel1_gpio: vsel1-gpio {
> > > + rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO _pull_down>;
> > > + };
> > > +
> > > + vsel2_gpio: vsel2-gpio {
> > > + rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO _pull_down>;
> > > + };
> > > + };
> > > +
> > > + sdio-pwrseq {
> > > + wifi_enable_h: wifi-enable-h {
> > > + rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO _pull_none>;
> > > + };
> > > + };
> > > +
> > > + usb-typec {
> > > + vcc5v0_typec_en: vcc5v0_typec_en {
> > > + rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO _pull_up>;
> > > + };
> > > + };
> > > +
> > > + usb2 {
> > > + vcc5v0_host_en: vcc5v0-host-en {
> > > + rockchip,pins = <4 RK_PD2 RK_FUNC_GPIO _pull_none>;
> > > + };
> > > + };
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + vref-supply = <_s3>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + bus-width = <4>;
> > > + cap-mmc-highspeed;
> > > + cap-sd-highspeed;
> > > + cd-gpios = < 7 GPIO_ACTIVE_LOW>;
> > > + disable-wp;
> > > + max-frequency = <15000>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_clk _cmd _bus4>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + bus-width = <8>;
> > > + mmc-hs400-1_8v;
> > > + mmc-hs400-enhanced-strobe;
> > > + non-removable;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + /* tshut mode 0:CRU 1:GPIO */
> > > + rockchip,hw-tshut-mode = <1>;
> > > + /* tshut polarity 0:LOW 1:HIGH */
> > > + rockchip,hw-tshut-polarity = <1>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +
> > > + u2phy0_otg: otg-port {
> > > + status = "okay";
> > > + };
> > > +
> > > + u2phy0_host: host-port {
> > > + phy-supply = <_host>;
> > > + status = "okay";
> > > + };
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +
> > > + u2phy1_otg: otg-port {
> > > + status = "okay";
> > > + };
> > > +
> > > + u2phy1_host: host-port {
> > > + phy-supply = <_host>;
> > > + status = "okay";
> > > + };
> > > +};
> > > +
> > > + {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_xfer _cts>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > +_host0_ehci {
> > > + status = "okay";
> > > +};
> > > +
> > > +_host0_ohci {
> > > + status = "okay";
> > > +};
> > > +
> > > +_host1_ehci {
> > > + status = "okay";
> > > +};
> > > +
> > > +_host1_ohci {
> > > + status = "okay";
> > > +};
> > > +
> > > +_0 {
> > > + status = "okay";
> > > +};
> > > +
> > > +_dwc3_0 {
> > > + status = "okay";
> > > + dr_mode = "otg";
> > > +};
> > > +
> > > +_1 {
> > > + status = "okay";
> > > +};
> > > +
> > > +_dwc3_1 {
> > > + status = "okay";
> > > + dr_mode = "host";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > +_mmu {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > +_mmu {
> > > + status = "okay";
> > > +};
> > > diff --git a/board/rockchip/evb_rk3399/MAINTAINERS 
> > > b/board/rockchip/evb_rk3399/MAINTAINERS
> > > index 1f51f65160..295730c91b 100644
> > > --- a/board/rockchip/evb_rk3399/MAINTAINERS
> > > +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> > > @@ -30,3 +30,10 @@ S: Maintained
> > >  F:   configs/orangepi-rk3399_defconfig
> > >  F:   arch/arm/dts/rk3399-u-boot.dtsi
> > >  F:   arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> > > +
> > > +ROCKPRO64
> > > +M:   Akash Gajjar 
> > > +M:   Jagan Teki 
> > > +S:   Maintained
> > > +F:   configs/rockpro64-rk3399_defconfig
> > > +F:   arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > > diff --git a/configs/rockpro64-rk3399_defconfig 
> > > b/configs/rockpro64-rk3399_defconfig
> > > new file mode 100644
> > > index 00..90bcaedbd2
> > > --- /dev/null
> > > +++ b/configs/rockpro64-rk3399_defconfig
> > > @@ -0,0 +1,60 @@
> > > +CONFIG_ARM=y
> > > +CONFIG_ARCH_ROCKCHIP=y
> > > +CONFIG_SYS_TEXT_BASE=0x0020
> > > +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > > +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > > +CONFIG_SYS_MALLOC_F_LEN=0x4000
> > > +CONFIG_ROCKCHIP_RK3399=y
> > > +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5
> > > +CONFIG_DEBUG_UART_BASE=0xFF1A
> > > +CONFIG_DEBUG_UART_CLOCK=2400
> > > +CONFIG_SPL_STACK_R_ADDR=0x8
> > > +CONFIG_DEBUG_UART=y
> > > +CONFIG_NR_DRAM_BANKS=1
> > > +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb"
> > > +# CONFIG_DISPLAY_CPUINFO is not set
> > > +CONFIG_DISPLAY_BOARDINFO_LATE=y
> > > +CONFIG_SPL_STACK_R=y
> > > +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
> > > +CONFIG_CMD_BOOTZ=y
> > > +CONFIG_CMD_GPT=y
> > > +CONFIG_CMD_MMC=y
> > > +CONFIG_CMD_SF=y
> > > +CONFIG_CMD_USB=y
> > > +# CONFIG_CMD_SETEXPR is not set
> > > +CONFIG_CMD_TIME=y
> > > +CONFIG_SPL_OF_CONTROL=y
> > > +CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64"
> > > +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> > > interrupt-parent assigned-clocks assigned-clock-rates 
> > > assigned-clock-parents"
> > > +CONFIG_TPL=y
> > > +CONFIG_ENV_IS_IN_MMC=y
> > > +CONFIG_ROCKCHIP_GPIO=y
> > > +CONFIG_SYS_I2C_ROCKCHIP=y
> > > +CONFIG_MMC_DW=y
> > > +CONFIG_MMC_DW_ROCKCHIP=y
> > > +CONFIG_MMC_SDHCI=y
> > > +CONFIG_MMC_SDHCI_ROCKCHIP=y
> > > +CONFIG_DM_ETH=y
> > > +CONFIG_ETH_DESIGNWARE=y
> > > +CONFIG_GMAC_ROCKCHIP=y
> > > +CONFIG_PMIC_RK8XX=y
> > > +CONFIG_REGULATOR_PWM=y
> > > +CONFIG_REGULATOR_RK8XX=y
> > > +CONFIG_PWM_ROCKCHIP=y
> > > +CONFIG_BAUDRATE=150
> > > +CONFIG_DEBUG_UART_SHIFT=2
> > > +CONFIG_SYSRESET=y
> > > +CONFIG_USB=y
> > > +CONFIG_USB_XHCI_HCD=y
> > > +CONFIG_USB_XHCI_DWC3=y
> > > +CONFIG_USB_EHCI_HCD=y
> > > +CONFIG_USB_EHCI_GENERIC=y
> > > +CONFIG_USB_HOST_ETHER=y
> > > +CONFIG_USB_ETHER_ASIX=y
> > > +CONFIG_USB_ETHER_ASIX88179=y
> > > +CONFIG_USB_ETHER_MCS7830=y
> > > +CONFIG_USB_ETHER_RTL8152=y
> > > +CONFIG_USB_ETHER_SMSC95XX=y
> > > +CONFIG_USE_TINY_PRINTF=y
> > > +CONFIG_SPL_TINY_MEMSET=y
> > > +CONFIG_ERRNO_STR=y
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [linux-sunxi] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB

[Paul Kocialkowski]

Hi,

On Mon, 2019-05-27 at 00:50 +0100, André Przywara wrote:
> On 17/04/2019 12:28, Jagan Teki wrote:
> > On Mon, Apr 15, 2019 at 1:52 PM Paul Kocialkowski
> >  wrote:
> 
> Hi,
> 
> > > Le vendredi 12 avril 2019 à 14:49 +0530, Jagan Teki a écrit :
> > > > On Thu, Mar 14, 2019 at 4:08 PM Paul Kocialkowski
> > > >  wrote:
> > > > > Recent Allwinner platforms (starting with the H3) only use the MUSB
> > > > > controller for peripheral mode and use HCI for host mode. As a result,
> > > > > extra steps need to be taken to properly route USB signals to one or
> > > > > the other. More precisely, the following is required:
> > > > > * Routing the pins to either HCI/MUSB (controlled by PHY);
> > > > > * Enabling USB PHY passby in HCI mode (controlled by PMU).
> > > > > 
> > > > > The current code will enable passby for each PHY and reroute PHY0 to
> > > > > MUSB, which is inconsistent and results in broken USB peripheral 
> > > > > support.
> > > > > 
> > > > > Passby on PHY0 must only be enabled when we want to use HCI. Since
> > > > > host/device mode detection is not available from the PHY code and
> > > > > because U-Boot does not support changing the mode dynamically anyway,
> > > > > we can just mux the controller to MUSB if it is enabled and mux it to
> > > > > HCI otherwise.
> > > > > 
> > > > > This fixes USB peripheral support for platforms with PHY0 dual-route,
> > > > > especially H3/H5 and V3s.
> > > > > 
> > > > > Signed-off-by: Paul Kocialkowski 
> > > > > ---
> > > > >  drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
> > > > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> > > > > b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > > > index f206fa3f5d48..4f1c7e519d71 100644
> > > > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > > > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > > > @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy)
> > > > > data->cfg->disc_thresh, 
> > > > > PHY_DISCON_TH_LEN);
> > > > > }
> > > > > 
> > > > > +#ifdef CONFIG_USB_MUSB_SUNXI
> > > > > +   /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB 
> > > > > */
> > > > > +   if (usb_phy->id != 0)
> > > > > +   sun4i_usb_phy_passby(phy, true);
> > > > > +
> > > > > +   /* Route PHY0 to MUSB to allow USB gadget */
> > > > > +   if (data->cfg->phy0_dual_route)
> > > > > +   sun4i_usb_phy0_reroute(data, true);
> > > > > +#else
> > > > > sun4i_usb_phy_passby(phy, true);
> > > > > 
> > > > > -   sun4i_usb_phy0_reroute(data, true);
> > > > > +   /* Route PHY0 to HCI to allow USB host */
> > > > > +   if (data->cfg->phy0_dual_route)
> > > > > +   sun4i_usb_phy0_reroute(data, false);
> > > > > +#endif
> > > > 
> > > > I think we can manage this route and passby dynamically by detecting
> > > > id since we have dr_mode verify the MUSB host or peripheral via
> > > > usb_get_dr_mode, any chance to try that way?
> > > 
> > > Oh, I didn't know that U-Boot has support for usb_get_dr_mode these
> > > days. Thanks!
> > > 
> > > So far, the sunxi port has been using Kconfig to distinguish between
> > > host/device (unless I'm mistaken?) so I feel like this should be a
> > > separate follow-up patch to convert the sunxi MUSB glue + PHY to
> > > detecting dr_mode using usb_get_dr_mode. This feels like a significant
> > > rework, too.
> > 
> > Yes.
> > 
> > > Also, how should we handle the OTG case? I'm not sure we can support
> > > having both musb host and gadget built-in at this point. But that would
> > > certainly be welcome as part of the rework, too.
> > > 
> > > What do you think?
> > 
> > You mean handling dr_mode at runtime.
> > 
> > If yes, It is bit new where we can register the musb as UCLASS_MISC
> > wrapper and decide to bind driver for ho

Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards

[Paul Kocialkowski]

Hi,

On Thu, 2019-05-09 at 14:40 +0200, Philipp Tomsich wrote:
> Jagan,
> 
> > On 09.05.2019, at 14:36, Jagan Teki  wrote:
> > 
> > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski
> >  wrote:
> > > Hi,
> > > 
> > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote:
> > > > Hi Paul,
> > > > 
> > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski
> > > >  wrote:
> > > > > Hi,
> > > > > 
> > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote:
> > > > > > (Sorry for the noice, I have missed to send two patches from v7)
> > > > > > 
> > > > > > This is v7 resend patchset for New rk3399 boards support wrt 
> > > > > > previous
> > > > > > version[1]
> > > > > > 
> > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and
> > > > > > orangepi rk3399 changes are merged, so this is rework on top of
> > > > > > u-boot-rockchip/master.
> > > > > > 
> > > > > > Overall this series add support below rk3399 boards
> > > > > > - NanoPI M4
> > > > > > - NanoPC T4
> > > > > > - NanoPI NEO4
> > > > > > - Orangepi RK3399
> > > > > > - Rock PI 4
> > > > > > - Rockpro64
> > > > > > 
> > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and 
> > > > > > few
> > > > > > dts(i) from linux-next.
> > > > > > 
> > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of 
> > > > > > another
> > > > > > series [3].
> > > > > > 
> > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would 
> > > > > > support
> > > > > > booting via Rockchip miniloader as of now.
> > > > > 
> > > > > Could you send these two boards in a separate series so that we avoid
> > > > > merging them for now (because SPL support is broken) and then re-
> > > > > iterate the series later with the DDR bringup? Or maybe find a way to
> > > > > disable SPL support, but in any case, it's not ok to merge a board 
> > > > > with
> > > > > SPL enabled and broken.
> > > > 
> > > > I have explained the details about this concern on v2 [1], thought you
> > > > would comeback on the same line instead here.
> > > 
> > > Yes, you have already explained the issue, but I don't think it's
> > > enough a justification to merge broken SPL support. If it was only
> > > partial or limited, it would be fine, but here it's just broken.
> > > 
> > > > Anyway, making SPL as an optional is not an idea to go with Mainline
> > > > as we make many decisions with regards to make SPL is mandatory.
> > > 
> > > Yes I think making SPL mandatory is a good idea, so that's why I'm
> > > suggesting that we don't merge the boards until they have SPL support.
> > > 
> > > > Since the DDR is show stopper here (and it would really need a good
> > > > amount of time, since it effect the other boards), I can go with TPL
> > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of
> > > > booting stages. This way we can avoid skipping SPL usage, and many
> > > > config changes to make SPL optional.
> > > 
> > > Honestly I don't really see the point of merging these boards at all if
> > > they don't have SPL support. People who really want to use them with
> > > the rockchip blob can cherry-pick the patches from the list in the
> > > meantime.
> > > 
> > > It also creates incentive for people to free the DDR init, since that
> > > becomes a condition to have the board upstream.
> > > 
> > > What do you think?
> > 
> > I don't know whether you get my point or not? these boards are not
> > merged yet. What I'm saying is we are going to support them with
> > TPL-enabled, that was SPL can make use of these boards which still a
> > valid boot-chain. moreover this way can avoid touching core files and
> > no specific change require while supporting ddr dtsi.
> 
> On some boards, there will be no TPL and only a SPL stage that will
> initialise DRAM (as the move to having TPL on the RK3399 is optional).
> 
> I agree with Paul that the DRAM init should be part of U-Boot whenever
> we add new boards and make an open DRAM init a prerequisite.

Well, my initial point was to forbid merging broken SPL support, but I
am totally in favor of requiring free DRAM init for merging new boards.

Sadly it's hard to enforce this as a general rule in U-Boot since some
platforms are plagued by non-free first-stage bootloaders because of
signature checks, and that's where DRAM init happens.

But for RK3399, we can totally have that rule, which directly creates
incentive to free the blobs.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards

[Paul Kocialkowski]

On Thu, 2019-05-09 at 18:06 +0530, Jagan Teki wrote:
> On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote:
> > > Hi Paul,
> > > 
> > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote:
> > > > > (Sorry for the noice, I have missed to send two patches from v7)
> > > > > 
> > > > > This is v7 resend patchset for New rk3399 boards support wrt previous
> > > > > version[1]
> > > > > 
> > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and
> > > > > orangepi rk3399 changes are merged, so this is rework on top of
> > > > > u-boot-rockchip/master.
> > > > > 
> > > > > Overall this series add support below rk3399 boards
> > > > > - NanoPI M4
> > > > > - NanoPC T4
> > > > > - NanoPI NEO4
> > > > > - Orangepi RK3399
> > > > > - Rock PI 4
> > > > > - Rockpro64
> > > > > 
> > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few
> > > > > dts(i) from linux-next.
> > > > > 
> > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of 
> > > > > another
> > > > > series [3].
> > > > > 
> > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would 
> > > > > support
> > > > > booting via Rockchip miniloader as of now.
> > > > 
> > > > Could you send these two boards in a separate series so that we avoid
> > > > merging them for now (because SPL support is broken) and then re-
> > > > iterate the series later with the DDR bringup? Or maybe find a way to
> > > > disable SPL support, but in any case, it's not ok to merge a board with
> > > > SPL enabled and broken.
> > > 
> > > I have explained the details about this concern on v2 [1], thought you
> > > would comeback on the same line instead here.
> > 
> > Yes, you have already explained the issue, but I don't think it's
> > enough a justification to merge broken SPL support. If it was only
> > partial or limited, it would be fine, but here it's just broken.
> > 
> > > Anyway, making SPL as an optional is not an idea to go with Mainline
> > > as we make many decisions with regards to make SPL is mandatory.
> > 
> > Yes I think making SPL mandatory is a good idea, so that's why I'm
> > suggesting that we don't merge the boards until they have SPL support.
> > 
> > > Since the DDR is show stopper here (and it would really need a good
> > > amount of time, since it effect the other boards), I can go with TPL
> > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of
> > > booting stages. This way we can avoid skipping SPL usage, and many
> > > config changes to make SPL optional.
> > 
> > Honestly I don't really see the point of merging these boards at all if
> > they don't have SPL support. People who really want to use them with
> > the rockchip blob can cherry-pick the patches from the list in the
> > meantime.
> > 
> > It also creates incentive for people to free the DDR init, since that
> > becomes a condition to have the board upstream.
> > 
> > What do you think?
> 
> I don't know whether you get my point or not? these boards are not
> merged yet. What I'm saying is we are going to support them with
> TPL-enabled, that was SPL can make use of these boards which still a
> valid boot-chain. moreover this way can avoid touching core files and
> no specific change require while supporting ddr dtsi.

Ah maybe I missed the point indeed.

So what you are suggesting is:
rkboot (acts as TPL) -> SPL -> U-Boot?

Then I have no problem what that.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards

[Paul Kocialkowski]

Hi,

On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote:
> Hi Paul,
> 
> On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote:
> > > (Sorry for the noice, I have missed to send two patches from v7)
> > > 
> > > This is v7 resend patchset for New rk3399 boards support wrt previous
> > > version[1]
> > > 
> > > Unfortunately initial version of creating rk3399-u-boot.dtsi and
> > > orangepi rk3399 changes are merged, so this is rework on top of
> > > u-boot-rockchip/master.
> > > 
> > > Overall this series add support below rk3399 boards
> > > - NanoPI M4
> > > - NanoPC T4
> > > - NanoPI NEO4
> > > - Orangepi RK3399
> > > - Rock PI 4
> > > - Rockpro64
> > > 
> > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few
> > > dts(i) from linux-next.
> > > 
> > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another
> > > series [3].
> > > 
> > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support
> > > booting via Rockchip miniloader as of now.
> > 
> > Could you send these two boards in a separate series so that we avoid
> > merging them for now (because SPL support is broken) and then re-
> > iterate the series later with the DDR bringup? Or maybe find a way to
> > disable SPL support, but in any case, it's not ok to merge a board with
> > SPL enabled and broken.
> 
> I have explained the details about this concern on v2 [1], thought you
> would comeback on the same line instead here.

Yes, you have already explained the issue, but I don't think it's
enough a justification to merge broken SPL support. If it was only
partial or limited, it would be fine, but here it's just broken.

> Anyway, making SPL as an optional is not an idea to go with Mainline
> as we make many decisions with regards to make SPL is mandatory.

Yes I think making SPL mandatory is a good idea, so that's why I'm
suggesting that we don't merge the boards until they have SPL support.

> Since the DDR is show stopper here (and it would really need a good
> amount of time, since it effect the other boards), I can go with TPL
> enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of
> booting stages. This way we can avoid skipping SPL usage, and many
> config changes to make SPL optional.

Honestly I don't really see the point of merging these boards at all if
they don't have SPL support. People who really want to use them with
the rockchip blob can cherry-pick the patches from the list in the
meantime.

It also creates incentive for people to free the DDR init, since that
becomes a condition to have the board upstream.

What do you think?

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards

[Paul Kocialkowski]

9_defconfig  |  59 ++
>  doc/README.rockchip | 233 ++-
>  30 files changed, 2857 insertions(+), 119 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopc-t4.dts
>  create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts
>  create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts
>  create mode 100644 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rock-pi-4.dts
>  create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
>  create mode 100644 configs/nanopc-t4-rk3399_defconfig
>  create mode 100644 configs/nanopi-m4-rk3399_defconfig
>  create mode 100644 configs/nanopi-neo4-rk3399_defconfig
>  create mode 100644 configs/rock-pi-4-rk3399_defconfig
>  create mode 100644 configs/rockpro64-rk3399_defconfig
> 
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v6 09/13] rockchip: rk3399: Add Nanopc T4 board support

[Paul Kocialkowski]

Hi,

On Sat, 2019-04-27 at 17:18 +0530, Jagan Teki wrote:
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS 
> b/board/rockchip/evb_rk3399/MAINTAINERS
> index ae43805a6a..5917abb9c1 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -6,6 +6,12 @@ F:  include/configs/evb_rk3399.h
>  F:  configs/evb-rk3399_defconfig
>  F:  configs/firefly-rk3399_defconfig
>  
> +NANOPC-T4
> +M:   Jagan Teki 
> +S:   Maintained
> +F:   configs/nanopic-t4-rk3399_defconfig
> +F:   arch/arm/dts/rk3399-nanopic-t4-u-boot.dtsi
> +

Mhh, I feel like each new board that you are introducing should have
its own board directory -- this board is definitely not a rk3399 evb
made by rockchip, but another board.

I have already patches to split that for the firefly-rk3399, but I
cannot really test them outside of building.

>  NANOPI-M4
>  M:   Jagan Teki 
>  S:   Maintained
> diff --git a/configs/nanopc-t4-rk3399_defconfig 
> b/configs/nanopc-t4-rk3399_defconfig
> new file mode 100644
> index 00..7ba4f85485
> --- /dev/null
> +++ b/configs/nanopc-t4-rk3399_defconfig
> @@ -0,0 +1,58 @@

Also I don't see which TARGET is selected here, is there a fallback on
the RK3399 EVB for the rk3399 platform?

Cheers,

Paul

> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SPL_STACK_R_ADDR=0x8
> +CONFIG_DEBUG_UART=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopc-t4.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopc-t4"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_ERRNO_STR=y
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v6 0/3] arm64: rockchip: dts: Add rk3399 -u-boot.dtsi files

[Paul Kocialkowski]

Hi,

On Sat, 2019-04-27 at 17:11 +0530, Jagan Teki wrote:
> This series is a rework of v5 patch that send it in separate series[1]
> 
> All these changes are creating an initial rk3399-u-boot.dtsi and rk3399
> board -u-boot.dtsi files and u-boot specific dts changes like
> - sdram dtsi
> - sdmmc, u-boot,dm-pre-reloc
> - spi1, u-boot,dm-pre-reloc

For the whole series:
Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Changes for v6:
> - spilt the existing patch[1] into multiple patches
>   and send as a separate series.
> 
> [1] https://patchwork.ozlabs.org/patch/1091720/
> 
> Any inputs?
> Jagan.
> 
> Jagan Teki (3):
>   arm64: rockchip: dts: rk3399: Add board -u-boot.dtsi files
>   arm64: rockchip: dts: Add initial rk3399-u-boot.dtsi file
>   arm64: rockchip: dts: rk3399: Use rk3399-u-boot.dtsi
> 
>  arch/arm/dts/rk3399-evb-u-boot.dtsi |  7 +++
>  arch/arm/dts/rk3399-evb.dts |  2 --
>  arch/arm/dts/rk3399-ficus-u-boot.dtsi   |  6 ++
>  arch/arm/dts/rk3399-ficus.dts   |  1 -
>  arch/arm/dts/rk3399-firefly-u-boot.dtsi |  7 +++
>  arch/arm/dts/rk3399-firefly.dts |  2 --
>  arch/arm/dts/rk3399-gru-bob-u-boot.dtsi |  7 +++
>  arch/arm/dts/rk3399-gru-bob.dts |  1 -
>  arch/arm/dts/rk3399-gru-u-boot.dtsi |  6 ++
>  arch/arm/dts/rk3399-gru.dtsi|  1 -
>  arch/arm/dts/rk3399-puma-ddr1600.dts|  1 +
>  arch/arm/dts/rk3399-puma.dtsi   |  3 ---
>  arch/arm/dts/rk3399-rock960-u-boot.dtsi |  6 ++
>  arch/arm/dts/rk3399-rock960.dts |  1 -
>  arch/arm/dts/rk3399-u-boot.dtsi | 12 
>  15 files changed, 52 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-evb-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-ficus-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-firefly-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-gru-bob-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-gru-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rock960-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
> 
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

Le vendredi 26 avril 2019 à 23:12 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 11:07 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only 
> > > > > > > > > the new
> > > > > > > > > boards are using this file and next series rest of the boards 
> > > > > > > > > are
> > > > > > > > > using which indeed a valid step. what is inconsistent here, I 
> > > > > > > > > don't
> > > > > > > > > understand.
> > > > > > > > 
> > > > > > > > Yes, what you are describing is exactly the issue. It does not 
> > > > > > > > make
> > > > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add 
> > > > > > > > new
> > > > > > > > devices that use this file *before* switching existing devices 
> > > > > > > > to the
> > > > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > > > 
> > > > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? 
> > > > > > > as
> > > > > > > patch says it is an initial one and it is bit hard to add all at 
> > > > > > > once.
> > > > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > > > unaffected to any of the existing dts files.
> > > > > > 
> > > > > > Again, it's not a technical issue. Your proposal works and has no
> > > > > > technical issue. The issue is in how the commits are grouped 
> > > > > > together.
> > > > > > Patch series need to make logical sense. One patch series should
> > > > > > accomplish one change, and each patch represents a step of that 
> > > > > > change.
> > > > > 
> > > > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > > > this kind of discussion may not happen. In first mail you said
> > > > > "something broken and how it can repair next" that indeed doesn't make
> > > > > any sense of without understanding the whole series of changes.
> > > > 
> > > > One part to that is that I had misunderstood a few things, but I really
> > > > should not have to look at each patch before I can have an idea of what
> > > > the series does. Your series is called "rockchip: Add new rk3399
> > > > boards" and with the v3.1 change you made, the title is no longer true.
> > > > You are doing that + introducing a new rk3399 u-boot dtsi without
> > > > switching existing boards to it before adding new ones.
> > > > 
> > > > From that moment, you needed to split your changes into two series.
> > > > Instead of that, you made another series with mostly unrelated changes
> > > > where you included an unrelated commit adding the pre-reloc entries to
> > > > the dtsi created in the previous series.
> > > > 
> > > > That's an issue for communication with the community.
> > > > 
> > > > > Any new changes would come up with initial version, that what we
> > > > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > > > developers are using the same is adding one after another.
> > > > 
> > > > But you already have boards in the tree that needs the tree. You can
> > > > make individual commits for switching boards to the new dtsi, but you
> > > > need to do that in the same series as introducing the dtsi if you are
> > > > submitting both things at the same time. If you want to have them
> > > > merged separately, then you can send device dtsi patches individually
> > > > for that, but not as part of another unrelated series.
> > > > 
> > > > > > This is how upstream contributions work, and it's a powerful way to
> > > > > > allow both efficient code review and good code quality. We want t

Re: [U-Boot] [PATCH 1/5] arm64: rockchip: dts: rk3399: Create -u-boot.dtsi files

[Paul Kocialkowski]

Hi,

Please split off this two commits to another dedicated series, with the
patch introducing rk3399-u-boot.dtsi. You can then decide to introduce
rk3399 boards support (in a third series) before or after.

Cheers,

Paul

Le vendredi 26 avril 2019 à 19:04 +0530, Jagan Teki a écrit :
> We have a base rk3399-u-boot.dtsi which enabled sdmmc for SPL,
> extend the same with spi1 so-that the SPL spi boot boards can
> make use of the same.
> 
> So, to make use of this common rk3399-u-boot.dtsi we have to
> include this in respective dts files.
> 
> So, this patch will create all preliminary infrastructure, like
> - create -u-boot.dtsi
> - include rk3399-u-boot.dtsi
> - move sdram dtsi into -u-boot.dtsi
> - drop sdmmc, u-boot,dm-pre-reloc
> - drop spi1, u-boot,dm-pre-reloc
> 
> This would help to
> - sync the dts(i) files from Linux whenever required instead of
>   adding specific nodes.
> - easy to add u-boot specific changes like binman node into common
>   -u-boot.dtsi file
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3399-evb-u-boot.dtsi | 7 +++
>  arch/arm/dts/rk3399-evb.dts | 2 --
>  arch/arm/dts/rk3399-ficus-u-boot.dtsi   | 7 +++
>  arch/arm/dts/rk3399-ficus.dts   | 1 -
>  arch/arm/dts/rk3399-firefly-u-boot.dtsi | 7 +++
>  arch/arm/dts/rk3399-firefly.dts | 2 --
>  arch/arm/dts/rk3399-gru-bob-u-boot.dtsi | 7 +++
>  arch/arm/dts/rk3399-gru-bob.dts | 1 -
>  arch/arm/dts/rk3399-gru.dtsi| 1 -
>  arch/arm/dts/rk3399-puma-ddr1600.dts| 2 +-
>  arch/arm/dts/rk3399-puma.dtsi   | 3 ---
>  arch/arm/dts/rk3399-rock960-u-boot.dtsi | 7 +++
>  arch/arm/dts/rk3399-rock960.dts | 1 -
>  arch/arm/dts/rk3399-u-boot.dtsi | 4 
>  14 files changed, 40 insertions(+), 12 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-evb-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-ficus-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-firefly-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-gru-bob-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rock960-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi 
> b/arch/arm/dts/rk3399-evb-u-boot.dtsi
> new file mode 100644
> index 00..20910e744b
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
> diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> index ce004d0d18..a506e8da37 100644
> --- a/arch/arm/dts/rk3399-evb.dts
> +++ b/arch/arm/dts/rk3399-evb.dts
> @@ -7,7 +7,6 @@
>  #include 
>  #include 
>  #include "rk3399.dtsi"
> -#include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
>  
>  / {
>   model = "Rockchip RK3399 Evaluation Board";
> @@ -155,7 +154,6 @@
>  };
>  
>   {
> - u-boot,dm-pre-reloc;
>   bus-width = <4>;
>   status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-ficus-u-boot.dtsi 
> b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> new file mode 100644
> index 00..67b63a8352
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-ddr3-1600.dtsi"
> diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
> index 4af0e4e383..4b2dd82b67 100644
> --- a/arch/arm/dts/rk3399-ficus.dts
> +++ b/arch/arm/dts/rk3399-ficus.dts
> @@ -8,7 +8,6 @@
>  
>  /dts-v1/;
>  #include "rk3399-rock960.dtsi"
> -#include "rk3399-sdram-ddr3-1600.dtsi"
>  
>  / {
>   model = "96boards RK3399 Ficus";
> diff --git a/arch/arm/dts/rk3399-firefly-u-boot.dtsi 
> b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
> new file mode 100644
> index 00..67b63a8352
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-ddr3-1600.dtsi"
> diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> index f90e7e88db..a4cb64f8bd 100644
> --- a/arch/arm/dts/rk3399-firefly.dts
> +++ b/arch/arm/dts/rk3399-firefly.dts
> @@ -7,7 +7,6 @@
>  #include 
>  #include 
>  #include "rk3399.dtsi"
> -#include "rk3399-sdram-ddr3-1600.dtsi"
>  
>  / {
>   model = "Firefly-RK3399 Board";
> @@ -592,7 +591,6 @@
>  };
>  
>   {
> - u-boot,dm-pre-reloc;
>   bus-width = <4>;
>   status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-gru-bob-u-boot.dtsi 
> b/arch/arm/dts/rk3399-gru-bob-u-boot.dtsi
> new file mode 100644
> index 00..f0d31edefd
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-gru-bob-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include 

Re: [U-Boot] [PATCH 0/5] rk3399: make u-boot-rockchip-with-spl.bin

[Paul Kocialkowski]

Le vendredi 26 avril 2019 à 23:22 +0530, Jagan Teki a écrit :
> Hi Tom and Simon,
> 
> On Fri, Apr 26, 2019 at 7:04 PM Jagan Teki  wrote:
> > This series will create single bootable image 'u-boot-rockchip-with-spl.bin'
> > for rk3399 platform with single make command instead of building u-boot
> > separately for u-boot.itb and burn them separately for SPL and U-Boot 
> > proper.
> > 
> > This series has dependecy with[1]
> > 
> > travis-ci issue:
> > - need to include 'python-pyelftools' package, tried but can't succeed
> > - right now build failed if BL31 is not exported, but this would manage to
> > create dummy arm64 elf but any help on this would appreciate.
> 
> Any inputs on this?

I think we have the same issue regarding BL31 for ARM64 sunxi boards
don't we?

It would be great to have a solution to this, and even better if it
could scale to most ARM64 platforms too!

Cheers,

Paul

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

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the 
> > > > > > > new
> > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > using which indeed a valid step. what is inconsistent here, I 
> > > > > > > don't
> > > > > > > understand.
> > > > > > 
> > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > devices that use this file *before* switching existing devices to 
> > > > > > the
> > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > 
> > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > unaffected to any of the existing dts files.
> > > > 
> > > > Again, it's not a technical issue. Your proposal works and has no
> > > > technical issue. The issue is in how the commits are grouped together.
> > > > Patch series need to make logical sense. One patch series should
> > > > accomplish one change, and each patch represents a step of that change.
> > > 
> > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > this kind of discussion may not happen. In first mail you said
> > > "something broken and how it can repair next" that indeed doesn't make
> > > any sense of without understanding the whole series of changes.
> > 
> > One part to that is that I had misunderstood a few things, but I really
> > should not have to look at each patch before I can have an idea of what
> > the series does. Your series is called "rockchip: Add new rk3399
> > boards" and with the v3.1 change you made, the title is no longer true.
> > You are doing that + introducing a new rk3399 u-boot dtsi without
> > switching existing boards to it before adding new ones.
> > 
> > From that moment, you needed to split your changes into two series.
> > Instead of that, you made another series with mostly unrelated changes
> > where you included an unrelated commit adding the pre-reloc entries to
> > the dtsi created in the previous series.
> > 
> > That's an issue for communication with the community.
> > 
> > > Any new changes would come up with initial version, that what we
> > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > developers are using the same is adding one after another.
> > 
> > But you already have boards in the tree that needs the tree. You can
> > make individual commits for switching boards to the new dtsi, but you
> > need to do that in the same series as introducing the dtsi if you are
> > submitting both things at the same time. If you want to have them
> > merged separately, then you can send device dtsi patches individually
> > for that, but not as part of another unrelated series.
> > 
> > > > This is how upstream contributions work, and it's a powerful way to
> > > > allow both efficient code review and good code quality. We want to keep
> > > > things as simple, explicit and well-described as possible, so that
> > > > things are easy for reviewers and as many people as possible can
> > > > understand the issue and share their thoughts about it.
> > > 
> > > Yes, we adopt these principles and that what we are really working.
> > > 
> > > > It is all part of communication with others as part of a community.
> > > > It is definitely an implicit rule that is not written down somewhere
> > > > precisely, but that's the social contract between developers that work
> > > > on a common software project.
> > > > 
> > > > In that, contributing to upstream is different than baseline tech
> > > > company standards, because you have to take extra steps to describe
> > > > your work and explain it to others. You must make sure you give them
> > > > all the comfort they need to pain

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > boards are using this file and next series rest of the boards are
> > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > understand.
> > > > 
> > > > Yes, what you are describing is exactly the issue. It does not make
> > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > devices that use this file *before* switching existing devices to the
> > > > new common u-boot dtsi for rk3399 in the same series.
> > > 
> > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > patch says it is an initial one and it is bit hard to add all at once.
> > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > unaffected to any of the existing dts files.
> > 
> > Again, it's not a technical issue. Your proposal works and has no
> > technical issue. The issue is in how the commits are grouped together.
> > Patch series need to make logical sense. One patch series should
> > accomplish one change, and each patch represents a step of that change.
> 
> It's about how you think. say if I wouldn't send the binman, I'm sure
> this kind of discussion may not happen. In first mail you said
> "something broken and how it can repair next" that indeed doesn't make
> any sense of without understanding the whole series of changes.

One part to that is that I had misunderstood a few things, but I really
should not have to look at each patch before I can have an idea of what
the series does. Your series is called "rockchip: Add new rk3399
boards" and with the v3.1 change you made, the title is no longer true.
You are doing that + introducing a new rk3399 u-boot dtsi without
switching existing boards to it before adding new ones.

From that moment, you needed to split your changes into two series.
Instead of that, you made another series with mostly unrelated changes
where you included an unrelated commit adding the pre-reloc entries to
the dtsi created in the previous series.

That's an issue for communication with the community.

> Any new changes would come up with initial version, that what we
> usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> developers are using the same is adding one after another.

But you already have boards in the tree that needs the tree. You can
make individual commits for switching boards to the new dtsi, but you
need to do that in the same series as introducing the dtsi if you are
submitting both things at the same time. If you want to have them
merged separately, then you can send device dtsi patches individually
for that, but not as part of another unrelated series.

> > This is how upstream contributions work, and it's a powerful way to
> > allow both efficient code review and good code quality. We want to keep
> > things as simple, explicit and well-described as possible, so that
> > things are easy for reviewers and as many people as possible can
> > understand the issue and share their thoughts about it.
> 
> Yes, we adopt these principles and that what we are really working.
> 
> > It is all part of communication with others as part of a community.
> > It is definitely an implicit rule that is not written down somewhere
> > precisely, but that's the social contract between developers that work
> > on a common software project.
> > 
> > In that, contributing to upstream is different than baseline tech
> > company standards, because you have to take extra steps to describe
> > your work and explain it to others. You must make sure you give them
> > all the comfort they need to painlessly understand what you did.
> 
> I hope all my communication was relevant to the topics, I can even
> given the example how things were moved.

Clearly there was a major communication issue between us. You only
answered on technical topics and never about how your patch series is
organized and what logical changes you are making.

To be honest with you, I feel like we have a general communication
issue where you only seem to focus on technical aspects, when the
issues are about the meta-data of the changes such as commit messages,
code comments and how changes are organized together.

> > It plays a great deal in having series accepted without going through
> > very long discussions and numerous iterations. The less questions
> > maintainers will have about your work, the better. They may disagree
> > with the decisions you took, but these discussions are purely technical
> > and can be resolved quickly.
> 
> Pure technical, yes ie what I thought off. no problem for me for long
> discussion atleast people can understand how things went.

Community discussions can not, and must not be purely technical. This
is not a personal opinion of mine, this is how all free software
communities work. Some care more than others about it, but in very
technical 

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

Le vendredi 26 avril 2019 à 21:46 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 9:38 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > > >  wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > > >  wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > > >  wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Specification
> > > > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > > > - SD card slot
> > > > > > > > > > > > 
> > > > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have 
> > > > > > > > > > > > it working, which
> > > > > > > > > > > > will need to be introduced when moving to 
> > > > > > > > > > > > rk3399-u-boot.dtsi.
> > > > > > > > > > > 
> > > > > > > > > > > Look like you are confused or doesn't check the patch. 
> > > > > > > > > > > This patch have
> > > > > > > > > > > rk3399-orangepi-u-boot.dtsi which included 
> > > > > > > > > > > rk3399-u-boot.dtsi that has
> > > > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > > > 
> > > > > > > > > > Well no, in your v3.1 patch, you no longer have 
> > > > > > > > > > u-boot,dm-pre-reloc in
> > > > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts 
> > > > > > > > > > and remove
> > > > > > > > > > it in your second series when you add it back to 
> > > > > > > > > > rk3399-u-boot.dtsi.
> > > > > > > > > 
> > > > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > > > 
> > > > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again 
> > > > > > > > > [1]
> > > > > > > > > which were used by subsequent boards on the same series.
> > > > > > > > > 
> > > > > > > > > The diff between v3 vs v3.1 is like v3 removed 
> > > > > > > > > u-boot,dm-pre-reloc on
> > > > > > > > > existing board dts files thought that it will include
> > > > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in 
> > > > > > > > > v3.1
> > > > > > > > > 
> > > > > > > > > > It's not okay to submit the board with broken MMC support 
> > > > > > > > > > and fix it in

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > >  wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > >  wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > 
> > > > > > > > > > > Specification
> > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > - SD card slot
> > > > > > > > > > 
> > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it 
> > > > > > > > > > working, which
> > > > > > > > > > will need to be introduced when moving to 
> > > > > > > > > > rk3399-u-boot.dtsi.
> > > > > > > > > 
> > > > > > > > > Look like you are confused or doesn't check the patch. This 
> > > > > > > > > patch have
> > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi 
> > > > > > > > > that has
> > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > 
> > > > > > > > Well no, in your v3.1 patch, you no longer have 
> > > > > > > > u-boot,dm-pre-reloc in
> > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and 
> > > > > > > > remove
> > > > > > > > it in your second series when you add it back to 
> > > > > > > > rk3399-u-boot.dtsi.
> > > > > > > 
> > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > 
> > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > which were used by subsequent boards on the same series.
> > > > > > > 
> > > > > > > The diff between v3 vs v3.1 is like v3 removed 
> > > > > > > u-boot,dm-pre-reloc on
> > > > > > > existing board dts files thought that it will include
> > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > 
> > > > > > > > It's not okay to submit the board with broken MMC support and 
> > > > > > > > fix it in
> > > > > > > > a subsequent series.
> > > > > > > 
> > > > > > > Again, nothing broken. existing boards or dts(i) files are 
> > > > > > > untouched.
> > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc 
> > > > > > > u-boot,dm-pre-reloc
> > > > > > > node to make use of new boards.  and the same reused by next 
> > > > > > > series
> > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > 
> > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while 
> > > > > > all
> > > > > > other

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > >  wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > 
> > > > > > > > > Specification
> > > > > > > > > - Rockchip RK3399
> > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > - 16GB eMMC
> > > > > > > > > - SD card slot
> > > > > > > > 
> > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it 
> > > > > > > > working, which
> > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > 
> > > > > > > Look like you are confused or doesn't check the patch. This patch 
> > > > > > > have
> > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi 
> > > > > > > that has
> > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > 
> > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc 
> > > > > > in
> > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and 
> > > > > > remove
> > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > 
> > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > 
> > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > which were used by subsequent boards on the same series.
> > > > > 
> > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > existing board dts files thought that it will include
> > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > 
> > > > > > It's not okay to submit the board with broken MMC support and fix 
> > > > > > it in
> > > > > > a subsequent series.
> > > > > 
> > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > node to make use of new boards.  and the same reused by next series
> > > > > so-that I can add binman global to all rk3399 boards.
> > > > 
> > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > other boards are still using the previous scheme after the series.
> > > > 
> > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > all the other boards. You're mixing multiple logical steps which makes
> > > > it really hard to understand what's going on.
> > > > 
> > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > should be grouped with your second series, not the first one. In your
> > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > 
> > > > Could you respin the two series to group changes by logic changes
> > > > instead of the current state of interleaved changes?
> > > 
> > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > commit log. but I the new series about binman remains same since the
> &

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > 
> > > > > > > Specification
> > > > > > > - Rockchip RK3399
> > > > > > > - 2GB/4GB DDR3
> > > > > > > - 16GB eMMC
> > > > > > > - SD card slot
> > > > > > 
> > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, 
> > > > > > which
> > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > 
> > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > 
> > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > 
> > > Which u-boot,dm-pre-reloc are you taking about?
> > > 
> > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > which were used by subsequent boards on the same series.
> > > 
> > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > existing board dts files thought that it will include
> > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > 
> > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > a subsequent series.
> > > 
> > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > node to make use of new boards.  and the same reused by next series
> > > so-that I can add binman global to all rk3399 boards.
> > 
> > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > other boards are still using the previous scheme after the series.
> > 
> > This is very confusing and I really think you should keep u-boot,dm-
> > pre-reloc in the orange pi dts file and then make the transition with
> > all the other boards. You're mixing multiple logical steps which makes
> > it really hard to understand what's going on.
> > 
> > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > should be grouped with your second series, not the first one. In your
> > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > 
> > Could you respin the two series to group changes by logic changes
> > instead of the current state of interleaved changes?
> 
> Okay, to make it clear I can send v4 with v3.1 included and updated
> commit log. but I the new series about binman remains same since the
> changes on first patch on the series are relevant.

I think it makes no sense to introduce rk3399-u-boot.dts as part of the
series currently in v3. You need to remove the patch (currently v3.1)
from this series and group it with the new series (binman-related).

Otherwise, you're mixing two unrelated logical changes across two
series.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > Add initial support for Orangepi RK3399 board.
> > > > > 
> > > > > Specification
> > > > > - Rockchip RK3399
> > > > > - 2GB/4GB DDR3
> > > > > - 16GB eMMC
> > > > > - SD card slot
> > > > 
> > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > 
> > > Look like you are confused or doesn't check the patch. This patch have
> > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > u-boot,dm-pre-reloc for sdmmc.
> > 
> > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > it in your second series when you add it back to rk3399-u-boot.dtsi.
> 
> Which u-boot,dm-pre-reloc are you taking about?
> 
> v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> which were used by subsequent boards on the same series.
> 
> The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> existing board dts files thought that it will include
> rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> 
> > It's not okay to submit the board with broken MMC support and fix it in
> > a subsequent series.
> 
> Again, nothing broken. existing boards or dts(i) files are untouched.
> Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> node to make use of new boards.  and the same reused by next series
> so-that I can add binman global to all rk3399 boards.

Okay I think I'm getting there. So the Orangepi uses the new scheme
(including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
other boards are still using the previous scheme after the series.

This is very confusing and I really think you should keep u-boot,dm-
pre-reloc in the orange pi dts file and then make the transition with
all the other boards. You're mixing multiple logical steps which makes
it really hard to understand what's going on.

More to that, introducing the rk3399-u-boot.dtsi is a logical step that
should be grouped with your second series, not the first one. In your
first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.

Could you respin the two series to group changes by logic changes
instead of the current state of interleaved changes?

Mixing logical changes (not to mention spreading them accross series)
is really a no-go and makes reviewing the patches very difficult, as
this thread perfectly illustrates.

It's really not against you personally, but there are such rules that
need to be followed in upstream contributions. They are at least as
essential as the underlying technical work.

Cheers,

Paul

> [1] https://patchwork.ozlabs.org/patch/1091534/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > Add initial support for Orangepi RK3399 board.
> > > 
> > > Specification
> > > - Rockchip RK3399
> > > - 2GB/4GB DDR3
> > > - 16GB eMMC
> > > - SD card slot
> > 
> > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > will need to be introduced when moving to rk3399-u-boot.dtsi.
> 
> Look like you are confused or doesn't check the patch. This patch have
> rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> u-boot,dm-pre-reloc for sdmmc.

Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
it in your second series when you add it back to rk3399-u-boot.dtsi.

It's not okay to submit the board with broken MMC support and fix it in
a subsequent series.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3.1 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 19:55 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 7:46 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 19:32 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 7:28 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 19:20 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 7:12 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 19:07 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 7:04 PM Paul Kocialkowski
> > > > > > >  wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Fri, 2019-04-26 at 18:48 +0530, Jagan Teki wrote:
> > > > > > > > > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 
> > > > > > > > > boards and
> > > > > > > > > which is U-Boot specific devicetrees binding.
> > > > > > > > > 
> > > > > > > > > Move it on global rk3399-u-boot.dtsi file and rest of the 
> > > > > > > > > U-Boot
> > > > > > > > > bindings will move it future based on the requirement.
> > > > > > > > > 
> > > > > > > > > This would help to sync the devicetrees from Linux whenever 
> > > > > > > > > required
> > > > > > > > > instead of adding specific nodes.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Jagan Teki 
> > > > > > > > > Reviewed-by: Paul Kocialkowski 
> > > > > > > > 
> > > > > > > > Since your patch has changed significantly, you can no longer 
> > > > > > > > include a
> > > > > > > > Reviewed-by that was given on a previous iteration.
> > > > > > > > 
> > > > > > > > It looks like we are still missing bits to have 
> > > > > > > > rk3399-u-boot.dtsi
> > > > > > > > included, so this patch does not get my Reviewed-by tag.
> > > > > > > 
> > > > > > > It will include rockchip-u-boot.dtsi automatically and I made the
> > > > > > > receptive changes to include other files in this patch [1] and 
> > > > > > > sure I
> > > > > > > will ask Philipp to remove the reviewed-by tag, thanks.
> > > > > > 
> > > > > > Most importantly (now that I see the new series), you should 
> > > > > > certainly
> > > > > > have sent that patch as part of your new series because we now have 
> > > > > > an
> > > > > > inter-dependency between both series.
> > > > > 
> > > > > It is not like an inter-dependency the previous rk3399-u-boot.dtsi is
> > > > > not included by these files so they would work as before. and now this
> > > > > series would need this change to include rk3399-u-boot.dtsi since the
> > > > > goal here to add binman node to common for all rk3399 dts files.
> > > > 
> > > > Well, what I mean is that the latest series you sent mentions a
> > > > dependency on the first one, when it really should be the other way
> > > > round: you need the rework to make things in your first series work at
> > > > all, since that dm-pre-reloc is necessary.
> > > > 
> > > > We don't want to merge one broken series and then the fix for it later,
> > > > even if it would still build in all cases. Here there is a clear
> > > > logical dependency, in the reverse ordre to the one you are describing.
> > > 
> > > I don't understand your point, sorry.
> > > 
> > > This patch [1] will make use of the new boards added on that series it
> > > will not effect existing or previous rk3399 boards. in that case why
> > > it is broken patch or series could you elaborate? the existing boards
> > > are already supported dm-pre-reloc on their respective devicetree
> > > files.
> > 
> > On looks like I still didn't really get what you are trying to do.
> > Let's try and recap the situation:
> > 
> > - Currently, we have rk3399 boards wit

Re: [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> Add initial support for Orangepi RK3399 board.
> 
> Specification
> - Rockchip RK3399
> - 2GB/4GB DDR3
> - 16GB eMMC
> - SD card slot

Looks like you're missing u-boot,dm-pre-reloc to have it working, which
will need to be introduced when moving to rk3399-u-boot.dtsi.

Cheers,

Paul

> - RTL8211E 1Gbps
> - AP6356S WiFI/BT
> - HDMI In/Out, DP, MIPI DSI/CSI
> - Mini PCIe
> - Sensors, Keys etc
> - DC12V-2A and DC5V-2A
> 
> Commit details about Linux DTS sync:
> "arm64: dts: rockchip: Add support for the Orange Pi RK3399"
> (sha1: d3e71487a790979057c0fdbf32f85033639c16e6)
> 
> Signed-off-by: Jagan Teki 
> Reviewed-by: Paul Kocialkowski 
> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/rk3399-orangepi-u-boot.dtsi |   7 +
>  arch/arm/dts/rk3399-orangepi.dts | 771 +++
>  board/rockchip/evb_rk3399/MAINTAINERS|   7 +
>  configs/orangepi-rk3399_defconfig|  58 ++
>  5 files changed, 844 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-orangepi.dts
>  create mode 100644 configs/orangepi-rk3399_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0e2ffdb87f..6d55b0caf8 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3399-evb.dtb \
>   rk3399-firefly.dtb \
>   rk3399-gru-bob.dtb \
> + rk3399-orangepi.dtb \
>   rk3399-puma-ddr1333.dtb \
>   rk3399-puma-ddr1600.dtb \
>   rk3399-puma-ddr1866.dtb \
> diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi 
> b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> new file mode 100644
> index 00..236b61d78d
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-ddr3-1333.dtsi"
> diff --git a/arch/arm/dts/rk3399-orangepi.dts 
> b/arch/arm/dts/rk3399-orangepi.dts
> new file mode 100644
> index 00..cf37b96a6b
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi.dts
> @@ -0,0 +1,771 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "dt-bindings/pwm/pwm.h"
> +#include "dt-bindings/input/input.h"
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Orange Pi RK3399 Board";
> + compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = < 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <180>;
> + poll-interval = <100>;
> +
> + button-up {
> + label = "Volume Up";
> + linux,code = ;
> + press-threshold-microvolt = <10>;
> + };
> +
> + button-down {
> + label = "Volume Down";
> + linux,code = ;
> + press-threshold-microvolt = <30>;
> + };
> +
> + back {
> + label = "Back";
> + linux,code = ;
> + press-threshold-microvolt = <985000>;
> + };
> +
> + menu {
> + label = "Menu";
> + linux,code = ;
> + press-threshold-microvolt = <1314000>;
> + };
> + };
> +
> + dc_12v: dc-12v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + };
> +
> +

Re: [U-Boot] [PATCH v3.1 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 19:32 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 7:28 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 19:20 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 7:12 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 19:07 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 7:04 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 18:48 +0530, Jagan Teki wrote:
> > > > > > > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> > > > > > > which is U-Boot specific devicetrees binding.
> > > > > > > 
> > > > > > > Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> > > > > > > bindings will move it future based on the requirement.
> > > > > > > 
> > > > > > > This would help to sync the devicetrees from Linux whenever 
> > > > > > > required
> > > > > > > instead of adding specific nodes.
> > > > > > > 
> > > > > > > Signed-off-by: Jagan Teki 
> > > > > > > Reviewed-by: Paul Kocialkowski 
> > > > > > 
> > > > > > Since your patch has changed significantly, you can no longer 
> > > > > > include a
> > > > > > Reviewed-by that was given on a previous iteration.
> > > > > > 
> > > > > > It looks like we are still missing bits to have rk3399-u-boot.dtsi
> > > > > > included, so this patch does not get my Reviewed-by tag.
> > > > > 
> > > > > It will include rockchip-u-boot.dtsi automatically and I made the
> > > > > receptive changes to include other files in this patch [1] and sure I
> > > > > will ask Philipp to remove the reviewed-by tag, thanks.
> > > > 
> > > > Most importantly (now that I see the new series), you should certainly
> > > > have sent that patch as part of your new series because we now have an
> > > > inter-dependency between both series.
> > > 
> > > It is not like an inter-dependency the previous rk3399-u-boot.dtsi is
> > > not included by these files so they would work as before. and now this
> > > series would need this change to include rk3399-u-boot.dtsi since the
> > > goal here to add binman node to common for all rk3399 dts files.
> > 
> > Well, what I mean is that the latest series you sent mentions a
> > dependency on the first one, when it really should be the other way
> > round: you need the rework to make things in your first series work at
> > all, since that dm-pre-reloc is necessary.
> > 
> > We don't want to merge one broken series and then the fix for it later,
> > even if it would still build in all cases. Here there is a clear
> > logical dependency, in the reverse ordre to the one you are describing.
> 
> I don't understand your point, sorry.
> 
> This patch [1] will make use of the new boards added on that series it
> will not effect existing or previous rk3399 boards. in that case why
> it is broken patch or series could you elaborate? the existing boards
> are already supported dm-pre-reloc on their respective devicetree
> files.

On looks like I still didn't really get what you are trying to do.
Let's try and recap the situation:

- Currently, we have rk3399 boards with u-boot,dm-pre-reloc in their
shared dtsi;
- Your v3.1 adds rk3399-u-boot.dtsi but keeps the u-boot,dm-pre-reloc
in each device since rk3399-u-boot won't be included.
- Your new series allows rk3399-u-boot.dtsi to be included
automatically, so we can move the per-common-device-dts u-boot,dm-pre-
reloc to rk3399-u-boot.dtsi

If that's correct, then it indeed makes sense the way it is proposed.
Your commit messages just lack a clear explanation of what is going on
here, since it's not quite trivial for anyone but you.

Cheers,

Paul

> [1] https://patchwork.ozlabs.org/patch/1091534/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3.1 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 19:20 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 7:12 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 19:07 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 7:04 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 18:48 +0530, Jagan Teki wrote:
> > > > > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> > > > > which is U-Boot specific devicetrees binding.
> > > > > 
> > > > > Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> > > > > bindings will move it future based on the requirement.
> > > > > 
> > > > > This would help to sync the devicetrees from Linux whenever required
> > > > > instead of adding specific nodes.
> > > > > 
> > > > > Signed-off-by: Jagan Teki 
> > > > > Reviewed-by: Paul Kocialkowski 
> > > > 
> > > > Since your patch has changed significantly, you can no longer include a
> > > > Reviewed-by that was given on a previous iteration.
> > > > 
> > > > It looks like we are still missing bits to have rk3399-u-boot.dtsi
> > > > included, so this patch does not get my Reviewed-by tag.
> > > 
> > > It will include rockchip-u-boot.dtsi automatically and I made the
> > > receptive changes to include other files in this patch [1] and sure I
> > > will ask Philipp to remove the reviewed-by tag, thanks.
> > 
> > Most importantly (now that I see the new series), you should certainly
> > have sent that patch as part of your new series because we now have an
> > inter-dependency between both series.
> 
> It is not like an inter-dependency the previous rk3399-u-boot.dtsi is
> not included by these files so they would work as before. and now this
> series would need this change to include rk3399-u-boot.dtsi since the
> goal here to add binman node to common for all rk3399 dts files.

Well, what I mean is that the latest series you sent mentions a
dependency on the first one, when it really should be the other way
round: you need the rework to make things in your first series work at
all, since that dm-pre-reloc is necessary.

We don't want to merge one broken series and then the fix for it later,
even if it would still build in all cases. Here there is a clear
logical dependency, in the reverse ordre to the one you are describing.

In order to get this right, you need to take that v3.1 patch from the
first series and stick first in the new one. When that's done, I'll be
happy to move on to reviewing the code!

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3.1 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 19:07 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 7:04 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 18:48 +0530, Jagan Teki wrote:
> > > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> > > which is U-Boot specific devicetrees binding.
> > > 
> > > Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> > > bindings will move it future based on the requirement.
> > > 
> > > This would help to sync the devicetrees from Linux whenever required
> > > instead of adding specific nodes.
> > > 
> > > Signed-off-by: Jagan Teki 
> > > Reviewed-by: Paul Kocialkowski 
> > 
> > Since your patch has changed significantly, you can no longer include a
> > Reviewed-by that was given on a previous iteration.
> > 
> > It looks like we are still missing bits to have rk3399-u-boot.dtsi
> > included, so this patch does not get my Reviewed-by tag.
> 
> It will include rockchip-u-boot.dtsi automatically and I made the
> receptive changes to include other files in this patch [1] and sure I
> will ask Philipp to remove the reviewed-by tag, thanks.

Most importantly (now that I see the new series), you should certainly
have sent that patch as part of your new series because we now have an
inter-dependency between both series.

Could you clean that up and make a proper standalone series that
creates and populates rk3399-u-boot.dtsi?

Cheers,

Paul

> [1] https://patchwork.ozlabs.org/patch/1091543/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3.1 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 18:48 +0530, Jagan Teki wrote:
> u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> which is U-Boot specific devicetrees binding.
> 
> Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> bindings will move it future based on the requirement.
> 
> This would help to sync the devicetrees from Linux whenever required
> instead of adding specific nodes.
> 
> Signed-off-by: Jagan Teki 
> Reviewed-by: Paul Kocialkowski 

Since your patch has changed significantly, you can no longer include a
Reviewed-by that was given on a previous iteration.

It looks like we are still missing bits to have rk3399-u-boot.dtsi
included, so this patch does not get my Reviewed-by tag.

Cheers,

Paul

> ---
> Changes for v3.1:
> - exclude changes for other dts files, since they handle separately.
> 
>  arch/arm/dts/rk3399-u-boot.dtsi | 8 
>  1 file changed, 8 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> new file mode 100644
> index 00..f533ed95eb
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-26 at 18:51 +0530, Jagan Teki wrote:
> On Thu, Apr 25, 2019 at 11:04 PM Jagan Teki  
> wrote:
> > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> > which is U-Boot specific devicetrees binding.
> > 
> > Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> > bindings will move it future based on the requirement.
> > 
> > This would help to sync the devicetrees from Linux whenever required
> > instead of adding specific nodes.
> > 
> > Signed-off-by: Jagan Teki 
> > Reviewed-by: Paul Kocialkowski 
> > ---
> >  arch/arm/dts/rk3399-evb.dts | 1 -
> >  arch/arm/dts/rk3399-firefly.dts | 1 -
> >  arch/arm/dts/rk3399-puma.dtsi   | 1 -
> >  arch/arm/dts/rk3399-u-boot.dtsi | 8 
> >  4 files changed, 8 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
> > 
> > diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> > index ce004d0d18..9162f3dd50 100644
> > --- a/arch/arm/dts/rk3399-evb.dts
> > +++ b/arch/arm/dts/rk3399-evb.dts
> > @@ -155,7 +155,6 @@
> >  };
> > 
> >   {
> > -   u-boot,dm-pre-reloc;
> > bus-width = <4>;
> > status = "okay";
> >  };
> > diff --git a/arch/arm/dts/rk3399-firefly.dts 
> > b/arch/arm/dts/rk3399-firefly.dts
> > index f90e7e88db..46f2ffaf8d 100644
> > --- a/arch/arm/dts/rk3399-firefly.dts
> > +++ b/arch/arm/dts/rk3399-firefly.dts
> > @@ -592,7 +592,6 @@
> >  };
> > 
> >   {
> > -   u-boot,dm-pre-reloc;
> > bus-width = <4>;
> > status = "okay";
> >  };
> > diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> > index 8304f67192..9049694243 100644
> > --- a/arch/arm/dts/rk3399-puma.dtsi
> > +++ b/arch/arm/dts/rk3399-puma.dtsi
> > @@ -492,7 +492,6 @@
> >  };
> > 
> >   {
> > -   u-boot,dm-pre-reloc;
> 
> We need to explicitly include rk3399-u-boot.dtsi to these files since
> the SoC name is rockchip, I'm sending other series for these changes.
> and I have send v3.1 patches for only this change [1] and rest
> unchanged.

Does this mean that the rk3399-u-boot.dtsi file won't be auto-included
from the boards dtsi? If so, we should probably create -u-boot.dtsi
files for each device, to include rk3399-u-boot.dtsi.

Cheers,

Paul

> Sorry for not noticing before.
> 
> [1] https://patchwork.ozlabs.org/patch/1091534/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2 13/14] rockchip: rk3399: Add Rockpro64 board support

[Paul Kocialkowski]

Hi,

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> Add initial support for Rockpro64 board.
> 
> Specification
> - Rockchip RK3399
> - 2/4GB Dual-Channel LPDDR3
> - SD card slot
> - eMMC socket
> - 128Mb SPI Flash
> - Gigabit ethernet
> - PCIe 4X slot
> - WiFI/BT module socket
> - HDMI In/Out, DP, MIPI DSI/CSI, eDP
> - USB 3.0, 2.0
> - USB Type C power and data
> - GPIO expansion ports
> - DC 12V/2A
> 
> Commit details of rk3399-rockpro64.dts sync from Linux 5.1-rc2:
> "arm64: dts: rockchip: rockpro64 dts add usb regulator"
> (sha1: 6db644c79c8d45d73b56bc389aebd85fc3679beb)
> 
> 'Akash' has sent an initial patch before, so I keep him as board
> maintainer and I'm co-maintainer based on our conversation.

I think SPL support should be disabled for this one too.

Cheers,

Paul

> Cc: Paul Kocialkowski 
> Signed-off-by: Akash Gajjar 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3399-rockpro64-u-boot.dtsi |   6 +
>  arch/arm/dts/rk3399-rockpro64.dts | 712 ++
>  board/rockchip/evb_rk3399/MAINTAINERS |   7 +
>  configs/rockpro64-rk3399_defconfig|  58 ++
>  5 files changed, 784 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
>  create mode 100644 configs/rockpro64-rk3399_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index ede7da23fb..23a9807444 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -95,6 +95,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3399-puma-ddr1600.dtb \
>   rk3399-puma-ddr1866.dtb \
>   rk3399-rock960.dtb \
> + rk3399-rockpro64.dtb \
>   rv1108-elgin-r1.dtb \
>   rv1108-evb.dtb
>  dtb-$(CONFIG_ARCH_MESON) += \
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi 
> b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> new file mode 100644
> index 00..7bddc3acdb
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-rockpro64.dts 
> b/arch/arm/dts/rk3399-rockpro64.dts
> new file mode 100644
> index 00..1f2394e058
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-rockpro64.dts
> @@ -0,0 +1,712 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + * Copyright (c) 2018 Akash Gajjar 
> + */
> +
> +/dts-v1/;
> +#include 
> +#include 
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Pine64 RockPro64";
> + compatible = "pine64,rockpro64", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <>;
> +
> + power {
> + debounce-interval = <100>;
> + gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
> + label = "GPIO Key Power";
> + linux,code = ;
> + wakeup-source;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_led_gpio>, <_led_gpio>;
> +
> + work-led {
> + label = "work";
> + default-state = "on";
> + gpios = < RK_PB3 GPIO_ACTIVE_HIGH>;
> + };
> +
> + diy-led {
> + label = "diy";
> + default-state = "off";
> + gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = < 1>;
> + clock-names = "ext_clock";
> + pinctrl-names = &quo

Re: [U-Boot] [PATCH v2 12/14] rockchip: rk3399: Add Nanopi NEO4 board support

[Paul Kocialkowski]

G_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SPL_STACK_R_ADDR=0x8
> +CONFIG_DEBUG_UART=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-neo4.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-neo4"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_ERRNO_STR=y
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2 07/14] rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux

[Paul Kocialkowski]

Hi,

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> Sync rk3399-nanopi4.dtsi from Linux 5.1-rc2 tag.
> 
> Linux commit details about the rk3399-nanopi4.dtsi sync:
> "arm64: dts: rockchip: Add nanopi4 bluetooth"
> (sha1: 3e2f0bb72be36aa6c14ee7f11ac4dd8014801030)
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  arch/arm/dts/rk3399-nanopi4.dtsi | 703 +++
>  1 file changed, 703 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi
> 
> diff --git a/arch/arm/dts/rk3399-nanopi4.dtsi 
> b/arch/arm/dts/rk3399-nanopi4.dtsi
> new file mode 100644
> index 00..d325e11728
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-nanopi4.dtsi
> @@ -0,0 +1,703 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * RK3399-based FriendlyElec boards device tree source
> + *
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + * Copyright (c) 2019 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +#include 
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc3v3_sys";
> + };
> +
> + vcc5v0_sys: vcc5v0-sys {
> + compatible = "regulator-fixed";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-name = "vcc5v0_sys";
> + vin-supply = <_5v>;
> + };
> +
> + /* switched by pmic_sleep */
> + vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> + compatible = "regulator-fixed";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-name = "vcc1v8_s3";
> + vin-supply = <_1v8>;
> + };
> +
> + vcc3v0_sd: vcc3v0-sd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < RK_PA1 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pwr_h>;
> + regulator-always-on;
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + regulator-name = "vcc3v0_sd";
> + vin-supply = <_sys>;
> + };
> +
> + vbus_typec: vbus-typec {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-name = "vbus_typec";
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <_key>;
> +
> + power {
> + debounce-interval = <100>;
> + gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
> + label = "GPIO Key Power";
> + linux,code = ;
> + wakeup-source;
> + };
> + };
> +
> + leds: gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio>;
> +
> + status {
> + gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
> + label = "status_led";
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {

Re: [U-Boot] [PATCH v2 11/14] rockchip: rk3399: Add Nanopc T4 board support

[Paul Kocialkowski]

t; + phy-supply = <_host0>;
> +};
> +
> +_host {
> + phy-supply = <_host0>;
> +};
> +
> +_sys {
> + vin-supply = <_sys>;
> +};
> +
> +_sys {
> + vin-supply = <_sys>;
> +};
> +
> +_typec {
> + enable-active-high;
> + gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
> + vin-supply = <_sys>;
> +};
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS 
> b/board/rockchip/evb_rk3399/MAINTAINERS
> index ae43805a6a..5917abb9c1 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -6,6 +6,12 @@ F:  include/configs/evb_rk3399.h
>  F:  configs/evb-rk3399_defconfig
>  F:  configs/firefly-rk3399_defconfig
>  
> +NANOPC-T4
> +M:   Jagan Teki 
> +S:   Maintained
> +F:   configs/nanopic-t4-rk3399_defconfig
> +F:   arch/arm/dts/rk3399-nanopic-t4-u-boot.dtsi
> +
>  NANOPI-M4
>  M:   Jagan Teki 
>  S:   Maintained
> diff --git a/configs/nanopc-t4-rk3399_defconfig 
> b/configs/nanopc-t4-rk3399_defconfig
> new file mode 100644
> index 00..7ba4f85485
> --- /dev/null
> +++ b/configs/nanopc-t4-rk3399_defconfig
> @@ -0,0 +1,58 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SPL_STACK_R_ADDR=0x8
> +CONFIG_DEBUG_UART=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopc-t4.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopc-t4"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_ERRNO_STR=y
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2 10/14] rockchip: rk3399: Add Nanopi M4 board support

[Paul Kocialkowski]

Hi,

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> Add initial support for Nanopi M4 board.
> 
> Specification
> - Rockchip RK3399
> - Dual-Channel 4GB LPDDR3-1866
> - SD card slot
> - eMMC socket
> - RTL8211E 1Gbps
> - AP6356S WiFI/BT
> - HDMI In/Out, DP, MIPI DSI/CSI
> - USB 3.0 x4
> - USB Type C power and data
> - GPIO1, GPIO2 expansion ports
> - DC5V/3A
> 
> Commit details of rk3399-nanopi-m4.dts sync from Linux 5.1-rc2:
> "arm64: dts: rockchip: Refine nanopi4 differences"
> (sha1: c62ffaf5026d0b7633e62b2cea8450b5543c349a)
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  arch/arm/dts/Makefile |  1 +
>  arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi |  7 +++
>  arch/arm/dts/rk3399-nanopi-m4.dts | 66 +++
>  board/rockchip/evb_rk3399/MAINTAINERS |  6 +++
>  configs/nanopi-m4-rk3399_defconfig| 58 
>  5 files changed, 138 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts
>  create mode 100644 configs/nanopi-m4-rk3399_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 6d55b0caf8..d2ac26b556 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3399-evb.dtb \
>   rk3399-firefly.dtb \
>   rk3399-gru-bob.dtb \
> + rk3399-nanopi-m4.dtb \
>   rk3399-orangepi.dtb \
>   rk3399-puma-ddr1333.dtb \
>   rk3399-puma-ddr1600.dtb \
> diff --git a/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi 
> b/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
> new file mode 100644
> index 00..1173d496ec
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr3-4GB-1866.dtsi"
> diff --git a/arch/arm/dts/rk3399-nanopi-m4.dts 
> b/arch/arm/dts/rk3399-nanopi-m4.dts
> new file mode 100644
> index 00..60358ab8c7
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-nanopi-m4.dts
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * FriendlyElec NanoPi M4 board device tree source
> + *
> + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + * Copyright (c) 2019 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +#include "rk3399-nanopi4.dtsi"
> +
> +/ {
> + model = "FriendlyElec NanoPi M4";
> + compatible = "friendlyarm,nanopi-m4", "rockchip,rk3399";
> +
> + vdd_5v: vdd-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_5v";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc5v0_core: vcc5v0-core {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_core";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_5v>;
> + };
> +
> + vcc5v0_usb1: vcc5v0-usb1 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb1";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_sys>;
> + };
> +
> + vcc5v0_usb2: vcc5v0-usb2 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb2";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_sys>;
> + };
> +};
> +
> +_sys {
> + vin-supply = <_core>;
> +};
> +
> +_host {
> + phy-supply = <_usb1>;
> +};
> +
> +_host {
> + phy-supply = <_usb2>;
> +};
> +
> +_typec {
> + regulator-always-on;
> + vin-supply = <_5v>;
> +};
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS 
> b/board/rockchip/evb_rk3399/MAINTAINERS
> index 07ee8ce92c..ae43805a6a 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -6,6 +6,12 @@ F:  include/configs/evb_rk3399.h
>  F:  configs/evb-rk3399_defconfig
>  F:  configs/firefly-rk3399_defconfig
>  
> +NANOPI-M4
> +M:   Jagan Teki 
> +S:   Maintained
> +F:   configs/nanopi-m4-rk3399_defconfig

Re: [U-Boot] [PATCH v2 06/14] rockchip: rk3399: Add Orangepi RK3399 support

[Paul Kocialkowski]

Hi,

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> Add initial support for Orangepi RK3399 board.
> 
> Specification
> - Rockchip RK3399
> - 2GB/4GB DDR3
> - 16GB eMMC
> - SD card slot
> - RTL8211E 1Gbps
> - AP6356S WiFI/BT
> - HDMI In/Out, DP, MIPI DSI/CSI
> - Mini PCIe
> - Sensors, Keys etc
> - DC12V-2A and DC5V-2A
> 
> Commit details about Linux DTS sync:
> "arm64: dts: rockchip: Add support for the Orange Pi RK3399"
> (sha1: d3e71487a790979057c0fdbf32f85033639c16e6)
> 
> Signed-off-by: Jagan Teki 

I think it would be good to have DRAM configuration eventually exposed
to Linux for advanced power management. But that's a separare issue.

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/rk3399-orangepi-u-boot.dtsi |   7 +
>  arch/arm/dts/rk3399-orangepi.dts | 771 +++
>  board/rockchip/evb_rk3399/MAINTAINERS|   7 +
>  configs/orangepi-rk3399_defconfig|  58 ++
>  5 files changed, 844 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-orangepi.dts
>  create mode 100644 configs/orangepi-rk3399_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0e2ffdb87f..6d55b0caf8 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3399-evb.dtb \
>   rk3399-firefly.dtb \
>   rk3399-gru-bob.dtb \
> + rk3399-orangepi.dtb \
>   rk3399-puma-ddr1333.dtb \
>   rk3399-puma-ddr1600.dtb \
>   rk3399-puma-ddr1866.dtb \
> diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi 
> b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> new file mode 100644
> index 00..236b61d78d
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-ddr3-1333.dtsi"
> diff --git a/arch/arm/dts/rk3399-orangepi.dts 
> b/arch/arm/dts/rk3399-orangepi.dts
> new file mode 100644
> index 00..cf37b96a6b
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi.dts
> @@ -0,0 +1,771 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "dt-bindings/pwm/pwm.h"
> +#include "dt-bindings/input/input.h"
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Orange Pi RK3399 Board";
> + compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = < 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <180>;
> + poll-interval = <100>;
> +
> + button-up {
> + label = "Volume Up";
> + linux,code = ;
> + press-threshold-microvolt = <10>;
> + };
> +
> + button-down {
> + label = "Volume Down";
> + linux,code = ;
> + press-threshold-microvolt = <30>;
> + };
> +
> + back {
> + label = "Back";
> + linux,code = ;
> + press-threshold-microvolt = <985000>;
> + };
> +
> + menu {
> + label = "Menu";
> + linux,code = ;
> + press-threshold-microvolt = <1314000>;
> + };
> + };
> +
> + dc_12v: dc-12v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + };
> +
>

Re: [U-Boot] [PATCH v2 05/14] arm: rockchip: rk3399: Move common configs in Kconfig

[Paul Kocialkowski]

Hi,

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> Few SPL and U-Boot proper configs are common to all rk3399 target
> defconfigs, move them and select it from platform kconfig.
> 
> Moved configs:
> -  SPL_ATF
> -  SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
> -  SPL_LOAD_FIT
> -  SPL_CLK if SPL
> -  SPL_PINCTRL if SPL
> -  SPL_RAM if SPL
> -  SPL_REGMAP if SPL
> -  SPL_SYSCON if SPL
> -  CLK
> -  FIT
> -  PINCTRL
> -  RAM
> -  REGMAP
> -  SYSCON
> -  DM_PMIC
> -  DM_REGULATOR_FIXED
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  arch/arm/mach-rockchip/Kconfig   | 16 
>  configs/chromebook_bob_defconfig | 16 
>  configs/evb-rk3399_defconfig | 16 
>  configs/ficus-rk3399_defconfig   | 16 
>  configs/firefly-rk3399_defconfig | 16 
>  configs/puma-rk3399_defconfig| 16 
>  configs/rock960-rk3399_defconfig | 16 
>  7 files changed, 16 insertions(+), 96 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index b9a026abb5..dbe7f11d39 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -132,9 +132,25 @@ config ROCKCHIP_RK3399
>   select ARM64
>   select SUPPORT_SPL
>   select SPL
> + select SPL_ATF
> + select SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
> + select SPL_LOAD_FIT
> + select SPL_CLK if SPL
> + select SPL_PINCTRL if SPL
> + select SPL_RAM if SPL
> + select SPL_REGMAP if SPL
> + select SPL_SYSCON if SPL
>   select SPL_SEPARATE_BSS
>   select SPL_SERIAL_SUPPORT
>   select SPL_DRIVERS_MISC_SUPPORT
> + select CLK
> + select FIT
> + select PINCTRL
> + select RAM
> + select REGMAP
> + select SYSCON
> + select DM_PMIC
> + select DM_REGULATOR_FIXED
>   select DEBUG_UART_BOARD_INIT
>   select BOARD_LATE_INIT
>   select ROCKCHIP_BROM_HELPER
> diff --git a/configs/chromebook_bob_defconfig 
> b/configs/chromebook_bob_defconfig
> index 04e25e1d4f..fdcbabf912 100644
> --- a/configs/chromebook_bob_defconfig
> +++ b/configs/chromebook_bob_defconfig
> @@ -17,16 +17,12 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI_SUPPORT=y
>  CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
> -CONFIG_FIT=y
> -CONFIG_SPL_LOAD_FIT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
>  CONFIG_SPL_SPI_LOAD=y
> -CONFIG_SPL_ATF=y
> -CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
>  CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_GPT=y
> @@ -45,12 +41,6 @@ CONFIG_SPL_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-bob"
>  CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
>  CONFIG_ENV_IS_IN_MMC=y
> -CONFIG_REGMAP=y
> -CONFIG_SPL_REGMAP=y
> -CONFIG_SYSCON=y
> -CONFIG_SPL_SYSCON=y
> -CONFIG_CLK=y
> -CONFIG_SPL_CLK=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_I2C_CROS_EC_TUNNEL=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
> @@ -70,16 +60,10 @@ CONFIG_SPI_FLASH_GIGADEVICE=y
>  CONFIG_DM_ETH=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_GMAC_ROCKCHIP=y
> -CONFIG_PINCTRL=y
> -CONFIG_SPL_PINCTRL=y
> -CONFIG_DM_PMIC=y
>  CONFIG_PMIC_RK8XX=y
>  CONFIG_REGULATOR_PWM=y
> -CONFIG_DM_REGULATOR_FIXED=y
>  CONFIG_REGULATOR_RK8XX=y
>  CONFIG_PWM_ROCKCHIP=y
> -CONFIG_RAM=y
> -CONFIG_SPL_RAM=y
>  CONFIG_DEBUG_UART_SHIFT=2
>  CONFIG_ROCKCHIP_SPI=y
>  CONFIG_SYSRESET=y
> diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
> index 49b2e2e089..1ba9dcba62 100644
> --- a/configs/evb-rk3399_defconfig
> +++ b/configs/evb-rk3399_defconfig
> @@ -11,15 +11,11 @@ CONFIG_DEBUG_UART_CLOCK=2400
>  CONFIG_SPL_STACK_R_ADDR=0x8
>  CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
> -CONFIG_FIT=y
> -CONFIG_SPL_LOAD_FIT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> -CONFIG_SPL_ATF=y
> -CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
>  CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPT=y
>  CONFIG_CMD_MMC=y
> @@ -32,12 +28,6 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
>  CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-pare

Re: [U-Boot] [PATCH v2 04/14] Kconfig: Add default SPL_FIT_GENERATOR for rockchip

[Paul Kocialkowski]

Hi,

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> Add default SPL_FIT_GENERATOR py script for rockchip platforms if
> specific target enabled SPL_LOAD_FIT.
> 
> So, this would help get rid of explicitly mentioning the default
> SPL FIT generator in defconfigs. however some targets, like puma_rk3399
> still require their own FIT generator so in those cases the default will
> override with defconfig defined generator.
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  Kconfig  | 1 +
>  configs/chromebook_bob_defconfig | 1 -
>  configs/evb-rk3399_defconfig | 1 -
>  configs/ficus-rk3399_defconfig   | 1 -
>  configs/firefly-rk3399_defconfig | 1 -
>  configs/rock960-rk3399_defconfig | 1 -
>  6 files changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/Kconfig b/Kconfig
> index 305b265ed7..5679a288ec 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -424,6 +424,7 @@ config SPL_FIT_GENERATOR
>   string ".its file generator script for U-Boot FIT image"
>   depends on SPL_FIT
>   default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
> + default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && 
> ARCH_ROCKCHIP
>   help
> Specifies a (platform specific) script file to generate the FIT
> source file used to build the U-Boot FIT image file. This gets
> diff --git a/configs/chromebook_bob_defconfig 
> b/configs/chromebook_bob_defconfig
> index ce3deccb8a..04e25e1d4f 100644
> --- a/configs/chromebook_bob_defconfig
> +++ b/configs/chromebook_bob_defconfig
> @@ -19,7 +19,6 @@ CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
> index d98535357a..49b2e2e089 100644
> --- a/configs/evb-rk3399_defconfig
> +++ b/configs/evb-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
> index 94c565efc2..fe3b9964e8 100644
> --- a/configs/ficus-rk3399_defconfig
> +++ b/configs/ficus-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x8
>  CONFIG_DEBUG_UART=y
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_SPL_STACK_R=y
> diff --git a/configs/firefly-rk3399_defconfig 
> b/configs/firefly-rk3399_defconfig
> index 6725b48970..914304bb43 100644
> --- a/configs/firefly-rk3399_defconfig
> +++ b/configs/firefly-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> diff --git a/configs/rock960-rk3399_defconfig 
> b/configs/rock960-rk3399_defconfig
> index cb5a35f4f5..5e6778ea20 100644
> --- a/configs/rock960-rk3399_defconfig
> +++ b/configs/rock960-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x8
>  CONFIG_DEBUG_UART=y
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2 03/14] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Paul Kocialkowski]

Hi,

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> which is U-Boot specific devicetrees binding.
> 
> Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> bindings will move it future based on the requirement.
> 
> This would help to sync the devicetrees from Linux whenever required
> instead of adding specific nodes.
> 
> Signed-off-by: Jagan Teki 


Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  arch/arm/dts/rk3399-evb.dts | 1 -
>  arch/arm/dts/rk3399-firefly.dts | 1 -
>  arch/arm/dts/rk3399-puma.dtsi   | 1 -
>  arch/arm/dts/rk3399-u-boot.dtsi | 8 
>  4 files changed, 8 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> index ce004d0d18..9162f3dd50 100644
> --- a/arch/arm/dts/rk3399-evb.dts
> +++ b/arch/arm/dts/rk3399-evb.dts
> @@ -155,7 +155,6 @@
>  };
>  
>   {
> - u-boot,dm-pre-reloc;
>   bus-width = <4>;
>   status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> index f90e7e88db..46f2ffaf8d 100644
> --- a/arch/arm/dts/rk3399-firefly.dts
> +++ b/arch/arm/dts/rk3399-firefly.dts
> @@ -592,7 +592,6 @@
>  };
>  
>   {
> - u-boot,dm-pre-reloc;
>   bus-width = <4>;
>   status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> index 8304f67192..9049694243 100644
> --- a/arch/arm/dts/rk3399-puma.dtsi
> +++ b/arch/arm/dts/rk3399-puma.dtsi
> @@ -492,7 +492,6 @@
>  };
>  
>   {
> - u-boot,dm-pre-reloc;
>   clock-frequency = <15000>;
>   max-frequency = <4000>;
>   supports-sd;
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> new file mode 100644
> index 00..f533ed95eb
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki 
> + */
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2 02/14] rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2

[Paul Kocialkowski]

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> To make successful build with dts(i) files syncing from Linux 5.1-rc2
> the rk3399.dtsi would require pwm2_pin_pull_down.
> 
> So, sync the pwm2_pin_pull_down node from Linux 5.1-rc2.  Since this
> node is strictly not part of any commit alone, I have mentioned
> Linux 5.1-rc2 tag for future reference of where would this sync
> coming from.
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  arch/arm/dts/rk3399.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
> index b53e41b4dc..99471f6287 100644
> --- a/arch/arm/dts/rk3399.dtsi
> +++ b/arch/arm/dts/rk3399.dtsi
> @@ -2495,6 +2495,12 @@
>   rockchip,pins =
>   <1 RK_PC3 RK_FUNC_1 _pull_none>;
>   };
> +
> +
> + pwm2_pin_pull_down: pwm2-pin-pull-down {
> + rockchip,pins =
> + <1 RK_PC3 RK_FUNC_1 _pull_down>;
> + };
>   };
>  
>   pwm3a {
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2 01/14] rockchip: dts: rk3399: Sync rk3399-opp from Linux

[Paul Kocialkowski]

Le mardi 16 avril 2019 à 16:26 +0530, Jagan Teki a écrit :
> Sync rk3399-opp.dtsi from Linux.
> 
> Linux commit details about the rk3399-opp.dtsi sync:
> "arm64: dts: rockchip: use SPDX-License-Identifier"
> (sha1: 4ee99cebd486238ac433da823b95cc5f8d8a6905)
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  arch/arm/dts/rk3399-opp.dtsi | 133 +++
>  1 file changed, 133 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-opp.dtsi
> 
> diff --git a/arch/arm/dts/rk3399-opp.dtsi b/arch/arm/dts/rk3399-opp.dtsi
> new file mode 100644
> index 00..d6f1095abb
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-opp.dtsi
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd
> + */
> +
> +/ {
> + cluster0_opp: opp-table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <40800>;
> + opp-microvolt = <80>;
> + clock-latency-ns = <4>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <81600>;
> + opp-microvolt = <85>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <100800>;
> + opp-microvolt = <925000>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <12>;
> + opp-microvolt = <100>;
> + };
> + opp05 {
> + opp-hz = /bits/ 64 <141600>;
> + opp-microvolt = <1125000>;
> + };
> + };
> +
> + cluster1_opp: opp-table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <40800>;
> + opp-microvolt = <80>;
> + clock-latency-ns = <4>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <81600>;
> + opp-microvolt = <825000>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <100800>;
> + opp-microvolt = <875000>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <12>;
> + opp-microvolt = <95>;
> + };
> + opp05 {
> + opp-hz = /bits/ 64 <141600>;
> + opp-microvolt = <1025000>;
> + };
> + opp06 {
> + opp-hz = /bits/ 64 <160800>;
> + opp-microvolt = <110>;
> + };
> + opp07 {
> + opp-hz = /bits/ 64 <18>;
> + opp-microvolt = <120>;
> + };
> + };
> +
> + gpu_opp_table: opp-table2 {
> + compatible = "operating-points-v2";
> +
> + opp00 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <29700>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <825000>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <5>;
> + opp-microvolt = <875000>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <925000>;
> + };
> + opp05 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <110>;
> + };
> + };
> +};
> +
> +_l0 {
> + operating-points-v2 = <_opp>;
> +};
> +
> +_l1 {
> + operating-points-v2 = <_opp>;
> +};
> +
> +_l2 {
> + operating-points-v2 = <_opp>;
> +};
> +
> +_l3 {
> + operating-points-v2 = <_opp>;
> +};
> +
> +_b0 {
> + operating-points-v2 = <_opp>;
> +};
> +
> +_b1 {
> + operating-points-v2 = <_opp>;
> +};
> +
> + {
> + operating-points-v2 = <_opp_table>;
> +};
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH v2 00/14] rockchip: Add new rk3399 boards

[Paul Kocialkowski]

4656 insertions(+), 105 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopc-t4.dts
>  create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts
>  create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts
>  create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi
>  create mode 100644 arch/arm/dts/rk3399-opp.dtsi
>  create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-orangepi.dts
>  create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
>  create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-4GB-1866.dtsi
>  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
>  create mode 100644 configs/nanopc-t4-rk3399_defconfig
>  create mode 100644 configs/nanopi-m4-rk3399_defconfig
>  create mode 100644 configs/nanopi-neo4-rk3399_defconfig
>  create mode 100644 configs/orangepi-rk3399_defconfig
>  create mode 100644 configs/rockpro64-rk3399_defconfig
> 
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [linux-sunxi] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB

[Paul Kocialkowski]

Hi,

Le vendredi 12 avril 2019 à 14:49 +0530, Jagan Teki a écrit :
> On Thu, Mar 14, 2019 at 4:08 PM Paul Kocialkowski
>  wrote:
> > Recent Allwinner platforms (starting with the H3) only use the MUSB
> > controller for peripheral mode and use HCI for host mode. As a result,
> > extra steps need to be taken to properly route USB signals to one or
> > the other. More precisely, the following is required:
> > * Routing the pins to either HCI/MUSB (controlled by PHY);
> > * Enabling USB PHY passby in HCI mode (controlled by PMU).
> > 
> > The current code will enable passby for each PHY and reroute PHY0 to
> > MUSB, which is inconsistent and results in broken USB peripheral support.
> > 
> > Passby on PHY0 must only be enabled when we want to use HCI. Since
> > host/device mode detection is not available from the PHY code and
> > because U-Boot does not support changing the mode dynamically anyway,
> > we can just mux the controller to MUSB if it is enabled and mux it to
> > HCI otherwise.
> > 
> > This fixes USB peripheral support for platforms with PHY0 dual-route,
> > especially H3/H5 and V3s.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> > b/drivers/phy/allwinner/phy-sun4i-usb.c
> > index f206fa3f5d48..4f1c7e519d71 100644
> > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy)
> > data->cfg->disc_thresh, 
> > PHY_DISCON_TH_LEN);
> > }
> > 
> > +#ifdef CONFIG_USB_MUSB_SUNXI
> > +   /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */
> > +   if (usb_phy->id != 0)
> > +   sun4i_usb_phy_passby(phy, true);
> > +
> > +   /* Route PHY0 to MUSB to allow USB gadget */
> > +   if (data->cfg->phy0_dual_route)
> > +   sun4i_usb_phy0_reroute(data, true);
> > +#else
> > sun4i_usb_phy_passby(phy, true);
> > 
> > -   sun4i_usb_phy0_reroute(data, true);
> > +   /* Route PHY0 to HCI to allow USB host */
> > +   if (data->cfg->phy0_dual_route)
> > +   sun4i_usb_phy0_reroute(data, false);
> > +#endif
> 
> I think we can manage this route and passby dynamically by detecting
> id since we have dr_mode verify the MUSB host or peripheral via
> usb_get_dr_mode, any chance to try that way?

Oh, I didn't know that U-Boot has support for usb_get_dr_mode these
days. Thanks!

So far, the sunxi port has been using Kconfig to distinguish between
host/device (unless I'm mistaken?) so I feel like this should be a
separate follow-up patch to convert the sunxi MUSB glue + PHY to
detecting dr_mode using usb_get_dr_mode. This feels like a significant
rework, too.

Also, how should we handle the OTG case? I'm not sure we can support
having both musb host and gadget built-in at this point. But that would
certainly be welcome as part of the rework, too.

What do you think?

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [linux-sunxi] [PATCH] arm: sunxi: Add support for the RerVision H3-DVK board

[Paul Kocialkowski]

Hi,

Le mardi 09 avril 2019 à 15:56 +0530, Jagan Teki a écrit :
> On Thu, Mar 14, 2019 at 4:10 PM Paul Kocialkowski
>  wrote:
> > This is an H3-based board that sticks close to the reference design.
> > 
> > Supported features:
> > * UART
> > * DRAM
> > * MMC
> > * eMMC
> > * Ethernet
> > * USB host
> > * USB peripheral
> > * HDMI
> 
> Can you add commit details of dts file from Linux sync, I usually
> prefer this for future reference syncs.

Sure thing, I'll make a new version with the associated linux commit
listed.

Cheers,

Paul

> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  arch/arm/dts/Makefile   |   3 +-
> >  arch/arm/dts/sun8i-h3-rervision-dvk.dts | 107 
> >  configs/rervision_h3_dvk_defconfig  |  17 
> >  3 files changed, 126 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
> >  create mode 100644 configs/rervision_h3_dvk_defconfig
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 2a040b20a539..a64c0fada4cb 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -401,7 +401,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
> > sun8i-h3-orangepi-pc.dtb \
> > sun8i-h3-orangepi-pc-plus.dtb \
> > sun8i-h3-orangepi-plus.dtb \
> > -   sun8i-h3-orangepi-plus2e.dtb
> > +   sun8i-h3-orangepi-plus2e.dtb \
> > +   sun8i-h3-rervision-dvk.dtb
> >  dtb-$(CONFIG_MACH_SUN8I_R40) += \
> > sun8i-r40-bananapi-m2-ultra.dtb \
> > sun8i-v40-bananapi-m2-berry.dtb
> > diff --git a/arch/arm/dts/sun8i-h3-rervision-dvk.dts 
> > b/arch/arm/dts/sun8i-h3-rervision-dvk.dts
> > new file mode 100644
> > index 0000..8a4b83a02d9d
> > --- /dev/null
> > +++ b/arch/arm/dts/sun8i-h3-rervision-dvk.dts
> > @@ -0,0 +1,107 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (C) 2019 Bootlin
> > + * Author: Paul Kocialkowski 
> > + */
> > +
> > +/dts-v1/;
> > +#include "sun8i-h3.dtsi"
> > +#include "sunxi-common-regulators.dtsi"
> > +
> > +#include 
> > +#include 
> > +
> > +/ {
> > +   model = "RerVision H3-DVK";
> > +   compatible = "rervision,h3-dvk", "allwinner,sun8i-h3";
> > +
> > +   aliases {
> > +   ethernet0 = 
> > +   serial0 = 
> > +   };
> > +
> > +   chosen {
> > +   stdout-path = "serial0:115200n8";
> > +   };
> > +
> > +   connector {
> > +   compatible = "hdmi-connector";
> > +   type = "a";
> > +
> > +   port {
> > +   hdmi_connector_input: endpoint {
> > +   remote-endpoint = <_connector_output>;
> > +   };
> > +   };
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   phy-handle = <_mii_phy>;
> > +   phy-mode = "mii";
> > +   allwinner,leds-active-low;
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > +_out {
> > +   hdmi_connector_output: endpoint {
> > +   remote-endpoint = <_connector_input>;
> > +   };
> > +};
> > +
> > + {
> > +   bus-width = <4>;
> > +   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > +   status = "okay";
> > +   vmmc-supply = <_vcc3v3>;
> > +};
> > +
> > + {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_8bit_pins>;
> > +   vmmc-supply = <_vcc3v3>;
> > +   bus-width = <8>;
> > +   non-removable;
> > +   cap-mmc-hw-reset;
> > +   status = "okay";
> > +};
> > +
> > +_8bit_pins {
> > +   drive-strength = <40>;
> > +   bias-pull-up;
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   pinctrl-names = "default";
> > +   p

Re: [U-Boot] arm: sunxi: Bananapi_M2_Ultra not working with DM_MMC

[Paul Kocialkowski]

Hi,

Le lundi 08 avril 2019 à 19:47 +0530, Jagan Teki a écrit :
> On Mon, Apr 8, 2019 at 7:31 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le lundi 08 avril 2019 à 19:21 +0530, Jagan Teki a écrit :
> > > On Mon, Apr 8, 2019 at 7:06 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > Le lundi 08 avril 2019 à 19:03 +0530, Jagan Teki a écrit :
> > > > > On Mon, Apr 8, 2019 at 6:40 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Le lundi 08 avril 2019 à 18:23 +0530, Jagan Teki a écrit :
> > > > > > > Hi Paul,
> > > > > > > 
> > > > > > > On Mon, Apr 8, 2019 at 6:00 PM Paul Kocialkowski
> > > > > > >  wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Thu, 2019-04-04 at 05:51 -0300, Pablo Sebastián Greco wrote:
> > > > > > > > > A few days ago I tried to boot my Bananapi_M2_Ultra with 
> > > > > > > > > 2019.04rc, I
> > > > > > > > > found that it wasn't booting, 2019.01 was working ok.
> > > > > > > > > Bisecting indicated that the problem was after
> > > > > > > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a7cca5793774ee139b75a704d6efaa4d29f09f93
> > > > > > > > 
> > > > > > > > I think the patch should be reverted ASAP since it obviously 
> > > > > > > > breaks
> > > > > > > > some supported configs. Sadly, the offending commit doesn't say
> > > > > > > > anything about the test coverage for the change and what the 
> > > > > > > > status is
> > > > > > > > after it. There is probably a reason why it was enabled for 
> > > > > > > > sun4i only
> > > > > > > > before and there must have been a motivation for doing this on 
> > > > > > > > all
> > > > > > > > sunxi platforms, but then again, the commit message says 
> > > > > > > > nothing about
> > > > > > > > those underlying reasons.
> > > > > > > > 
> > > > > > > > I believe we should be more strict on patch review and not let 
> > > > > > > > any
> > > > > > > > change bringing such a major change get applied with a commit 
> > > > > > > > message
> > > > > > > > that provides no context about why the change is okay and how 
> > > > > > > > it was
> > > > > > > > tested.
> > > > > > > 
> > > > > > > Appropriate your concern.
> > > > > > > 
> > > > > > > If you please list what all boards are not working with this 
> > > > > > > effect,
> > > > > > > please write back. we will defiantly look into it. All these 
> > > > > > > changes
> > > > > > > were merged in MW which is 2.5 months back, commenting in final 
> > > > > > > stage
> > > > > > > like this is not the professional way.
> > > > > > 
> > > > > > I really do not think this is a sane approach to follow. You can't 
> > > > > > make
> > > > > > a change like this, with no context whatsoever in the commit 
> > > > > > message,
> > > > > > which ends up breaking other people's setups and wait for others to
> > > > > > debug subsequent issues it introduces that you don't encounter.
> > > > > > 
> > > > > > Sorry but your commit should never have been merged. Sure, I wasn't
> > > > > > there to review it either, but the code review process definitely 
> > > > > > did
> > > > > > not go as planned here.
> > > > > 
> > > > > Which commit message your referring to? are you referring this
> > > > > patch[1] commit message. let me point what exactly is the issue?
> > > > > 
> > > > > [1] 
> > > > > http://git.denx.de/?p=u-boot.git;a=commit;h=a7cca5793774ee139b75a704d6efaa4d29f09f93
> > > > 
> > > > Yes, this is the patch I'm talking about.
> > > > 
> > &g

Re: [U-Boot] arm: sunxi: Bananapi_M2_Ultra not working with DM_MMC

[Paul Kocialkowski]

Hi,

Le lundi 08 avril 2019 à 19:21 +0530, Jagan Teki a écrit :
> On Mon, Apr 8, 2019 at 7:06 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le lundi 08 avril 2019 à 19:03 +0530, Jagan Teki a écrit :
> > > On Mon, Apr 8, 2019 at 6:40 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > Le lundi 08 avril 2019 à 18:23 +0530, Jagan Teki a écrit :
> > > > > Hi Paul,
> > > > > 
> > > > > On Mon, Apr 8, 2019 at 6:00 PM Paul Kocialkowski
> > > > >  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Thu, 2019-04-04 at 05:51 -0300, Pablo Sebastián Greco wrote:
> > > > > > > A few days ago I tried to boot my Bananapi_M2_Ultra with 
> > > > > > > 2019.04rc, I
> > > > > > > found that it wasn't booting, 2019.01 was working ok.
> > > > > > > Bisecting indicated that the problem was after
> > > > > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a7cca5793774ee139b75a704d6efaa4d29f09f93
> > > > > > 
> > > > > > I think the patch should be reverted ASAP since it obviously breaks
> > > > > > some supported configs. Sadly, the offending commit doesn't say
> > > > > > anything about the test coverage for the change and what the status 
> > > > > > is
> > > > > > after it. There is probably a reason why it was enabled for sun4i 
> > > > > > only
> > > > > > before and there must have been a motivation for doing this on all
> > > > > > sunxi platforms, but then again, the commit message says nothing 
> > > > > > about
> > > > > > those underlying reasons.
> > > > > > 
> > > > > > I believe we should be more strict on patch review and not let any
> > > > > > change bringing such a major change get applied with a commit 
> > > > > > message
> > > > > > that provides no context about why the change is okay and how it was
> > > > > > tested.
> > > > > 
> > > > > Appropriate your concern.
> > > > > 
> > > > > If you please list what all boards are not working with this effect,
> > > > > please write back. we will defiantly look into it. All these changes
> > > > > were merged in MW which is 2.5 months back, commenting in final stage
> > > > > like this is not the professional way.
> > > > 
> > > > I really do not think this is a sane approach to follow. You can't make
> > > > a change like this, with no context whatsoever in the commit message,
> > > > which ends up breaking other people's setups and wait for others to
> > > > debug subsequent issues it introduces that you don't encounter.
> > > > 
> > > > Sorry but your commit should never have been merged. Sure, I wasn't
> > > > there to review it either, but the code review process definitely did
> > > > not go as planned here.
> > > 
> > > Which commit message your referring to? are you referring this
> > > patch[1] commit message. let me point what exactly is the issue?
> > > 
> > > [1] 
> > > http://git.denx.de/?p=u-boot.git;a=commit;h=a7cca5793774ee139b75a704d6efaa4d29f09f93
> > 
> > Yes, this is the patch I'm talking about.
> > 
> > The issue with it is that the commit message is totally redundant: the
> > description does not say more than what the diff does.
> > 
> > A git commit description should provide context about what the change
> > does above the modified lines: what problem it tries to resolve and how
> > , on what hardware, how it was tested, etc. Especially for a commit
> > making such a big change, the commit message must have all this
> > information.
> > 
> > Do you see why I think it's a problem?
> 
> I can't agree if we consider the series of changes in one set. As I
> mentioned in another mail, this patch is last from the DM_MMC
> migration series and as the last one it enable the DM_MMC global to
> Allwinner (not respective to board). The previous patches are trying
> to support and fix DM_MMC on respective SoC's and board. ie the reason
> I didn't mention any thing related to board or any other information
> since It is global SoC change.

I don't think this is relevant. You can't expect people to go through
the list archive, find which series this commit was attached to,
etc. Especially when running a bisect, where you'll end up with a
single offending commit.

You need to make sure that each commit message provides context about
what it's doing, and not just rephrase the diff.

In order words, it's *never* okay to just re-work the diff, you
*always* need to describe the context. That's not something optional to
only do on special occasions.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] arm: sunxi: Bananapi_M2_Ultra not working with DM_MMC

[Paul Kocialkowski]

Hi,

Le lundi 08 avril 2019 à 19:03 +0530, Jagan Teki a écrit :
> On Mon, Apr 8, 2019 at 6:40 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le lundi 08 avril 2019 à 18:23 +0530, Jagan Teki a écrit :
> > > Hi Paul,
> > > 
> > > On Mon, Apr 8, 2019 at 6:00 PM Paul Kocialkowski
> > >  wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 2019-04-04 at 05:51 -0300, Pablo Sebastián Greco wrote:
> > > > > A few days ago I tried to boot my Bananapi_M2_Ultra with 2019.04rc, I
> > > > > found that it wasn't booting, 2019.01 was working ok.
> > > > > Bisecting indicated that the problem was after
> > > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a7cca5793774ee139b75a704d6efaa4d29f09f93
> > > > 
> > > > I think the patch should be reverted ASAP since it obviously breaks
> > > > some supported configs. Sadly, the offending commit doesn't say
> > > > anything about the test coverage for the change and what the status is
> > > > after it. There is probably a reason why it was enabled for sun4i only
> > > > before and there must have been a motivation for doing this on all
> > > > sunxi platforms, but then again, the commit message says nothing about
> > > > those underlying reasons.
> > > > 
> > > > I believe we should be more strict on patch review and not let any
> > > > change bringing such a major change get applied with a commit message
> > > > that provides no context about why the change is okay and how it was
> > > > tested.
> > > 
> > > Appropriate your concern.
> > > 
> > > If you please list what all boards are not working with this effect,
> > > please write back. we will defiantly look into it. All these changes
> > > were merged in MW which is 2.5 months back, commenting in final stage
> > > like this is not the professional way.
> > 
> > I really do not think this is a sane approach to follow. You can't make
> > a change like this, with no context whatsoever in the commit message,
> > which ends up breaking other people's setups and wait for others to
> > debug subsequent issues it introduces that you don't encounter.
> > 
> > Sorry but your commit should never have been merged. Sure, I wasn't
> > there to review it either, but the code review process definitely did
> > not go as planned here.
> 
> Which commit message your referring to? are you referring this
> patch[1] commit message. let me point what exactly is the issue?
> 
> [1] 
> http://git.denx.de/?p=u-boot.git;a=commit;h=a7cca5793774ee139b75a704d6efaa4d29f09f93

Yes, this is the patch I'm talking about.

The issue with it is that the commit message is totally redundant: the
description does not say more than what the diff does.

A git commit description should provide context about what the change
does above the modified lines: what problem it tries to resolve and how
, on what hardware, how it was tested, etc. Especially for a commit
making such a big change, the commit message must have all this
information.

Do you see why I think it's a problem?

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] arm: sunxi: Bananapi_M2_Ultra not working with DM_MMC

[Paul Kocialkowski]

Hi,

Le lundi 08 avril 2019 à 09:25 -0400, Tom Rini a écrit :
> On Mon, Apr 08, 2019 at 06:51:48PM +0530, Jagan Teki wrote:
> > + Andre
> > 
> > On Mon, Apr 8, 2019 at 6:40 PM Tom Rini  wrote:
> > > On Mon, Apr 08, 2019 at 06:23:29PM +0530, Jagan Teki wrote:
> > > > Hi Paul,
> > > > 
> > > > On Mon, Apr 8, 2019 at 6:00 PM Paul Kocialkowski
> > > >  wrote:
> > > > > Hi,
> > > > > 
> > > > > On Thu, 2019-04-04 at 05:51 -0300, Pablo Sebastián Greco wrote:
> > > > > > A few days ago I tried to boot my Bananapi_M2_Ultra with 2019.04rc, 
> > > > > > I
> > > > > > found that it wasn't booting, 2019.01 was working ok.
> > > > > > Bisecting indicated that the problem was after
> > > > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a7cca5793774ee139b75a704d6efaa4d29f09f93
> > > > > 
> > > > > I think the patch should be reverted ASAP since it obviously breaks
> > > > > some supported configs. Sadly, the offending commit doesn't say
> > > > > anything about the test coverage for the change and what the status is
> > > > > after it. There is probably a reason why it was enabled for sun4i only
> > > > > before and there must have been a motivation for doing this on all
> > > > > sunxi platforms, but then again, the commit message says nothing about
> > > > > those underlying reasons.
> > > > > 
> > > > > I believe we should be more strict on patch review and not let any
> > > > > change bringing such a major change get applied with a commit message
> > > > > that provides no context about why the change is okay and how it was
> > > > > tested.
> > > > 
> > > > Appropriate your concern.
> > > > 
> > > > If you please list what all boards are not working with this effect,
> > > > please write back. we will defiantly look into it. All these changes
> > > > were merged in MW which is 2.5 months back, commenting in final stage
> > > > like this is not the professional way.
> > > 
> > > OK, but what platforms was this all tested on?  Thanks!
> > 
> > We have tested DM_MMC all the Allwinner SoC platforms and I couldn't
> > find any mmc issues so-far on my boards atleast.
> 
> Sorry, let me try and be clearer.  Which hardware platforms did you test
> this on?  There's quite a lot of Allwinner SoCs, and it's not clear at
> all if Paul's problem is because of something on the SoC on the Bananapi
> M2 Ultra (because it's not clear if another platform with that same SoC
> was tested) or how the board is wired (DM MMC is fine on that SoC, but
> was tested on something where uSD/MMC are opposite of that platform or
> ...).

For the record, it's not my setup that was broken but Pablo Sebastián
Greco's. I suggested that we revert the offending patch for now and
replace it with a proper one that provides some context about the
change.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] arm: sunxi: Bananapi_M2_Ultra not working with DM_MMC

[Paul Kocialkowski]

Hi,

Le lundi 08 avril 2019 à 18:23 +0530, Jagan Teki a écrit :
> Hi Paul,
> 
> On Mon, Apr 8, 2019 at 6:00 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Thu, 2019-04-04 at 05:51 -0300, Pablo Sebastián Greco wrote:
> > > A few days ago I tried to boot my Bananapi_M2_Ultra with 2019.04rc, I
> > > found that it wasn't booting, 2019.01 was working ok.
> > > Bisecting indicated that the problem was after
> > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a7cca5793774ee139b75a704d6efaa4d29f09f93
> > 
> > I think the patch should be reverted ASAP since it obviously breaks
> > some supported configs. Sadly, the offending commit doesn't say
> > anything about the test coverage for the change and what the status is
> > after it. There is probably a reason why it was enabled for sun4i only
> > before and there must have been a motivation for doing this on all
> > sunxi platforms, but then again, the commit message says nothing about
> > those underlying reasons.
> > 
> > I believe we should be more strict on patch review and not let any
> > change bringing such a major change get applied with a commit message
> > that provides no context about why the change is okay and how it was
> > tested.
> 
> Appropriate your concern.
> 
> If you please list what all boards are not working with this effect,
> please write back. we will defiantly look into it. All these changes
> were merged in MW which is 2.5 months back, commenting in final stage
> like this is not the professional way.

I really do not think this is a sane approach to follow. You can't make
a change like this, with no context whatsoever in the commit message,
which ends up breaking other people's setups and wait for others to
debug subsequent issues it introduces that you don't encounter.

Sorry but your commit should never have been merged. Sure, I wasn't
there to review it either, but the code review process definitely did
not go as planned here.

The commit you made was not appropriate when you submitted it, it turns
out it broke something and it should be fixed. As for professionalism,
are you actually suggesting that we void fixing your commit as a
courtesy because it went through patch review already? That makes no
sense to me.

Clearly, your work was the issue here so please don't try and dodge the
bullet. I already had the occasion to tell you that your commit
messages are not appropriate when reviewing other patches and this is a
clear result of what happens when a patch skips through patch review
and nobody pushed you to produce a proper commit message. It would be
great if you could take this as a clear example why this is a problem.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] arm: sunxi: Bananapi_M2_Ultra not working with DM_MMC

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-04 at 05:51 -0300, Pablo Sebastián Greco wrote:
> A few days ago I tried to boot my Bananapi_M2_Ultra with 2019.04rc, I 
> found that it wasn't booting, 2019.01 was working ok.
> Bisecting indicated that the problem was after 
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a7cca5793774ee139b75a704d6efaa4d29f09f93

I think the patch should be reverted ASAP since it obviously breaks
some supported configs. Sadly, the offending commit doesn't say
anything about the test coverage for the change and what the status is
after it. There is probably a reason why it was enabled for sun4i only
before and there must have been a motivation for doing this on all
sunxi platforms, but then again, the commit message says nothing about
those underlying reasons.

I believe we should be more strict on patch review and not let any
change bringing such a major change get applied with a commit message
that provides no context about why the change is okay and how it was
tested.

Cheers,

Paul

> Here's what I see when booting:
> 
> U-Boot SPL 2019.04-rc4 (Apr 02 2019 - 16:17:43 +)
> DRAM: 2048 MiB
> Trying to boot from MMC1
> 
> 
> U-Boot 2019.04-rc4 (Apr 02 2019 - 16:17:43 +) Allwinner Technology
> 
> CPU:   Allwinner R40 (SUN8I 1701)
> Model: Banana Pi BPI-M2-Ultra
> I2C:   ready
> DRAM:  2 GiB
> MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c1'
> mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
> Loading Environment from FAT... ** No valid partitions found **
> In:serial@1c28000
> Out:   serial@1c28000
> Err:   serial@1c28000
> SCSI:  Target spinup took 0 ms.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> 
> Net:   phy interface7
> eth0: ethernet@1c5
> starting USB...
> No controllers found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> switch to partitions #0, OK
> mmc1(part 0) is current device
> ** Invalid partition 1 **
> scanning bus for devices...
> data abort
> pc : []  lr : []
> reloc pc : [<4a01a6da>]lr : [<4a016991>]
> sp : bbf5d620  ip : 001c fp : 00c0
> r10:   r9 : bbf61ed8 r8 : 
> r7 : bbf5d8a0  r6 : bffdbff0 r5 : bffdbff0  r4 : bffdbff0
> r3 :   r2 :  r1 : ea16  r0 : bffdbff0
> Flags: nZcv  IRQs off  FIQs off  Mode SVC_32
> Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604)
> Resetting CPU ...
> 
> resetting ...
> 
> Any pointers on what to text next?
> 
> Thanks.
> Pablo.
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support

[Paul Kocialkowski]

Hi,

Le jeudi 04 avril 2019 à 14:12 +0530, Jagan Teki a écrit :
> On Thu, Apr 4, 2019 at 1:43 PM Paul Kocialkowski  wrote:
> > Hi,
> > 
> > On Sat, 2018-11-03 at 16:58 +0530, Akash Gajjar wrote:
> > > Rockpro64 is rk3399 based board from pine64.org. add initial board 
> > > support for
> > > Rockpro64. complete board support will be added later in upcoming 
> > > patchsets.
> > 
> > Thanks for contributing this initial support patchset!
> > 
> > Now that the dts has landed in Linux, do you have plans for making a
> > new revision of this series?
> > 
> > I plan on using the board soon-ish and I'd like to get an upstream U-
> > Boot + Linux setup on it, so I'm definitely interested in this series.
> > 
> > Feel free to let me know if I could help with anything when I get the
> > board!
> 
> It is paused because of LPDDR4 code dependency, right now we are
> working on it. Will update once the code gets ready to push it on
> Mainline.

Sound great, thanks for the update!

Cheers,

Paul

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

Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support

[Paul Kocialkowski]

Hi,

On Sat, 2018-11-03 at 16:58 +0530, Akash Gajjar wrote:
> Rockpro64 is rk3399 based board from pine64.org. add initial board support for
> Rockpro64. complete board support will be added later in upcoming patchsets.

Thanks for contributing this initial support patchset!

Now that the dts has landed in Linux, do you have plans for making a
new revision of this series?

I plan on using the board soon-ish and I'd like to get an upstream U-
Boot + Linux setup on it, so I'm definitely interested in this series.

Feel free to let me know if I could help with anything when I get the
board!

Cheers,

Paul

> Signed-off-by: Akash Gajjar 
> ---
>  arch/arm/dts/Makefile  |1 +
>  arch/arm/dts/rk3399-rockpro64.dts  |  519 +++
>  arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi | 1535 
>  arch/arm/mach-rockchip/rk3399/Kconfig  |   10 +
>  board/rockchip/rockpro64/Kconfig   |   15 +
>  board/rockchip/rockpro64/MAINTAINERS   |6 +
>  board/rockchip/rockpro64/Makefile  |7 +
>  board/rockchip/rockpro64/rockpro64.c   |   94 ++
>  configs/rockpro64-rk3399_defconfig |   78 +
>  include/configs/rockpro64.h|   15 +
>  10 files changed, 2280 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
>  create mode 100644 arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi
>  create mode 100644 board/rockchip/rockpro64/Kconfig
>  create mode 100644 board/rockchip/rockpro64/MAINTAINERS
>  create mode 100644 board/rockchip/rockpro64/Makefile
>  create mode 100644 board/rockchip/rockpro64/rockpro64.c
>  create mode 100644 configs/rockpro64-rk3399_defconfig
>  create mode 100644 include/configs/rockpro64.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d36447d18d..8a84cf55a3 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -51,6 +51,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3399-puma-ddr1333.dtb \
>   rk3399-puma-ddr1600.dtb \
>   rk3399-puma-ddr1866.dtb \
> + rk3399-rockpro64.dtb \
>   rv1108-evb.dtb
>  dtb-$(CONFIG_ARCH_MESON) += \
>   meson-gxbb-nanopi-k2.dtb \
> diff --git a/arch/arm/dts/rk3399-rockpro64.dts 
> b/arch/arm/dts/rk3399-rockpro64.dts
> new file mode 100644
> index 00..8497a1124b
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-rockpro64.dts
> @@ -0,0 +1,519 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2018 Akash Gajjar 
> + */
> +
> +/dts-v1/;
> +#include 
> +#include 
> +#include "rk3399.dtsi"
> +#include "rk3399-sdram-lpddr4-1600.dtsi"
> +
> +/ {
> + model = "Pine64 Rockpro64-RK3399 Board";
> + compatible = "pine64,rockpro64", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = 
> + u-boot,spl-boot-order = , 
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + vcc5v0_host: vcc5v0-host-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < RK_PD2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_vbus_drv>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + };
> +
> + vcc5v0_sys: vcc5v0-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_log: vdd-log {
> + compatible = "pwm-regulator";
> + pwms = < 0 25000 1>;
> + regulator-name = "vdd_log";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <43>;
> + regulator-max-microvolt = <140>;
> + regulator-init-microvolt = <95>;
> + };
> +
> + vccadc_ref: vccadc-ref {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + };
> +};
> +

Re: [U-Boot] [linux-sunxi] [PATCH 3/3] arm: sunxi: Enable DRAM ODT by default on H3/H5

[Paul Kocialkowski]

Hi,

Le mercredi 03 avril 2019 à 13:09 +0530, Jagan Teki a écrit :
> On Thu, Mar 14, 2019 at 4:07 PM Paul Kocialkowski
>  wrote:
> > Most of the boards we support with H3/H5 enable DRAM on-die termination,
> > which is consistent with the high DRAM clocks that are used.
> > 
> > Make it the default (like it's done for other similar platforms) instead
> > of defining it in each defconfig.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  arch/arm/mach-sunxi/Kconfig   | 1 +
> >  configs/bananapi_m2_plus_h3_defconfig | 1 -
> >  configs/bananapi_m2_plus_h5_defconfig | 1 -
> >  configs/bananapi_m2_zero_defconfig| 1 -
> >  configs/emlid_neutis_n5_devboard_defconfig| 1 +
> >  configs/libretech_all_h3_cc_h2_plus_defconfig | 1 -
> >  configs/libretech_all_h3_cc_h3_defconfig  | 1 -
> >  configs/libretech_all_h3_cc_h5_defconfig  | 1 -
> >  configs/nanopi_m1_defconfig   | 1 -
> >  configs/nanopi_m1_plus_defconfig  | 1 -
> >  configs/nanopi_neo2_defconfig | 1 +
> >  configs/nanopi_neo_air_defconfig  | 1 -
> >  configs/nanopi_neo_defconfig  | 1 -
> >  configs/nanopi_neo_plus2_defconfig| 1 +
> >  configs/orangepi_2_defconfig  | 1 -
> >  configs/orangepi_lite_defconfig   | 1 -
> >  configs/orangepi_one_defconfig| 1 -
> >  configs/orangepi_pc2_defconfig| 1 +
> >  configs/orangepi_pc_defconfig | 1 -
> >  configs/orangepi_pc_plus_defconfig| 1 -
> >  configs/orangepi_plus2e_defconfig | 1 -
> >  configs/orangepi_plus_defconfig   | 1 -
> >  configs/orangepi_prime_defconfig  | 1 +
> >  configs/orangepi_r1_defconfig | 1 -
> >  configs/orangepi_zero_defconfig   | 1 -
> >  configs/orangepi_zero_plus2_defconfig | 1 +
> >  configs/orangepi_zero_plus_defconfig  | 1 +
> >  27 files changed, 8 insertions(+), 19 deletions(-)

[...]

> > diff --git a/configs/orangepi_zero_plus_defconfig 
> > b/configs/orangepi_zero_plus_defconfig
> > index cc8b8c7f9ab9..37ca6dff374f 100644
> > --- a/configs/orangepi_zero_plus_defconfig
> > +++ b/configs/orangepi_zero_plus_defconfig
> > @@ -4,6 +4,7 @@ CONFIG_SPL=y
> >  CONFIG_MACH_SUN50I_H5=y
> >  CONFIG_DRAM_CLK=624
> >  CONFIG_DRAM_ZQ=3881977
> > +# CONFIG_DRAM_ODT_EN is not set
> 
> Why ODT not enabled these boards?

Because the config wasn't set before on these boards and I don't want
to change the DRAM configuration of any board without testing.

It's very likely that enabling ODT would be a good idea on these boards
too, but someone needs to test that before making the change.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] [PATCH] env: add support to sunxi save env to spi

[Paul Kocialkowski]

Hi,

Le dimanche 17 mars 2019 à 20:49 +0200, Oskari Lemmela a écrit :
> CONFIG_ENV_SECT_SIZE value is defined via Kconfig.
> 
> Signed-off-by: Oskari Lemmela 

Looks good to me!

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  env/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/env/Kconfig b/env/Kconfig
> index c22cbbdadc..e1070187f2 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -456,9 +456,9 @@ config ENV_SIZE
>  
>  config ENV_SECT_SIZE
>   hex "Environment Sector-Size"
> - depends on !ENV_IS_NOWHERE && (ARCH_ZYNQ || ARCH_ZYNQMP)
> + depends on !ENV_IS_NOWHERE && (ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_SUNXI )
>   default 0x4 if ARCH_ZYNQMP
> - default 0x2 if ARCH_ZYNQ
> + default 0x2 if ARCH_ZYNQ || ARCH_SUNXI
>   help
> Size of the sector containing the environment.
>  
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [U-Boot] Subject

[Paul Kocialkowski]

Hi,

Le lundi 18 mars 2019 à 10:56 +0100, Eugeniu Rosca a écrit :
> Hi Marek, Paul, cc: Alex
> 
> jFYI/FWIW, reverting [1-2] allows getting rid of below warnings on
> R-Car3, when running basic fastboot commands (e.g. fastboot getvar):
> 
> [8.035764] status: -104 ep 'ep1' trans: 0
> [   18.744354] status: -104 ep 'ep1' trans: 28
> [   18.748950] status: -104 ep 'ep1' trans: 9
> [   18.753370] status: -104 ep 'ep1' trans: 28
> [   26.064761] status: -104 ep 'ep1' trans: 28

I don't think reverting this patch in mainline U-Boot would be a good
idea, as it is required to get fastboot to work at all on sunxi
platforms with the MUSB controller.

Did you investigate the issue to see what is happening here precisely?

Cheers,

Paul

> This has been pointed out by Dmytro (To:) in one of his patches which
> reached us via official Renesas release. Since R-Car USB gadget driver
> is not yet present in mainline [3], the behavior cannot be reproduced
> with vanilla U-Boot. In case, at some point in time, you hit the same
> problem and come to the same or an alternative solution, please share.
> TIA!
> 
> [1] https://patchwork.ozlabs.org/patch/491249/ ("[U-Boot,2/2] usb: gadget: 
> fastboot: Dequeue the previous IN request for the current request")
> [2] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=bc9071c9f318 ("usb: 
> gadget: fastboot: Dequeue the previous IN request for the current request")
> [3] https://patchwork.ozlabs.org/patch/978026/#2107803
> 
> Best regards,
> Eugeniu.

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

Re: [U-Boot] [linux-sunxi] [PATCH 1/3] arm: sunxi: Allow per-platform DRAM ZQ configuration on sun8i

[Paul Kocialkowski]

Hi Julian,

On Thu, 2019-03-14 at 22:19 +1100, Julian Calaby wrote:
> Hi Paul,
> 
> On Thu, Mar 14, 2019 at 9:37 PM Paul Kocialkowski
>  wrote:
> > A few sun8i platforms define specific default DRAM ZQ values, but they
> > are not taken in account because of MACH_SUN8I being used for the 123
> > default first.
> > 
> > Replace MACH_SUN8I with the list of platforms that don't have specific
> > DRAM ZQ values, to avoid overwriting the default for those that do.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  arch/arm/mach-sunxi/Kconfig | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 74e234cded75..c557c79ef097 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -414,7 +414,9 @@ endif
> > 
> >  config DRAM_ZQ
> > int "sunxi dram zq value"
> > -   default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I
> > +   default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || \
> > +  MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_A83T 
> > || \
> > +  MACH_SUNXI_H3_H5
> > default 127 if MACH_SUN7I
> > default 14779 if MACH_SUN8I_V3S
> > default 3881979 if MACH_SUN8I_R40 || MACH_SUN50I_H6
> 
> Would it work if these were just re-ordered so the more specific ones
> come first?

Yes it looks like this would work, but I think it's better to be
explicit and avoid any misunderstanding.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

[U-Boot] [PATCH] arm: sunxi: Add support for the RerVision H3-DVK board

[Paul Kocialkowski]

This is an H3-based board that sticks close to the reference design.

Supported features:
* UART
* DRAM
* MMC
* eMMC
* Ethernet
* USB host
* USB peripheral
* HDMI

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/sun8i-h3-rervision-dvk.dts | 107 
 configs/rervision_h3_dvk_defconfig  |  17 
 3 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
 create mode 100644 configs/rervision_h3_dvk_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2a040b20a539..a64c0fada4cb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -401,7 +401,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-pc.dtb \
sun8i-h3-orangepi-pc-plus.dtb \
sun8i-h3-orangepi-plus.dtb \
-   sun8i-h3-orangepi-plus2e.dtb
+   sun8i-h3-orangepi-plus2e.dtb \
+   sun8i-h3-rervision-dvk.dtb
 dtb-$(CONFIG_MACH_SUN8I_R40) += \
sun8i-r40-bananapi-m2-ultra.dtb \
sun8i-v40-bananapi-m2-berry.dtb
diff --git a/arch/arm/dts/sun8i-h3-rervision-dvk.dts 
b/arch/arm/dts/sun8i-h3-rervision-dvk.dts
new file mode 100644
index ..8a4b83a02d9d
--- /dev/null
+++ b/arch/arm/dts/sun8i-h3-rervision-dvk.dts
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "RerVision H3-DVK";
+   compatible = "rervision,h3-dvk", "allwinner,sun8i-h3";
+
+   aliases {
+   ethernet0 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_input: endpoint {
+   remote-endpoint = <_connector_output>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   phy-handle = <_mii_phy>;
+   phy-mode = "mii";
+   allwinner,leds-active-low;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_connector_output: endpoint {
+   remote-endpoint = <_connector_input>;
+   };
+};
+
+ {
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+   status = "okay";
+   vmmc-supply = <_vcc3v3>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
+};
+
+_8bit_pins {
+   drive-strength = <40>;
+   bias-pull-up;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
+_otg {
+   status = "okay";
+   dr_mode = "peripheral";
+};
+
+ {
+   status = "okay";
+};
diff --git a/configs/rervision_h3_dvk_defconfig 
b/configs/rervision_h3_dvk_defconfig
new file mode 100644
index ..895a985ccdcd
--- /dev/null
+++ b/configs/rervision_h3_dvk_defconfig
@@ -0,0 +1,17 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL=y
+CONFIG_MACH_SUN8I_H3=y
+CONFIG_DRAM_CLK=408
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_NR_DRAM_BANKS=1
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-rervision-dvk"
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_FASTBOOT=y
-- 
2.20.1

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

[U-Boot] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB

[Paul Kocialkowski]

Recent Allwinner platforms (starting with the H3) only use the MUSB
controller for peripheral mode and use HCI for host mode. As a result,
extra steps need to be taken to properly route USB signals to one or
the other. More precisely, the following is required:
* Routing the pins to either HCI/MUSB (controlled by PHY);
* Enabling USB PHY passby in HCI mode (controlled by PMU).

The current code will enable passby for each PHY and reroute PHY0 to
MUSB, which is inconsistent and results in broken USB peripheral support.

Passby on PHY0 must only be enabled when we want to use HCI. Since
host/device mode detection is not available from the PHY code and
because U-Boot does not support changing the mode dynamically anyway,
we can just mux the controller to MUSB if it is enabled and mux it to
HCI otherwise.

This fixes USB peripheral support for platforms with PHY0 dual-route,
especially H3/H5 and V3s.

Signed-off-by: Paul Kocialkowski 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index f206fa3f5d48..4f1c7e519d71 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy)
data->cfg->disc_thresh, PHY_DISCON_TH_LEN);
}
 
+#ifdef CONFIG_USB_MUSB_SUNXI
+   /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */
+   if (usb_phy->id != 0)
+   sun4i_usb_phy_passby(phy, true);
+
+   /* Route PHY0 to MUSB to allow USB gadget */
+   if (data->cfg->phy0_dual_route)
+   sun4i_usb_phy0_reroute(data, true);
+#else
sun4i_usb_phy_passby(phy, true);
 
-   sun4i_usb_phy0_reroute(data, true);
+   /* Route PHY0 to HCI to allow USB host */
+   if (data->cfg->phy0_dual_route)
+   sun4i_usb_phy0_reroute(data, false);
+#endif
 
return 0;
 }
-- 
2.20.1

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

[U-Boot] [PATCH 3/3] arm: sunxi: Enable DRAM ODT by default on H3/H5

[Paul Kocialkowski]

Most of the boards we support with H3/H5 enable DRAM on-die termination,
which is consistent with the high DRAM clocks that are used.

Make it the default (like it's done for other similar platforms) instead
of defining it in each defconfig.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/mach-sunxi/Kconfig   | 1 +
 configs/bananapi_m2_plus_h3_defconfig | 1 -
 configs/bananapi_m2_plus_h5_defconfig | 1 -
 configs/bananapi_m2_zero_defconfig| 1 -
 configs/emlid_neutis_n5_devboard_defconfig| 1 +
 configs/libretech_all_h3_cc_h2_plus_defconfig | 1 -
 configs/libretech_all_h3_cc_h3_defconfig  | 1 -
 configs/libretech_all_h3_cc_h5_defconfig  | 1 -
 configs/nanopi_m1_defconfig   | 1 -
 configs/nanopi_m1_plus_defconfig  | 1 -
 configs/nanopi_neo2_defconfig | 1 +
 configs/nanopi_neo_air_defconfig  | 1 -
 configs/nanopi_neo_defconfig  | 1 -
 configs/nanopi_neo_plus2_defconfig| 1 +
 configs/orangepi_2_defconfig  | 1 -
 configs/orangepi_lite_defconfig   | 1 -
 configs/orangepi_one_defconfig| 1 -
 configs/orangepi_pc2_defconfig| 1 +
 configs/orangepi_pc_defconfig | 1 -
 configs/orangepi_pc_plus_defconfig| 1 -
 configs/orangepi_plus2e_defconfig | 1 -
 configs/orangepi_plus_defconfig   | 1 -
 configs/orangepi_prime_defconfig  | 1 +
 configs/orangepi_r1_defconfig | 1 -
 configs/orangepi_zero_defconfig   | 1 -
 configs/orangepi_zero_plus2_defconfig | 1 +
 configs/orangepi_zero_plus_defconfig  | 1 +
 27 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 10d5c5b5cb0f..8234a76e7310 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -427,6 +427,7 @@ config DRAM_ZQ
 config DRAM_ODT_EN
bool "sunxi dram odt enable"
default y if MACH_SUN8I_A23
+   default y if MACH_SUNXI_H3_H5
default y if MACH_SUN8I_R40
default y if MACH_SUN50I
default y if MACH_SUN50I_H6
diff --git a/configs/bananapi_m2_plus_h3_defconfig 
b/configs/bananapi_m2_plus_h3_defconfig
index b906942b2430..4e4734655fc9 100644
--- a/configs/bananapi_m2_plus_h3_defconfig
+++ b/configs/bananapi_m2_plus_h3_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ODT_EN=y
 CONFIG_MACPWR="PD6"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
diff --git a/configs/bananapi_m2_plus_h5_defconfig 
b/configs/bananapi_m2_plus_h5_defconfig
index 4d70cb632fe9..29dd892d7f07 100644
--- a/configs/bananapi_m2_plus_h5_defconfig
+++ b/configs/bananapi_m2_plus_h5_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN50I_H5=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ODT_EN=y
 CONFIG_MACPWR="PD6"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
diff --git a/configs/bananapi_m2_zero_defconfig 
b/configs/bananapi_m2_zero_defconfig
index 4cabf32ffc72..8546674b2395 100644
--- a/configs/bananapi_m2_zero_defconfig
+++ b/configs/bananapi_m2_zero_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=408
-CONFIG_DRAM_ODT_EN=y
 CONFIG_MMC0_CD_PIN=""
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/emlid_neutis_n5_devboard_defconfig 
b/configs/emlid_neutis_n5_devboard_defconfig
index 3df0ca13f04d..19e8d792556c 100644
--- a/configs/emlid_neutis_n5_devboard_defconfig
+++ b/configs/emlid_neutis_n5_devboard_defconfig
@@ -4,6 +4,7 @@ CONFIG_SPL=y
 CONFIG_MACH_SUN50I_H5=y
 CONFIG_DRAM_CLK=408
 CONFIG_DRAM_ZQ=3881977
+# CONFIG_DRAM_ODT_EN is not set
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/libretech_all_h3_cc_h2_plus_defconfig 
b/configs/libretech_all_h3_cc_h2_plus_defconfig
index 7a83e0752ec2..3bccd6042910 100644
--- a/configs/libretech_all_h3_cc_h2_plus_defconfig
+++ b/configs/libretech_all_h3_cc_h2_plus_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ODT_EN=y
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/libretech_all_h3_cc_h3_defconfig 
b/configs/libretech_all_h3_cc_h3_defconfig
index e2ebc7527f2f..c00ab01fdda4 100644
--- a/configs/libretech_all_h3_cc_h3_defconfig
+++ b/configs/libretech_all_h3_cc_h3_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ODT_EN=y
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/libretech_all_h3_cc_h5_defconfig 
b/configs/libretech_all_h3_cc_h5_defconfig

[U-Boot] [PATCH 2/3] arm: sunxi: Set the default DRAM ZQ value to 3881979 on H3/H5

[Paul Kocialkowski]

Most H3/H5 boards we support have the DRAM ZQ value set to 3881979,
which is also consistent with the default set for the R40.

Make this value the default on H3/H5 instead of 123.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/mach-sunxi/Kconfig   | 5 ++---
 configs/bananapi_m2_plus_h3_defconfig | 1 -
 configs/bananapi_m2_plus_h5_defconfig | 1 -
 configs/bananapi_m2_zero_defconfig| 1 -
 configs/libretech_all_h3_cc_h2_plus_defconfig | 1 -
 configs/libretech_all_h3_cc_h3_defconfig  | 1 -
 configs/libretech_all_h3_cc_h5_defconfig  | 1 -
 configs/nanopi_m1_defconfig   | 1 -
 configs/nanopi_m1_plus_defconfig  | 1 -
 configs/nanopi_neo_air_defconfig  | 1 -
 configs/nanopi_neo_defconfig  | 1 -
 configs/orangepi_2_defconfig  | 1 -
 configs/orangepi_lite_defconfig   | 1 -
 configs/orangepi_one_defconfig| 1 -
 configs/orangepi_pc_defconfig | 1 -
 configs/orangepi_pc_plus_defconfig| 1 -
 configs/orangepi_plus2e_defconfig | 1 -
 configs/orangepi_plus_defconfig   | 1 -
 configs/orangepi_r1_defconfig | 1 -
 configs/orangepi_zero_defconfig   | 1 -
 20 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index c557c79ef097..10d5c5b5cb0f 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -415,11 +415,10 @@ endif
 config DRAM_ZQ
int "sunxi dram zq value"
default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || \
-  MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_A83T || \
-  MACH_SUNXI_H3_H5
+  MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_A83T
default 127 if MACH_SUN7I
default 14779 if MACH_SUN8I_V3S
-   default 3881979 if MACH_SUN8I_R40 || MACH_SUN50I_H6
+   default 3881979 if MACH_SUNXI_H3_H5 || MACH_SUN8I_R40 || MACH_SUN50I_H6
default 4145117 if MACH_SUN9I
default 3881915 if MACH_SUN50I
---help---
diff --git a/configs/bananapi_m2_plus_h3_defconfig 
b/configs/bananapi_m2_plus_h3_defconfig
index 597618fb900b..b906942b2430 100644
--- a/configs/bananapi_m2_plus_h3_defconfig
+++ b/configs/bananapi_m2_plus_h3_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
 CONFIG_MACPWR="PD6"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
diff --git a/configs/bananapi_m2_plus_h5_defconfig 
b/configs/bananapi_m2_plus_h5_defconfig
index e7c10dbdf2d0..4d70cb632fe9 100644
--- a/configs/bananapi_m2_plus_h5_defconfig
+++ b/configs/bananapi_m2_plus_h5_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN50I_H5=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
 CONFIG_MACPWR="PD6"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
diff --git a/configs/bananapi_m2_zero_defconfig 
b/configs/bananapi_m2_zero_defconfig
index 91302eb49cf8..4cabf32ffc72 100644
--- a/configs/bananapi_m2_zero_defconfig
+++ b/configs/bananapi_m2_zero_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=408
-CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
 CONFIG_MMC0_CD_PIN=""
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/libretech_all_h3_cc_h2_plus_defconfig 
b/configs/libretech_all_h3_cc_h2_plus_defconfig
index 8f3144895c6d..7a83e0752ec2 100644
--- a/configs/libretech_all_h3_cc_h2_plus_defconfig
+++ b/configs/libretech_all_h3_cc_h2_plus_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
diff --git a/configs/libretech_all_h3_cc_h3_defconfig 
b/configs/libretech_all_h3_cc_h3_defconfig
index e5e0f593a7db..e2ebc7527f2f 100644
--- a/configs/libretech_all_h3_cc_h3_defconfig
+++ b/configs/libretech_all_h3_cc_h3_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
diff --git a/configs/libretech_all_h3_cc_h5_defconfig 
b/configs/libretech_all_h3_cc_h5_defconfig
index e4a93bde481f..30c1aa21b713 100644
--- a/configs/libretech_all_h3_cc_h5_defconfig
+++ b/configs/libretech_all_h3_cc_h5_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN50I_H5=y
 CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_NR_DRAM_BANKS=1
diff --git a/configs/nanopi_m1_defconfig b/configs/nanopi_m1_defconfig
index b3a7870ea9a6..222a8f9eaf35 100644
--- a/configs/nanopi_m1_defconfig
+++ b/configs/nanopi_m1_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CON

[U-Boot] [PATCH 1/3] arm: sunxi: Allow per-platform DRAM ZQ configuration on sun8i

[Paul Kocialkowski]

A few sun8i platforms define specific default DRAM ZQ values, but they
are not taken in account because of MACH_SUN8I being used for the 123
default first.

Replace MACH_SUN8I with the list of platforms that don't have specific
DRAM ZQ values, to avoid overwriting the default for those that do.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/mach-sunxi/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 74e234cded75..c557c79ef097 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -414,7 +414,9 @@ endif
 
 config DRAM_ZQ
int "sunxi dram zq value"
-   default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I
+   default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || \
+  MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_A83T || \
+  MACH_SUNXI_H3_H5
default 127 if MACH_SUN7I
default 14779 if MACH_SUN8I_V3S
default 3881979 if MACH_SUN8I_R40 || MACH_SUN50I_H6
-- 
2.20.1

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

[U-Boot] FOSDEM 2019 Hardware Enablement Devroom Call for Participation

[Paul Kocialkowski]

Hi,

The Hardware Enablement devroom is back for a second year at FOSDEM!
It will take place on Sunday 3 February 2019.

# Call for Participation

We are opening the call for participation to our devroom, with the
deadline for talk proposals set to Saturday 1 December 2018.

# Devroom Scope

This devroom covers topics related to hardware support and enablement
with free software. It includes the following topics:
* peripheral/controller firmwares
* boot software
* kernel drivers and hardware interfaces
* hardware-related adaptation in operating systems
* tools for firmware flashing
* tools for low-level development

Despite this large scope, the focus of the devroom is set on
highlighting the technical aspects of the hardware and its enablement
in free projects, rather than the specific applications and use cases
that benefit from it. We also want to avoid purely commercial vague
talks with marketing content, which leave little place to technical
aspects.

This year, we are looking to particularly highlighting free software
outside of the operating system boundaries, especially with boot
software as well as controller and peripheral firmwares.

# Talk Format

Since no Embedded devroom is taking place this year (and our devroom
also covers embedded devices), we are expecting a significant number of
submissions.

In order to cover as much ground as we can, a new talk will be
scheduled every half-hour, so accepted talks will follow this format:

 20 minutes for the talk
+ 5 minutes for questions
+ 5 minutes for speaker setup

We ask speakers to be present in the room before their talk so that
speaker setup can go smoothly.

# Submission

Talks that fit in our devroom's scope can be submitted to the FOSDEM
Pentabarf interface at https://penta.fosdem.org/submission/FOSDEM19

We encourage reusing accounts from previous years instead of creating
new ones:
* lost password: https://penta.fosdem.org/user/forgot_password
* new Account: https://penta.fosdem.org/user/new_account/FOSDEM19

Here are a few guidelines when submitting a talk:
* select the Hardware Enablement devroom as track
* include an abstract for every submission and optionally a full
  description
* make sure your contact details are up to date

# Video

Talks will be streamed live during the event and recorded. They will be
available under a Creative Commons Attribution (BY) license later.

# Contact

For more information or questions about the devroom and this CFP, feel
free to email hardware-devroom-manager at fosdem.org

We're looking forward to lots of interesting proposals and hoping to
see you all in Brussels at the event!

Cheers,

Paul for the Hardware Enablement devroom


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/4] sunxi: display: Also use the PWM controller for backlight on sun7i

[Paul Kocialkowski]

Using PWM to drive the backlight pin instead of a GPIO provides various
advantages, that are described in commit 421c98d7d2 ("sunxi: display:
Use PWM to drive backlight where applicable").

Defining SUNXI_PWM_PIN0 triggers the configuration of the PWM controller
in the display driver.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/include/asm/arch-sunxi/pwm.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/pwm.h 
b/arch/arm/include/asm/arch-sunxi/pwm.h
index 47eb433fb6..a9588a04f3 100644
--- a/arch/arm/include/asm/arch-sunxi/pwm.h
+++ b/arch/arm/include/asm/arch-sunxi/pwm.h
@@ -15,7 +15,8 @@
 
 #define SUNXI_PWM_PERIOD_80PCT 0x04af03c0
 
-#if defined CONFIG_MACH_SUN4I || defined CONFIG_MACH_SUN5I
+#if defined CONFIG_MACH_SUN4I || defined CONFIG_MACH_SUN5I || \
+defined CONFIG_MACH_SUN7I
 #define SUNXI_PWM_PIN0 SUNXI_GPB(2)
 #define SUNXI_PWM_MUX  SUN4I_GPB_PWM
 #endif
-- 
2.19.0

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

[U-Boot] [PATCH 2/4] sunxi: display: Add support for panels with an active-low DE signal

[Paul Kocialkowski]

This introduces a Kconfig option for indicating that the panel requires
the data enable (DE) signal driven low. The associated display flag is
set when converting the mode to display timings. It is later used for
setting the relevant bit in the TCON configuration registers.

This new option is kept separate from the VIDEO_LCD_MODE string because
the string format is expected to be kept in sync with the Linux
framebuffer definitions, that do not include this indication.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/include/asm/arch-sunxi/lcdc.h | 1 +
 arch/arm/mach-sunxi/Kconfig| 8 
 drivers/video/sunxi/lcdc.c | 2 ++
 drivers/video/sunxi/sunxi_display.c| 4 
 4 files changed, 15 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/lcdc.h 
b/arch/arm/include/asm/arch-sunxi/lcdc.h
index 90216bcfd5..3ce450636a 100644
--- a/arch/arm/include/asm/arch-sunxi/lcdc.h
+++ b/arch/arm/include/asm/arch-sunxi/lcdc.h
@@ -64,6 +64,7 @@ struct sunxi_lcdc_reg {
 #define SUNXI_LCDC_Y(y)(((y) - 1) << 0)
 #define SUNXI_LCDC_TCON_VSYNC_MASK (1 << 24)
 #define SUNXI_LCDC_TCON_HSYNC_MASK (1 << 25)
+#define SUNXI_LCDC_TCON_DE_MASK(1 << 27)
 #define SUNXI_LCDC_CTRL_IO_MAP_MASK(1 << 0)
 #define SUNXI_LCDC_CTRL_IO_MAP_TCON0   (0 << 0)
 #define SUNXI_LCDC_CTRL_IO_MAP_TCON1   (1 << 0)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index b868f0e350..a9fe3e4ab5 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -771,6 +771,14 @@ config VIDEO_LCD_DCLK_PHASE
---help---
Select LCD panel display clock phase shift, range 0-3.
 
+config VIDEO_LCD_DE_LOW
+   bool "LCD panel active-low data enable signal"
+   depends on VIDEO_SUNXI
+   default n
+   ---help---
+   Make the data enable signal active-low when driving the LCD panel.
+   This should only be enabled if the panel actually needs it.
+
 config VIDEO_LCD_POWER
string "LCD panel power enable pin"
depends on VIDEO_SUNXI
diff --git a/drivers/video/sunxi/lcdc.c b/drivers/video/sunxi/lcdc.c
index ef851070b2..abcef81a45 100644
--- a/drivers/video/sunxi/lcdc.c
+++ b/drivers/video/sunxi/lcdc.c
@@ -135,6 +135,8 @@ void lcdc_tcon0_mode_set(struct sunxi_lcdc_reg * const lcdc,
val |= SUNXI_LCDC_TCON_HSYNC_MASK;
if (mode->flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= SUNXI_LCDC_TCON_VSYNC_MASK;
+   if (mode->flags & DISPLAY_FLAGS_DE_LOW)
+   val |= SUNXI_LCDC_TCON_DE_MASK;
 
 #ifdef CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH
if (for_ext_vga_dac)
diff --git a/drivers/video/sunxi/sunxi_display.c 
b/drivers/video/sunxi/sunxi_display.c
index 5c8f88c42f..4baefee070 100644
--- a/drivers/video/sunxi/sunxi_display.c
+++ b/drivers/video/sunxi/sunxi_display.c
@@ -637,6 +637,10 @@ static void sunxi_ctfb_mode_to_display_timing(const struct 
ctfb_res_modes *mode,
timing->flags |= DISPLAY_FLAGS_VSYNC_LOW;
if (mode->vmode == FB_VMODE_INTERLACED)
timing->flags |= DISPLAY_FLAGS_INTERLACED;
+
+#ifdef CONFIG_VIDEO_LCD_DE_LOW
+   timing->flags |= DISPLAY_FLAGS_DE_LOW;
+#endif
 }
 
 static void sunxi_lcdc_tcon0_mode_set(const struct ctfb_res_modes *mode,
-- 
2.19.0

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

[U-Boot] [PATCH 4/4] sunxi: Add defconfig for the BananaPi with BL035 LCD module

[Paul Kocialkowski]

This introduces a new defconfig for the BananaPi, which includes support
for the BL035 LCD module distributed by Lemaker for use with this board.

Signed-off-by: Paul Kocialkowski 
---
 configs/Bananapi_LCD_BL035_defconfig | 29 
 1 file changed, 29 insertions(+)
 create mode 100644 configs/Bananapi_LCD_BL035_defconfig

diff --git a/configs/Bananapi_LCD_BL035_defconfig 
b/configs/Bananapi_LCD_BL035_defconfig
new file mode 100644
index 00..b0a8fb9099
--- /dev/null
+++ b/configs/Bananapi_LCD_BL035_defconfig
@@ -0,0 +1,29 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL=y
+CONFIG_MACH_SUN7I=y
+CONFIG_DRAM_CLK=432
+CONFIG_MACPWR="PH23"
+CONFIG_VIDEO_COMPOSITE=y
+CONFIG_VIDEO_LCD_MODE="x:320,y:240,depth:24,pclk_khz:7000,le:38,ri:20,up:15,lo:4,hs:30,vs:3,sync:0,vmode:0"
+CONFIG_VIDEO_LCD_DE_LOW=y
+CONFIG_VIDEO_LCD_POWER="PH12"
+CONFIG_VIDEO_LCD_BL_EN="PH8"
+CONFIG_VIDEO_LCD_BL_PWM="PB2"
+# CONFIG_VIDEO_LCD_BL_PWM_ACTIVE_LOW is not set
+CONFIG_GMAC_TX_DELAY=3
+CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-bananapi"
+CONFIG_AHCI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_I2C_SUPPORT=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_NETCONSOLE=y
+CONFIG_SCSI_AHCI=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_RGMII=y
+CONFIG_SUN7I_GMAC=y
+CONFIG_SCSI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.19.0

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

[U-Boot] [PATCH 1/4] sunxi: display: Fix h/vsync TCON polarity bits to indicate active-high

[Paul Kocialkowski]

Contrary to what is implemented in the Linux kernel, the U-Boot driver
supporting the sunxi TCON was assuming that the TCON0_IO_POL bits
indicate active-low signals when set for the hsync and vsync signals.

After looking at it with a logic analyzer, it appears that the signals
are active-low with the bits unset and active-high with the bits set.

Fix this by looking for the right flag (high instead of low) and
inverting the sync bits in the VIDEO_LCD_MODE declarations.

Signed-off-by: Paul Kocialkowski 
---
 configs/A33-OLinuXino_defconfig   | 2 +-
 configs/Ainol_AW1_defconfig   | 2 +-
 configs/Ampe_A76_defconfig| 2 +-
 configs/Chuwi_V7_CW0825_defconfig | 2 +-
 configs/Colombus_defconfig| 2 +-
 configs/Empire_electronix_d709_defconfig  | 2 +-
 configs/Empire_electronix_m712_defconfig  | 2 +-
 configs/Hyundai_A7HD_defconfig| 2 +-
 configs/MSI_Primo73_defconfig | 2 +-
 configs/MSI_Primo81_defconfig | 2 +-
 configs/Sinlinx_SinA33_defconfig  | 2 +-
 configs/UTOO_P66_defconfig| 2 +-
 configs/Wexler_TAB7200_defconfig  | 2 +-
 configs/Wits_Pro_A20_DKT_defconfig| 2 +-
 configs/Yones_Toptech_BD1078_defconfig| 2 +-
 configs/Yones_Toptech_BS1078_V2_defconfig | 2 +-
 configs/colorfly_e708_q1_defconfig| 2 +-
 configs/difrnce_dit4350_defconfig | 2 +-
 configs/dserve_dsrv9703c_defconfig| 2 +-
 configs/ga10h_v1_1_defconfig  | 2 +-
 configs/gt90h_v4_defconfig| 2 +-
 configs/iNet_3F_defconfig | 2 +-
 configs/iNet_3W_defconfig | 2 +-
 configs/iNet_86VS_defconfig   | 2 +-
 configs/iNet_D978_rev2_defconfig  | 2 +-
 configs/icnova-a20-swac_defconfig | 2 +-
 configs/inet1_defconfig   | 2 +-
 configs/inet86dz_defconfig| 2 +-
 configs/inet97fv2_defconfig   | 2 +-
 configs/inet98v_rev2_defconfig| 2 +-
 configs/inet9f_rev03_defconfig| 2 +-
 configs/inet_q972_defconfig   | 2 +-
 configs/polaroid_mid2407pxe03_defconfig   | 2 +-
 configs/polaroid_mid2809pxe04_defconfig   | 2 +-
 configs/pov_protab2_ips9_defconfig| 2 +-
 configs/q8_a13_tablet_defconfig   | 2 +-
 configs/q8_a23_tablet_800x480_defconfig   | 2 +-
 configs/q8_a33_tablet_1024x600_defconfig  | 2 +-
 configs/q8_a33_tablet_800x480_defconfig   | 2 +-
 configs/sunxi_Gemei_G9_defconfig  | 2 +-
 drivers/video/sunxi/lcdc.c| 4 ++--
 41 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/configs/A33-OLinuXino_defconfig b/configs/A33-OLinuXino_defconfig
index 744e7ef511..e456703be7 100644
--- a/configs/A33-OLinuXino_defconfig
+++ b/configs/A33-OLinuXino_defconfig
@@ -10,7 +10,7 @@ CONFIG_USB0_VBUS_PIN="AXP0-VBUS-ENABLE"
 CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT"
 CONFIG_USB0_ID_DET="PB3"
 CONFIG_AXP_GPIO=y
-CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
+CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:0,vmode:0"
 CONFIG_VIDEO_LCD_DCLK_PHASE=0
 CONFIG_VIDEO_LCD_BL_EN="PB2"
 CONFIG_VIDEO_LCD_BL_PWM="PH0"
diff --git a/configs/Ainol_AW1_defconfig b/configs/Ainol_AW1_defconfig
index 3e47ca2466..0d449cc53d 100644
--- a/configs/Ainol_AW1_defconfig
+++ b/configs/Ainol_AW1_defconfig
@@ -8,7 +8,7 @@ CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_USB0_VBUS_PIN="PB9"
 CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT"
 CONFIG_AXP_GPIO=y
-CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:4,le:87,ri:112,up:38,lo:141,hs:1,vs:1,sync:3,vmode:0"
+CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:4,le:87,ri:112,up:38,lo:141,hs:1,vs:1,sync:0,vmode:0"
 CONFIG_VIDEO_LCD_POWER="PH8"
 CONFIG_VIDEO_LCD_BL_EN="PH7"
 CONFIG_VIDEO_LCD_BL_PWM="PB2"
diff --git a/configs/Ampe_A76_defconfig b/configs/Ampe_A76_defconfig
index b0d6047789..1e18458179 100644
--- a/configs/Ampe_A76_defconfig
+++ b/configs/Ampe_A76_defconfig
@@ -9,7 +9,7 @@ CONFIG_USB0_VBUS_DET="PG1"
 CONFIG_USB0_ID_DET="PG2"
 CONFIG_AXP_GPIO=y
 # CONFIG_VIDEO_HDMI is not set
-CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:45,ri:82,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0"
+CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:45,ri:82,up:22,lo:22,hs:1,vs:1,sync:0,vmode:0"
 CONFIG_VIDEO_LCD_POWER="AXP0-0"
 CONFIG_VIDEO_LCD_BL_EN="AXP0-1"
 CONFIG_VIDEO_LCD_BL_PWM="PB2"
diff --git a/configs/Chuwi_V7_CW0825_defconfig 
b/configs/Chuwi_V7_CW0825_defconfig
index 645a759fc2..e08d1ac3cc 100644
--- a/configs/Chuwi_V7_CW0825_defconfig
+++ b/configs/Chuwi_V7_CW0825_defconfig
@@ -7,7 +7,7 @@ CONFIG_DRAM_EMR1=4
 CONFIG_USB0_VBUS_PIN="PB9"
 CON

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi,

Le mercredi 20 juin 2018 à 17:12 +0100, Andre Przywara a écrit :
> On 20/06/18 16:24, Paul Kocialkowski wrote:
> > Regarding the DDR firmware: I would like to start a discussion with NXP
> > and Synopsys about making the firmware free software/open source.
> 
> Don't want to temper your enthusiasm, but I believe this has been tried
> before - in vain. Hence my proposal to work around this. This is a
> common problem for many platforms: DDR training or initialisation code
> is not documented and/or provided as a closed source blob.
> I very much appreciate your push for FOSS code, but I guess this is
> where reality kicks in.

I somewhat share your analysis here and I am well aware of the general
issue (I remember not too long ago when nobody could say for sure
whether the Allwinner A64 platform would see free DRAM init code or not)
but I still feel like trying the political way first is the most
reasonable way to go.

And I am definitely not going to give up so easily for now :)

> There was and is quite some reverse engineering effort around this,
> though, and a lot of similarities have been found between the DDR
> controllers in different platforms, for instance between Rockchip and
> Allwinner. I believe it would be worthwhile to go over what we have in
> U-Boot and try to unify this. AFAIK many vendors use Synopsis IP, but
> don't necessarily say so. This might lead to some insight about the
> controllers used in i.MX as well.

Indeed, that is another not-so-painful way to go towards resolving this
problem. And it also helps with the political way, since it seems that
code covering these DRAM controllers' innards tends to come out sooner
or later. So what's the point in Synopsys keeping it a secret?

And even if the code can't be released as-is, I'm sure that
documentation that would allow writing a feature-equivalent firmware
could be released without too much trouble involving lawyers.

Heck, it could even be released under NDA and a company could be
mandated to write such a clean firmware!

> > Would you be able to tell me who to contact about this (probably a
> > manager on the NXP DDR team to begin with)? Feel free to answer off-list 
> > if contact information cannot be shared publicly. 
> 
> Good luck with that, but don't be disappointed ...

To be honest, I would mostly feel disappointed for not trying!

Cheers,

Paul

> > > > About that DDR PHY firmware: to what extent is it necessary? It is
> > > > common that DDR link training is required for socketed DRAM chips, but
> > > > properly-tuned static per-board configuration is usually enough for
> > > > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > > > it be possible to provide such a static configuration mode, that does
> > > > not involved any firmware for link training?
> > > 
> > > The DDR PHY firmware is not per board. It is required.
> > > 
> > > There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could 
> > > generated
> > > the script like what this patch contains regarding the ddr part. But the 
> > > DDR
> > > PHY firmware is a must, the DDR PHY firmware will be loaded to a place
> > > saying IMEM/DMEM inside DDR PHY.
> > 
> > Okay, so if I understand correctly, we there is already static
> > configuration. Do you know the role of the DDR PHY in details?
> > 
> > It is very unclear to me why the firmware is required. If you do not
> > have the details, could you direct me to someone who knows such details?
> > 
> > > > Perhaps the PHY link training code (with the firmware) could be kept
> > > > around as a fallback, disabled by default. Also, I see lots of
> > > > undocumented registers in the process. Does it seem feasable to document
> > > > these? This currently does not really like the source form of the
> > > > software.
> > > 
> > > There are lots lots of registers to configure, honestly, I also do not
> > > know the detailed meaning. The ddr code is from DDR team, hard
> > > for me to restructure. I suggest you use the DDR tool from NXP to
> > > generate the ddr code you need.
> > 
> > Well, this is a very borderline situation, where we can consider that
> > the register dumps are not really source code. I understand that you may
> > not have the necessary information here. Do you know who to contact to
> > solve this problem?
> > 
> > > > Having a firmware in the boot process is a fatal flaw when it comes to
> > > > software freedom, as it prevents having a fully free boot chain. Since
> > > > some projects (e.g. the Purism Librem

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi and thanks for your anwers!

On Wed, 2018-06-20 at 11:56 +, Peng Fan wrote:
> Hi Paul
> 
> > -Original Message-
> > From: Paul Kocialkowski [mailto:cont...@paulk.fr]
> > Sent: 2018年6月20日 16:58
> > To: Peng Fan ; sba...@denx.de; Fabio Estevam
> > 
> > Cc: u-boot@lists.denx.de; andre.przyw...@arm.com; Todd Weaver
> > ; Nicole Faerber 
> > Subject: Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support
> > 
> > Hi there,
> > 
> > On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> > > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > > DRAM.
> > 
> > First off, I'd like to express my gratitude for this port: the i.MX8
> > looks like a great platform and it's really nice to see support for it
> > land in U-Boot!
> > 
> > Regarding the integration of i.MX8 with upstream software in general:
> > are there plans to upstream the ARM Trusted Firmware port for i.MX8?
> 
> There are i.MX8 i.MX8X i.MX8M product lines for now. This patchset
> is upstream i.MX8MQ in i.MX8M family.
> 
> The i.MX8QM in i.MX8 and i.MX8QXP in i.MX8X has been upstreamed to
> ATF recently. The i.MX8MQ support will be soon sent to ATF, I think.

Okay, thanks for the clarification, this is good to know :)

> > It would be great to have both U-Boot and ATF upstream support to
> > achieve a boot chain with (mostly-)free and upstream software.
> > 
> > On that note, are there proprietary components involved in the boot
> > process, other than the already-identified DDR training firmware for the
> > DDR PHY?
> 
> The DDR firmware is not opensource, also there is HDMI firmware.
> U-Boot will load DDR PHY firmware and initialize DDR controller.

Oh, I didn't know about the HDMI firmware.

Regarding the DDR firmware: I would like to start a discussion with NXP
and Synopsys about making the firmware free software/open source.

Would you be able to tell me who to contact about this (probably a
manager on the NXP DDR team to begin with)? Feel free to answer off-list 
if contact information cannot be shared publicly. 

> > About that DDR PHY firmware: to what extent is it necessary? It is
> > common that DDR link training is required for socketed DRAM chips, but
> > properly-tuned static per-board configuration is usually enough for
> > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > it be possible to provide such a static configuration mode, that does
> > not involved any firmware for link training?
> 
> The DDR PHY firmware is not per board. It is required.
> 
> There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could 
> generated
> the script like what this patch contains regarding the ddr part. But the DDR
> PHY firmware is a must, the DDR PHY firmware will be loaded to a place
> saying IMEM/DMEM inside DDR PHY.

Okay, so if I understand correctly, we there is already static
configuration. Do you know the role of the DDR PHY in details?

It is very unclear to me why the firmware is required. If you do not
have the details, could you direct me to someone who knows such details?

> > Perhaps the PHY link training code (with the firmware) could be kept
> > around as a fallback, disabled by default. Also, I see lots of
> > undocumented registers in the process. Does it seem feasable to document
> > these? This currently does not really like the source form of the
> > software.
> 
> There are lots lots of registers to configure, honestly, I also do not
> know the detailed meaning. The ddr code is from DDR team, hard
> for me to restructure. I suggest you use the DDR tool from NXP to
> generate the ddr code you need.

Well, this is a very borderline situation, where we can consider that
the register dumps are not really source code. I understand that you may
not have the necessary information here. Do you know who to contact to
solve this problem?

> > Having a firmware in the boot process is a fatal flaw when it comes to
> > software freedom, as it prevents having a fully free boot chain. Since
> > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > for this precise reason, this is a serious (if not fatal) drawback.
> 
> The DDR PHY firmware runs inside DDR PHY, it is only DDR TYPE specific,
> such as DDR4 and LPDDR4 use different DDR PHY firmware.

I see, that makes sense.

> If different boards use LPDDR4, they could use same firmware.
> 
> > 
> > Moreover, it is really not convenient to have a non-free firmware that
> > must be carried around with U-Boot and prevents user from just cloning
> > u-boot, build

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

On Wed, 2018-06-20 at 13:54 +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Wed, 2018-06-20 at 12:37 +0100, Andre Przywara wrote:
> > (resending trimmed version to pass the U-Boot size limit filter ...)
> > 
> > Hi,
> > 
> > On 20/06/18 09:57, Paul Kocialkowski wrote:
> > > Hi there,
> > > 
> > > On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> > > > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > > > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > > > DRAM.
> > > 
> > > First off, I'd like to express my gratitude for this port: the i.MX8
> > > looks like a great platform and it's really nice to see support for it
> > > land in U-Boot!
> > > 
> > > Regarding the integration of i.MX8 with upstream software in general:
> > > are there plans to upstream the ARM Trusted Firmware port for i.MX8?
> > > It would be great to have both U-Boot and ATF upstream support to
> > > achieve a boot chain with (mostly-)free and upstream software.
> > 
> > The support for i.MX8QX and i.MX8QM has been merged into the official
> > ATF repo yesterday:
> > https://github.com/ARM-software/arm-trusted-firmware/pull/1410
> > 
> > I am bit lost in the naming here (i.MX8QM vs i.MX8MQ), but I think that
> > should answer your question.
> 
> Great to hear and great work! I must admit, I did not even check ATF
> sources when writing the email from this morning, as it seemed too early
> anyway.
> 
> I'm definitely glad I was wrong :)
> 
> > > On that note, are there proprietary components involved in the boot
> > > process, other than the already-identified DDR training firmware for the
> > > DDR PHY?
> > > 
> > > About that DDR PHY firmware: to what extent is it necessary? It is
> > > common that DDR link training is required for socketed DRAM chips, but
> > > properly-tuned static per-board configuration is usually enough for
> > > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > > it be possible to provide such a static configuration mode, that does
> > > not involved any firmware for link training?
> > 
> > I agree on not wanting a blob for that, although that depends a bit on
> > what it does: If it's an not-signed binary, that just does the training
> > and then goes out of the way, and shipping the binary is reasonably
> > licensed, then it might be beneficial to have it, at least for now.
> 
> Well, that covers some use cases, but definitely does not help with
> software freedom issues, that can only be solved by either avoiding or
> liberating that blob. Even following the RYF approach that Purism is
> considering[0] (moving DDR calibration to a coprocessor) does not help
> at all with freedom issues and is merely an "exception" that the FSF's
> RYF certification allows.
> 
> I did not mention it, but perhaps NXP is in a positon to ask Designware
> to free that blob altogether (which would definitely solve the issue at
> hand here)?

I meant Synopsys (the company), not Designware (the line of products)
here.

> > AFAIK actual DRAM training for a wide range of chips is not trivial, so
> > there is probably some value in that blob.
> > For specific boards with soldered chips: can't we dump the results of
> > the training and use that for a static configuration? It is my
> > understanding that the DRAM controller parameters depend on actual
> > voltage and also temperature, but we might get some good enough values
> > for a reasonable range of both? This would make this blob optional then,
> > and people could decide for their own.
> 
> This is also my understanding and I would totally be satisfied with this
> approach, as I mentioned earlier.
> 
> Thanks for the reply!
> 
> Paul
> 
> [0]: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/
> 
> > Cheers,
> > Andre.
> > 
> > > Perhaps the PHY link training code (with the firmware) could be kept
> > > around as a fallback, disabled by default. Also, I see lots of
> > > undocumented registers in the process. Does it seem feasable to document
> > > these? This currently does not really like the source form of the
> > > software.
> > > 
> > > Having a firmware in the boot process is a fatal flaw when it comes to
> > > software freedom, as it prevents having a fully free boot chain. Since
> > > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > > for this precise reason, this is a serious (if n

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi,

On Wed, 2018-06-20 at 12:37 +0100, Andre Przywara wrote:
> (resending trimmed version to pass the U-Boot size limit filter ...)
> 
> Hi,
> 
> On 20/06/18 09:57, Paul Kocialkowski wrote:
> > Hi there,
> > 
> > On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> > > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > > DRAM.
> > 
> > First off, I'd like to express my gratitude for this port: the i.MX8
> > looks like a great platform and it's really nice to see support for it
> > land in U-Boot!
> > 
> > Regarding the integration of i.MX8 with upstream software in general:
> > are there plans to upstream the ARM Trusted Firmware port for i.MX8?
> > It would be great to have both U-Boot and ATF upstream support to
> > achieve a boot chain with (mostly-)free and upstream software.
> 
> The support for i.MX8QX and i.MX8QM has been merged into the official
> ATF repo yesterday:
> https://github.com/ARM-software/arm-trusted-firmware/pull/1410
> 
> I am bit lost in the naming here (i.MX8QM vs i.MX8MQ), but I think that
> should answer your question.

Great to hear and great work! I must admit, I did not even check ATF
sources when writing the email from this morning, as it seemed too early
anyway.

I'm definitely glad I was wrong :)

> > On that note, are there proprietary components involved in the boot
> > process, other than the already-identified DDR training firmware for the
> > DDR PHY?
> > 
> > About that DDR PHY firmware: to what extent is it necessary? It is
> > common that DDR link training is required for socketed DRAM chips, but
> > properly-tuned static per-board configuration is usually enough for
> > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > it be possible to provide such a static configuration mode, that does
> > not involved any firmware for link training?
> 
> I agree on not wanting a blob for that, although that depends a bit on
> what it does: If it's an not-signed binary, that just does the training
> and then goes out of the way, and shipping the binary is reasonably
> licensed, then it might be beneficial to have it, at least for now.

Well, that covers some use cases, but definitely does not help with
software freedom issues, that can only be solved by either avoiding or
liberating that blob. Even following the RYF approach that Purism is
considering[0] (moving DDR calibration to a coprocessor) does not help
at all with freedom issues and is merely an "exception" that the FSF's
RYF certification allows.

I did not mention it, but perhaps NXP is in a positon to ask Designware
to free that blob altogether (which would definitely solve the issue at
hand here)?

> AFAIK actual DRAM training for a wide range of chips is not trivial, so
> there is probably some value in that blob.
> For specific boards with soldered chips: can't we dump the results of
> the training and use that for a static configuration? It is my
> understanding that the DRAM controller parameters depend on actual
> voltage and also temperature, but we might get some good enough values
> for a reasonable range of both? This would make this blob optional then,
> and people could decide for their own.

This is also my understanding and I would totally be satisfied with this
approach, as I mentioned earlier.

Thanks for the reply!

Paul

[0]: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/

> Cheers,
> Andre.
> 
> > Perhaps the PHY link training code (with the firmware) could be kept
> > around as a fallback, disabled by default. Also, I see lots of
> > undocumented registers in the process. Does it seem feasable to document
> > these? This currently does not really like the source form of the
> > software.
> > 
> > Having a firmware in the boot process is a fatal flaw when it comes to
> > software freedom, as it prevents having a fully free boot chain. Since
> > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > for this precise reason, this is a serious (if not fatal) drawback.
> > 
> > Moreover, it is really not convenient to have a non-free firmware that
> > must be carried around with U-Boot and prevents user from just cloning
> > u-boot, building and running (by adding an extra step that complicates
> > the process and makes it different from other platforms that do not
> > require such a blob).
> > 
> > Thanks in advance for your time and consideration of these questions!
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > The boot log with Arm trusted firmware console en

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi there,

On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> DRAM.

First off, I'd like to express my gratitude for this port: the i.MX8
looks like a great platform and it's really nice to see support for it
land in U-Boot!

Regarding the integration of i.MX8 with upstream software in general:
are there plans to upstream the ARM Trusted Firmware port for i.MX8?
It would be great to have both U-Boot and ATF upstream support to
achieve a boot chain with (mostly-)free and upstream software.

On that note, are there proprietary components involved in the boot
process, other than the already-identified DDR training firmware for the
DDR PHY?

About that DDR PHY firmware: to what extent is it necessary? It is
common that DDR link training is required for socketed DRAM chips, but
properly-tuned static per-board configuration is usually enough for
soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
it be possible to provide such a static configuration mode, that does
not involved any firmware for link training?

Perhaps the PHY link training code (with the firmware) could be kept
around as a fallback, disabled by default. Also, I see lots of
undocumented registers in the process. Does it seem feasable to document
these? This currently does not really like the source form of the
software.

Having a firmware in the boot process is a fatal flaw when it comes to
software freedom, as it prevents having a fully free boot chain. Since
some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
for this precise reason, this is a serious (if not fatal) drawback.

Moreover, it is really not convenient to have a non-free firmware that
must be carried around with U-Boot and prevents user from just cloning
u-boot, building and running (by adding an extra step that complicates
the process and makes it different from other platforms that do not
require such a blob).

Thanks in advance for your time and consideration of these questions!

Cheers,

Paul

> The boot log with Arm trusted firmware console enabled:
> "
> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
> PMIC:  PFUZE100 ID=0x10
> Normal Boot
> Trying to boot from MMC2
> NOTICE:  Configureing TZASC380
> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
> NOTICE:  sip svc init
> 
> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
> 
> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
> Reset cause: POR
> Model: Freescale i.MX8MQ EVK
> DRAM:  3 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> u-boot=>
> "
> 
> Signed-off-by: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/Makefile|2 +
>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>  board/freescale/mx8mq_evk/Kconfig|   12 +
>  board/freescale/mx8mq_evk/Makefile   |   12 +
>  board/freescale/mx8mq_evk/README |   47 +
>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
> ++
>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>  board/freescale/mx8mq_evk/spl.c  |  230 +
>  configs/mx8mq_evk_defconfig  |   27 +
>  include/configs/mx8mq_evk.h  |  269 ++
>  14 files changed, 2819 insertions(+)
>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>  create mode 100644 board/freescale/mx8mq_evk/README
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>  create mode 100644 configs/mx8mq_evk_defconfig
>  create mode 100644 include/configs/mx8mq_evk.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a895c70284..299107977f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>  
>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>  
> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
> +
>  dtb-$(CONFIG_RCAR_GEN3) += \
>   r8a7795-h3ulcb.dtb \
>   r8a7795-salvator-x.dtb \
> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts b/arch/arm/dts/fsl-imx8mq-evk.dts
> new file 

Re: [U-Boot] [PATCH] configs: Lower Lamobo R1 DRAM clock rate to 384 MHz

[Paul Kocialkowski]

Hi,

On Mon, 2018-06-18 at 09:59 +0200, Maxime Ripard wrote:
> On Fri, Jun 15, 2018 at 10:52:39PM +0200, Paul Kocialkowski wrote:
> > When running at 432 MHz, the Lamobo R1 DRAM tends to get corrupted under
> > stressing workloads. Reducing the clock rate to 384 MHz results in
> > significantly-improved stability.
> > 
> > One reliable way to trigger a corruption at 432 MHz is to run
> > I/O-intensive operations on an attached SATA disk. The same operations
> > when operating the DRAM at 384 MHz typically go fine.
> > 
> > For some unexplained reason, running at 408 MHz worsens the situation.
> > 
> > Signed-off-by: Paul Kocialkowski 
> 
> What RAM settings are used by the Allwinner BSP, and can you reproduce
> the issue there if they are the same?

I forgot to mention it, but the fex uses 432 MHz (just like the u-boot
defconfig we have currently). I doubt that building the Allwinner boot
software (boot0 and so on) for comparison is really an option at this
point, due to the trainwreck of build issues that may occur.

Would the linux-sunxi downstream u-boot be sufficient for this?

For the sake of completeness, I also looked whether enabling ODT for 432
MHz could be a solution, but since the fex does not make use of it (and
has the default Zq value of 0x7f), this is not an option.

Cheers,

Paul

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] configs: Lower Lamobo R1 DRAM clock rate to 384 MHz

[Paul Kocialkowski]

When running at 432 MHz, the Lamobo R1 DRAM tends to get corrupted under
stressing workloads. Reducing the clock rate to 384 MHz results in
significantly-improved stability.

One reliable way to trigger a corruption at 432 MHz is to run
I/O-intensive operations on an attached SATA disk. The same operations
when operating the DRAM at 384 MHz typically go fine.

For some unexplained reason, running at 408 MHz worsens the situation.

Signed-off-by: Paul Kocialkowski 
---
 configs/Lamobo_R1_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 92e682128c..cf60fdfaf4 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SYS_TEXT_BASE=0x4a00
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=432
+CONFIG_DRAM_CLK=384
 CONFIG_MACPWR="PH23"
 CONFIG_MMC0_CD_PIN="PH10"
 CONFIG_SATAPWR="PB3"
-- 
2.17.1

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

Re: [U-Boot] [PATCH 1/3] arm: dts: sun7i: Update Ainol AW1 dts

[Paul Kocialkowski]

Hi,

On Mon, 2018-03-26 at 13:09 +0200, Maxime Ripard wrote:
> Hi,
> 
> On Sun, Mar 25, 2018 at 02:35:59PM +0200, Paul Kocialkowski wrote:
> > This introduces a newer dts for the Ainol AW1, that will be the base
> > for
> > introducing upstream Linux support for the device.
> > 
> > This update in U-Boot allows fixing USB OTG detection, that was
> > missing
> > from the previous dts.
> > 
> > Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
> 
> We usually will use the Linux DTS once it's been merged, so please
> send it there first.

Sure thing!

[...]

> Your nodes should be ordered by alphabetical order (at least as much
> as possible, this isn't really doable for all the AXP stuff).

I tried to preserve the order from the sun7i-a20.dtsi file, which felt
like the most straightforward thing to do.

Is there any particlar reason why things should be sorted
alphabetically? It feels like it has the potential to explode related
blocs in different areas of the file, thus reducing readability (like
you've mentioned for the AXP).

> > + {
> > +   backlight_enable_pin: backlight_enable_pin@0 {
> > +   pins = "PH7";
> > +   function = "gpio_out";
> > +   };
> > +
> > +   usb0_id_detect_pin: usb0_id_detect_pin@0 {
> > +   pins = "PH4";
> > +   function = "gpio_in";
> > +   bias-pull-up;
> > +   };
> > +
> > +   usb0_vbus_pin: usb0_vbus_pin@0 {
> > +   pins = "PB9";
> > +   function = "gpio_out";
> > +   };
> > +};
> 
> We're trying to remove these nodes from our DTs, it's redundant since
> the GPIOs will request the pin in pinctrl when being taken.
> 
> > +
> > + {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins_a>;
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   vref-supply = <_vcc3v0>;
> > +   status = "okay";
> > +
> > +   button@571 {
> > +   label = "Volume Up";
> > +   linux,code = ;
> > +   channel = <0>;
> > +   voltage = <571428>;
> > +   };
> > +
> > +   button@761 {
> > +   label = "Volume Down";
> > +   linux,code = ;
> > +   channel = <0>;
> > +   voltage = <761904>;
> > +   };
> > +
> > +   button@952 {
> > +   label = "Home";
> > +   linux,code = ;
> > +   channel = <0>;
> > +   voltage = <952380>;
> > +   };
> >  };
> >  
> >   {
> > @@ -27,3 +177,60 @@
> > pinctrl-0 = <_pins_a>;
> > status = "okay";
> >  };
> > +
> > + {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins_a>;
> > +   status = "okay";
> > +
> > +   axp209: pmic@34 {
> > +   reg = <0x34>;
> > +   interrupt-parent = <_intc>;
> > +   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > +   };
> > +};
> > +
> > +#include "axp209.dtsi"
> > +
> > +_dcdc2 {
> > +   regulator-always-on;
> > +   regulator-min-microvolt = <100>;
> > +   regulator-max-microvolt = <145>;
> > +   regulator-name = "vdd-cpu";
> > +};
> > +
> > +_dcdc3 {
> > +   regulator-always-on;
> > +   regulator-min-microvolt = <100>;
> > +   regulator-max-microvolt = <140>;
> > +   regulator-name = "vdd-int-dll";
> > +};
> > +
> > +_ldo1 {
> > +   regulator-name = "vdd-rtc";
> > +};
> > +
> > +_ldo2 {
> > +   regulator-always-on;
> > +   regulator-min-microvolt = <300>;
> > +   regulator-max-microvolt = <300>;
> > +   regulator-name = "avcc";
> > +};
> > +
> > +_usb0_vbus {
> > +   pinctrl-0 = <_vbus_pin>;
> > +   gpio = < 1 9 GPIO_ACTIVE_HIGH>; /*PB9 */
> > +   status = "okay";
> > +};
> > +
> > +_usb1_vbus {
> > +   status = "okay";
> > +};
> > +
> > +_usb2_vbus {
> > +   status = "okay";
> > +};
> > +
> > +_power_supply {
> > +   status = "okay";
> > +};
> > -- 
> > 2.16.2
> > 
> 
> 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] sunxi: Add extra I2C bus support to Ainol AW1 defconfig

[Paul Kocialkowski]

Hi,

On Mon, 2018-03-26 at 13:10 +0200, Maxime Ripard wrote:
> On Sun, Mar 25, 2018 at 02:36:01PM +0200, Paul Kocialkowski wrote:
> > I2C bus 1 is used for the accelerometer and i2c bus 2 for the
> > touchscreen of the device. While these are not supported in U-Boot,
> > its
> > command line can be used to access these peripherals.
> > 
> > Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
> 
> I'm not sure what the use case would be for U-Boot though. I guess you
> can always enable it through menuconfig if you really want it, but
> there's no real need for it in the default configuration.

Fair enough, I'll drop this patch.

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/3] sunxi: Add extra I2C bus support to Ainol AW1 defconfig

[Paul Kocialkowski]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  I2C bus 1 is used for the accelerometer and i2c bus 2 for
  the touchscreen of the device. While these are not supported in U-Boot, its
   command line can be used to access these peripherals. Signed-off-by: Paul
   Kocialkowski <cont...@paulk.fr> --- configs/Ainol_AW1_defconfig | 2 ++ 1
  file changed, 2 insertions(+) [...] 

Content analysis details:   (5.2 points, 5.0 required)

 pts rule name  description
 -- --
 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL,
https://senderscore.org/blacklistlookup/
   [77.128.107.220 listed in bl.score.senderscore.com]
 0.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP address
[77.128.107.220 listed in dnsbl.sorbs.net]
 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL
[77.128.107.220 listed in zen.spamhaus.org]
 0.4 RDNS_DYNAMIC   Delivered to internal network by host with
dynamic-looking rDNS


--- Begin Message ---
I2C bus 1 is used for the accelerometer and i2c bus 2 for the
touchscreen of the device. While these are not supported in U-Boot, its
command line can be used to access these peripherals.

Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
---
 configs/Ainol_AW1_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/Ainol_AW1_defconfig b/configs/Ainol_AW1_defconfig
index 9fb464b703..87f14b0ea5 100644
--- a/configs/Ainol_AW1_defconfig
+++ b/configs/Ainol_AW1_defconfig
@@ -4,6 +4,8 @@ CONFIG_MACH_SUN7I=y
 CONFIG_DRAM_CLK=432
 CONFIG_DRAM_ZQ=123
 CONFIG_MMC0_CD_PIN="PH1"
+CONFIG_I2C1_ENABLE=y
+CONFIG_I2C2_ENABLE=y
 CONFIG_USB0_VBUS_PIN="PB9"
 CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT"
 CONFIG_USB0_ID_DET="PH4"
-- 
2.16.2

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

[U-Boot] [PATCH 2/3] sunxi: Add USB0 ID detection pin to Ainol AW1 defconfig

[Paul Kocialkowski]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  This adds the detection pin for the USB OTG port of the 
tablet.
   It allows properly detecting OTG cables and using connected devices when
  they are supported. Signed-off-by: Paul Kocialkowski <cont...@paulk.fr> ---
   configs/Ainol_AW1_defconfig | 1 + 1 file changed, 1 insertion(+) [...] 

Content analysis details:   (5.2 points, 5.0 required)

 pts rule name  description
 -- --
 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL,
https://senderscore.org/blacklistlookup/
   [77.128.107.220 listed in bl.score.senderscore.com]
 0.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP address
[77.128.107.220 listed in dnsbl.sorbs.net]
 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL
[77.128.107.220 listed in zen.spamhaus.org]
 0.4 RDNS_DYNAMIC   Delivered to internal network by host with
dynamic-looking rDNS


--- Begin Message ---
This adds the detection pin for the USB OTG port of the tablet.
It allows properly detecting OTG cables and using connected
devices when they are supported.

Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
---
 configs/Ainol_AW1_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/Ainol_AW1_defconfig b/configs/Ainol_AW1_defconfig
index e11e75d418..9fb464b703 100644
--- a/configs/Ainol_AW1_defconfig
+++ b/configs/Ainol_AW1_defconfig
@@ -6,6 +6,7 @@ CONFIG_DRAM_ZQ=123
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_USB0_VBUS_PIN="PB9"
 CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT"
+CONFIG_USB0_ID_DET="PH4"
 CONFIG_AXP_GPIO=y
 
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:4,le:87,ri:112,up:38,lo:141,hs:1,vs:1,sync:3,vmode:0"
 CONFIG_VIDEO_LCD_POWER="PH8"
-- 
2.16.2

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

[U-Boot] [PATCH 1/3] arm: dts: sun7i: Update Ainol AW1 dts

[Paul Kocialkowski]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  This introduces a newer dts for the Ainol AW1, that will be
   the base for introducing upstream Linux support for the device. This update
   in U-Boot allows fixing USB OTG detection, that was missing from the previous
   dts. [...] 

Content analysis details:   (5.2 points, 5.0 required)

 pts rule name  description
 -- --
 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL
[77.128.107.220 listed in zen.spamhaus.org]
 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL,
https://senderscore.org/blacklistlookup/
   [77.128.107.220 listed in bl.score.senderscore.com]
 0.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP address
[77.128.107.220 listed in dnsbl.sorbs.net]
 0.4 RDNS_DYNAMIC   Delivered to internal network by host with
dynamic-looking rDNS


--- Begin Message ---
This introduces a newer dts for the Ainol AW1, that will be the base for
introducing upstream Linux support for the device.

This update in U-Boot allows fixing USB OTG detection, that was missing
from the previous dts.

Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
---
 arch/arm/dts/sun7i-a20-ainol-aw1.dts | 215 ++-
 1 file changed, 211 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/sun7i-a20-ainol-aw1.dts 
b/arch/arm/dts/sun7i-a20-ainol-aw1.dts
index 8b730cdfae..f62d67d6d6 100644
--- a/arch/arm/dts/sun7i-a20-ainol-aw1.dts
+++ b/arch/arm/dts/sun7i-a20-ainol-aw1.dts
@@ -1,17 +1,57 @@
 /*
- * Copyright 2015 Hans de Goede <hdego...@redhat.com>
+ * Copyright 2018 Paul Kocialkowski <cont...@paulk.fr>
  *
- * Minimal dts file for the Ainol AW1 for u-boot only
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
  *
- * SPDX-License-Identifier: GPL-2.0+ or X11
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 /dts-v1/;
 #include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+#include 
 
 / {
model = "Ainol AW1";
-   compatible = "ainol,aw1", "allwinner,sun7i-a20";
+   compatible = "ainol,ainol-aw1", "allwinner,sun7i-a20";
 
aliases {
serial0 = 
@@ -20,6 +60,116 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_enable_pin>;
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+

Re: [U-Boot] [PATCH] libfdt: move headers to and

[Paul Kocialkowski]

Hi,

On Mon, 2018-03-05 at 01:20 +0900, Masahiro Yamada wrote:
> Thomas reported U-Boot failed to build host tools if libfdt-devel
> package is installed because tools include libfdt headers from
> /usr/include/ instead of using internal ones.

Sorry for being late to the party here, but isn't this issue fixed by
the patch I sent a few days ago "tools: Include U-Boot libfdt headers
from their actual path": https://patchwork.ozlabs.org/patch/880924/ ?

I doubt we need to keep both changes here. What do you think?

> This commit moves the header code:
>   include/libfdt.h -> include/linux/libfdt.h
>   include/libfdt_env.h -> include/linux/libfdt_env.h
> 
> and replaces include directives:
>   #include   -> #include 
>   #include   -> #include 
> 
> Reported-by: Thomas Petazzoni 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/arm/cpu/armv7/ls102xa/fdt.c  |   2 +-
>  arch/arm/cpu/armv7/virt-dt.c  |   2 +-
>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c   |   2 +-
>  arch/arm/cpu/armv8/spin_table.c   |   2 +-
>  arch/arm/lib/bootm.c  |   2 +-
>  arch/arm/lib/psci-dt.c|   2 +-
>  arch/arm/mach-imx/mx6/litesom.c   |   2 +-
>  arch/arm/mach-imx/mx6/opos6ul.c   |   2 +-
>  arch/arm/mach-meson/board.c   |   2 +-
>  arch/arm/mach-mvebu/arm64-common.c|   2 +-
>  arch/arm/mach-mvebu/armada3700/cpu.c  |   2 +-
>  arch/arm/mach-mvebu/armada8k/cpu.c|   2 +-
>  arch/arm/mach-omap2/am33xx/fdt.c  |   2 +-
>  arch/arm/mach-omap2/fdt-common.c  |   2 +-
>  arch/arm/mach-omap2/omap5/fdt.c   |   2 +-
>  arch/arm/mach-socfpga/misc.c  |   2 +-
>  arch/arm/mach-socfpga/misc_gen5.c |   2 +-
>  arch/arm/mach-uniphier/board_late_init.c  |   2 +-
>  arch/arm/mach-uniphier/boards.c   |   2 +-
>  arch/powerpc/cpu/mpc83xx/cpu.c|   2 +-
>  arch/powerpc/cpu/mpc83xx/fdt.c|   2 +-
>  arch/powerpc/cpu/mpc83xx/pci.c|   2 +-
>  arch/powerpc/cpu/mpc85xx/fdt.c|   2 +-
>  arch/powerpc/cpu/mpc85xx/liodn.c  |   2 +-
>  arch/powerpc/cpu/mpc85xx/portals.c|   2 +-
>  arch/powerpc/cpu/mpc86xx/fdt.c|   2 +-
>  arch/powerpc/cpu/mpc8xx/cpu.c |   2 +-
>  arch/powerpc/cpu/mpc8xx/fdt.c |   2 +-
>  arch/powerpc/cpu/mpc8xxx/fdt.c|   2 +-
>  arch/powerpc/lib/bootm.c  |   2 +-
>  arch/sandbox/cpu/cpu.c|   2 +-
>  arch/x86/cpu/intel_common/microcode.c |   2 +-
>  board/Arcturus/ucp1020/ucp1020.c  |   2 +-
>  board/armltd/vexpress/vexpress_tc2.c  |   2 +-
>  board/congatec/cgtqmx6eval/cgtqmx6eval.c  |   2 +-
>  board/el/el6x/el6x.c  |   2 +-
>  board/esd/vme8349/vme8349.c   |   2 +-
>  board/freescale/b4860qds/pci.c|   2 +-
>  board/freescale/bsc9131rdb/bsc9131rdb.c   |   2 +-
>  board/freescale/bsc9132qds/bsc9132qds.c   |   2 +-
>  board/freescale/c29xpcie/c29xpcie.c   |   2 +-
>  board/freescale/common/cds_pci_ft.c   |   2 +-
>  board/freescale/common/fman.c |   4 +-
>  board/freescale/common/p_corenet/pci.c|   2 +-
>  board/freescale/common/sgmii_riser.c  |   2 +-
>  board/freescale/ls1043aqds/eth.c  |   2 +-
>  board/freescale/ls1088a/ls1088a.c |   2 +-
>  board/freescale/ls2080a/ls2080a.c |   2 +-
>  board/freescale/ls2080aqds/ls2080aqds.c   |   2 +-
>  board/freescale/ls2080ardb/ls2080ardb.c   |   2 +-
>  board/freescale/mpc8308rdb/mpc8308rdb.c   |   2 +-
>  board/freescale/mpc8313erdb/mpc8313erdb.c |   2 +-
>  board/freescale/mpc8315erdb/mpc8315erdb.c |   2 +-
>  board/freescale/mpc8323erdb/mpc8323erdb.c |   2 +-
>  board/freescale/mpc832xemds/mpc832xemds.c |   2 +-
>  board/freescale/mpc8349emds/mpc8349emds.c |   2 +-
>  board/freescale/mpc8349itx/mpc8349itx.c   |   2 +-
>  board/freescale/mpc837xemds/mpc837xemds.c |   2 +-
>  board/freescale/mpc8536ds/mpc8536ds.c |   2 +-
>  board/freescale/mpc8541cds/mpc8541cds.c   |   2 +-
>  board/freescale/mpc8544ds/mpc8544ds.c |   2 +-
>  board/freescale/mpc8548cds/mpc8548cds.c   |   2 +-
>  board/freescale/mpc8555cds/mpc8555cds.c   |   2 +-
>  board/freescale/mpc8568mds/mpc8568mds.c   |   2 +-
>  board/freescale/mpc8569mds/mpc8569mds.c   |   2 +-
>  board/freescale/mpc8572ds/mpc8572ds.c |   2 

[U-Boot] [PATCH] tools: Include U-Boot libfdt headers from their actual path

[Paul Kocialkowski]

There are no headers for libfdt in lib/libfdt, as they are instead
located in scripts/dtc/libfdt. Specifying lib/libfdt for headers
inclusion in host tools results in using the system libfdt headers,
which is not what we want. Change this to the proper path.

Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index d3387fad69..f38f68ee47 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -244,7 +244,7 @@ endif # !LOGO_BMP
 #
 HOST_EXTRACFLAGS += -include $(srctree)/include/compiler.h \
$(patsubst -I%,-idirafter%, $(filter -I%, $(UBOOTINCLUDE))) \
-   -I$(srctree)/lib/libfdt \
+   -I$(srctree)/scripts/dtc/libfdt \
-I$(srctree)/tools \
-DUSE_HOSTCC \
-D__KERNEL_STRICT_NAMES \
-- 
2.16.2

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

Re: [U-Boot] [PATCH] Convert CONFIG_SYS_OMAP24_I2C_SLAVE et al to Kconfig

[Paul Kocialkowski]

Hi,

Le mercredi 24 janvier 2018 à 15:21 -0600, Adam Ford a écrit :
> This converts the following to Kconfig:
>CONFIG_SYS_OMAP24_I2C_SLAVE
>CONFIG_SYS_OMAP24_I2C_SPEED

Thanks again for working on Kconfig'ing OMAP support, it is greatly
appreciated!

Reviewed-by: Paul Kocialkowski <cont...@paulk.fr>

> Signed-off-by: Adam Ford <aford...@gmail.com>
> ---
>  configs/am335x_baltos_defconfig|  1 +
>  configs/cm_t3517_defconfig |  1 +
>  configs/eco5pk_defconfig   |  1 +
>  configs/kc1_defconfig  |  1 +
>  configs/mt_ventoux_defconfig   |  1 +
>  configs/sniper_defconfig   |  1 +
>  configs/twister_defconfig  |  1 +
>  drivers/i2c/Kconfig| 14 ++
>  include/configs/am3517_crane.h |  2 --
>  include/configs/am3517_evm.h   |  2 --
>  include/configs/baltos.h   |  2 --
>  include/configs/bur_am335x_common.h|  2 --
>  include/configs/cm_t35.h   |  2 --
>  include/configs/cm_t3517.h |  2 --
>  include/configs/kc1.h  |  2 --
>  include/configs/mcx.h  |  2 --
>  include/configs/nokia_rx51.h   |  2 --
>  include/configs/siemens-am33x-common.h |  2 --
>  include/configs/sniper.h   |  2 --
>  include/configs/tam3517-common.h   |  2 --
>  include/configs/tao3530.h  |  2 --
>  include/configs/ti_armv7_omap.h|  2 --
>  include/configs/tricorder.h|  2 --
>  scripts/config_whitelist.txt   |  2 --
>  24 files changed, 21 insertions(+), 32 deletions(-)
> 
> diff --git a/configs/am335x_baltos_defconfig
> b/configs/am335x_baltos_defconfig
> index 19ea684..a9d5f68 100644
> --- a/configs/am335x_baltos_defconfig
> +++ b/configs/am335x_baltos_defconfig
> @@ -48,6 +48,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
>  CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-
> nand.0:128k(SPL),128k(SPL.backup1),128k(SPL.backup2),128k(SPL.backup3)
> ,1920k(u-boot),-(UBI)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ISO_PARTITION=y
> +CONFIG_SYS_OMAP24_I2C_SPEED=1000
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NAND=y
>  CONFIG_SPL_NAND_DRIVERS=y
> diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig
> index fa78bde..c1e1153 100644
> --- a/configs/cm_t3517_defconfig
> +++ b/configs/cm_t3517_defconfig
> @@ -31,6 +31,7 @@ CONFIG_CMD_MTDPARTS=y
>  CONFIG_MTDIDS_DEFAULT="nand0=nand"
>  CONFIG_MTDPARTS_DEFAULT="mtdparts=nand:512k(x-loader),1920k(u-
> boot),256k(u-boot-env),4m(kernel),-(fs)"
>  CONFIG_ENV_IS_IN_NAND=y
> +CONFIG_SYS_OMAP24_I2C_SPEED=40
>  CONFIG_LED_STATUS=y
>  CONFIG_LED_STATUS_GPIO=y
>  CONFIG_LED_STATUS0=y
> diff --git a/configs/eco5pk_defconfig b/configs/eco5pk_defconfig
> index dac6aac..d0d82e9 100644
> --- a/configs/eco5pk_defconfig
> +++ b/configs/eco5pk_defconfig
> @@ -27,6 +27,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
>  CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(xloader-
> nand),1024k(uboot-nand),256k(params-nand),5120k(kernel),-(ubifs)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_NAND=y
> +CONFIG_SYS_OMAP24_I2C_SPEED=40
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NAND=y
>  CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
> diff --git a/configs/kc1_defconfig b/configs/kc1_defconfig
> index eaf7112..b501dfe 100644
> --- a/configs/kc1_defconfig
> +++ b/configs/kc1_defconfig
> @@ -35,6 +35,7 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_ISO_PARTITION=y
>  CONFIG_EFI_PARTITION=y
> +CONFIG_SYS_OMAP24_I2C_SPEED=40
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_USB=y
> diff --git a/configs/mt_ventoux_defconfig
> b/configs/mt_ventoux_defconfig
> index fc184d7..e5df51d 100644
> --- a/configs/mt_ventoux_defconfig
> +++ b/configs/mt_ventoux_defconfig
> @@ -32,6 +32,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
>  CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1m(u-
> boot),256k(env1),256k(env2),8m(ubisystem),-(rootfs)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_NAND=y
> +CONFIG_SYS_OMAP24_I2C_SPEED=40
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NAND=y
>  CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
> diff --git a/configs/sniper_defconfig b/configs/sniper_defconfig
> index 0761698..d06dfd6 100644
> --- a/configs/sniper_defconfig
> +++ b/configs/sniper_defconfig
> @@ -36,6 +36,7 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_ISO_PARTITION=y
>  CONFIG_EFI_PARTITION=y
> +CONFIG_SYS_OMAP24_I2C_SPEED=40
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_USB=y
> diff --git a/configs/twister_defconfig b/configs/twister_defconfig
> index 34bd76

Re: [U-Boot] [PATCH] Convert CONFIG_TWL4030_USB et al to Kconfig

[Paul Kocialkowski]

e CONFIG_USB_DEVICE
> diff --git a/include/configs/omap3_beagle.h
> b/include/configs/omap3_beagle.h
> index f21a843..2fc81db 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -43,7 +43,6 @@
>  #define CONFIG_SYS_I2C_NOPROBES  {{0x0, 0x0}}
>  
>  /* USB */
> -#define CONFIG_TWL4030_USB   1
>  
>  /* USB EHCI */
>  
> diff --git a/include/configs/omap3_igep00x0.h
> b/include/configs/omap3_igep00x0.h
> index 9b815e0..4888176 100644
> --- a/include/configs/omap3_igep00x0.h
> +++ b/include/configs/omap3_igep00x0.h
> @@ -42,7 +42,6 @@
>  #define GPIO_IGEP00X0_REVISION_DETECTION 129
>  
>  /* USB */
> -#define CONFIG_TWL4030_USB   1
>  
>  /* USB device configuration */
>  #define CONFIG_USB_DEVICE1
> diff --git a/include/configs/omap3_logic.h
> b/include/configs/omap3_logic.h
> index a4b29f1..5445186 100644
> --- a/include/configs/omap3_logic.h
> +++ b/include/configs/omap3_logic.h
> @@ -55,7 +55,6 @@
>  /* USB */
>  
>  /* TWL4030 */
> -#define CONFIG_TWL4030_USB
>  
>  /* Board NAND Info. */
>  #ifdef CONFIG_NAND
> diff --git a/include/configs/omap3_zoom1.h
> b/include/configs/omap3_zoom1.h
> index e5e4bc4..653790e 100644
> --- a/include/configs/omap3_zoom1.h
> +++ b/include/configs/omap3_zoom1.h
> @@ -35,7 +35,6 @@
>   */
>  
>  /* USB */
> -#define CONFIG_TWL4030_USB   1
>  
>  /* USB device configuration */
>  #define CONFIG_USB_DEVICE1
> diff --git a/include/configs/rk3188_common.h
> b/include/configs/rk3188_common.h
> index 0cb0762..9ab5502 100644
> --- a/include/configs/rk3188_common.h
> +++ b/include/configs/rk3188_common.h
> @@ -58,7 +58,6 @@
>  
>  #ifndef CONFIG_SPL_BUILD
>  /* usb otg */
> -#define CONFIG_ROCKCHIP_USB2_PHY
>  
>  /* usb host support */
>  #define ENV_MEM_LAYOUT_SETTINGS \
> diff --git a/include/configs/rk3288_common.h
> b/include/configs/rk3288_common.h
> index e2f070f..c2bd378 100644
> --- a/include/configs/rk3288_common.h
> +++ b/include/configs/rk3288_common.h
> @@ -58,7 +58,6 @@
>  
>  #ifndef CONFIG_SPL_BUILD
>  /* usb otg */
> -#define CONFIG_ROCKCHIP_USB2_PHY
>  
>  /* usb mass storage */
>  #define CONFIG_USB_FUNCTION_MASS_STORAGE
> diff --git a/include/configs/sniper.h b/include/configs/sniper.h
> index 09b5a73..99bee4c 100644
> --- a/include/configs/sniper.h
> +++ b/include/configs/sniper.h
> @@ -113,8 +113,6 @@
>   * USB gadget
>   */
>  
> -#define CONFIG_TWL4030_USB
> -

Please remove the heading "USB gadget" as this change effectively leaves
the section empty.

>  /*
>   * Environment
>   */
> diff --git a/scripts/config_whitelist.txt
> b/scripts/config_whitelist.txt
> index fdf9e55..d12d0eb 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -1561,7 +1561,6 @@ CONFIG_OMAP_EHCI_PHY2_RESET_GPIO
>  CONFIG_OMAP_EHCI_PHY3_RESET_GPIO
>  CONFIG_OMAP_USB2PHY2_HOST
>  CONFIG_OMAP_USB3PHY1_HOST
> -CONFIG_OMAP_USB_PHY
>  CONFIG_ORIGEN
>  CONFIG_OS1_ENV_ADDR
>  CONFIG_OS2_ENV_ADDR
> @@ -1830,7 +1829,6 @@ CONFIG_RMSTP9_ENA
>  CONFIG_ROCKCHIP_CHIP_TAG
>  CONFIG_ROCKCHIP_MAX_INIT_SIZE
>  CONFIG_ROCKCHIP_SDHCI_MAX_FREQ
> -CONFIG_ROCKCHIP_USB2_PHY
>  CONFIG_ROM_STUBS
>  CONFIG_ROOTFS_OFFSET
>  CONFIG_ROOTPATH
> @@ -4814,7 +4812,6 @@ CONFIG_TUXX1
>  CONFIG_TWL4030_INPUT
>  CONFIG_TWL4030_KEYPAD
>  CONFIG_TWL4030_LED
> -CONFIG_TWL4030_USB
>  CONFIG_TWL6030_INPUT
>  CONFIG_TWL6030_POWER
>  CONFIG_TWR

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2] Convert CONFIG_USB_MUSB_OMAP2PLUS et al to Kconfig

[Paul Kocialkowski]

{{0x0, 0x0}}
>  
>  /* USB */
> -#define CONFIG_USB_MUSB_OMAP2PLUS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_TWL4030_USB   1
>  
>  /* USB EHCI */
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index 42f2153..0eefb84 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -77,8 +77,6 @@
>  
>  /* MUSB */
>  #define CONFIG_USB_OMAP3
> -#define CONFIG_USB_MUSB_OMAP2PLUS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  
>  /* USB EHCI */
>  #define CONFIG_SYS_USB_FAT_BOOT_PARTITION  1
> diff --git a/include/configs/omap3_logic.h
> b/include/configs/omap3_logic.h
> index b095814..1e4e42a 100644
> --- a/include/configs/omap3_logic.h
> +++ b/include/configs/omap3_logic.h
> @@ -55,8 +55,6 @@
>  #define CONFIG_SYS_I2C_EEPROM_ADDR   0x50/* EEPROM
> AT24C64  */
>  
>  /* USB */
> -#define CONFIG_USB_MUSB_OMAP2PLUS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  
>  /* TWL4030 */
>  #define CONFIG_TWL4030_USB
> diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
> index 79f3f48..c6ff1e1 100644
> --- a/include/configs/pcm051.h
> +++ b/include/configs/pcm051.h
> @@ -126,8 +126,6 @@
>  /*
>   * USB configuration
>   */
> -#define CONFIG_USB_MUSB_DSPS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_AM335X_USB0
>  #define CONFIG_AM335X_USB0_MODE  MUSB_PERIPHERAL
>  #define CONFIG_AM335X_USB1
> diff --git a/include/configs/pengwyn.h b/include/configs/pengwyn.h
> index 8afd64e..d9a50ca 100644
> --- a/include/configs/pengwyn.h
> +++ b/include/configs/pengwyn.h
> @@ -162,8 +162,6 @@
>   * board schematic and physical port wired to each.  Then for host we
>   * add mass storage support.
>   */
> -#define CONFIG_USB_MUSB_DSPS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
>  #define CONFIG_AM335X_USB0
>  #define CONFIG_AM335X_USB0_MODE  MUSB_PERIPHERAL
> diff --git a/include/configs/pic32mzdask.h
> b/include/configs/pic32mzdask.h
> index 97636fe..0bb5126 100644
> --- a/include/configs/pic32mzdask.h
> +++ b/include/configs/pic32mzdask.h
> @@ -80,7 +80,6 @@
>  /*--
>   * USB Configuration
>   */
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  
>  /*---
> 
>   * File System Configuration
> diff --git a/include/configs/siemens-am33x-common.h
> b/include/configs/siemens-am33x-common.h
> index 78708a2..85b6412 100644
> --- a/include/configs/siemens-am33x-common.h
> +++ b/include/configs/siemens-am33x-common.h
> @@ -168,8 +168,6 @@
>  /*
>   * USB configuration
>   */
> -#define CONFIG_USB_MUSB_DSPS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
>  
>  #define CONFIG_AM335X_USB0
> diff --git a/include/configs/sniper.h b/include/configs/sniper.h
> index 5809942..09b5a73 100644
> --- a/include/configs/sniper.h
> +++ b/include/configs/sniper.h
> @@ -113,8 +113,6 @@
>   * USB gadget
>   */
>  
> -#define CONFIG_USB_MUSB_PIO_ONLY
> -#define CONFIG_USB_MUSB_OMAP2PLUS
>  #define CONFIG_TWL4030_USB
>  
>  /*
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-
> common.h
> index 3855c56..582aba2 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -302,10 +302,6 @@ extern int soft_i2c_gpio_scl;
>  #define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1
>  #endif
>  
> -#ifdef CONFIG_USB_MUSB_SUNXI
> -#define CONFIG_USB_MUSB_PIO_ONLY
> -#endif
> -
>  #ifdef CONFIG_USB_MUSB_GADGET
>  #define CONFIG_USB_FUNCTION_MASS_STORAGE
>  #endif
> diff --git a/scripts/config_whitelist.txt
> b/scripts/config_whitelist.txt
> index 43a4ff0..7ff11c5 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -4943,12 +4943,8 @@ CONFIG_USB_HOST_XHCI_BASE
>  CONFIG_USB_INVENTRA_DMA
>  CONFIG_USB_ISP1301_I2C_ADDR
>  CONFIG_USB_MAX_CONTROLLER_COUNT
> -CONFIG_USB_MUSB_AM35X
>  CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
> -CONFIG_USB_MUSB_DSPS
>  CONFIG_USB_MUSB_HCD
> -CONFIG_USB_MUSB_OMAP2PLUS
> -CONFIG_USB_MUSB_PIO_ONLY
>  CONFIG_USB_MUSB_TIMEOUT
>  CONFIG_USB_MUSB_TUSB6010
>  CONFIG_USB_MUSB_UDC
-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Convert CONFIG_USB_MUSB_OMAP2PLUS et al to Kconfig

[Paul Kocialkowski]

1.h
> @@ -81,7 +81,6 @@ BUR_COMMON_ENV \
>  
>  /* USB configuration */
>  #define CONFIG_USB_MUSB_DSPS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
>  #define CONFIG_AM335X_USB0
>  #define CONFIG_AM335X_USB0_MODE  MUSB_HOST
> diff --git a/include/configs/chiliboard.h
> b/include/configs/chiliboard.h
> index 92fd235..835b9dc 100644
> --- a/include/configs/chiliboard.h
> +++ b/include/configs/chiliboard.h
> @@ -154,7 +154,6 @@
>  /* USB configuration */
>  #define CONFIG_USB_MUSB_DSPS
>  #define CONFIG_ARCH_MISC_INIT
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
>  #define CONFIG_AM335X_USB1
>  #define CONFIG_AM335X_USB1_MODE MUSB_HOST
> diff --git a/include/configs/cm_t3517.h b/include/configs/cm_t3517.h
> index a472b9f..1737f88 100644
> --- a/include/configs/cm_t3517.h
> +++ b/include/configs/cm_t3517.h
> @@ -84,8 +84,6 @@
>  #define CONFIG_USB_OMAP3
>  #define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 146
>  #define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 147
> -#else /* !CONFIG_USB_MUSB_AM35X */
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #endif /* CONFIG_USB_MUSB_AM35X */
>  
>  /* commands to include */
> diff --git a/include/configs/kc1.h b/include/configs/kc1.h
> index 8d8dc26..94c3d0a 100644
> --- a/include/configs/kc1.h
> +++ b/include/configs/kc1.h
> @@ -115,9 +115,6 @@
>   * USB gadget
>   */
>  
> -#define CONFIG_USB_MUSB_PIO_ONLY
> -#define CONFIG_USB_MUSB_OMAP2PLUS
> -
>  /*
>   * Environment
>   */
> diff --git a/include/configs/omap3_beagle.h
> b/include/configs/omap3_beagle.h
> index 394bfb7..f21a843 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -43,8 +43,6 @@
>  #define CONFIG_SYS_I2C_NOPROBES  {{0x0, 0x0}}
>  
>  /* USB */
> -#define CONFIG_USB_MUSB_OMAP2PLUS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_TWL4030_USB   1
>  
>  /* USB EHCI */
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index 42f2153..0eefb84 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -77,8 +77,6 @@
>  
>  /* MUSB */
>  #define CONFIG_USB_OMAP3
> -#define CONFIG_USB_MUSB_OMAP2PLUS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  
>  /* USB EHCI */
>  #define CONFIG_SYS_USB_FAT_BOOT_PARTITION  1
> diff --git a/include/configs/omap3_logic.h
> b/include/configs/omap3_logic.h
> index b095814..1e4e42a 100644
> --- a/include/configs/omap3_logic.h
> +++ b/include/configs/omap3_logic.h
> @@ -55,8 +55,6 @@
>  #define CONFIG_SYS_I2C_EEPROM_ADDR   0x50/* EEPROM
> AT24C64  */
>  
>  /* USB */
> -#define CONFIG_USB_MUSB_OMAP2PLUS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  
>  /* TWL4030 */
>  #define CONFIG_TWL4030_USB
> diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
> index 79f3f48..9482501 100644
> --- a/include/configs/pcm051.h
> +++ b/include/configs/pcm051.h
> @@ -127,7 +127,6 @@
>   * USB configuration
>   */
>  #define CONFIG_USB_MUSB_DSPS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_AM335X_USB0
>  #define CONFIG_AM335X_USB0_MODE  MUSB_PERIPHERAL
>  #define CONFIG_AM335X_USB1
> diff --git a/include/configs/pengwyn.h b/include/configs/pengwyn.h
> index 8afd64e..d1ddb15 100644
> --- a/include/configs/pengwyn.h
> +++ b/include/configs/pengwyn.h
> @@ -163,7 +163,6 @@
>   * add mass storage support.
>   */
>  #define CONFIG_USB_MUSB_DSPS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
>  #define CONFIG_AM335X_USB0
>  #define CONFIG_AM335X_USB0_MODE  MUSB_PERIPHERAL
> diff --git a/include/configs/pic32mzdask.h
> b/include/configs/pic32mzdask.h
> index 97636fe..0bb5126 100644
> --- a/include/configs/pic32mzdask.h
> +++ b/include/configs/pic32mzdask.h
> @@ -80,7 +80,6 @@
>  /*--
>   * USB Configuration
>   */
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  
>  /*---
> 
>   * File System Configuration
> diff --git a/include/configs/siemens-am33x-common.h
> b/include/configs/siemens-am33x-common.h
> index 78708a2..5da5a08 100644
> --- a/include/configs/siemens-am33x-common.h
> +++ b/include/configs/siemens-am33x-common.h
> @@ -169,7 +169,6 @@
>   * USB configuration
>   */
>  #define CONFIG_USB_MUSB_DSPS
> -#define CONFIG_USB_MUSB_PIO_ONLY
>  #define CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
>  
>  #define CONFIG_AM335X_USB0
> diff --git a/include/configs/sniper.h b/include/configs/sniper.h
> index 5809942..09b5a73 100644
> --- a/include/configs/sniper.h
> +++ b/include/configs/sniper.h
> @@ -113,8 +113,6 @@
>   * USB gadget
>   */
>  
> -#define CONFIG_USB_MUSB_PIO_ONLY
> -#define CONFIG_USB_MUSB_OMAP2PLUS
>  #define CONFIG_TWL4030_USB
>  
>  /*
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-
> common.h
> index 3855c56..582aba2 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -302,10 +302,6 @@ extern int soft_i2c_gpio_scl;
>  #define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1
>  #endif
>  
> -#ifdef CONFIG_USB_MUSB_SUNXI
> -#define CONFIG_USB_MUSB_PIO_ONLY
> -#endif
> -
>  #ifdef CONFIG_USB_MUSB_GADGET
>  #define CONFIG_USB_FUNCTION_MASS_STORAGE
>  #endif
> diff --git a/scripts/config_whitelist.txt
> b/scripts/config_whitelist.txt
> index 43a4ff0..97d27fc 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -4947,8 +4947,6 @@ CONFIG_USB_MUSB_AM35X
>  CONFIG_USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
>  CONFIG_USB_MUSB_DSPS
>  CONFIG_USB_MUSB_HCD
> -CONFIG_USB_MUSB_OMAP2PLUS
> -CONFIG_USB_MUSB_PIO_ONLY
>  CONFIG_USB_MUSB_TIMEOUT
>  CONFIG_USB_MUSB_TUSB6010
>  CONFIG_USB_MUSB_UDC
-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Re : FOSDEM Hardware Enablement Devroom

[Paul Kocialkowski]

Hi,

Le lundi 13 novembre 2017 à 11:57 +0100, Paul Kocialkowski a écrit :
> A Hardware Enablement devroom will be taking place at FOSDEM this
> year, on Sunday 10 December 2017. This newly-created devroom is the
> result of 3 proposals that were merged together. It is co-organized by
> several individuals.

As it was pointed out on the Replicant mailing list, the devroom is
actually taking place on the Sunday  4 February 2018, not on december
2018.

> The devroom covers all aspects related to hardware enablement and
> support with free software, including aspects related to boot
> software,
> firmwares, drivers and userspace tools and adaptation.
> 
> Proposals for talks related to these topics are welcome and can be
> submitted until Sunday 26 November 2017 via the pentabarf interface.
> Short talks are encouraged over longer ones in order to cover a wide
> range of topics.
> 
> The announcement for the devroom, that contains all the useful
> information, was published at:
> https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
> 
> Cheers and see you at FOSDEM!

Cheers,

-- 
Paul Kocialkowski, developer of free digital technology and hardware
support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot