diff mbox series

ramips: add support for Notion R281 (mtd5)

Message ID c7980e8537888450064e5d3c5fa6e458@imap4.upd.edu.ph
State Superseded
Delegated to: Hauke Mehrtens
Headers show
Series ramips: add support for Notion R281 (mtd5) | expand

Commit Message

Ian Pangilinan July 24, 2022, 9:38 a.m. UTC 
From: Ian Pangilinan <braveheart_leo@yahoo.com>
Date: Sun, 24 July 2022 12:37:00 +0800
Subject: [PATCH] ramips: add support for Notion R281 (mtd5)

Notion R281 is a Cat.6 LTE CPE.

Product link: https://www.notioni.com/productinfo/759146.html

Hardware highlights:
  - CPU: MT7621A 2C4T @ 880MHz
  - RAM: DDR3 128MB @ 1066MHz
  - FLASH: S34ML01G2 128MB SPI NAND
  - WLAN0: MT7603E 2.4GHz 802.11bgn 2x2:2 @ 300Mbps
  - WLAN1: MT7613BE 5GHz 802.11nac 2x2:2 @ 867Mbps
  - SWITCH: MT7530 4-port GbE
  - WWAN: Marvell PXA1826 (Nezha3) Profile M26H Board Cat.6 LTE
  - SIM: 1x Mini-SIM 2FF
  - USB: 1x USB 2.0 Micro Type-B
  - BUTTONS: WPS, Reset
  - LEDS: Power, Data, Wi-Fi, LAN, Signal1-3
  - POWER: 12VDc 2A


The device comes in two variants depending on where the bootloader
loads the kernel. One variant where the bootloader loads at 0xbc140000
(mtd4), and another at 0xbe800000 (mtd5). This patch is for the latter.
I haven't found a way to change this behavior, so I'm making a
distinction between the two.

This is the MTD partitions from the stock firmware:

0x000000000000-0x000007f80000 : "ALL"
0x000000000000-0x000000080000 : "Bootloader"
0x000000080000-0x000000100000 : "Config"
0x000000100000-0x000000140000 : "Factory"
0x000000140000-0x000002800000 : "firmware1"
0x000002800000-0x000004ec0000 : "firmware2"
0x000002996dfc-0x000004ec0000 : "rootfs"
0x000003180000-0x000004ec0000 : "rootfs_data"
0x000004ec0000-0x000007f00000 : "ota"
0x000007f00000-0x000007f80000 : "Configbak"

This is how it looks when flashed to OpenWrt with this patch:

0x000000000000-0x000000080000 : "u-boot"
0x000000080000-0x0000000a0000 : "u-boot-env"
0x000000100000-0x000000140000 : "factory"
0x000000140000-0x000002800000 : "ubiconcat0"
0x000002800000-0x000002c00000 : "kernel"
0x000002c00000-0x000007f00000 : "ubiconcat1"
0x000007f00000-0x000007f80000 : "configbak"
0x000000000000-0x0000079c0000 : "ubi"

I have the mtd5 variant on hand, and will send another patch for the
other variant once I confirmed some flash offsets, or update this
patch when a way could be found to set this load address.


Installation instructions:

Stock firmware runs an old OpenWrt Chaos Calmer release. Unfortunately,
because of the changes in the flash layout, this cannot be sysupgrade-d
readily from stock. Installation will be via tftpboot in the bootloader.
Connect the USB-TTL serial converter as follows, indicated on the board
by the APTX marking near three round PCB pads:

(RX) (GND) (TX) APTX

Baud rate is 57600.

1. Connect the computer to the device via ethernet cable.
Set a static adddress of 10.10.10.3/24 to the wired interface.
2. Start the TFTP server, point it to where the initramfs image is
located. Rename the image to 'test.bin'.
3. Turn on the device. There will be a three-second delay before the
default 'Boot system code via flash' is selected.
4. Interrupt the boot process by pressing 1 to 'System Load Linux to
SDRAM via TFTP'.
5. Press enter to accept the default 'Input device IP (10.10.10.123)'.
6. Press enter to accept the default 'Input server IP (10.10.10.3)'.
7. Press enter to accept the default 'Input Linux Kernel filename ()',
or enter 'test.bin'.
8. Wait for the initramfs to load.
9. Reconnect the wired interface to any LAN ports of the device
via dhcp.
9. Flash the sysupgrade image at
http://192.168.1.1/cgi-bin/luci/admin/system/flash


The only configurable LEDs are the red and white data, and white wifi
LEDs. I use the red data LED as status indicator for OpenWrt.
The white LAN led is controlled by the switch and functions as expected,
as well as the three green Signal LED indicators controlled by the WWAN.
There is also an exported GPIO to reset the WWAN. These are also the 
same
LEDs and GPIO found on the stock firmware.

Support for WWAN could come at a later date. I have setup LAN1 of the
device as WAN, and implemented a patch in part that achieves '2Gbps CPU
bandwidth', found here: https://github.com/openwrt/openwrt/pull/10238

Signed-off-by: Ian Pangilinan <braveheart_leo@yahoo.com>
---
  package/boot/uboot-envtools/files/ramips                       |   1 +
  target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts (new)      | 240 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  target/linux/ramips/image/mt7621.mk                            |  15 
++++++++
  target/linux/ramips/mt7621/base-files/etc/board.d/02_network   |   3 ++
  target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh  |   1 +
  5 files changed, 260 insertions(+), 0 deletion(-)
  create mode 100644 target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts

Comments

