[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Rayagonda Kokatanur]

This is the second patch set series prepared on top of the
first patch set ("add initial support for broadcom NS3 soc").

This patch set will add following,
-dt nodes and defconfig options for basic device like pinctrl,
 gpio, mmc, qspi, wdt, i2c and pcie.
-start wdt service
-Enable GPT commands
-Enable EXT4 and FAT fs support

Pramod Kumar (2):
  arm: dts: ns3: add emmc node
  arm: dts: ns3: add sp805 watchdog node

Rayagonda Kokatanur (12):
  configs: ns3: enable pinctrl driver
  dt-bindings: pinctrl: add ns3 pads definition
  arm: dts: ns3: add pinctrl node
  arm: dts: ns3: add gpio node
  configs: ns3: enable BCM IPROC mmc driver
  configs: ns3: enable mmc commands
  arm: dts: ns3: add qspi node
  arm: dts: ns3: add i2c node
  configs: ns3: enable gpt commands
  configs: ns3: enable EXT4 and FAT fs support
  configs: ns3: enable sp805 watchdog driver
  board: ns3: start sp805 watchdog service

Srinath Mannam (1):
  arm: dts: ns3: add PAXB PCIe host and phy node

 arch/arm/dts/ns3-board.dts                    |  58 ++++
 arch/arm/dts/ns3-pinctrl.dtsi                 | 321 ++++++++++++++++++
 arch/arm/dts/ns3.dtsi                         | 224 ++++++++++++
 board/broadcom/bcmns3/ns3.c                   |  56 +++
 configs/bcm_ns3_defconfig                     |  19 ++
 .../dt-bindings/pinctrl/brcm,pinctrl-ns3.h    |  41 +++
 6 files changed, 719 insertions(+)
 create mode 100644 arch/arm/dts/ns3-pinctrl.dtsi
 create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h

-- 
2.17.1

[PATCH v1 01/15] configs: ns3: enable pinctrl driver

[Rayagonda Kokatanur]

Enable pinctrl driver for ns3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 configs/bcm_ns3_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig
index 9adb44cb51..328b0e2b4e 100644
--- a/configs/bcm_ns3_defconfig
+++ b/configs/bcm_ns3_defconfig
@@ -14,12 +14,15 @@ CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="u-boot> "
 CONFIG_SYS_XTRACE="n"
+# CONFIG_CMD_PINMUX is not set
 # CONFIG_CMD_SOURCE is not set
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="ns3-board"
 CONFIG_DM=y
 CONFIG_CLK=y
 CONFIG_CLK_CCF=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPL_OF_LIBFDT=y
-- 
2.17.1

[PATCH v1 01/15] configs: ns3: enable pinctrl driver

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Enable pinctrl driver for ns3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  configs/bcm_ns3_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 02/15] dt-bindings: pinctrl: add ns3 pads definition

[Rayagonda Kokatanur]

Add NS3 pads definitions.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 .../dt-bindings/pinctrl/brcm,pinctrl-ns3.h    | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h

diff --git a/include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h b/include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h
new file mode 100644
index 0000000000..81ebd58ca5
--- /dev/null
+++ b/include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2020 Broadcom.
+ */
+
+#ifndef __DT_BINDINGS_PINCTRL_BRCM_STINGRAY_H__
+#define __DT_BINDINGS_PINCTRL_BRCM_STINGRAY_H__
+
+/* Alternate functions available in MUX controller */
+#define MODE_NITRO				0
+#define MODE_NAND				1
+#define MODE_PNOR				2
+#define MODE_GPIO				3
+
+/* Pad configuration attribute */
+#define PAD_SLEW_RATE_ENA			BIT(0)
+#define PAD_SLEW_RATE_ENA_MASK			BIT(0)
+
+#define PAD_DRIVE_STRENGTH_2_MA			(0 << 1)
+#define PAD_DRIVE_STRENGTH_4_MA			BIT(1)
+#define PAD_DRIVE_STRENGTH_6_MA			(2 << 1)
+#define PAD_DRIVE_STRENGTH_8_MA			(3 << 1)
+#define PAD_DRIVE_STRENGTH_10_MA		(4 << 1)
+#define PAD_DRIVE_STRENGTH_12_MA		(5 << 1)
+#define PAD_DRIVE_STRENGTH_14_MA		(6 << 1)
+#define PAD_DRIVE_STRENGTH_16_MA		(7 << 1)
+#define PAD_DRIVE_STRENGTH_MASK			(7 << 1)
+
+#define PAD_PULL_UP_ENA				BIT(4)
+#define PAD_PULL_UP_ENA_MASK			BIT(4)
+
+#define PAD_PULL_DOWN_ENA			BIT(5)
+#define PAD_PULL_DOWN_ENA_MASK			BIT(5)
+
+#define PAD_INPUT_PATH_DIS			BIT(6)
+#define PAD_INPUT_PATH_DIS_MASK			BIT(6)
+
+#define PAD_HYSTERESIS_ENA			BIT(7)
+#define PAD_HYSTERESIS_ENA_MASK			BIT(7)
+
+#endif
-- 
2.17.1

[PATCH v1 02/15] dt-bindings: pinctrl: add ns3 pads definition

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Add NS3 pads definitions.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  .../dt-bindings/pinctrl/brcm,pinctrl-ns3.h    | 41 +++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 03/15] arm: dts: ns3: add pinctrl node

[Rayagonda Kokatanur]

Add pinctrl dt node for ns3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 arch/arm/dts/ns3-pinctrl.dtsi | 321 ++++++++++++++++++++++++++++++++++
 arch/arm/dts/ns3.dtsi         |   2 +
 2 files changed, 323 insertions(+)
 create mode 100644 arch/arm/dts/ns3-pinctrl.dtsi

