[PATCH v1 00/15] add basic driver support for broadcom NS3 soc
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
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
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
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
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
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@140000 { + compatible = "pinconf-single"; + reg = <0x00140000 0x250>; + pinctrl-single,register-width = <32>; + + /* pinconf functions */ + }; + + pinmux: pinmux@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@110000 { compatible = "snps,dw-apb-uart"; reg = <0x00110000 0x1000>;
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
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
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
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@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>; + }; }; };
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
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
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
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
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@3f1000 { + compatible = "brcm,iproc-sdhci"; + reg = <0x003f1000 0x100>; + bus-width = <8>; + clock-freq-min-max = <400000 200000000>; + index = <0>; + status = "disabled"; + }; + + sdio1: sdhci@3f2000 { + compatible = "brcm,iproc-sdhci"; + reg = <0x003f2000 0x100>; + bus-width = <8>; + clock-freq-min-max = <400000 200000000>; + index = <1>; + status = "disabled"; + }; + gpio_hsls: gpio@d0000 { compatible = "brcm,iproc-gpio"; reg = <0x000d0000 0x864>;
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
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
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
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@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@370000 { + compatible = "brcm,iproc-qspi"; + reg = <0x00370000 0x100>, + <0x00370100 0x100>, + <0x00370200 0x200>; + reg-names = "bspi", "bspi_raf", "mspi"; + status = "disabled"; + }; + sdio0: sdhci@3f1000 { compatible = "brcm,iproc-sdhci"; reg = <0x003f1000 0x100>;
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
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@b0000 { + compatible = "brcm,iproc-i2c"; + reg = <0xb0000 0x100>; + bus-frequency = <100000>; + }; + gpio_hsls: gpio@d0000 { compatible = "brcm,iproc-gpio"; reg = <0x000d0000 0x864>;
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
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@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@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@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@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@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@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@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@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@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@0,0 { + compatible = "pci-bridge"; + reg = <0x0000 0 0 0 0>; + }; + }; + + pcie_phy: phy@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>; + }; };
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
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
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
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
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
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
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
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@c0000 { + compatible = "arm,sp805-wdt"; + reg = <0x000c0000 0x1000>; + timeout-sec = <60>; + clocks = <&hsls_25m_div2_clk>; + };
uart1: uart@110000 { compatible = "snps,dw-apb-uart";
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
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 */
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
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!
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
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!
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
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
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
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
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
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
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.
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
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.
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
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.
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
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
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,
- 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
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,
- 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
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/
participants (7)
-
dphadke -
Rayagonda Kokatanur -
Simon Glass -
Soeren Moch -
Thomas Fitzsimmons -
Tom Rini -
Walter Lozano