Arınç ÜNAL July 24, 2022, 10:32 a.m. UTC | #1 
On 24.07.2022 12:38, Ian Pangilinan wrote:
>   From: Ian Pangilinan <braveheart_leo@yahoo.com>
> Date: Sun, 24 July 2022 12:37:00 +0800
> Subject: [PATCH] ramips: add support for Notion R281 (mtd5)
> 
> Notion R281 is a Cat.6 LTE CPE.
> 
> Product link: https://www.notioni.com/productinfo/759146.html
> 
> Hardware highlights:
>    - CPU: MT7621A 2C4T @ 880MHz
>    - RAM: DDR3 128MB @ 1066MHz
>    - FLASH: S34ML01G2 128MB SPI NAND
>    - WLAN0: MT7603E 2.4GHz 802.11bgn 2x2:2 @ 300Mbps
>    - WLAN1: MT7613BE 5GHz 802.11nac 2x2:2 @ 867Mbps
>    - SWITCH: MT7530 4-port GbE
>    - WWAN: Marvell PXA1826 (Nezha3) Profile M26H Board Cat.6 LTE
>    - SIM: 1x Mini-SIM 2FF
>    - USB: 1x USB 2.0 Micro Type-B
>    - BUTTONS: WPS, Reset
>    - LEDS: Power, Data, Wi-Fi, LAN, Signal1-3
>    - POWER: 12VDc 2A
> 
> 
> The device comes in two variants depending on where the bootloader
> loads the kernel. One variant where the bootloader loads at 0xbc140000
> (mtd4), and another at 0xbe800000 (mtd5). This patch is for the latter.
> I haven't found a way to change this behavior, so I'm making a
> distinction between the two.
> 
> This is the MTD partitions from the stock firmware:
> 
> 0x000000000000-0x000007f80000 : "ALL"
> 0x000000000000-0x000000080000 : "Bootloader"
> 0x000000080000-0x000000100000 : "Config"
> 0x000000100000-0x000000140000 : "Factory"
> 0x000000140000-0x000002800000 : "firmware1"
> 0x000002800000-0x000004ec0000 : "firmware2"
> 0x000002996dfc-0x000004ec0000 : "rootfs"
> 0x000003180000-0x000004ec0000 : "rootfs_data"
> 0x000004ec0000-0x000007f00000 : "ota"
> 0x000007f00000-0x000007f80000 : "Configbak"
> 
> This is how it looks when flashed to OpenWrt with this patch:
> 
> 0x000000000000-0x000000080000 : "u-boot"
> 0x000000080000-0x0000000a0000 : "u-boot-env"
> 0x000000100000-0x000000140000 : "factory"
> 0x000000140000-0x000002800000 : "ubiconcat0"
> 0x000002800000-0x000002c00000 : "kernel"
> 0x000002c00000-0x000007f00000 : "ubiconcat1"
> 0x000007f00000-0x000007f80000 : "configbak"
> 0x000000000000-0x0000079c0000 : "ubi"
> 
> I have the mtd5 variant on hand, and will send another patch for the
> other variant once I confirmed some flash offsets, or update this
> patch when a way could be found to set this load address.
> 
> 
> Installation instructions:
> 
> Stock firmware runs an old OpenWrt Chaos Calmer release. Unfortunately,
> because of the changes in the flash layout, this cannot be sysupgrade-d
> readily from stock. Installation will be via tftpboot in the bootloader.
> Connect the USB-TTL serial converter as follows, indicated on the board
> by the APTX marking near three round PCB pads:
> 
> (RX) (GND) (TX) APTX
> 
> Baud rate is 57600.
> 
> 1. Connect the computer to the device via ethernet cable.
> Set a static adddress of 10.10.10.3/24 to the wired interface.
> 2. Start the TFTP server, point it to where the initramfs image is
> located. Rename the image to 'test.bin'.
> 3. Turn on the device. There will be a three-second delay before the
> default 'Boot system code via flash' is selected.
> 4. Interrupt the boot process by pressing 1 to 'System Load Linux to
> SDRAM via TFTP'.
> 5. Press enter to accept the default 'Input device IP (10.10.10.123)'.
> 6. Press enter to accept the default 'Input server IP (10.10.10.3)'.
> 7. Press enter to accept the default 'Input Linux Kernel filename ()',
> or enter 'test.bin'.
> 8. Wait for the initramfs to load.
> 9. Reconnect the wired interface to any LAN ports of the device
> via dhcp.
> 9. Flash the sysupgrade image at
> http://192.168.1.1/cgi-bin/luci/admin/system/flash
> 
> 
> The only configurable LEDs are the red and white data, and white wifi
> LEDs. I use the red data LED as status indicator for OpenWrt.
> The white LAN led is controlled by the switch and functions as expected,
> as well as the three green Signal LED indicators controlled by the WWAN.
> There is also an exported GPIO to reset the WWAN. These are also the
> same
> LEDs and GPIO found on the stock firmware.
> 
> Support for WWAN could come at a later date. I have setup LAN1 of the
> device as WAN, and implemented a patch in part that achieves '2Gbps CPU
> bandwidth', found here: https://github.com/openwrt/openwrt/pull/10238
> 
> Signed-off-by: Ian Pangilinan <braveheart_leo@yahoo.com>
> ---
>    package/boot/uboot-envtools/files/ramips                       |   1 +
>    target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts (new)      | 240
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>    target/linux/ramips/image/mt7621.mk                            |  15
> ++++++++
>    target/linux/ramips/mt7621/base-files/etc/board.d/02_network   |   3 ++
>    target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh  |   1 +
>    5 files changed, 260 insertions(+), 0 deletion(-)
>    create mode 100644 target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts
> diff --git a/package/boot/uboot-envtools/files/ramips
> b/package/boot/uboot-envtools/files/ramips
> index eebc08d65d..d9017052ed 100644
> --- a/package/boot/uboot-envtools/files/ramips
> +++ b/package/boot/uboot-envtools/files/ramips
> @@ -61,6 +63,7 @@ linksys,ea7500-v2|\
>    linksys,ea8100-v1|\
>    linksys,ea8100-v2|\
>    mts,wg430223|\
> +notion,r281-mtd5|\
>    xiaomi,mi-router-3g|\
>    xiaomi,mi-router-3-pro|\
>    xiaomi,mi-router-4|\
> diff --git a/target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts
> b/target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts
> new file mode 100644
> index 0000000000..4866209fa5
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +// Copyright (C) 2022, Ian Pangilinan <braveheart_leo@yahoo.com>
> +
> +#include "mt7621.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +	compatible = "notion,r281-mtd5", "mediatek,mt7621-soc";
> +	model = "Notion R281 (mtd5)";
> +
> +	aliases {
> +		led-boot = &led_red;
> +		led-failsafe = &led_red;
> +		/* led-running: skip this LED event as we use
> +		 * the red LED indicator for no data,
> +		 * which will leave it in the default-on state
> +		 */
> +		led-upgrade = &led_red;
> +		label-mac-device = &label_mac;
> +	};
> +
> +	ubi-concat {
> +		compatible = "mtd-concat";
> +		devices = <&ubiconcat0 &ubiconcat1>;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			partition@0 {
> +				reg = <0x0 0x79c0000>;
> +				label = "ubi";
> +			};
> +		};
> +	};
> +
> +	gpio-export {
> +		compatible = "gpio-export";
> +		#size-cells = <0>;
> +
> +		reset_cp {
> +			gpio-export,name = "reset_cp";
> +			gpio-export,output = <0>;
> +			gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led_red: led-0 {
> +			label = "red:data";
> +			gpios = <&gpio 16 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		led-1 {
> +			label = "white:data";
> +			gpios = <&gpio 15 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		led-2 {
> +			label = "white:wifi";
> +			gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> +			linux,default-trigger = "phy0tpt";
> +		};
> +	};
> +
> +	keys {
> +		compatible = "gpio-keys";
> +
> +		/* use wps as wifi button */
> +		key-wifi {
> +			label = "wifi";
> +			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_RFKILL>;
> +		};
> +
> +		key-reset {
> +			label = "reset";
> +			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_RESTART>;
> +		};
> +	};
> +};
> +
> +&state_default {
> +	gpio {
> +		groups = "jtag", "rgmii2", "uart3";
> +		function = "gpio";
> +	};
> +};

Please remove this node. It is unnecessary and claiming the rgmii2 group 
here will break gmac1 configuration.

> +
> +&pcie {
> +	status = "okay";
> +};
> +
> +&pcie0 {
> +	label_mac: wifi@0,0 {
> +		compatible = "pci14c3,7603";
> +		reg = <0x0 0 0 0 0>;
> +
> +		mediatek,mtd-eeprom = <&factory 0x0>;
> +		ieee80211-freq-limit = <2400000 2500000>;
> +
> +		nvmem-cells = <&macaddr_factory_4>;
> +		nvmem-cell-names = "mac-address";
> +	};
> +};
> +
> +&pcie1 {
> +	wifi@0,0 {
> +		compatible = "pci14c3,7663";
> +		reg = <0x0 0 0 0 0>;
> +
> +		mediatek,mtd-eeprom = <&factory 0x8000>;
> +		ieee80211-freq-limit = <5000000 6000000>;
> +
> +		nvmem-cells = <&macaddr_factory_8004>;
> +		nvmem-cell-names = "mac-address";
> +	};
> +};
> +
> +&nand {
> +	status = "okay";
> +
> +	partitions {
> +		compatible = "fixed-partitions";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		partition@0 {
> +			label = "u-boot";
> +			reg = <0x0 0x80000>;
> +			read-only;
> +		};
> +
> +		/* allow setting u-boot-env vars */
> +		partition@80000 {
> +			label = "u-boot-env";
> +			reg = <0x80000 0x20000>;
> +		};
> +
> +		factory: partition@100000 {
> +			label = "factory";
> +			reg = <0x100000 0x40000>;
> +			read-only;
> +		};
> +
> +		/* convert firmware1 from stock to ubi */
> +		ubiconcat0: partition@140000 {
> +			label = "ubiconcat0";
> +			reg = <0x140000 0x26c0000>;
> +		};
> +
> +		/* set kernel mtdsize to 4MB */
> +		partition@2800000 {
> +			label = "kernel";
> +			reg = <0x2800000 0x400000>;
> +		};
> +
> +		/* convert firmware2, ota from stock to ubi */
> +		ubiconcat1: partition@2c00000 {
> +			label = "ubiconcat1";
> +			reg = <0x2c00000 0x5300000>;
> +		};
> +
> +		partition@7f00000 {
> +			label = "configbak";
> +			reg = <0x7f00000 0x80000>;
> +			read-only;
> +		};
> +
> +		/* BBT probably contained in the last 0x80000 or 512K bytes */
> +	};
> +};
> +
> +&switch0 {
> +	ports {
> +		port@1 {
> +			status = "okay";
> +			label = "lan2";
> +		};
> +
> +		port@2 {
> +			status = "okay";
> +			label = "lan3";
> +		};
> +
> +		port@3 {
> +			status = "okay";
> +			label = "lan4";
> +		};
> +	};
> +};
> +
> +&ethernet {
> +	pinctrl-0 = <&mdio_pins>, <&rgmii1_pins>;
> +};

Ditto.

Arınç
Ian Pangilinan July 24, 2022, 11:48 a.m. UTC | #2 
> On 2022-07-24 18:32, Arınç ÜNAL wrote:
> On 24.07.2022 12:38, Ian Pangilinan wrote:
>> +	keys {
>> +		compatible = "gpio-keys";
>> +
>> +		/* use wps as wifi button */
>> +		key-wifi {
>> +			label = "wifi";
>> +			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
>> +			linux,code = <KEY_RFKILL>;
>> +		};
>> +
>> +		key-reset {
>> +			label = "reset";
>> +			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
>> +			linux,code = <KEY_RESTART>;
>> +		};
>> +	};
>> +};
>> +
>> +&state_default {
>> +	gpio {
>> +		groups = "jtag", "rgmii2", "uart3";
>> +		function = "gpio";
>> +	};
>> +};
> 
> Please remove this node. It is unnecessary and claiming the rgmii2
> group here will break gmac1 configuration.

I have removed rgmii2 from the group. But I could not remove the
state_default node, as I have not fully applied the patch series yet
to my locally cloned OpenWrt git repo, which will involve changes to
mt7621.dtsi and a hundred other device-tree files, which will render
this patch unable to be applied to master as your pull request is
still pending.

BTW, thank you for your patch, I hope it gets merged soon. For
those devices that do need GPIOs 22-33, which is shared with rgmii2,
would this not break gmac1 configuration?

&rgmii2_pins {
	rgmii2 {
		function = "gpio";
	};
};

Is this not the same as above? Also, I have noticed this in dmesg
after applying the changes:

[    5.279629] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
[    5.469566] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
[    5.499862] mt7530 mdio-bus:1f lan2 (uninitialized): PHY
[mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=27)
[    5.521957] mt7530 mdio-bus:1f lan3 (uninitialized): PHY
[mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=28)
[    5.543995] mt7530 mdio-bus:1f lan4 (uninitialized): PHY
[mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=29)
[    5.566898] mt7530 mdio-bus:1f: configuring for fixed/rgmii link mode
[    6.841401] mt7530 mdio-bus:1f: Link is Up - 1Gbps/Full - flow
control rx/tx
[   14.228062] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link 
mode
[   16.997212] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
control rx/tx
[   17.277909] mt7530 mdio-bus:1f lan2: Link is Down
[   35.288001] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link 
mode
[   35.431097] mt7530 mdio-bus:1f lan3: configuring for phy/gmii link 
mode
[   35.508752] mt7530 mdio-bus:1f lan4: configuring for phy/gmii link 
mode
[   35.590215] mtk_soc_eth 1e100000.ethernet wan: PHY [mdio-bus:00] 
driver
[MediaTek MT7530 PHY] (irq=POLL)
[   39.186967] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
control rx/tx
[  170.691572] mt7530 mdio-bus:1f lan2: Link is Down
[  173.311930] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
control rx/tx

Is the irq=POLL for the ethernet-phy0, which is the wan/lan1 port where
the change is made, normal?

>> +&switch0 {
>> +	ports {
>> +		port@1 {
>> +			status = "okay";
>> +			label = "lan2";
>> +		};
>> +
>> +		port@2 {
>> +			status = "okay";
>> +			label = "lan3";
>> +		};
>> +
>> +		port@3 {
>> +			status = "okay";
>> +			label = "lan4";
>> +		};
>> +	};
>> +};
>> +
>> +&ethernet {
>> +	pinctrl-0 = <&mdio_pins>, <&rgmii1_pins>;
>> +};
> 
> Ditto.
> 
> Arınç
> 

I have removed this node workaround. Thank you.

-ianp
Arınç ÜNAL July 24, 2022, 11:53 a.m. UTC | #3 
On 24.07.2022 14:48, Ian Pangilinan wrote:
>> On 2022-07-24 18:32, Arınç ÜNAL wrote:
>> On 24.07.2022 12:38, Ian Pangilinan wrote:
>>> +	keys {
>>> +		compatible = "gpio-keys";
>>> +
>>> +		/* use wps as wifi button */
>>> +		key-wifi {
>>> +			label = "wifi";
>>> +			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
>>> +			linux,code = <KEY_RFKILL>;
>>> +		};
>>> +
>>> +		key-reset {
>>> +			label = "reset";
>>> +			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
>>> +			linux,code = <KEY_RESTART>;
>>> +		};
>>> +	};
>>> +};
>>> +
>>> +&state_default {
>>> +	gpio {
>>> +		groups = "jtag", "rgmii2", "uart3";
>>> +		function = "gpio";
>>> +	};
>>> +};
>>
>> Please remove this node. It is unnecessary and claiming the rgmii2
>> group here will break gmac1 configuration.
> 
> I have removed rgmii2 from the group. But I could not remove the
> state_default node, as I have not fully applied the patch series yet
> to my locally cloned OpenWrt git repo, which will involve changes to
> mt7621.dtsi and a hundred other device-tree files, which will render
> this patch unable to be applied to master as your pull request is
> still pending.

