Re: [RFC] pci: mediatek: add PCIe controller support for Filogic
Am 10. Mai 2024 15:08:19 MESZ schrieb Tom Rini : >On Fri, May 10, 2024 at 01:57:26PM +0200, Frank Wunderlich wrote: > >> a gentle ping...any comments? > >Seems fine? > Can we switch to OF_UPSTREAM first however? Pulling mediatek devicetrees from linux will afaik break network in uboot for mt7622,7623,mt7986 and mt7988 bananapi boards because switch (mt753x) binding is different to linux. regards Frank
Aw: [RFC] pci: mediatek: add PCIe controller support for Filogic
a gentle ping...any comments?
regards Frank
> Gesendet: Freitag, 12. April 2024 um 16:10 Uhr
> Von: "Frank Wunderlich"
> An: "Tom Rini" , "Lukasz Majewski" , "Sean
> Anderson" , "Ryder Lee" , "Weijie
> Gao" , "Chunfeng Yun" ,
> "GSS_MTK_Uboot_upstream" , "John
> Crispin"
> Cc: "Frank Wunderlich" , u-boot@lists.denx.de
> Betreff: [RFC] pci: mediatek: add PCIe controller support for Filogic
>
> From: John Crispin
>
> This adds PCIe controller support for the MediaTek Filogic family..
>
> Signed-off-by: John Crispin
> Signed-off-by: Frank Wunderlich
> ---
> Note for mt7988: pcie2 needs a dedicated phy which has no driver
> in uboot yet, so this pcie port is not enabled in the board device-
> trees.
>
> Note for mt7981: i have no board and have no dts nodes yet for it,
> so only clock change first.
> ---
> arch/arm/dts/mt7986.dtsi | 46 +++
> arch/arm/dts/mt7988-rfb.dts| 12 +
> arch/arm/dts/mt7988-sd-rfb.dts | 12 +
> arch/arm/dts/mt7988.dtsi | 164 +++
> drivers/clk/mediatek/clk-mt7986.c | 5 +-
> drivers/pci/Kconfig| 7 +
> drivers/pci/Makefile | 1 +
> drivers/pci/pcie_mediatek_gen3.c | 382 +
> include/dt-bindings/clock/mt7981-clk.h | 3 +-
> include/dt-bindings/clock/mt7986-clk.h | 3 +-
> 10 files changed, 631 insertions(+), 4 deletions(-)
> create mode 100644 drivers/pci/pcie_mediatek_gen3.c
>
> diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> index c9aeeaca2b11..9a9b0b64cc68 100644
> --- a/arch/arm/dts/mt7986.dtsi
> +++ b/arch/arm/dts/mt7986.dtsi
> @@ -375,5 +375,51 @@
> #phy-cells = <1>;
> status = "okay";
> };
> +
> + pcie_port: pcie-phy@11c0 {
> + reg = <0x11c0 0x2>;
> + clocks = <_clk>;
> + clock-names = "ref";
> + #phy-cells = <1>;
> + status = "okay";
> + };
> + };
> +
> + pcie: pcie@1128 {
> + compatible = "mediatek,mt7986-pcie",
> + "mediatek,mt8192-pcie";
> + device_type = "pci";
> + reg = <0x1128 0x4000>;
> + reg-names = "pcie-mac";
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + clocks = <_ao CK_INFRA_IPCIE_PIPE_CK>,
> + <_ao CK_INFRA_IPCIE_CK>,
> + <_ao CK_INFRA_IPCIER_CK>,
> + <_ao CK_INFRA_IPCIEB_CK>;
> + clock-names = "pl_250m", "tl_26m", "peri_26m", "top_133m";
> +
> + bus-range = <0x00 0xff>;
> + ranges = <0x8200 0 0x2000 0x2000 0 0x1000>;
> +
> + interrupts = ;
> + #interrupt-cells = <2>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 _intc 0>, /* INTA */
> + <0 0 0 2 _intc 1>, /* INTB */
> + <0 0 0 3 _intc 2>, /* INTC */
> + <0 0 0 4 _intc 3>; /* INTD */
> +
> + phy-names = "pcie-phy";
> + phys = <_port PHY_TYPE_PCIE>;
> +
> + status = "okay";
> +
> + pcie_intc: legacy-interrupt-controller {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> };
> };
> diff --git a/arch/arm/dts/mt7988-rfb.dts b/arch/arm/dts/mt7988-rfb.dts
> index 2c1142843091..2f0d00b6950b 100644
> --- a/arch/arm/dts/mt7988-rfb.dts
> +++ b/arch/arm/dts/mt7988-rfb.dts
> @@ -180,3 +180,15 @@
> non-removable;
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/mt7988-sd-rfb.dts b/arch/arm/dts/mt7988-sd-rfb.dts
> index a3df37d252de..0a3eb5360d21 100644
> --- a/arch/arm/dts/mt7988-sd-rfb.dts
> +++ b/arch/arm/dts/mt7988-sd-rfb.dts
> @@ -132,3 +132,15 @@
> vqmmc-supply = <_3p3v>;
> status
[RFC] pci: mediatek: add PCIe controller support for Filogic
From: John Crispin
This adds PCIe controller support for the MediaTek Filogic family..
Signed-off-by: John Crispin
Signed-off-by: Frank Wunderlich
---
Note for mt7988: pcie2 needs a dedicated phy which has no driver
in uboot yet, so this pcie port is not enabled in the board device-
trees.
Note for mt7981: i have no board and have no dts nodes yet for it,
so only clock change first.
---
arch/arm/dts/mt7986.dtsi | 46 +++
arch/arm/dts/mt7988-rfb.dts| 12 +
arch/arm/dts/mt7988-sd-rfb.dts | 12 +
arch/arm/dts/mt7988.dtsi | 164 +++
drivers/clk/mediatek/clk-mt7986.c | 5 +-
drivers/pci/Kconfig| 7 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_mediatek_gen3.c | 382 +
include/dt-bindings/clock/mt7981-clk.h | 3 +-
include/dt-bindings/clock/mt7986-clk.h | 3 +-
10 files changed, 631 insertions(+), 4 deletions(-)
create mode 100644 drivers/pci/pcie_mediatek_gen3.c
diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
index c9aeeaca2b11..9a9b0b64cc68 100644
--- a/arch/arm/dts/mt7986.dtsi
+++ b/arch/arm/dts/mt7986.dtsi
@@ -375,5 +375,51 @@
#phy-cells = <1>;
status = "okay";
};
+
+ pcie_port: pcie-phy@11c0 {
+ reg = <0x11c0 0x2>;
+ clocks = <_clk>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
+ pcie: pcie@1128 {
+ compatible = "mediatek,mt7986-pcie",
+"mediatek,mt8192-pcie";
+ device_type = "pci";
+ reg = <0x1128 0x4000>;
+ reg-names = "pcie-mac";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <_ao CK_INFRA_IPCIE_PIPE_CK>,
+<_ao CK_INFRA_IPCIE_CK>,
+<_ao CK_INFRA_IPCIER_CK>,
+<_ao CK_INFRA_IPCIEB_CK>;
+ clock-names = "pl_250m", "tl_26m", "peri_26m", "top_133m";
+
+ bus-range = <0x00 0xff>;
+ ranges = <0x8200 0 0x2000 0x2000 0 0x1000>;
+
+ interrupts = ;
+ #interrupt-cells = <2>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 0>, /* INTA */
+ <0 0 0 2 _intc 1>, /* INTB */
+ <0 0 0 3 _intc 2>, /* INTC */
+ <0 0 0 4 _intc 3>; /* INTD */
+
+ phy-names = "pcie-phy";
+ phys = <_port PHY_TYPE_PCIE>;
+
+ status = "okay";
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
};
};
diff --git a/arch/arm/dts/mt7988-rfb.dts b/arch/arm/dts/mt7988-rfb.dts
index 2c1142843091..2f0d00b6950b 100644
--- a/arch/arm/dts/mt7988-rfb.dts
+++ b/arch/arm/dts/mt7988-rfb.dts
@@ -180,3 +180,15 @@
non-removable;
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/mt7988-sd-rfb.dts b/arch/arm/dts/mt7988-sd-rfb.dts
index a3df37d252de..0a3eb5360d21 100644
--- a/arch/arm/dts/mt7988-sd-rfb.dts
+++ b/arch/arm/dts/mt7988-sd-rfb.dts
@@ -132,3 +132,15 @@
vqmmc-supply = <_3p3v>;
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/mt7988.dtsi b/arch/arm/dts/mt7988.dtsi
index ac476d5cdd7f..b2e2724732fc 100644
--- a/arch/arm/dts/mt7988.dtsi
+++ b/arch/arm/dts/mt7988.dtsi
@@ -194,6 +194,152 @@
status = "okay";
};
+ pcie2: pcie@1128 {
+ compatible = "mediatek,mt7988-pcie",
+"mediatek,mt7986-pcie",
+"mediatek,mt8192-pcie";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <0 0x1128 0 0x2000>;
+ reg-names = "pcie-mac";
+ linux,pci-domain = <3>;
+ interrupts = ;
+ bus-range = <0x00 0xff>;
+
[PATCH v6] board: rockchip: Add Bananapi R2Pro Board
From: Frank Wunderlich
Add Bananapi R2 Pro board.
tested:
- sdcard
- both front usb-ports
- sata
- wan-port
lan-ports are connected to mt7531 switch where driver needs to be
separated from mtk ethernet-driver.
Signed-off-by: Frank Wunderlich
Reviewed-by: Kever Yang
Reviewed-by: Jonas Karlman
---
because iodomain is different to evb and now iodomain driver is sent as
patch we need to separate between EVB and R2Pro else board can be bricked.
ethernet support depends on these series from jonas:
rockchip: Port IO-domain driver for RK3568 from linux
https://patchwork.ozlabs.org/project/uboot/cover/20230821223020.3918620-1-jo...@kwiboo.se/
and
rockchip: Add GMAC support for RK3568 and RK3588
https://patchwork.ozlabs.org/project/uboot/cover/20230807000817.1701012-1-jo...@kwiboo.se/
---
v6:
- fix missing dtb extension in CONFIG_DEFAULT_FDT_FILE
- drop CONFIG_REGULATOR_PWM
- add RBs
- board name in maintainers file full uppercase
v5:
- add line break in description
- reorder in makefile
- drop special dts-handling
(deletion of switchnode, disable of usb and gmac0)
- add MAINTAINERS entry
- changes to defconfig suggested by jonas
- remove "pinctrl-0 pinctrl-names" from CONFIG_OF_SPL_REMOVE_PROPS
- add CONFIG_SPL_DM_SEQ_ALIAS=y
- add CONFIG_SPL_PINCTRL=y
- remove CONFIG_USB_UHCI_HCD
- enable EFI_LOADER (defaults to y)
- drop CONFIG_SYSRESET_PSCI (reset works without)
v4:
- add r2pro board to readme
- update r2pro dts to linux version
- remove switch node from linux dts
- disable gmac0 because switch driver does not work yet
to solve timeout error:
ethernet@fe2a Waiting for PHY auto negotiation to complete.
TIMEOUT!
phy_startup() failed: -110FAILED: -110ethernet@fe01 Waiting for PHY auto
nee
- cleanup r2pro u-boot.dtsi like jonas suggests
- update and reorder defconfig based on jonas suggestions
- dts: disable usb_host0_ohci because of error on usb-start
scanning bus usb@fd84 for devices...
ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN)
or did
not provide a handshake (OUT) (5)
unable to get device descriptor (error=-1)
- pcie is not yet working, so not adding these options
rockchip_pcie3phy phy@fe8c: lock failed 0x689
rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
pcie_dw_rockchip pcie@fe27: failed to init phy (ret=-110)
rockchip_pcie3phy phy@fe8c: lock failed 0x689
rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
pcie_dw_rockchip pcie@fe28: failed to init phy (ret=-110)
- emmc not tested as it is empty on my board because it breaks sdcard boot
- rename dts and defconfig (add minus sign)
- enable efi_loader in defconfig
v3:
- disable gmac0 as switch-driver is not yet ready to attach to the mac
v2:
- drop switch-node for now as u-boot driver works differently to linux
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi | 19 +
arch/arm/dts/rk3568-bpi-r2-pro.dts | 852 +
board/rockchip/evb_rk3568/MAINTAINERS | 7 +
configs/bpi-r2-pro-rk3568_defconfig| 93 +++
doc/board/rockchip/rockchip.rst| 1 +
6 files changed, 973 insertions(+)
create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro.dts
create mode 100644 configs/bpi-r2-pro-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bde2176ec7f6..fba7dfed26ba 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -177,6 +177,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-soquartz-blade.dtb \
rk3566-soquartz-cm4.dtb \
rk3566-soquartz-model-a.dtb \
+ rk3568-bpi-r2-pro.dtb \
rk3568-evb.dtb \
rk3568-lubancat-2.dtb \
rk3568-nanopi-r5c.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
b/arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
new file mode 100644
index ..60a3b21f2d45
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-pre-ram;
+ status = "okay";
+};
+
diff --git a/arch/arm/dts/rk3568-bpi-r2-pro.dts
b/arch/arm/dts/rk3568-bpi-r2-pro.dts
new file mode 100644
index ..f9127ddfbb7d
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
@@ -0,0 +1,852 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+ compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568"
Aw: Re: [PATCH v5] board: rockchip: Add Bananapi R2Pro Board
Hi Jonas thanks for your review. > Gesendet: Dienstag, 03. Oktober 2023 um 22:27 Uhr > Von: "Jonas Karlman" > An: "Frank Wunderlich" , "Frank Wunderlich" > , "Kever Yang" > Cc: "Simon Glass" , "Philipp Tomsich" > , "Joseph Chen" , > u-boot@lists.denx.de > Betreff: Re: [PATCH v5] board: rockchip: Add Bananapi R2Pro Board > > Hi Frank, > > On 2023-09-20 20:40, Frank Wunderlich wrote: > > From: Frank Wunderlich > > > > Add Bananapi R2 Pro board. > > > > tested: > > - sdcard > > - both front usb-ports > > - sata > > - wan-port > > > > lan-ports are connected to mt7531 switch where driver needs to be > > separated from mtk ethernet-driver. > > > > Signed-off-by: Frank Wunderlich > > --- > > because iodomain is different to evb and now iodomain driver is sent as > > patch we need to separate between EVB and R2Pro else board can be bricked. > > > > ethernet support depends on these series from jonas: > > > > rockchip: Port IO-domain driver for RK3568 from linux > > https://patchwork.ozlabs.org/project/uboot/cover/20230821223020.3918620-1-jo...@kwiboo.se/ > > and > > rockchip: Add GMAC support for RK3568 and RK3588 > > https://patchwork.ozlabs.org/project/uboot/cover/20230807000817.1701012-1-jo...@kwiboo.se/ > > --- > > v5: > > - add line break in description > > - reorder in makefile > > - drop special dts-handling > > (deletion of switchnode, disable of usb and gmac0) > > - add MAINTAINERS entry > > - changes to defconfig suggested by jonas > > - remove "pinctrl-0 pinctrl-names" from CONFIG_OF_SPL_REMOVE_PROPS > > - add CONFIG_SPL_DM_SEQ_ALIAS=y > > - add CONFIG_SPL_PINCTRL=y > > - remove CONFIG_USB_UHCI_HCD > > - enable EFI_LOADER (defaults to y) > > - drop CONFIG_SYSRESET_PSCI (reset works without) > > > > v4: > > - add r2pro board to readme > > - update r2pro dts to linux version > > - remove switch node from linux dts > > - disable gmac0 because switch driver does not work yet > > to solve timeout error: > > ethernet@fe2a Waiting for PHY auto negotiation to complete. > > TIMEOUT! > > phy_startup() failed: -110FAILED: -110ethernet@fe01 Waiting for PHY > > auto nee > > - cleanup r2pro u-boot.dtsi like jonas suggests > > - update and reorder defconfig based on jonas suggestions > > - dts: disable usb_host0_ohci because of error on usb-start > > scanning bus usb@fd84 for devices... > > ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token > > (IN) or did > > not provide a handshake (OUT) (5) > > unable to get device descriptor (error=-1) > > - pcie is not yet working, so not adding these options > > rockchip_pcie3phy phy@fe8c: lock failed 0x689 > > rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110. > > pcie_dw_rockchip pcie@fe27: failed to init phy (ret=-110) > > rockchip_pcie3phy phy@fe8c: lock failed 0x689 > > rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110. > > pcie_dw_rockchip pcie@fe28: failed to init phy (ret=-110) > > - emmc not tested as it is empty on my board because it breaks sdcard boot > > - rename dts and defconfig (add minus sign) > > - enable efi_loader in defconfig > > > > v3: > > - disable gmac0 as switch-driver is not yet ready to attach to the mac > > > > v2: > > - drop switch-node for now as u-boot driver works differently to linux > > --- > > arch/arm/dts/Makefile | 1 + > > arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi | 19 + > > arch/arm/dts/rk3568-bpi-r2-pro.dts | 852 + > > board/rockchip/evb_rk3568/MAINTAINERS | 7 + > > configs/bpi-r2-pro-rk3568_defconfig| 94 +++ > > doc/board/rockchip/rockchip.rst| 1 + > > 6 files changed, 974 insertions(+) > > create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi > > create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro.dts > > create mode 100644 configs/bpi-r2-pro-rk3568_defconfig > > > > [...] > > > diff --git a/board/rockchip/evb_rk3568/MAINTAINERS > > b/board/rockchip/evb_rk3568/MAINTAINERS > > index cc9eb432a8b5..8c506162c01e 100644 > > --- a/board/rockchip/evb_rk3568/MAINTAINERS > > +++ b/board/rockchip/evb_rk3568/MAINTAINERS > > @@ -7,6 +7,13 @@ F: configs/evb-rk3568_defconfig > > F: arch/arm/dts/rk3568-evb-u-boot.dtsi >
Aw: Re: Re: [PATCH v2 0/7] rockchip: rk3568: Fix use of PCIe bifurcation
Hi Jonas, > Gesendet: Montag, 02. Oktober 2023 um 10:33 Uhr > Von: "Jonas Karlman" > An: "Frank Wunderlich" , "Sebastian Reichel" > > Cc: "Kever Yang" , "Simon Glass" > , "Philipp Tomsich" , "Eugen > Hristev" , "Jon Lin" , > "FUKAUMI Naoki" , "John Clark" , > u-boot@lists.denx.de > Betreff: Re: Aw: Re: [PATCH v2 0/7] rockchip: rk3568: Fix use of PCIe > bifurcation > > Hi Frank, > > On 2023-10-02 09:17, Frank Wunderlich wrote: > > Hi, > > > >> Gesendet: Sonntag, 01. Oktober 2023 um 21:11 Uhr > >> Von: "Sebastian Reichel" > >> An: "Jonas Karlman" > >> Cc: "Kever Yang" , "Simon Glass" > >> , "Philipp Tomsich" , "Eugen > >> Hristev" , "Jon Lin" > >> , "FUKAUMI Naoki" , "John Clark" > >> , u-boot@lists.denx.de > >> Betreff: Re: [PATCH v2 0/7] rockchip: rk3568: Fix use of PCIe bifurcation > >> > >> Hi, > >> > >> On Wed, Sep 27, 2023 at 06:07:59PM +, Jonas Karlman wrote: > >>> Above works with this series in U-Boot and also in mainline linux. Not > >>> sure the RK3588 bifurcation part of driver have been verified on real HW, > >>> rk3588 boards available for testing have typicality not used bifurcation. > >> > >> Upstream kernel bifurcation code looks ok to me. It's quite different > >> from Rockchip vendor implementation, which might have confused Kever. > >> I also missed this when having a quick look initially. As you said > >> Rock 5A, Rock 5B and EVB1 do not use bifurcation, so no testing happened > >> on our side. > > > > my Bananapi R2Pro (rk3568) uses bifurcation and it is working in mainline > > Linux, but not yet in uboot. > > The issue on your Bananapi R2Pro is most likely not related to the > pcie bifurcation code added in this series. > > The coded added in this series works same/very similar as on mainline > linux and fixes bifurcation use on devices such as Radxa E25 and NanoPi > R5C/R5S. > > Please clarify if pcie work in mainline linux when booting with mainline > u-boot, or does it only work when booting with vendor u-boot? (in case > vendor u-boot set different/default pinconf). > > > > > posted my test-results here: > > https://patchwork.ozlabs.org/project/uboot/patch/20230918173624.31464-1-li...@fw-web.de/#3183519 > > From your pci enum command I only see an expected pcie@fe27 (ngff) > link fail. Does it also print out link fail for pcie@fe28 (minipcie)? good catch, you're right, no message of mpcie, only ngff (no card) #initial status (before enabling pcie-related regulators) BPI-R2PRO> regulator status Name EnableduV mA Mode Status vdd_logicenabled90 - - 0 vdd_gpu enabled90 - - 0 vcc_ddr enabled50 - - 0 vdd_npu disabled 50 - - 0 vcc_1v8 enabled 180 - - 0 vdda0v9_imageenabled90 - - 0 vdda_0v9 enabled90 - - 0 vdda0v9_pmu enabled90 - - 0 vccio_acodec enabled 330 - - 0 vccio_sd enabled 330 - - 0 vcc3v3_pmu enabled 330 - - 0 vcca_1v8 enabled 180 - - 0 vcca1v8_pmu enabled 180 - - 0 vcca1v8_imageenabled 180 - - 0 vcc_3v3 enabled 0 - - 0 vcc3v3_sdenabled 0 - - 0 dc_12v enabled 1200 - - 0 vcc3v3_sys enabled 330 - - 0 vcc5v0_sys enabled 500 - - 0 pcie30_avdd0v9 enabled90 - - 0 pcie30_avdd1v8 enabled 180 - - 0 vcc3v3_pcie disabled 330 - - 0 vcc3v3_minipcie disabled 330 - - 0 vcc3v3_ngff disabled 330 - - 0 vcc5v0_usb enabled 500 - - 0 vcc5v0_usb_host disabled 500 - - 0 vcc5v0_usb_otg disabled 500 - - 0 BPI-R2PRO> regulator dev vcc3v3_pcie dev: vcc3v3_pcie @ vcc3v3-pi6c-05-regulator BP
Aw: Re: [PATCH v2 0/7] rockchip: rk3568: Fix use of PCIe bifurcation
Hi, > Gesendet: Sonntag, 01. Oktober 2023 um 21:11 Uhr > Von: "Sebastian Reichel" > An: "Jonas Karlman" > Cc: "Kever Yang" , "Simon Glass" > , "Philipp Tomsich" , "Eugen > Hristev" , "Jon Lin" , > "FUKAUMI Naoki" , "John Clark" , > u-boot@lists.denx.de > Betreff: Re: [PATCH v2 0/7] rockchip: rk3568: Fix use of PCIe bifurcation > > Hi, > > On Wed, Sep 27, 2023 at 06:07:59PM +, Jonas Karlman wrote: > > Above works with this series in U-Boot and also in mainline linux. Not > > sure the RK3588 bifurcation part of driver have been verified on real HW, > > rk3588 boards available for testing have typicality not used bifurcation. > > Upstream kernel bifurcation code looks ok to me. It's quite different > from Rockchip vendor implementation, which might have confused Kever. > I also missed this when having a quick look initially. As you said > Rock 5A, Rock 5B and EVB1 do not use bifurcation, so no testing happened > on our side. my Bananapi R2Pro (rk3568) uses bifurcation and it is working in mainline Linux, but not yet in uboot. posted my test-results here: https://patchwork.ozlabs.org/project/uboot/patch/20230918173624.31464-1-li...@fw-web.de/#3183519 regards Frank
Aw: Re: [PATCH v5] board: rockchip: Add Bananapi R2Pro Board
Hi Thank you kever for review. Tom can you take this and the depencies into next release (2024-01)? regards Frank > Gesendet: Mittwoch, 27. September 2023 um 04:42 Uhr > Von: "Kever Yang" > An: "Frank Wunderlich" , u-boot@lists.denx.de > Cc: "Frank Wunderlich" , "Simon Glass" > , "Philipp Tomsich" , "Joseph > Chen" , "Jonas Karlman" > Betreff: Re: [PATCH v5] board: rockchip: Add Bananapi R2Pro Board > > > On 2023/9/21 02:40, Frank Wunderlich wrote: > > From: Frank Wunderlich > > > > Add Bananapi R2 Pro board. > > > > tested: > > - sdcard > > - both front usb-ports > > - sata > > - wan-port > > > > lan-ports are connected to mt7531 switch where driver needs to be > > separated from mtk ethernet-driver. > > > > Signed-off-by: Frank Wunderlich > Reviewed-by: Kever Yang > > Thanks, > - Kever > > --- > > because iodomain is different to evb and now iodomain driver is sent as > > patch we need to separate between EVB and R2Pro else board can be bricked. > > > > ethernet support depends on these series from jonas: > > > > rockchip: Port IO-domain driver for RK3568 from linux > > https://patchwork.ozlabs.org/project/uboot/cover/20230821223020.3918620-1-jo...@kwiboo.se/ > > and > > rockchip: Add GMAC support for RK3568 and RK3588 > > https://patchwork.ozlabs.org/project/uboot/cover/20230807000817.1701012-1-jo...@kwiboo.se/
Aw: Re: github dependabot alert on py / pytest
> Gesendet: Samstag, 30. September 2023 um 16:44 Uhr > Von: "Tom Rini" > An: "Frank Wunderlich" > Cc: "u-bootlists.denx.de" > Betreff: Re: github dependabot alert on py / pytest > > On Sat, Sep 30, 2023 at 03:13:30PM +0200, Frank Wunderlich wrote: > > Hi, > > > > dependabot reports a high security issue > > > > https://github.com/frank-w/u-boot/security/dependabot/1 > > > > it seems it is not yet fixed in master and next as there py is still in and > > pytest==6.2.5 > > > > I have not yet seen any topics for this...are you aware of this? I know > > tests are run in > > isolated environment through gitlab-pipeline, but maybe this can have still > > a risk. > > The dependabot requests aren't public. But I don't see one myself when > pushing to GitHub, can you please elaborate on what it's saying we > should have updated? it says py-package is affected till 1.11.0 and pytest after 7.2.0 does not have requirement for it... so dropping py package and upgrade pytest to at least 7.2.0 should be the right fix i guess you do not use subversion (so basicly no security issue), but maybe we can fix this by upgrading pytest to avoid the alerts in future full report: ReDoS in py library when used with subversion #1 Package: py (pip) Affected versions: <= 1.11.0 Patched version: None The py library through 1.11.0 for Python allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data, because the InfoSvnCommand argument is mishandled. The particular codepath in question is the regular expression at py._path.svnurl.InfoSvnCommand.lspattern and is only relevant when dealing with subversion (svn) projects. Notably the codepath is not used in the popular pytest project. The developers of the pytest package have released version 7.2.0 which removes their dependency on py. Users of pytest seeing alerts relating to this advisory may update to version 7.2.0 of pytest to resolve this issue. See https://github.com/pytest-dev/py/issues/287#issuecomment-1290407715 (comment) for additional context. Severity High 7.5 / 10 CVSS base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Tags Direct dependency Weaknesses Weakness CWE-1333 CVE ID CVE-2022-42969 regards Frank
github dependabot alert on py / pytest
Hi, dependabot reports a high security issue https://github.com/frank-w/u-boot/security/dependabot/1 it seems it is not yet fixed in master and next as there py is still in and pytest==6.2.5 I have not yet seen any topics for this...are you aware of this? I know tests are run in isolated environment through gitlab-pipeline, but maybe this can have still a risk. regards Frank
[PATCH v5] board: rockchip: Add Bananapi R2Pro Board
From: Frank Wunderlich
Add Bananapi R2 Pro board.
tested:
- sdcard
- both front usb-ports
- sata
- wan-port
lan-ports are connected to mt7531 switch where driver needs to be
separated from mtk ethernet-driver.
Signed-off-by: Frank Wunderlich
---
because iodomain is different to evb and now iodomain driver is sent as
patch we need to separate between EVB and R2Pro else board can be bricked.
ethernet support depends on these series from jonas:
rockchip: Port IO-domain driver for RK3568 from linux
https://patchwork.ozlabs.org/project/uboot/cover/20230821223020.3918620-1-jo...@kwiboo.se/
and
rockchip: Add GMAC support for RK3568 and RK3588
https://patchwork.ozlabs.org/project/uboot/cover/20230807000817.1701012-1-jo...@kwiboo.se/
---
v5:
- add line break in description
- reorder in makefile
- drop special dts-handling
(deletion of switchnode, disable of usb and gmac0)
- add MAINTAINERS entry
- changes to defconfig suggested by jonas
- remove "pinctrl-0 pinctrl-names" from CONFIG_OF_SPL_REMOVE_PROPS
- add CONFIG_SPL_DM_SEQ_ALIAS=y
- add CONFIG_SPL_PINCTRL=y
- remove CONFIG_USB_UHCI_HCD
- enable EFI_LOADER (defaults to y)
- drop CONFIG_SYSRESET_PSCI (reset works without)
v4:
- add r2pro board to readme
- update r2pro dts to linux version
- remove switch node from linux dts
- disable gmac0 because switch driver does not work yet
to solve timeout error:
ethernet@fe2a Waiting for PHY auto negotiation to complete.
TIMEOUT!
phy_startup() failed: -110FAILED: -110ethernet@fe01 Waiting for PHY auto
nee
- cleanup r2pro u-boot.dtsi like jonas suggests
- update and reorder defconfig based on jonas suggestions
- dts: disable usb_host0_ohci because of error on usb-start
scanning bus usb@fd84 for devices...
ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN)
or did
not provide a handshake (OUT) (5)
unable to get device descriptor (error=-1)
- pcie is not yet working, so not adding these options
rockchip_pcie3phy phy@fe8c: lock failed 0x689
rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
pcie_dw_rockchip pcie@fe27: failed to init phy (ret=-110)
rockchip_pcie3phy phy@fe8c: lock failed 0x689
rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
pcie_dw_rockchip pcie@fe28: failed to init phy (ret=-110)
- emmc not tested as it is empty on my board because it breaks sdcard boot
- rename dts and defconfig (add minus sign)
- enable efi_loader in defconfig
v3:
- disable gmac0 as switch-driver is not yet ready to attach to the mac
v2:
- drop switch-node for now as u-boot driver works differently to linux
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi | 19 +
arch/arm/dts/rk3568-bpi-r2-pro.dts | 852 +
board/rockchip/evb_rk3568/MAINTAINERS | 7 +
configs/bpi-r2-pro-rk3568_defconfig| 94 +++
doc/board/rockchip/rockchip.rst| 1 +
6 files changed, 974 insertions(+)
create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro.dts
create mode 100644 configs/bpi-r2-pro-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85fd5b1157b1..016eb5556513 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -177,6 +177,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-soquartz-blade.dtb \
rk3566-soquartz-cm4.dtb \
rk3566-soquartz-model-a.dtb \
+ rk3568-bpi-r2-pro.dtb \
rk3568-evb.dtb \
rk3568-lubancat-2.dtb \
rk3568-nanopi-r5c.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
b/arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
new file mode 100644
index ..60a3b21f2d45
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2-pro-u-boot.dtsi
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-pre-ram;
+ status = "okay";
+};
+
diff --git a/arch/arm/dts/rk3568-bpi-r2-pro.dts
b/arch/arm/dts/rk3568-bpi-r2-pro.dts
new file mode 100644
index ..f9127ddfbb7d
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
@@ -0,0 +1,852 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+ compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen: chosen {
+ stdout-path =
Aw: Re: [PATCH v4] board: rockchip: Add Bananapi R2Pro Board
Hi Jonas > Gesendet: Montag, 18. September 2023 um 23:45 Uhr > Von: "Jonas Karlman" > An: "Frank Wunderlich" > Cc: "Frank Wunderlich" , "Simon Glass" > , "Philipp Tomsich" , "Kever > Yang" , u-boot@lists.denx.de > Betreff: Re: [PATCH v4] board: rockchip: Add Bananapi R2Pro Board > > Hi Frank, > > On 2023-09-18 19:36, Frank Wunderlich wrote: > > From: Frank Wunderlich > > > > Add Bananapi R2 Pro board. > > > > tested: > > - sdcard > > - both front usb-ports > > - sata > > - wan-port > > > > lan-ports are connected to mt7531 switch where driver needs to be separated > > from mtk ethernet-driver. > > > > Signed-off-by: Frank Wunderlich > > --- > > because iodomain is different to evb and now iodomain driver is sent as > > patch we need to separate between EVB and R2Pro else board can be bricked. > > --- > > v4: > > - add r2pro board to readme > > - update r2pro dts to linux version > > - remove switch node from linux dts > > - disable gmac0 because switch driver does not work yet > > to solve timeout error: > > ethernet@fe2a Waiting for PHY auto negotiation to complete. > > TIMEOUT! > > phy_startup() failed: -110FAILED: -110ethernet@fe01 Waiting for PHY > > auto nee > > - cleanup r2pro u-boot.dtsi like jonas suggests > > - update and reorder defconfig based on jonas suggestions > > - dts: disable usb_host0_ohci because of error on usb-start > > scanning bus usb@fd84 for devices... > > ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token > > (IN) or did > > not provide a handshake (OUT) (5) > > unable to get device descriptor (error=-1) > > - pcie is not yet working, so not adding these options > > rockchip_pcie3phy phy@fe8c: lock failed 0x689 > > rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110. > > pcie_dw_rockchip pcie@fe27: failed to init phy (ret=-110) > > rockchip_pcie3phy phy@fe8c: lock failed 0x689 > > rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110. > > pcie_dw_rockchip pcie@fe28: failed to init phy (ret=-110) > > Looks like this board use PCIe bifurcation and would depend on my rk35xx > PCIe bifurcation series to at least have a chance to work. (looks like > it is applied based on your log rows). yes i have added your series to my tree... https://github.com/frank-w/u-boot/commits/2023-10-bpi-r2pro_2 and yes, board uses bifurcation to split pcie3 to an mPCIe slot and an m.2 slot. > Could there be an issue with a regulator not being enabled in time? > Please use regulator cmd to enable all regulators prior to running the > pci enum cmd, and see if that changes anything. at least the output changes... there are 3 pcie-regulators, first is for clock vcc3v3_pcie disabled 330 - - 0 vcc3v3_minipcie disabled 330 - - 0 vcc3v3_ngff disabled 330 - - 0 BPI-R2PRO> regulator dev vcc3v3_pcie dev: vcc3v3_pcie @ vcc3v3-pi6c-05-regulator BPI-R2PRO> regulator enable BPI-R2PRO> regulator dev vcc3v3_minipcie dev: vcc3v3_minipcie @ vcc3v3-minipcie-regulator BPI-R2PRO> regulator enable vcc3v3_pcie enabled 330 - - 0 vcc3v3_minipcie enabled 330 - - 0 vcc3v3_ngff disabled 330 - - 0 BPI-R2PRO> pci enum pcie_dw_rockchip pcie@fe27: PCIe-0 Link Fail (card is in mpcie-slot) > > - emmc not tested as it is empty on my board because it breaks sdcard boot > > > > v3: > > - disable gmac0 as switch-driver is not yet ready to attach to the mac > > > > v2: > > - drop switch-node for now as u-boot driver works differently to linux > > --- > > arch/arm/dts/Makefile | 3 +- > > arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 28 + > > arch/arm/dts/rk3568-bpi-r2pro.dts | 852 ++ > > configs/bpi-r2pro-rk3568_defconfig| 95 +++ > > doc/board/rockchip/rockchip.rst | 1 + > > 5 files changed, 978 insertions(+), 1 deletion(-) > > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi > > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts > > The DT file is named rk3568-bpi-r2-pro.dts in linux, please use same > name in U-Boot. Same goes for defconfig-file, please name it > bpi-r2-pro-rk3568_defconfig to match DT filename. > > > create mode 100644 configs/bpi-r2pro-rk3568_defconfig > >
Re: [PATCH v4] board: rockchip: Add Bananapi R2Pro Board
Am 18. September 2023 20:59:55 MESZ schrieb Mark Kettenis
:
>> Date: Mon, 18 Sep 2023 20:09:54 +0200
>> From: Frank Wunderlich
>>
>> Am 18. September 2023 19:52:31 MESZ schrieb Mark Kettenis
>> :
>> >> From: Frank Wunderlich
>> >> Date: Mon, 18 Sep 2023 19:36:24 +0200
>>
>> Hi Mark,
>
>Hello Frank,
>
>> >> --- /dev/null
>> >> +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
>> >> @@ -0,0 +1,28 @@
>> >> +// SPDX-License-Identifier: GPL-2.0+
>> >> +/*
>> >> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
>> >> + */
>> >> +
>> >> +#include "rk356x-u-boot.dtsi"
>> >> +
>> >> +/ {
>> >> + chosen {
>> >> + stdout-path =
>> >> + };
>> >> +};
>> >> +
>> >> + {
>> >> + clock-frequency = <2400>;
>> >> + bootph-pre-ram;
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> + {
>> >> + status = "disabled";
>> >> +};
>> >> +
>> >> +/delete-node/ &{/ethernet@fe2a/mdio/switch@0};
>> >
>> >Why are you deleting the switch node? This way an OS that uses the
>> >device tree provided by U-boot will not have a working switch...
>>
>> Is there such an OS?
>
>Yes, OpenBSD tends to rely on the device tree provided by U-Boot. It
>is impossible to include device trees for all possible boards on the
>installation media. And if U-Boot provides the device tree for the
>board we don't need to (as long as the device tree uses the "official"
>bindings).
>
>> Linux uses own dts.
>
>Well, Linux *may* use its own dts. Some boards never make it in the
>official Linux tree. Or a generic Linux distro may use a kernel that
>was released before the board made it to the market. So generic Linux
>distros face the same problem as OpenBSD in that it isn't practical to
>include device trees for every possible board on the installation
>media.
>
>So the goal is that U-Boot provides a usable device tree for as many
>boards as possible.
>
>> The switch will also not work because the gmac0 is deactivated to
>> fix the timeout in uboot because phy does not answer.
>
>I missed that. But that is a bug in U-Boot that should be fixed.
>Probably by adding support for "fixed-link" switch ports. Now I
>appreciate that having a U-Boot that partly works is better than no
>U-Boot at all. So that may justify what you did. However...
I'm not sure if it is the fixed link that causes the
timeout or that switch is not initialized due to
missing driver. I guess last one...
>> I can leave the switch-node, but i do not want the timeout on network access
>> on gmac0.
>
>...such a timeout could be seen as a reminder that the work isn't
>finished yet.
I wanted to work cleanly on u-boot,but of course i
can send without these "fixes" and add them in
my own tree if this is the better way.
>> >> + {
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> +
>> >> + switch@0 {
>> >> + compatible = "mediatek,mt7531";
>> >> + reg = <0>;
>> >> +
>> >> + ports {
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> +
>> >> + port@1 {
>> >> + reg = <1>;
>> >> + label = "lan0";
>> >> + };
>> >> +
>> >> + port@2 {
>> >> + reg = <2>;
>> >> + label = "lan1";
>> >> + };
>> >> +
>> >> + port@3 {
>> >> + reg = <3>;
>> >> + label = "lan2";
>> >> + };
>> >> +
>> >> + port@4 {
>> >> + reg = <4>;
>> >> + label = "lan3";
>> >> + };
>> >> +
>> >> + port@5 {
>> >> + reg = <5>;
>> >> + label = "cpu";
>> >> + ethernet = <>;
>> >> + phy-mode = "rgmii";
>> >> +
>> >> + fixed-link {
>> >> + speed = <1000>;
>> >> + full-duplex;
>> >> + pause;
>> >> + };
>> >> + };
>> >> + };
>> >> + };
>> >> +};
>>
>>
>> regards Frank
>>
regards Frank
Re: [PATCH v4] board: rockchip: Add Bananapi R2Pro Board
Am 18. September 2023 19:52:31 MESZ schrieb Mark Kettenis
:
>> From: Frank Wunderlich
>> Date: Mon, 18 Sep 2023 19:36:24 +0200
Hi Mark,
>> --- /dev/null
>> +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
>> @@ -0,0 +1,28 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
>> + */
>> +
>> +#include "rk356x-u-boot.dtsi"
>> +
>> +/ {
>> +chosen {
>> +stdout-path =
>> +};
>> +};
>> +
>> + {
>> +clock-frequency = <2400>;
>> +bootph-pre-ram;
>> +status = "okay";
>> +};
>> +
>> + {
>> +status = "disabled";
>> +};
>> +
>> +/delete-node/ &{/ethernet@fe2a/mdio/switch@0};
>
>Why are you deleting the switch node? This way an OS that uses the
>device tree provided by U-boot will not have a working switch...
Is there such an OS? Linux uses own dts.
The switch will also not work because the gmac0 is deactivated to fix the
timeout in uboot because phy does not answer.
I can leave the switch-node, but i do not want the timeout on network access on
gmac0.
>> + {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +switch@0 {
>> +compatible = "mediatek,mt7531";
>> +reg = <0>;
>> +
>> +ports {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +port@1 {
>> +reg = <1>;
>> +label = "lan0";
>> +};
>> +
>> +port@2 {
>> +reg = <2>;
>> +label = "lan1";
>> +};
>> +
>> +port@3 {
>> +reg = <3>;
>> +label = "lan2";
>> +};
>> +
>> +port@4 {
>> +reg = <4>;
>> +label = "lan3";
>> +};
>> +
>> +port@5 {
>> +reg = <5>;
>> +label = "cpu";
>> +ethernet = <>;
>> +phy-mode = "rgmii";
>> +
>> +fixed-link {
>> +speed = <1000>;
>> +full-duplex;
>> +pause;
>> +};
>> +};
>> +};
>> +};
>> +};
regards Frank
[PATCH v4] board: rockchip: Add Bananapi R2Pro Board
From: Frank Wunderlich
Add Bananapi R2 Pro board.
tested:
- sdcard
- both front usb-ports
- sata
- wan-port
lan-ports are connected to mt7531 switch where driver needs to be separated
from mtk ethernet-driver.
Signed-off-by: Frank Wunderlich
---
because iodomain is different to evb and now iodomain driver is sent as
patch we need to separate between EVB and R2Pro else board can be bricked.
---
v4:
- add r2pro board to readme
- update r2pro dts to linux version
- remove switch node from linux dts
- disable gmac0 because switch driver does not work yet
to solve timeout error:
ethernet@fe2a Waiting for PHY auto negotiation to complete.
TIMEOUT!
phy_startup() failed: -110FAILED: -110ethernet@fe01 Waiting for PHY auto
nee
- cleanup r2pro u-boot.dtsi like jonas suggests
- update and reorder defconfig based on jonas suggestions
- dts: disable usb_host0_ohci because of error on usb-start
scanning bus usb@fd84 for devices...
ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN)
or did
not provide a handshake (OUT) (5)
unable to get device descriptor (error=-1)
- pcie is not yet working, so not adding these options
rockchip_pcie3phy phy@fe8c: lock failed 0x689
rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
pcie_dw_rockchip pcie@fe27: failed to init phy (ret=-110)
rockchip_pcie3phy phy@fe8c: lock failed 0x689
rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
pcie_dw_rockchip pcie@fe28: failed to init phy (ret=-110)
- emmc not tested as it is empty on my board because it breaks sdcard boot
v3:
- disable gmac0 as switch-driver is not yet ready to attach to the mac
v2:
- drop switch-node for now as u-boot driver works differently to linux
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 28 +
arch/arm/dts/rk3568-bpi-r2pro.dts | 852 ++
configs/bpi-r2pro-rk3568_defconfig| 95 +++
doc/board/rockchip/rockchip.rst | 1 +
5 files changed, 978 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
create mode 100644 configs/bpi-r2pro-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85fd5b1157b1..71c557e87e9e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -183,7 +183,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-nanopi-r5s.dtb \
rk3568-odroid-m1.dtb \
rk3568-radxa-e25.dtb \
- rk3568-rock-3a.dtb
+ rk3568-rock-3a.dtb \
+ rk3568-bpi-r2pro.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
new file mode 100644
index ..089e54f8cece
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-pre-ram;
+ status = "okay";
+};
+
+ {
+ status = "disabled";
+};
+
+/delete-node/ &{/ethernet@fe2a/mdio/switch@0};
+
+_host0_ohci {
+ status = "disabled";
+};
diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
b/arch/arm/dts/rk3568-bpi-r2pro.dts
new file mode 100644
index ..f9127ddfbb7d
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
@@ -0,0 +1,852 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+ compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pin _led_pin>;
+
+ blue_led: led-0 {
+ color = ;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+ };
+
+ green_led: led-1 {
+ color = ;
+ default-state = "on";
+ function = LED_FUNCTION_POWER;
+ gpios = < RK_PD5 GPIO_ACTIVE_HIGH>
Aw: Re: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
Hi,
thank you for your suggestions
> Gesendet: Sonntag, 17. September 2023 um 00:51 Uhr
> Von: "Jonas Karlman"
> An: "Frank Wunderlich"
> Cc: "Frank Wunderlich" , "Simon Glass"
> , "Philipp Tomsich" , "Kever
> Yang" , "Marek Vasut" ,
> u-boot@lists.denx.de
> Betreff: Re: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
>
> Hi Frank,
>
> On 2023-08-20 18:00, Frank Wunderlich wrote:
> > From: Frank Wunderlich
> >
> > Add Bananapi R2 Pro board.
> >
> > Till now evb dts could be used, but iodomain is different
> > (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro)
> > and with iodomain driver this can cause hardware fault.
> >
> > Devicetree in mainline-Linux:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> >
> > Signed-off-by: Frank Wunderlich
> > ---
> > v3:
> > - disable gmac0 as switch-driver is not yet ready to attach to the mac
> > v2:
> > - drop switch-node for now as u-boot driver works differently to linux
> > ---
> > arch/arm/dts/Makefile | 3 +-
> > arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 +
> > arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++
> > configs/bpi-r2pro-rk3568_defconfig| 101
> > 4 files changed, 675 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
> > create mode 100644 configs/bpi-r2pro-rk3568_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index bd518064f35f..767bf9db39fb 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> > rk3568-nanopi-r5s.dtb \
> > rk3568-odroid-m1.dtb \
> > rk3568-radxa-e25.dtb \
> > - rk3568-rock-3a.dtb
> > + rk3568-rock-3a.dtb \
> > + rk3568-bpi-r2pro.dtb
> >
> > dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> > rk3588-edgeble-neu6a-io.dtb \
> > diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > new file mode 100644
> > index ..382a52a28b10
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > @@ -0,0 +1,23 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> > + */
> > +
> > +#include "rk356x-u-boot.dtsi"
> > +
> > +/ {
> > + chosen {
> > + stdout-path =
> > + u-boot,spl-boot-order = "same-as-spl", ,
>
> This is the default order in rk356x-u-boot.dtsi and can be dropped.
>
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
>
> sdmmc0 is already enabled in rk3568-bpi-r2pro.dts
>
> > +};
> > +
> > + {
> > + clock-frequency = <2400>;
> > + bootph-pre-ram;
> > + status = "okay";
> > +};
then i have only the uart here...right? do you remember i missed the
-uboot.dtsi in first try and board does not find mmc in spl.
do i really not need the first 2 nodes here?
> > diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
> > b/arch/arm/dts/rk3568-bpi-r2pro.dts
> > new file mode 100644
> > index ..e4fcbb8a1174
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
>
> Should be a 1:1 copy from kernel.
i try to do so, but this will result in many nodes not used in uboot like the
switch i remove in the dtsi and graphics.
thx for pointing to the pcie driver then i can let these nodes in.
> [...]
>
> > diff --git a/configs/bpi-r2pro-rk3568_defconfig
> > b/configs/bpi-r2pro-rk3568_defconfig
> > new file mode 100644
> > index ..e8936261eab3
> > --- /dev/null
> > +++ b/configs/bpi-r2pro-rk3568_defconfig
> > @@ -0,0 +1,101 @@
> > +CONFIG_ARM=y
> > +CONFIG_SKIP_LOWLEVEL_INIT=y
> > +CONFIG_COUNTER_FREQUENCY=2400
> > +CONFIG_ARCH_ROCKCHIP=y
> > +CONFIG_TEXT_BASE=0x00a0
> > +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > +CONFIG_NR_DRAM_BANKS=2
> > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
> > +CONFIG_DEFAULT_DEVICE_TREE="rk3568-bpi-r2pro"
> > +CONFIG_ROCKCHIP_RK3568=y
> > +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> > +CONFIG_SPL_SERIA
Re: Aw: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
Am 16. September 2023 18:07:44 MESZ schrieb Marek Vasut : >On 9/16/23 16:18, Frank Wunderlich wrote: >> Hi, >> >> just a friedly reminder. would be great if it can be merged in next >> uboot-version. > >+CC Tom > >> regards Frank >> >> >>> Gesendet: Sonntag, 20. August 2023 um 18:00 Uhr >>> Von: "Frank Wunderlich" >>> An: u-boot@lists.denx.de >>> Cc: "Frank Wunderlich" , "Simon Glass" >>> , "Philipp Tomsich" , "Kever >>> Yang" , "Marek Vasut" , "Jonas >>> Karlman" >>> Betreff: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board >>> >>> From: Frank Wunderlich >>> >>> Add Bananapi R2 Pro board. >>> >>> Till now evb dts could be used, but iodomain is different >>> (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro) >>> and with iodomain driver this can cause hardware fault. >>> >>> Devicetree in mainline-Linux: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts > >What would be real helpful is a commit ID from which the DT was copied , so it >can be easily updated in the future. It is no plain copy...i removed parts not relevant for uboot now (from current linux version). E.g. switch driver is currently bundled in mtk ethernet driver and using different devicetree structure than linux dsa driver. We have to separate it before we can use it on r2pro. But this will take some time...also pcie(-phy) does not have a driver yet,so before adding dead code i dropped these parts for now. regards Frank
Aw: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
Hi, just a friedly reminder. would be great if it can be merged in next uboot-version. regards Frank > Gesendet: Sonntag, 20. August 2023 um 18:00 Uhr > Von: "Frank Wunderlich" > An: u-boot@lists.denx.de > Cc: "Frank Wunderlich" , "Simon Glass" > , "Philipp Tomsich" , "Kever > Yang" , "Marek Vasut" , "Jonas > Karlman" > Betreff: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board > > From: Frank Wunderlich > > Add Bananapi R2 Pro board. > > Till now evb dts could be used, but iodomain is different > (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro) > and with iodomain driver this can cause hardware fault. > > Devicetree in mainline-Linux: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts > > Signed-off-by: Frank Wunderlich > --- > v3: > - disable gmac0 as switch-driver is not yet ready to attach to the mac > v2: > - drop switch-node for now as u-boot driver works differently to linux > --- > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 + > arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++ > configs/bpi-r2pro-rk3568_defconfig| 101 > 4 files changed, 675 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts > create mode 100644 configs/bpi-r2pro-rk3568_defconfig
[PATCH v3] board: rockchip: Add Bananapi R2Pro Board
From: Frank Wunderlich
Add Bananapi R2 Pro board.
Till now evb dts could be used, but iodomain is different
(evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro)
and with iodomain driver this can cause hardware fault.
Devicetree in mainline-Linux:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
Signed-off-by: Frank Wunderlich
---
v3:
- disable gmac0 as switch-driver is not yet ready to attach to the mac
v2:
- drop switch-node for now as u-boot driver works differently to linux
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 +
arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++
configs/bpi-r2pro-rk3568_defconfig| 101
4 files changed, 675 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
create mode 100644 configs/bpi-r2pro-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bd518064f35f..767bf9db39fb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-nanopi-r5s.dtb \
rk3568-odroid-m1.dtb \
rk3568-radxa-e25.dtb \
- rk3568-rock-3a.dtb
+ rk3568-rock-3a.dtb \
+ rk3568-bpi-r2pro.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
new file mode 100644
index ..382a52a28b10
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-pre-ram;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
b/arch/arm/dts/rk3568-bpi-r2pro.dts
new file mode 100644
index ..e4fcbb8a1174
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
@@ -0,0 +1,549 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+ compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pin _led_pin>;
+
+ blue_led: led-0 {
+ color = ;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+ };
+
+ green_led: led-1 {
+ color = ;
+ default-state = "on";
+ function = LED_FUNCTION_POWER;
+ gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dc_12v: dc-12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_usb: vcc5v0-usb-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usb&quo
Re: [PATCH] arm: dts: mediatek: convert gmac link mode to 2500base-x for r3
Am 18. August 2023 19:49:45 MESZ schrieb Tom Rini :
>On Thu, Aug 03, 2023 at 06:52:58PM +0200, Frank Wunderlich wrote:
>
>> From: Frank Wunderlich
>>
>> Ethernet on Bananapi-r3 is broken after
>>
>> commit bd70f3cea353 ("net: mediatek: add support for SGMII 1Gbps
>> auto-negotiation mode")
>>
>> because changes from this commit were not applied to bpi-r3 devicetree too:
>>
>> commit aef54ea16cac ("arm: dts: medaitek: convert gmac link mode to
>> 2500base-x")
>>
>> Signed-off-by: Frank Wunderlich
>> Reviewed-by: Weijie Gao
>
>Applied to u-boot/next, thanks!
>
>--
>Tom
Thx,but this leaves ethernet broken on 2023.10 for r3...could this be added to
this release too?
regards Frank
Re: [PATCH v1] board: rockchip: Add Bananapi R2Pro Board
Am 12. August 2023 03:50:14 MESZ schrieb Kever Yang :
>Hi Frank,
>
>On 2023/8/8 01:14, Frank Wunderlich wrote:
>> From: Frank Wunderlich
>>
>> Add rk3568 based Bananapi R2 Pro board.
>>
>> Signed-off-by: Frank Wunderlich
>> ---
>> because iodomain is different to evb and now iodomain driver is sent as
>> patch we need to separate between EVB and R2Pro else board can be bricked.
>What's the detail difference before and after the iodomain driver for this
>board?
Sorry, missed this question somehow.
Evb defines these iodomains
_io_domains {
pmuio1-supply = <_pmu>;
pmuio2-supply = <_pmu>;
vccio1-supply = <_acodec>;
vccio2-supply = <_1v8>;
vccio3-supply = <_sd>;
vccio4-supply = <_1v8>;
vccio5-supply = <_3v3>;
vccio6-supply = <_1v8>;
vccio7-supply = <_3v3>;
status = "okay";
};
So vccio2 and vccio4 are 1v8 too which will brick these 2 io if still using
this dts on r2pro which has these 2 3v3 (default).
>> diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
>> b/arch/arm/dts/rk3568-bpi-r2pro.dts
>> new file mode 100644
>> index ..9295e9836a56
>> --- /dev/null
>> +++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
...
>> +_io_domains {
>> +pmuio1-supply = <_pmu>;
>> +pmuio2-supply = <_pmu>;
>> +vccio1-supply = <_acodec>;
>> +vccio3-supply = <_sd>;
>> +vccio4-supply = <_3v3>;
>> +vccio5-supply = <_3v3>;
>> +vccio6-supply = <_1v8>;
>> +vccio7-supply = <_3v3>;
>> +status = "okay";
>> +};
regards Frank
Aw: Re: [PATCH v1] board: rockchip: Add Bananapi R2Pro Board
Hi > Gesendet: Samstag, 12. August 2023 um 03:50 Uhr > Von: "Kever Yang" > An: "Frank Wunderlich" , u-boot@lists.denx.de > Cc: "Frank Wunderlich" , "Simon Glass" > , "Philipp Tomsich" , "Jonas > Karlman" , "Jagan Teki" , "zhangqing" > > Betreff: Re: [PATCH v1] board: rockchip: Add Bananapi R2Pro Board > > Hi Frank, > > On 2023/8/8 01:14, Frank Wunderlich wrote: > > From: Frank Wunderlich > > > > Add rk3568 based Bananapi R2 Pro board. > > > > Signed-off-by: Frank Wunderlich > > --- > > because iodomain is different to evb and now iodomain driver is sent as > > patch we need to separate between EVB and R2Pro else board can be bricked. > What's the detail difference before and after the iodomain driver for > this board? > > --- > > arch/arm/dts/Makefile | 3 +- > > arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 + > > arch/arm/dts/rk3568-bpi-r2pro.dts | 597 ++ > > Does this dts already available in mainline kernel, if yes, please > add info in commit message. yes: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts should i really add this link to commit description? i tried to leave dts compatible with linux dts and only added relevant parts, but switch-driver works differently in uboot so i dropped it in v2 (and plan to disable gmac in v3). have not yet tried ethernet. only bootup, usb and sata (mmc is same as evb). as u-boot doesn't care iodomain till jonas patches i have used evb devicetree/defconfig, but if this gets activated and users do not recognize this they brick their board. So imho this should be added before iodomain gets enabled in evb defconfig. > Thanks, > > - Kever
Aw: Re: [PATCH v2] board: rockchip: Add Bananapi R2Pro Board
Hi
thx for first look
> Gesendet: Dienstag, 08. August 2023 um 13:18 Uhr
> Von: "Eugen Hristev"
> Hi Frank,
>
> On 8/8/23 11:09, Frank Wunderlich wrote:
> > From: Frank Wunderlich
> >
> > Add Bananapi R2 Pro board.
> >
> > Signed-off-by: Frank Wunderlich
> > ---
> > because iodomain is different to evb and now iodomain driver is sent as
> > patch we need to separate between EVB and R2Pro else board can be bricked.
> > ---
> > v2:
> > - drop switch-node for now as u-boot driver works differently to linux
> > ---
> > arch/arm/dts/Makefile | 3 +-
> > arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 +
> > arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++
> > configs/bpi-r2pro-rk3568_defconfig| 101
> > 4 files changed, 675 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
> > create mode 100644 configs/bpi-r2pro-rk3568_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index bd518064f35f..767bf9db39fb 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> > rk3568-nanopi-r5s.dtb \
> > rk3568-odroid-m1.dtb \
> > rk3568-radxa-e25.dtb \
> > - rk3568-rock-3a.dtb
> > + rk3568-rock-3a.dtb \
> > + rk3568-bpi-r2pro.dtb
> >
> > dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> > rk3588-edgeble-neu6a-io.dtb \
> > diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > new file mode 100644
> > index ..382a52a28b10
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> > @@ -0,0 +1,23 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> > + */
> > +
> > +#include "rk356x-u-boot.dtsi"
>
> Isn't rk356x-u-boot.dtsi automatically included if rk356x.dtsi is included ?
afaik this -u-boot file is for SPL and i need it to boot successful. This adds
nodes for DRAM and
MMC needed in first boot stage.
I based this file, dts and defconfig on the EVB.
> > +
> > +/ {
> > + chosen {
> > + stdout-path =
> > + u-boot,spl-boot-order = "same-as-spl", ,
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + clock-frequency = <2400>;
> > + bootph-pre-ram;
> > + status = "okay";
> > +};
> > diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
> > b/arch/arm/dts/rk3568-bpi-r2pro.dts
> > new file mode 100644
> > index ..d99f29ab0bcb
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
> > @@ -0,0 +1,549 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Author: Frank Wunderlich
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +#include
> > +#include
> > +#include
> > +#include "rk3568.dtsi"
> ... as it's included here and rk3568.dtsi includes rk356x.dtsi
yes, but this DTS is used for second stage and not taken for SPL.
> > diff --git a/configs/bpi-r2pro-rk3568_defconfig
> > b/configs/bpi-r2pro-rk3568_defconfig
> > new file mode 100644
> > index ..e8936261eab3
> > --- /dev/null
> > +++ b/configs/bpi-r2pro-rk3568_defconfig
> > @@ -0,0 +1,101 @@
> > +CONFIG_ARM=y
> > +CONFIG_SKIP_LOWLEVEL_INIT=y
> > +CONFIG_COUNTER_FREQUENCY=2400
> > +CONFIG_ARCH_ROCKCHIP=y
> > +CONFIG_TEXT_BASE=0x00a0
> > +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > +CONFIG_NR_DRAM_BANKS=2
> > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
> > +CONFIG_DEFAULT_DEVICE_TREE="rk3568-bpi-r2pro"
> > +CONFIG_ROCKCHIP_RK3568=y
> > +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> > +CONFIG_SPL_SERIAL=y
> > +CONFIG_SPL_STACK_R_ADDR=0x60
> > +CONFIG_SPL_STACK=0x40
> > +CONFIG_DEBUG_UART_BASE=0xFE66
> > +CONFIG_DEBUG_UART_CLOCK=2400
> > +CONFIG_SYS_LOAD_ADDR=0xc00800
> > +CONFIG_DEBUG_UART=y
> > +CONFIG_FIT=y
> > +CONFIG_FIT_VERBOSE=y
> > +CONFIG_SPL_FIT_SIGNATURE=y
> > +CONFIG_SPL_LOAD_FIT=y
> > +CONFIG_LEGACY_IMAGE_FORMAT=y
> > +#CONFIG_OF_SYSTEM_SETUP=y
> > +CONFIG_DEFAULT_FDT_FILE=&quo
[PATCH v2] board: rockchip: Add Bananapi R2Pro Board
From: Frank Wunderlich
Add Bananapi R2 Pro board.
Signed-off-by: Frank Wunderlich
---
because iodomain is different to evb and now iodomain driver is sent as
patch we need to separate between EVB and R2Pro else board can be bricked.
---
v2:
- drop switch-node for now as u-boot driver works differently to linux
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 +
arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++
configs/bpi-r2pro-rk3568_defconfig| 101
4 files changed, 675 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
create mode 100644 configs/bpi-r2pro-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bd518064f35f..767bf9db39fb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-nanopi-r5s.dtb \
rk3568-odroid-m1.dtb \
rk3568-radxa-e25.dtb \
- rk3568-rock-3a.dtb
+ rk3568-rock-3a.dtb \
+ rk3568-bpi-r2pro.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
new file mode 100644
index ..382a52a28b10
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-pre-ram;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
b/arch/arm/dts/rk3568-bpi-r2pro.dts
new file mode 100644
index ..d99f29ab0bcb
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
@@ -0,0 +1,549 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+ compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pin _led_pin>;
+
+ blue_led: led-0 {
+ color = ;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+ };
+
+ green_led: led-1 {
+ color = ;
+ default-state = "on";
+ function = LED_FUNCTION_POWER;
+ gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dc_12v: dc-12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_usb: vcc5v0-usb-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usb";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_usb_host:
Aw: Re: [PATCH v1] board: rockchip: Add Bananapi R2Pro Board
> Gesendet: Montag, 07. August 2023 um 19:20 Uhr > Von: "Pali Rohár" > Could you stop sending me these rockchip emails? What is not > understandable on the fact that I'm not rockchip maintainer? > https://lists.denx.de/pipermail/u-boot/2023-March/511199.html > https://lists.denx.de/pipermail/u-boot/2023-April/515012.html sorry, but maintainer.pl returns you for the changes (added_lines:16/181=9%,removed_lines:12/62=19%)...not maintainer, but because of email i thought it could be interesting for you too...sorry about that. maintainers.pl imho should not return you here (i guess because of vendor-independ arm/dts directory/makefile). Dropped some more people from thread which may not involved into rockchip-changes. maybe this should be changed like linux kernel does for arm64 (dts//...)? then maintainer-script can show the right people here. regards Frank
[PATCH v1] board: rockchip: Add Bananapi R2Pro Board
From: Frank Wunderlich
Add rk3568 based Bananapi R2 Pro board.
Signed-off-by: Frank Wunderlich
---
because iodomain is different to evb and now iodomain driver is sent as
patch we need to separate between EVB and R2Pro else board can be bricked.
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 +
arch/arm/dts/rk3568-bpi-r2pro.dts | 597 ++
configs/bpi-r2pro-rk3568_defconfig| 101
4 files changed, 723 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
create mode 100644 configs/bpi-r2pro-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8f43dba58632..1bd48a7e0535 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-nanopi-r5s.dtb \
rk3568-odroid-m1.dtb \
rk3568-radxa-e25.dtb \
- rk3568-rock-3a.dtb
+ rk3568-rock-3a.dtb \
+ rk3568-bpi-r2pro.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
new file mode 100644
index ..382a52a28b10
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-pre-ram;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
b/arch/arm/dts/rk3568-bpi-r2pro.dts
new file mode 100644
index ..9295e9836a56
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
@@ -0,0 +1,597 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+ compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pin _led_pin>;
+
+ blue_led: led-0 {
+ color = ;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+ };
+
+ green_led: led-1 {
+ color = ;
+ default-state = "on";
+ function = LED_FUNCTION_POWER;
+ gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dc_12v: dc-12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_usb: vcc5v0-usb-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usb";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_12v>;
+ };
+
+ vcc5v0_usb_host: vcc5v0-usb-host-regulator {
+ compatib
[PATCH] arm: mediatek: add usb support for MT7988
From: Frank Wunderlich
MT7988 has a t-phy and an x-phy controller. There is already a driver for
t-phy so we can add USB support for this phy type.
Signed-off-by: Frank Wunderlich
---
arch/arm/dts/mt7988.dtsi | 60
1 file changed, 60 insertions(+)
diff --git a/arch/arm/dts/mt7988.dtsi b/arch/arm/dts/mt7988.dtsi
index ddd629e8c99d..ac476d5cdd7f 100644
--- a/arch/arm/dts/mt7988.dtsi
+++ b/arch/arm/dts/mt7988.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt7988-rfb";
@@ -161,6 +162,65 @@
#clock-cells = <1>;
};
+ dummy_clk: dummy12m {
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+ #clock-cells = <0>;
+ /* must need this line, or uart uanable to get dummy_clk */
+ bootph-all;
+ };
+
+ xhci1: xhci@1120 {
+ compatible = "mediatek,mt7988-xhci",
+"mediatek,mtk-xhci";
+ reg = <0 0x1120 0 0x2e00>,
+ <0 0x11203e00 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ phys = < PHY_TYPE_USB2>,
+ < PHY_TYPE_USB3>;
+ clocks = <_clk>,
+<_clk>,
+<_clk>,
+<_clk>,
+<_clk>;
+ clock-names = "sys_ck",
+ "xhci_ck",
+ "ref_ck",
+ "mcu_ck",
+ "dma_ck";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ status = "okay";
+ };
+
+ usbtphy: usb-phy@11c5 {
+ compatible = "mediatek,mt7988",
+"mediatek,generic-tphy-v2";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ tphyu2port0: usb-phy@11c5 {
+ reg = <0 0x11c5 0 0x700>;
+ clocks = <_clk>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ tphyu3port0: usb-phy@11c50700 {
+ reg = <0 0x11c50700 0 0x900>;
+ clocks = <_clk>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ mediatek,usb3-pll-ssc-delta;
+ mediatek,usb3-pll-ssc-delta1;
+ status = "okay";
+ };
+ };
+
xfi_pextp0: syscon@11f2 {
compatible = "mediatek,mt7988-xfi_pextp_0", "syscon";
reg = <0 0x11f2 0 0x1>;
--
2.34.1
[PATCH] arm: dts: mediatek: convert gmac link mode to 2500base-x for r3
From: Frank Wunderlich
Ethernet on Bananapi-r3 is broken after
commit bd70f3cea353 ("net: mediatek: add support for SGMII 1Gbps
auto-negotiation mode")
because changes from this commit were not applied to bpi-r3 devicetree too:
commit aef54ea16cac ("arm: dts: medaitek: convert gmac link mode to 2500base-x")
Signed-off-by: Frank Wunderlich
---
arch/arm/dts/mt7986a-bpi-r3-sd.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
index 15256302b86b..c156a8136343 100644
--- a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
+++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
@@ -76,12 +76,12 @@
{
status = "okay";
mediatek,gmac-id = <0>;
- phy-mode = "sgmii";
+ phy-mode = "2500base-x";
mediatek,switch = "mt7531";
reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
fixed-link {
- speed = <1000>;
+ speed = <2500>;
full-duplex;
};
};
--
2.34.1
Aw: Re: [PATCH 21/29] arm: dts: medaitek: convert gmac link mode to 2500base-x
Gesendet: Donnerstag, 20. Juli 2023 um 02:58 Uhr
Von: "Weijie Gao (高惟杰)"
> > On Wed, 2023-07-19 at 14:08 +0200, Frank Wunderlich wrote:
> > noticed some build-warnings from the pinctrl-patch which are not
> > critical, but should be fixed.
> >
> > e.g. this (seems for each call of PINCTRL_PIN_GROUP)
> >
> > drivers/pinctrl/mediatek/pinctrl-mt7988.c:1148:42: warning:
> > initialization discards 'const' qualifier from pointer target type [-
> > Wdiscarded-qualifiers]
> > 1148 | PINCTRL_PIN_GROUP("net_wo1_uart_txd_1",
> > mt7988_net_wo1_uart_txd_1),
> > | ^~~~
> > ~
> > drivers/pinctrl/mediatek/pinctrl-mtk-common.h:31:3: note: in
> > definition of macro 'PINCTRL_PIN_GROUP'
> >31 | id##_funcs, \
> > | ^~
> This is due to on of the patch was missing because its size exceeds
> 100KB. Please refer to:
> https://patchwork.ozlabs.org/project/uboot/patch/7c0cfbdeb17abcf805138eb69be583d5a068231b.1689756363.git.weijie@mediatek.com/
> I have to split it into two patches in v2.
indeed, part 12 was missing in my series-export from patchwork...all clean
after applying it. thx for pointing to it.
regards Frank
Aw: [PATCH 21/29] arm: dts: medaitek: convert gmac link mode to 2500base-x
Hi
> Gesendet: Mittwoch, 19. Juli 2023 um 11:17 Uhr
> Von: "Weijie Gao"
> An: u-boot@lists.denx.de
> Cc: "GSS_MTK_Uboot_upstream" , "Daniel
> Golle" , "Frank Wunderlich" , "Weijie
> Gao"
> Betreff: [PATCH 21/29] arm: dts: medaitek: convert gmac link mode to
> 2500base-x
>
> Now that individual 2.5Gbps SGMII support has been added to
> mtk-eth, all boards that use 2.5Gbps link with mt7531 must be
> converted to use "2500base-x" instead of "sgmii".
>
> Signed-off-by: Weijie Gao
> ---
> arch/arm/dts/mt7622-bananapi-bpi-r64.dts | 4 ++--
> arch/arm/dts/mt7622-rfb.dts | 4 ++--
> arch/arm/dts/mt7629-rfb.dts | 4 ++--
> arch/arm/dts/mt7981-emmc-rfb.dts | 4 ++--
> arch/arm/dts/mt7981-rfb.dts | 4 ++--
> arch/arm/dts/mt7981-sd-rfb.dts | 4 ++--
> arch/arm/dts/mt7986a-rfb.dts | 4 ++--
> arch/arm/dts/mt7986a-sd-rfb.dts | 4 ++--
> arch/arm/dts/mt7986b-rfb.dts | 4 ++--
> arch/arm/dts/mt7986b-sd-rfb.dts | 4 ++--
you miss arch/arm/dts/mt7986a-bpi-r3-sd.dts here which was added in 2023.07
i tested series on Bananapi-R4/mt7988, sdcard and network-support (many thx for
this) works so far (not tested i2c, spi and others yet), also have not done
tests on my other boards yet.
noticed some build-warnings from the pinctrl-patch which are not critical, but
should be fixed.
e.g. this (seems for each call of PINCTRL_PIN_GROUP)
drivers/pinctrl/mediatek/pinctrl-mt7988.c:1148:42: warning: initialization
discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
1148 | PINCTRL_PIN_GROUP("net_wo1_uart_txd_1", mt7988_net_wo1_uart_txd_1),
| ^
drivers/pinctrl/mediatek/pinctrl-mtk-common.h:31:3: note: in definition of
macro 'PINCTRL_PIN_GROUP'
31 | id##_funcs, \
| ^~
regards Frank
Aw: [PATCH 21/29] arm: dts: medaitek: convert gmac link mode to 2500base-x
Hi, thank you very much for your work on mt7988 support and faster than expected ;) Nice to see that ethernet-support is already included, i see some changes to mt753x.. I will try out this series as fast as possible. > Gesendet: Mittwoch, 19. Juli 2023 um 11:17 Uhr > Von: "Weijie Gao" > An: u-boot@lists.denx.de > Cc: "GSS_MTK_Uboot_upstream" , "Daniel > Golle" , "Frank Wunderlich" , "Weijie > Gao" > Betreff: [PATCH 21/29] arm: dts: medaitek: convert gmac link mode to > 2500base-x so far only noticed a typo (medaitek => mediatek) in this part here regards Frank > Now that individual 2.5Gbps SGMII support has been added to > mtk-eth, all boards that use 2.5Gbps link with mt7531 must be > converted to use "2500base-x" instead of "sgmii". > > Signed-off-by: Weijie Gao
Re: [ANN] U-Boot v2023.07 released
Hi, Btw. Githubs dependa-bot reports some security related issues with pythons setup-tools. As far as i see it should only affects tests...as i don't use the tests i cannot say if it breaks anything and so not send a patch in ML. maybe this can be done directly in original uboot repo. https://github.com/frank-w/u-boot/pull/6 I hope this way of reporting is ok :) regards Frank
Aw: Re: Re: Re: distro_boot vs. env-based bootmenu
Hi Jonas thx again for your valuable answer > Gesendet: Samstag, 01. Juli 2023 um 10:12 Uhr > Von: "Jonas Karlman" > An: "Frank Wunderlich" > Cc: "Simon Glass" , "U-Boot Mailing List" > , "Heinrich Schuchardt" > , "Ilias Apalodimas" > > Betreff: Re: Aw: Re: Re: distro_boot vs. env-based bootmenu > > Hi Frank, > On 2023-06-30 19:51, Frank Wunderlich wrote: > > Hi Jonas > > > > sorry for the delay. i came back to this and tried your way. Thx for your > > information...there is no real example in the docs (or i didn't found it) > > for manual trigger the extlinux-boot, so your information helps a lot. > > > >> Gesendet: Sonntag, 30. April 2023 um 19:40 Uhr > >> Von: "Jonas Karlman" > >> An: "Frank Wunderlich" , "Simon Glass" > >> > >> Cc: "U-Boot Mailing List" , "Heinrich Schuchardt" > >> , "Ilias Apalodimas" > >> > >> Betreff: Re: Aw: Re: distro_boot vs. env-based bootmenu > >> > >> Hi Frank, > >> > >> On 2023-04-30 15:25, Frank Wunderlich wrote: > >>> Hi > >>> > >>> I tried to find out why distroboot is enabled (i have not set it in my > >>> defconfig) and i think this is why: > >>> > >>> │ Symbol: DISTRO_DEFAULTS [=y] > >>> │ > >>> │ Type : bool > >>> │ > >>> │ Prompt: Select defaults suitable for booting general purpose Linux > >>> dist │ > >>> │ Location: > >>> │ > >>> │ (3) -> Boot options > >>> │ > >>> │ Defined at boot/Kconfig:833 > >>> │ > >>> │ Selects: BOOT_DEFAULTS [=y] && AUTO_COMPLETE [=y] && > >>> CMDLINE_EDITING │ > >>> │ Implied by [y]: > >>> │ > >>> │ - ARCH_ROCKCHIP [=y] && && !ROCKCHIP_RK3399 [=n] > >>> > >>> as far as i see you've got a response from Jonas about this option and he > >>> changed Kconfig file to BOOTSTD_DEFAULTS > >>> > >>> as i have not used BOOTSTD_DEFAULTS before, what needs to be changed to > >>> have it working? > >> > >> Please update to latest master branch, rk356x is not fully working > >> with v2023.04 or earlier, especially BOOTSTD without extra CONFIGs. > >> > >> With latest master branch CONFIG_BOOTSTD_DEFAULTS=y should be set by > >> default for all ARCH_ROCKCHIP. And should work very similar to if you > >> used to have "run distro_bootcmd" as your bootcmd. > > > > As i use builtin-environment there is no distro_bootcmd which i can run. > > > >> It is still unclear what script/bootcmd you are trying to use, or if > >> you used to have "run distro_bootcmd" as a fallback. Replacing > >> "run distro_bootcmd" with "bootflow scan -lb" or "bootflow scan" > >> could work as such fallback option. > > > > but with "bootflow scan -lb" it works except 1 thing: old bootchain looked > > in config directory for the files (kernel+fdt) whereas new way looks in > > root of partition and now needs additional extlinux prefix. > > This could be related to an issue that was fixed in v2023.07-rc5: > > bootstd: Fix relative path use in extlinux bootmeth > > See > https://source.denx.de/u-boot/u-boot/-/commit/a7e4dffcd8c582bf4344548270d2fc7ac6c0f9ec > > If not then please provide more details, in case this is a bug. thx, after rebase on rc5 it works as expected...rebased on rc4 a few hours before rc5 was relasted :p as this commit was done by you thx for fixing this ;) > > > > and yes i want distroboot as fallback... > > > > is there a way to avoid this to hold the file compatible? > > The intent is that the new standard boot should be as compatible as > possible as the old script based distro boot, depending on you boot > script. > > If you use any of the script part that the old distro boot provided you > will have to adjust your boot script, e.g. replace "run distro_bootcmd" > with "bootflow scan -lb" or "bootflow scan", and
Aw: Re: distro_boot vs. env-based bootmenu
Hi thanks for your anser > Gesendet: Samstag, 01. Juli 2023 um 04:08 Uhr > Von: "AKASHI Takahiro" > Hi, > > On Wed, Apr 12, 2023 at 11:22:23AM +0200, Frank Wunderlich wrote: > > Hi, > > > > i try to move from distro-boot (extlinux-config files) to an env-based > > bootmenu (builtin-environment) for > > my bananapi r2pro. > > > > basicly it works, but i see more bootmenu-entries than i have defined in my > > environment > > > > *** U-Boot Boot Menu *** > > > > 1. Boot from SD/EMMC. > > mmc 1:2 > > mmc 1:3 > > mmc 1:4 > > U-Boot consoleHit any key to stop autoboot: 2 > > > > i have only defined one botmenu-entry (first one in uEnv_r2pro.txt) > > > > bootmenu_0=1. Boot from SD/EMMC.=run newboot > > bootmenu_default=0 > > > > i guess the 3 mmc 1:x entries are part from distro-boot. i see a series > > from simon where he drops > > distroboot for rockchip-boards. > > Probably they came from UEFI's removable media support, specifically > commit c606c0059f7f > Author: Masahisa Kojima > Date: Thu Apr 28 17:09:42 2022 +0900 > > bootmenu: add UEFI boot entry into bootmenu yes, thats right, disabling efi (that was somehow enabled by default as i do not find any EFI in my defconfig) https://github.com/frank-w/u-boot/blob/2023-07-bpi/configs/evb-rk3568_defconfig > > https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf7708a1ba953b9abd81375d93af34665c7b251@changeid/ > > > > can anyone explain me where i can disable the mmc 1:x entries? i wanted to > > leave distro_boot as > > fallback but it seems this is not possible. > > Try to disable either CONFIG_CMD_EFICONFIG or CONFIG_CMD_BOOTEFI_BOOTMGR, > even CONFIG_EFI_LOADER if you don't need UEFI subsystem at all. disabled CONFIG_EFI_LOADER=n and CONFIG_EFI_LOADER and now the menuitems are disappeared and i have no efi-options set > -Takahiro Akashi regards Frank
Aw: Re: Re: distro_boot vs. env-based bootmenu
Hi Jonas sorry for the delay. i came back to this and tried your way. Thx for your information...there is no real example in the docs (or i didn't found it) for manual trigger the extlinux-boot, so your information helps a lot. > Gesendet: Sonntag, 30. April 2023 um 19:40 Uhr > Von: "Jonas Karlman" > An: "Frank Wunderlich" , "Simon Glass" > > Cc: "U-Boot Mailing List" , "Heinrich Schuchardt" > , "Ilias Apalodimas" > > Betreff: Re: Aw: Re: distro_boot vs. env-based bootmenu > > Hi Frank, > > On 2023-04-30 15:25, Frank Wunderlich wrote: > > Hi > > > > I tried to find out why distroboot is enabled (i have not set it in my > > defconfig) and i think this is why: > > > > │ Symbol: DISTRO_DEFAULTS [=y] > > │ > > │ Type : bool > > │ > > │ Prompt: Select defaults suitable for booting general purpose Linux dist > > │ > > │ Location: > > │ > > │ (3) -> Boot options > > │ > > │ Defined at boot/Kconfig:833 > > │ > > │ Selects: BOOT_DEFAULTS [=y] && AUTO_COMPLETE [=y] && CMDLINE_EDITING > > │ > > │ Implied by [y]: > > │ > > │ - ARCH_ROCKCHIP [=y] && && !ROCKCHIP_RK3399 [=n] > > > > as far as i see you've got a response from Jonas about this option and he > > changed Kconfig file to BOOTSTD_DEFAULTS > > > > as i have not used BOOTSTD_DEFAULTS before, what needs to be changed to > > have it working? > > Please update to latest master branch, rk356x is not fully working > with v2023.04 or earlier, especially BOOTSTD without extra CONFIGs. > > With latest master branch CONFIG_BOOTSTD_DEFAULTS=y should be set by > default for all ARCH_ROCKCHIP. And should work very similar to if you > used to have "run distro_bootcmd" as your bootcmd. As i use builtin-environment there is no distro_bootcmd which i can run. > It is still unclear what script/bootcmd you are trying to use, or if > you used to have "run distro_bootcmd" as a fallback. Replacing > "run distro_bootcmd" with "bootflow scan -lb" or "bootflow scan" > could work as such fallback option. but with "bootflow scan -lb" it works except 1 thing: old bootchain looked in config directory for the files (kernel+fdt) whereas new way looks in root of partition and now needs additional extlinux prefix. and yes i want distroboot as fallback... is there a way to avoid this to hold the file compatible? why i use the environment bootmenu? i do a bit more in the menuitems (and before) e.g. loading a uEnv.txt to override some options and for testing. have bootargs only defined once, have testkernels with initrd and some special stuff with asking for user input (list kernels from mmc/tftp/... and let user choose which kernel/fdt/initrd/...). Such things are imho not possible with extlinux way. currently only bpi-r2pro uses extlinux boot and the other 3 boards using the builtin environment bootmenu. So to keep all boards nearly same i want to have the same for r2pro but allow users with extlinux still using this. > > basicly my Plan is to script the bootup via env in script with a bootmenu > > (default entry + additional ones which can be > > changed by an env.txt file), but i do not want to break existing setups > > (using extlinux/*.conf behaviour) and no additional > > bootmenu-entries. > > The "distro" bootmeth described at the documentation you linked to will > looks for a file called extlinux/extlinux.conf. > > Is there a special reason why you need to use a custom bootmenu script > and are moving from distro-boot (extlinux-config files)? > > > > > is there any documentation describing the "Standard boot"? > > > > i found this, but it looks like the "old" distro-boot...or is is same from > > users PoV? > > > > https://u-boot.readthedocs.io/en/latest/develop/bootstd.html > > This is the documentation for standard boot. > > I recommend you try out the commands bootdev, bootflow and bootmeth with > CONFIG_BOOTSTD_FULL=y to get a better handling on how it would work on > your device and how you can use them in your script. > > Regards, > Jonas regards Frank
Aw: [PATCH v2 0/2] Add DTS for BPI-R3
Hi, Is it possible to take this series in upcoming release? regards Frank > Gesendet: Dienstag, den 11.04.2023 um 17:19 Uhr > Von: "Frank Wunderlich" > An: u-boot@lists.denx.de > Cc: "Frank Wunderlich" , "Sam Shih" > , "William Zhang" , > "Philippe Reynes" , "Marek Vasut" > , "Fabio Estevam" , "Marcel Ziswiler" > , "Samuel Holland" , "Pali > Rohár" , "Daniel Golle" , "Simon > Glass" , "Weijie Gao" > Betreff: [PATCH v2 0/2] Add DTS for BPI-R3 > > From: Frank Wunderlich > > Add board specific devicetree for BananaPi R3. > > It is taken from openwrt > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/430-add-bpi-r3.patch;hb=HEAD > only enabled the factory button which was disabled because a HW-bug in > rev 1.0 of r3. > > v2: changed label for wps-button (used as reset in openwrt) > > Daniel Golle (1): > board: mediatek: add Bananapi-R3 devicetree > > Frank Wunderlich (1): > configs: change bpi-r3 to board specific dts and change prompt > > arch/arm/dts/Makefile| 2 + > arch/arm/dts/mt7986a-bpi-r3-emmc.dts | 32 > arch/arm/dts/mt7986a-bpi-r3-sd.dts | 268 +++ > configs/mt7986a_bpir3_emmc_defconfig | 6 +- > configs/mt7986a_bpir3_sd_defconfig | 6 +- > 5 files changed, 308 insertions(+), 6 deletions(-) > create mode 100644 arch/arm/dts/mt7986a-bpi-r3-emmc.dts > create mode 100644 arch/arm/dts/mt7986a-bpi-r3-sd.dts > > -- > 2.34.1 >
Aw: Re: distro_boot vs. env-based bootmenu
Hi I tried to find out why distroboot is enabled (i have not set it in my defconfig) and i think this is why: │ Symbol: DISTRO_DEFAULTS [=y]│ │ Type : bool│ │ Prompt: Select defaults suitable for booting general purpose Linux dist │ │ Location: │ │ (3) -> Boot options │ │ Defined at boot/Kconfig:833 │ │ Selects: BOOT_DEFAULTS [=y] && AUTO_COMPLETE [=y] && CMDLINE_EDITING │ │ Implied by [y]: │ │ - ARCH_ROCKCHIP [=y] && && !ROCKCHIP_RK3399 [=n] as far as i see you've got a response from Jonas about this option and he changed Kconfig file to BOOTSTD_DEFAULTS as i have not used BOOTSTD_DEFAULTS before, what needs to be changed to have it working? basicly my Plan is to script the bootup via env in script with a bootmenu (default entry + additional ones which can be changed by an env.txt file), but i do not want to break existing setups (using extlinux/*.conf behaviour) and no additional bootmenu-entries. is there any documentation describing the "Standard boot"? i found this, but it looks like the "old" distro-boot...or is is same from users PoV? https://u-boot.readthedocs.io/en/latest/develop/bootstd.html regards Frank > On Mon, 24 Apr 2023 at 15:22, Frank Wunderlich > wrote: > > > > Am 24. April 2023 21:44:25 MESZ schrieb Simon Glass : > > >Hi Frank, > > > > > >On Fri, 21 Apr 2023 at 10:03, Frank Wunderlich > > >wrote: > > >> > > >> Maybe you have an idea because your patch removes distro-boot > > >> > > >> https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf7708a1ba953b9abd81375d93af34665c7b251@changeid/ > > >> > > >> For missing linebreak for autoboot this seems to be a calculation issue > > >> > > >> https://source.denx.de/u-boot/u-boot/-/blob/master/common/menu.c#L439 > > > > > >Are you able to fix it with a patch? > > > > Have not yet figured out which part of u-boot creates the mmc-entries on > > top of my bootmenu (i guess this comes from my still enabled distroboot > > options). > > > > For missing linebreak i guess position calculation is wrong in this case. > > > > >Or if not, do you have a patch for the 'move to env-based bootmenu' so > > >I can try it? > > > > I have i builtin env file (uEnv_r2pro.txt) in my tree here and add (enable > > pepared option) the config-option to use this env file in topmost commit. > > > > https://github.com/frank-w/u-boot/commits/2023-04-bpi-r2pro > > > > I had this in but disabled but this overrides the env created by > > distroboot-defines...but now enabling it to get rid of distroboot. > > > > >> Ursprüngliche Nachricht > > >> Von: Frank Wunderlich > > >> Gesendet: 12. April 2023 11:22:23 MESZ > > >> An: u-boot@lists.denx.de > > >> Betreff: distro_boot vs. env-based bootmenu > > >> > > >> Hi, > > >> > > >> i try to move from distro-boot (extlinux-config files) to an env-based > > >> bootmenu (builtin-environment) for > > >> my bananapi r2pro. > > >> > > >> basicly it works, but i see more bootmenu-entries than i have defined in > > >> my environment > > >> > > >> *** U-Boot Boot Menu *** > > >> > > >> 1. Boot from SD/EMMC. > > >> mmc 1:2 > > >> mmc 1:3 > > >> mmc 1:4 > > >> U-Boot consoleHit any key to stop autoboot: 2 > > >> > > >> i have only defined one botmenu-entry (first one in uEnv_r2pro.txt) > > >> > > >> bootmenu_0=1. Boot from SD/EMMC.=run newboot > > >> bootmenu_default=0 > > >> > > >> i guess the 3 mmc 1:x entries are part from distro-boot. i see a series > > >> from simon where he drops > > >> distroboot for rockchip-boards. > > >> > > >> https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf7708a1ba953b9abd81375d93af34665c7b251@changeid/ > > >> > > >> can anyone explain me where i can disable the mmc 1:x entries? i wanted > > >> to leave distro_boot as > > >> fallback but it seems this is not possible. > > >> > > >> maybe i have to disable these? > > >> > > >> BOOTMETH_DISTRO [=y] > > >> DISTRO_DEFAULTS [=y] > > >> > > >> can i keep distro-boot (seems to works with env too, but overridden by > > >> my builtin env) somehow and drop the mmc-entries from my bootmenu? > > >> > > >> any idea why i have no linebreak after u-Boot console? > > >> > > >> i use u-boot 2023.04 my source for this conversion/tests is there: > > >> https://github.com/frank-w/u-boot/tree/2023-04-bpi-r2pro > > >> using modified configs/evb-rk3568_defconfig
Re: distro_boot vs. env-based bootmenu
Am 24. April 2023 21:44:25 MESZ schrieb Simon Glass : >Hi Frank, > >On Fri, 21 Apr 2023 at 10:03, Frank Wunderlich wrote: >> >> Maybe you have an idea because your patch removes distro-boot >> >> https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf7708a1ba953b9abd81375d93af34665c7b251@changeid/ >> >> For missing linebreak for autoboot this seems to be a calculation issue >> >> https://source.denx.de/u-boot/u-boot/-/blob/master/common/menu.c#L439 > >Are you able to fix it with a patch? Have not yet figured out which part of u-boot creates the mmc-entries on top of my bootmenu (i guess this comes from my still enabled distroboot options). For missing linebreak i guess position calculation is wrong in this case. >Or if not, do you have a patch for the 'move to env-based bootmenu' so >I can try it? I have i builtin env file (uEnv_r2pro.txt) in my tree here and add (enable pepared option) the config-option to use this env file in topmost commit. https://github.com/frank-w/u-boot/commits/2023-04-bpi-r2pro I had this in but disabled but this overrides the env created by distroboot-defines...but now enabling it to get rid of distroboot. >Regards, >Simon > > > >> >> >> >> Ursprüngliche Nachricht >> Von: Frank Wunderlich >> Gesendet: 12. April 2023 11:22:23 MESZ >> An: u-boot@lists.denx.de >> Betreff: distro_boot vs. env-based bootmenu >> >> Hi, >> >> i try to move from distro-boot (extlinux-config files) to an env-based >> bootmenu (builtin-environment) for >> my bananapi r2pro. >> >> basicly it works, but i see more bootmenu-entries than i have defined in my >> environment >> >> *** U-Boot Boot Menu *** >> >> 1. Boot from SD/EMMC. >> mmc 1:2 >> mmc 1:3 >> mmc 1:4 >> U-Boot consoleHit any key to stop autoboot: 2 >> >> i have only defined one botmenu-entry (first one in uEnv_r2pro.txt) >> >> bootmenu_0=1. Boot from SD/EMMC.=run newboot >> bootmenu_default=0 >> >> i guess the 3 mmc 1:x entries are part from distro-boot. i see a series from >> simon where he drops >> distroboot for rockchip-boards. >> >> https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf7708a1ba953b9abd81375d93af34665c7b251@changeid/ >> >> can anyone explain me where i can disable the mmc 1:x entries? i wanted to >> leave distro_boot as >> fallback but it seems this is not possible. >> >> maybe i have to disable these? >> >> BOOTMETH_DISTRO [=y] >> DISTRO_DEFAULTS [=y] >> >> can i keep distro-boot (seems to works with env too, but overridden by my >> builtin env) somehow and drop the mmc-entries from my bootmenu? >> >> any idea why i have no linebreak after u-Boot console? >> >> i use u-boot 2023.04 my source for this conversion/tests is there: >> https://github.com/frank-w/u-boot/tree/2023-04-bpi-r2pro >> using modified configs/evb-rk3568_defconfig >> >> regards Frank >> regards Frank regards Frank
Aw: [PATCH] pinctrl: mediatek: set R1/R0 in case pullen/pullsel succeeded
FYI...this issue affects only specific eMMC-Chips (vendor SEC) on the Bananapi-R2 (v1.2). i have a v1.1 with a Samsung eMMC where i had no problems with the missing pullups/pulldowns (maybe this has internal resistors) more information about this special case: https://forum.banana-pi.org/t/problem-trying-to-use-emmc/11253 tested the patch on my device for regressions...no problems Tested-By: Frank Wunderlich
distro_boot vs. env-based bootmenu
Hi, i try to move from distro-boot (extlinux-config files) to an env-based bootmenu (builtin-environment) for my bananapi r2pro. basicly it works, but i see more bootmenu-entries than i have defined in my environment *** U-Boot Boot Menu *** 1. Boot from SD/EMMC. mmc 1:2 mmc 1:3 mmc 1:4 U-Boot consoleHit any key to stop autoboot: 2 i have only defined one botmenu-entry (first one in uEnv_r2pro.txt) bootmenu_0=1. Boot from SD/EMMC.=run newboot bootmenu_default=0 i guess the 3 mmc 1:x entries are part from distro-boot. i see a series from simon where he drops distroboot for rockchip-boards. https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf7708a1ba953b9abd81375d93af34665c7b251@changeid/ can anyone explain me where i can disable the mmc 1:x entries? i wanted to leave distro_boot as fallback but it seems this is not possible. maybe i have to disable these? BOOTMETH_DISTRO [=y] DISTRO_DEFAULTS [=y] can i keep distro-boot (seems to works with env too, but overridden by my builtin env) somehow and drop the mmc-entries from my bootmenu? any idea why i have no linebreak after u-Boot console? i use u-boot 2023.04 my source for this conversion/tests is there: https://github.com/frank-w/u-boot/tree/2023-04-bpi-r2pro using modified configs/evb-rk3568_defconfig regards Frank
[PATCH v2 1/2] board: mediatek: add Bananapi-R3 devicetree
From: Daniel Golle
Add board specific devicetree for Bananapi R3 SBC.
Signed-off-by: Daniel Golle
Signed-off-by: Frank Wunderlich
---
taken from openwrt
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/430-add-bpi-r3.patch;hb=HEAD
only enabled the factory button which was disabled because a HW-bug in
rev 1.0 of r3.
v2:
- change label for wps-button
---
arch/arm/dts/Makefile| 2 +
arch/arm/dts/mt7986a-bpi-r3-emmc.dts | 32
arch/arm/dts/mt7986a-bpi-r3-sd.dts | 268 +++
3 files changed, 302 insertions(+)
create mode 100644 arch/arm/dts/mt7986a-bpi-r3-emmc.dts
create mode 100644 arch/arm/dts/mt7986a-bpi-r3-sd.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0a9b1f7749d5..de0c0e35b8c3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1296,6 +1296,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7981-rfb.dtb \
mt7981-emmc-rfb.dtb \
mt7981-sd-rfb.dtb \
+ mt7986a-bpi-r3-sd.dtb \
+ mt7986a-bpi-r3-emmc.dtb \
mt7986a-rfb.dtb \
mt7986b-rfb.dtb \
mt7986a-sd-rfb.dtb \
diff --git a/arch/arm/dts/mt7986a-bpi-r3-emmc.dts
b/arch/arm/dts/mt7986a-bpi-r3-emmc.dts
new file mode 100644
index ..4e2e5262f536
--- /dev/null
+++ b/arch/arm/dts/mt7986a-bpi-r3-emmc.dts
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+/dts-v1/;
+#include "mt7986a-bpi-r3-sd.dts"
+#include
+/ {
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+ bus-width = <8>;
+ max-frequency = <2>;
+ cap-mmc-highspeed;
+ cap-mmc-hw-reset;
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_1p8v>;
+ non-removable;
+ status = "okay";
+};
diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
new file mode 100644
index ..4d12440fa3c0
--- /dev/null
+++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+/dts-v1/;
+#include "mt7986.dtsi"
+#include
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "BananaPi BPi-R3";
+ compatible = "mediatek,mt7986", "mediatek,mt7986-sd-rfb";
+
+ chosen {
+ stdout-path =
+ tick-timer =
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ factory {
+ label = "reset";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_status_green: green {
+ label = "green:status";
+ gpios = < 69 GPIO_ACTIVE_HIGH>;
+ };
+
+ led_status_blue: blue {
+ label = "blue:status";
+ gpios = < 86 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "disabled";
+};
+
+ {
+ status = "okay";
+ mediatek,gmac-id = <0>;
+ phy-mode = "sgmii";
+ mediatek,switch = "mt7531";
+ reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+ {
+ spic_pins: spi1-pins-func-1 {
+ mux {
+ function = "spi";
+ groups = "spi1_2";
+ };
+ };
+
+ uart1_pins: spi1-pins-func-3 {
+ mux {
+ function = "uart";
+ g
[PATCH v2 2/2] configs: change bpi-r3 to board specific dts and change prompt
From: Frank Wunderlich Use own devicetree for the board and change the prompt. Signed-off-by: Frank Wunderlich --- configs/mt7986a_bpir3_emmc_defconfig | 6 +++--- configs/mt7986a_bpir3_sd_defconfig | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configs/mt7986a_bpir3_emmc_defconfig b/configs/mt7986a_bpir3_emmc_defconfig index 2d4876f299f4..5b76512a46f6 100644 --- a/configs/mt7986a_bpir3_emmc_defconfig +++ b/configs/mt7986a_bpir3_emmc_defconfig @@ -7,15 +7,15 @@ CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x8 CONFIG_ENV_OFFSET=0x30 -CONFIG_DEFAULT_DEVICE_TREE="mt7986a-emmc-rfb" -CONFIG_SYS_PROMPT="MT7986> " +CONFIG_DEFAULT_DEVICE_TREE="mt7986a-bpi-r3-emmc" +CONFIG_SYS_PROMPT="BPI-R3> " CONFIG_TARGET_MT7986=y CONFIG_DEBUG_UART_BASE=0x11002000 CONFIG_DEBUG_UART_CLOCK=4000 CONFIG_SYS_LOAD_ADDR=0x4600 CONFIG_DEBUG_UART=y # CONFIG_AUTOBOOT is not set -CONFIG_DEFAULT_FDT_FILE="mt7986a-emmc-rfb" +CONFIG_DEFAULT_FDT_FILE="mt7986a-bpi-r3-emmc" CONFIG_LOGLEVEL=7 CONFIG_LOG=y CONFIG_SYS_CBSIZE=512 diff --git a/configs/mt7986a_bpir3_sd_defconfig b/configs/mt7986a_bpir3_sd_defconfig index 08edfe7ac409..36547db91423 100644 --- a/configs/mt7986a_bpir3_sd_defconfig +++ b/configs/mt7986a_bpir3_sd_defconfig @@ -7,15 +7,15 @@ CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x8 CONFIG_ENV_OFFSET=0x30 -CONFIG_DEFAULT_DEVICE_TREE="mt7986a-sd-rfb" -CONFIG_SYS_PROMPT="MT7986> " +CONFIG_DEFAULT_DEVICE_TREE="mt7986a-bpi-r3-sd" +CONFIG_SYS_PROMPT="BPI-R3> " CONFIG_TARGET_MT7986=y CONFIG_DEBUG_UART_BASE=0x11002000 CONFIG_DEBUG_UART_CLOCK=4000 CONFIG_SYS_LOAD_ADDR=0x4600 CONFIG_DEBUG_UART=y # CONFIG_AUTOBOOT is not set -CONFIG_DEFAULT_FDT_FILE="mt7986a-sd-rfb" +CONFIG_DEFAULT_FDT_FILE="mt7986a-bpi-r3-sd" CONFIG_LOGLEVEL=7 CONFIG_LOG=y CONFIG_SYS_CBSIZE=512 -- 2.34.1
[PATCH v2 0/2] Add DTS for BPI-R3
From: Frank Wunderlich Add board specific devicetree for BananaPi R3. It is taken from openwrt https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/430-add-bpi-r3.patch;hb=HEAD only enabled the factory button which was disabled because a HW-bug in rev 1.0 of r3. v2: changed label for wps-button (used as reset in openwrt) Daniel Golle (1): board: mediatek: add Bananapi-R3 devicetree Frank Wunderlich (1): configs: change bpi-r3 to board specific dts and change prompt arch/arm/dts/Makefile| 2 + arch/arm/dts/mt7986a-bpi-r3-emmc.dts | 32 arch/arm/dts/mt7986a-bpi-r3-sd.dts | 268 +++ configs/mt7986a_bpir3_emmc_defconfig | 6 +- configs/mt7986a_bpir3_sd_defconfig | 6 +- 5 files changed, 308 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/mt7986a-bpi-r3-emmc.dts create mode 100644 arch/arm/dts/mt7986a-bpi-r3-sd.dts -- 2.34.1
Aw: [v1 1/2] board: mediatek: add Bananapi-R3 devicetree
Hi
noticed that i need to change the label of wps button back to "wps" when
enabling the factory
button (else there will be 2 buttons with same label).
> Gesendet: Freitag, 07. April 2023 um 23:26 Uhr
> Von: "Frank Wunderlich"
> Betreff: [v1 1/2] board: mediatek: add Bananapi-R3 devicetree
>
> From: Daniel Golle
>
> Add board specific devicetree for Bananapi R3 SBC.
>
> Signed-off-by: Daniel Golle
> Signed-off-by: Frank Wunderlich
> ---
> taken from openwrt
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/430-add-bpi-r3.patch;hb=HEAD
> only enabled the factory button which was disabled because a HW-bug in
> rev 1.0 of r3.
> ---
> diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> new file mode 100644
> index ..82a3975c7de8
> --- /dev/null
> +++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> + keys {
> + compatible = "gpio-keys";
> +
> + factory {
> + label = "reset";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + };
> +
> + wps {
> + label = "reset";
label was changed in openwrt to use this button for reset, but hw bug fixed in
newer v1.1 versions of
the board. I will change this to "wps" like in linux in next version.
just tell me if the structure is right or if there any other things need to be
changed.
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + };
> + };
regards Frank
[v1 1/2] board: mediatek: add Bananapi-R3 devicetree
From: Daniel Golle
Add board specific devicetree for Bananapi R3 SBC.
Signed-off-by: Daniel Golle
Signed-off-by: Frank Wunderlich
---
taken from openwrt
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/430-add-bpi-r3.patch;hb=HEAD
only enabled the factory button which was disabled because a HW-bug in
rev 1.0 of r3.
---
arch/arm/dts/Makefile| 2 +
arch/arm/dts/mt7986a-bpi-r3-emmc.dts | 32
arch/arm/dts/mt7986a-bpi-r3-sd.dts | 268 +++
3 files changed, 302 insertions(+)
create mode 100644 arch/arm/dts/mt7986a-bpi-r3-emmc.dts
create mode 100644 arch/arm/dts/mt7986a-bpi-r3-sd.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0a9b1f7749d5..de0c0e35b8c3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1296,6 +1296,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7981-rfb.dtb \
mt7981-emmc-rfb.dtb \
mt7981-sd-rfb.dtb \
+ mt7986a-bpi-r3-sd.dtb \
+ mt7986a-bpi-r3-emmc.dtb \
mt7986a-rfb.dtb \
mt7986b-rfb.dtb \
mt7986a-sd-rfb.dtb \
diff --git a/arch/arm/dts/mt7986a-bpi-r3-emmc.dts
b/arch/arm/dts/mt7986a-bpi-r3-emmc.dts
new file mode 100644
index ..4e2e5262f536
--- /dev/null
+++ b/arch/arm/dts/mt7986a-bpi-r3-emmc.dts
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+/dts-v1/;
+#include "mt7986a-bpi-r3-sd.dts"
+#include
+/ {
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+ bus-width = <8>;
+ max-frequency = <2>;
+ cap-mmc-highspeed;
+ cap-mmc-hw-reset;
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_1p8v>;
+ non-removable;
+ status = "okay";
+};
diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
new file mode 100644
index ..82a3975c7de8
--- /dev/null
+++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+/dts-v1/;
+#include "mt7986.dtsi"
+#include
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "BananaPi BPi-R3";
+ compatible = "mediatek,mt7986", "mediatek,mt7986-sd-rfb";
+
+ chosen {
+ stdout-path =
+ tick-timer =
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ factory {
+ label = "reset";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+
+ wps {
+ label = "reset";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_status_green: green {
+ label = "green:status";
+ gpios = < 69 GPIO_ACTIVE_HIGH>;
+ };
+
+ led_status_blue: blue {
+ label = "blue:status";
+ gpios = < 86 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "disabled";
+};
+
+ {
+ status = "okay";
+ mediatek,gmac-id = <0>;
+ phy-mode = "sgmii";
+ mediatek,switch = "mt7531";
+ reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+ {
+ spic_pins: spi1-pins-func-1 {
+ mux {
+ function = "spi";
+ groups = "spi1_2";
+ };
+ };
+
+ uart1_pins: spi1-pins-func-3 {
+ mux {
+ function = "uart";
+ groups = "uart1_2";
+ };
+
[v1 2/2] configs: change bpi-r3 to board specific dts and change prompt
From: Frank Wunderlich Use own devicetree for the board and change the prompt. Signed-off-by: Frank Wunderlich --- configs/mt7986a_bpir3_emmc_defconfig | 6 +++--- configs/mt7986a_bpir3_sd_defconfig | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configs/mt7986a_bpir3_emmc_defconfig b/configs/mt7986a_bpir3_emmc_defconfig index 2d4876f299f4..5b76512a46f6 100644 --- a/configs/mt7986a_bpir3_emmc_defconfig +++ b/configs/mt7986a_bpir3_emmc_defconfig @@ -7,15 +7,15 @@ CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x8 CONFIG_ENV_OFFSET=0x30 -CONFIG_DEFAULT_DEVICE_TREE="mt7986a-emmc-rfb" -CONFIG_SYS_PROMPT="MT7986> " +CONFIG_DEFAULT_DEVICE_TREE="mt7986a-bpi-r3-emmc" +CONFIG_SYS_PROMPT="BPI-R3> " CONFIG_TARGET_MT7986=y CONFIG_DEBUG_UART_BASE=0x11002000 CONFIG_DEBUG_UART_CLOCK=4000 CONFIG_SYS_LOAD_ADDR=0x4600 CONFIG_DEBUG_UART=y # CONFIG_AUTOBOOT is not set -CONFIG_DEFAULT_FDT_FILE="mt7986a-emmc-rfb" +CONFIG_DEFAULT_FDT_FILE="mt7986a-bpi-r3-emmc" CONFIG_LOGLEVEL=7 CONFIG_LOG=y CONFIG_SYS_CBSIZE=512 diff --git a/configs/mt7986a_bpir3_sd_defconfig b/configs/mt7986a_bpir3_sd_defconfig index 08edfe7ac409..36547db91423 100644 --- a/configs/mt7986a_bpir3_sd_defconfig +++ b/configs/mt7986a_bpir3_sd_defconfig @@ -7,15 +7,15 @@ CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x8 CONFIG_ENV_OFFSET=0x30 -CONFIG_DEFAULT_DEVICE_TREE="mt7986a-sd-rfb" -CONFIG_SYS_PROMPT="MT7986> " +CONFIG_DEFAULT_DEVICE_TREE="mt7986a-bpi-r3-sd" +CONFIG_SYS_PROMPT="BPI-R3> " CONFIG_TARGET_MT7986=y CONFIG_DEBUG_UART_BASE=0x11002000 CONFIG_DEBUG_UART_CLOCK=4000 CONFIG_SYS_LOAD_ADDR=0x4600 CONFIG_DEBUG_UART=y # CONFIG_AUTOBOOT is not set -CONFIG_DEFAULT_FDT_FILE="mt7986a-sd-rfb" +CONFIG_DEFAULT_FDT_FILE="mt7986a-bpi-r3-sd" CONFIG_LOGLEVEL=7 CONFIG_LOG=y CONFIG_SYS_CBSIZE=512 -- 2.34.1
[v1 0/2] Add DTS for BPI-R3
From: Frank Wunderlich Add board specific devicetree for BananaPi R3. It is taken from openwrt https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/430-add-bpi-r3.patch;hb=HEAD only enabled the factory button which was disabled because a HW-bug in rev 1.0 of r3. Daniel Golle (1): board: mediatek: add Bananapi-R3 devicetree Frank Wunderlich (1): configs: change bpi-r3 to board specific dts and change prompt arch/arm/dts/Makefile| 2 + arch/arm/dts/mt7986a-bpi-r3-emmc.dts | 32 arch/arm/dts/mt7986a-bpi-r3-sd.dts | 268 +++ configs/mt7986a_bpir3_emmc_defconfig | 6 +- configs/mt7986a_bpir3_sd_defconfig | 6 +- 5 files changed, 308 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/mt7986a-bpi-r3-emmc.dts create mode 100644 arch/arm/dts/mt7986a-bpi-r3-sd.dts -- 2.34.1
Aw: [PATCH v5 2/6] rockchip: Use an external TPL binary on RK3568
Tested full series on bananapi r2pro Tested-by: Frank Wunderlich regards Frank
Aw: [PATCH v4 0/4] rockchip: Use external TPL binary to create a working firmware image
Hi, tested this series on top of 2023.04-rc2 on bananapi r2, works well if i disable CONFIG_OF_SYSTEM_SETUP else i get this error: LD u-boot aarch64-linux-gnu-ld.bfd: boot/image-fdt.o: in function `image_setup_libfdt': /media/data_nvme/git/uboot/u-boot/boot/image-fdt.c:661: undefined reference to `ft_system_setup' aarch64-linux-gnu-ld.bfd: cmd/fdt.o: in function `do_fdt': /media/data_nvme/git/uboot/u-boot/cmd/fdt.c:272: undefined reference to `ft_system_setup' Segmentation fault (core dumped) make: *** [Makefile:1753: u-boot] Error 139 make: *** Deleting file 'u-boot' build failed! because there is no implementation for this function for rockchip: https://elixir.bootlin.com/u-boot/v2023.04-rc2/C/ident/ft_system_setup i had this option set in my defconfig from 2022-04 before it was broken by binman patches, but do not remember why i have added it. but basicly it works again, so Tested-By: Frank Wunderlich regards Frank > Gesendet: Sonntag, 19. Februar 2023 um 16:06 Uhr > Von: "Jonas Karlman" > An: "Simon Glass" , "Philipp Tomsich" > , "Kever Yang" , "Joseph > Chen" , "Alper Nebi Yasak" > Cc: "Quentin Schulz" , "Jagan Teki" > , "Heinrich Schuchardt" , > u-boot@lists.denx.de, "Jonas Karlman" > Betreff: [PATCH v4 0/4] rockchip: Use external TPL binary to create a working > firmware image > > Rockchip SoCs typically use U-Boot TPL to initialize DRAM, then jumps > back to BootRom to load next stage, U-Boot SPL, into DRAM. BootRom then > jumps to U-Boot SPL to continue the boot flow. > > For RK356x there is no support to initialize DRAM using U-Boot > TPL and instead an external TPL binary must be used to generate a > bootable u-boot-rockchip.bin image. > > This adds a new rockchip-tpl entry to binman and make use of this new > entry in rockchip-u-boot.dtsi. > > Build U-Boot with ROCKCHIP_TPL=/path/to/ddr.bin to generate a > bootable u-boot-rockchip.bin image for RK356x. > > I have dropped the RFC patch that was related to showing a friendly > message instead of a generic file not found message when TPL blob is > missing in v3. Will address that in a follow-up series. > > The last patch that updates evb-rk3568_defconfig was dropped in v4. > Will address that and more config options in a follow-up series. > > Changes in v4: > - Only change init size limit for rk3328 and rk3568 > - Drop update evb-rk3568_defconfig patch > > Changes in v3: > - Move test function last > - Add help text to Kconfig option > - Add build step for rk3568 to documentation > - Resync init size limit table > - Drop missing message RFC patch > > Changes in v2: > - Renamed external-tpl to rockchip-tpl > - Renamed EXTERNAL_TPL to ROCKCHIP_TPL > - Add CONFIG_ROCKCHIP_EXTERNAL_TPL Kconfig option > - New patch to sync init size limit in mkimage > - New RFC patch to improve allow-missing/fake-ext-blobs handling for > binman mkimage entry > > Jonas Karlman (4): > binman: Add support for a rockchip-tpl entry > rockchip: Use an external TPL binary on RK3568 > Revert "board: rockchip: Fix binman_init failure on EVB-RK3568" > rockchip: mkimage: Update init size limit for RK3328 and RK3568 > > Makefile | 1 + > arch/arm/dts/rockchip-u-boot.dtsi | 10 -- > arch/arm/mach-rockchip/Kconfig | 8 > configs/evb-rk3568_defconfig | 1 - > doc/board/rockchip/rockchip.rst| 11 +++ > tools/binman/entries.rst | 14 ++ > tools/binman/etype/rockchip_tpl.py | 20 > tools/binman/ftest.py | 7 +++ > tools/binman/missing-blob-help | 5 + > tools/binman/test/277_rockchip_tpl.dts | 16 > tools/rkcommon.c | 4 ++-- > 11 files changed, 92 insertions(+), 5 deletions(-) > create mode 100644 tools/binman/etype/rockchip_tpl.py > create mode 100644 tools/binman/test/277_rockchip_tpl.dts > > -- > 2.39.2 > >
Aw: Nand write from uboot
Hi, this is how i do nand-write on a mediatek board, if your driver is capable with mtd it should be similar: https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r3:uboot#nand_flash HTH regards Frank
[PATCH v3] arm: rockchip: switch to mainline dts for bpi-r2-pro
From: Frank Wunderlich
Use mainline DTS for Bananapi R2 Pro like the other rk356x devices.
Xhci0 has to be set to host again, as board has no id-pin to switch between
otg and hostmode.
Signed-off-by: Frank Wunderlich
---
v3:
- accidentally squashed raminit-bins, buildscript and my defconfig from test
v2:
- fixed patch to apply on master
---
.../boards/rockchip-rk3568-bpi-r2pro/board.c | 5 +-
arch/arm/dts/rk3568-bpi-r2-pro.dts| 522 +-
2 files changed, 4 insertions(+), 523 deletions(-)
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
index 1a5faa8afb12..b5d406576f89 100644
--- a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
@@ -28,8 +28,9 @@ static int rk3568_bpi_r2pro_probe(struct device_d *dev)
else
of_device_enable_path("/chosen/environment-emmc");
- rk3568_bbu_mmc_register("emmc", BBU_HANDLER_FLAG_DEFAULT, "/dev/emmc");
- rk3568_bbu_mmc_register("sd", 0, "/dev/sd");
+ rk3568_bbu_mmc_register("sd", 0, "/dev/mmc0");
+ rk3568_bbu_mmc_register("emmc", BBU_HANDLER_FLAG_DEFAULT,
+ "/dev/mmc1");
return 0;
}
diff --git a/arch/arm/dts/rk3568-bpi-r2-pro.dts
b/arch/arm/dts/rk3568-bpi-r2-pro.dts
index 8c13ddd5c103..58a2bc442fdf 100644
--- a/arch/arm/dts/rk3568-bpi-r2-pro.dts
+++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
@@ -5,24 +5,9 @@
*/
/dts-v1/;
-#include
-#include
-#include
-#include "rk3568.dtsi"
-#include "rk356x.dtsi"
-
+#include "arm64/rockchip/rk3568-bpi-r2-pro.dts"
/ {
- model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
- compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
-
- aliases {
- emmc =
- sd =
- };
-
chosen {
- stdout-path = "serial2:150n8";
-
environment-sd {
compatible = "barebox,environment";
device-path = _sd;
@@ -40,422 +25,10 @@
device_type = "memory";
reg = <0x0 0x00a0 0x0 0x7f60>;
};
-
- leds {
- compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <_led_pin _led_pin>;
-
- blue_led: led-0 {
- color = ;
- default-state = "off";
- function = LED_FUNCTION_STATUS;
- gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
- };
-
- green_led: led-1 {
- color = ;
- default-state = "on";
- function = LED_FUNCTION_POWER;
- gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
- };
- };
-
- dc_12v: dc-12v {
- compatible = "regulator-fixed";
- regulator-name = "dc_12v";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1200>;
- regulator-max-microvolt = <1200>;
- };
-
- vcc3v3_sys: vcc3v3-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- vin-supply = <_12v>;
- };
-
- vcc5v0_sys: vcc5v0-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <_12v>;
- };
-
- vcc3v3_lcd0_n: vcc3v3-lcd0-n {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_lcd0_n";
- regulator-boot-on;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc3v3_lcd1_n: vcc3v3-lcd1-n {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_lcd1_n";
- regulator-boot-on;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc5v0_host: vcc5v0-host-regulator {
- compatible = "regulator-fixed";
-
[PATCH v2] arm: rockchip: switch to mainline dts for bpi-r2-pro
From: Frank Wunderlich
Use mainline DTS for Bananapi R2 Pro like the other rk356x devices.
Xhci0 has to be set to host again, as board has no id-pin to switch between
otg and hostmode.
Signed-off-by: Frank Wunderlich
---
v2:
- fixed patch to apply on master
---
.../arm/boards/pine64-quartz64/sdram-init.bin | Bin 0 -> 59392 bytes
.../boards/rockchip-rk3568-bpi-r2pro/board.c | 5 +-
.../rockchip-rk3568-bpi-r2pro/sdram-init.bin | Bin 0 -> 59392 bytes
.../boards/rockchip-rk3568-evb/sdram-init.bin | Bin 0 -> 59392 bytes
arch/arm/configs/rk3568_defconfig | 144 +
arch/arm/dts/rk3568-bpi-r2-pro.dts| 522 +-
build.sh | 60 ++
7 files changed, 208 insertions(+), 523 deletions(-)
create mode 100644 arch/arm/boards/pine64-quartz64/sdram-init.bin
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/sdram-init.bin
create mode 100644 arch/arm/boards/rockchip-rk3568-evb/sdram-init.bin
create mode 100644 arch/arm/configs/rk3568_defconfig
create mode 100755 build.sh
diff --git a/arch/arm/boards/pine64-quartz64/sdram-init.bin
b/arch/arm/boards/pine64-quartz64/sdram-init.bin
new file mode 100644
index
..271bf5b720b6d0f1a31bc6630cf0fa6188ecf42d
GIT binary patch
literal 59392
zcmbrne|%KcnfQP1ok=nz0g_1wVG_ulBq$l(Ee!-nOPf0rM5?yJB(1Jxn+X9$;-@vB
zHG$OJNuuD!Zn;W}i``~I2%2=ebz5mO+wNw9O0{+SBiY)1w%d;rz@pM0{-{C}
z$so1e*Z2GSe*c))x%d2daS;YSQrsF|?|U77Jy58v{wa;4(BW=-g3
z>@|%%e|uSjUv0GgZe{yl`NCwA(#|$3)u@yePPm$$Tc=!o?(JL8uj^Ikr)Opsrt{y~
zGdBE=OWDB^bs(v!n#AbXgk}wd_1nHWq2;>bChvaT3Ln>FuT9O1?bM1@Jn<}blr<6T
zG{61Mp7BQo{z;b#sLs*`3mDQyi^Rg3(@iBmr{V+uIyRAXX(OS{$}8<(VH{;{
z)fUxNV^i+-*QD=eO*Lu;ZRuN6y}FG_MgLaK;wNua97uJ&0
z+pOX;w=$1v8waL&+l`avC3CuTKIyrP1M63_;~1EkX-v)E3WI~44(xS2|DJwJRs0R9
zm#f;QW?>s?*y^w|-k^JSuFz%*xKF(g?o^LEHD1MdWnR~*cr-n)jVk`S)Xz)dL
z{6|ypP2eXPi(AFD{}`M2#-G90Q}FlAj(LNMzbSPJ{~V@Y#ll)1IKFwduA$<7U_SI`
zFjcivFO6fy>A)<04-Z0f!CN#9Q{9`IA26HK^Q(l0z_uKrvMO6H(z%%|F
zXPRfW|Mj#Jo>}=>OV3n^U$krzmuu5<0J)ol~W13%XNtO5@Ct6QM
z;IDZ9{0#b!q~@okX?@3Em>>L-u6Gd+TT}DXkiW`p%wzAFiPP5I^dKMK{D+
zlpRs(KuoEXrc(Qrd%hiAq7EqZ(qKV-RlQO*m9E*ch{x9Ql_R{27xIED`+NJc?
z0d!G0da7IL*EFe&9WiL-Ho{fC&9_%GmbVyRkxv~!pL{S`(0|iAdyYGLDLpT(bp2!9VGnw=24cf4t9NQ^+wwtmLWlzlXdzovzzRU{O|M$f~oI
zu2wdYm+Vp1D^B)?8-Fl1VeoEc*2gW)v}X)p7V@x0y;98QnV(5x`?h>I@V
zm8se+#%DmA7n#!^QuOiuk@THCaYs*|YjF)P{CjIc#&-j_img`DO4~mnICev9!-
zUva(4Kc~9_Wj)B|J2Q>3)#miV?Q2KBTA=JHaMZ$DGB`iC3Vq?=@E~Ivyv2;aL|LLd
z81G_UZ?jHC-kDh`^AjB?{R=(b_;hIaTuVLpTQ}_B%vBP2d)HOa=?4xUrSUI#F9837
z>xTE?UuYxvubIXFRL}hCH2x#t`AwHAAh`M?_`iJ?|B^5Gzm50LJNPdOYmRzYS}7)`a@m*n|!q
z(z2@kZ0xnM4`36mQ=?_rKI5$AqQ`>B*Gcdm`?j*b#5iIfFyk@wl?Cp!ccWh5IC3d<
zHP(Z4-QL-{N$M)ynrKe;U#vS-W;wb^xu6R_fl(-MsPnp%fmea|AhZ>D(JU)0{eNy2
zW&)VWnX#}%xk9%{d!dE25j~wAL(3)Om3mslx;O?c+nNvP}^RyrUm=)ZRAC8sIYTfN*n3&
zn6CwSzUo5#q_jDLec7elXJx%z_sSO@2<2w{$gkXeZhmQ)nykgZyli{R`ONJV=UdSA
zV&9y0sgZM}OSiYIxo5UN(Qjo+wfUL9f8WSXcV2KeIBL}1><^FMb!?|nT29^|tMz
zyQ!1X*<-_|tVOrYw}l73Q>qRal%?%aN2i~^`e$_>^HqmOa@6$Gj7cdouI^aU0L;EJ
z%3eR%?|U%4u01*5J_4Mit03@tjyavy(JO#^o-roNc7028nfi
zzN4Q-KZtG^$Wf2~5nb~p_U<##@eQ7n^m9zNyrN^%y#LOgCmmV{%zj<93EW<E*PIdTw1Zu`
zdi6}6+H|_u+?~K~NnAJ(M&>3G=O5jvb?OZ*JGQLx7pk0)>^YPxXNGkiyk4^m*?a
zb~km6XUj$n_=q@FF_6|Kr`0&5WTAUhUdpjQ*S8m2n)P+=6Jfqz;5qST>KUB0
zCeLH9ou64L?RRCXK1n0*~|3uR0)p3^*kIm_}6lP*9nJVJV>W_gE5m5do)6#Auk
zOoxu_ky@khRQEPy3%stSuGCYklVblZ!~S$|nVe@E;Idh%JY%2Hr9zvEAwpOcPHP>vxV24=goQctLf*?JX`iNA{*ecM&+4tkq6-|
zDZX_D$w+u0&0*2HpsCb>{x8VgHc*rUe~;N$TW{
z=GjlBpZ`1GKF)Jwo*CEB--eO!{Wx9rY@Yo+DT7a*N#~u;v%e#G*=9Uhp71@vvqgCl
zJ^LJMm;?WOp8XB-ljYC(q`i}un{PiV?R;k3X;0c5NXc6QzHsWS%(wfc4*AkP!kDo!
z+g?JKIOS{e?SqoP#EcKkrp?W%E@~?LH@E64FMSE35P{O-)kV@qzGd_1$UPh=o;$K4MIkFigMf;^!s{AX8RsI=iXFTQmjmmV$Ec!W9naV#yzVwqpKV$42
zmKrMmH(C9@6SVmOFs1A&#
[PATCH] arm: rockchip: switch to mainline dts for bpi-r2-pro
From: Frank Wunderlich
Use mainline DTS for Bananapi R2 Pro like the other rk356x devices.
Xhci0 has to be set to host again, as board has no id-pin to switch between
otg and hostmode.
Signed-off-by: Frank Wunderlich
---
.../boards/rockchip-rk3568-bpi-r2pro/board.c | 5 +-
arch/arm/dts/rk3568-bpi-r2-pro.dts| 562 +-
2 files changed, 4 insertions(+), 563 deletions(-)
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
index ce633266f52c..9853bf275f9f 100644
--- a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
@@ -36,8 +36,9 @@ static int rk3568_bpi_r2pro_probe(struct device_d *dev)
defaultenv_append_directory(defaultenv);
- rk3568_bbu_mmc_register("emmc", BBU_HANDLER_FLAG_DEFAULT, "/dev/emmc");
- rk3568_bbu_mmc_register("sd", 0, "/dev/sd");
+ rk3568_bbu_mmc_register("sd", 0, "/dev/mmc0");
+ rk3568_bbu_mmc_register("emmc", BBU_HANDLER_FLAG_DEFAULT,
+ "/dev/mmc1");
return 0;
}
diff --git a/arch/arm/dts/rk3568-bpi-r2-pro.dts
b/arch/arm/dts/rk3568-bpi-r2-pro.dts
index c5cc300359c2..58a2bc442fdf 100644
--- a/arch/arm/dts/rk3568-bpi-r2-pro.dts
+++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
@@ -5,23 +5,9 @@
*/
/dts-v1/;
-#include
-#include
-#include
-#include "rk3568.dtsi"
-
+#include "arm64/rockchip/rk3568-bpi-r2-pro.dts"
/ {
- model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
- compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
-
- aliases {
- emmc =
- sd =
- };
-
chosen {
- stdout-path = "serial2:150n8";
-
environment-sd {
compatible = "barebox,environment";
device-path = _sd;
@@ -39,462 +25,10 @@
device_type = "memory";
reg = <0x0 0x00a0 0x0 0x7f60>;
};
-
- leds {
- compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <_led_pin _led_pin>;
-
- blue_led: led-0 {
- color = ;
- default-state = "off";
- function = LED_FUNCTION_STATUS;
- gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
- };
-
- green_led: led-1 {
- color = ;
- default-state = "on";
- function = LED_FUNCTION_POWER;
- gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
- };
- };
-
- dc_12v: dc-12v {
- compatible = "regulator-fixed";
- regulator-name = "dc_12v";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1200>;
- regulator-max-microvolt = <1200>;
- };
-
- vcc3v3_sys: vcc3v3-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- vin-supply = <_12v>;
- };
-
- vcc5v0_sys: vcc5v0-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <_12v>;
- };
-
- vcc3v3_lcd0_n: vcc3v3-lcd0-n {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_lcd0_n";
- regulator-boot-on;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc3v3_lcd1_n: vcc3v3-lcd1-n {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_lcd1_n";
- regulator-boot-on;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc5v0_usb: vcc5v0_usb {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_usb";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <5
Aw: Re: helping with remapping vmem for dma
> Gesendet: Freitag, 17. Juni 2022 um 19:22 Uhr > Von: "Robin Murphy" > An: "Frank Wunderlich" , "Christoph Hellwig" > > Cc: linux-ker...@vger.kernel.org, iommu@lists.linux-foundation.org, "Marek > Szyprowski" > Betreff: Re: helping with remapping vmem for dma > > On 2022-06-17 17:17, Frank Wunderlich wrote: > > Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig : > >> On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote: > >>> Put simply, if you want to call dma_map_single() on a buffer, then that > >>> buffer needs to be allocated with kmalloc() (or technically alloc_pages(), > >>> but then dma_map_page() would make more sense when dealing with entire > >>> pages. > >> > >> Yes. It sounds like the memory here comes from the dma coherent > >> allocator, in which case the code need to use the address returned > >> by that and not create another mapping. > > > > Hi > > > > traced it to buffer allocated as simple uint8-array [1]: > > > > UINT_8 aucBuffer[sizeof(INIT_HIF_RX_HEADER_T) + > > sizeof(INIT_EVENT_CMD_RESULT)]; > > Ah, so it's trying to do DMA with a stack variable? CONFIG_DMA_API_DEBUG > is your friend; it should have screamed about that specifically. > Allocate this buffer properly to begin with, and free it again on the > way out of the function (it's surely not worth having to make a > temporary copy further down the callchain). The kmalloc flags can > probably be regular GFP_KERNEL, unless this can be called from more > restrictive contexts like an IRQ handler - the fact that it might be > mapped for DMA later is essentially irrelevant in that respect. Hi, simply replaced the stack-vars to uint_8-pointers and using kmalloc/kfree for memory handling (needed to replace some returns to goto to always free memory). Thanks very much for support, driver is now working again :) https://github.com/frank-w/BPI-R2-4.14/commit/7f3a721d5b0d8ca44935c23d5513a19cc57786c0 > Thanks, > Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: helping with remapping vmem for dma
Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig :
>On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote:
>> Put simply, if you want to call dma_map_single() on a buffer, then that
>> buffer needs to be allocated with kmalloc() (or technically alloc_pages(),
>> but then dma_map_page() would make more sense when dealing with entire
>> pages.
>
>Yes. It sounds like the memory here comes from the dma coherent
>allocator, in which case the code need to use the address returned
>by that and not create another mapping.
Hi
traced it to buffer allocated as simple uint8-array [1]:
UINT_8 aucBuffer[sizeof(INIT_HIF_RX_HEADER_T) + sizeof(INIT_EVENT_CMD_RESULT)];
and then called as
nicRxWaitResponse(prAdapter,0,aucBuffer,sizeof(INIT_HIF_RX_HEADER_T) +
sizeof(INIT_EVENT_CMD_RESULT),/* 4B + 4B */
)
this calls [2]:
WLAN_STATUS
nicRxWaitResponse(IN P_ADAPTER_T prAdapter,
IN UINT_8 ucPortIdx, OUT PUINT_8 pucRspBuffer, IN UINT_32
u4MaxRespBufferLen, OUT PUINT_32 pu4Length)
{
...
HAL_PORT_RD(prAdapter,ucPortIdx == 0 ? MCR_WRDR0 : MCR_WRDR1, u4PktLen,
pucRspBuffer, u4MaxRespBufferLen);
}
nicRxWaitResponse contains a do-while(true)-loop, but it looks like this is
failing on first call (i see my debug before call of HAL_PORT_RD only once)...
do i need kmalloc before call of nicRxWaitResponse and if yes which flags are
right here?
https://www.kernel.org/doc/htmldocs/kernel-api/API-kmalloc.html
callstack is like this:
[ 126.919569] __dma_page_dev_to_cpu from kalDevPortRead+0x3a0/0x6b4
[wlan_gen2]
[ 126.928643] kalDevPortRead [wlan_gen2] from nicRxWaitResponse+0x4c0/0x61c
[wlan_gen2]
[ 126.939752] nicRxWaitResponse [wlan_gen2] from
wlanImageSectionDownloadStatus.part.0+0xd0/0x26c [wlan_gen2]
[ 126.952783] wlanImageSectionDownloadStatus.part.0 [wlan_gen2] from
wlanImageSectionDownload+0x168/0x36c [wlan_gen2]
[ 126.966511] wlanImageSectionDownload [wlan_gen2] from
wlanAdapterStart+0x674/0xf94 [wlan_gen2]
[ 126.978367] wlanAdapterStart [wlan_gen2] from wlanProbe+0x318/0xbe8
[wlan_gen2]
[ 126.988951] wlanProbe [wlan_gen2] from HifAhbProbe+0x54/0x88 [wlan_gen2]
[ 126.998905] HifAhbProbe [wlan_gen2] from wmt_func_wifi_on+0x4c/0x150
regards Frank
[1]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/common/wlan_lib.c#L3046
[2]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/nic/nic_rx.c#L3604
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: helping with remapping vmem for dma
Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig : >On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote: >> Put simply, if you want to call dma_map_single() on a buffer, then that >> buffer needs to be allocated with kmalloc() (or technically alloc_pages(), >> but then dma_map_page() would make more sense when dealing with entire >> pages. > >Yes. It sounds like the memory here comes from the dma coherent >allocator, in which case the code need to use the address returned >by that and not create another mapping. As i have not found position where memory is allocated (this is a very huge and dirty driver) is it maybe possible to check if buf is such "allready dma" memory (maybe is_vmalloc_addr) and call dma_single_map only if not (using original buf if yes)? But i guess it should map only a part of available (pre-allocated) memory and other parts of this are used somewhere else. So i can ran into some issues caused by sharing this full block in different functions. Hi, Thanks for first suggestions. regards Frank ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
helping with remapping vmem for dma
Hi,
i have upported a wifi-driver (mt6625l for armhf) for some time and fall now
(at least 5.18) in the
"rejecting DMA map of vmalloc memory" error [1].
maybe anybody here can guide me on how to nail it down and maybe fix it.
as far as i have debugged it, it uses dma_map_single [2] to get dma memory from
a previous
allocated memory region.
this function "kalDevPortRead" in [2] is used via macro HAL_PORT_RD [3] (used
in HAL_READ_RX_PORT
and HAL_READ_INTR_STATUS in same hal.h file)
HAL_READ_INTR_STATUS is always called with an empty int array as buf which i
guess is not the problem.
I think the issue is using the use with an preallocated prSDIOCtrl struct (have
not completely traced
it back where it is allocated).
calls of HAL_PORT_RD/HAL_READ_RX_PORT are in nic{,_rx}.c (with sdio-struct)
([4] as example)
maybe there is a simple way to get an address in preallocated memory as
replacement for the dma_map_simple call (and the unmap of course).
regards Frank
[1]
https://elixir.bootlin.com/linux/latest/source/include/linux/dma-mapping.h#L327
[2]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/os/linux/hif/ahb/ahb.c#L940
[3]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/include/nic/hal.h#L176
[4]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/nic/nic_rx.c#L3604
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Aw: Re: Re: Re: Driver load order
Hi,
as far as i looked into the linux driver and the binding-conversion [1] i think
adding those fields is not enough
as the supply needs to be set from the upper values (vccX-supply) of the rk808
pmic.
in core it seems that this recursion is not implemented yet (like the check for
rdev->supply)
from binding i mean this part:
vcc1-supply: The input supply for DCDC_REG1
vcc2-supply: The input supply for DCDC_REG2
vcc3-supply: The input supply for DCDC_REG3
vcc4-supply: The input supply for DCDC_REG4
vcc6-supply: The input supply for LDO_REG1 and LDO_REG2
vcc7-supply: The input supply for LDO_REG3 and LDO_REG7
vcc8-supply: The input supply for SWITCH_REG1
vcc9-supply: The input supply for LDO_REG4 and LDO_REG5
vcc10-supply: The input supply for LDO_REG6
vcc11-supply: The input supply for LDO_REG8
regards Frank
[1]
https://patchwork.kernel.org/project/linux-rockchip/patch/20220519161731.1168-1-macroalph...@gmail.com/
> Gesendet: Dienstag, 24. Mai 2022 um 10:53 Uhr
> Von: "Ahmad Fatoum"
> An: "Frank Wunderlich" , "Sascha Hauer"
>
> Cc: barebox@lists.infradead.org
> Betreff: Re: Aw: Re: Re: Driver load order
>
> Hello Frank,
>
> On 21.05.22 12:31, Frank Wunderlich wrote:
> > Hi,
> >
> > current state is that pmu/ldo regulators work, but not the SWITCH ones.
> >
> > these are read by linux using the supply of the regulator itself
> >
> > } else if (rdev->supply) {
> > ret = regulator_get_voltage_rdev(rdev->supply->rdev);
> >
> > tried to port this to barebox, but regulator-struct there does not have the
> > supply member
> >
> > } else if (rdev->supply) {
> > ret = regulator_get_voltage(rdev->supply);
> >
> > so i added it here:
> >
> > +++ b/include/regulator.h
> > @@ -86,6 +86,7 @@ struct regulator_dev {
> > struct regmap *regmap;
> > bool boot_on;
> > bool always_on;
> > + struct regulator *supply;
>
> I think this should go into struct regulator_internal instead?
> (You'll need to rename the current const char *supply there).
>
> > /* the device this regulator device belongs to */
> > struct device_d *dev;
> >
> > but now this needs to be set somwhere...linux set this in
> >
> > set_supply(struct regulator_dev *rdev,
> > struct regulator_dev *supply_rdev)
> > which is called in regulator_resolve_supply (called by _regulator_get).
>
> Ah, I missed b8074eba2a6b ("regulator: RK808: Add proper input supplies
> for rk808"). I recall now that I had ported an older version of the Linux
> driver to make porting work easier.
>
> You should probably add a supply_name member into struct regulator_desc
> and then propagate this to core, so core can request it.
>
> Cheers,
> Ahmad
>
> >
> > regards Frank
> >
> >
> >> Gesendet: Donnerstag, 19. Mai 2022 um 15:10 Uhr
> >> Von: "Sascha Hauer"
> >> I gave it a test with your rk808 driver. It just works \o/
> >>
> >> regulator_get() triggers probing of the rk808 regulator driver and
> >> returns a valid regulator.
> >>
> >> Sascha
> >
> >
>
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Re: Driver load order
Hi,
current state is that pmu/ldo regulators work, but not the SWITCH ones.
these are read by linux using the supply of the regulator itself
} else if (rdev->supply) {
ret = regulator_get_voltage_rdev(rdev->supply->rdev);
tried to port this to barebox, but regulator-struct there does not have the
supply member
} else if (rdev->supply) {
ret = regulator_get_voltage(rdev->supply);
so i added it here:
+++ b/include/regulator.h
@@ -86,6 +86,7 @@ struct regulator_dev {
struct regmap *regmap;
bool boot_on;
bool always_on;
+ struct regulator *supply;
/* the device this regulator device belongs to */
struct device_d *dev;
but now this needs to be set somwhere...linux set this in
set_supply(struct regulator_dev *rdev,
struct regulator_dev *supply_rdev)
which is called in regulator_resolve_supply (called by _regulator_get).
regards Frank
> Gesendet: Donnerstag, 19. Mai 2022 um 15:10 Uhr
> Von: "Sascha Hauer"
> I gave it a test with your rk808 driver. It just works \o/
>
> regulator_get() triggers probing of the rk808 regulator driver and
> returns a valid regulator.
>
> Sascha
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Re: Driver load order
Hi
> Gesendet: Donnerstag, 19. Mai 2022 um 15:10 Uhr
> Von: "Sascha Hauer"
>
> I gave it a test with your rk808 driver. It just works \o/
>
> regulator_get() triggers probing of the rk808 regulator driver and
> returns a valid regulator.
Added rk808 drivers to my and added basic Kconfig/Makefile entry for mfd driver.
chip-id of my pmic is read:
rk808 rk8090: chip id: 0x8090
looks like regulators are enabled during access from my iodomain driver :)
except vccio4/5
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:pmuio1
(404b0450) uV:330
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:pmuio2
(404b0980) uV:330
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio1
(404b0eb0) uV:90
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio3
(4049c720) uV:330
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio4
(4049cc50) uV:-22
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio5
(4049a180) uV:-22
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio6
(4049a6a8) uV:180
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio7
(4049abd8) uV:-22
vccio 4/5 using regulator with name SWITCH_REG1, maybe this is not registered?
_io_domains {
pmuio1-supply = <_pmu>;
pmuio2-supply = <_pmu>;
vccio1-supply = <_acodec>;
vccio3-supply = <_sd>;
vccio4-supply = <_3v3>;
vccio5-supply = <_3v3>;
vccio6-supply = <_1v8>;
vccio7-supply = <_3v3>;
status = "okay";
};
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Driver load order
Hi,
> Gesendet: Donnerstag, 19. Mai 2022 um 13:54 Uhr
> Von: "Sascha Hauer"
> An: "Frank Wunderlich"
> Cc: barebox@lists.infradead.org
> Betreff: Re: Driver load order
>
> Hi Frank,
>
> On Thu, May 19, 2022 at 12:59:35PM +0200, Frank Wunderlich wrote:
> > Hi,
> >
> > I try to create a basic driver for rk808 pmic/iodomains. I've noticed
> > that first the iodomain driver is probed and then the rk808 on,but i
> > need it reversed as rk808 registers regulators linked in iodomain via
> > devicetree.
> >
> > How can i defer iodomain probing till rk808 is ready (regulators
> > available defined as phandles in iodomain dt node)? Currently i get
> > always ENODEV (property does not exist or regulator is not ready
> > yet)
>
> Your board has deep probe enabled. The idea with deep probe is that the
> devices for a specific device node are registered on demand instead of
> any particular order. Basically this means that once you do a
> regulator_get() the regulator will be registered automatically for you
> without having to mess with the probe order.
regulator_get returns Null in my case. So imho i need to register
the regulators from the rk808, right?
currently i probe the rk808 and do a double child-loop (first subnodes,
second subnode "regulators"). Then i have the regulator node itself and
i can do something like this:
struct regulator_dev *rd;
ret=of_regulator_register(rd,regchild);
including the loops to have the context:
struct device_node *child,*regchild;
for_each_child_of_node(dev->device_node, child) {
if (!strcmp(child->name,"regulators"))
{
dev_info(dev, "DEBUG %s:%d regulators
found\n",__FUNCTION__,__LINE__);
for_each_child_of_node(child, regchild) {
struct regulator_dev *rd;
ret=of_regulator_register(rd,regchild);
}
}
}
> That said I'm not sure if that works properly with regulators yet. For
> deep probe to work there must be a device registered for the device node
> representing the regulator. Currently this is not the case, there will
> only be a device for the "rockchip,rk808" device node, but not for the
> regulator child nodes.
as an idea i would do something like this in the iodomain-drivers probe:
if (!pmic_probed())
return -EPROBE_DEFER
but how can i check the pmic is probed? to delay the probing of the
iodomain driver. I check if the linked phandles are there and
not registered...here i get -ENODEV (-19), but if the proeprty does
not exist i get Null from of_regulator_get(). Basicly i can defer the
probe there (kernel and my current code do a continue here), but i
think it's better to do it before looping over the properties of iodomain.
> I haven't found a suitable test setup to have a deeper look. If you
> could bring your rk808 driver up to a point where it actually registers
> the regulators then I could add the missing pieces in the regulator core
> for you.
>
> Sascha
@ahmad: thanks for your driver. Take a quick look into it...
it seems nearly complete, is there anything not working or was the only
problem the missing regmap-handling added in part1?
My current approach is only register the regulators without doing a real
pmic init. IO-Domain driver only needs to read out regulator voltage, i'm
not sure if it's enough to get the value from the DT or if it needs to be
really measured (to depend on complete probe/init of the pmic).
but the problem is that iodomain is probed before the pmic due to deep-probing
if i understand Sascha the right way. So i need a way to defer the iodomain
driver
probe till rk808 is ready.
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Driver load order
Hi, I try to create a basic driver for rk808 pmic/iodomains. I've noticed that first the iodomain driver is probed and then the rk808 on,but i need it reversed as rk808 registers regulators linked in iodomain via devicetree. How can i defer iodomain probing till rk808 is ready (regulators available defined as phandles in iodomain dt node)? Currently i get always ENODEV (property does not exist or regulator is not ready yet) This is my current (dirty) source: https://github.com/frank-w/barebox-r2pro/commits/r2pro-iodomain regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [urgent] ARM: rockchip: fix iodomain for r2pro V1.0
Am 16. Mai 2022 10:41:26 MESZ schrieb Sascha Hauer :
>On Sat, May 14, 2022 at 05:56:09PM +0200, Frank Wunderlich wrote:
>> From: Frank Wunderlich
>>
>> Current code sets vccio4 and vccio6 both to 1v8. R2Pro v1.0 needs 3v3
>> setting on vccio4, else gmac0 (switch for lan-ports) will be damaged.
>
>By damaged you mean physically damaged? How can this happen? Does that
>mean some input signals are not 3v3 tolerant when the domain is
>supplied
>with 1v8?
Yes, if iodomain is set to 1v8 and board works with 3v3 signals it breaks
hardware physically (affected me). I know this for device tree,but did not
noticed this direct register write.
>Sascha
>
>>
>> IO-domain is per default 3v3 so only vccio6 needs to be set to 1v8
>and
>> clear this bit in the 3v3 register.
>>
>> Fixes: 8ba96c5942d6 ("ARM: rockchip: add BPI-R2-Pro V00 board")
>> Signed-off-by: Frank Wunderlich
>> ---
>> arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c | 9 ++---
>> arch/arm/mach-rockchip/include/mach/rockchip.h | 3 +++
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
>b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
>> index 4c5b4751b3fb..2a6e0700233a 100644
>> --- a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
>> +++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
>> @@ -17,10 +17,13 @@ static noinline void rk3568_start(void
>*fdt_blob_fixed_offset)
>> void *fdt;
>>
>> /*
>> - * Enable vccio4 1.8V and vccio6 1.8V
>> - * Needed for GMAC to work.
>> + * set iodomain vccio6 to 1.8V needed for GMAC1 to work.
>> + * vccio4 (gmac0/switch) needs to stay at 3v3 (default)
>> */
>> -writel(RK_SETBITS(0x50), 0xfdc20140);
>> +//set bit 6 in PMU_GRF_IO_VSEL0 for vccio6 1v8
>> +writel(RK_SETBITS(BIT(6)), PMU_GRF_IO_VSEL0);
>> +//clear bit 6 for 3v3 as it was set to 1v8
>> +writel(RK_CLRBITS(BIT(6)), PMU_GRF_IO_VSEL1);
>>
>> fdt = fdt_blob_fixed_offset;
>>
>> diff --git a/arch/arm/mach-rockchip/include/mach/rockchip.h
>b/arch/arm/mach-rockchip/include/mach/rockchip.h
>> index f24db36f0161..ff8b1109f858 100644
>> --- a/arch/arm/mach-rockchip/include/mach/rockchip.h
>> +++ b/arch/arm/mach-rockchip/include/mach/rockchip.h
>> @@ -23,6 +23,9 @@ static inline int rk3288_init(void)
>>
>> #ifdef CONFIG_ARCH_RK3568
>> int rk3568_init(void);
>> +#define PMU_GRF 0xfdc2
>> +#define PMU_GRF_IO_VSEL0(PMU_GRF + 0x140)
>> +#define PMU_GRF_IO_VSEL1(PMU_GRF + 0x144)
>> #else
>> static inline int rk3568_init(void)
>> {
>> --
>> 2.25.1
>>
>>
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[urgent] ARM: rockchip: fix iodomain for r2pro V1.0
From: Frank Wunderlich
Current code sets vccio4 and vccio6 both to 1v8. R2Pro v1.0 needs 3v3
setting on vccio4, else gmac0 (switch for lan-ports) will be damaged.
IO-domain is per default 3v3 so only vccio6 needs to be set to 1v8 and
clear this bit in the 3v3 register.
Fixes: 8ba96c5942d6 ("ARM: rockchip: add BPI-R2-Pro V00 board")
Signed-off-by: Frank Wunderlich
---
arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c | 9 ++---
arch/arm/mach-rockchip/include/mach/rockchip.h | 3 +++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
index 4c5b4751b3fb..2a6e0700233a 100644
--- a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
@@ -17,10 +17,13 @@ static noinline void rk3568_start(void
*fdt_blob_fixed_offset)
void *fdt;
/*
-* Enable vccio4 1.8V and vccio6 1.8V
-* Needed for GMAC to work.
+* set iodomain vccio6 to 1.8V needed for GMAC1 to work.
+* vccio4 (gmac0/switch) needs to stay at 3v3 (default)
*/
- writel(RK_SETBITS(0x50), 0xfdc20140);
+ //set bit 6 in PMU_GRF_IO_VSEL0 for vccio6 1v8
+ writel(RK_SETBITS(BIT(6)), PMU_GRF_IO_VSEL0);
+ //clear bit 6 for 3v3 as it was set to 1v8
+ writel(RK_CLRBITS(BIT(6)), PMU_GRF_IO_VSEL1);
fdt = fdt_blob_fixed_offset;
diff --git a/arch/arm/mach-rockchip/include/mach/rockchip.h
b/arch/arm/mach-rockchip/include/mach/rockchip.h
index f24db36f0161..ff8b1109f858 100644
--- a/arch/arm/mach-rockchip/include/mach/rockchip.h
+++ b/arch/arm/mach-rockchip/include/mach/rockchip.h
@@ -23,6 +23,9 @@ static inline int rk3288_init(void)
#ifdef CONFIG_ARCH_RK3568
int rk3568_init(void);
+#define PMU_GRF0xfdc2
+#define PMU_GRF_IO_VSEL0 (PMU_GRF + 0x140)
+#define PMU_GRF_IO_VSEL1 (PMU_GRF + 0x144)
#else
static inline int rk3568_init(void)
{
--
2.25.1
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: [PATCH 0/2] align rk356x drivers as preparation for mainline dts
Hi, > Gesendet: Montag, 09. Mai 2022 um 13:36 Uhr > Von: "Michael Riesch" > The changes are tested exclusively on the RK3568 EVB1 -- Frank, if you could > give this a test on the BananaPi it would be great. currently usb on r2pro v1 is broken in barebox. Have got it working for upper port and then applied this series. It does not seem to break anything, upper port still working in my local repo (based on master). > Looking forward to your comments! > > Best regards, > Michael regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Aw: [PATCH v11 17/24] arm64: dts: rockchip: rk356x: Add HDMI nodes
Hi,
> Gesendet: Freitag, 22. April 2022 um 09:28 Uhr
> Von: "Sascha Hauer"
> Betreff: [PATCH v11 17/24] arm64: dts: rockchip: rk356x: Add HDMI nodes
>
> Add support for the HDMI port found on RK3568.
>
> Signed-off-by: Sascha Hauer
> ---
>
> Notes:
> Changes since v7:
> - Rename hclk to niu
clock-name no more present since v9, see below
> Changes since v5:
> - Drop unnecessary #size-cells/#address-cells from nodes with only single
> endpoint
>
...
> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> @@ -620,6 +620,38 @@ vop_mmu: iommu@fe043e00 {
> status = "disabled";
> };
>
> + hdmi: hdmi@fe0a {
> + compatible = "rockchip,rk3568-dw-hdmi";
> + reg = <0x0 0xfe0a 0x0 0x2>;
> + interrupts = ;
> + clocks = < PCLK_HDMI_HOST>,
> + < CLK_HDMI_SFR>,
> + < CLK_HDMI_CEC>,
> + < CLK_HDMI_REF>,
> + < HCLK_VO>;
> + clock-names = "iahb", "isfr", "cec", "ref";
noticed there are still 5 clocks, but only 4 clock-names. So i added "niu"
after ref.
maybe missing clock-name was causing my iommu page-faults...on a quick test i
have not got it,
but they came not every time.
what do you think?
> + pinctrl-names = "default";
> + pinctrl-0 = <_scl _sda _cec>;
> + power-domains = < RK3568_PD_VO>;
regards Frank
[PATCH] ARM: Rockchip: Update DTS for BPI-R2Pro for new HW-Rev
From: Frank Wunderlich
New Hardware revision swapped the gmacs (wan is now gmac1).
Previous Revision (v00) was not in public sale so devicetree
can be savely changed.
Signed-off-by: Frank Wunderlich
---
arch/arm/dts/rk3568-bpi-r2-pro.dts | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/dts/rk3568-bpi-r2-pro.dts
b/arch/arm/dts/rk3568-bpi-r2-pro.dts
index ef2e0c33e663..cc1bab37074a 100644
--- a/arch/arm/dts/rk3568-bpi-r2-pro.dts
+++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
@@ -120,20 +120,20 @@
};
};
- {
- assigned-clocks = < SCLK_GMAC0_RX_TX>, < SCLK_GMAC0>;
- assigned-clock-parents = < SCLK_GMAC0_RGMII_SPEED>, <
CLK_MAC0_2TOP>;
- assigned-clock-rates = <0>, <12500>;
- clock_in_out = "input";
- phy-handle = <_phy0>;
+ {
+ assigned-clocks = < SCLK_GMAC1_RX_TX>, < SCLK_GMAC1>;
+ assigned-clock-parents = < SCLK_GMAC1_RGMII_SPEED>, <
CLK_MAC1_2TOP>;
+ clock_in_out = "output";
+ phy-handle = <_phy1>;
phy-mode = "rgmii";
pinctrl-names = "default";
- pinctrl-0 = <_miim
-_tx_bus2
-_rx_bus2
-_rgmii_clk
-_rgmii_bus>;
- snps,reset-gpio = < RK_PB7 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <_miim
+_tx_bus2
+_rx_bus2
+_rgmii_clk
+_rgmii_bus>;
+
+ snps,reset-gpio = < RK_PB0 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
/* Reset time is 20ms, 100ms for rtl8211f */
snps,reset-delays-us = <0 2 10>;
@@ -367,8 +367,8 @@
status = "disabled";
};
- {
- rgmii_phy0: ethernet-phy@0 {
+ {
+ rgmii_phy1: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0x0>;
};
--
2.25.1
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
Hi, it turned out that my problem is not wrong setting...it was the load method. i loaded barebox by uboot like it's documented here: https://www.barebox.org/doc/latest/user/barebox.html#starting-barebox except i have loaded files via fatload and not tftp. if i flash barebox and boot directly into it, network works (also with first version of dts with rx-delay/tx-delay and rgmii phy_mode). barebox@BPI R2PRO:/ dhcp eth1 eth1: 1000Mbps full duplex link detected WARNING: eth1: No MAC address set. Using random address 92:26:6a:9c:ec:d5 T T T eth1: DHCP client bound to address 192.168.0.104 barebox@BPI R2PRO:/ ping 192.168.0.10 PING 192.168.0.10 (192.168.0.10) host 192.168.0.10 is alive so imho there are 2 possible rootcauses - uboot has initialized anything (clocks/pinctrl/...) which barebox cannot change afterwards (due to missing reset) - barebox skips any initialization step if it is chainloaded i have now tested both configurations (rgmii+delays and rgmii-id without delay-properties, but delays set in driver). linux is already updated in next to the rgmii+delays part, so i would send this as update to barebox. regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
Am 10. April 2022 09:41:06 MESZ schrieb Oleksij Rempel :
>Normally we use phy-mode with predefined values:
>- rgmii == tx/rx delay is 0
>- rgmii-id == PHY configures tx and rx delays to closest possible
>values to 2.8ns
>- rgmii-txid == PHY configures only tx delay to 2.8ns, rx is 0
>- rgmii-rxid == same as rgmii-txid but for rx.
>
>Using raw values or fine tuning this delays makes no sense in 99%
>cases.
So i need to disable the delay-configuration and set rgmii-id. Do i need to set
only on mac or on the phy too?
https://git.pengutronix.de/cgit/barebox/tree/drivers/net/designware_rockchip.c#n117
Set flags to RK3568_GMAC_{R,T}XCLK_DLY_DISABLE and disable second regmap write.
Board has a realtek phy which is defined in dts only with this:
{
rgmii_phy1: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0x0>;
};
};
https://github.com/frank-w/barebox-r2pro/blob/b13021268148954a59682620ab284054b25448e4/arch/arm/dts/rk3568-bpi-r2-pro.dts#L373
Can i check if the phy is recognized on mdio-bus and initialized? I see it in
the devlist,but not sure if this means that it is completely initialized.
>Since the PHY and the driver, used on this boards, supports internal
>delay configuration, it makes
>no sense to spend any time on this kind of investigation for this or
>any other board. All embedded
>boards would work with "rgmii-id" and no delay on the MAC side. Which
>should be default MAC
>configuration without additional device tree properties, except of
>buggy driver or MACs with
>integrated not configurable delays, or boards with insanely long traces
>for rgmii clk.
>
>As I already said, except of delays there can be other issue. For
>example:
>- incorrect pinmux configuration
>- incorrect RGMII clock source configuration
>- incorrect MAC or PHY mode configuration (xMII instead of RGMII)
>- incorrect reset or power up sequence affecting proper bootstrap
>configuration.
>- incorrect MDIO configuration, for example CLK rate outside of range
>supported by the PHY.
>- not properly configured SoCs internal clock dependencies.
>- some missing "enable" bit on the PHY or the MAC side
I more guess something like the last 2 is the problem as the delay-settings
work in linux. But have not completely understood all parts. Imho pinmux is
done on usage. So if i use
pinctrl-0 = <_miim _tx_bus2
_rx_bus2_rgmii_clk
_rgmii_bus>;
The pinmux should be set,or am i wrong?
https://github.com/frank-w/barebox-r2pro/blob/b13021268148954a59682620ab284054b25448e4/arch/arm/dts/rk3568-pinctrl.dtsi#L705
Afaik gmac1 uses fixed 125MHz clock (it came from cru like gmac0) as
clock_in_out is set to output.
assigned-clocks = < SCLK_GMAC1_RX_TX>, < SCLK_GMAC1>;
assigned-clock-parents = < SCLK_GMAC1_RGMII_SPEED>, < CLK_MAC1_2TOP>;
I basicly use the config from linux,which i had mostly taken from vendors repo.
As the first version (used the other gmac for wan-port) worked,i guess the phy
and mac driver is right. Same for clock driver and constant values.
>Even if you don't like the fact, that for most of this cases, scope
>will reduce dramatically
>investigation time. I'll need to repeat it, it will help to use the
>scope.
I have none and if i'm not sure if i can trace it right because it's decades
ago i made something with one.
So i search ways to check it in software as far as possible. Maybe there are
ways to read out registers to check if phy is available and compare values with
linux.
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
> Gesendet: Samstag, 09. April 2022 um 10:04 Uhr > Von: "Oleksij Rempel" > An: fran...@public-files.de, "Ahmad Fatoum" > Cc: barebox@lists.infradead.org > Betreff: Re: change r2pro dts to public hw version (was "Board code with 2 > dts" ) > > Am 08.04.22 um 19:19 schrieb Frank Wunderlich: > > Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel > > : > >> Hi Frank > >> > >> Am 08.04.22 um 13:03 schrieb Frank Wunderlich: > >>> Hi, > >>> > >>> have now the new board, but cannot get the gmac working in barebox. > >> In linux i have it working > >>> > >>> > >> https://github.com/frank-w/BPI-R2-4.14/blob/5.17-main/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L235 > >>> > >>> changed the dts in barebox to same values, but cannot get it working > >>> > >>> > >> https://github.com/frank-w/barebox-r2pro/blob/r2pro/arch/arm/dts/rk3568-bpi-r2-pro.dts#L123 > >>> > >>> i see both interfaces, but it looks like the phy (rtl8211F) is not > >> working in barebox > >> > >> The rgmii configuration is may be wrong. > >> > >> phy-mode = "rgmii" looks not realistic. The "rgmii" is only possible if > >> rgmii clock line on this > >> board is about 20cm longer compared to rgmii data lines. I doubt it is > >> the case :) > >> > >> So, it looks like the delay was added as separate property for the MAC. > >> Without reading manual for > >> this chip I can't interprete this values looks somehow strange: > >>tx_delay = <0x4f>; > >>rx_delay = <0x0f>; > >> > >> Normally delays are equal for both directions. > >> Best practice is: MAC do not adds delays, PHY will do it (PHY driver > >> should be enabled) > >> > >>> barebox@BPI R2PRO:/ dhcp eth1 > >>> eth1: 1000Mbps full duplex link detected > >>> eth1: 1000Mbps full duplex link detected > >>> WARNING: eth1: No MAC address set. Using random address > >> e2:3c:a9:08:b8:c8 > >>> T T T T T T T T T T T eth1: link down > >>> T dhcp: Network is down > >>> barebox@BPI R2PRO:/ eth1: 1000Mbps full duplex link detected > >>> > >>> barebox@BPI R2PRO:/ > >>> barebox@BPI R2PRO:/ > >>> barebox@BPI R2PRO:/ > >>> barebox@BPI R2PRO:/ devinfo eth1 > >>> Parent: fe01.ether...@fe01.of > >>> Parameters: > >>> ethaddr: e2:3c:a9:08:b8:c8 (type: MAC) > >>> gateway: 0.0.0.0 (type: ipv4) > >>> ipaddr: 0.0.0.0 (type: ipv4) > >>> linux.bootargs: (type: string) > >>> linux.devname: (type: string) > >>> mode: dhcp (type: enum) (values: "dhcp", "static", "disabled") > >>> netmask: 0.0.0.0 (type: ipv4) > >>> serverip: (type: string) > >>> barebox@BPI R2PRO:/ eth1.mode=static > >>> barebox@BPI R2PRO:/ eth1.netmask=255.255.255.0 > >>> barebox@BPI R2PRO:/ eth1.ipaddr=192.168.0.18 > >>> barebox@BPI R2PRO:/ devinfo eth1 > >>> Parent: fe01.ether...@fe01.of > >>> Parameters: > >>> ethaddr: e2:3c:a9:08:b8:c8 (type: MAC) > >>> gateway: 0.0.0.0 (type: ipv4) > >>> ipaddr: 192.168.0.18 (type: ipv4) > >>> linux.bootargs: (type: string) > >>> linux.devname: (type: string) > >>> mode: static (type: enum) (values: "dhcp", "static", "disabled") > >>> netmask: 255.255.255.0 (type: ipv4) > >>> serverip: (type: string) > >>> barebox@BPI R2PRO:/ global.net.nameserver=192.168.0.10 > >>> barebox@BPI R2PRO:/ ifup eth1 > >>> barebox@BPI R2PRO:/ ping 192.168.0.10 > >>> T T T T T ping failed: Connection timed out > >>> barebox@BPI R2PRO:/ > >>> > >>> devinfo without device shows me this: > >>> > >>> `-- fe01.ether...@fe01.of > >>> `-- miibus0 > >>> `-- mdio0-phy00 > >>> `-- 0x-0x003f ( 64 Bytes): /dev/mdio0-phy00 > >>> `-- eth1 > >>> `-- fe2a.ether...@fe2a.of > >>> `-- miibus1 > >>> `-- eth0 > >>> > >>> any idea how to trace the problem down? > >>> > >>> regards Frank > > > >> -- > >> Regards, > >> Oleksij > > > > Thanks for first l
Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel : >Hi Frank > >Am 08.04.22 um 13:03 schrieb Frank Wunderlich: >> Hi, >> >> have now the new board, but cannot get the gmac working in barebox. >In linux i have it working >> >> >https://github.com/frank-w/BPI-R2-4.14/blob/5.17-main/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L235 >> >> changed the dts in barebox to same values, but cannot get it working >> >> >https://github.com/frank-w/barebox-r2pro/blob/r2pro/arch/arm/dts/rk3568-bpi-r2-pro.dts#L123 >> >> i see both interfaces, but it looks like the phy (rtl8211F) is not >working in barebox > >The rgmii configuration is may be wrong. > >phy-mode = "rgmii" looks not realistic. The "rgmii" is only possible if >rgmii clock line on this >board is about 20cm longer compared to rgmii data lines. I doubt it is >the case :) > >So, it looks like the delay was added as separate property for the MAC. >Without reading manual for >this chip I can't interprete this values looks somehow strange: > tx_delay = <0x4f>; > rx_delay = <0x0f>; > >Normally delays are equal for both directions. >Best practice is: MAC do not adds delays, PHY will do it (PHY driver >should be enabled) > >> barebox@BPI R2PRO:/ dhcp eth1 >> eth1: 1000Mbps full duplex link detected >> eth1: 1000Mbps full duplex link detected >> WARNING: eth1: No MAC address set. Using random address >e2:3c:a9:08:b8:c8 >> T T T T T T T T T T T eth1: link down >> T dhcp: Network is down >> barebox@BPI R2PRO:/ eth1: 1000Mbps full duplex link detected >> >> barebox@BPI R2PRO:/ >> barebox@BPI R2PRO:/ >> barebox@BPI R2PRO:/ >> barebox@BPI R2PRO:/ devinfo eth1 >> Parent: fe01.ether...@fe01.of >> Parameters: >> ethaddr: e2:3c:a9:08:b8:c8 (type: MAC) >> gateway: 0.0.0.0 (type: ipv4) >> ipaddr: 0.0.0.0 (type: ipv4) >> linux.bootargs: (type: string) >> linux.devname: (type: string) >> mode: dhcp (type: enum) (values: "dhcp", "static", "disabled") >> netmask: 0.0.0.0 (type: ipv4) >> serverip: (type: string) >> barebox@BPI R2PRO:/ eth1.mode=static >> barebox@BPI R2PRO:/ eth1.netmask=255.255.255.0 >> barebox@BPI R2PRO:/ eth1.ipaddr=192.168.0.18 >> barebox@BPI R2PRO:/ devinfo eth1 >> Parent: fe01.ether...@fe01.of >> Parameters: >> ethaddr: e2:3c:a9:08:b8:c8 (type: MAC) >> gateway: 0.0.0.0 (type: ipv4) >> ipaddr: 192.168.0.18 (type: ipv4) >> linux.bootargs: (type: string) >> linux.devname: (type: string) >> mode: static (type: enum) (values: "dhcp", "static", "disabled") >> netmask: 255.255.255.0 (type: ipv4) >> serverip: (type: string) >> barebox@BPI R2PRO:/ global.net.nameserver=192.168.0.10 >> barebox@BPI R2PRO:/ ifup eth1 >> barebox@BPI R2PRO:/ ping 192.168.0.10 >> T T T T T ping failed: Connection timed out >> barebox@BPI R2PRO:/ >> >> devinfo without device shows me this: >> >> `-- fe01.ether...@fe01.of >>`-- miibus0 >> `-- mdio0-phy00 >>`-- 0x-0x003f ( 64 Bytes): /dev/mdio0-phy00 >>`-- eth1 >> `-- fe2a.ether...@fe2a.of >>`-- miibus1 >>`-- eth0 >> >> any idea how to trace the problem down? >> >> regards Frank >-- >Regards, >Oleksij Thanks for first lookup. Imho delays are read here,so source supports these properties: https://git.pengutronix.de/cgit/barebox/tree/drivers/net/designware_rockchip.c#n272 And default values are different too. Have not compared source with linux,but there it works with this values. If understand you right,the rgmii should be possible with the delays. Is there any way to debug this (or try different values)? Just to get which value is wrong. The only way i'm thinking about is creating different dtbs and loading then for testing from uboot. But which values to try...i don't know which direction is broken and can try only some "random" values. I hope this is not the problem that i load barebox from uboot. regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
change r2pro dts to public hw version (was "Board code with 2 dts" )
Hi, have now the new board, but cannot get the gmac working in barebox. In linux i have it working https://github.com/frank-w/BPI-R2-4.14/blob/5.17-main/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L235 changed the dts in barebox to same values, but cannot get it working https://github.com/frank-w/barebox-r2pro/blob/r2pro/arch/arm/dts/rk3568-bpi-r2-pro.dts#L123 i see both interfaces, but it looks like the phy (rtl8211F) is not working in barebox barebox@BPI R2PRO:/ dhcp eth1 eth1: 1000Mbps full duplex link detected eth1: 1000Mbps full duplex link detected WARNING: eth1: No MAC address set. Using random address e2:3c:a9:08:b8:c8 T T T T T T T T T T T eth1: link down T dhcp: Network is down barebox@BPI R2PRO:/ eth1: 1000Mbps full duplex link detected barebox@BPI R2PRO:/ barebox@BPI R2PRO:/ barebox@BPI R2PRO:/ barebox@BPI R2PRO:/ devinfo eth1 Parent: fe01.ether...@fe01.of Parameters: ethaddr: e2:3c:a9:08:b8:c8 (type: MAC) gateway: 0.0.0.0 (type: ipv4) ipaddr: 0.0.0.0 (type: ipv4) linux.bootargs: (type: string) linux.devname: (type: string) mode: dhcp (type: enum) (values: "dhcp", "static", "disabled") netmask: 0.0.0.0 (type: ipv4) serverip: (type: string) barebox@BPI R2PRO:/ eth1.mode=static barebox@BPI R2PRO:/ eth1.netmask=255.255.255.0 barebox@BPI R2PRO:/ eth1.ipaddr=192.168.0.18 barebox@BPI R2PRO:/ devinfo eth1 Parent: fe01.ether...@fe01.of Parameters: ethaddr: e2:3c:a9:08:b8:c8 (type: MAC) gateway: 0.0.0.0 (type: ipv4) ipaddr: 192.168.0.18 (type: ipv4) linux.bootargs: (type: string) linux.devname: (type: string) mode: static (type: enum) (values: "dhcp", "static", "disabled") netmask: 255.255.255.0 (type: ipv4) serverip: (type: string) barebox@BPI R2PRO:/ global.net.nameserver=192.168.0.10 barebox@BPI R2PRO:/ ifup eth1 barebox@BPI R2PRO:/ ping 192.168.0.10 T T T T T ping failed: Connection timed out barebox@BPI R2PRO:/ devinfo without device shows me this: `-- fe01.ether...@fe01.of `-- miibus0 `-- mdio0-phy00 `-- 0x-0x003f ( 64 Bytes): /dev/mdio0-phy00 `-- eth1 `-- fe2a.ether...@fe2a.of `-- miibus1 `-- eth0 any idea how to trace the problem down? regards Frank > Gesendet: Mittwoch, 23. März 2022 um 10:03 Uhr > Von: "Ahmad Fatoum" > An: "Frank Wunderlich" > Cc: barebox@lists.infradead.org > Betreff: Re: Aw: Re: Board code with 2 dts > > Hi Frank, > > On 23.03.22 08:47, Frank Wunderlich wrote: > > Hi > > > > thanks for your fast and detailed answer. > > afaik vendor have not changed the saradc-detection (because v00 was not > > public), so v00 has same value as v1.0 and i cannot detect difference > > there. Maybe there is another way to detect (maybe based on gmac or any > > hardware-change), but for now i used last option you've mentioned (second > > entry function). > > If it's just pre-production HW, it's not worth it to dynamically detect, I > agree. > > > Have it implemented like kontron-samx6i (both dts currently same), it > > compiles, can you take a quick look if i did it right? > > > > https://github.com/frank-w/barebox-r2pro/commit/deaf7a8eed7575e35c17807aa0a432363122b033 > > Looks ok to me. Nitpick: Using __dtb_z_ instead of __dtb_ and selecting > ARM_USE_COMPRESSED_DTB > will decrease barebox size a bit. > > > this is not intended to be upstreamed, but for me to fix upstream with v1 > > config (when i get the board) and still using v00 board. > > If v00 is not publicly available, it would be nice if you could replace the > existing > v00 support with v01 once you can test it. > > Cheers, > Ahmad > > > > > regards Frank > > > > > >> Gesendet: Dienstag, 22. März 2022 um 18:34 Uhr > >> Von: "Ahmad Fatoum" > >> An: fran...@public-files.de, barebox@lists.infradead.org > >> Betreff: Re: Board code with 2 dts > >> > >> Hello Frank, > >> > >> On 22.03.22 18:23, Frank Wunderlich wrote: > >>> Hi, > >>> > >>> I get information that new hardware revision of bpi-r2 pro has some > >>> differences to the version i upstreamed. Is it possible to add a new dts > >>> and use same board code? > >>> > >>> How can i choose between the 2 dts on build (kconfig option)? > >> > >> In any case, don't add a new Kconfig option. The existing one suffices. > >> > >>> Afaik the name of dtb is hardcoded in lowlevel.c [1] > >>> > >>> Differences are iodomains (not defined in barebox,but linux) and > >>> gmac-config (gmacs swapped and different settings). > >>> > >>> Currently i have not yet t
Aw: Re: Board code with 2 dts
Hi thanks for your fast and detailed answer. afaik vendor have not changed the saradc-detection (because v00 was not public), so v00 has same value as v1.0 and i cannot detect difference there. Maybe there is another way to detect (maybe based on gmac or any hardware-change), but for now i used last option you've mentioned (second entry function). Have it implemented like kontron-samx6i (both dts currently same), it compiles, can you take a quick look if i did it right? https://github.com/frank-w/barebox-r2pro/commit/deaf7a8eed7575e35c17807aa0a432363122b033 this is not intended to be upstreamed, but for me to fix upstream with v1 config (when i get the board) and still using v00 board. regards Frank > Gesendet: Dienstag, 22. März 2022 um 18:34 Uhr > Von: "Ahmad Fatoum" > An: fran...@public-files.de, barebox@lists.infradead.org > Betreff: Re: Board code with 2 dts > > Hello Frank, > > On 22.03.22 18:23, Frank Wunderlich wrote: > > Hi, > > > > I get information that new hardware revision of bpi-r2 pro has some > > differences to the version i upstreamed. Is it possible to add a new dts > > and use same board code? > > > > How can i choose between the 2 dts on build (kconfig option)? > > In any case, don't add a new Kconfig option. The existing one suffices. > > > Afaik the name of dtb is hardcoded in lowlevel.c [1] > > > > Differences are iodomains (not defined in barebox,but linux) and > > gmac-config (gmacs swapped and different settings). > > > > Currently i have not yet the new board for testing,but then i want to send > > patches for linux and barebox. > > > > [1] > > https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24 > > Is it possible to detect which board is being used? > If so, best practice is to have barebox the same image for both > and detect board type at runtime. > Here's an example doing it in lowlevel.c: > arch/arm/boards/stm32mp15xx-dkx/lowlevel.c > > If you need more barebox infrastructure than what's available in the > bootloader > to detect board type, you could e.g. rewrite gmac-config in barebox board code > after detection. > > If there is no way to dynamically detect which board variant barebox is > running > on, just duplicate the entry point in the same file and change just the device > tree. Then extend images/Makefile.rockchip to reference the new entry point > and barebox build will generate an image for each board. See for example: > > arch/arm/boards/kontron-samx6i/lowlevel.c > > > Cheers, > Ahmad ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Board code with 2 dts
Hi, I get information that new hardware revision of bpi-r2 pro has some differences to the version i upstreamed. Is it possible to add a new dts and use same board code? How can i choose between the 2 dts on build (kconfig option)? Afaik the name of dtb is hardcoded in lowlevel.c [1] Differences are iodomains (not defined in barebox,but linux) and gmac-config (gmacs swapped and different settings). Currently i have not yet the new board for testing,but then i want to send patches for linux and barebox. [1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24 regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Aw: [PATCH v7 22/24] drm: rockchip: Add VOP2 driver
Tested this Series on my rk3568 Bananapi R2 Pro v00 Tested-by: Frank Wunderlich regards Frank
Aw: [PATCH v6 17/23] arm64: dts: rockchip: rk356x: Add HDMI nodes
Hi > Gesendet: Donnerstag, 17. Februar 2022 um 09:29 Uhr > Von: "Sascha Hauer" > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > @@ -10,7 +10,6 @@ > #include > #include > #include > -#include why dropping this after adding in part 16? > #include it looks like you moved this to board includes...imho this should stay in the rk356x.dtsi, because compilation will fail if a board without the vop2 (and missing the include) is derived from rk356x.dtsi. regards Frank
Re: [PATCH] ARM: Rockchip: rk3568: add tsadc and spi
Am 11. Februar 2022 11:43:44 MEZ schrieb Sascha Hauer :
>Hi Frank,
>
>On Fri, Feb 11, 2022 at 10:11:14AM +0100, Frank Wunderlich wrote:
>> From: Frank Wunderlich
>>
>> Add tsadc and spi node from linux.
>>
>> Signed-off-by: Frank Wunderlich
>> ---
>> arch/arm/dts/rk3568-pinctrl.dtsi | 9
>> arch/arm/dts/rk3568.dtsi | 35
>
>> 2 files changed, 44 insertions(+)
>>
>> diff --git a/arch/arm/dts/rk3568-pinctrl.dtsi
>b/arch/arm/dts/rk3568-pinctrl.dtsi
>> index a588ca95ace2..8f90c66dd9e9 100644
>> --- a/arch/arm/dts/rk3568-pinctrl.dtsi
>> +++ b/arch/arm/dts/rk3568-pinctrl.dtsi
>> @@ -3108,4 +3108,13 @@
>> <4 RK_PA0 3 _pull_none_drv_level_2>;
>> };
>> };
>> +
>> +tsadc {
>> +/omit-if-no-ref/
>> +tsadc_pin: tsadc-pin {
>> +rockchip,pins =
>> +/* tsadc_pin */
>> +<0 RK_PA1 0 _pull_none>;
>> +};
>> +};
>> };
>> diff --git a/arch/arm/dts/rk3568.dtsi b/arch/arm/dts/rk3568.dtsi
>> index 0f19d3f0c0c3..6afd95b01c0c 100644
>> --- a/arch/arm/dts/rk3568.dtsi
>> +++ b/arch/arm/dts/rk3568.dtsi
>> @@ -772,6 +772,21 @@
>> clock-names = "tclk", "pclk";
>> };
>>
>> +spi3: spi@fe64 {
>> +compatible = "rockchip,rk3568-spi", "rockchip,rk3066-spi";
>> +reg = <0x0 0xfe64 0x0 0x1000>;
>> +interrupts = ;
>> +clocks = < CLK_SPI3>, < PCLK_SPI3>;
>> +clock-names = "spiclk", "apb_pclk";
>> +dmas = < 26>, < 27>;
>> +dma-names = "tx", "rx";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_cs0 _cs1 _pins>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +status = "disabled";
>> +};
>
>When you asked me if you should keep tsadc/spi3 in your board dts I
>didn't understand that these are missing in rk3568.dtsi.
>Adding these nodes when barebox doesn't use them has no gain for us. I
>won't take this patch and removed references to spi3/tsadc from your
>board patch while applying.
>
>Sascha
Hi,
I understood it,that when you take the mainline-linux dts it will not find spi3
and tsadc in rk3568.dtsi. Or do you plan to sync this too?
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH v3] ARM: Rockchip: Add rk3568 BananaPi R2 Pro board support
From: Frank Wunderlich
This adds support for the BananaPi R2 Pro board.
It is basicly a copy of rk3568 evb board but with slightly modified DTS.
Added GPIO-Leds to dts and modified the hw-detection a bit.
Tested features so far are:
- 1st stage booting
- Network
- SD card and Emmc
- usb (1.1 and 3 work, usb2 not working)
- power LED (green)
Signed-off-by: Frank Wunderlich
---
changes in v3:
- modify to be more similar to linux dts
changes in v2:
- dts: drop chosen label
- some changes to dts to make it similar to linux-version
- board.c: add "bpi" on different places and drop rk3568 partially
- drop change in dt-bindings
- add entry to Documentation rk356x supported boards
- add bpi-r2-pro to rockchip_v8_defconfig
---
Documentation/boards/rockchip.rst | 1 +
arch/arm/boards/Makefile | 1 +
.../rockchip-rk3568-bpi-r2pro/.gitignore | 1 +
.../boards/rockchip-rk3568-bpi-r2pro/Makefile | 2 +
.../boards/rockchip-rk3568-bpi-r2pro/board.c | 93 +++
.../rockchip-rk3568-bpi-r2pro/lowlevel.c | 49 ++
arch/arm/configs/rockchip_v8_defconfig| 1 +
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-bpi-r2-pro.dts| 593 ++
arch/arm/mach-rockchip/Kconfig| 6 +
images/Makefile.rockchip | 7 +
11 files changed, 755 insertions(+)
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro.dts
diff --git a/Documentation/boards/rockchip.rst
b/Documentation/boards/rockchip.rst
index 68c3e112650b..041bb9fa6490 100644
--- a/Documentation/boards/rockchip.rst
+++ b/Documentation/boards/rockchip.rst
@@ -57,6 +57,7 @@ Supported Boards
- Rockchip RK3568 EVB
+- Rockchip RK3568 Bananapi R2 Pro
- Pine64 Quartz64 Model A
The steps described in the following target the RK3568 and the RK3568 EVB but
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
index 6fe1b5991455..0ede7818fdde 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -186,4 +186,5 @@ obj-$(CONFIG_MACH_TQMLS1046A) +=
tqmls1046a/
obj-$(CONFIG_MACH_MNT_REFORM) += mnt-reform/
obj-$(CONFIG_MACH_SKOV_ARM9CPU)+= skov-arm9cpu/
obj-$(CONFIG_MACH_RK3568_EVB) += rockchip-rk3568-evb/
+obj-$(CONFIG_MACH_RK3568_BPI_R2PRO)+=
rockchip-rk3568-bpi-r2pro/
obj-$(CONFIG_MACH_PINE64_QUARTZ64) += pine64-quartz64/
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
new file mode 100644
index ..f458f794b54c
--- /dev/null
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
@@ -0,0 +1 @@
+sdram-init.bin
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
new file mode 100644
index ..01c7a259e9a5
--- /dev/null
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
@@ -0,0 +1,2 @@
+obj-y += board.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
new file mode 100644
index ..e472f13c8bbf
--- /dev/null
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#define pr_fmt(fmt) "rk3568-r2pro: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static bool machine_is_bpi_r2pro = false;
+
+static int rk3568_bpi_r2pro_probe(struct device_d *dev)
+{
+ enum bootsource bootsource = bootsource_get();
+ int instance = bootsource_get_instance();
+
+ barebox_set_model("BPI R2PRO");
+ barebox_set_hostname("bpi-r2pro");
+ machine_is_bpi_r2pro = true;
+
+ if (bootsource == BOOTSOURCE_MMC && instance == 1)
+ of_device_enable_path("/chosen/environment-sd");
+ else
+ of_device_enable_path("/chosen/environment-emmc");
+
+ rk3568_bbu_mmc_register("emmc", BBU_HANDLER_FLAG_DEFAULT, "/dev/emmc");
+ rk3568_bbu_mmc_register("sd", 0, "/dev/sd");
+
+ return 0;
+}
+
+static const struct of_device_id rk3568_bpi_r2pro_of_match[] = {
+ { .compatible = "rockchip,rk3568-bpi-r2pro" },
+ { /* Sentinel */},
+};
+
+static struct driver_d rk3568_bpi_r2pro_board_driver = {
+ .name = "board-rk3568-bpi-r2pro",
+ .probe = rk3568_bpi_r2pro_probe,
+ .of_compatible = rk3568_bpi_r2pro_of_match,
+};
+c
[PATCH] ARM: Rockchip: rk3568: add tsadc and spi
From: Frank Wunderlich
Add tsadc and spi node from linux.
Signed-off-by: Frank Wunderlich
---
arch/arm/dts/rk3568-pinctrl.dtsi | 9
arch/arm/dts/rk3568.dtsi | 35
2 files changed, 44 insertions(+)
diff --git a/arch/arm/dts/rk3568-pinctrl.dtsi b/arch/arm/dts/rk3568-pinctrl.dtsi
index a588ca95ace2..8f90c66dd9e9 100644
--- a/arch/arm/dts/rk3568-pinctrl.dtsi
+++ b/arch/arm/dts/rk3568-pinctrl.dtsi
@@ -3108,4 +3108,13 @@
<4 RK_PA0 3 _pull_none_drv_level_2>;
};
};
+
+ tsadc {
+ /omit-if-no-ref/
+ tsadc_pin: tsadc-pin {
+ rockchip,pins =
+ /* tsadc_pin */
+ <0 RK_PA1 0 _pull_none>;
+ };
+ };
};
diff --git a/arch/arm/dts/rk3568.dtsi b/arch/arm/dts/rk3568.dtsi
index 0f19d3f0c0c3..6afd95b01c0c 100644
--- a/arch/arm/dts/rk3568.dtsi
+++ b/arch/arm/dts/rk3568.dtsi
@@ -772,6 +772,21 @@
clock-names = "tclk", "pclk";
};
+ spi3: spi@fe64 {
+ compatible = "rockchip,rk3568-spi", "rockchip,rk3066-spi";
+ reg = <0x0 0xfe64 0x0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_SPI3>, < PCLK_SPI3>;
+ clock-names = "spiclk", "apb_pclk";
+ dmas = < 26>, < 27>;
+ dma-names = "tx", "rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <_cs0 _cs1 _pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
uart1: serial@fe65 {
compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
reg = <0x0 0xfe65 0x0 0x100>;
@@ -1030,6 +1045,26 @@
status = "disabled";
};
+ tsadc: tsadc@fe71 {
+ compatible = "rockchip,rk3568-tsadc";
+ reg = <0x0 0xfe71 0x0 0x100>;
+ interrupts = ;
+ assigned-clocks = < CLK_TSADC_TSEN>, < CLK_TSADC>;
+ assigned-clock-rates = <1700>, <70>;
+ clocks = < CLK_TSADC>, < PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ resets = < SRST_P_TSADC>, < SRST_TSADC>,
+< SRST_TSADCPHY>;
+ rockchip,grf = <>;
+ rockchip,hw-tshut-temp = <95000>;
+ pinctrl-names = "init", "default", "sleep";
+ pinctrl-0 = <_pin>;
+ pinctrl-1 = <_shutorg>;
+ pinctrl-2 = <_pin>;
+ #thermal-sensor-cells = <1>;
+ status = "disabled";
+ };
+
saradc: saradc@fe72 {
compatible = "rockchip,rk3568-saradc";
reg = <0x0 0xfe72 0x0 0x100>;
--
2.25.1
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: [PATCH v1] ARM: Rockchip: Add rk3568 BananaPi R2 Pro board support
> Gesendet: Montag, 24. Januar 2022 um 09:55 Uhr > Von: "Sascha Hauer" > I saw this device tree looks different from the one you sent for kernel > inclusion. This is not a problem now, but once the kernel dts is > upstream it will show up in dts/ in the barebox tree. We then usually > include the upstream dts from the barebox board dts, so that only the > barebox specific additions are in the barebox dts. Given that it would > be nice if you could minimize the differences now already, so that later > inclusion of the upstream dts becomes easier. Hi, after dts got merged to linux i used it to find differences and minimized them. have not added io-domain as i don't know if they change in future and they are not needed in barebox. needed to add tsadc+pinctrl and spi3 to rk3568*.dtsi as they are referenced in my linux board dts can you look if the dts is now ok for upstreaming? https://github.com/frank-w/barebox-r2pro/blob/r2pro/arch/arm/dts/rk3568-bpi-r2-pro.dts regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Aw: [PATCH v5 22/23] drm: rockchip: Add VOP2 driver
Hi Sascha tested full v5 Series + 3 clk-Patches from v4 on 5.17-rc2 on my rk3568 based Bananapi R2 Pro 1280x720-32@60Hz 1920x1080-32@60Hz 3840x2160-32@60Hz with fb console Tested-by: Frank Wunderlich regards Frank
Aw: [PATCH v5 00/23] drm/rockchip: RK356x VOP2 support
Hi Sascha tested full v5 Series + 3 clk-Patches from v4 on 5.17-rc2 on my rk3568 based Bananapi R2 Pro 1280x720-32@60Hz 1920x1080-32@60Hz 3840x2160-32@60Hz with fb console Tested-by: Frank Wunderlich regards Frank
Aw: Re: blspec - autoboot + timeout/default
Hi > Gesendet: Montag, 07. Februar 2022 um 09:59 Uhr > Von: "Sascha Hauer" > An: "Frank Wunderlich" > Cc: barebox@lists.infradead.org > Betreff: Re: blspec - autoboot + timeout/default > > On Sat, Feb 05, 2022 at 03:58:54PM +0100, Frank Wunderlich wrote: > > Hi, > > > > can i boot directly to blspec-menu (boot -m sd.1) with setting in > > default env and boot a specific entry (by title/filename) after some > > time (e.g.3-5 sec)? > > There is a -t option to the boot command. It seems however that > there is no possibility to select a specfic entry beforehand. The first > one would be booted. mhm, then i need a way to add it...is there anything similar in blspec not implemented in barebox or is this a function that needs to be added to specification too? > > i have defined some blspec files in /mnt/sd.1/loader/entries/ and i > > want to show the menu by default and after some time the entry from > > specific file should be booted. this gives user the possibility to > > modify this conf to define his kernel for autoboot in headless mode. > > > > i tried to modify defaultenv/nv/boot.default, but this needs filenames > > in /env/boot, no commands and if i use a script, it cannot start the > > "boot -m sd.1" because the /env/boot scripts run bootm (tried loading > > barebox with such script - ended with putting a separate script in > > /env/bin/) > > It should work by setting: > > nv boot.default=myboot i want to avoid user environment...it should be defined in builtin env, but afaik i can set the boot.default in this too...but currently i appended only my scripts... i can use the script next as first entry if it is handled correctly > With /env/boot/myboot: > > #!/bin/sh > > boot -m sd.1 -t 3 > > > > > btw. is there a way to load environment from a txt file from a > > specific partition (similar to uboots uEnv.txt)? > > The barebox environment is a directory tree rather than a list of > variables, so there is no way to load a text file as environment. > There is the loadenv command which takes the path to an environment > image as argument. You can generate such an image on the host > with the bareboxenv tool and then load it under barebox with loadenv. binary import is not that userfriendly :) for me no problem. so there should be a way to define a blspec config as default... regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 2/2] Documentation: user: barebox: mention generic dt 2nd stage support
Am 7. Februar 2022 09:34:40 MEZ schrieb Sascha Hauer : >On Mon, Feb 07, 2022 at 09:14:51AM +0100, Ahmad Fatoum wrote: >> Hello Sascha, >> >> On 07.02.22 09:00, Sascha Hauer wrote: >> > On Sun, Feb 06, 2022 at 12:19:30AM +0100, Ahmad Fatoum wrote: >> >> Most users interested in chainloading barebox will probably want >to use >> >> the generic DT format for that: It will pass the checks the boot >command >> >> may have and it will ensure the system is in the correct state, >e.g. >> >> that caches are disabled. >> >> >example: >> >> + >> >> +.. code-block:: console >> >> + >> >> + U-Boot: tftp $kernel_addr barebox-dt-2nd.img >> >> + U-Boot: tftp $fdt_addr my-board.dtb >> >> + U-Boot: booti $kernel_addr - $fdt_addr >> >> + >> This is what the documentation is saying right now. It only appeared >> in the diff, because I rephrased the start a bit. I don't have a >> 32-bit ARM U-Boot here to test, so I'd rather not rewrite that part >> myself. > >Well you've introduced the part to use the bootm command yourself :) > >commit 3a14fb79153af84323fee8308989011cd05c7d96 >Author: Ahmad Fatoum >Date: Mon Jun 17 16:18:46 2019 +0200 > >However, I obviously failed to review this properly. I'll create a >patch >for that. > >Sascha In barebox "bootm flashable.img" works, in uboot it is booti with barebox-dt-2nd.img +fdt like example. I have a armhf bananapi r2 (mt7623),but it looks not supported by barebox regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] Kbuild: add bareboxversion target to Makefile
From: Frank Wunderlich This allows getting version string with make bareboxversion like for linux and uboot. Signed-off-by: Frank Wunderlich --- Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 3125d628114b..4b4a92181034 100644 --- a/Makefile +++ b/Makefile @@ -247,7 +247,7 @@ version_h := include/generated/version.h clean-targets := %clean mrproper cleandocs no-dot-config-targets := $(clean-targets) \ cscope gtags TAGS tags help% %docs \ -$(version_h) kernelversion outputmakefile +$(version_h) bareboxversion outputmakefile no-sync-config-targets := $(no-dot-config-targets) install %install \ kernelrelease @@ -1277,6 +1277,9 @@ docs: FORCE @$(SPHINXBUILD) -b html -d $(objtree)/doctrees $(srctree)/Documentation \ $(objtree)/Documentation/html +bareboxversion: + @echo $(KERNELVERSION) + # Single targets # --- # Single targets are compatible with: -- 2.25.1 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: chainload barebox from uboot
Hi,
thanks for your answer.
BOARD_ARM_GENERIC_DT [=y] and BOARD_ARM_GENERIC_DT_AARCH64 [=y] were already
set,
so i just copied the
arch/arm/dts/rk3568-bpi-r2-pro.dtb
and the
images/barebox-dt-2nd.img
to my sdcard and could it boot this way (using booti instead of bootm) :)
=> fatload mmc 1:2 ${kernel_addr_r} barebox-dt-2nd.img
reading barebox-dt-2nd.img
403792 bytes read in 38 ms (10.1 MiB/s)
=> fatload mmc 1:2 ${fdt_addr_r} rk3568-bpi-r2-pro.dtb
reading rk3568-bpi-r2-pro.dtb
35602 bytes read in 8 ms (4.2 MiB/s)
=> booti ${kernel_addr_r} - ${fdt_addr_r}
so problem solved ;)
regards Frank
> Gesendet: Sonntag, 06. Februar 2022 um 00:20 Uhr
> Von: "Ahmad Fatoum"
> You'll want to use the generic DT 2nd image, which in your case would have a
> Linux
> ARM64 header and be bootable just like a Linux kernel.
> See the documentation patches I cc'd you on.
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
blspec - autoboot + timeout/default
Hi, can i boot directly to blspec-menu (boot -m sd.1) with setting in default env and boot a specific entry (by title/filename) after some time (e.g.3-5 sec)? i have defined some blspec files in /mnt/sd.1/loader/entries/ and i want to show the menu by default and after some time the entry from specific file should be booted. this gives user the possibility to modify this conf to define his kernel for autoboot in headless mode. i tried to modify defaultenv/nv/boot.default, but this needs filenames in /env/boot, no commands and if i use a script, it cannot start the "boot -m sd.1" because the /env/boot scripts run bootm (tried loading barebox with such script - ended with putting a separate script in /env/bin/) btw. is there a way to load environment from a txt file from a specific partition (similar to uboots uEnv.txt)? regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
chainload barebox from uboot
Hi,
documentation says that barebox can be loaded from uboot:
https://www.barebox.org/doc/latest/user/barebox.html#starting-barebox
i tried the ./barebox.bin and the barebox-rk3568-*.img, both are not working in
uboot.
=> fatload mmc 1:2 ${scriptaddr} barebox-rk3568-bpi-r2pro.img
reading barebox-rk3568-bpi-r2pro.img
768000 bytes read in 68 ms (10.8 MiB/s)
=> bootm ${scriptaddr}
Fdt Ramdisk skip relocation
Wrong Image Format for bootm command
ERROR: can't get kernel image!
=> fatload mmc 1:2 ${scriptaddr} barebox.bin
reading barebox.bin
860784 bytes read in 76 ms (10.8 MiB/s)
=> bootm ${scriptaddr}
Fdt Ramdisk skip relocation
Wrong Image Format for bootm command
ERROR: can't get kernel image!
documation talkes about a "arch/$ARCH/pbl/zbarebox.bin" but i have no such
file. Symbol PBL_IMAGE is already set to y
for testing i used my vendors uboot
=> version
U-Boot 2017.09 (Nov 21 2021 - 14:25:03 +0100)
isn't it possible to chainload barebox from uboot or do i miss any
config-option to get the right image?
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Re: barebox extending boot-scripts
Hi, > Gesendet: Donnerstag, 06. Januar 2022 um 09:08 Uhr > Von: "Sascha Hauer" > It works for example with: > > for i in /mnt/sd.1/extlinux/Image*; do basename $i b; echo $b; done this works with full path, but not if using a var for dir var barebox@BPI R2PRO:/ i=0;for f in /mnt/sd.1/extlinux/Image*; do basename $f b; echo "$i:$b";let i++; done 0:Image_5.16 1:Image_5.16-next.gz 2:Image_5.16.gz 3:Image_5.16.gz.bak 4:Image_5.16_q64 5:Image_bpi barebox@BPI R2PRO:/ imgdir=/mnt/sd.1/extlinux/ barebox@BPI R2PRO:/ i=0;for f in $imgdir/Image*; do basename $f b; echo "$i:$b";let i++; done basename - strip directory and suffix from filenames Usage: basename PATH VAR Remove directory part from the PATH and store result into variable VAR. 0:Image_bpi barebox@BPI R2PRO:/ any idea how to get it working with variable path? i can do a cd before and drop the basename cd $imgdir for f in Image*; do echo $f;done Image_5.16 Image_5.16-next.gz Image_5.16.gz Image_5.16.gz.bak Image_5.16_q64 Image_bpi but then i need to restore the path again (something like prevdir=$(pwd);cd $prevdir) if script fails regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Aw: [PATCH 27/27] drm: rockchip: Add VOP2 driver
Hi Sascha tested full series on Bananapi r2 Pro V0 prototype (rk3568) 4K@60Hz 1080p@60Hz both look good Tested-By: Frank Wunderlich regards Frank
Aw: [PATCH 01/27] drm/encoder: Add of_graph port to struct drm_encoder
Hi > Gesendet: Mittwoch, 26. Januar 2022 um 15:55 Uhr > Von: "Sascha Hauer" > Betreff: [PATCH 01/27] drm/encoder: Add of_graph port to struct drm_encoder Please use "git format-patch -vX ..." when creating your patches to make sure the version is set in every patch and not only the coverletter. That makes it easier to find Patch from specific version and shows version also in Patchwork where the coverletter is hidden regards Frank
Aw: Re: [PATCH v1] ARM: Rockchip: Add rk3568 BananaPi R2 Pro board support
Hi,
> Gesendet: Montag, 24. Januar 2022 um 09:55 Uhr
> Von: "Sascha Hauer"
> > +static bool machine_is_rk3568_r2pro = false;
> > +
> > +static int rk3568_r2pro_probe(struct device_d *dev)
> > +{
> > + enum bootsource bootsource = bootsource_get();
> > + int instance = bootsource_get_instance();
> > +
> > + barebox_set_model("RK3568 R2PRO");
> > + barebox_set_hostname("rk3568-r2pro");
> > + machine_is_rk3568_r2pro = true;
>
> Maybe add a bpi to the hostname, model, variable names and instead drop
> the rk3568?
i can do...
> > + if (!IS_ENABLED(CONFIG_AIODEV))
> > + return 0;
> > +
> > + if (!machine_is_rk3568_r2pro)
> > + return 0;
> > +
> > + hwid_chan = aiochannel_by_name("aiodev0.in_value1_mV");
> > + if (IS_ERR(hwid_chan)) {
> > + ret = PTR_ERR(hwid_chan);
> > + goto err_hwid;
> > + }
> > +
> > + ret = aiochannel_get_value(hwid_chan, _voltage);
> > + if (ret)
> > + goto err_hwid;
> > +
> > + pr_info("hwid_voltage: %d\n", hwid_voltage);
>
> The voltage is not really interesting. This should be a pr_debug.
ok, i change this
> > +
> > + if (hwid_voltage == 1800)
> > + hwid = "V00";
> > + else
> > + hwid = "unknown";
>
> Have you verified this board really encodes the hardware revision using
> this adc channel?
yes, in shematics it is named SARADC_VIN1_HW_ID (which should map the
in_value1_mV), but i have only this one prototype for testing.
> > diff --git a/arch/arm/dts/rk3568-bpi-r2-pro.dts
> > b/arch/arm/dts/rk3568-bpi-r2-pro.dts
>
> I saw this device tree looks different from the one you sent for kernel
> inclusion. This is not a problem now, but once the kernel dts is
> upstream it will show up in dts/ in the barebox tree. We then usually
> include the upstream dts from the barebox board dts, so that only the
> barebox specific additions are in the barebox dts. Given that it would
> be nice if you could minimize the differences now already, so that later
> inclusion of the upstream dts becomes easier.
ok, we can wait for kernel dts to be merged, but most stuff in kernel dts will
be unused in barebox. so i started with the evb one which is enough for barebox
atm. Only added the leds.
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH v1] ARM: Rockchip: Add rk3568 BananaPi R2 Pro board support
From: Frank Wunderlich
This adds support for the BananaPi R2 Pro board.
It is basicly a copy of rk3568 evb board but with slightly modified DTS.
Added GPIO-Leds to dts and modified the hw-detection a bit.
Tested features so far are:
- 1st stage booting
- Network
- SD card (Emmc not tested but basicly same as on EVB)
- power LED (green)
Signed-off-by: Frank Wunderlich
---
arch/arm/boards/Makefile | 1 +
.../rockchip-rk3568-bpi-r2pro/.gitignore | 1 +
.../boards/rockchip-rk3568-bpi-r2pro/Makefile | 2 +
.../boards/rockchip-rk3568-bpi-r2pro/board.c | 93 +++
.../rockchip-rk3568-bpi-r2pro/lowlevel.c | 49 ++
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-bpi-r2-pro.dts| 593 ++
arch/arm/mach-rockchip/Kconfig| 6 +
dts/Bindings/arm/rockchip.yaml| 5 +
images/Makefile.rockchip | 7 +
10 files changed, 758 insertions(+)
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
create mode 100644 arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c
create mode 100644 arch/arm/dts/rk3568-bpi-r2-pro.dts
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
index 6fe1b5991455..c26f84dcd8de 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -186,4 +186,5 @@ obj-$(CONFIG_MACH_TQMLS1046A) +=
tqmls1046a/
obj-$(CONFIG_MACH_MNT_REFORM) += mnt-reform/
obj-$(CONFIG_MACH_SKOV_ARM9CPU)+= skov-arm9cpu/
obj-$(CONFIG_MACH_RK3568_EVB) += rockchip-rk3568-evb/
+obj-$(CONFIG_MACH_RK3568_R2PRO)+=
rockchip-rk3568-bpi-r2pro/
obj-$(CONFIG_MACH_PINE64_QUARTZ64) += pine64-quartz64/
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
new file mode 100644
index ..f458f794b54c
--- /dev/null
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/.gitignore
@@ -0,0 +1 @@
+sdram-init.bin
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
new file mode 100644
index ..01c7a259e9a5
--- /dev/null
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/Makefile
@@ -0,0 +1,2 @@
+obj-y += board.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
new file mode 100644
index ..37634a7e33ed
--- /dev/null
+++ b/arch/arm/boards/rockchip-rk3568-bpi-r2pro/board.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#define pr_fmt(fmt) "rk3568-r2pro: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static bool machine_is_rk3568_r2pro = false;
+
+static int rk3568_r2pro_probe(struct device_d *dev)
+{
+ enum bootsource bootsource = bootsource_get();
+ int instance = bootsource_get_instance();
+
+ barebox_set_model("RK3568 R2PRO");
+ barebox_set_hostname("rk3568-r2pro");
+ machine_is_rk3568_r2pro = true;
+
+ if (bootsource == BOOTSOURCE_MMC && instance == 1)
+ of_device_enable_path("/chosen/environment-sd");
+ else
+ of_device_enable_path("/chosen/environment-emmc");
+
+ rk3568_bbu_mmc_register("emmc", BBU_HANDLER_FLAG_DEFAULT, "/dev/emmc");
+ rk3568_bbu_mmc_register("sd", 0, "/dev/sd");
+
+ return 0;
+}
+
+static const struct of_device_id rk3568_r2pro_of_match[] = {
+ { .compatible = "rockchip,rk3568-bpi-r2pro" },
+ { /* Sentinel */},
+};
+
+static struct driver_d rk3568_r2pro_board_driver = {
+ .name = "board-rk3568-r2pro",
+ .probe = rk3568_r2pro_probe,
+ .of_compatible = rk3568_r2pro_of_match,
+};
+coredevice_platform_driver(rk3568_r2pro_board_driver);
+
+BAREBOX_DEEP_PROBE_ENABLE(rk3568_r2pro_of_match);
+
+static int rk3568_r2pro_detect_hwid(void)
+{
+ int ret;
+ int hwid_voltage;
+ struct aiochannel *hwid_chan;
+ char *hwid;
+
+ if (!IS_ENABLED(CONFIG_AIODEV))
+ return 0;
+
+ if (!machine_is_rk3568_r2pro)
+ return 0;
+
+ hwid_chan = aiochannel_by_name("aiodev0.in_value1_mV");
+ if (IS_ERR(hwid_chan)) {
+ ret = PTR_ERR(hwid_chan);
+ goto err_hwid;
+ }
+
+ ret = aiochannel_get_value(hwid_chan, _voltage);
+ if (ret)
+ goto err_hwid;
+
+ pr_info("hwid_voltage: %d\n", hwid_voltage);
+
+ if (hwid_voltage == 1800)
+ hwid = "V00";
+ else
+ hwid
use string as variable name
Hi,
is it possible to use a string as variable-name?
example:
i=1
img_$i=foo
now i have defined $img_1, but how to display it using $i again?
echo ${img_$i}
echo ${img_${i}}
alternative may be a variable-array, but it seems not possible
img[$i]=bar
img[1]=bar: No such file or directory
i just want to create a dynamic list and access the items of this list by index
another way may be appending new string with separator to existing string and
split afterwards,
but then i have the index-problem again.
i know barebox shell is limited (but much more mighty than expected for just a
bootloader),
but maybe it is possible :)
any idea?
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Re: Re: Re: barebox extending boot-scripts
Hi, i have now created a new barebox board as copy from evb. i can load it from tftp with bootm /mnt/tftp/barebox-rk3568-r2pro.img i can create a bootmenu with entries of loader/entries and boot it: boot -m sd.1 my bootscripts are also there, but they are not listed in $global.boot.default $ grep defaultenv arch/arm/boards/bananapi-r2-pro/Makefile bbenv-y += defaultenv-rk3568 $ grep defaultenv arch/arm/boards/bananapi-r2-pro/board.c defaultenv_append_directory(defaultenv_rk3568); $ cat arch/arm/boards/bananapi-r2-pro/defaultenv-rk3568/nv/boot.default net list-images mmc-linux tftp-linux so it looks like the env is load, but the nv is not updated regards Frank > Gesendet: Montag, 10. Januar 2022 um 10:42 Uhr > Von: "Sascha Hauer" > An: "Frank Wunderlich" > Cc: "Ahmad Fatoum" , barebox@lists.infradead.org > Betreff: Re: Re: Re: Re: barebox extending boot-scripts > > On Fri, Jan 07, 2022 at 05:42:22PM +0100, Frank Wunderlich wrote: > > Hi > > > > missed the defaultenv_append_directory(defaultenv_rk3568); in > > board-file...after adding that it seems to work > > > > > Gesendet: Freitag, 07. Januar 2022 um 14:07 Uhr > > > Von: "Sascha Hauer" > > > > > > Yes. Furthermore you have to add to the board code: > > > > > > defaultenv_append_directory(defaultenv_rk3568); > > > > maybe this is the part i've missed. i thought it were 2 ways...either link > > via makefile or add to boards code > > > > > > > > > Boot scripts for publicly available evaluation kits are often not > > > > > > > good candidates > > > > > > > for upstreaming, because everybody using the EVKs has different > > > > > > > thoughts on how to > > > > > > > boot. The best way would be to use bootloader spec. It's one or > > > > > > > more files you > > > > > > > place at a known location that describe where your kernel and > > > > > > > device tree are and > > > > > > > what command line arguments to use and barebox can then > > > > > > > automatically generate > > > > > > > boot entries from all available bootloader spec files. > > > > > > > > is extlinux (i used in uboot and conf-file is already present) > > > > supported here? > > > > > > > > > > > See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf > > > > > > > for an example > > > > > > > of how to set this up. This is what I'd recommend instead of > > > > > > > writing your own > > > > > > > scripts. > > > > > > > > i do not fully understand the bootloader spec in the pdf as config file > > > > seems to be > > > > > > > > /mnt/mmc0.4/loader/entries/stm32mp157c-dk2.conf > > > > > > > > and then > > > > boot -d mmc0.4 > > > > > > > > is run...so the path (loader/entries) seems to be fixed and all files > > > > there will be processed (which order)? > > > > > > Yes. No particular order, I guess it would be the order it is on the > > > filesystem. > > > > > > > how is root appended (/dev/mmcblkXpY|uuid|...) when linux-appendroot is > > > > set to true? > > > > > > When root is appended it is assumed to be the same fs that also has the > > > bootloader spec file, so the rootfs also has the entry and the kernel. > > > > ok, then this is not usable for me, as i have a boot-partition > > (bootloader+kernel+dtb) and separate rootfs-partition > > > > > > this is for testing multiple kernels with changing filenames (very > > > > dynamic process, e.g. using 1 kernel binary with multiple dtb) and to > > > > avoid adding a bootmenu entry everytimethis is not for end-user :) > > > > > > In that case you could also use bootm directly. > > > > yes but my approach is to list the available kernels before and ask to > > enter the filename to not everytime look for correct commands ;) > > > > > > and here scripting is imho the best way...this allows me to add extra > > > > params to cmdline too (like debug level,dumping offsets) without > > > > changing a distroboot config > > > > > > Not sure if you know already, but barebox concatenates all variables in > > > the "global.linux.bootargs." namespace to the kernel command line, so
Aw: Re: Re: Re: barebox extending boot-scripts
Hi missed the defaultenv_append_directory(defaultenv_rk3568); in board-file...after adding that it seems to work > Gesendet: Freitag, 07. Januar 2022 um 14:07 Uhr > Von: "Sascha Hauer" > > Yes. Furthermore you have to add to the board code: > > defaultenv_append_directory(defaultenv_rk3568); maybe this is the part i've missed. i thought it were 2 ways...either link via makefile or add to boards code > > > > > Boot scripts for publicly available evaluation kits are often not > > > > > good candidates > > > > > for upstreaming, because everybody using the EVKs has different > > > > > thoughts on how to > > > > > boot. The best way would be to use bootloader spec. It's one or more > > > > > files you > > > > > place at a known location that describe where your kernel and device > > > > > tree are and > > > > > what command line arguments to use and barebox can then automatically > > > > > generate > > > > > boot entries from all available bootloader spec files. > > > > is extlinux (i used in uboot and conf-file is already present) supported > > here? > > > > > > > See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf for > > > > > an example > > > > > of how to set this up. This is what I'd recommend instead of writing > > > > > your own > > > > > scripts. > > > > i do not fully understand the bootloader spec in the pdf as config file > > seems to be > > > > /mnt/mmc0.4/loader/entries/stm32mp157c-dk2.conf > > > > and then > > boot -d mmc0.4 > > > > is run...so the path (loader/entries) seems to be fixed and all files there > > will be processed (which order)? > > Yes. No particular order, I guess it would be the order it is on the > filesystem. > > > how is root appended (/dev/mmcblkXpY|uuid|...) when linux-appendroot is set > > to true? > > When root is appended it is assumed to be the same fs that also has the > bootloader spec file, so the rootfs also has the entry and the kernel. ok, then this is not usable for me, as i have a boot-partition (bootloader+kernel+dtb) and separate rootfs-partition > > this is for testing multiple kernels with changing filenames (very > > dynamic process, e.g. using 1 kernel binary with multiple dtb) and to > > avoid adding a bootmenu entry everytimethis is not for end-user :) > > In that case you could also use bootm directly. yes but my approach is to list the available kernels before and ask to enter the filename to not everytime look for correct commands ;) > > and here scripting is imho the best way...this allows me to add extra > > params to cmdline too (like debug level,dumping offsets) without > > changing a distroboot config > > Not sure if you know already, but barebox concatenates all variables in > the "global.linux.bootargs." namespace to the kernel command line, so > you can easily add or remove a variable to add/remove kernel options > without affecting unrelated options. i know some options from documentation like this i've used to get a earlycon for tftp global linux.bootargs.debug="earlycon=uart8250,mmio32,0xfe66 earlyprintk" > > for fixed kernels i have defined an extlinux.conf for uboot, but i'm > > unsure if barebox can use this file too. have not found anything about > > extlinux/syslinux in barebox yet. > > No, not yet. ok, i created a bootloader-config like described in the pdf: cat /mnt/sd.1/loader/entries/linux-gz.conf title Linux GZip version 5.16 options earlycon=uart8250,mmio32,0xfe66 console=ttyS2,150n8 linux /extlinux/Image_5.16.gz devicetree /extlinux/dtb_5.16 initrd /rootfs.cpio.lz4 but on starting it is skipped due to devicetree mismatch boot -d sd.1 blspec: ignoring entry with incompatible devicetree "rockchip,rk3568-bpi-r2pro" blspec: ignoring entry with incompatible devicetree "rockchip,rk3568-bpi-r2pro" Nothing bootable found on 'sd.1' Nothing bootable found in barebox i use the evb whereas in linux i already have a separate dts. Can i override the compatible for the bootloader or do i need to add my board (as copy of evb first)? btw. don't you get my direct messages (regarding vop2 driver for rk3568 and the result of my barebox environment-tests)? regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Re: barebox extending boot-scripts
Hi,
thanks for answer. tried to strip mail it a bit down ;)
> Gesendet: Donnerstag, 06. Januar 2022 um 09:08 Uhr
> Von: "Sascha Hauer"
> On Wed, Jan 05, 2022 at 07:13:22PM +0100, Frank Wunderlich wrote:
> > > > DEFAULT_ENVIRONMENT_PATH
> > > > [=arch/arm/boards/rockchip-rk3568-evb/defaultenv]
> > > The config option is meant for use with external build systems, e.g.
> > > buildroot
> > > or PTXdist. For boards in-tree, you can add bbenv-y in the Makefile and
> > > call
> > >
> > > // assuming directory is called defaultenv-myboard
> > > defaultenv_append_directory(defaultenv_myboard);
> > >
> > > in the board code, see e.g. arch/arm/boards/embest-marsboard for an
> > > example.
if i understand it right i need to create a dir
arch/arm/boards/rockchip-rk3568-evb/defaultenv-rk3568
with dirs nv (variables) and boot (bootscripts)
and add
bbenv-y += defaultenv-rk3568
in
arch/arm/boards/rockchip-rk3568-evb/Makefile
> > > Boot scripts for publicly available evaluation kits are often not good
> > > candidates
> > > for upstreaming, because everybody using the EVKs has different thoughts
> > > on how to
> > > boot. The best way would be to use bootloader spec. It's one or more
> > > files you
> > > place at a known location that describe where your kernel and device tree
> > > are and
> > > what command line arguments to use and barebox can then automatically
> > > generate
> > > boot entries from all available bootloader spec files.
is extlinux (i used in uboot and conf-file is already present) supported here?
> > > See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf for an
> > > example
> > > of how to set this up. This is what I'd recommend instead of writing your
> > > own
> > > scripts.
i do not fully understand the bootloader spec in the pdf as config file seems
to be
/mnt/mmc0.4/loader/entries/stm32mp157c-dk2.conf
and then
boot -d mmc0.4
is run...so the path (loader/entries) seems to be fixed and all files there
will be processed (which order)?
how is root appended (/dev/mmcblkXpY|uuid|...) when linux-appendroot is set to
true?
sorry for asking dumb questions but i want to understand how to do it right and
not only doing anything ;)
> > > > ./defaultenv/defaultenv-2-menu/menu/10-boot-all/net
> > > >
> > > > seems to be a menu entry, but have not yet figured out how i can define
> > > > one to add my scripts too
> > > >
> > > > have not found anything for it in the documentation yet
> > >
> > > The default boot menu is populated with the boot entries extracted from
> > > the contents of $global.boot.default.
> >
> > currently only net is listed there
> >
> > barebox@Rockchip RK3568 EVB:/ echo $global.boot.default
> > net
> >
> > but in /env/boot i have my 2 new scripts
> >
> > barebox@Rockchip RK3568 EVB:/ ls /env/boot
> > bnet mmc-linux net tftp-linux
> >
> > > boot -m will display that menu. It will also include all bootloader spec
> > > files.
> > > If that suffices, you won't need to create your own menu. If you want
> > > though,
> > > check the help text of the menutree command.
> >
> > needed to add this option, and now it prints only "net" and "back",not my
> > own scripts ;(
> >
> > do i need my scripts to ./defaultenv/defaultenv-2-menu/menu/10-boot-all/
> > too?
do i need to propagate my own scripts somewhere to be listed in the bootmenu?
in cmdline i had tried this:
global.boot.default="net mmc-linux tftp-linux"
boot -m
which works, but how can i set this variable at compile-time?
is the right way creating a file
defaultenv/defaultenv-2-base/nv/boot.default (or
arch/arm/boards/rockchip-rk3568-evb/defaultenv-rk3568/nv/boot.default)
with the content i want? so it looks like in the pdf above ("global.variable s,
these are initialized from the
correspoding non-volatile nv.variable s")
> > > To boot into the boot menu, set nv autoboot=menu. "Detect bootsources"
> > > will
> > > list boot sources known to the barebox boot command.
> >
> > is this stored anywhere so that is persistent on next reboot?
>
> Variables beginning with 'nv.' are stored in the environment
> automatically.
>
> >
> > btw. how does saveenv exactly work (which part/filename/offset is
> > used)? sasha told me that device will be enumerated to the current
> > boot device, but where on this device is the env stored?
>
Aw: Re: barebox extending boot-scripts
Hi, > Gesendet: Mittwoch, 05. Januar 2022 um 17:07 Uhr > Von: "Ahmad Fatoum" > An: "Frank Wunderlich" , barebox@lists.infradead.org > Betreff: Re: barebox extending boot-scripts > > Hi, > > On 05.01.22 16:20, Frank Wunderlich wrote: > > Hi, > > > > i'm making my first steps and try to add more boot-scripts (to land in > > /env/boot) > > > > i added a scipt in > > > > arch/arm/boards/rockchip-rk3568-evb/defaultenv/mmc-linux > > This should be defaultenv/boot/mmc-linux instead. > > > and set > > > > DEFAULT_ENVIRONMENT_PATH [=arch/arm/boards/rockchip-rk3568-evb/defaultenv] > > > > but if i boot the board /env/boot only contains the 2 default scripts > > > > barebox@Rockchip RK3568 EVB:/ ls /env/boot/ > > bnetnet > > Try ls -R /env, you should see mmc-linux at top-level with your > current setup. > > > so maybe the dir/config-option i used is for defining variables only right? > > Top level is only meant for directories. There are directories for the > different > stuff, e.g. variables go into /env/nv/ > > > should this point to an directory or a file? > > The config option is meant for use with external build systems, e.g. buildroot > or PTXdist. For boards in-tree, you can add bbenv-y in the Makefile and call > > // assuming directory is called defaultenv-myboard > defaultenv_append_directory(defaultenv_myboard); > > in the board code, see e.g. arch/arm/boards/embest-marsboard for an example. > > The reason for avoiding the config option for in-tree boards is that a single > barebox > configuration can build multiple boards in one go: > extreme case: imx_v7_defconfig, which builds marsboard also builds more than > 100 other images. > > The config option is global, but by explicitly calling > defaultenv_append_directory, > you can have board-specific environments. will try this approach, thanks > > i see this file which looks like the source of it > > > > ./defaultenv/defaultenv-2-base/boot/net > > > > I've put them there and they appear, but this is not board specific > > Ye, you can use this for debugging, but stuff upstreamed there must be > generally > applicable. > > > so if i later want to upstream one this is maybe not the right place. > > Boot scripts for publicly available evaluation kits are often not good > candidates > for upstreaming, because everybody using the EVKs has different thoughts on > how to > boot. The best way would be to use bootloader spec. It's one or more files you > place at a known location that describe where your kernel and device tree are > and > what command line arguments to use and barebox can then automatically generate > boot entries from all available bootloader spec files. > > See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf for an example > of how to set this up. This is what I'd recommend instead of writing your own > scripts. > > > ./defaultenv/defaultenv-2-menu/menu/10-boot-all/net > > > > seems to be a menu entry, but have not yet figured out how i can define one > > to add my scripts too > > > > have not found anything for it in the documentation yet > > The default boot menu is populated with the boot entries extracted from > the contents of $global.boot.default. currently only net is listed there barebox@Rockchip RK3568 EVB:/ echo $global.boot.default net but in /env/boot i have my 2 new scripts barebox@Rockchip RK3568 EVB:/ ls /env/boot bnet mmc-linux net tftp-linux > boot -m will display that menu. It will also include all bootloader spec > files. > If that suffices, you won't need to create your own menu. If you want though, > check the help text of the menutree command. needed to add this option, and now it prints only "net" and "back",not my own scripts ;( do i need my scripts to ./defaultenv/defaultenv-2-menu/menu/10-boot-all/ too? > To boot into the boot menu, set nv autoboot=menu. "Detect bootsources" will > list boot sources known to the barebox boot command. is this stored anywhere so that is persistent on next reboot? btw. how does saveenv exactly work (which part/filename/offset is used)? sasha told me that device will be enumerated to the current boot device, but where on this device is the env stored? > See magicvar for a listing of all magic variables, or refer to the > documentation. > > > btw. is there a way to use ls with wildcard without printing the path? > > > > ls /mnt/sd.1/extlinux/ > > Image_5.16Image_5.16-next.gzImage_5.16.gz > > > > ls /mnt/sd.1/extlinux/Image* > > /mnt/
Aw: Re: barebox - rk3568
> Gesendet: Mittwoch, 05. Januar 2022 um 13:08 Uhr
> Von: "Ahmad Fatoum"
> An: "Frank Wunderlich" , barebox@lists.infradead.org
> Betreff: Re: barebox - rk3568
> > https://www.barebox.org/doc/latest/boards/rockchip.html#rockchip-rk3568
> >
> > says it starts from sector 32, my first block for uboot
> > (idblock.bin=spl+raminit) starts at 64, full uboot in partition at 8M.
>
> You probably figured it out by now, but the discrepancy is likely due to
> differing
> block sizes. barebox documentation has `dd bs=1024`, while the default is 512.
> boot firmware is a single chunk with barebox, so no separate second stage
> bootloader
> partition.
thanks, this indeed explain the different offset, which is same after resolving
the double blocksize
> > As it differs a bit from evb can i add new dts like in uboot?
>
> You can check out the commit adding the EVB or the Pine64 Quartz64:
> 8d14f8e898b4 ("arm: rockchip: add support for the quartz64 board")
>
> Feel free to send patches for your board along the same lines. :)
currently evb is working well, so i try to add bootscripts and maybe an menu
(if i found out how) :)
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
barebox extending boot-scripts
Hi, i'm making my first steps and try to add more boot-scripts (to land in /env/boot) i added a scipt in arch/arm/boards/rockchip-rk3568-evb/defaultenv/mmc-linux and set DEFAULT_ENVIRONMENT_PATH [=arch/arm/boards/rockchip-rk3568-evb/defaultenv] but if i boot the board /env/boot only contains the 2 default scripts barebox@Rockchip RK3568 EVB:/ ls /env/boot/ bnetnet so maybe the dir/config-option i used is for defining variables only right? should this point to an directory or a file? i see this file which looks like the source of it ./defaultenv/defaultenv-2-base/boot/net I've put them there and they appear, but this is not board specific, so if i later want to upstream one this is maybe not the right place. ./defaultenv/defaultenv-2-menu/menu/10-boot-all/net seems to be a menu entry, but have not yet figured out how i can define one to add my scripts too have not found anything for it in the documentation yet btw. is there a way to use ls with wildcard without printing the path? ls /mnt/sd.1/extlinux/ Image_5.16Image_5.16-next.gzImage_5.16.gz ls /mnt/sd.1/extlinux/Image* /mnt/sd.1/extlinux/Image_5.16 /mnt/sd.1/extlinux/Image_5.16-next.gz /mnt/sd.1/extlinux/Image_5.16.gz i want to list only files matching Image*, but without pathnumber of columns does not matter regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
