Am 2022-10-28 11:19, schrieb AngeloGioacchino Del Regno:
Il 26/10/22 11:36, Frank Wunderlich ha scritto:
From: Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx>
Add support for Bananapi R3 SBC.
- SD/eMMC support (switching first 4 bits of data-bus with sw6/D)
- all rj45 ports and both SFP working (eth1/lan4)
- all USB-Ports + SIM-Slot tested
- i2c and all uarts tested
- wifi tested
Signed-off-by: Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx>
---
SPI-NAND/NOR switched (CS by sw5/C) not yet included
this is done with DT-Overlays in my tree, but i have no idea yet,
how to upstream
break some lines in wifi-eeprom-data because of checkpatch warnings.
originally there were 8 x int32 per line
changes:
v2:
- remove pcie to be added later (discussion about clocks)
- some fixes based on suggestions on ML
- add key suffix like it's done in mt7622-bpi-r64 devicetree
- add dash in sfp node names
- use reg as unit for switch-node
- drop "-3-4" suffix from i2c-pins node name
- fix order in Makefile
---
arch/arm64/boot/dts/mediatek/Makefile | 2 +
.../mediatek/mt7986a-bananapi-bpi-r3-emmc.dts | 34 +
.../mediatek/mt7986a-bananapi-bpi-r3-sd.dts | 29 +
.../dts/mediatek/mt7986a-bananapi-bpi-r3.dtsi | 593
++++++++++++++++++
4 files changed, 658 insertions(+)
create mode 100644
arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-emmc.dts
create mode 100644
arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-sd.dts
create mode 100644
arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index 0ec90cb3ef28..e8902f2cc58f 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -7,6 +7,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-rfb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986b-rfb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8167-pumpkin.dtb
diff --git
a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-emmc.dts
b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-emmc.dts
new file mode 100644
index 000000000000..859b4180ca11
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-emmc.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2021 MediaTek Inc.
+ * Author: Sam.Shih <sam.shih@xxxxxxxxxxxx>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+
+#include "mt7986a-bananapi-bpi-r3.dtsi"
+
+/ {
+ model = "Bananapi BPI-R3 (emmc)";
+};
+
+&mmc0 {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&mmc0_pins_default>;
+ pinctrl-1 = <&mmc0_pins_uhs>;
pinctrl properties and power supply properties can go to the shared
mt7986a-bananapi-bpi-r3.dtsi file.
OK
Also, I have a question here... so your hardware can take either eMMC
or MicroSD... and... is there really no way to build in both
devicetrees
and having the bootloader to select the right one based on hardware
version
or on machine compatible?
as i wrote in description the board has both, an emmc-chip and
microsd-slot, but they cannot be used simultanously as mt7986 has only 1
mmc-controller. BPI-R3 has a switch that changes the first 4 data-lines
either to emmc or microsd-slot. You have only 1 mmc-node that has to be
configured to which mmc-device you have connected, so i have to use 2
different devicetrees here.
I can see, on the wiki, that both bootloader and ATF can be customized
(so,
can be compiled and flashed just fine), so I would say that even if the
"original" U-Boot doesn't distinguish devicetrees, you can definitely
easily
implement that.
i already boot a fit-image with 2 dts (and 2 overlays for spi-nand/nor)
and my uboot can check with "mmc partconf" if emmc is available and if
not choose the sd-dts.
If you have no idea how to recognize the boards, from a fast look at
the
board schematics, I can see that there's a bootstrap setting based on
the
state of GPIO0 and GPIO1... you can perhaps use that somehow?
Otherwise, remember that, most of the times, there are other ways to
determine
the board version, like Board ID resistors...
but how should this effect the dts files here? originally i had the
sd-card dts as base and the emmc had overridden/deleted some properties
there (so only 2 dts-files). Had talked to Matthias and he suggested
having a base dtsi and 2 dts for the 2 mmc-configs.
Also, still on the wiki, I can't see any no-eMMC version of this board:
is
the sd-only a pre-production version or..?
no sd/emmc-only version...1 board with 1 mmc-controller, but 2
"storages" connected (only 1 functional based on hw switch setting)
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ hs400-ds-delay = <0x14014>;
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ non-removable;
+ no-sd;
+ no-sdio;
+ status = "okay";
+};
+
diff --git
a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-sd.dts
b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-sd.dts
new file mode 100644
index 000000000000..57200407ab86
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3-sd.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2021 MediaTek Inc.
+ * Author: Sam.Shih <sam.shih@xxxxxxxxxxxx>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+
+#include "mt7986a-bananapi-bpi-r3.dtsi"
+
+/ {
+ model = "Bananapi BPI-R3 (sdmmc)";
+};
+
+&mmc0 {
+ //sdcard
C-style comments please
ok
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&mmc0_pins_default>;
+ pinctrl-1 = <&mmc0_pins_uhs>;
+ bus-width = <4>;
+ max-frequency = <52000000>;
+ cap-sd-highspeed;
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ status = "okay";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtsi
b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtsi
new file mode 100644
index 000000000000..fc100c3a6415
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtsi
@@ -0,0 +1,593 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2021 MediaTek Inc.
+ * Authors: Sam.Shih <sam.shih@xxxxxxxxxxxx>
+ * Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx>
+ * Daniel Golle <daniel@xxxxxxxxxxxxxx>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+#include "mt7986a.dtsi"
+
+/ {
+ model = "Bananapi BPI-R3";
+ compatible = "bananapi,bpi-r3", "mediatek,mt7986a";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ factory-key {
I'd say that this is not "factory-key" but "reset-key"?
okay i rename it.
+ label = "reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&pio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ wps-key {
+ label = "wps";
+ linux,code = <KEY_WPS_BUTTON>;
+ gpios = <&pio 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+
..snip..
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
Doesn't your bootloader fill-in the memory size automatically?
have not tried yet.
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
This is "avdd18", isn't it?
need to check
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
All these regulators have a vin-supply: please fill it in.
Moreover, in the schematics, I can also see other LDOs: 0.9VD (input
+12VD),
AVDD12 (input 1.8VD), DDRV_VPP (input 3.3VD)...
ok
Of course, this means that you have one more 1.8V regulator, called
1.8vd.
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
regulator-name = "3.3vd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
vin-supply = <&dcin>; (dcin: regulator-12vd { ... })
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-5V";
regulator-name = "fixed-5p1";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
Schematics say "+5V: 5.1V/3A", so this is not 5000000.
+ regulator-boot-on;
+ regulator-always-on;
vin-supply = <&dcin>;
+ };
+
..snip..
+
+&pio {
+ i2c_pins: i2c-pins {
+ mux {
+ function = "i2c";
+ groups = "i2c";
+ };
+ };
+
+ mmc0_pins_default: mmc0-pins {
+ mux {
+ function = "emmc";
+ groups = "emmc_51";
+ };
+ conf-cmd-dat {
+ pins = "EMMC_DATA_0", "EMMC_DATA_1", "EMMC_DATA_2",
+ "EMMC_DATA_3", "EMMC_DATA_4", "EMMC_DATA_5",
+ "EMMC_DATA_6", "EMMC_DATA_7", "EMMC_CMD";
+ input-enable;
+ drive-strength = <4>;
+ mediatek,pull-up-adv = <1>; /* pull-up 10K */
Can we please stop using these custom pull-{up,down}-adv properties?
Check what was done on pinctrl-mt8192.c (and dt schema) for more
information
and examples.
need to check these with MTK.
+ };
+ conf-clk {
..snip..
+
+&wifi {
+ status = "okay";
+ pinctrl-names = "default", "dbdc";
+ pinctrl-0 = <&wf_2g_5g_pins>, <&wf_led_pins>;
+ pinctrl-1 = <&wf_dbdc_pins>, <&wf_led_pins>;
+
+ mediatek,eeprom-data = <0x86790900 0xc4326 0x60000000 0x00 0x00 0x00
0x00 0x00
Ouch! This looks like firmware unrolled in a devicetree property - that
can't
be right.
Please dump that in a binary file and load it as firmware from
userspace.
it uses the mt76 driver and here eeprom can only be loaded from
mtd-partition or from device tree. Previous attempts loading eeprom data
from userspace file (like it's done for "normal" firmware) were
rejected.
regards Frank