You can either revert your gmac1 configuration (because that requires my 
PR as well) or remove this node and put a disclaimer to require my PR to 
be applied for this patch to be applied.

> 
> BTW, thank you for your patch, I hope it gets merged soon. For
> those devices that do need GPIOs 22-33, which is shared with rgmii2,
> would this not break gmac1 configuration?
> 
> &rgmii2_pins {
> 	rgmii2 {
> 		function = "gpio";
> 	};
> };

This is exactly why there is no phy muxing to gmac1 for devices that use 
the pins 22-33 as GPIO.

> 
> Is this not the same as above? Also, I have noticed this in dmesg
> after applying the changes:
> 
> [    5.279629] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
> [    5.469566] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
> [    5.499862] mt7530 mdio-bus:1f lan2 (uninitialized): PHY
> [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=27)
> [    5.521957] mt7530 mdio-bus:1f lan3 (uninitialized): PHY
> [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=28)
> [    5.543995] mt7530 mdio-bus:1f lan4 (uninitialized): PHY
> [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=29)
> [    5.566898] mt7530 mdio-bus:1f: configuring for fixed/rgmii link mode
> [    6.841401] mt7530 mdio-bus:1f: Link is Up - 1Gbps/Full - flow
> control rx/tx
> [   14.228062] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link
> mode
> [   16.997212] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
> control rx/tx
> [   17.277909] mt7530 mdio-bus:1f lan2: Link is Down
> [   35.288001] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link
> mode
> [   35.431097] mt7530 mdio-bus:1f lan3: configuring for phy/gmii link
> mode
> [   35.508752] mt7530 mdio-bus:1f lan4: configuring for phy/gmii link
> mode
> [   35.590215] mtk_soc_eth 1e100000.ethernet wan: PHY [mdio-bus:00]
> driver
> [MediaTek MT7530 PHY] (irq=POLL)
> [   39.186967] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
> control rx/tx
> [  170.691572] mt7530 mdio-bus:1f lan2: Link is Down
> [  173.311930] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
> control rx/tx
> 
> Is the irq=POLL for the ethernet-phy0, which is the wan/lan1 port where
> the change is made, normal?