diff --git a/arch/arm/dts/ns3-pinctrl.dtsi b/arch/arm/dts/ns3-pinctrl.dtsi
new file mode 100644
index 0000000000..dfc13c7014
--- /dev/null
+++ b/arch/arm/dts/ns3-pinctrl.dtsi
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier:      GPL-2.0+
+/*
+ * Copyright (C) 2020 Broadcom
+ */
+
+#include <dt-bindings/pinctrl/brcm,pinctrl-ns3.h>
+
+		pinconf: pinconf at 140000 {
+			compatible = "pinconf-single";
+			reg = <0x00140000 0x250>;
+			pinctrl-single,register-width = <32>;
+
+			/* pinconf functions */
+		};
+
+		pinmux: pinmux at 14029c {
+			ranges;
+			compatible = "pinctrl-single";
+			reg = <0x0014029c 0x250>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <0xf>;
+
+			pinctrl-single,gpio-range = <
+				&range 0  91 MODE_GPIO
+				&range 95 60 MODE_GPIO
+				>;
+			range: gpio-range {
+				#pinctrl-single,gpio-range-cells = <3>;
+			};
+
+			/* pinctrl functions */
+			tsio_pins: pinmux_gpio_14 {
+				pinctrl-single,pins = <
+					0x038 MODE_NITRO /* tsio_0 */
+					0x03c MODE_NITRO /* tsio_1 */
+				>;
+			};
+
+			nor_pins: pinmux_pnor_adv_n {
+				pinctrl-single,pins = <
+					0x0ac MODE_PNOR /* nand_ce1_n */
+					0x0b0 MODE_PNOR /* nand_ce0_n */
+					0x0b4 MODE_PNOR /* nand_we_n */
+					0x0b8 MODE_PNOR /* nand_wp_n */
+					0x0bc MODE_PNOR /* nand_re_n */
+					0x0c0 MODE_PNOR /* nand_rdy_bsy_n */
+					0x0c4 MODE_PNOR /* nand_io0_0 */
+					0x0c8 MODE_PNOR /* nand_io1_0 */
+					0x0cc MODE_PNOR /* nand_io2_0 */
+					0x0d0 MODE_PNOR /* nand_io3_0 */
+					0x0d4 MODE_PNOR /* nand_io4_0 */
+					0x0d8 MODE_PNOR /* nand_io5_0 */
+					0x0dc MODE_PNOR /* nand_io6_0 */
+					0x0e0 MODE_PNOR /* nand_io7_0 */
+					0x0e4 MODE_PNOR /* nand_io8_0 */
+					0x0e8 MODE_PNOR /* nand_io9_0 */
+					0x0ec MODE_PNOR /* nand_io10_0 */
+					0x0f0 MODE_PNOR /* nand_io11_0 */
+					0x0f4 MODE_PNOR /* nand_io12_0 */
+					0x0f8 MODE_PNOR /* nand_io13_0 */
+					0x0fc MODE_PNOR /* nand_io14_0 */
+					0x100 MODE_PNOR /* nand_io15_0 */
+					0x104 MODE_PNOR /* nand_ale_0 */
+					0x108 MODE_PNOR /* nand_cle_0 */
+					0x040 MODE_PNOR /* pnor_adv_n */
+					0x044 MODE_PNOR /* pnor_baa_n */
+					0x048 MODE_PNOR /* pnor_bls_0_n */
+					0x04c MODE_PNOR /* pnor_bls_1_n */
+					0x050 MODE_PNOR /* pnor_cre */
+					0x054 MODE_PNOR /* pnor_cs_2_n */
+					0x058 MODE_PNOR /* pnor_cs_1_n */
+					0x05c MODE_PNOR /* pnor_cs_0_n */
+					0x060 MODE_PNOR /* pnor_we_n */
+					0x064 MODE_PNOR /* pnor_oe_n */
+					0x068 MODE_PNOR /* pnor_intr */
+					0x06c MODE_PNOR /* pnor_dat_0 */
+					0x070 MODE_PNOR /* pnor_dat_1 */
+					0x074 MODE_PNOR /* pnor_dat_2 */
+					0x078 MODE_PNOR /* pnor_dat_3 */
+					0x07c MODE_PNOR /* pnor_dat_4 */
+					0x080 MODE_PNOR /* pnor_dat_5 */
+					0x084 MODE_PNOR /* pnor_dat_6 */
+					0x088 MODE_PNOR /* pnor_dat_7 */
+					0x08c MODE_PNOR /* pnor_dat_8 */
+					0x090 MODE_PNOR /* pnor_dat_9 */
+					0x094 MODE_PNOR /* pnor_dat_10 */
+					0x098 MODE_PNOR /* pnor_dat_11 */
+					0x09c MODE_PNOR /* pnor_dat_12 */
+					0x0a0 MODE_PNOR /* pnor_dat_13 */
+					0x0a4 MODE_PNOR /* pnor_dat_14 */
+					0x0a8 MODE_PNOR /* pnor_dat_15 */
+				>;
+			};
+
+			nand_pins: pinmux_nand_ce1_n {
+				pinctrl-single,pins = <
+					0x0ac MODE_NAND /* nand_ce1_n */
+					0x0b0 MODE_NAND /* nand_ce0_n */
+					0x0b4 MODE_NAND /* nand_we_n */
+					0x0b8 MODE_NAND /* nand_wp_n */
+					0x0bc MODE_NAND /* nand_re_n */
+					0x0c0 MODE_NAND /* nand_rdy_bsy_n */
+					0x0c4 MODE_NAND /* nand_io0_0 */
+					0x0c8 MODE_NAND /* nand_io1_0 */
+					0x0cc MODE_NAND /* nand_io2_0 */
+					0x0d0 MODE_NAND /* nand_io3_0 */
+					0x0d4 MODE_NAND /* nand_io4_0 */
+					0x0d8 MODE_NAND /* nand_io5_0 */
+					0x0dc MODE_NAND /* nand_io6_0 */
+					0x0e0 MODE_NAND /* nand_io7_0 */
+					0x0e4 MODE_NAND /* nand_io8_0 */
+					0x0e8 MODE_NAND /* nand_io9_0 */
+					0x0ec MODE_NAND /* nand_io10_0 */
+					0x0f0 MODE_NAND /* nand_io11_0 */
+					0x0f4 MODE_NAND /* nand_io12_0 */
+					0x0f8 MODE_NAND /* nand_io13_0 */
+					0x0fc MODE_NAND /* nand_io14_0 */
+					0x100 MODE_NAND /* nand_io15_0 */
+					0x104 MODE_NAND /* nand_ale_0 */
+					0x108 MODE_NAND /* nand_cle_0 */
+				>;
+			};
+
+			pwm0_pins: pinmux_pwm_0 {
+				pinctrl-single,pins = <
+					0x10c MODE_NITRO
+				>;
+			};
+
+			pwm1_pins: pinmux_pwm_1 {
+				pinctrl-single,pins = <
+					0x110 MODE_NITRO
+				>;
+			};
+
+			pwm2_pins: pinmux_pwm_2 {
+				pinctrl-single,pins = <
+					0x114 MODE_NITRO
+				>;
+			};
+
+			pwm3_pins: pinmux_pwm_3 {
+				pinctrl-single,pins = <
+					0x118 MODE_NITRO
+				>;
+			};
+
+			dbu_rxd_pins: pinmux_uart1_sin_nitro {
+				pinctrl-single,pins = <
+					0x11c MODE_NITRO /* dbu_rxd */
+					0x120 MODE_NITRO /* dbu_txd */
+				>;
+			};
+
+			uart1_pins: pinmux_uart1_sin_nand {
+				pinctrl-single,pins = <
+					0x11c MODE_NAND /* uart1_sin */
+					0x120 MODE_NAND /* uart1_out */
+				>;
+			};
+
+			uart2_pins: pinmux_uart2_sin {
+				pinctrl-single,pins = <
+					0x124 MODE_NITRO /* uart2_sin */
+					0x128 MODE_NITRO /* uart2_out */
+				>;
+			};
+
+			uart3_pins: pinmux_uart3_sin {
+				pinctrl-single,pins = <
+					0x12c MODE_NITRO /* uart3_sin */
+					0x130 MODE_NITRO /* uart3_out */
+				>;
+			};
+
+			i2s_pins: pinmux_i2s_bitclk {
+				pinctrl-single,pins = <
+					0x134 MODE_NITRO /* i2s_bitclk */
+					0x138 MODE_NITRO /* i2s_sdout */
+					0x13c MODE_NITRO /* i2s_sdin */
+					0x140 MODE_NITRO /* i2s_ws */
+					0x144 MODE_NITRO /* i2s_mclk */
+					0x148 MODE_NITRO /* i2s_spdif_out */
+				>;
+			};
+
+			qspi_pins: pinumx_qspi_hold_n {
+				pinctrl-single,pins = <
+					0x14c MODE_NAND /* qspi_hold_n */
+					0x150 MODE_NAND /* qspi_wp_n */
+					0x154 MODE_NAND /* qspi_sck */
+					0x158 MODE_NAND /* qspi_cs_n */
+					0x15c MODE_NAND /* qspi_mosi */
+					0x160 MODE_NAND /* qspi_miso */
+				>;
+			};
+
+			mdio_pins: pinumx_ext_mdio {
+				pinctrl-single,pins = <
+					0x164 MODE_NITRO /* ext_mdio */
+					0x168 MODE_NITRO /* ext_mdc */
+				>;
+			};
+
+			i2c0_pins: pinmux_i2c0_sda {
+				pinctrl-single,pins = <
+					0x16c MODE_NITRO /* i2c0_sda */
+					0x170 MODE_NITRO /* i2c0_scl */
+				>;
+			};
+
+			i2c1_pins: pinmux_i2c1_sda {
+				pinctrl-single,pins = <
+					0x174 MODE_NITRO /* i2c1_sda */
+					0x178 MODE_NITRO /* i2c1_scl */
+				>;
+			};
+
+			sdio0_pins: pinmux_sdio0_cd_l {
+				pinctrl-single,pins = <
+					0x17c MODE_NITRO /* sdio0_cd_l */
+					0x180 MODE_NITRO /* sdio0_clk_sdcard */
+					0x184 MODE_NITRO /* sdio0_data0 */
+					0x188 MODE_NITRO /* sdio0_data1 */
+					0x18c MODE_NITRO /* sdio0_data2 */
+					0x190 MODE_NITRO /* sdio0_data3 */
+					0x194 MODE_NITRO /* sdio0_data4 */
+					0x198 MODE_NITRO /* sdio0_data5 */
+					0x19c MODE_NITRO /* sdio0_data6 */
+					0x1a0 MODE_NITRO /* sdio0_data7 */
+					0x1a4 MODE_NITRO /* sdio0_cmd */
+					0x1a8 MODE_NITRO /* sdio0_emmc_rst_n */
+					0x1ac MODE_NITRO /* sdio0_led_on */
+					0x1b0 MODE_NITRO /* sdio0_wp */
+				>;
+			};
+
+			sdio1_pins: pinmux_sdio1_cd_l {
+				pinctrl-single,pins = <
+					0x1b4 MODE_NITRO /* sdio1_cd_l */
+					0x1b8 MODE_NITRO /* sdio1_clk_sdcard */
+					0x1bc MODE_NITRO /* sdio1_data0 */
+					0x1c0 MODE_NITRO /* sdio1_data1 */
+					0x1c4 MODE_NITRO /* sdio1_data2 */
+					0x1c8 MODE_NITRO /* sdio1_data3 */
+					0x1cc MODE_NITRO /* sdio1_data4 */
+					0x1d0 MODE_NITRO /* sdio1_data5 */
+					0x1d4 MODE_NITRO /* sdio1_data6 */
+					0x1d8 MODE_NITRO /* sdio1_data7 */
+					0x1dc MODE_NITRO /* sdio1_cmd */
+					0x1e0 MODE_NITRO /* sdio1_emmc_rst_n */
+					0x1e4 MODE_NITRO /* sdio1_led_on */
+					0x1e8 MODE_NITRO /* sdio1_wp */
+				>;
+			};
+
+			spi0_pins: pinmux_spi0_sck_nand {
+				pinctrl-single,pins = <
+					0x1ec MODE_NITRO /* spi0_sck */
+					0x1f0 MODE_NITRO /* spi0_rxd */
+					0x1f4 MODE_NITRO /* spi0_fss */
+					0x1f8 MODE_NITRO /* spi0_txd */
+				>;
+			};
+
+			spi1_pins: pinmux_spi1_sck_nand {
+				pinctrl-single,pins = <
+					0x1fc MODE_NITRO /* spi1_sck */
+					0x200 MODE_NITRO /* spi1_rxd */
+					0x204 MODE_NITRO /* spi1_fss */
+					0x208 MODE_NITRO /* spi1_txd */
+				>;
+			};
+
+			nuart_pins: pinmux_uart0_sin_nitro {
+				pinctrl-single,pins = <
+					0x20c MODE_NITRO /* nuart_rxd */
+					0x210 MODE_NITRO /* nuart_txd */
+				>;
+			};
+
+			uart0_pins: pinumux_uart0_sin_nand {
+				pinctrl-single,pins = <
+					0x20c MODE_NAND /* uart0_sin */
+					0x210 MODE_NAND /* uart0_out */
+					0x214 MODE_NAND /* uart0_rts */
+					0x218 MODE_NAND /* uart0_cts */
+					0x21c MODE_NAND /* uart0_dtr */
+					0x220 MODE_NAND /* uart0_dcd */
+					0x224 MODE_NAND /* uart0_dsr */
+					0x228 MODE_NAND /* uart0_ri */
+				>;
+			};
+
+			drdu2_pins: pinmux_drdu2_overcurrent {
+				pinctrl-single,pins = <
+					0x22c MODE_NITRO /* drdu2_overcurrent */
+					0x230 MODE_NITRO /* drdu2_vbus_ppc */
+					0x234 MODE_NITRO /* drdu2_vbus_present */
+					0x238 MODE_NITRO /* drdu2_id */
+				>;
+			};
+
+			drdu3_pins: pinmux_drdu3_overcurrent {
+				pinctrl-single,pins = <
+					0x23c MODE_NITRO /* drdu3_overcurrent */
+					0x240 MODE_NITRO /* drdu3_vbus_ppc */
+					0x244 MODE_NITRO /* drdu3_vbus_present */
+					0x248 MODE_NITRO /* drdu3_id */
+				>;
+			};
+
+			usb3h_pins: pinmux_usb3h_overcurrent {
+				pinctrl-single,pins = <
+					0x24c MODE_NITRO /* usb3h_overcurrent */
+					0x250 MODE_NITRO /* usb3h_vbus_ppc */
+				>;
+			};
+		};
diff --git a/arch/arm/dts/ns3.dtsi b/arch/arm/dts/ns3.dtsi
index 09098aac3a..a21455515d 100644
--- a/arch/arm/dts/ns3.dtsi
+++ b/arch/arm/dts/ns3.dtsi
@@ -23,6 +23,8 @@
 		#size-cells = <1>;
 		ranges = <0x0 0x0 0x68900000 0x17700000>;
 
+		#include "ns3-pinctrl.dtsi"
+
 		uart1: uart at 110000 {
 			compatible = "snps,dw-apb-uart";
 			reg = <0x00110000 0x1000>;
-- 
2.17.1

[PATCH v1 03/15] arm: dts: ns3: add pinctrl node

[Simon Glass]

Hi,

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Add pinctrl dt node for ns3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  arch/arm/dts/ns3-pinctrl.dtsi | 321 ++++++++++++++++++++++++++++++++++
>  arch/arm/dts/ns3.dtsi         |   2 +
>  2 files changed, 323 insertions(+)
>  create mode 100644 arch/arm/dts/ns3-pinctrl.dtsi
>

Reviewed-by: Simon Glass <sjg@chromium.org>

Can you please mention the linux version this came from. Also I cannot
find this file - are you sure you are using the same filename as
Linux?

Regards,
Simon

[PATCH v1 03/15] arm: dts: ns3: add pinctrl node

[Rayagonda Kokatanur]

Hi Simon,

On Mon, May 25, 2020 at 7:45 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi,
>
> On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
> <rayagonda.kokatanur@broadcom.com> wrote:
> >
> > Add pinctrl dt node for ns3.
> >
> > Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> > ---
> >  arch/arm/dts/ns3-pinctrl.dtsi | 321 ++++++++++++++++++++++++++++++++++
> >  arch/arm/dts/ns3.dtsi         |   2 +
> >  2 files changed, 323 insertions(+)
> >  create mode 100644 arch/arm/dts/ns3-pinctrl.dtsi
> >
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> Can you please mention the linux version this came from. Also I cannot
> find this file - are you sure you are using the same filename as
> Linux?
Linux 5.6
In Linux file name different, it is -
arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi

Best regards,
Rayagonda
>
> Regards,
> Simon

[PATCH v1 03/15] arm: dts: ns3: add pinctrl node

[Simon Glass]

Hi Rayagonda,

On Tue, 26 May 2020 at 04:08, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Hi Simon,
>
> On Mon, May 25, 2020 at 7:45 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi,
> >
> > On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
> > <rayagonda.kokatanur@broadcom.com> wrote:
> > >
> > > Add pinctrl dt node for ns3.
> > >
> > > Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> > > ---
> > >  arch/arm/dts/ns3-pinctrl.dtsi | 321 ++++++++++++++++++++++++++++++++++
> > >  arch/arm/dts/ns3.dtsi         |   2 +
> > >  2 files changed, 323 insertions(+)
> > >  create mode 100644 arch/arm/dts/ns3-pinctrl.dtsi
> > >
> >
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > Can you please mention the linux version this came from. Also I cannot
> > find this file - are you sure you are using the same filename as
> > Linux?
> Linux 5.6
> In Linux file name different, it is -
> arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi

OK. Please use the same filename and file contents here or it will get
very confusing!

Regards,
Simon

[PATCH v1 04/15] arm: dts: ns3: add gpio node

[Rayagonda Kokatanur]

Add IPROC GPIO node for NS3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 arch/arm/dts/ns3-board.dts |  1 +
 arch/arm/dts/ns3.dtsi      | 23 +++++++++++++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/arch/arm/dts/ns3-board.dts b/arch/arm/dts/ns3-board.dts
index c660e74dc8..5926123379 100644
--- a/arch/arm/dts/ns3-board.dts
+++ b/arch/arm/dts/ns3-board.dts
@@ -35,6 +35,7 @@
 
 	aliases {
 		serial0 = &uart1;
+		gpio0 = &gpio_hsls;
 	};
 
 	chosen {
diff --git a/arch/arm/dts/ns3.dtsi b/arch/arm/dts/ns3.dtsi
index a21455515d..84464add9a 100644
--- a/arch/arm/dts/ns3.dtsi
+++ b/arch/arm/dts/ns3.dtsi
@@ -32,5 +32,28 @@
 			clock-frequency = <25000000>;
 			status = "disabled";
 		};
+
+		gpio_hsls: gpio at d0000 {
+			compatible = "brcm,iproc-gpio";
+			reg = <0x000d0000 0x864>;
+			ngpios = <151>;
+			#gpio-cells = <2>;
+			gpio-controller;
+			gpio-ranges = <&pinmux 0 0 16>,
+					<&pinmux 16 71 2>,
+					<&pinmux 18 131 8>,
+					<&pinmux 26 83 6>,
+					<&pinmux 32 123 4>,
+					<&pinmux 36 43 24>,
+					<&pinmux 60 89 2>,
+					<&pinmux 62 73 4>,
+					<&pinmux 66 95 28>,
+					<&pinmux 94 127 4>,
+					<&pinmux 98 139 10>,
+					<&pinmux 108 16 27>,
+					<&pinmux 135 77 6>,
+					<&pinmux 141 67 4>,
+					<&pinmux 145 149 6>;
+		};
 	};
 };
