
Am 18. September 2023 20:59:55 MESZ schrieb Mark Kettenis mark.kettenis@xs4all.nl:
Date: Mon, 18 Sep 2023 20:09:54 +0200 From: Frank Wunderlich frank-w@public-files.de
Am 18. September 2023 19:52:31 MESZ schrieb Mark Kettenis mark.kettenis@xs4all.nl:
From: Frank Wunderlich linux@fw-web.de 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 = &uart2;
- };
+};
+&uart2 {
- clock-frequency = <24000000>;
- bootph-pre-ram;
- status = "okay";
+};
+&gmac0 {
- status = "disabled";
+};
+/delete-node/ &{/ethernet@fe2a0000/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.
+&mdio0 {
- #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 = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
- };
+};
regards Frank
regards Frank