Good question. The phy was controlled under the DSA switch node which 
had interrupts defined. Interrupts aren't defined on the mdio node where 
we define the phy now. Therefore polling is used instead. Anyway, this 
does not break anything.

Arınç
Ian Pangilinan July 24, 2022, 12:34 p.m. UTC | #4 
> On 2022-07-24 19:53, Arınç ÜNAL wrote:
> On 24.07.2022 14:48, Ian Pangilinan wrote:
>>> On 2022-07-24 18:32, Arınç ÜNAL wrote:
>>> On 24.07.2022 12:38, Ian Pangilinan wrote:
>>>> +	keys {
>>>> +		compatible = "gpio-keys";
>>>> +
>>>> +		/* use wps as wifi button */
>>>> +		key-wifi {
>>>> +			label = "wifi";
>>>> +			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
>>>> +			linux,code = <KEY_RFKILL>;
>>>> +		};
>>>> +
>>>> +		key-reset {
>>>> +			label = "reset";
>>>> +			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
>>>> +			linux,code = <KEY_RESTART>;
>>>> +		};
>>>> +	};
>>>> +};
>>>> +
>>>> +&state_default {
>>>> +	gpio {
>>>> +		groups = "jtag", "rgmii2", "uart3";
>>>> +		function = "gpio";
>>>> +	};
>>>> +};
>>> 
>>> Please remove this node. It is unnecessary and claiming the rgmii2
>>> group here will break gmac1 configuration.
>> 
>> I have removed rgmii2 from the group. But I could not remove the
>> state_default node, as I have not fully applied the patch series yet
>> to my locally cloned OpenWrt git repo, which will involve changes to
>> mt7621.dtsi and a hundred other device-tree files, which will render
>> this patch unable to be applied to master as your pull request is
>> still pending.
> 
> You can either revert your gmac1 configuration (because that requires
> my PR as well) or remove this node and put a disclaimer to require my
> PR to be applied for this patch to be applied.
> 

This is my first time to submit a patch on this mailing list, so forgive
me for being a little hard on the head. ;) But, I don't see why I can't
use the relevant part of your patch series, which is not dependent on 
the
other changes made, to make the change as intended by your PR.

Of course I don't wan't to take away credit where credit is due, that's
why I referenced your PR here.

>> 
>> BTW, thank you for your patch, I hope it gets merged soon. For
>> those devices that do need GPIOs 22-33, which is shared with rgmii2,
>> would this not break gmac1 configuration?
>> 
>> &rgmii2_pins {
>> 	rgmii2 {
>> 		function = "gpio";
>> 	};
>> };
> 
> This is exactly why there is no phy muxing to gmac1 for devices that
> use the pins 22-33 as GPIO.
> 

Understood. It is unfortunate for those devices that can't take
advantage of this improvement if those pins are used for something else.

>> 
>> Is this not the same as above? Also, I have noticed this in dmesg
>> after applying the changes:
>> 
>> [    5.279629] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
>> [    5.469566] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
>> [    5.499862] mt7530 mdio-bus:1f lan2 (uninitialized): PHY
>> [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=27)
>> [    5.521957] mt7530 mdio-bus:1f lan3 (uninitialized): PHY
>> [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=28)
>> [    5.543995] mt7530 mdio-bus:1f lan4 (uninitialized): PHY
>> [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=29)
>> [    5.566898] mt7530 mdio-bus:1f: configuring for fixed/rgmii link 
>> mode
>> [    6.841401] mt7530 mdio-bus:1f: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> [   14.228062] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link
>> mode
>> [   16.997212] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> [   17.277909] mt7530 mdio-bus:1f lan2: Link is Down
>> [   35.288001] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link
>> mode
>> [   35.431097] mt7530 mdio-bus:1f lan3: configuring for phy/gmii link
>> mode
>> [   35.508752] mt7530 mdio-bus:1f lan4: configuring for phy/gmii link
>> mode
>> [   35.590215] mtk_soc_eth 1e100000.ethernet wan: PHY [mdio-bus:00]
>> driver
>> [MediaTek MT7530 PHY] (irq=POLL)
>> [   39.186967] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> [  170.691572] mt7530 mdio-bus:1f lan2: Link is Down
>> [  173.311930] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> 
>> Is the irq=POLL for the ethernet-phy0, which is the wan/lan1 port 
>> where
>> the change is made, normal?
> 
> Good question. The phy was controlled under the DSA switch node which
> had interrupts defined. Interrupts aren't defined on the mdio node
> where we define the phy now. Therefore polling is used instead.
> Anyway, this does not break anything.
> 
> Arınç
> 

Copy. This is good to know.

