| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <64daf96b-b2b5-6f02-91aa-58d19083ee01@collabora.com>
Date: Fri, 28 Oct 2022 11:19:37 +0200
From: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
To: Frank Wunderlich <linux@...web.de>,
linux-mediatek@...ts.infradead.org
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Matthias Brugger <matthias.bgg@...il.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC v2 7/7] arm64: dts: mt7986: add Bananapi R3
Il 26/10/22 11:36, Frank Wunderlich ha scritto:
> From: Frank Wunderlich <frank-w@...lic-files.de>
>
> 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@...lic-files.de>
> ---
> 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@...iatek.com>
> + */
> +
> +/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.
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?
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.
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...
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..?
> + 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@...iatek.com>
> + */
> +
> +/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
> + 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@...iatek.com>
> + * Frank Wunderlich <frank-w@...lic-files.de>
> + * Daniel Golle <daniel@...rotopia.org>
> + */
> +
> +/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"?
> + 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@...00000 {
> + device_type = "memory";
> + reg = <0 0x40000000 0 0x40000000>;
Doesn't your bootloader fill-in the memory size automatically?
> + };
> +
> + reg_1p8v: regulator-1p8v {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-1.8V";
This is "avdd18", isn't it?
> + 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)...
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.
> + };
> + 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.
Regards,
Angelo
Powered by blists - more mailing lists