[PATCH v4] board: rockchip: Add Bananapi R2Pro Board

[Frank Wunderlich]

Am 18. September 2023 20:59:55 MESZ schrieb Mark Kettenis <mark.kettenis at xs4all.nl>:
>> Date: Mon, 18 Sep 2023 20:09:54 +0200
>> From: Frank Wunderlich <frank-w at public-files.de>
>> 
>> Am 18. September 2023 19:52:31 MESZ schrieb Mark Kettenis <mark.kettenis at xs4all.nl>:
>> >> From: Frank Wunderlich <linux at 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 at fe2a0000/mdio/switch at 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 at 0 {
>> >> +		compatible = "mediatek,mt7531";
>> >> +		reg = <0>;
>> >> +
>> >> +		ports {
>> >> +			#address-cells = <1>;
>> >> +			#size-cells = <0>;
>> >> +
>> >> +			port at 1 {
>> >> +				reg = <1>;
>> >> +				label = "lan0";
>> >> +			};
>> >> +
>> >> +			port at 2 {
>> >> +				reg = <2>;
>> >> +				label = "lan1";
>> >> +			};
>> >> +
>> >> +			port at 3 {
>> >> +				reg = <3>;
>> >> +				label = "lan2";
>> >> +			};
>> >> +
>> >> +			port at 4 {
>> >> +				reg = <4>;
>> >> +				label = "lan3";
>> >> +			};
>> >> +
>> >> +			port at 5 {
>> >> +				reg = <5>;
>> >> +				label = "cpu";
>> >> +				ethernet = <&gmac0>;
>> >> +				phy-mode = "rgmii";
>> >> +
>> >> +				fixed-link {
>> >> +					speed = <1000>;
>> >> +					full-duplex;
>> >> +					pause;
>> >> +				};
>> >> +			};
>> >> +		};
>> >> +	};
>> >> +};
>> 
>> 
>> regards Frank
>> 


regards Frank