-- 
2.17.1

[PATCH v1 04/15] arm: dts: ns3: add gpio node

[Simon Glass]

Hi Rayagonda,

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Add IPROC GPIO node for NS3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  arch/arm/dts/ns3-board.dts |  1 +
>  arch/arm/dts/ns3.dtsi      | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

If you are adding the device tree, just bring in the file all at once.

Regards,
Simon

[PATCH v1 04/15] arm: dts: ns3: add gpio node

[Rayagonda Kokatanur]

Hi Simon,

On Mon, May 25, 2020 at 7:44 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Rayagonda,
>
> On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
> <rayagonda.kokatanur@broadcom.com> wrote:
> >
> > Add IPROC GPIO node for NS3.
> >
> > Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> > ---
> >  arch/arm/dts/ns3-board.dts |  1 +
> >  arch/arm/dts/ns3.dtsi      | 23 +++++++++++++++++++++++
> >  2 files changed, 24 insertions(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> If you are adding the device tree, just bring in the file all at once.

Thank you for your review and suggestions.
I will remove all dt patches and push it as a single patch.

Best Regards
Rayagonda


>
> Regards,
> Simon

[PATCH v1 05/15] configs: ns3: enable BCM IPROC mmc driver

[Rayagonda Kokatanur]

Enable BCM IPROC mmc driver ns3.
Enable DMA for MMC Host to have better reads and writes.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 configs/bcm_ns3_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig
index 328b0e2b4e..432237b56d 100644
--- a/configs/bcm_ns3_defconfig
+++ b/configs/bcm_ns3_defconfig
@@ -21,6 +21,10 @@ CONFIG_DEFAULT_DEVICE_TREE="ns3-board"
 CONFIG_DM=y
 CONFIG_CLK=y
 CONFIG_CLK_CCF=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_IPROC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DM_SERIAL=y
-- 
2.17.1

[PATCH v1 05/15] configs: ns3: enable BCM IPROC mmc driver

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Enable BCM IPROC mmc driver ns3.
> Enable DMA for MMC Host to have better reads and writes.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  configs/bcm_ns3_defconfig | 4 ++++
>  1 file changed, 4 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 06/15] arm: dts: ns3: add emmc node

[Rayagonda Kokatanur]

From: Pramod Kumar <pramod.kumar@broadcom.com>

Add emmc dt nodes for ns3.

Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 arch/arm/dts/ns3-board.dts |  4 ++++
 arch/arm/dts/ns3.dtsi      | 18 ++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/dts/ns3-board.dts b/arch/arm/dts/ns3-board.dts
index 5926123379..45565c9c73 100644
--- a/arch/arm/dts/ns3-board.dts
+++ b/arch/arm/dts/ns3-board.dts
@@ -46,3 +46,7 @@
 &uart1 {
 	status = "okay";
 };
+
+&sdio0 {
+	status = "okay";
+};
diff --git a/arch/arm/dts/ns3.dtsi b/arch/arm/dts/ns3.dtsi
index 84464add9a..7f94b922fc 100644
--- a/arch/arm/dts/ns3.dtsi
+++ b/arch/arm/dts/ns3.dtsi
@@ -33,6 +33,24 @@
 			status = "disabled";
 		};
 
+		sdio0: sdhci at 3f1000 {
+			compatible = "brcm,iproc-sdhci";
+			reg = <0x003f1000 0x100>;
+			bus-width = <8>;
+			clock-freq-min-max = <400000 200000000>;
+			index = <0>;
+			status = "disabled";
+		};
+
+		sdio1: sdhci at 3f2000 {
+			compatible = "brcm,iproc-sdhci";
+			reg = <0x003f2000 0x100>;
+			bus-width = <8>;
+			clock-freq-min-max = <400000 200000000>;
+			index = <1>;
+			status = "disabled";
+		};
+
 		gpio_hsls: gpio at d0000 {
 			compatible = "brcm,iproc-gpio";
 			reg = <0x000d0000 0x864>;
-- 
2.17.1

[PATCH v1 06/15] arm: dts: ns3: add emmc node

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> From: Pramod Kumar <pramod.kumar@broadcom.com>
>
> Add emmc dt nodes for ns3.
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  arch/arm/dts/ns3-board.dts |  4 ++++
>  arch/arm/dts/ns3.dtsi      | 18 ++++++++++++++++++
>  2 files changed, 22 insertions(+)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 07/15] configs: ns3: enable mmc commands

[Rayagonda Kokatanur]

Enable mmc commands for NS3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 configs/bcm_ns3_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig
index 432237b56d..a1ee866e54 100644
--- a/configs/bcm_ns3_defconfig
+++ b/configs/bcm_ns3_defconfig
@@ -14,6 +14,8 @@ CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="u-boot> "
 CONFIG_SYS_XTRACE="n"
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MMC_SWRITE=y
 # CONFIG_CMD_PINMUX is not set
 # CONFIG_CMD_SOURCE is not set
 CONFIG_OF_CONTROL=y
-- 
2.17.1

[PATCH v1 07/15] configs: ns3: enable mmc commands

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Enable mmc commands for NS3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  configs/bcm_ns3_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 08/15] arm: dts: ns3: add qspi node

[Rayagonda Kokatanur]

Add QSPI node and qspi NOR flash node for NS3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 arch/arm/dts/ns3-board.dts | 16 ++++++++++++++++
 arch/arm/dts/ns3.dtsi      |  9 +++++++++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/dts/ns3-board.dts b/arch/arm/dts/ns3-board.dts
index 45565c9c73..78a69ac3f9 100644
--- a/arch/arm/dts/ns3-board.dts
+++ b/arch/arm/dts/ns3-board.dts
@@ -35,6 +35,7 @@
 
 	aliases {
 		serial0 = &uart1;
+		spi0 = &qspi;
 		gpio0 = &gpio_hsls;
 	};
 
@@ -47,6 +48,21 @@
 	status = "okay";
 };
 
+&qspi {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+	spi_nor_flash: spi_flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <12500000>;
+		spi-cpol;
+		spi-cpha;
+		spi-tx-bus-width = <1>;
+		spi-rx-bus-width = <4>;
+	};
+};
+
 &sdio0 {
 	status = "okay";
 };
diff --git a/arch/arm/dts/ns3.dtsi b/arch/arm/dts/ns3.dtsi
index 7f94b922fc..7681bbc673 100644
--- a/arch/arm/dts/ns3.dtsi
+++ b/arch/arm/dts/ns3.dtsi
@@ -33,6 +33,15 @@
 			status = "disabled";
 		};
 
+		qspi: spi at 370000 {
+			compatible = "brcm,iproc-qspi";
+			reg = <0x00370000 0x100>,
+			      <0x00370100 0x100>,
+			      <0x00370200 0x200>;
+			reg-names = "bspi", "bspi_raf", "mspi";
+			status = "disabled";
+		};
+
 		sdio0: sdhci at 3f1000 {
 			compatible = "brcm,iproc-sdhci";
 			reg = <0x003f1000 0x100>;
-- 
2.17.1

[PATCH v1 08/15] arm: dts: ns3: add qspi node

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Add QSPI node and qspi NOR flash node for NS3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  arch/arm/dts/ns3-board.dts | 16 ++++++++++++++++
>  arch/arm/dts/ns3.dtsi      |  9 +++++++++
>  2 files changed, 25 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 09/15] arm: dts: ns3: add i2c node

[Rayagonda Kokatanur]

Add IPROC I2C node for NS3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 arch/arm/dts/ns3-board.dts | 1 +
 arch/arm/dts/ns3.dtsi      | 6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/dts/ns3-board.dts b/arch/arm/dts/ns3-board.dts
index 78a69ac3f9..f8e501c225 100644
--- a/arch/arm/dts/ns3-board.dts
+++ b/arch/arm/dts/ns3-board.dts
@@ -36,6 +36,7 @@
 	aliases {
 		serial0 = &uart1;
 		spi0 = &qspi;
+		i2c0 = &i2c0;
 		gpio0 = &gpio_hsls;
 	};
 
diff --git a/arch/arm/dts/ns3.dtsi b/arch/arm/dts/ns3.dtsi
index 7681bbc673..adb1277471 100644
--- a/arch/arm/dts/ns3.dtsi
+++ b/arch/arm/dts/ns3.dtsi
@@ -60,6 +60,12 @@
 			status = "disabled";
 		};
 
+		i2c0:i2c at b0000 {
+			compatible = "brcm,iproc-i2c";
+			reg = <0xb0000 0x100>;
+			bus-frequency = <100000>;
+		};
+
 		gpio_hsls: gpio at d0000 {
 			compatible = "brcm,iproc-gpio";
 			reg = <0x000d0000 0x864>;
-- 
2.17.1

[PATCH v1 09/15] arm: dts: ns3: add i2c node

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Add IPROC I2C node for NS3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  arch/arm/dts/ns3-board.dts | 1 +
>  arch/arm/dts/ns3.dtsi      | 6 ++++++
>  2 files changed, 7 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 10/15] arm: dts: ns3: add PAXB PCIe host and phy node

[Rayagonda Kokatanur]

From: Srinath Mannam <srinath.mannam@broadcom.com>

Add PAXB PCIe host controller and phy node for NS3.

Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 arch/arm/dts/ns3-board.dts |  36 +++++++++
 arch/arm/dts/ns3.dtsi      | 158 +++++++++++++++++++++++++++++++++++++
 2 files changed, 194 insertions(+)

diff --git a/arch/arm/dts/ns3-board.dts b/arch/arm/dts/ns3-board.dts
index f8e501c225..460ed39132 100644
--- a/arch/arm/dts/ns3-board.dts
+++ b/arch/arm/dts/ns3-board.dts
@@ -67,3 +67,39 @@
 &sdio0 {
 	status = "okay";
 };
+
+&pcie0 {
+	status = "okay";
+};
+
+&pcie1 {
+	status = "okay";
+};
+
+&pcie2 {
+	status = "okay";
+};
+
+&pcie3 {
+	status = "okay";
+};
+
+&pcie4 {
+	status = "okay";
+};
+
+&pcie5 {
+	status = "okay";
+};
+
+&pcie6 {
+	status = "okay";
+};
+
+&pcie7 {
+	status = "okay";
+};
+
+&pcie8 {
+	status = "okay";
+};
diff --git a/arch/arm/dts/ns3.dtsi b/arch/arm/dts/ns3.dtsi
index adb1277471..9fd59a855e 100644
--- a/arch/arm/dts/ns3.dtsi
+++ b/arch/arm/dts/ns3.dtsi
@@ -5,6 +5,11 @@
 
 #include "skeleton64.dtsi"
 
+#define PCIE_DMA_RANGES dma-ranges = < \
+	0x43000000 0x00 0x80000000 0x00 0x80000000 0x00 0x80000000 \
+	0x43000000 0x08 0x00000000 0x08 0x00000000 0x08 0x00000000 \
+	0x43000000 0x80 0x00000000 0x80 0x00000000 0x80 0x00000000>
+
 / {
 	compatible = "brcm,ns3";
 	#address-cells = <2>;
@@ -89,4 +94,157 @@
 					<&pinmux 145 149 6>;
 		};
 	};