-ianp
Arınç ÜNAL July 24, 2022, 1:21 p.m. UTC | #5 
On 24.07.2022 15:34, Ian Pangilinan wrote:
>> On 2022-07-24 19:53, Arınç ÜNAL wrote:
>> On 24.07.2022 14:48, Ian Pangilinan wrote:
>>>> On 2022-07-24 18:32, Arınç ÜNAL wrote:
>>>> On 24.07.2022 12:38, Ian Pangilinan wrote:
>>>>> +	keys {
>>>>> +		compatible = "gpio-keys";
>>>>> +
>>>>> +		/* use wps as wifi button */
>>>>> +		key-wifi {
>>>>> +			label = "wifi";
>>>>> +			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
>>>>> +			linux,code = <KEY_RFKILL>;
>>>>> +		};
>>>>> +
>>>>> +		key-reset {
>>>>> +			label = "reset";
>>>>> +			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
>>>>> +			linux,code = <KEY_RESTART>;
>>>>> +		};
>>>>> +	};
>>>>> +};
>>>>> +
>>>>> +&state_default {
>>>>> +	gpio {
>>>>> +		groups = "jtag", "rgmii2", "uart3";
>>>>> +		function = "gpio";
>>>>> +	};
>>>>> +};
>>>>
>>>> Please remove this node. It is unnecessary and claiming the rgmii2
>>>> group here will break gmac1 configuration.
>>>
>>> I have removed rgmii2 from the group. But I could not remove the
>>> state_default node, as I have not fully applied the patch series yet
>>> to my locally cloned OpenWrt git repo, which will involve changes to
>>> mt7621.dtsi and a hundred other device-tree files, which will render
>>> this patch unable to be applied to master as your pull request is
>>> still pending.
>>
>> You can either revert your gmac1 configuration (because that requires
>> my PR as well) or remove this node and put a disclaimer to require my
>> PR to be applied for this patch to be applied.
>>
> 
> This is my first time to submit a patch on this mailing list, so forgive
> me for being a little hard on the head. ;) But, I don't see why I can't
> use the relevant part of your patch series, which is not dependent on
> the
> other changes made, to make the change as intended by your PR.

Of course you can. This is exactly what I want this patch to become. 
However, don't take half measures while you do that. Removing this node 
will not render the patch in a state where it is unable to be applied if 
my PR was not applied beforehand, which I wrongfully said otherwise 
above. So, take the full measure and remove this node, along with the 
other changes you have already made.

Arınç
Ian Pangilinan July 24, 2022, 2:11 p.m. UTC | #6 
On 2022-07-24 21:21, Arınç ÜNAL wrote:
> On 24.07.2022 15:34, Ian Pangilinan wrote:
>>> On 2022-07-24 19:53, Arınç ÜNAL wrote:
>>> On 24.07.2022 14:48, Ian Pangilinan wrote:
>>>>> On 2022-07-24 18:32, Arınç ÜNAL wrote:
>>>>> On 24.07.2022 12:38, Ian Pangilinan wrote:
>>>>>> +	keys {
>>>>>> +		compatible = "gpio-keys";
>>>>>> +
>>>>>> +		/* use wps as wifi button */
>>>>>> +		key-wifi {
>>>>>> +			label = "wifi";
>>>>>> +			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
>>>>>> +			linux,code = <KEY_RFKILL>;
>>>>>> +		};
>>>>>> +
>>>>>> +		key-reset {
>>>>>> +			label = "reset";
>>>>>> +			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
>>>>>> +			linux,code = <KEY_RESTART>;
>>>>>> +		};
>>>>>> +	};
>>>>>> +};
>>>>>> +
>>>>>> +&state_default {
>>>>>> +	gpio {
>>>>>> +		groups = "jtag", "rgmii2", "uart3";
>>>>>> +		function = "gpio";
>>>>>> +	};
>>>>>> +};
>>>>> 
>>>>> Please remove this node. It is unnecessary and claiming the rgmii2
>>>>> group here will break gmac1 configuration.
>>>> 
>>>> I have removed rgmii2 from the group. But I could not remove the
>>>> state_default node, as I have not fully applied the patch series yet
>>>> to my locally cloned OpenWrt git repo, which will involve changes to
>>>> mt7621.dtsi and a hundred other device-tree files, which will render
>>>> this patch unable to be applied to master as your pull request is
>>>> still pending.
>>> 
>>> You can either revert your gmac1 configuration (because that requires
>>> my PR as well) or remove this node and put a disclaimer to require my
>>> PR to be applied for this patch to be applied.
>>> 
>> 
>> This is my first time to submit a patch on this mailing list, so 
>> forgive
>> me for being a little hard on the head. ;) But, I don't see why I 
>> can't
>> use the relevant part of your patch series, which is not dependent on
>> the
>> other changes made, to make the change as intended by your PR.
> 
> Of course you can. This is exactly what I want this patch to become.
> However, don't take half measures while you do that. Removing this
> node will not render the patch in a state where it is unable to be
> applied if my PR was not applied beforehand, which I wrongfully said
> otherwise above. So, take the full measure and remove this node, along
> with the other changes you have already made.
> 
> Arınç
> 

Understood. I will have to wait until your PR gets merged. For this 
patch submission, I will revert to the state before your PR.

I'd like to hear comments, if there be any, from others before I 
resubmit this patch. Thank you.

-ianp
Bjørn Mork July 25, 2022, 5:54 a.m. UTC | #7 
Ian Pangilinan <ian.pangilinan@upd.edu.ph> writes:

> The device comes in two variants depending on where the bootloader
> loads the kernel. One variant where the bootloader loads at 0xbc140000
> (mtd4), and another at 0xbe800000 (mtd5). This patch is for the latter.
> I haven't found a way to change this behavior, so I'm making a
> distinction between the two.
>
> This is the MTD partitions from the stock firmware:
>
> 0x000000000000-0x000007f80000 : "ALL"
> 0x000000000000-0x000000080000 : "Bootloader"
> 0x000000080000-0x000000100000 : "Config"
> 0x000000100000-0x000000140000 : "Factory"
> 0x000000140000-0x000002800000 : "firmware1"
> 0x000002800000-0x000004ec0000 : "firmware2"
> 0x000002996dfc-0x000004ec0000 : "rootfs"
> 0x000003180000-0x000004ec0000 : "rootfs_data"
> 0x000004ec0000-0x000007f00000 : "ota"
> 0x000007f00000-0x000007f80000 : "Configbak"
>
> This is how it looks when flashed to OpenWrt with this patch:
>
> 0x000000000000-0x000000080000 : "u-boot"
> 0x000000080000-0x0000000a0000 : "u-boot-env"
> 0x000000100000-0x000000140000 : "factory"
> 0x000000140000-0x000002800000 : "ubiconcat0"
> 0x000002800000-0x000002c00000 : "kernel"
> 0x000002c00000-0x000007f00000 : "ubiconcat1"
> 0x000007f00000-0x000007f80000 : "configbak"
> 0x000000000000-0x0000079c0000 : "ubi"


This sounds strange.  The above looks like a pretty common dual
partition scheme, where one or more variables in the
"Config"/"u-boot-env" partition decides which system partition is booted
by default.

