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

[Mark Kettenis]

> 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 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.

> >> +&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
>