+
+	pcie0: pcie at 48000000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x48000000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x83000000 0x0 0x42000000 0x0 0x42000000 0 0x2000000>,
+			<0x43000000 0x4 0x00000000 0x4 0x00000000 0 0x80000000>;
+		brcm,pcie-ob;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 0>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie1: pcie at 48004000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x48004000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x83000000 0x0 0x44000000 0x0 0x44000000 0 0x2000000>,
+			<0x43000000 0x4 0x80000000 0x4 0x80000000 0 0x80000000>;
+		brcm,pcie-ob;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 1>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie2: pcie at 48008000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x48008000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x83000000 0x0 0x4a000000 0x0 0x4a000000 0 0x2000000>,
+			<0x43000000 0x5 0x00000000 0x5 0x00000000 0 0x80000000>;
+		brcm,pcie-ob;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 2>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie3: pcie at 4800c000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x4800c000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		brcm,pcie-ob;
+		ranges = <0x83000000 0x0 0x4c000000 0x0 0x4c000000 0 0x2000000>,
+			<0x43000000 0x5 0x80000000 0x5 0x80000000 0 0x80000000>;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 3>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie4: pcie at 48010000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x48010000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		brcm,pcie-ob;
+		ranges = <0x83000000 0x0 0x52000000 0x0 0x52000000 0 0x2000000>,
+			<0x43000000 0x6 0x00000000 0x6 0x00000000 0 0x80000000>;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 4>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie5: pcie at 48014000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x48014000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		brcm,pcie-ob;
+		ranges = <0x83000000 0x0 0x54000000 0x0 0x54000000 0 0x2000000>,
+			<0x43000000 0x6 0x80000000 0x6 0x80000000 0 0x80000000>;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 5>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie6: pcie at 48018000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x48018000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		brcm,pcie-ob;
+		ranges = <0x83000000 0x0 0x5a000000 0x0 0x5a000000 0 0x2000000>,
+			<0x43000000 0x7 0x00000000 0x7 0x00000000 0 0x80000000>;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 6>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie7: pcie at 4801c000 {
+		compatible = "brcm,iproc-pcie-paxb-v2";
+		reg = <0 0x4801c000 0 0x4000>;
+		bus-range = <0x0 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		brcm,pcie-ob;
+		ranges = <0x83000000 0x0 0x5c000000 0x0 0x5c000000 0 0x2000000>,
+			<0x43000000 0x8 0x00000000 0x8 0x00000000 0 0x80000000>;
+		PCIE_DMA_RANGES;
+		phys = <&pcie_phy 7>;
+		phy-names = "pcie-phy";
+		status = "disabled";
+	};
+
+	pcie8: pcie at 60400000 {
+		compatible = "brcm,iproc-pcie-paxc-v2";
+		reg = <0 0x60400000 0 0x1000>;
+		bus-range = <0x0 0x1>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x83000000 0 0x10000000 0 0x10000000 0 0x20000000>;
+		status = "disabled";
+		pci at 0,0 {
+			compatible = "pci-bridge";
+			reg = <0x0000 0 0 0 0>;
+		};
+	};
+
+	pcie_phy: phy at 0 {
+		compatible = "brcm,sr-pcie-phy";
+		reg = <0 0x40000000 0 0x200>,
+		      <0 0x6641d000 0 0x100>;
+		reg-names = "reg_base", "cdru_base";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#phy-cells = <1>;
+	};
 };
-- 
2.17.1

[PATCH v1 10/15] arm: dts: ns3: add PAXB PCIe host and phy node

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> From: Srinath Mannam <srinath.mannam@broadcom.com>
>
> Add PAXB PCIe host controller and phy node for NS3.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  arch/arm/dts/ns3-board.dts |  36 +++++++++
>  arch/arm/dts/ns3.dtsi      | 158 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 194 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 11/15] configs: ns3: enable gpt commands

[Rayagonda Kokatanur]

Enable gpt commands for ns3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 configs/bcm_ns3_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig
index a1ee866e54..0f23f30db2 100644
--- a/configs/bcm_ns3_defconfig
+++ b/configs/bcm_ns3_defconfig
@@ -14,6 +14,8 @@ CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="u-boot> "
 CONFIG_SYS_XTRACE="n"
+CONFIG_CMD_GPT=y
+CONFIG_CMD_GPT_RENAME=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_MMC_SWRITE=y
 # CONFIG_CMD_PINMUX is not set
-- 
2.17.1

[PATCH v1 11/15] configs: ns3: enable gpt commands

[Simon Glass]

On Sun, 17 May 2020 at 02:20, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Enable gpt commands for ns3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  configs/bcm_ns3_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 12/15] configs: ns3: enable EXT4 and FAT fs support

[Rayagonda Kokatanur]

Enable EXT4 and FAT fs support for ns3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 configs/bcm_ns3_defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig
index 0f23f30db2..66fbdb20d6 100644
--- a/configs/bcm_ns3_defconfig
+++ b/configs/bcm_ns3_defconfig
@@ -20,6 +20,10 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_MMC_SWRITE=y
 # CONFIG_CMD_PINMUX is not set
 # CONFIG_CMD_SOURCE is not set
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+# CONFIG_DOS_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="ns3-board"
 CONFIG_DM=y
@@ -33,4 +37,5 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+CONFIG_FAT_WRITE=y
 CONFIG_SPL_OF_LIBFDT=y
-- 
2.17.1

[PATCH v1 12/15] configs: ns3: enable EXT4 and FAT fs support

[Simon Glass]

Hi Rayagonda,

On Sun, 17 May 2020 at 02:21, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Enable EXT4 and FAT fs support for ns3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  configs/bcm_ns3_defconfig | 5 +++++
>  1 file changed, 5 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

I don't think it is worth bringing in multiple config changes in
separate patches when you are adding a new board. You could have one
at the end to enable all the new features.


- Simon

[PATCH v1 13/15] configs: ns3: enable sp805 watchdog driver

[Rayagonda Kokatanur]

Enable sp805 watchdog driver for ns3.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 configs/bcm_ns3_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig
index 66fbdb20d6..3cb69eff9d 100644
--- a/configs/bcm_ns3_defconfig
+++ b/configs/bcm_ns3_defconfig
@@ -37,5 +37,8 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+# CONFIG_WATCHDOG is not set
+CONFIG_WDT=y
+CONFIG_WDT_SP805=y
 CONFIG_FAT_WRITE=y
 CONFIG_SPL_OF_LIBFDT=y
-- 
2.17.1

[PATCH v1 13/15] configs: ns3: enable sp805 watchdog driver

[Simon Glass]

On Sun, 17 May 2020 at 02:21, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Enable sp805 watchdog driver for ns3.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  configs/bcm_ns3_defconfig | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 14/15] arm: dts: ns3: add sp805 watchdog node

[Rayagonda Kokatanur]

From: Pramod Kumar <pramod.kumar@broadcom.com>

Add sp805 watchdog dts node for ns3.

Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 arch/arm/dts/ns3.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/ns3.dtsi b/arch/arm/dts/ns3.dtsi
index 9fd59a855e..6962e658d3 100644
--- a/arch/arm/dts/ns3.dtsi
+++ b/arch/arm/dts/ns3.dtsi
@@ -29,6 +29,14 @@
 		ranges = <0x0 0x0 0x68900000 0x17700000>;
 
 		#include "ns3-pinctrl.dtsi"
+		#include "ns3-clock.dtsi"
+
+		wdt0: watchdog at c0000 {
+			compatible = "arm,sp805-wdt";
+			reg = <0x000c0000 0x1000>;
+			timeout-sec = <60>;
+			clocks = <&hsls_25m_div2_clk>;
+		};
 
 		uart1: uart at 110000 {
 			compatible = "snps,dw-apb-uart";
-- 
2.17.1

[PATCH v1 14/15] arm: dts: ns3: add sp805 watchdog node

[Simon Glass]

On Sun, 17 May 2020 at 02:21, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> From: Pramod Kumar <pramod.kumar@broadcom.com>
>
> Add sp805 watchdog dts node for ns3.
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
>  arch/arm/dts/ns3.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH v1 15/15] board: ns3: start sp805 watchdog service

[Rayagonda Kokatanur]

Start sp805 watchdog service.

Parse wdt timeout from env and dts, give precedence to env
timeout if defined. Set default timeout to 60s if both env
and dts doesn't specifiy timeout.

Stop the WDT in board late init and start the
WDT service before giving control to Linux.

Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
---
 board/broadcom/bcmns3/ns3.c | 56 +++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
index 51cab1aad3..37a3cf9d14 100644
--- a/board/broadcom/bcmns3/ns3.c
+++ b/board/broadcom/bcmns3/ns3.c
@@ -11,9 +11,12 @@
 #include <asm/gic.h>
 #include <asm/gic-v3.h>
 #include <asm/system.h>
+#include <dm/device.h>
+#include <dm/uclass.h>
 #include <dt-bindings/memory/bcm-ns3-mc.h>
 #include <fdtdec.h>
 #include <fdt_support.h>
+#include <wdt.h>
 
 #define BANK_OFFSET(bank)      ((u64)BCM_NS3_DDR_INFO_BASE + 8 + ((bank) * 16))
 
@@ -134,6 +137,14 @@ int board_init(void)
 
 int board_late_init(void)
 {
+#if CONFIG_IS_ENABLED(WDT)
+	/*
+	 * Default WDT service is started with 60 sec time out.
+	 * Disable it and start before giving control to Linux.
+	 */
+	wdt_stop(gd->watchdog_dev);
+#endif
+
 	return 0;
 }
 
@@ -185,12 +196,57 @@ void reset_cpu(ulong level)
 }
 
 #ifdef CONFIG_OF_BOARD_SETUP
+#if CONFIG_IS_ENABLED(WDT)
+
+#ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS
+#define CONFIG_WATCHDOG_TIMEOUT_MSECS	(60 * 1000)
+#endif
+#define DEF_TIMEOUT_SEC	(CONFIG_WATCHDOG_TIMEOUT_MSECS / 1000)
+
+static int start_wdt(void)
+{
+	u32 timeout = DEF_TIMEOUT_SEC;
+	struct udevice *udev;
+	int rc = 0;
+	u32 wdt_enable;
+
+	wdt_enable = env_get_ulong("wdt_enable", 16, 0);
+	printf("wdt_enable :%u\n", wdt_enable);
+	if (!wdt_enable)
+		return rc;
+
+	rc = uclass_get_device(UCLASS_WDT, 0, &udev);
+	if (rc) {
+		printf("Failed to get wdt rc:%d\n", rc);
+	} else {
+		timeout = env_get_ulong("wdt_timeout_sec", 10, 0);
+		if (!timeout) {
+			if (CONFIG_IS_ENABLED(OF_CONTROL))
+				timeout = dev_read_u32_default(gd->watchdog_dev,
+							       "timeout-sec",
+							       DEF_TIMEOUT_SEC);
+		}
+		wdt_start(udev, timeout * 1000, 0);
+		printf("Started wdt (%ds timeout)\n", timeout);
+	}
+
+	return rc;
+}
+#else
+static int start_wdt(void)
+{
+	return 0;
+}
+#endif /* CONFIG_WDT */
+
 int ft_board_setup(void *fdt, bd_t *bd)
 {
 	gic_lpi_tables_init(BCM_NS3_GIC_LPI_BASE, MAX_GIC_REDISTRIBUTORS);
 
 	mem_info_parse_fixup(fdt);
 
+	start_wdt();
+
 	return 0;
 }
 #endif /* CONFIG_OF_BOARD_SETUP */
-- 
2.17.1

[PATCH v1 15/15] board: ns3: start sp805 watchdog service

[Simon Glass]

Hi Rayagonda,

On Sun, 17 May 2020 at 02:21, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Start sp805 watchdog service.
>
> Parse wdt timeout from env and dts, give precedence to env
> timeout if defined. Set default timeout to 60s if both env
> and dts doesn't specifiy timeout.
>
> Stop the WDT in board late init and start the
> WDT service before giving control to Linux.
>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> ---
>  board/broadcom/bcmns3/ns3.c | 56 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
>
> diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
> index 51cab1aad3..37a3cf9d14 100644
> --- a/board/broadcom/bcmns3/ns3.c
> +++ b/board/broadcom/bcmns3/ns3.c
> @@ -11,9 +11,12 @@
>  #include <asm/gic.h>
>  #include <asm/gic-v3.h>
>  #include <asm/system.h>
> +#include <dm/device.h>
> +#include <dm/uclass.h>

You can include <dm.h> and get both of those

>  #include <dt-bindings/memory/bcm-ns3-mc.h>
>  #include <fdtdec.h>

Hoping you don't need that?

>  #include <fdt_support.h>
> +#include <wdt.h>
>
>  #define BANK_OFFSET(bank)      ((u64)BCM_NS3_DDR_INFO_BASE + 8 + ((bank) * 16))

Maybe you should change the BCM_NS3... to ULL? Then you shouldn't need
that cast.