Could you please dump the contents of "Config"/"u-boot-env"?  Are you
100% sure there isn't anything there telling U-Boot which partition is
active?


Bjørn
Ian Pangilinan July 25, 2022, 6:45 a.m. UTC | #8 
> On 2022-07-25 13:54, Bjørn Mork wrote:
> Ian Pangilinan <ian.pangilinan@upd.edu.ph> writes:
> 
>> The device comes in two variants depending on where the bootloader
>> loads the kernel. One variant where the bootloader loads at 0xbc140000
>> (mtd4), and another at 0xbe800000 (mtd5). This patch is for the 
>> latter.
>> I haven't found a way to change this behavior, so I'm making a
>> distinction between the two.
>> 
>> This is the MTD partitions from the stock firmware:
>> 
>> 0x000000000000-0x000007f80000 : "ALL"
>> 0x000000000000-0x000000080000 : "Bootloader"
>> 0x000000080000-0x000000100000 : "Config"
>> 0x000000100000-0x000000140000 : "Factory"
>> 0x000000140000-0x000002800000 : "firmware1"
>> 0x000002800000-0x000004ec0000 : "firmware2"
>> 0x000002996dfc-0x000004ec0000 : "rootfs"
>> 0x000003180000-0x000004ec0000 : "rootfs_data"
>> 0x000004ec0000-0x000007f00000 : "ota"
>> 0x000007f00000-0x000007f80000 : "Configbak"
>> 
>> This is how it looks when flashed to OpenWrt with this patch:
>> 
>> 0x000000000000-0x000000080000 : "u-boot"
>> 0x000000080000-0x0000000a0000 : "u-boot-env"
>> 0x000000100000-0x000000140000 : "factory"
>> 0x000000140000-0x000002800000 : "ubiconcat0"
>> 0x000002800000-0x000002c00000 : "kernel"
>> 0x000002c00000-0x000007f00000 : "ubiconcat1"
>> 0x000007f00000-0x000007f80000 : "configbak"
>> 0x000000000000-0x0000079c0000 : "ubi"
> 
> 
> This sounds strange.  The above looks like a pretty common dual
> partition scheme, where one or more variables in the
> "Config"/"u-boot-env" partition decides which system partition is 
> booted
> by default.
> 
> Could you please dump the contents of "Config"/"u-boot-env"?  Are you
> 100% sure there isn't anything there telling U-Boot which partition is
> active?
> 
> 
> Bjørn
> 

Hi, thank you for your reply.

Here's the contents of the u-boot-env as a fw_printenv output:

bootcmd=tftp
baudrate=57600
ethaddr="00:AA:BB:CC:DD:10"
BootType=3
uboot_ver=V1.1
PCB_SN=<snip>
SN=<snip>
dropbear_password=75912917
dropbear_mode=0
dropbear_key_type=0
bootargs=console=ttyS1,57600n8 root=/dev/mtdblock6
wifi_ate=on
rootfs_data_ofs=0x3180000
rootfs_data_size=0x01d40000
rootfs_data_fail=0
IMEI=<snip>
stdin=serial
stdout=serial
stderr=serial
filesize=651338
fileaddr=84000000
ipaddr=10.10.10.123
serverip=10.10.10.3
autostart=no
bootfile=test.bin
bootdelay=3

It may look like a dual-partition scheme on the outside, but the other
partition merely serves as backup to the main partition where the 
bootloader
is hardcoded, it seems, to load. This is an ISP-branded device that is
actively being updated to thwart consumer modifications. And just 
recently
they went beyond regular system updates and released a bootloader update 
that
effectively disables tftpboot.

I guess they forgot that this is a CPE, where the C stands for consumer. 
I
have tried setting load_firmware_addr=0xbc140000 but this did not change
anything. The variable was taken from another device, a Cat.4 LTE R051
from the same vendor. I thought it could work, but it didn't. Here's the
serial console log from the stock firmware, in case you could find 
something:
https://pastebin.com/etEUiphL

-ianp
Bjørn Mork July 25, 2022, 7:21 a.m. UTC | #9 
Ian Pangilinan <ian.pangilinan@upd.edu.ph> writes:

> Here's the contents of the u-boot-env as a fw_printenv output:
>
> bootcmd=tftp

This is odd.  Might indicate that U-Boot doesn't use these settings at
all?

> baudrate=57600
> ethaddr="00:AA:BB:CC:DD:10"
> BootType=3

But that's probably overriding the bootcmd - booting from flash by
default.

> uboot_ver=V1.1
> PCB_SN=<snip>
> SN=<snip>
> dropbear_password=75912917
> dropbear_mode=0
> dropbear_key_type=0
> bootargs=console=ttyS1,57600n8 root=/dev/mtdblock6

This is sort of interesting since that root partition is dynamically
split out of the firmware partition.  I assume it would be
/dev/mtdblock5 if you booted from the first image.  But I don't think
it's likely that U-Boot uses this as imput.  It's rather something
that's set by U-Boot depending on which image it decides to boot.

> wifi_ate=on
> rootfs_data_ofs=0x3180000
> rootfs_data_size=0x01d40000
> rootfs_data_fail=0
> IMEI=<snip>
> stdin=serial
> stdout=serial
> stderr=serial
> filesize=651338
> fileaddr=84000000
> ipaddr=10.10.10.123
> serverip=10.10.10.3
> autostart=no
> bootfile=test.bin
> bootdelay=3
>
> It may look like a dual-partition scheme on the outside, but the other
> partition merely serves as backup to the main partition where the 
> bootloader
> is hardcoded, it seems, to load. This is an ISP-branded device that is
> actively being updated to thwart consumer modifications. And just 
> recently
> they went beyond regular system updates and released a bootloader update 
> that
> effectively disables tftpboot.

Ah, OK.  So they do modify the bootloader too.  Then I guess anything is
possible.

I've seen ISP-branded devices seemingly ignoring one of the dual
partitions, using the other image purely as an emergency backup.  The
ZyXEL NR7101 used to be like this.  But that was only because the ISP
firmware never modified the BootingFlag variable. This changed with an
update, but without changing U-Boot.  It was already looking at the
variable.

> I guess they forgot that this is a CPE, where the C stands for consumer. 

"customer", I believe :-) 

> I
> have tried setting load_firmware_addr=0xbc140000 but this did not change
> anything. The variable was taken from another device, a Cat.4 LTE R051
> from the same vendor. I thought it could work, but it didn't.

Maybe run "strings" on the U-Boot partition (or a copy of it) to see if
any interesting variable names show up?

> Here's the
> serial console log from the stock firmware, in case you could find 
> something:
> https://pastebin.com/etEUiphL

Thanks.  I see that you got no hints there.  But that's not unusual.
There could still be a magic variable controlling which image to load.
Even one that doesn't show up in the current settings, making U-Boot
fall back to a default value.



Bjørn
Ian Pangilinan July 25, 2022, 8:06 a.m. UTC | #10 
> On 2022-07-25 15:21, Bjørn Mork wrote:
> Ian Pangilinan writes:
> 
>> Here's the contents of the u-boot-env as a fw_printenv output:
>> 
>> bootcmd=tftp
> 
> This is odd.  Might indicate that U-Boot doesn't use these settings at
> all?
> 
>> baudrate=57600
>> ethaddr="00:AA:BB:CC:DD:10"
>> BootType=3
> 
> But that's probably overriding the bootcmd - booting from flash by
> default.
> 
>> uboot_ver=V1.1
>> PCB_SN=<snip>
>> SN=<snip>
>> dropbear_password=75912917
>> dropbear_mode=0
>> dropbear_key_type=0
>> bootargs=console=ttyS1,57600n8 root=/dev/mtdblock6
> 

We can only guess what black magic goes on for devices such as these 
where the bootloader is modified by the vendor, per request of the ISP 
being their customer.

> This is sort of interesting since that root partition is dynamically
> split out of the firmware partition.  I assume it would be
> /dev/mtdblock5 if you booted from the first image.  But I don't think
> it's likely that U-Boot uses this as imput.  It's rather something
> that's set by U-Boot depending on which image it decides to boot.

The layout is fixed afaict, depending on whether the bootloader is coded 
to load at mtd4 or mtd5. In the mtd4 variant, I can  make an educated 
guess that it looks like this:

ALL
Bootloader
Config
Factory
firmware1
rootfs
rootfs_data
firmware2
ota
Configbak

So it will have bootargs=console=ttyS1,57600n8 root=/dev/mtdblock5. That 
other firmware partition really is only there as a standby/backup copy.

> 
>> wifi_ate=on
>> rootfs_data_ofs=0x3180000
>> rootfs_data_size=0x01d40000
>> rootfs_data_fail=0
>> IMEI=<snip>
>> stdin=serial
>> stdout=serial
>> stderr=serial
>> filesize=651338
>> fileaddr=84000000
>> ipaddr=10.10.10.123
>> serverip=10.10.10.3
>> autostart=no
>> bootfile=test.bin
>> bootdelay=3
>> 
>> It may look like a dual-partition scheme on the outside, but the other
>> partition merely serves as backup to the main partition where the
>> bootloader
>> is hardcoded, it seems, to load. This is an ISP-branded device that is
>> actively being updated to thwart consumer modifications. And just
>> recently
>> they went beyond regular system updates and released a bootloader 
>> update
>> that
>> effectively disables tftpboot.
> 
> Ah, OK.  So they do modify the bootloader too.  Then I guess anything 
> is
> possible.
> 
> I've seen ISP-branded devices seemingly ignoring one of the dual
> partitions, using the other image purely as an emergency backup.  The
> ZyXEL NR7101 used to be like this.  But that was only because the ISP
> firmware never modified the BootingFlag variable. This changed with an
> update, but without changing U-Boot.  It was already looking at the
> variable.
> 

I was hoping that they used a variable to tell which flash address to 
load, but it no longer looks that way if you  consider the two different 
partition layouts of the same hardware, thus two different bootloader 
images with hardcoded values for each layout.

>> I guess they forgot that this is a CPE, where the C stands for 
>> consumer.
> 
> "customer", I believe :-)
> 

Haha, yes good catch. :D

>> I
>> have tried setting load_firmware_addr=0xbc140000 but this did not 
>> change
>> anything. The variable was taken from another device, a Cat.4 LTE R051
>> from the same vendor. I thought it could work, but it didn't.
> 
> Maybe run "strings" on the U-Boot partition (or a copy of it) to see if
> any interesting variable names show up?
> 
> 
>> Here's the
>> serial console log from the stock firmware, in case you could find
>> something:
>> https://pastebin.com/etEUiphL
> 
> Thanks.  I see that you got no hints there.  But that's not unusual.
> There could still be a magic variable controlling which image to load.
> Even one that doesn't show up in the current settings, making U-Boot
> fall back to a default value.
> 
> 
> 
> Bjørn
> 

Yes I have tried to strings /dev/mtd0, but I didn't see anything that 
could give hint. Maybe I missed it, so here it is. Another set of eyes 
is better than one. https://pastebin.com/uDcUyvNc

-ianp
Bjørn Mork July 25, 2022, 8:35 a.m. UTC | #11 
Ian Pangilinan <ian.pangilinan@upd.edu.ph> writes:

> Yes I have tried to strings /dev/mtd0, but I didn't see anything that 
> could give hint. Maybe I missed it, so here it is. Another set of eyes 
> is better than one. https://pastebin.com/uDcUyvNc

I can't see anything interesting there either.  You're probably right -
this is hardcoded in the installed (ISP-specific?) U-Boot build. Ugly.

Only thing of interest I can see is the default

 'bootargs=console=ttyS1,57600n8 root=/dev/mtdblock5'

along with a static 'mtdblock6' string elsewhere.  But that only
supports the assumption that this is a calculated value based on a
decision already made by U-Boot.


Bjørn
Ian Pangilinan July 26, 2022, 10:10 a.m. UTC | #12 
> On 2022-07-25 16:35, Bjørn Mork wrote:
> Ian Pangilinan <ian.pangilinan@upd.edu.ph> writes:
> 
>> Yes I have tried to strings /dev/mtd0, but I didn't see anything that
>> could give hint. Maybe I missed it, so here it is. Another set of eyes
>> is better than one. https://pastebin.com/uDcUyvNc
> 
> I can't see anything interesting there either.  You're probably right -
> this is hardcoded in the installed (ISP-specific?) U-Boot build. Ugly.
> 
> Only thing of interest I can see is the default
> 
>  'bootargs=console=ttyS1,57600n8 root=/dev/mtdblock5'
> 
> along with a static 'mtdblock6' string elsewhere.  But that only
> supports the assumption that this is a calculated value based on a
> decision already made by U-Boot.
> 
> 
> Bjørn
> 
> Email secured by UP Diliman Webmail

Looks like your observations regarding the bootargs and the static 
mtdblock6 were hints, and with the help of a colleague of mine we found 
out how to switch partitions. ;) It really is an ugly hack, the 
bootloader looks at the value of 'root' in 'bootargs'. If 
root=/dev/mtdblock5, then it loads the kernel at 0xbc140000. If 
root=/dev/mtdblock6, then it loads the kernel at 0xbe800000.

Now I can simply this patch and use the layout where kernel is loaded at 
0xbc140000, and note how to switch to this if not yet set like mine.

-ianp
diff mbox series

Patch

diff --git a/package/boot/uboot-envtools/files/ramips 
b/package/boot/uboot-envtools/files/ramips
index eebc08d65d..d9017052ed 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -61,6 +63,7 @@  linksys,ea7500-v2|\
  linksys,ea8100-v1|\
  linksys,ea8100-v2|\
  mts,wg430223|\
+notion,r281-mtd5|\
  xiaomi,mi-router-3g|\
  xiaomi,mi-router-3-pro|\
  xiaomi,mi-router-4|\