>
> @@ -134,6 +137,14 @@ int board_init(void)
>
>  int board_late_init(void)
>  {
> +#if CONFIG_IS_ENABLED(WDT)

Is it possible to use if() instead of #if?

> +       /*
> +        * Default WDT service is started with 60 sec time out.
> +        * Disable it and start before giving control to Linux.
> +        */
> +       wdt_stop(gd->watchdog_dev);
> +#endif
> +
>         return 0;
>  }
>
> @@ -185,12 +196,57 @@ void reset_cpu(ulong level)
>  }
>
>  #ifdef CONFIG_OF_BOARD_SETUP
> +#if CONFIG_IS_ENABLED(WDT)
> +
> +#ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS
> +#define CONFIG_WATCHDOG_TIMEOUT_MSECS  (60 * 1000)
> +#endif
> +#define DEF_TIMEOUT_SEC        (CONFIG_WATCHDOG_TIMEOUT_MSECS / 1000)
> +
> +static int start_wdt(void)
> +{
> +       u32 timeout = DEF_TIMEOUT_SEC;
> +       struct udevice *udev;
> +       int rc = 0;
> +       u32 wdt_enable;
> +
> +       wdt_enable = env_get_ulong("wdt_enable", 16, 0);
> +       printf("wdt_enable :%u\n", wdt_enable);
> +       if (!wdt_enable)
> +               return rc;
> +
> +       rc = uclass_get_device(UCLASS_WDT, 0, &udev);
> +       if (rc) {
> +               printf("Failed to get wdt rc:%d\n", rc);

I suggest return rc here, so you don't need the 'else' below, and the
extra indent/

> +       } else {
> +               timeout = env_get_ulong("wdt_timeout_sec", 10, 0);
> +               if (!timeout) {
> +                       if (CONFIG_IS_ENABLED(OF_CONTROL))
> +                               timeout = dev_read_u32_default(gd->watchdog_dev,
> +                                                              "timeout-sec",
> +                                                              DEF_TIMEOUT_SEC);
> +               }
> +               wdt_start(udev, timeout * 1000, 0);
> +               printf("Started wdt (%ds timeout)\n", timeout);
> +       }
> +
> +       return rc;
> +}
> +#else

Not sure why you need this:

> +static int start_wdt(void)
> +{
> +       return 0;
> +}
> +#endif /* CONFIG_WDT */
> +
>  int ft_board_setup(void *fdt, bd_t *bd)
>  {
>         gic_lpi_tables_init(BCM_NS3_GIC_LPI_BASE, MAX_GIC_REDISTRIBUTORS);
>
>         mem_info_parse_fixup(fdt);
>
> +       start_wdt();

Perhaps you could drop the #idefs above and do something like this here:

if (CONFIG_IS_ENABLED(WDT))
   start_wdt();

> +
>         return 0;
>  }
>  #endif /* CONFIG_OF_BOARD_SETUP */
> --
> 2.17.1
>

Regards,
Simon

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Tom Rini]

On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:

> This is the second patch set series prepared on top of the
> first patch set ("add initial support for broadcom NS3 soc").
> 
> This patch set will add following,
> -dt nodes and defconfig options for basic device like pinctrl,
>  gpio, mmc, qspi, wdt, i2c and pcie.
> -start wdt service
> -Enable GPT commands
> -Enable EXT4 and FAT fs support

All of the dts changes not in a -u-boot.dtsi file either come from
mainline Linux or at least linux-next and have had some level upstream
review, right?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200518/2ebe4ada/attachment.sig>

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Rayagonda Kokatanur]

Hi Tom,


On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
>
> > This is the second patch set series prepared on top of the
> > first patch set ("add initial support for broadcom NS3 soc").
> >
> > This patch set will add following,
> > -dt nodes and defconfig options for basic device like pinctrl,
> >  gpio, mmc, qspi, wdt, i2c and pcie.
> > -start wdt service
> > -Enable GPT commands
> > -Enable EXT4 and FAT fs support
>
> All of the dts changes not in a -u-boot.dtsi file either come from
> mainline Linux or at least linux-next and have had some level upstream
> review, right?  Thanks!

Yes. All the DTS changes are merged in the Linux and are available at
arch/arm64/boot/dts/broadcom/stingray/

Best regards,
Rayagonda

>
> --
> Tom

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Tom Rini]

On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> Hi Tom,
> 
> 
> On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> >
> > > This is the second patch set series prepared on top of the
> > > first patch set ("add initial support for broadcom NS3 soc").
> > >
> > > This patch set will add following,
> > > -dt nodes and defconfig options for basic device like pinctrl,
> > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > -start wdt service
> > > -Enable GPT commands
> > > -Enable EXT4 and FAT fs support
> >
> > All of the dts changes not in a -u-boot.dtsi file either come from
> > mainline Linux or at least linux-next and have had some level upstream
> > review, right?  Thanks!
> 
> Yes. All the DTS changes are merged in the Linux and are available at
> arch/arm64/boot/dts/broadcom/stingray/

Great.  Please reference the release you're taking these from as that
will make future resyncs easier.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200519/089a6e4e/attachment.sig>

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Rayagonda Kokatanur]

On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > Hi Tom,
> >
> >
> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > >
> > > > This is the second patch set series prepared on top of the
> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > >
> > > > This patch set will add following,
> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > -start wdt service
> > > > -Enable GPT commands
> > > > -Enable EXT4 and FAT fs support
> > >
> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > mainline Linux or at least linux-next and have had some level upstream
> > > review, right?  Thanks!
> >
> > Yes. All the DTS changes are merged in the Linux and are available at
> > arch/arm64/boot/dts/broadcom/stingray/
>
> Great.  Please reference the release you're taking these from as that
> will make future resyncs easier.  Thanks!

It's Linux v5.6.

Best regards,
Rayagonda

>
>
> --
> Tom

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Thomas Fitzsimmons]

Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:

> On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
>>
>> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
>> > Hi Tom,
>> >
>> >
>> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
>> > >
>> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
>> > >
>> > > > This is the second patch set series prepared on top of the
>> > > > first patch set ("add initial support for broadcom NS3 soc").
>> > > >
>> > > > This patch set will add following,
>> > > > -dt nodes and defconfig options for basic device like pinctrl,
>> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
>> > > > -start wdt service
>> > > > -Enable GPT commands
>> > > > -Enable EXT4 and FAT fs support
>> > >
>> > > All of the dts changes not in a -u-boot.dtsi file either come from
>> > > mainline Linux or at least linux-next and have had some level upstream
>> > > review, right?  Thanks!
>> >
>> > Yes. All the DTS changes are merged in the Linux and are available at
>> > arch/arm64/boot/dts/broadcom/stingray/
>>
>> Great.  Please reference the release you're taking these from as that
>> will make future resyncs easier.  Thanks!
>
> It's Linux v5.6.

What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
looked at the mainline Linux device trees and I couldn't easily see the
correspondence.  Will the renaming complicate synchronization?

Thomas

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Rayagonda Kokatanur]

Hi Thomas,

On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
>
> Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
>
> > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> >>
> >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> >> > Hi Tom,
> >> >
> >> >
> >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> >> > >
> >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> >> > >
> >> > > > This is the second patch set series prepared on top of the
> >> > > > first patch set ("add initial support for broadcom NS3 soc").
> >> > > >
> >> > > > This patch set will add following,
> >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> >> > > > -start wdt service
> >> > > > -Enable GPT commands
> >> > > > -Enable EXT4 and FAT fs support
> >> > >
> >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> >> > > mainline Linux or at least linux-next and have had some level upstream
> >> > > review, right?  Thanks!
> >> >
> >> > Yes. All the DTS changes are merged in the Linux and are available at
> >> > arch/arm64/boot/dts/broadcom/stingray/
> >>
> >> Great.  Please reference the release you're taking these from as that
> >> will make future resyncs easier.  Thanks!
> >
> > It's Linux v5.6.
>
> What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> looked at the mainline Linux device trees and I couldn't easily see the
> correspondence.  Will the renaming complicate synchronization?

Do we need to maintain the same dt file between linux and uboot ?
Also in uboot we don't enable all devices,  how do we handle this ?
Please let me know.

Best regards,
Rayagonda

>
> Thomas

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Simon Glass]

Hi Rayagonda,

On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Hi Thomas,
>
> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> >
> > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> >
> > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > >>
> > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > >> > Hi Tom,
> > >> >
> > >> >
> > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > >> > >
> > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > >> > >
> > >> > > > This is the second patch set series prepared on top of the
> > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > >> > > >
> > >> > > > This patch set will add following,
> > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > >> > > > -start wdt service
> > >> > > > -Enable GPT commands
> > >> > > > -Enable EXT4 and FAT fs support
> > >> > >
> > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > >> > > mainline Linux or at least linux-next and have had some level upstream
> > >> > > review, right?  Thanks!
> > >> >
> > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > >> > arch/arm64/boot/dts/broadcom/stingray/
> > >>
> > >> Great.  Please reference the release you're taking these from as that
> > >> will make future resyncs easier.  Thanks!
> > >
> > > It's Linux v5.6.
> >
> > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > looked at the mainline Linux device trees and I couldn't easily see the
> > correspondence.  Will the renaming complicate synchronization?
>
> Do we need to maintain the same dt file between linux and uboot ?
> Also in uboot we don't enable all devices,  how do we handle this ?

If there is no U-Boot driver for a particular node then it will be
ignored. It is easier to keep them in sync if they are the same in
U-Boot and Linux.

> Please let me know.

That is implied by your question above :-)

Regards,
SImon

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Rayagonda Kokatanur]

Hi Simon,

On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Rayagonda,
>
> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> <rayagonda.kokatanur@broadcom.com> wrote:
> >
> > Hi Thomas,
> >
> > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > >
> > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > >
> > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > >>
> > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > >> > Hi Tom,
> > > >> >
> > > >> >
> > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > >> > >
> > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > >> > >
> > > >> > > > This is the second patch set series prepared on top of the
> > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > >> > > >
> > > >> > > > This patch set will add following,
> > > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > >> > > > -start wdt service
> > > >> > > > -Enable GPT commands
> > > >> > > > -Enable EXT4 and FAT fs support
> > > >> > >
> > > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > >> > > mainline Linux or at least linux-next and have had some level upstream
> > > >> > > review, right?  Thanks!
> > > >> >
> > > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > >>
> > > >> Great.  Please reference the release you're taking these from as that
> > > >> will make future resyncs easier.  Thanks!
> > > >
> > > > It's Linux v5.6.
> > >
> > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > looked at the mainline Linux device trees and I couldn't easily see the
> > > correspondence.  Will the renaming complicate synchronization?
> >
> > Do we need to maintain the same dt file between linux and uboot ?
> > Also in uboot we don't enable all devices,  how do we handle this ?
>
> If there is no U-Boot driver for a particular node then it will be
> ignored. It is easier to keep them in sync if they are the same in
> U-Boot and Linux.
>
> > Please let me know.
>
> That is implied by your question above :-)

NS3 board is derivative of the existing bcm95874t board
(arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
Hence we have different dt for NS3 in Linux but it is not yet upstremed.

I compared the dt file size between uboot and Linux.
Uboot dt size = 9K
Linux dt size  = 41K (32K extra)

In uboot we have 8MB non-volatile SPI flash memory.
Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
space is allocated to other components
like nitor/bnxt firmware image, DDR shmoo value and for backup image.

uboot.bin is part of the fip.bin image. If we pull Linux dt files this
will use extra 33K memory of allocated 1.5MB.
This increase in 33K will reduce total memory availability for u-boot
and other features (like ARM trusted firmware, Op-TEE OS) development
in future.
Hence we anticipate qpsi memory shortage going ahead for new features.

So please let me know your view on maintaining different dt files in uboot.

Best regards,
Rayagonda


>
> Regards,
> SImon

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Simon Glass]

Hi Rayagonda,

On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Hi Simon,
>
> On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Rayagonda,
> >
> > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > <rayagonda.kokatanur@broadcom.com> wrote:
> > >
> > > Hi Thomas,
> > >
> > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > > >
> > > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > > >
> > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > > >>
> > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > > >> > Hi Tom,
> > > > >> >
> > > > >> >
> > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > > >> > >
> > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > > >> > >
> > > > >> > > > This is the second patch set series prepared on top of the
> > > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > >> > > >
> > > > >> > > > This patch set will add following,
> > > > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > >> > > > -start wdt service
> > > > >> > > > -Enable GPT commands
> > > > >> > > > -Enable EXT4 and FAT fs support
> > > > >> > >
> > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > > >> > > mainline Linux or at least linux-next and have had some level upstream
> > > > >> > > review, right?  Thanks!
> > > > >> >
> > > > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > >>
> > > > >> Great.  Please reference the release you're taking these from as that
> > > > >> will make future resyncs easier.  Thanks!
> > > > >
> > > > > It's Linux v5.6.
> > > >
> > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > looked at the mainline Linux device trees and I couldn't easily see the
> > > > correspondence.  Will the renaming complicate synchronization?
> > >
> > > Do we need to maintain the same dt file between linux and uboot ?
> > > Also in uboot we don't enable all devices,  how do we handle this ?
> >
> > If there is no U-Boot driver for a particular node then it will be
> > ignored. It is easier to keep them in sync if they are the same in
> > U-Boot and Linux.
> >
> > > Please let me know.
> >
> > That is implied by your question above :-)
>
> NS3 board is derivative of the existing bcm95874t board
> (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> Hence we have different dt for NS3 in Linux but it is not yet upstremed.
>
> I compared the dt file size between uboot and Linux.
> Uboot dt size = 9K
> Linux dt size  = 41K (32K extra)
>
> In uboot we have 8MB non-volatile SPI flash memory.
> Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> space is allocated to other components
> like nitor/bnxt firmware image, DDR shmoo value and for backup image.
>
> uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> will use extra 33K memory of allocated 1.5MB.
> This increase in 33K will reduce total memory availability for u-boot
> and other features (like ARM trusted firmware, Op-TEE OS) development
> in future.
> Hence we anticipate qpsi memory shortage going ahead for new features.
>
> So please let me know your view on maintaining different dt files in uboot.

Sounds like you have plenty of memory, actually. Is U-Boot the first
thing to load?

I think it is important to use the same filename and have the same DT
contents where they are present in U-Boot. But if you want to leave
out nodes, etc., that seems OK to me. It should be easy enough to meld
in the updates later.

I wonder if we should add a way to drop unused nodes for U-Boot
proper, like we do for SPL?

Regards,
Simon

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Tom Rini]