diff --git a/target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts 
b/target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts
new file mode 100644
index 0000000000..4866209fa5
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_notion_r281-mtd5.dts
@@ -0,0 +1,240 @@ 
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+// Copyright (C) 2022, Ian Pangilinan <braveheart_leo@yahoo.com>
+
+#include "mt7621.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	compatible = "notion,r281-mtd5", "mediatek,mt7621-soc";
+	model = "Notion R281 (mtd5)";
+
+	aliases {
+		led-boot = &led_red;
+		led-failsafe = &led_red;
+		/* led-running: skip this LED event as we use
+		 * the red LED indicator for no data,
+		 * which will leave it in the default-on state
+		 */
+		led-upgrade = &led_red;
+		label-mac-device = &label_mac;
+	};
+
+	ubi-concat {
+		compatible = "mtd-concat";
+		devices = <&ubiconcat0 &ubiconcat1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				reg = <0x0 0x79c0000>;
+				label = "ubi";
+			};
+		};
+	};
+
+	gpio-export {
+		compatible = "gpio-export";
+		#size-cells = <0>;
+
+		reset_cp {
+			gpio-export,name = "reset_cp";
+			gpio-export,output = <0>;
+			gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led_red: led-0 {
+			label = "red:data";
+			gpios = <&gpio 16 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-1 {
+			label = "white:data";
+			gpios = <&gpio 15 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-2 {
+			label = "white:wifi";
+			gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "phy0tpt";
+		};
+	};
+
+	keys {
+		compatible = "gpio-keys";
+
+		/* use wps as wifi button */
+		key-wifi {
+			label = "wifi";
+			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_RFKILL>;
+		};
+
+		key-reset {
+			label = "reset";
+			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_RESTART>;
+		};
+	};
+};
+
+&state_default {
+	gpio {
+		groups = "jtag", "rgmii2", "uart3";
+		function = "gpio";
+	};
+};
+
+&pcie {
+	status = "okay";
+};
+
+&pcie0 {
+	label_mac: wifi@0,0 {
+		compatible = "pci14c3,7603";
+		reg = <0x0 0 0 0 0>;
+
+		mediatek,mtd-eeprom = <&factory 0x0>;
+		ieee80211-freq-limit = <2400000 2500000>;
+
+		nvmem-cells = <&macaddr_factory_4>;
+		nvmem-cell-names = "mac-address";
+	};
+};
+
+&pcie1 {
+	wifi@0,0 {
+		compatible = "pci14c3,7663";
+		reg = <0x0 0 0 0 0>;
+
+		mediatek,mtd-eeprom = <&factory 0x8000>;
+		ieee80211-freq-limit = <5000000 6000000>;
+
+		nvmem-cells = <&macaddr_factory_8004>;
+		nvmem-cell-names = "mac-address";
+	};
+};
+
+&nand {
+	status = "okay";
+
+	partitions {
+		compatible = "fixed-partitions";
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		partition@0 {
+			label = "u-boot";
+			reg = <0x0 0x80000>;
+			read-only;
+		};
+
+		/* allow setting u-boot-env vars */
+		partition@80000 {
+			label = "u-boot-env";
+			reg = <0x80000 0x20000>;
+		};
+
+		factory: partition@100000 {
+			label = "factory";
+			reg = <0x100000 0x40000>;
+			read-only;
+		};
+
+		/* convert firmware1 from stock to ubi */
+		ubiconcat0: partition@140000 {
+			label = "ubiconcat0";
+			reg = <0x140000 0x26c0000>;
+		};
+
+		/* set kernel mtdsize to 4MB */
+		partition@2800000 {
+			label = "kernel";
+			reg = <0x2800000 0x400000>;
+		};
+
+		/* convert firmware2, ota from stock to ubi */
+		ubiconcat1: partition@2c00000 {
+			label = "ubiconcat1";
+			reg = <0x2c00000 0x5300000>;
+		};
+
+		partition@7f00000 {
+			label = "configbak";
+			reg = <0x7f00000 0x80000>;
+			read-only;
+		};
+
+		/* BBT probably contained in the last 0x80000 or 512K bytes */
+	};
+};
+
+&switch0 {
+	ports {
+		port@1 {
+			status = "okay";
+			label = "lan2";
+		};
+
+		port@2 {
+			status = "okay";
+			label = "lan3";
+		};
+
+		port@3 {
+			status = "okay";
+			label = "lan4";
+		};
+	};
+};
+
+&ethernet {
+	pinctrl-0 = <&mdio_pins>, <&rgmii1_pins>;
+};
+
+&gmac0 {
+	nvmem-cells = <&macaddr_factory_4>;
+	nvmem-cell-names = "mac-address";
+	mac-address-increment = <1>;
+};
+
+&gmac1 {
+	status = "okay";
+	label = "wan";
+	phy-handle = <&ethphy0>;
+
+	nvmem-cells = <&macaddr_factory_4>;
+	nvmem-cell-names = "mac-address";
+	mac-address-increment = <2>;
+};
+
+&mdio {
+	ethphy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
+
+&factory {
+	compatible = "nvmem-cells";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	/* WLAN24 MAC address */
+	macaddr_factory_4: macaddr@4 {
+		reg = <0x4 0x6>;
+	};
+
+	/* WLAN5 MAC address */
+	macaddr_factory_8004: macaddr@8004 {
+		reg = <0x8004 0x6>;
+	};
+};
diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index aa7adeee60..5570c93223 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -1451,6 +1451,21 @@  define Device/netis_wf2881
  endef
  TARGET_DEVICES += netis_wf2881

+define Device/notion_r281-mtd5
+  $(Device/dsa-migration)
+  BLOCKSIZE := 128k
+  PAGESIZE := 2048
+  KERNEL_SIZE := 4096k
+  IMAGE_SIZE := 129792k
+  UBINIZE_OPTS := -E 5
+  IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
+  DEVICE_VENDOR := Notion
+  DEVICE_MODEL := R281 (mtd5)
+  DEVICE_PACKAGES := kmod-usb3 kmod-mt7603 kmod-mt7615e 
kmod-mt7663-firmware-ap \
+    kmod-usb-net-rndis kmod-usb-acm comgt-ncm uboot-envtools
+endef
+TARGET_DEVICES += notion_r281-mtd5
+
  define Device/oraybox_x3a
    $(Device/dsa-migration)
    $(Device/uimage-lzma-loader)
diff --git 
a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network 
b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
index 29336bad68..a44fb414f4 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
@@ -77,6 +78,9 @@  ramips_setup_interfaces()
  	mikrotik,routerboard-760igs)
  		ucidef_set_interfaces_lan_wan "lan2 lan3 lan4 lan5" "wan sfp"
  		;;
+	notion,r281-mtd5)
+		ucidef_set_interfaces_lan_wan "lan2 lan3 lan4" "wan"
+		;;
  	tplink,eap235-wall-v1|\
  	tplink,eap615-wall-v1)
  		ucidef_set_interface_lan "lan0 lan1 lan2 lan3"
diff --git 
a/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
index b4dc34fbec..d9dd2c9423 100755
--- a/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
@@ -84,6 +84,7 @@  platform_do_upgrade() {
  	netgear,wac104|\
  	netgear,wac124|\
  	netis,wf2881|\
+	notion,r281-mtd5|\
  	raisecom,msg1500-x-00|\
  	sercomm,na502|\
  	sercomm,na502s|\