On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
> Hi Rayagonda,
> 
> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> <rayagonda.kokatanur@broadcom.com> wrote:
> >
> > Hi Simon,
> >
> > On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > >
> > > > Hi Thomas,
> > > >
> > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > > > >
> > > > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > > > >
> > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > >>
> > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > > > >> > Hi Tom,
> > > > > >> >
> > > > > >> >
> > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > > > >> > >
> > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > > > >> > >
> > > > > >> > > > This is the second patch set series prepared on top of the
> > > > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > > >> > > >
> > > > > >> > > > This patch set will add following,
> > > > > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > >> > > > -start wdt service
> > > > > >> > > > -Enable GPT commands
> > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > >> > >
> > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > > > >> > > mainline Linux or at least linux-next and have had some level upstream
> > > > > >> > > review, right?  Thanks!
> > > > > >> >
> > > > > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > >>
> > > > > >> Great.  Please reference the release you're taking these from as that
> > > > > >> will make future resyncs easier.  Thanks!
> > > > > >
> > > > > > It's Linux v5.6.
> > > > >
> > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > looked at the mainline Linux device trees and I couldn't easily see the
> > > > > correspondence.  Will the renaming complicate synchronization?
> > > >
> > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > >
> > > If there is no U-Boot driver for a particular node then it will be
> > > ignored. It is easier to keep them in sync if they are the same in
> > > U-Boot and Linux.
> > >
> > > > Please let me know.
> > >
> > > That is implied by your question above :-)
> >
> > NS3 board is derivative of the existing bcm95874t board
> > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> >
> > I compared the dt file size between uboot and Linux.
> > Uboot dt size = 9K
> > Linux dt size  = 41K (32K extra)
> >
> > In uboot we have 8MB non-volatile SPI flash memory.
> > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > space is allocated to other components
> > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> >
> > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > will use extra 33K memory of allocated 1.5MB.
> > This increase in 33K will reduce total memory availability for u-boot
> > and other features (like ARM trusted firmware, Op-TEE OS) development
> > in future.
> > Hence we anticipate qpsi memory shortage going ahead for new features.
> >
> > So please let me know your view on maintaining different dt files in uboot.
> 
> Sounds like you have plenty of memory, actually. Is U-Boot the first
> thing to load?
> 
> I think it is important to use the same filename and have the same DT
> contents where they are present in U-Boot. But if you want to leave
> out nodes, etc., that seems OK to me. It should be easy enough to meld
> in the updates later.
> 
> I wonder if we should add a way to drop unused nodes for U-Boot
> proper, like we do for SPL?

We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
trim things down for tbs2910.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200603/89a4aaad/attachment.sig>

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Soeren Moch]

On 04.06.20 05:16, Tom Rini wrote:
> On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
>> Hi Rayagonda,
>>
>> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
>> <rayagonda.kokatanur@broadcom.com> wrote:
>>>
>>> Hi Simon,
>>>
>>> On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
>>>>
>>>> Hi Rayagonda,
>>>>
>>>> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
>>>> <rayagonda.kokatanur@broadcom.com> wrote:
>>>>>
>>>>> Hi Thomas,
>>>>>
>>>>> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
>>>>>>
>>>>>> Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
>>>>>>
>>>>>>> On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>
>>>>>>>> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
>>>>>>>>>>
>>>>>>>>>>> This is the second patch set series prepared on top of the
>>>>>>>>>>> first patch set ("add initial support for broadcom NS3 soc").
>>>>>>>>>>>
>>>>>>>>>>> This patch set will add following,
>>>>>>>>>>> -dt nodes and defconfig options for basic device like pinctrl,
>>>>>>>>>>>  gpio, mmc, qspi, wdt, i2c and pcie.
>>>>>>>>>>> -start wdt service
>>>>>>>>>>> -Enable GPT commands
>>>>>>>>>>> -Enable EXT4 and FAT fs support
>>>>>>>>>>
>>>>>>>>>> All of the dts changes not in a -u-boot.dtsi file either come from
>>>>>>>>>> mainline Linux or at least linux-next and have had some level upstream
>>>>>>>>>> review, right?  Thanks!
>>>>>>>>>
>>>>>>>>> Yes. All the DTS changes are merged in the Linux and are available at
>>>>>>>>> arch/arm64/boot/dts/broadcom/stingray/
>>>>>>>>
>>>>>>>> Great.  Please reference the release you're taking these from as that
>>>>>>>> will make future resyncs easier.  Thanks!
>>>>>>>
>>>>>>> It's Linux v5.6.
>>>>>>
>>>>>> What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
>>>>>> looked at the mainline Linux device trees and I couldn't easily see the
>>>>>> correspondence.  Will the renaming complicate synchronization?
>>>>>
>>>>> Do we need to maintain the same dt file between linux and uboot ?
>>>>> Also in uboot we don't enable all devices,  how do we handle this ?
>>>>
>>>> If there is no U-Boot driver for a particular node then it will be
>>>> ignored. It is easier to keep them in sync if they are the same in
>>>> U-Boot and Linux.
>>>>
>>>>> Please let me know.
>>>>
>>>> That is implied by your question above :-)
>>>
>>> NS3 board is derivative of the existing bcm95874t board
>>> (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
>>> Hence we have different dt for NS3 in Linux but it is not yet upstremed.
>>>
>>> I compared the dt file size between uboot and Linux.
>>> Uboot dt size = 9K
>>> Linux dt size  = 41K (32K extra)
>>>
>>> In uboot we have 8MB non-volatile SPI flash memory.
>>> Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
>>> space is allocated to other components
>>> like nitor/bnxt firmware image, DDR shmoo value and for backup image.
>>>
>>> uboot.bin is part of the fip.bin image. If we pull Linux dt files this
>>> will use extra 33K memory of allocated 1.5MB.
>>> This increase in 33K will reduce total memory availability for u-boot
>>> and other features (like ARM trusted firmware, Op-TEE OS) development
>>> in future.
>>> Hence we anticipate qpsi memory shortage going ahead for new features.
>>>
>>> So please let me know your view on maintaining different dt files in uboot.
>>
>> Sounds like you have plenty of memory, actually. Is U-Boot the first
>> thing to load?
>>
>> I think it is important to use the same filename and have the same DT
>> contents where they are present in U-Boot. But if you want to leave
>> out nodes, etc., that seems OK to me. It should be easy enough to meld
>> in the updates later.
>>
>> I wonder if we should add a way to drop unused nodes for U-Boot
>> proper, like we do for SPL?
>
> We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
> trim things down for tbs2910.
>
For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
it possible to also remove complete nodes? This would help even more for
size reduction, I think.

Soeren

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Tom Rini]

On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:
> On 04.06.20 05:16, Tom Rini wrote:
> > On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
> >> Hi Rayagonda,
> >>
> >> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> >> <rayagonda.kokatanur@broadcom.com> wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> >>>>
> >>>> Hi Rayagonda,
> >>>>
> >>>> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> >>>> <rayagonda.kokatanur@broadcom.com> wrote:
> >>>>>
> >>>>> Hi Thomas,
> >>>>>
> >>>>> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> >>>>>>
> >>>>>> Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> >>>>>>
> >>>>>>> On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> >>>>>>>>
> >>>>>>>> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> >>>>>>>>> Hi Tom,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> >>>>>>>>>>
> >>>>>>>>>>> This is the second patch set series prepared on top of the
> >>>>>>>>>>> first patch set ("add initial support for broadcom NS3 soc").
> >>>>>>>>>>>
> >>>>>>>>>>> This patch set will add following,
> >>>>>>>>>>> -dt nodes and defconfig options for basic device like pinctrl,
> >>>>>>>>>>>  gpio, mmc, qspi, wdt, i2c and pcie.
> >>>>>>>>>>> -start wdt service
> >>>>>>>>>>> -Enable GPT commands
> >>>>>>>>>>> -Enable EXT4 and FAT fs support
> >>>>>>>>>>
> >>>>>>>>>> All of the dts changes not in a -u-boot.dtsi file either come from
> >>>>>>>>>> mainline Linux or at least linux-next and have had some level upstream
> >>>>>>>>>> review, right?  Thanks!
> >>>>>>>>>
> >>>>>>>>> Yes. All the DTS changes are merged in the Linux and are available at
> >>>>>>>>> arch/arm64/boot/dts/broadcom/stingray/
> >>>>>>>>
> >>>>>>>> Great.  Please reference the release you're taking these from as that
> >>>>>>>> will make future resyncs easier.  Thanks!
> >>>>>>>
> >>>>>>> It's Linux v5.6.
> >>>>>>
> >>>>>> What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> >>>>>> looked at the mainline Linux device trees and I couldn't easily see the
> >>>>>> correspondence.  Will the renaming complicate synchronization?
> >>>>>
> >>>>> Do we need to maintain the same dt file between linux and uboot ?
> >>>>> Also in uboot we don't enable all devices,  how do we handle this ?
> >>>>
> >>>> If there is no U-Boot driver for a particular node then it will be
> >>>> ignored. It is easier to keep them in sync if they are the same in
> >>>> U-Boot and Linux.
> >>>>
> >>>>> Please let me know.
> >>>>
> >>>> That is implied by your question above :-)
> >>>
> >>> NS3 board is derivative of the existing bcm95874t board
> >>> (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> >>> Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> >>>
> >>> I compared the dt file size between uboot and Linux.
> >>> Uboot dt size = 9K
> >>> Linux dt size  = 41K (32K extra)
> >>>
> >>> In uboot we have 8MB non-volatile SPI flash memory.
> >>> Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> >>> space is allocated to other components
> >>> like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> >>>
> >>> uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> >>> will use extra 33K memory of allocated 1.5MB.
> >>> This increase in 33K will reduce total memory availability for u-boot
> >>> and other features (like ARM trusted firmware, Op-TEE OS) development
> >>> in future.
> >>> Hence we anticipate qpsi memory shortage going ahead for new features.
> >>>
> >>> So please let me know your view on maintaining different dt files in uboot.
> >>
> >> Sounds like you have plenty of memory, actually. Is U-Boot the first
> >> thing to load?
> >>
> >> I think it is important to use the same filename and have the same DT
> >> contents where they are present in U-Boot. But if you want to leave
> >> out nodes, etc., that seems OK to me. It should be easy enough to meld
> >> in the updates later.
> >>
> >> I wonder if we should add a way to drop unused nodes for U-Boot
> >> proper, like we do for SPL?
> >
> > We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
> > trim things down for tbs2910.
> >
> For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
> it possible to also remove complete nodes? This would help even more for
> size reduction, I think.

Ah, that I think not.  Another idea to keep in mind for the dtoc
enhancements perhaps?  There is very much a use case of having a dtb (or
set of dtbs) and a U-Boot (full or SPL) and not needing/wanting to pass
our DTB on to the OS so both discarding things from the DTB and from
U-Boot based on this knowledge would be great.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200605/a3f0ac48/attachment.sig>

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Walter Lozano]

Hi Tom,

On 5/6/20 12:05, Tom Rini wrote:
> On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:
>> On 04.06.20 05:16, Tom Rini wrote:
>>> On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
>>>> Hi Rayagonda,
>>>>
>>>> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
>>>> <rayagonda.kokatanur@broadcom.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Rayagonda,
>>>>>>
>>>>>> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
>>>>>> <rayagonda.kokatanur@broadcom.com> wrote:
>>>>>>> Hi Thomas,
>>>>>>>
>>>>>>> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
>>>>>>>> Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
>>>>>>>>
>>>>>>>>> On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>>> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
>>>>>>>>>>> Hi Tom,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>>>>> On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This is the second patch set series prepared on top of the
>>>>>>>>>>>>> first patch set ("add initial support for broadcom NS3 soc").
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch set will add following,
>>>>>>>>>>>>> -dt nodes and defconfig options for basic device like pinctrl,
>>>>>>>>>>>>>   gpio, mmc, qspi, wdt, i2c and pcie.
>>>>>>>>>>>>> -start wdt service
>>>>>>>>>>>>> -Enable GPT commands
>>>>>>>>>>>>> -Enable EXT4 and FAT fs support
>>>>>>>>>>>> All of the dts changes not in a -u-boot.dtsi file either come from
>>>>>>>>>>>> mainline Linux or at least linux-next and have had some level upstream
>>>>>>>>>>>> review, right?  Thanks!
>>>>>>>>>>> Yes. All the DTS changes are merged in the Linux and are available at
>>>>>>>>>>> arch/arm64/boot/dts/broadcom/stingray/
>>>>>>>>>> Great.  Please reference the release you're taking these from as that
>>>>>>>>>> will make future resyncs easier.  Thanks!
>>>>>>>>> It's Linux v5.6.
>>>>>>>> What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
>>>>>>>> looked at the mainline Linux device trees and I couldn't easily see the
>>>>>>>> correspondence.  Will the renaming complicate synchronization?
>>>>>>> Do we need to maintain the same dt file between linux and uboot ?
>>>>>>> Also in uboot we don't enable all devices,  how do we handle this ?
>>>>>> If there is no U-Boot driver for a particular node then it will be
>>>>>> ignored. It is easier to keep them in sync if they are the same in
>>>>>> U-Boot and Linux.
>>>>>>
>>>>>>> Please let me know.
>>>>>> That is implied by your question above :-)
>>>>> NS3 board is derivative of the existing bcm95874t board
>>>>> (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
>>>>> Hence we have different dt for NS3 in Linux but it is not yet upstremed.
>>>>>
>>>>> I compared the dt file size between uboot and Linux.
>>>>> Uboot dt size = 9K
>>>>> Linux dt size  = 41K (32K extra)
>>>>>
>>>>> In uboot we have 8MB non-volatile SPI flash memory.
>>>>> Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
>>>>> space is allocated to other components
>>>>> like nitor/bnxt firmware image, DDR shmoo value and for backup image.
>>>>>
>>>>> uboot.bin is part of the fip.bin image. If we pull Linux dt files this
>>>>> will use extra 33K memory of allocated 1.5MB.
>>>>> This increase in 33K will reduce total memory availability for u-boot
>>>>> and other features (like ARM trusted firmware, Op-TEE OS) development
>>>>> in future.
>>>>> Hence we anticipate qpsi memory shortage going ahead for new features.
>>>>>
>>>>> So please let me know your view on maintaining different dt files in uboot.
>>>> Sounds like you have plenty of memory, actually. Is U-Boot the first
>>>> thing to load?
>>>>
>>>> I think it is important to use the same filename and have the same DT
>>>> contents where they are present in U-Boot. But if you want to leave
>>>> out nodes, etc., that seems OK to me. It should be easy enough to meld
>>>> in the updates later.
>>>>
>>>> I wonder if we should add a way to drop unused nodes for U-Boot
>>>> proper, like we do for SPL?
>>> We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
>>> trim things down for tbs2910.
>>>
>> For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
>> it possible to also remove complete nodes? This would help even more for
>> size reduction, I think.
> Ah, that I think not.  Another idea to keep in mind for the dtoc
> enhancements perhaps?  There is very much a use case of having a dtb (or
> set of dtbs) and a U-Boot (full or SPL) and not needing/wanting to pass
> our DTB on to the OS so both discarding things from the DTB and from
> U-Boot based on this knowledge would be great.
>
This enhancement sounds more to extend the current u-boot.dtsi feature, 
to include just specific nodes in the dtb, which currently works for 
SPL. A first step towards this direction could be to add a configuration 
option to use the same DTB for? both SPL and U-Boot, which would be a 
reduced version if the proper u-boot.dtsi is found.

What do you think?

Regarding dtoc, currently is used to parse dtb and to convert this info 
to C structures, which doesn't seems to be the desired goal here.

Regards,

Walter

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Tom Rini]

On Fri, Jun 05, 2020 at 12:47:10PM -0300, Walter Lozano wrote:
> Hi Tom,
> 
> On 5/6/20 12:05, Tom Rini wrote:
> > On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:
> > > On 04.06.20 05:16, Tom Rini wrote:
> > > > On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
> > > > > Hi Rayagonda,
> > > > > 
> > > > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> > > > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > > > > Hi Simon,
> > > > > > 
> > > > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> > > > > > > Hi Rayagonda,
> > > > > > > 
> > > > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > > > > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > > > > > > Hi Thomas,
> > > > > > > > 
> > > > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > > > > > > > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > > > > > > > > 
> > > > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > This is the second patch set series prepared on top of the
> > > > > > > > > > > > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > This patch set will add following,
> > > > > > > > > > > > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > > > > > > > > > > > >   gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > > > > > > > > > > -start wdt service
> > > > > > > > > > > > > > -Enable GPT commands
> > > > > > > > > > > > > > -Enable EXT4 and FAT fs support
> > > > > > > > > > > > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > > > > > > > > > > > mainline Linux or at least linux-next and have had some level upstream
> > > > > > > > > > > > > review, right?  Thanks!
> > > > > > > > > > > > Yes. All the DTS changes are merged in the Linux and are available at
> > > > > > > > > > > > arch/arm64/boot/dts/broadcom/stingray/
> > > > > > > > > > > Great.  Please reference the release you're taking these from as that
> > > > > > > > > > > will make future resyncs easier.  Thanks!
> > > > > > > > > > It's Linux v5.6.
> > > > > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > > > > > looked at the mainline Linux device trees and I couldn't easily see the
> > > > > > > > > correspondence.  Will the renaming complicate synchronization?
> > > > > > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > > > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > > > > > > If there is no U-Boot driver for a particular node then it will be
> > > > > > > ignored. It is easier to keep them in sync if they are the same in
> > > > > > > U-Boot and Linux.
> > > > > > > 
> > > > > > > > Please let me know.
> > > > > > > That is implied by your question above :-)
> > > > > > NS3 board is derivative of the existing bcm95874t board
> > > > > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > > > > > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> > > > > > 
> > > > > > I compared the dt file size between uboot and Linux.
> > > > > > Uboot dt size = 9K
> > > > > > Linux dt size  = 41K (32K extra)
> > > > > > 
> > > > > > In uboot we have 8MB non-volatile SPI flash memory.
> > > > > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > > > > > space is allocated to other components
> > > > > > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> > > > > > 
> > > > > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > > > > > will use extra 33K memory of allocated 1.5MB.
> > > > > > This increase in 33K will reduce total memory availability for u-boot
> > > > > > and other features (like ARM trusted firmware, Op-TEE OS) development
> > > > > > in future.
> > > > > > Hence we anticipate qpsi memory shortage going ahead for new features.
> > > > > > 
> > > > > > So please let me know your view on maintaining different dt files in uboot.
> > > > > Sounds like you have plenty of memory, actually. Is U-Boot the first
> > > > > thing to load?
> > > > > 
> > > > > I think it is important to use the same filename and have the same DT
> > > > > contents where they are present in U-Boot. But if you want to leave
> > > > > out nodes, etc., that seems OK to me. It should be easy enough to meld
> > > > > in the updates later.
> > > > > 
> > > > > I wonder if we should add a way to drop unused nodes for U-Boot
> > > > > proper, like we do for SPL?
> > > > We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
> > > > trim things down for tbs2910.
> > > > 
> > > For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
> > > it possible to also remove complete nodes? This would help even more for
> > > size reduction, I think.
> > Ah, that I think not.  Another idea to keep in mind for the dtoc
> > enhancements perhaps?  There is very much a use case of having a dtb (or
> > set of dtbs) and a U-Boot (full or SPL) and not needing/wanting to pass
> > our DTB on to the OS so both discarding things from the DTB and from
> > U-Boot based on this knowledge would be great.
> > 
> This enhancement sounds more to extend the current u-boot.dtsi feature, to
> include just specific nodes in the dtb, which currently works for SPL. A
> first step towards this direction could be to add a configuration option to
> use the same DTB for? both SPL and U-Boot, which would be a reduced version
> if the proper u-boot.dtsi is found.
> 
> What do you think?

I think there's another RFC patch that dropped a ton of not-needed nodes
via the -u-boot.dtsi file but that's also less than ideal since it's
manual.

> Regarding dtoc, currently is used to parse dtb and to convert this info to C
> structures, which doesn't seems to be the desired goal here.

So, what made me think of dtoc is that we aren't so much tied to device
trees because we want device trees, but rather we're tied to device
trees because that's the common format for describing hardware in a
machine readable format.

While this is more appropriate to the RFC thread about tiny-DM or some
other idea, what keeps popping to my mind is that we have few cases
where the device tree we work from is being passed to us from some
outside source.  Most of the time we're being told at build time the
device tree, or sometimes trees, that will ever be used on a platform at
run time.  How can we use that information to discard never-will-be-used
information?  If we've turned the device trees to C, then we can <do
something I haven't figured out the details on> and have the linker
discard things.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200605/d3dd0c6d/attachment.sig>

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Walter Lozano]

Hi Tom.

On 5/6/20 15:22, Tom Rini wrote:
> On Fri, Jun 05, 2020 at 12:47:10PM -0300, Walter Lozano wrote:
>> Hi Tom,
>>
>> On 5/6/20 12:05, Tom Rini wrote:
>>> On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:
>>>> On 04.06.20 05:16, Tom Rini wrote:
>>>>> On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
>>>>>> Hi Rayagonda,
>>>>>>
>>>>>> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
>>>>>> <rayagonda.kokatanur@broadcom.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi Rayagonda,
>>>>>>>>
>>>>>>>> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
>>>>>>>> <rayagonda.kokatanur@broadcom.com> wrote:
>>>>>>>>> Hi Thomas,
>>>>>>>>>
>>>>>>>>> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
>>>>>>>>>> Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>>>>> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
>>>>>>>>>>>>> Hi Tom,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>>>>>>> On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is the second patch set series prepared on top of the
>>>>>>>>>>>>>>> first patch set ("add initial support for broadcom NS3 soc").
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch set will add following,
>>>>>>>>>>>>>>> -dt nodes and defconfig options for basic device like pinctrl,
>>>>>>>>>>>>>>>    gpio, mmc, qspi, wdt, i2c and pcie.
>>>>>>>>>>>>>>> -start wdt service
>>>>>>>>>>>>>>> -Enable GPT commands
>>>>>>>>>>>>>>> -Enable EXT4 and FAT fs support
>>>>>>>>>>>>>> All of the dts changes not in a -u-boot.dtsi file either come from
>>>>>>>>>>>>>> mainline Linux or at least linux-next and have had some level upstream
>>>>>>>>>>>>>> review, right?  Thanks!
>>>>>>>>>>>>> Yes. All the DTS changes are merged in the Linux and are available at
>>>>>>>>>>>>> arch/arm64/boot/dts/broadcom/stingray/
>>>>>>>>>>>> Great.  Please reference the release you're taking these from as that
>>>>>>>>>>>> will make future resyncs easier.  Thanks!
>>>>>>>>>>> It's Linux v5.6.
>>>>>>>>>> What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
>>>>>>>>>> looked at the mainline Linux device trees and I couldn't easily see the
>>>>>>>>>> correspondence.  Will the renaming complicate synchronization?
>>>>>>>>> Do we need to maintain the same dt file between linux and uboot ?
>>>>>>>>> Also in uboot we don't enable all devices,  how do we handle this ?
>>>>>>>> If there is no U-Boot driver for a particular node then it will be
>>>>>>>> ignored. It is easier to keep them in sync if they are the same in
>>>>>>>> U-Boot and Linux.
>>>>>>>>
>>>>>>>>> Please let me know.
>>>>>>>> That is implied by your question above :-)
>>>>>>> NS3 board is derivative of the existing bcm95874t board
>>>>>>> (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
>>>>>>> Hence we have different dt for NS3 in Linux but it is not yet upstremed.
>>>>>>>
>>>>>>> I compared the dt file size between uboot and Linux.
>>>>>>> Uboot dt size = 9K
>>>>>>> Linux dt size  = 41K (32K extra)
>>>>>>>
>>>>>>> In uboot we have 8MB non-volatile SPI flash memory.
>>>>>>> Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
>>>>>>> space is allocated to other components
>>>>>>> like nitor/bnxt firmware image, DDR shmoo value and for backup image.
>>>>>>>
>>>>>>> uboot.bin is part of the fip.bin image. If we pull Linux dt files this
>>>>>>> will use extra 33K memory of allocated 1.5MB.
>>>>>>> This increase in 33K will reduce total memory availability for u-boot
>>>>>>> and other features (like ARM trusted firmware, Op-TEE OS) development
>>>>>>> in future.
>>>>>>> Hence we anticipate qpsi memory shortage going ahead for new features.
>>>>>>>
>>>>>>> So please let me know your view on maintaining different dt files in uboot.
>>>>>> Sounds like you have plenty of memory, actually. Is U-Boot the first
>>>>>> thing to load?
>>>>>>
>>>>>> I think it is important to use the same filename and have the same DT
>>>>>> contents where they are present in U-Boot. But if you want to leave
>>>>>> out nodes, etc., that seems OK to me. It should be easy enough to meld
>>>>>> in the updates later.
>>>>>>
>>>>>> I wonder if we should add a way to drop unused nodes for U-Boot
>>>>>> proper, like we do for SPL?
>>>>> We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
>>>>> trim things down for tbs2910.
>>>>>
>>>> For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
>>>> it possible to also remove complete nodes? This would help even more for
>>>> size reduction, I think.
>>> Ah, that I think not.  Another idea to keep in mind for the dtoc
>>> enhancements perhaps?  There is very much a use case of having a dtb (or
>>> set of dtbs) and a U-Boot (full or SPL) and not needing/wanting to pass
>>> our DTB on to the OS so both discarding things from the DTB and from
>>> U-Boot based on this knowledge would be great.
>>>
>> This enhancement sounds more to extend the current u-boot.dtsi feature, to
>> include just specific nodes in the dtb, which currently works for SPL. A
>> first step towards this direction could be to add a configuration option to
>> use the same DTB for? both SPL and U-Boot, which would be a reduced version
>> if the proper u-boot.dtsi is found.
>>
>> What do you think?
> I think there's another RFC patch that dropped a ton of not-needed nodes
> via the -u-boot.dtsi file but that's also less than ideal since it's
> manual.
I see, thanks for clarifying.
>> Regarding dtoc, currently is used to parse dtb and to convert this info to C
>> structures, which doesn't seems to be the desired goal here.
> So, what made me think of dtoc is that we aren't so much tied to device
> trees because we want device trees, but rather we're tied to device
> trees because that's the common format for describing hardware in a
> machine readable format.
>
> While this is more appropriate to the RFC thread about tiny-DM or some
> other idea, what keeps popping to my mind is that we have few cases
> where the device tree we work from is being passed to us from some
> outside source.  Most of the time we're being told at build time the
> device tree, or sometimes trees, that will ever be used on a platform at
> run time.  How can we use that information to discard never-will-be-used
> information?  If we've turned the device trees to C, then we can <do
> something I haven't figured out the details on> and have the linker
> discard things.


I totally agree with you. From what I see there are several things we 
could do. Let's continue the discussion on the RFC thread about tiny-DM

Regards,

Walter

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Rayagonda Kokatanur]

Hi Simon,

On Thu, Jun 4, 2020 at 8:30 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Rayagonda,
>
> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> <rayagonda.kokatanur@broadcom.com> wrote:
> >
> > Hi Simon,
> >
> > On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > >
> > > > Hi Thomas,
> > > >
> > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > > > >
> > > > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > > > >
> > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > >>
> > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > > > >> > Hi Tom,
> > > > > >> >
> > > > > >> >
> > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > > > >> > >
> > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > > > >> > >
> > > > > >> > > > This is the second patch set series prepared on top of the
> > > > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > > >> > > >
> > > > > >> > > > This patch set will add following,
> > > > > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > >> > > > -start wdt service
> > > > > >> > > > -Enable GPT commands
> > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > >> > >
> > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > > > >> > > mainline Linux or at least linux-next and have had some level upstream
> > > > > >> > > review, right?  Thanks!
> > > > > >> >
> > > > > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > >>
> > > > > >> Great.  Please reference the release you're taking these from as that
> > > > > >> will make future resyncs easier.  Thanks!
> > > > > >
> > > > > > It's Linux v5.6.
> > > > >
> > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > looked at the mainline Linux device trees and I couldn't easily see the
> > > > > correspondence.  Will the renaming complicate synchronization?
> > > >
> > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > >
> > > If there is no U-Boot driver for a particular node then it will be
> > > ignored. It is easier to keep them in sync if they are the same in
> > > U-Boot and Linux.
> > >
> > > > Please let me know.
> > >
> > > That is implied by your question above :-)
> >
> > NS3 board is derivative of the existing bcm95874t board
> > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> >
> > I compared the dt file size between uboot and Linux.
> > Uboot dt size = 9K
> > Linux dt size  = 41K (32K extra)
> >
> > In uboot we have 8MB non-volatile SPI flash memory.
> > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > space is allocated to other components
> > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> >
> > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > will use extra 33K memory of allocated 1.5MB.
> > This increase in 33K will reduce total memory availability for u-boot
> > and other features (like ARM trusted firmware, Op-TEE OS) development
> > in future.
> > Hence we anticipate qpsi memory shortage going ahead for new features.
> >
> > So please let me know your view on maintaining different dt files in uboot.
>
> Sounds like you have plenty of memory, actually. Is U-Boot the first
> thing to load?
>
> I think it is important to use the same filename and have the same DT
> contents where they are present in U-Boot. But if you want to leave
> out nodes, etc., that seems OK to me. It should be easy enough to meld
> in the updates later.
>
> I wonder if we should add a way to drop unused nodes for U-Boot
> proper, like we do for SPL?

Thank you for your suggestion.

Right now linux dt files are not upstremed.
Upstreaming linux dt files first and then using the same in uboot will
delay these uboot patch merge.
Hence I am planning to do following,
1. Use one sample dt file with just few basic nodes so that uboot can
be built without any issues.
2. Parallely start linux dt file upstream.
3. Once the linux dt file gets merged, I will pull them into uboot and
submit a patch.

Please let me know.

Best regards,
Rayagonda


>
> Regards,
> Simon

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Simon Glass]

Hi Rayagonda,

On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Hi Simon,
>
> On Thu, Jun 4, 2020 at 8:30 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Rayagonda,
> >
> > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> > <rayagonda.kokatanur@broadcom.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Rayagonda,
> > > >
> > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > > >
> > > > > Hi Thomas,
> > > > >
> > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > > > > >
> > > > > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > > > > >
> > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > >>
> > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > > > > >> > Hi Tom,
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > > > > >> > >
> > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > > > > >> > >
> > > > > > >> > > > This is the second patch set series prepared on top of the
> > > > > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > > > >> > > >
> > > > > > >> > > > This patch set will add following,
> > > > > > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > > >> > > > -start wdt service
> > > > > > >> > > > -Enable GPT commands
> > > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > > >> > >
> > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > > > > >> > > mainline Linux or at least linux-next and have had some level upstream
> > > > > > >> > > review, right?  Thanks!
> > > > > > >> >
> > > > > > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > > >>
> > > > > > >> Great.  Please reference the release you're taking these from as that
> > > > > > >> will make future resyncs easier.  Thanks!
> > > > > > >
> > > > > > > It's Linux v5.6.
> > > > > >
> > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > > looked at the mainline Linux device trees and I couldn't easily see the
> > > > > > correspondence.  Will the renaming complicate synchronization?
> > > > >
> > > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > > >
> > > > If there is no U-Boot driver for a particular node then it will be
> > > > ignored. It is easier to keep them in sync if they are the same in
> > > > U-Boot and Linux.
> > > >
> > > > > Please let me know.
> > > >
> > > > That is implied by your question above :-)
> > >
> > > NS3 board is derivative of the existing bcm95874t board
> > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> > >
> > > I compared the dt file size between uboot and Linux.
> > > Uboot dt size = 9K
> > > Linux dt size  = 41K (32K extra)
> > >
> > > In uboot we have 8MB non-volatile SPI flash memory.
> > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > > space is allocated to other components
> > > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> > >
> > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > > will use extra 33K memory of allocated 1.5MB.
> > > This increase in 33K will reduce total memory availability for u-boot
> > > and other features (like ARM trusted firmware, Op-TEE OS) development
> > > in future.
> > > Hence we anticipate qpsi memory shortage going ahead for new features.
> > >
> > > So please let me know your view on maintaining different dt files in uboot.
> >
> > Sounds like you have plenty of memory, actually. Is U-Boot the first
> > thing to load?
> >
> > I think it is important to use the same filename and have the same DT
> > contents where they are present in U-Boot. But if you want to leave
> > out nodes, etc., that seems OK to me. It should be easy enough to meld
> > in the updates later.
> >
> > I wonder if we should add a way to drop unused nodes for U-Boot
> > proper, like we do for SPL?
>
> Thank you for your suggestion.
>
> Right now linux dt files are not upstremed.
> Upstreaming linux dt files first and then using the same in uboot will

U-Boot

> delay these uboot patch merge.
> Hence I am planning to do following,
> 1. Use one sample dt file with just few basic nodes so that uboot can
> be built without any issues.
> 2. Parallely start linux dt file upstream.
> 3. Once the linux dt file gets merged, I will pull them into uboot and
> submit a patch.
>
> Please let me know.

That sounds fine to me.

Regards,
Simon

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[Rayagonda Kokatanur]

On Mon, Jun 8, 2020 at 10:43 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Rayagonda,
>
> On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur
> <rayagonda.kokatanur@broadcom.com> wrote:
> >
> > Hi Simon,
> >
> > On Thu, Jun 4, 2020 at 8:30 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Rayagonda,
> > > > >
> > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > > > >
> > > > > > Hi Thomas,
> > > > > >
> > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > > > > > >
> > > > > > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > > > > > >
> > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >>
> > > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > > > > > >> > Hi Tom,
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >> > >
> > > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > > > > > >> > >
> > > > > > > >> > > > This is the second patch set series prepared on top of the
> > > > > > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > > > > >> > > >
> > > > > > > >> > > > This patch set will add following,
> > > > > > > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > > > >> > > > -start wdt service
> > > > > > > >> > > > -Enable GPT commands
> > > > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > > > >> > >
> > > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > > > > > >> > > mainline Linux or at least linux-next and have had some level upstream
> > > > > > > >> > > review, right?  Thanks!
> > > > > > > >> >
> > > > > > > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > > > >>
> > > > > > > >> Great.  Please reference the release you're taking these from as that
> > > > > > > >> will make future resyncs easier.  Thanks!
> > > > > > > >
> > > > > > > > It's Linux v5.6.
> > > > > > >
> > > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > > > looked at the mainline Linux device trees and I couldn't easily see the
> > > > > > > correspondence.  Will the renaming complicate synchronization?
> > > > > >
> > > > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > > > >
> > > > > If there is no U-Boot driver for a particular node then it will be
> > > > > ignored. It is easier to keep them in sync if they are the same in
> > > > > U-Boot and Linux.
> > > > >
> > > > > > Please let me know.
> > > > >
> > > > > That is implied by your question above :-)
> > > >
> > > > NS3 board is derivative of the existing bcm95874t board
> > > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > > > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> > > >
> > > > I compared the dt file size between uboot and Linux.
> > > > Uboot dt size = 9K
> > > > Linux dt size  = 41K (32K extra)
> > > >
> > > > In uboot we have 8MB non-volatile SPI flash memory.
> > > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > > > space is allocated to other components
> > > > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> > > >
> > > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > > > will use extra 33K memory of allocated 1.5MB.
> > > > This increase in 33K will reduce total memory availability for u-boot
> > > > and other features (like ARM trusted firmware, Op-TEE OS) development
> > > > in future.
> > > > Hence we anticipate qpsi memory shortage going ahead for new features.
> > > >
> > > > So please let me know your view on maintaining different dt files in uboot.
> > >
> > > Sounds like you have plenty of memory, actually. Is U-Boot the first
> > > thing to load?
> > >
> > > I think it is important to use the same filename and have the same DT
> > > contents where they are present in U-Boot. But if you want to leave
> > > out nodes, etc., that seems OK to me. It should be easy enough to meld
> > > in the updates later.
> > >
> > > I wonder if we should add a way to drop unused nodes for U-Boot
> > > proper, like we do for SPL?
> >
> > Thank you for your suggestion.
> >
> > Right now linux dt files are not upstremed.
> > Upstreaming linux dt files first and then using the same in uboot will
>
> U-Boot
>
> > delay these uboot patch merge.
> > Hence I am planning to do following,
> > 1. Use one sample dt file with just few basic nodes so that uboot can
> > be built without any issues.
> > 2. Parallely start linux dt file upstream.
> > 3. Once the linux dt file gets merged, I will pull them into uboot and
> > submit a patch.
> >
> > Please let me know.
>
> That sounds fine to me.

Thank you Simon.

>
> Regards,
> Simon

[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

[dphadke]

USB host node is missing from this patch series.

Driver was previously added here -
https://lists.denx.de/pipermail/u-boot/2020-April/405764.html

Linux arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi

Regards,
Dhananjay




--
Sent from: http://u-boot.10912.n7.nabble.com/