Re: Status of snapshot builds for omap target

[INAGAKI Hiroshi]

Hi Raylynn,

On 2024/04/11 15:57, Raylynn Knight wrote:

Hiroshi,

I’m late responding also so no problem.

On Apr 8, 2024, at 9:48 PM, INAGAKI Hiroshi  wrote:

Hi Raylynn,

sorry for late reply.

 From my understanding...

On 2024/04/05 4:42, Raylynn Knight via openwrt-devel wrote:

If I understand the issue correctly then it does not affect two of the four 
currently supported devices (i.e. it only affects Beaglebone Black and AM335x 
EVM and not BeagleBoard or PandaBoard).  Is that correct?

Yes, all devices that has the ethernet port(s) provided by TI OMAP SoC are 
affected. Currently, ti_am335x-evm and ti_am335x-bone-black.

So can we re-enable the target and disable the affected devices?


I think that's one way to keep omap target as available as possible. 
However, I don't know what OpenWrt's team members will think...



Is the proposed correction a change to the device tree for all devices that 
have the 'dual-emac-pvid’ node?

Yes. but unfortunately, changing dual-emac-pvid is also not a fundamental fix since it 
also occupies VLAN ID(s)... But of course, reverting back to the old "cpsw" 
driver doesn't solve for devices that has 2x ethernet ports.


None of the devices currently supported have 2 ethernet ports.  I’m not aware 
of any popular device for this target that does have multiple ports.  The 
Netgate SG-1000 and the Olimex AM3352-SOM-EVB are the only devices I’m aware of 
that have 2 ports and they have no where near the popularity of the various 
Beagleboard devices.


Yes. I've opened (but closed) a PR for adding support of Century 
Systems MA-E350/N (AM3352), but it's probably completely unknown 
outside of Japan. ;)




Ray



Cheers,
Hiroshi


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Status of snapshot builds for omap target

[INAGAKI Hiroshi]

Hi Raylynn,

sorry for late reply.

From my understanding...

On 2024/04/05 4:42, Raylynn Knight via openwrt-devel wrote:
If I understand the issue correctly then it does not affect two of the 
four currently supported devices (i.e. it only affects Beaglebone 
Black and AM335x EVM and not BeagleBoard or PandaBoard).  Is that 
correct?


Yes, all devices that has the ethernet port(s) provided by TI OMAP SoC 
are affected. Currently, ti_am335x-evm and ti_am335x-bone-black.




Is the proposed correction a change to the device tree for all devices 
that have the 'dual-emac-pvid’ node?


Yes. but unfortunately, changing dual-emac-pvid is also not a 
fundamental fix since it also occupies VLAN ID(s)... But of course, 
reverting back to the old "cpsw" driver doesn't solve for devices that 
has 2x ethernet ports.



Ray
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Best,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek/rtl839x: Edgecore ECS4100-12PH support

[INAGAKI Hiroshi]

Hi stijn,

I have some comments below.

On 2024/04/04 23:28, st...@linux-ipv6.be wrote:

Add support for the Edgecore ECS4100-12PH, an 8-port PoE Gigabit
Ethernet switch with 2 combo RJ45/SFP and 2 SFP ports.

Hardware:
* SoC: RTL8392M
* RAM: 256MiB
* Flash: 32MiB SPI-NOR
* Ethernet:
   * 8x GbE RJ45 PoE (built-in RTL8218B)
   * 2x GbE RJ45 / SFP combo
   * 2x SFP
* Console: RJ45 RS232 port on front panel
* PoE: Nuvoton M0516 + 2x Broadcom BCM59121 PSE

Installation via bootloader:
* open serial console (baud rate 115200)
* interrupt boot process by pressing any key during boot
* boot the OpenWrt initramfs:
   # rtk network on
   # setenv bootcmd 'mtdparts default;sf probe 0;sf read  0x8100 0x0020 
0x40;bootm'
   # tftpboot 0x8f00 
/tftpboot/openwrt-realtek-rtl839x-edgecore_ecs4100-12ph-initramfs-kernel.bin
   # bootm
* copy openwrt-realtek-rtl839x-edgecore_ecs4100-12ph-squashfs-sysupgrade.bin
   to /tmp and use sysupgrade to install it:
   # sysupgrade 
/tmp/openwrt-realtek-rtl839x-edgecore_ecs4100-12ph-squashfs-sysupgrade.bin

Signed-off-by: Stijn Tintel 
---
I took the DTS from the TIP OpenWiFi project. It was introduced in the
initial commit of their Github repo [1]. I added gpio1 and
label-mac-device, and changed rtl838x-soc in the compatible line to
rtl839x-soc. The info page and photo on svanheule's website suggest
RTL8392M, while my units use RTL8393M. My units have the exact same P/N
and revision on the PCB as in the photo. Since there appear to be units
based on RTL8392M, I'll keep the original DTS filename unless someone
tells me otherwise.

All 4 SFP slots seem to detect SFP insertion and removal, however I
didn't manage to get a link on either of the ports. As I have very
limited experience with SFP/fiber on Linux, I'd appreciate some guidance
on how to test this properly.

[1] 
https://github.com/Telecominfraproject/wlan-ap/commit/528a778e3864064bfccd8295abd1ec23da778843
---
  package/boot/uboot-envtools/files/realtek |   1 +
  .../realtek/base-files/etc/board.d/02_network |   7 +-
  .../rtl8392_edgecore_ecs4100-12ph.dts | 305 ++
  target/linux/realtek/image/rtl839x.mk |   8 +
  4 files changed, 318 insertions(+), 3 deletions(-)
  create mode 100644 
target/linux/realtek/dts-5.15/rtl8392_edgecore_ecs4100-12ph.dts

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index cd2446432d..4137133061 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -37,6 +37,7 @@ zyxel,gs1900-24hp-v2)
[ -n "$idx2" ] && \
ubootenv_add_uci_sys_config "/dev/mtd$idx2" "0x0" "0x1000" 
"0x1"
;;
+edgecore,ecs4100-12ph|\
  tplink,sg2008p-v1|\
  tplink,sg2210p-v3|\
  tplink,sg2452p-v4)
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
b/target/linux/realtek/base-files/etc/board.d/02_network
index db1d99f4ec..b41eb59b2b 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -80,6 +80,10 @@ d-link,dgs-1210-28mp-f)
ucidef_set_poe 370 "lan8 lan7 lan6 lan5 lan4 lan3 lan2 lan1 lan16 lan15 
lan14 lan13 lan12 lan11 lan10 lan9 lan24 lan23
lan22 lan21 lan20 lan19 lan18 lan17"
;;
+edgecore,ecs4100-12ph|\
+netgear,gs110tpp-v1)
+   ucidef_set_poe 130 "$(filter_port_list "$lan_list" "lan9 lan10")"
+   ;;
  engenius,ews2910p)
ucidef_set_poe 60 "$(filter_port_list "$lan_list" "lan9 lan10")"
;;
@@ -89,9 +93,6 @@ hpe,1920-8g-poe-65w)
  hpe,1920-8g-poe-180w)
ucidef_set_poe 180 "$(filter_port_list_reversed "$lan_list" "lan9 
lan10")"
;;
-netgear,gs110tpp-v1)
-   ucidef_set_poe 130 "$(filter_port_list "$lan_list" "lan9 lan10")"
-   ;;
  netgear,gs110tup-v1)
ucidef_set_poe 240 "$(filter_port_list "$lan_list" "lan9 lan10")"
;;
diff --git a/target/linux/realtek/dts-5.15/rtl8392_edgecore_ecs4100-12ph.dts 
b/target/linux/realtek/dts-5.15/rtl8392_edgecore_ecs4100-12ph.dts
new file mode 100644
index 00..067bf24f5a
--- /dev/null
+++ b/target/linux/realtek/dts-5.15/rtl8392_edgecore_ecs4100-12ph.dts
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "rtl839x.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "edgecore,ecs4100-12ph", "realtek,rtl839x-soc";
+   model = "Edgecore ECS4100-12PH Switch";
+
+   aliases {
+   label-mac-device = ðernet0;
+   led-boot = &led_sys;
+   led-failsafe = &led_sys;
+   led-running = &led_sys;
+   led-upgrade = &led_sys;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+gpio1: rtl8231-gpio {
+compatible = "realtek,rtl8231-gpio";
+#gpio-c

Re: Status of snapshot builds for omap target

[INAGAKI Hiroshi]

Hi Raylynn,

omap target was disabled due to the VLAN issue on using cpsw-switch driver.

see details: https://github.com/openwrt/openwrt/issues/11953

On 2024/04/02 13:52, Raylynn Knight via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Best,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mtdsplit_uimage: Split also after offsetted uImage

[INAGAKI Hiroshi]

Hello Linus,

This is just a question: doesn't it work with "openwrt,offset" 
property of mtdsplit_uimage parser instead of modifying that parser?


I'm thinking like the following:

- dts:

partition@1 {
    compatible = "openwrt,uimage", "denx,uimage";
    reg = <0x01 0xfe>;
    openwrt,offset = <0x2>;
    label = "firmware";
};

- image/Makefile:

IMAGE/sysupgrade.bin := cfe-bin-uboot | pad-to 128k | \
    append-kernel | pad-to (($$(BLOCKSIZE))) | \
    append-rootfs | append-metadata


Thanks,

Hiroshi

On 2024/01/24 7:17, Linus Walleij wrote:

The uImage splitter recognizes a rootfs either:

1. Right after the uImage if it comes first in the
partition or
2. Before the uImage if it is located at an offset
inside the partition.

Add a third case:

3. After the uImage also at an offset inside the
partition, if and only if 1 and 2 fails.

The reason why this is needed is because on the
BCM6328-based Inteno XG6846 we need to put a small
U-Boot binary first in the partition, then the uImage,
then the rootfs.

The U-Boot binary that comes first cannot be split off
into its own partition in this case because it needs
to be part of the bigger "firmware" partition. Which
we use for installation and upgrades.

Signed-off-by: Linus Walleij 
---
  .../files/drivers/mtd/mtdsplit/mtdsplit_uimage.c  | 19 +++
  1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c 
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
index a3e55fb1fe38..de043fb9f702 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
+++ b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
@@ -217,11 +217,22 @@ static int __mtdsplit_parse_uimage(struct mtd_info 
*master,
if (ret) {
pr_debug("no rootfs before uImage in \"%s\"\n",
 master->name);
-   goto err_free_buf;
-   }
  
-		rootfs_offset = 0;

-   rootfs_size = uimage_offset;
+   /* Try after the uImage */
+   ret = mtd_find_rootfs_from(master, uimage_offset + 
uimage_size,
+  master->size, &rootfs_offset, 
&type);
+   if (ret) {
+   pr_debug("no rootfs after uImage either in 
\"%s\"\n",
+master->name);
+   goto err_free_buf;
+   }
+
+   rootfs_size = master->size - rootfs_offset;
+   uimage_size = rootfs_offset - uimage_offset;
+   } else {
+   rootfs_offset = 0;
+   rootfs_size = uimage_offset;
+   }
}
  
  	if (rootfs_size == 0) {


---
base-commit: 1b7e62b20b1735fcdc498a35e005afcd775abcf4
change-id: 20240123-offsetted-uimage-splitter-f5b65f0df2ed

Best regards,


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] mvebu: cortexa9: enable Ethernet PHY LED trigger

[INAGAKI Hiroshi]

To use :: trigger for LEDs, enable PHY LED trigger
(CONFIG_LED_TRIGGER_PHY).

Signed-off-by: INAGAKI Hiroshi 
---
 target/linux/mvebu/cortexa9/config-5.15 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/mvebu/cortexa9/config-5.15 
b/target/linux/mvebu/cortexa9/config-5.15
index b737c44d42..88a2f14c02 100644
--- a/target/linux/mvebu/cortexa9/config-5.15
+++ b/target/linux/mvebu/cortexa9/config-5.15
@@ -1,2 +1,3 @@
+CONFIG_LED_TRIGGER_PHY=y
 CONFIG_PHY_MVEBU_A38X_COMPHY=y
 CONFIG_RTC_DRV_MV=y
-- 
2.39.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] mvebu: use PHY LED trigger for speed LEDs on FortiGate 50E

[INAGAKI Hiroshi]

Use :: trigger instead of netdev(link) trigger for
Fortinet FortiGate 50E, to indicate link speed on the each phys.

1000 Mbps: Green
100 Mbps : Amber
10 Mbps  : (turn off)

Fixes: 102dc5a62506 ("mvebu: add support for Fortinet FortiGate 50E")

Signed-off-by: INAGAKI Hiroshi 
---
 .../mvebu/cortexa9/base-files/etc/board.d/01_leds|  9 -
 .../arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts | 12 
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds 
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
index bfc589e6c0..2b045d0945 100644
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
@@ -15,15 +15,6 @@ ctera,c200-v2)
ucidef_set_led_usbport "usb2" "USB2" "green:usb-2" "usb1-port1" 
"usb2-port1"
ucidef_set_led_usbport "usb3" "USB3" "green:usb-1" "usb1-port2" 
"usb2-port2"
;;
-fortinet,fg-50e)
-   ucidef_set_led_netdev "wan1_link" "WAN1 Link" "green:speed_wan1" "eth1" 
"link"
-   ucidef_set_led_netdev "wan2_link" "WAN2 Link" "green:speed_wan2" "eth2" 
"link"
-   ucidef_set_led_netdev "lan1_link" "LAN1 Link" "green:speed_lan1" "lan1" 
"link"
-   ucidef_set_led_netdev "lan2_link" "LAN2 Link" "green:speed_lan2" "lan2" 
"link"
-   ucidef_set_led_netdev "lan3_link" "LAN3 Link" "green:speed_lan3" "lan3" 
"link"
-   ucidef_set_led_netdev "lan4_link" "LAN4 Link" "green:speed_lan4" "lan4" 
"link"
-   ucidef_set_led_netdev "lan5_link" "LAN5 Link" "green:speed_lan5" "lan5" 
"link"
-   ;;
 kobol,helios4)
ucidef_set_led_usbport "USB" "USB" "helios4:green:usb" "usb1-port1" 
"usb2-port1" "usb3-port1" "usb4-port1" "usb5-port1"
;;
diff --git 
a/target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts 
b/target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts
index 506e01f0ff..61d2da1755 100644
--- a/target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts
+++ b/target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts
@@ -97,72 +97,84 @@
label = "green:speed_wan1";
gpios = <&gpio2 0 GPIO_ACTIVE_HIGH>;
color = ;
+   linux,default-trigger = "f1072004.mdio-mii:00:1Gbps";
};
 
led-7 {
label = "green:speed_wan2";
gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
color = ;
+   linux,default-trigger = "f1072004.mdio-mii:01:1Gbps";
};
 
led-8 {
label = "amber:speed_lan5";
gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
color = ;
+   linux,default-trigger = "mv88e6xxx-1:00:100Mbps";
};
 
led-9 {
label = "green:speed_lan5";
gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
color = ;
+   linux,default-trigger = "mv88e6xxx-1:00:1Gbps";
};
 
led-10 {
label = "green:speed_lan4";
gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
color = ;
+   linux,default-trigger = "mv88e6xxx-1:01:1Gbps";
};
 
led-11 {
label = "amber:speed_lan4";
gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
color = ;
+   linux,default-trigger = "mv88e6xxx-1:01:100Mbps";
};
 
led-12 {
label = "amber:speed_lan3";
gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
color = ;
+   linux,default-trigger = "mv88e6xxx-1:02:100Mbps";
};
 
led-13 {
label = "green:speed_lan3";
gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;
color = ;
+ 

[PATCH 0/2] mvebu: use PHY LED trigger "SPEED" LEDs on FortiGate 50E

[INAGAKI Hiroshi]

Enable PHY LED trigger on mvebu/cortexa9 and use it for each "SPEED" LEDs
on Fortinet FortiGate 50E to indicate 100M/1000M link speed on each ports.

When I add the support for 50E, I forgot that trigger and set netdev(link)
trigger for green:speed_* LEDs instead.
But I recently noticed PHY LED trigger which can be used to indicate link
speed (100M/1000M), so replace the default trigger to it.

INAGAKI Hiroshi (2):
  mvebu: cortexa9: enable Ethernet PHY LED trigger
  mvebu: use PHY LED trigger for speed LEDs on FortiGate 50E

 .../mvebu/cortexa9/base-files/etc/board.d/01_leds|  9 -
 target/linux/mvebu/cortexa9/config-5.15  |  1 +
 .../arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts | 12 
 3 files changed, 13 insertions(+), 9 deletions(-)

-- 
2.39.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3] mvebu: add support for Fortinet FortiGate 50E

[INAGAKI Hiroshi]

Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820).

Specification:

- SoC  : Marvell Armada 385 88F6820
- RAM  : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ")
- Flash: SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- Ethernet : 7x 10/100/1000 Mbps
  - LAN 1-5: Marvell 88E6176
  - WAN 1, 2   : Marvell 88E1512 (2x)
- LEDs/Keys: 18x/1x
- UART : "CONSOLE" port (RJ-45, RS-232C level)
  - port   : ttyS0
  - settings   : 9600bps 8n1
  - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
 5:GND, 6:RXD, 7:NC , 8:NC
  - note   : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power: 12 VDC, 2 A
  - plug   : Molex 5557-02R

Flash instruction using initramfs image:

1. Power on FG-50E and interrupt to show bootmenu
2. Call "[R]: Review TFTP parameters.", check TFTP parameters and
   connect computer to "Image download port" in the parameters
3. Prepare TFTP server with the parameters obtained above
4. Rename OpenWrt initramfs image to "image.out" and put to TFTP
   directory
5. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
   image from TFTP server
6. Type "r" key when the following message is showed, to boot initramfs
   image without flashing to spi-nor flash

   "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"

7. On initramfs image, backup mtd if needed

   minimum:

   - "firmware-info"
   - "kernel"
   - "rootfs"

7. On initramfs image, upload sysupgrade image to the device and perform
   sysupgrade
8. Wait ~200 seconds to complete flashing and rebooting.
   If the device is booted with stock firmware, login to bootmenu and
   call "[B]: Boot with backup firmware and set as default." to set the
   first OS image as default and boot it.

Notes:

- All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of
  WAN1/2 are connected to GPIO expander. There is no way to indicate
  link speed of networking device on Linux Kernel/OpenWrt, so those LEDs
  cannot be handled like stock firmware.
  On OpenWrt, use netdev(link) trigger instead.

- Both colors of Bi-color LEDs on the front panel cannot be turned on at
  the same time.

- "PWR" and "Logo" LEDs are connected to power source directly.

- The following partitions are added for OpenWrt.
  These partitions are contained in "uboot" partition (0x0-0x1f) on
  stock firmware.

  - "firmware-info"
  - "dtb"
  - "u-boot-env"
  - "board-info"

Image header for bootmenu tftp:

  0x0 - 0xf  : ?
 0x10 - 0x2f : Image Name
 0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?

*: required for initramfs image

MAC addresses:

(eth0): 70:4C:A5:xx:xx:7C (board-info, 0xd880 (hex))
WAN 1 : 70:4C:A5:xx:xx:7D
WAN 2 : 70:4C:A5:xx:xx:7E
LAN 1 : 70:4C:A5:xx:xx:7F
LAN 2 : 70:4C:A5:xx:xx:80
LAN 3 : 70:4C:A5:xx:xx:81
LAN 4 : 70:4C:A5:xx:xx:82
LAN 5 : 70:4C:A5:xx:xx:83

Signed-off-by: INAGAKI Hiroshi 
---
v2 -> v3

- use netdev(link) trigger for all green:speed_* leds
  - update note in the commit message
- fix typo in the commit message

v1 -> v2

- fix baudrate in the commit message
- add missing chip count of RAM in the commit message

 .../cortexa9/base-files/etc/board.d/01_leds   |   9 +
 .../base-files/etc/board.d/02_network |   3 +
 .../base-files/lib/upgrade/fortinet.sh|  54 ++
 .../base-files/lib/upgrade/platform.sh|   3 +
 .../boot/dts/armada-385-fortinet-fg-50e.dts   | 491 ++
 target/linux/mvebu/image/cortexa9.mk  |  28 +
 6 files changed, 588 insertions(+)
 create mode 100644 
target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh
 create mode 100644 
target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts

diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds 
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
index 2b045d0945..bfc589e6c0 100644
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
@@ -15,6 +15,15 @@ ctera,c200-v2)
ucidef_set_led_usbport "usb2" "USB2" "green:usb-2" "usb1-port1" 
"usb2-port1"
ucidef_set_led_usbport "usb3" "USB3" "green:usb-1" "usb1-port2" 
"usb2-port2"
;;
+fortinet,fg-50e)
+   ucidef_set_led_netdev "wan1_link" "WAN1 Link" "green:speed_wan1" "eth1" 
"link"
+   ucidef_

Re: [PATCH v2] mvebu: add support for Fortinet FortiGate 50E

[INAGAKI Hiroshi]

Hi Hauke,

thank you for your review.

On 2023/03/06 1:42, Hauke Mehrtens wrote:

On 3/1/23 17:01, INAGAKI Hiroshi wrote:

Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820).




Notes:

- All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of
   WAN1/2 are connected to GPIO expander. There is no way to indicate
   link speed of networking device, so those LEDs cannot be used like
   stock firmware.


I think you can use the ledtrig-netdev to activate the LEDs on link up 
if they are connected to the nxp,pca9555 GPIO extender.


I didn't think about it since "LINK/ACT" LEDs already indicate link up, 
but it certainly might be a good alternative for "SPEED" LEDs.





- Both colors of Bi-color LEDs on the front panel cannot be turned on at
   the same time.

- "PWR" and "Logo" LEDs are connected to power source directory.

- The following partitions are added for OpenWrt.
   These partitions are contained in "uboot" partition (0x0-0x1f) on
   stock firmware.

   - "firmware-info"
   - "dtb"
   - "u-boot-env"
   - "board-info"


.

  +define Device/fortinet_fg-50e
+  DEVICE_VENDOR := Fortinet
+  DEVICE_MODEL := FortiGate 50E
+  SOC := armada-385
+  KERNEL := kernel-bin | append-dtb
+  KERNEL_INITRAMFS := kernel-bin | append-dtb | fortigate-header | \
+    gzip-filename FGT50E
+  KERNEL_SIZE := 6144k
+  DEVICE_DTS := armada-385-fortinet-fg-50e
+  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | \
+    sysupgrade-tar rootfs=@ | append-metadata
+  DEVICE_PACKAGES := kmod-hwmon-nct7802


Why don't you add the driver for the GPIO extender kmod-gpio-pca953x 
here?


CONFIG_GPIO_PCA953X (and irq option) is enabled in mvebu/config-5.15[1], 
so I didn't add that package.


[1]: 
https://github.com/openwrt/openwrt/blob/a03076cc392b67c8342aac2017f8ac903c983e59/target/linux/mvebu/config-5.15#L191-L192





+endef
+TARGET_DEVICES += fortinet_fg-50e
+
  define Device/globalscale_mirabox
    $(Device/NAND-512K)
    DEVICE_VENDOR := Globalscale




Regards,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] mvebu: add support for Fortinet FortiGate 50E

[INAGAKI Hiroshi]

Hi Mark,

On 2023/03/02 4:47, Mark Thurston wrote:


   On Wed, 01 Mar 2023 16:01:50 +  INAGAKI Hiroshi  wrote ---
  > Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820).
  >
  > Specification:
  >
  > - SoC  : Marvell Armada 385 88F6820
  > - RAM  : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ")
  > - Flash: SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
  > - Ethernet : 7x 10/100/1000 Mbps
  >   - LAN 1-5: Marvell 88E6176
  >   - WAN 1, 2   : Marvell 88E1512 (2x)
  > - LEDs/Keys: 18x/1x
  > - UART : "CONSOLE" port (RJ-45, RS-232C level)
  >   - port   : ttyS0
  >   - settings   : 9600bps 8n1
  >   - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
  >  5:GND, 6:RXD, 7:NC , 8:NC
  >   - note   : compatible with Cisco console cable
  > - HW Monitoring: nuvoTon NCT7802Y
  > - Power: 12 VDC, 2 A
  >   - plug   : Molex 5557-02R

I couldn't find the Fortinet FortiGate 50E in the table of hardware.
Would you like to add it? If not, should I add it based on your description? (I 
don't have one of these to hand to confirm details).
https://openwrt.org/supported_devices/adding_to_toh


As for adding to ToH, I hadn't thought of anything yet.
For me, it doesn't matter which one... I'll leave it up to you to decide :)

BTW, adding entry to ToH should be done after the support is merged...

Thanks,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] mvebu: add support for Fortinet FortiGate 50E

[INAGAKI Hiroshi]

Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820).

Specification:

- SoC  : Marvell Armada 385 88F6820
- RAM  : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ")
- Flash: SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- Ethernet : 7x 10/100/1000 Mbps
  - LAN 1-5: Marvell 88E6176
  - WAN 1, 2   : Marvell 88E1512 (2x)
- LEDs/Keys: 18x/1x
- UART : "CONSOLE" port (RJ-45, RS-232C level)
  - port   : ttyS0
  - settings   : 9600bps 8n1
  - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
 5:GND, 6:RXD, 7:NC , 8:NC
  - note   : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power: 12 VDC, 2 A
  - plug   : Molex 5557-02R

Flash instruction using initramfs image:

1. Power on FG-50E and interrupt to show bootmenu
2. Call "[R]: Review TFTP parameters.", check TFTP parameters and
   connect computer to "Image download port" in the parameters
3. Prepare TFTP server with the parameters obtained above
4. Rename OpenWrt initramfs image to "image.out" and put to TFTP
   directory
5. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
   image from TFTP server
6. Type "r" key when the following message is showed, to boot initramfs
   image without flashing to spi-nor flash

   "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"

7. On initramfs image, backup mtd if needed

   minimum:

   - "firmware-info"
   - "kernel"
   - "rootfs"

7. On initramfs image, upload sysupgrade image to the device and perform
   sysupgrade
8. Wait ~200 seconds to complete flashing and rebooting.
   If the device is booted with stock firmware, login to bootmenu and
   call "[B]: Boot with backup firmware and set as default." to set the
   first OS image as default and boot it.

Notes:

- All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of
  WAN1/2 are connected to GPIO expander. There is no way to indicate
  link speed of networking device, so those LEDs cannot be used like
  stock firmware.

- Both colors of Bi-color LEDs on the front panel cannot be turned on at
  the same time.

- "PWR" and "Logo" LEDs are connected to power source directory.

- The following partitions are added for OpenWrt.
  These partitions are contained in "uboot" partition (0x0-0x1f) on
  stock firmware.

  - "firmware-info"
  - "dtb"
  - "u-boot-env"
  - "board-info"

Image header for bootmenu tftp:

  0x0 - 0xf  : ?
 0x10 - 0x2f : Image Name
 0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?

*: required for initramfs image

MAC addresses:

(eth0): 70:4C:A5:xx:xx:7C (board-info, 0xd880 (hex))
WAN 1 : 70:4C:A5:xx:xx:7D
WAN 2 : 70:4C:A5:xx:xx:7E
LAN 1 : 70:4C:A5:xx:xx:7F
LAN 2 : 70:4C:A5:xx:xx:80
LAN 3 : 70:4C:A5:xx:xx:81
LAN 4 : 70:4C:A5:xx:xx:82
LAN 5 : 70:4C:A5:xx:xx:83

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2

- fix baudrate in the commit message
- add missing chip count of RAM in the commit message

 .../base-files/etc/board.d/02_network |   3 +
 .../base-files/lib/upgrade/fortinet.sh|  54 ++
 .../base-files/lib/upgrade/platform.sh|   3 +
 .../boot/dts/armada-385-fortinet-fg-50e.dts   | 491 ++
 target/linux/mvebu/image/cortexa9.mk  |  28 +
 5 files changed, 579 insertions(+)
 create mode 100644 
target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh
 create mode 100644 
target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts

diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network 
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
index d2229fe6bf..9db29d52df 100644
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
@@ -18,6 +18,9 @@ mvebu_setup_interfaces()
cznic,turris-omnia)
ucidef_set_interfaces_lan_wan "lan0 lan1 lan2 lan3 lan4" "eth2"
;;
+   fortinet,fg-50e)
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5" "eth1 
eth2"
+   ;;
iptime,nas1dual)
ucidef_set_interface_lan "eth0 eth1" "dhcp"
;;
diff --git a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh 
b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh
new file mode 100644
index 00..a2742aa374
--- /dev/null
+++ b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh
@@ -0,0 +1

Re: [PATCH] mvebu: add support for Fortinet FortiGate 50E

[INAGAKI Hiroshi]

On 2023/03/02 0:29, INAGAKI Hiroshi wrote:

Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820).

Specification:

- SoC  : Marvell Armada 385 88F6820
- RAM  : DDR3 2 GiB (Micron MT41K512M8DA-107, "D9SGQ")
- Flash: SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- Ethernet : 7x 10/100/1000 Mbps
   - LAN 1-5: Marvell 88E6176
   - WAN 1, 2   : Marvell 88E1512 (2x)
- LEDs/Keys: 18x/1x
- UART : "CONSOLE" port (RJ-45, RS-232C level)
   - port   : ttyS0
   - settings   : 115200 8n1


Ahh, it's 9600bps, not 115200...
I'll fix this and re-send, please ignore this patch...sorry.


   - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
  5:GND, 6:RXD, 7:NC , 8:NC
   - note   : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power: 12 VDC, 2 A
   - plug   : Molex 5557-02R


Regards,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] mvebu: add support for Fortinet FortiGate 50E

[INAGAKI Hiroshi]

Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820).

Specification:

- SoC  : Marvell Armada 385 88F6820
- RAM  : DDR3 2 GiB (Micron MT41K512M8DA-107, "D9SGQ")
- Flash: SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- Ethernet : 7x 10/100/1000 Mbps
  - LAN 1-5: Marvell 88E6176
  - WAN 1, 2   : Marvell 88E1512 (2x)
- LEDs/Keys: 18x/1x
- UART : "CONSOLE" port (RJ-45, RS-232C level)
  - port   : ttyS0
  - settings   : 115200 8n1
  - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
 5:GND, 6:RXD, 7:NC , 8:NC
  - note   : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power: 12 VDC, 2 A
  - plug   : Molex 5557-02R

Flash instruction using initramfs image:

1. Power on FG-50E, interrupt and show bootmenu
2. Call "[R]: Review TFTP parameters.", check TFTP parameters and
   connect computer to "Image download port" in the parameters
3. Prepare TFTP server with the parameters obtained above
4. Rename OpenWrt initramfs image to "image.out" and put to TFTP
   directory
5. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
   image from TFTP server
6. Type "r" key when the following message is showed, to boot initramfs
   image without flashing to spi-nor flash

   "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"

7. On initramfs image, backup mtd if needed

   minimum:

   - "firmware-info"
   - "kernel"
   - "rootfs"

7. On initramfs image, upload sysupgrade image to the device and perform
   sysupgrade
8. Wait ~200 seconds to complete flashing and rebooting.
   If the device is booted with stock firmware, login to bootmenu and
   call "[B]: Boot with backup firmware and set as default.".

Notes:

- All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of
  WAN1/2 are connected to GPIO expander. There is no way to indicate
  link speed of networking device, so those LEDs cannot be used like
  stock firmware.

- Both colors of Bi-color LEDs on the front panel cannot be turned on at
  the same time.

- "PWR" and "Logo" LEDs are connected to power source directory.

- The following partitions are added for OpenWrt.
  These partitions are contained in "uboot" partition (0x0-0x1f) on
  stock firmware.

  - "firmware-info"
  - "dtb"
  - "u-boot-env"
  - "board-info"

Image header for bootmenu tftp:

  0x0 - 0xf  : ?
 0x10 - 0x2f : Image Name
 0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?

*: required for initramfs image

MAC addresses:

(eth0): 70:4C:A5:xx:xx:7C (board-info, 0xd880 (hex))
WAN 1 : 70:4C:A5:xx:xx:7D
WAN 2 : 70:4C:A5:xx:xx:7E
LAN 1 : 70:4C:A5:xx:xx:7F
LAN 2 : 70:4C:A5:xx:xx:80
LAN 3 : 70:4C:A5:xx:xx:81
LAN 4 : 70:4C:A5:xx:xx:82
LAN 5 : 70:4C:A5:xx:xx:83

Signed-off-by: INAGAKI Hiroshi 
---
 .../base-files/etc/board.d/02_network |   3 +
 .../base-files/lib/upgrade/fortinet.sh|  54 ++
 .../base-files/lib/upgrade/platform.sh|   3 +
 .../boot/dts/armada-385-fortinet-fg-50e.dts   | 491 ++
 target/linux/mvebu/image/cortexa9.mk  |  28 +
 5 files changed, 579 insertions(+)
 create mode 100644 
target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh
 create mode 100644 
target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts

diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network 
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
index d2229fe6bf..9db29d52df 100644
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
@@ -18,6 +18,9 @@ mvebu_setup_interfaces()
cznic,turris-omnia)
ucidef_set_interfaces_lan_wan "lan0 lan1 lan2 lan3 lan4" "eth2"
;;
+   fortinet,fg-50e)
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5" "eth1 
eth2"
+   ;;
iptime,nas1dual)
ucidef_set_interface_lan "eth0 eth1" "dhcp"
;;
diff --git a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh 
b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh
new file mode 100644
index 00..a2742aa374
--- /dev/null
+++ b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh
@@ -0,0 +1,54 @@
+. /lib/functions.sh
+
+fortinet_fwinfo_blocks() {
+   local fwinfo_mtd="$(find_mtd_part firmware-info)"
+   local offset="$1&quo

[PATCH v2] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR

[INAGAKI Hiroshi]

Use ARTIFACTS to generate initramfs-based factory image of I-O DATA
WN-AX1167GR instead of redundant recipe which generate on
KERNEL_INITRAMFS.

Note:

WN-AX1167GR has 2x OS images on stock firmware.

stock log:

flash manufacture id: c2, device id 20 18
MX25L12805D(c2 2018c220) (16384 Kbytes)
mtd .name = raspi, .size = 0x0100 (16M) .erasesize = 0x0001 (64K) 
.numeraseregions = 0
Creating 10 MTD partitions on "raspi":
0x-0x0100 : "ALL"
0x-0x0003 : "Bootloader"
0x0003-0x0004 : "Config "
0x0004-0x0005 : "Factory"
0x0005-0x0006 : "iNIC_rf"
0x0006-0x007e : "Kernel"
0x0080-0x00f8 : "app"
0x00f9-0x00fa : "Key"
0x00fa-0x00fb : "backup"
0x00fb-0x0100 : "storage"

1st image is "Kernel" and 2nd is "app" when booted from 1st image.
In OpenWrt, those 2x partitions are combined to "firmware" with
undefined (empty) areas (0x7e-0x7f, 0xf8-0xf8).

The size of an OS image partition is 0x78 (7680 KiB = 7.5 MiB), so
check-size for initramfs-factory image needs to be called with the size.

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2

- update for IB
  - use append-image-stage instead of append-image
  - drop ifneq-endif switch of CONFIG_TARGET_ROOTFS_INITRAMFS

 target/linux/ramips/image/mt7621.mk | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index 943fc62ecd..3e6c8d8a84 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -49,23 +49,6 @@ define Build/haier-sim_wr1800k-factory
   $(CP) $(1) $(BIN_DIR)/
 endef
 
-define Build/iodata-factory
-   $(eval fw_size=$(word 1,$(1)))
-   $(eval fw_type=$(word 2,$(1)))
-   $(eval product=$(word 3,$(1)))
-   $(eval factory_bin=$(word 4,$(1)))
-   if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) -a "$$(stat -c%s $@)" -lt 
"$(fw_size)" ]; then \
-   $(CP) $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) $(factory_bin); \
-   $(STAGING_DIR_HOST)/bin/mksenaofw \
-   -r 0x30a -p $(product) -t $(fw_type) \
-   -e $(factory_bin) -o $(factory_bin).new; \
-   mv $(factory_bin).new $(factory_bin); \
-   $(CP) $(factory_bin) $(BIN_DIR)/; \
-   else \
-   echo "WARNING: initramfs kernel image too big, cannot generate 
factory image (actual $$(stat -c%s $@); max $(fw_size))" >&2; \
-   fi
-endef
-
 define Build/iodata-mstc-header
( \
data_size_crc="$$(dd if=$@ ibs=64 skip=1 2>/dev/null | gzip -c 
| \
@@ -972,10 +955,11 @@ define Device/iodata_wn-ax1167gr
   $(Device/dsa-migration)
   $(Device/uimage-lzma-loader)
   IMAGE_SIZE := 15552k
-  KERNEL_INITRAMFS := $$(KERNEL) | \
-   iodata-factory 7864320 4 0x1055 
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.bin
   DEVICE_VENDOR := I-O DATA
   DEVICE_MODEL := WN-AX1167GR
+  ARTIFACTS := initramfs-factory.bin
+  ARTIFACT/initramfs-factory.bin := append-image-stage initramfs-kernel.bin | \
+   check-size 7680k | senao-header -r 0x30a -p 0x1055 -t 4
   DEVICE_PACKAGES := kmod-mt7603 kmod-mt76x2
 endef
 TARGET_DEVICES += iodata_wn-ax1167gr
-- 
2.36.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR

[INAGAKI Hiroshi]

On 2022/11/30 0:30, Daniel Golle wrote:

On Tue, Nov 29, 2022 at 11:10:22PM +0900, INAGAKI Hiroshi wrote:

[...]
This seems to be caused by "image" directory in
staging_dir/target-mipsel_24kc_musl/ not existing, and when I created that
folder manually the build succeeded.

---
user@hostmachine:/openwrt/user/git/musashino-build/openwrt$ mkdir
staging_dir/target-mipsel_24kc_musl/image
user@hostmachine:/openwrt/user/git/musashino-build/openwrt$ make -j8 V=s
...
(completed without errors)
---

Should I add a patch to create "image" directory before copying?

I've sent out a patch adding this to include/image-commands.mk.
Can you check if that fixes the issue for you?


Thank you for your fix!
I tested compilation with your patch and the following steps, the 
issue was solved :)


$ make clean  # to delete manually created "image" directory
$ make -j8 V=s

I'll prepare v2 patch.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR

[INAGAKI Hiroshi]

On 2022/11/29 22:04, Daniel Golle wrote:

On Tue, Nov 29, 2022 at 09:30:25PM +0900, INAGAKI Hiroshi wrote:

Hi Daniel,

thank you for your review.

On 2022/11/29 11:07, Daniel Golle wrote:

On Wed, Nov 23, 2022 at 12:24:09PM +0900, INAGAKI Hiroshi wrote:

...

@@ -972,10 +955,13 @@ define Device/iodata_wn-ax1167gr
 $(Device/dsa-migration)
 $(Device/uimage-lzma-loader)
 IMAGE_SIZE := 15552k
-  KERNEL_INITRAMFS := $$(KERNEL) | \
-   iodata-factory 7864320 4 0x1055 
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.bin
 DEVICE_VENDOR := I-O DATA
 DEVICE_MODEL := WN-AX1167GR
+ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
+  ARTIFACTS := initramfs-factory.bin
+  ARTIFACT/initramfs-factory.bin := append-image initramfs-kernel.bin | \

Please use 'append-image-stage' so this will work also with the
ImageBuilder where initramfs is not being generated/present.

Oh, I didn't know it. Then, should I remove ifneq-endif switch for IB?

Yes, you should also drop the ifneq-endif for IB.


Okay, I'll drop ifneq-endif and send the next version.

BTW, when I compiled images of WN-AX1167GR only with 
'append-image-stage', the following errors were printed and 
compilation failed.


---
cp 
"/openwrt/user/git/musashino-build/openwrt/bin/targets/ramips/mt7621/openwrt-ramips-mt7621-iodata_wn-ax1167gr-initramfs-kernel.bin" 
"/openwrt/user/git/musashino-build/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-iodata_wn-ax1167gr-initramfs-factory.bin.stripmeta"
fwtool -s /dev/null -t 
"/openwrt/user/git/musashino-build/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-iodata_wn-ax1167gr-initramfs-factory.bin.stripmeta" 
|| :

Data not found
fwtool -i /dev/null -t 
"/openwrt/user/git/musashino-build/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-iodata_wn-ax1167gr-initramfs-factory.bin.stripmeta" 
|| :

Data not found
dd 
if="/openwrt/user/git/musashino-build/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-iodata_wn-ax1167gr-initramfs-factory.bin.stripmeta" 
of="/openwrt/user/git/musashino-build/openwrt/staging_dir/target-mipsel_24kc_musl/image/ramips-mt7621-iodata_wn-ax1167gr-initramfs-kernel.bin"
dd: failed to open 
'/openwrt/user/git/musashino-build/openwrt/staging_dir/target-mipsel_24kc_musl/image/ramips-mt7621-iodata_wn-ax1167gr-initramfs-kernel.bin': 
No such file or directory
make[5]: *** [Makefile:230: 
/openwrt/user/git/musashino-build/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-iodata_wn-ax1167gr-initramfs-factory.bin] 
Error 1
make[5]: Leaving directory 
'/openwrt/user/git/musashino-build/openwrt/target/linux/ramips/image'

make[4]: *** [Makefile:23: install] Error 2
make[4]: Leaving directory 
'/openwrt/user/git/musashino-build/openwrt/target/linux/ramips'

make[3]: *** [Makefile:11: install] Error 2
make[3]: Leaving directory 
'/openwrt/user/git/musashino-build/openwrt/target/linux'

time: target/linux/install#28.28#3.36#18.20
    ERROR: target/linux failed to build.
make[2]: *** [target/Makefile:30: target/linux/install] Error 1
make[2]: Leaving directory '/openwrt/user/git/musashino-build/openwrt'
make[1]: *** [target/Makefile:24: 
/openwrt/user/git/musashino-build/openwrt/staging_dir/target-mipsel_24kc_musl/stamp/.target_install] 
Error 2

make[1]: Leaving directory '/openwrt/user/git/musashino-build/openwrt'
make: *** 
[/openwrt/user/git/musashino-build/openwrt/include/toplevel.mk:231: 
world] Error 2

---

This seems to be caused by "image" directory in 
staging_dir/target-mipsel_24kc_musl/ not existing, and when I created 
that folder manually the build succeeded.


---
user@hostmachine:/openwrt/user/git/musashino-build/openwrt$ mkdir 
staging_dir/target-mipsel_24kc_musl/image

user@hostmachine:/openwrt/user/git/musashino-build/openwrt$ make -j8 V=s
...
(completed without errors)
---

Should I add a patch to create "image" directory before copying?




+   check-size 7680k | senao-header -r 0x30a -p 0x1055 -t 4
+endif
 DEVICE_PACKAGES := kmod-mt7603 kmod-mt76x2
   endef
   TARGET_DEVICES += iodata_wn-ax1167gr
--
2.36.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR

[INAGAKI Hiroshi]

Hi Daniel,

thank you for your review.

On 2022/11/29 11:07, Daniel Golle wrote:

On Wed, Nov 23, 2022 at 12:24:09PM +0900, INAGAKI Hiroshi wrote:

...

@@ -972,10 +955,13 @@ define Device/iodata_wn-ax1167gr
$(Device/dsa-migration)
$(Device/uimage-lzma-loader)
IMAGE_SIZE := 15552k
-  KERNEL_INITRAMFS := $$(KERNEL) | \
-   iodata-factory 7864320 4 0x1055 
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.bin
DEVICE_VENDOR := I-O DATA
DEVICE_MODEL := WN-AX1167GR
+ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
+  ARTIFACTS := initramfs-factory.bin
+  ARTIFACT/initramfs-factory.bin := append-image initramfs-kernel.bin | \

Please use 'append-image-stage' so this will work also with the
ImageBuilder where initramfs is not being generated/present.


Oh, I didn't know it. Then, should I remove ifneq-endif switch for IB?




+   check-size 7680k | senao-header -r 0x30a -p 0x1055 -t 4
+endif
DEVICE_PACKAGES := kmod-mt7603 kmod-mt76x2
  endef
  TARGET_DEVICES += iodata_wn-ax1167gr
--
2.36.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR

[INAGAKI Hiroshi]

Use ARTIFACTS to generate initramfs-based factory image of I-O DATA
WN-AX1167GR instead of redundant recipe which generate on
KERNEL_INITRAMFS.

Note:

WN-AX1167GR has 2x OS images on stock firmware.

stock log:

flash manufacture id: c2, device id 20 18
MX25L12805D(c2 2018c220) (16384 Kbytes)
mtd .name = raspi, .size = 0x0100 (16M) .erasesize = 0x0001 (64K) 
.numeraseregions = 0
Creating 10 MTD partitions on "raspi":
0x-0x0100 : "ALL"
0x-0x0003 : "Bootloader"
0x0003-0x0004 : "Config "
0x0004-0x0005 : "Factory"
0x0005-0x0006 : "iNIC_rf"
0x0006-0x007e : "Kernel"
0x0080-0x00f8 : "app"
0x00f9-0x00fa : "Key"
0x00fa-0x00fb : "backup"
0x00fb-0x0100 : "storage"

1st image is "Kernel" and 2nd is "app" when booted from 1st image.
In OpenWrt, those 2x partitions are combined to "firmware" with
undefined (empty) areas (0x7e-0x7f, 0xf8-0xf8).

The size of an OS image partition is 0x78 (7680 KiB = 7.5 MiB), so
check-size for initramfs-factory image needs to be called with the size.

Signed-off-by: INAGAKI Hiroshi 
---
 target/linux/ramips/image/mt7621.mk | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index 943fc62ecd..0e3f1cf0f5 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -49,23 +49,6 @@ define Build/haier-sim_wr1800k-factory
   $(CP) $(1) $(BIN_DIR)/
 endef
 
-define Build/iodata-factory
-   $(eval fw_size=$(word 1,$(1)))
-   $(eval fw_type=$(word 2,$(1)))
-   $(eval product=$(word 3,$(1)))
-   $(eval factory_bin=$(word 4,$(1)))
-   if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) -a "$$(stat -c%s $@)" -lt 
"$(fw_size)" ]; then \
-   $(CP) $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) $(factory_bin); \
-   $(STAGING_DIR_HOST)/bin/mksenaofw \
-   -r 0x30a -p $(product) -t $(fw_type) \
-   -e $(factory_bin) -o $(factory_bin).new; \
-   mv $(factory_bin).new $(factory_bin); \
-   $(CP) $(factory_bin) $(BIN_DIR)/; \
-   else \
-   echo "WARNING: initramfs kernel image too big, cannot generate 
factory image (actual $$(stat -c%s $@); max $(fw_size))" >&2; \
-   fi
-endef
-
 define Build/iodata-mstc-header
( \
data_size_crc="$$(dd if=$@ ibs=64 skip=1 2>/dev/null | gzip -c 
| \
@@ -972,10 +955,13 @@ define Device/iodata_wn-ax1167gr
   $(Device/dsa-migration)
   $(Device/uimage-lzma-loader)
   IMAGE_SIZE := 15552k
-  KERNEL_INITRAMFS := $$(KERNEL) | \
-   iodata-factory 7864320 4 0x1055 
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.bin
   DEVICE_VENDOR := I-O DATA
   DEVICE_MODEL := WN-AX1167GR
+ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
+  ARTIFACTS := initramfs-factory.bin
+  ARTIFACT/initramfs-factory.bin := append-image initramfs-kernel.bin | \
+   check-size 7680k | senao-header -r 0x30a -p 0x1055 -t 4
+endif
   DEVICE_PACKAGES := kmod-mt7603 kmod-mt76x2
 endef
 TARGET_DEVICES += iodata_wn-ax1167gr
-- 
2.36.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: mark clock source as continuous

[INAGAKI Hiroshi]

Hi Sander,

thanks for the patch!

I tested on my Panasonic Switch-M48eG PN28480K (RTL8393M) and all 
issues are solved :)


- top page loading of LuCI (WebUI) at login: 2.64 s
- ethtool lanX (10x times): avg 0.00 s, max 0.01 s
- /proc/interrupts (per (about) 1s):
  root@OpenWrt:/# while :; do grep "timer" /proc/interrupts; echo 
"---"; sleep 1; done

   28:  0 388182  realtek-rtl-intc  28  timer@3100
   29:    1179094  0  realtek-rtl-intc  29  timer@3100
  ---
   28:  0 388632  realtek-rtl-intc  28  timer@3100
   29:    1181698  0  realtek-rtl-intc  29  timer@3100
  ---
   28:  0 389094  realtek-rtl-intc  28  timer@3100
   29:    1184276  0  realtek-rtl-intc  29  timer@3100
  ---
   28:  0 389350  realtek-rtl-intc  28  timer@3100
   29:    1185182  0  realtek-rtl-intc  29  timer@3100
  ---
   28:  0 389651  realtek-rtl-intc  28  timer@3100
   29:    1186753  0  realtek-rtl-intc  29  timer@3100
  ---
- bootlog:
https://gist.github.com/musashino205/2aa32ff858d863de9790c75c3a0b5bf8

  (without the patch):
https://gist.github.com/musashino205/0db98d9f99fbacc8a311f65739b72eb7

Thanks,
Hiroshi

On 2022/10/31 18:11, Sander Vanheule wrote:

After replacing the R4K event timer and clock source with the new
Realtek Otto timer, performance for RTL839x devices was severely
impacted, as reported by Hiroshi.

Research by Markus showed that after commit 4657a5301eb5 (realtek: avoid
busy waiting for RTL839x PHY read/write, 2022-10-14), the ethernet
driver could only update a phy once per timer interval, which also
heavily impacted boot time. On e.g. a Zyxel GS1900-48, this added around
a minute to the time to fully initialise the switch.

By marking the otto clocksource as continuous, the kernel enables it to
be used for high resolution timers. This allows readx_poll_timeout() to
sleep for less than one system timer interval, reducing system dead
time.

Link: https://github.com/openwrt/openwrt/issues/7
Reported-by: INAGAKI Hiroshi 
Cc: Markus Stockhausen 
Signed-off-by: Sander Vanheule 
---
With this patch, initialisation time for my GS1900-48 drops from 110
seconds to 50 seconds. Please check if you can reproduce this. The 'why
this works' from the commit message is from a quick look at the places
where this CLOCK_SOURCE flag is checked, so I hope it actually makes sense.

Best,
Sander

  .../realtek/files-5.10/drivers/clocksource/timer-rtl-otto.c  | 1 +
  1 file changed, 1 insertion(+)

diff --git 
a/target/linux/realtek/files-5.10/drivers/clocksource/timer-rtl-otto.c 
b/target/linux/realtek/files-5.10/drivers/clocksource/timer-rtl-otto.c
index 12eed78653d0..14e28e50f40e 100644
--- a/target/linux/realtek/files-5.10/drivers/clocksource/timer-rtl-otto.c
+++ b/target/linux/realtek/files-5.10/drivers/clocksource/timer-rtl-otto.c
@@ -227,6 +227,7 @@ struct rttm_cs rttm_cs = {
.name   = "realtek_otto_timer",
.rating = 400,
.mask   = CLOCKSOURCE_MASK(RTTM_BIT_COUNT),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
.read   = rttm_read_clocksource,
.enable = rttm_enable_clocksource
}


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] ipq40xx: add support for Sony NCP-HG100/Cellular

[INAGAKI Hiroshi]

8] sdhci_msm 7824900.sdhci: Card stuck in wrong state! 
card_busy_detect status: 0xe00
  [   17.446910] mmc0: tuning execution failed: -5
  [   17.447111] mmc0: cache flush error -110
  [   18.012440] F2FS-fs (mmcblk0p17): Found nat_bits in checkpoint
  [   18.062652] F2FS-fs (mmcblk0p17): Mounted with checkpoint version = 
428fa16b
  [   18.198691] block: attempting to load /etc/config/fstab
  [   18.198972] block: unable to load configuration (fstab: Entry not found)
  [   18.203029] block: no usable configuration
  [   18.211371] mount_root: overlay filesystem has not been fully initialized 
yet
  [   18.214487] mount_root: switching to f2fs overlay

  So, this support uses ext4 format instead which has no errors.

Note:

- The primary uart is shared for debug console and Z-Wave chip. The
  function is switched by GPIO15 (Linux: 427).

  value:

1: debug console
0: Z-Wave

- NCP-HG100/Cellular has 2x os-image pairs in eMMC.

  - 0:HLOS, rootfs
  - 0:HLOS_1, rootfs_1

  In OpenWrt, the first image pair is used.

- "bootipq" command in U-Boot requires authentication with signed-image
  by default. To boot unsigned image of OpenWrt, use "mmc read" and
  "bootm" command instead.

- This support is for "Cellular" variant of NCP-HG100 and not tested on
  "WLAN" (non-cellular) variant.

- The board files of ipq-wifi may also be used in "WLAN" variant of
  NCP-HG100, but unconfirmed and add files as for "Cellular" variant.

- "NET" LED is used to indicate WWAN status in stock firmware.

- There is no MAC address information in the label on the case, use the
  address included in UUID in the label as "label-MAC" instead.

- The "CLOUD" LEDs are partially used for indication of system status in
  stock firmware, use they as status LEDs in OpenWrt instead of RGB LED
  connected to the MCU.

MAC addresses:

LAN: 5C:FF:35:**:**:ED (ART, 0x6(hex))
WAN: 5C:FF:35:**:**:EF (ART, 0x0(hex))
2.4 GHz: 5C:FF:35:**:**:ED (ART, 0x1006 (hex))
5 GHz  : 5C:FF:35:**:**:EE (ART, 0x5006 (hex))

partition layout in eMMC (by fdisk, GPT):

Disk /dev/mmcblk0: 7733248 sectors, 3776M
Logical sector size: 512
Disk identifier (GUID): 
Partition table holds up to 20 entries
First usable sector is 34, last usable sector is 7634910

Number  Start (sector)End (sector)  Size Name
 1  341057  512K 0:SBL1
 210582081  512K 0:BOOTCONFIG
 320823105  512K 0:QSEE
 431064129  512K 0:QSEE_1
 541304641  256K 0:CDT
 646425153  256K 0:CDT_1
 751546177  512K 0:BOOTCONFIG1
 861786689  256K 0:APPSBLENV
 966908737 1024K 0:APPSBL
108738   10785 1024K 0:APPSBL_1
11   10786   11297  256K 0:ART
12   11298   11809  256K 0:HSEE
13   11810   28193 8192K 0:HLOS
14   28194   44577 8192K 0:HLOS_1
15   44578  306721  128M rootfs
16  306722  568865  128M rootfs_1
17  568866 3958065 1654M rootfs_data

[initial work]
Signed-off-by: Iwao Yuki 
Co-developed-by: Iwao Yuki 
[adjustments, cleanups, commit message, sending patch]
Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop "qcom,ipq4019" from root compatible
- update sdhci node and add emmc node
- specify gpio15 (Linux: 427) as configurable pin in 03_gpio_switches
- add notes about gpio pin of debug/zwave switching and MCU-controlled fan to
  commit message

 package/firmware/ipq-wifi/Makefile|   2 +
 .../board-sony_ncp-hg100-cellular.qca4019 | Bin 0 -> 24340 bytes
 .../ipq40xx/base-files/etc/board.d/01_leds|   5 +
 .../ipq40xx/base-files/etc/board.d/02_network |   3 +-
 .../base-files/etc/board.d/03_gpio_switches   |   3 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   6 +
 .../base-files/lib/upgrade/platform.sh|   3 +
 .../ipq40xx/base-files/lib/upgrade/sony.sh|  91 +++
 .../dts/qcom-ipq4019-ncp-hg100-cellular.dts   | 641 ++
 target/linux/ipq40xx/image/generic.mk |  13 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 12 files changed, 770 insertions(+), 3 deletions(-)
 create mode 100644 
package/firmware/ipq-wifi/board-sony_ncp-hg100-cellular.qca4019
 create mode 100644 target/linux/ipq40xx/base-files/lib/upgrade/sony.sh
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-ncp-hg100-cellular.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index ebd10cd2ec..812910c0c6 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -35,6 +35,7 @@ A

Re: [fstools v2 PATCH 1/2] partname: check all parameters for overriding if needed

[INAGAKI Hiroshi]

A, this series is not v2, it's v3... I mistook in the subject...

On 2022/07/02 15:48, INAGAKI Hiroshi wrote:

In bootargs, the specific parameter is overridden if needed for booting
OpenWrt, such as "root=".
In this case, the last specific parameter in bootargs should be read
instead of the one passed by bootloader.

example (I-O DATA HDL2-AAX):

console=ttyS0,115200 mtdparts=spi0.0:960k(boot),64k(env),-(system) \
   initrd=0x340 rw root=/dev/md2 rootfstype=ext4 rw rootdelay=2 \
   init=/lib/sysvinit/init init=/sbin/init root=PARTLABEL=rootfs \
   rootfstype=squashfs,ext4

- "root=/dev/md2": passed by bootloader, for stock firmware
- "root=PARTLABEL=rootfs": passed by dtb, for OpenWrt

So, this patch adds checking support for all parameters in the specified
file and check all for root device ("root=" parameter).

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

   (no patch)

v2 -> v3:

   - added patch to fix wrong detection of overridden root= parameter

  libfstools/partname.c | 17 ++---
  1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f59c52e..e282402 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -62,9 +62,9 @@ static int partname_volume_init(struct volume *v)
  }
  
  /* adapted from procd/utils.c -> should go to libubox */

-static char* get_var_from_file(const char* filename, const char* name, char* 
out, int len)
+static char* get_var_from_file(const char* filename, const char* name, char* 
out, int len, bool chk_all)
  {
-   char line[1024], *c, *sptr;
+   char line[1024], *c, *sptr, *_out = NULL;
int fd = open(filename, O_RDONLY);
if (fd == -1)
return NULL;
@@ -89,10 +89,13 @@ static char* get_var_from_file(const char* filename, const 
char* name, char* out
  
  		strncpy(out, &sep[1], len);

out[len-1] = '\0';
-   return out;
+   if (!chk_all)
+   return out;
+
+   _out = out;
}
  
-	return NULL;

+   return _out;
  }
  
  static char *rootdevname(char *devpath) {

@@ -123,12 +126,12 @@ static struct volume *partname_volume_find(char *name)
bool found = false;
glob_t gl;
  
-	if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", rootparam, sizeof(rootparam))) {

+   if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", 
rootparam, sizeof(rootparam), false)) {
if (!strcmp("1", rootparam))
return NULL;
}
  
-	if (get_var_from_file("/proc/cmdline", "root", rootparam, sizeof(rootparam))) {

+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam), true)) {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
@@ -139,7 +142,7 @@ static struct volume *partname_volume_find(char *name)
  
  	if (!glob(ueventgstr, GLOB_NOESCAPE, NULL, &gl))

for (j = 0; j < gl.gl_pathc; j++) {
-   if (!get_var_from_file(gl.gl_pathv[j], "PARTNAME", 
namebuf, sizeof(namebuf)))
+   if (!get_var_from_file(gl.gl_pathv[j], "PARTNAME", 
namebuf, sizeof(namebuf), false))
continue;
if (!strncmp(namebuf, name, sizeof(namebuf))) {
found = 1;


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[fstools v2 PATCH 2/2] partname: check "PARTLABEL" in root= parameter

[INAGAKI Hiroshi]

This patch adds "PARTLABEL=" checking of root= parameter to
partname_volume_find function.

The Linux Kernel supports "root=PARTLABEL=" syntax, but fstools
doesn't and fail to parse the path to the root device.
So check the parameter and skip parsing, find partition from all block
devices if this syntax is used.

Note:
This change is required for some NAS devices sold by I-O DATA, such as
HDL2-A and HDL2-AAX series.
On they, kernel and rootfs are stored in the storage device connected
to SATA, port1 or port2 and the path to the partition will be assigned
dynamically.
So "root=PARTLABEL=" syntax is required instead of "/dev/sdXN".

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

  - use "PARTLABEL=" string in root= parametr instead of the new fstools
parameter to block searching root device

v2 -> v3:

  - rebased on the first patch of this patch series

 libfstools/partname.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index e282402..8ccf12a 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -131,12 +131,13 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
 
-   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam), true)) {
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam), true) &&
+   strncmp(rootparam, "PARTLABEL=", 10)) {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
} else {
-   /* no 'root=' kernel cmdline parameter, find on any block 
device */
+   /* PARTLABEL= is specifed or no 'root=' kernel cmdline 
parameter, find on any block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
block_dir_name);
}
 
-- 
2.36.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[fstools v2 PATCH 1/2] partname: check all parameters for overriding if needed

[INAGAKI Hiroshi]

In bootargs, the specific parameter is overridden if needed for booting
OpenWrt, such as "root=".
In this case, the last specific parameter in bootargs should be read
instead of the one passed by bootloader.

example (I-O DATA HDL2-AAX):

console=ttyS0,115200 mtdparts=spi0.0:960k(boot),64k(env),-(system) \
  initrd=0x340 rw root=/dev/md2 rootfstype=ext4 rw rootdelay=2 \
  init=/lib/sysvinit/init init=/sbin/init root=PARTLABEL=rootfs \
  rootfstype=squashfs,ext4

- "root=/dev/md2": passed by bootloader, for stock firmware
- "root=PARTLABEL=rootfs": passed by dtb, for OpenWrt

So, this patch adds checking support for all parameters in the specified
file and check all for root device ("root=" parameter).

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

  (no patch)

v2 -> v3:

  - added patch to fix wrong detection of overridden root= parameter

 libfstools/partname.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f59c52e..e282402 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -62,9 +62,9 @@ static int partname_volume_init(struct volume *v)
 }
 
 /* adapted from procd/utils.c -> should go to libubox */
-static char* get_var_from_file(const char* filename, const char* name, char* 
out, int len)
+static char* get_var_from_file(const char* filename, const char* name, char* 
out, int len, bool chk_all)
 {
-   char line[1024], *c, *sptr;
+   char line[1024], *c, *sptr, *_out = NULL;
int fd = open(filename, O_RDONLY);
if (fd == -1)
return NULL;
@@ -89,10 +89,13 @@ static char* get_var_from_file(const char* filename, const 
char* name, char* out
 
strncpy(out, &sep[1], len);
out[len-1] = '\0';
-   return out;
+   if (!chk_all)
+   return out;
+
+   _out = out;
}
 
-   return NULL;
+   return _out;
 }
 
 static char *rootdevname(char *devpath) {
@@ -123,12 +126,12 @@ static struct volume *partname_volume_find(char *name)
bool found = false;
glob_t gl;
 
-   if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", 
rootparam, sizeof(rootparam))) {
+   if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", 
rootparam, sizeof(rootparam), false)) {
if (!strcmp("1", rootparam))
return NULL;
}
 
-   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam))) {
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam), true)) {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
@@ -139,7 +142,7 @@ static struct volume *partname_volume_find(char *name)
 
if (!glob(ueventgstr, GLOB_NOESCAPE, NULL, &gl))
for (j = 0; j < gl.gl_pathc; j++) {
-   if (!get_var_from_file(gl.gl_pathv[j], "PARTNAME", 
namebuf, sizeof(namebuf)))
+   if (!get_var_from_file(gl.gl_pathv[j], "PARTNAME", 
namebuf, sizeof(namebuf), false))
continue;
if (!strncmp(namebuf, name, sizeof(namebuf))) {
found = 1;
-- 
2.36.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ipq40xx: add support for Sony NCP-HG100/Cellular

[INAGAKI Hiroshi]

Hi Christian,

Thank you for your review.

On 2022/03/28 4:48, Christian Lamparter wrote:

Hi,

On Sun, Mar 27, 2022 at 10:22 AM INAGAKI Hiroshi
 wrote:

Sony NCP-HG100/Cellular is a IoT Gateway with 2.4/5 GHz band 11ac
(WiFi-5) wireless function, based on IPQ4019.

Specification:

- SoC   : Qualcomm IPQ4019
- RAM   : DDR3 512 MiB (H5TC4G63EFR)
- Flash : eMMC 4 GiB (THGBMNG5D1LBAIT)
- WLAN  : 2.4/5 GHz 2T2R (IPQ4019)
- Ethernet  : 10/100/1000 Mbps x2
   - Transceiver : Qualcomm QCA8072
- WWAN  : Telit LN940A9
- Z-Wave: Silicon Labs ZM5101
- Bluetooth : Qualcomm CSR8811
- Audio DAC : Realtek ALC5629
- Audio Amp.: Realtek ALC1304
- Voice Input Processor : Conexant CX20924
- Micro Controller Unit : Nuvoton MINI54FDE
   - RGB LED, Fan, Temp. sensors
- Touch Sensor  : Cypress CY8C4014LQI
- RGB LED driver: TI LP55231 (2x)
- LEDs/Keys : 11x, 6x
- UART  : through-hole on PCB
   - J1: 3.3V, TX, RX, GND from tri-angle marking
   - 115200n8
- Power : 12 VDC, 2.5 A

Flash instruction using initramfs image:

1. Prepare TFTP server with the IP address 192.168.132.100 and place the
initramfs image to TFTP directory with the name "C0A88401.img"

2. Boot NCP-HG100/Cellular and interrupt after the message
"Hit any key to stop autoboot:  2"

3. Perform the following commands and set bootcmd to allow booting from
eMMC

setenv bootcmd "mmc read 0x8400 0x2e22 0x4000 && bootm 0x8400"
saveenv

4. Perform the following command to load/boot the OpenWrt initramfs image

tftpboot && bootm

5. On the initramfs image, perform sysupgrade with the sysupgrade image
(if needed, backup eMMC partitions by dd command and download to
other place before performing sysupgrade)

6. Wait for ~120 seconds to complete flashing

Known issues:

- The primary uart is shared for debug console and Z-Wave chip. To use
   it for debug console on OpenWrt, Z-Wave chip cannot be used.

- There are no drivers for audio-related chips/functions in Linux Kernel
   and OpenWrt, they cannot be used.

- There is no driver for MINI54FDE Micro-Controller Unit, customized for
   this device by the firmware in the MCU. This chip controls the
   following functions, but they cannot be controlled in OpenWrt.

   - RGB LED
   - Fan
   - Thermal Sensors (2x)

Does the MCU do adequate thermal control even without input from the
kernel/userspace? Don't want to let it overheat.


It may be controlled automatically by default. However, so far I 
haven't done a rigorous test... I'll consider how to make sure.





- Currently, there is no driver or tool for CY8C4014LQI and cannot be
   controlled. It cannot be exited from "booting mode" and moved to "normal
   op mode" after booting. And also, the 4x buttons (mic mute, vol down,
   vol up, alexa trigger) connected to the IC cannot be controlled.

   - it can be exited from "booting mode" by installing and executing
 i2cset command:

 opkg update
 opkg install i2c-tools
 i2cset -y 1 0x14 0xf 1

- There is a connection issue on the control by uqmi for the WWAN module.
   But modemmanager can be used without any issues and the use of it is
   recommended.

- With the F2FS format, too many errors are reported on erasing eMMC
   partition "rootfs_data" while booting:

   [1.360270] sdhci: Secure Digital Host Controller Interface driver
   [1.363636] sdhci: Copyright(c) Pierre Ossman
   [1.369730] sdhci-pltfm: SDHCI platform and OF driver helper
   [1.374729] sdhci_msm 7824900.sdhci: Got CD GPIO
   ...
   [1.413552] mmc0: SDHCI controller on 7824900.sdhci [7824900.sdhci] using 
ADMA 64-bit
   [1.528325] mmc0: new HS200 MMC card at address 0001
   [1.530627] mmcblk0: mmc0:0001 004GA0 3.69 GiB
   [1.533530] mmcblk0boot0: mmc0:0001 004GA0 partition 1 2.00 MiB
   [1.537831] mmcblk0boot1: mmc0:0001 004GA0 partition 2 2.00 MiB
   [1.542918] mmcblk0rpmb: mmc0:0001 004GA0 partition 3 512 KiB, chardev 
(247:0)
   [1.550323] Alternate GPT is invalid, using primary GPT.
   [1.561669]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 
p16 p17
   ...
   [8.841400] mount_root: loading kmods from internal overlay
   [8.860241] kmodloader: loading kernel modules from //etc/modules-boot.d/*
   [8.863746] kmodloader: done loading kernel modules from 
//etc/modules-boot.d/*
   [9.240465] block: attempting to load /etc/config/fstab
   [9.246722] block: unable to load configuration (fstab: Entry not found)
   [9.246863] block: no usable configuration
   [9.254883] mount_root: overlay filesystem in /dev/mmcblk0p17 has not 
been formatted yet
   [9.438915] urandom_read: 5 callbacks suppressed
   [  

[PATCH] ipq40xx: add support for Sony NCP-HG100/Cellular

[INAGAKI Hiroshi]

mmc_erase: group start error -110, status 0x0
  [   17.439498] sdhci_msm 7824900.sdhci: Card stuck in wrong state! 
card_busy_detect status: 0xe00
  [   17.446910] mmc0: tuning execution failed: -5
  [   17.447111] mmc0: cache flush error -110
  [   18.012440] F2FS-fs (mmcblk0p17): Found nat_bits in checkpoint
  [   18.062652] F2FS-fs (mmcblk0p17): Mounted with checkpoint version = 
428fa16b
  [   18.198691] block: attempting to load /etc/config/fstab
  [   18.198972] block: unable to load configuration (fstab: Entry not found)
  [   18.203029] block: no usable configuration
  [   18.211371] mount_root: overlay filesystem has not been fully initialized 
yet
  [   18.214487] mount_root: switching to f2fs overlay

  So, this support uses ext4 format instead which has no errors.

Note:

- NCP-HG100/Cellular has 2x os-image pairs in eMMC.

  - 0:HLOS, rootfs
  - 0:HLOS_1, rootfs_1

  In OpenWrt, the first image pair is used.

- "bootipq" command in U-Boot requires authentication with signed-image
  by default. To boot unsigned image of OpenWrt, use "mmc read" and
  "bootm" command instead.

- This support is for "Cellular" variant of NCP-HG100 and not tested on
  "WLAN" (non-cellular) variant.

- The board files of ipq-wifi may also be used in "WLAN" variant of
  NCP-HG100, but unconfirmed and add files as for "Cellular" variant.

- "NET" LED is used to indicate WWAN status in stock firmware.

- There is no MAC address information in the label on the case, use the
  address included in UUID in the label as "label-MAC" instead.

- The "CLOUD" LEDs are partially used for indication of system status in
  stock firmware, use they as status LEDs in OpenWrt instead of RGB LED
  connected to the MCU.

MAC addresses:

LAN : 5C:FF:35:**:**:ED (ART, 0x6(hex))
WAN : 5C:FF:35:**:**:EF (ART, 0x0(hex))
2.4 GHz : 5C:FF:35:**:**:ED (ART, 0x1006 (hex))
5 GHz   : 5C:FF:35:**:**:EE (ART, 0x5006 (hex))

partition layout in eMMC (by fdisk, GPT):

Disk /dev/mmcblk0: 7733248 sectors, 3776M
Logical sector size: 512
Disk identifier (GUID): 
Partition table holds up to 20 entries
First usable sector is 34, last usable sector is 7634910

Number  Start (sector)End (sector)  Size Name
 1  341057  512K 0:SBL1
 210582081  512K 0:BOOTCONFIG
 320823105  512K 0:QSEE
 431064129  512K 0:QSEE_1
 541304641  256K 0:CDT
 646425153  256K 0:CDT_1
 751546177  512K 0:BOOTCONFIG1
 861786689  256K 0:APPSBLENV
 966908737 1024K 0:APPSBL
108738   10785 1024K 0:APPSBL_1
11   10786   11297  256K 0:ART
12   11298   11809  256K 0:HSEE
13   11810   28193 8192K 0:HLOS
14   28194   44577 8192K 0:HLOS_1
15   44578  306721  128M rootfs
16  306722  568865  128M rootfs_1
17  568866 3958065 1654M rootfs_data

[initial work]
Signed-off-by: Iwao Yuki 
Co-developed-by: Iwao Yuki 
[adjustments, cleanups, commit message, sending patch]
Signed-off-by: INAGAKI Hiroshi 
---
This is a continuation of the PR #4001[1] in GitHub.
The drivers for MCU are still missing and need to be controlled via
i2cset command.

[1]: https://github.com/openwrt/openwrt/pull/4001

 package/firmware/ipq-wifi/Makefile|   2 +
 .../board-sony_ncp-hg100-cellular.qca4019 | Bin 0 -> 24340 bytes
 .../ipq40xx/base-files/etc/board.d/01_leds|   5 +
 .../ipq40xx/base-files/etc/board.d/02_network |   3 +-
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   6 +
 .../base-files/lib/upgrade/platform.sh|   3 +
 .../ipq40xx/base-files/lib/upgrade/sony.sh|  91 +++
 .../dts/qcom-ipq4019-ncp-hg100-cellular.dts   | 635 ++
 target/linux/ipq40xx/image/generic.mk |  13 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 10 files changed, 759 insertions(+), 2 deletions(-)
 create mode 100644 
package/firmware/ipq-wifi/board-sony_ncp-hg100-cellular.qca4019
 create mode 100644 target/linux/ipq40xx/base-files/lib/upgrade/sony.sh
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-ncp-hg100-cellular.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index b3b04c6abf..372f2ba58a 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -57,6 +57,7 @@ ALLWIFIBOARDS:= \
plasmacloud_pa2200 \
qxwlan_e2600ac-c1 \
qxwlan_e2600ac-c2 \
+   sony_ncp-hg100-cellular \
teltonika_rutx \
zte_mf286d
 
@@ -151,6 +152,7 @@ $(eval $(call 
generate-ipq-wifi-package,plasmacloud_pa1200,Plasma Cloud PA1200))
 $(ev

Re: [PATCH v4 2/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Hi Sander,

Thank you for your review.

On 2022/03/13 19:41, Sander Vanheule wrote:

Hi Hiroshi,

On Wed, 2022-03-09 at 23:31 +0900, INAGAKI Hiroshi wrote:

Panasonic Switch-M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
   - port 1-8: TP, RTL8218B (SoC)
   - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
   - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
   - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
   - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
     the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
     and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
     image

     rtk network on
     tftpboot 0x8100
     bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
     filesystem in the flash

     ffsmount c:/
     ffsfmt c:/

     this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
     filesystem

     updatert 

     example:

   updatert pn28080k_v3.rom

     this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

     setenv loadaddr 0xb4e0
     setenv bootcmd bootm
     saveenv

10: Download the OpenWrt initramfs image and boot with it

     tftpboot 0x8100 0101A8C0.img
     bootm

11: On the initramfs image, download the sysupgrade image and perform
     sysupgrade with it

     sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
   Switch-M8eG has an another (old) model number ("PN28080"), it's not a
   Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
   GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
   fails to execute anything in "bootcmd" variable if the images are not
   exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
   firmware and it includes the stock images, configuration files and
   checksum files. It's unknown format, can't be managed on the OpenWrt.
   To get the enough space for OpenWrt, move the filesystem to the head
   of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

- On the other devices in the same series of Switch-M8eG PN28080K, the
   INT pin on the PCA9555 is not connected to anywhere.

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

    on U-Boot:

  setenv loadaddr
  setenv bootcmd 'bootm 0x8100'

    on OpenWrt:

  fw_setenv loadaddr
      fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

   on U-Boot:

     reset

   on OpenWrt:

     reboot

Signed-off-by: INAGAKI Hiroshi 

I still have one minor question and a small remark below, but otherwise this 
seems
good to me.

Reviewed-by: Sander Vanheule 


---
v1 -> v2:

- drop changes for kernel 5.4
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
   - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
   LEDs
- drop unnecessary default values from gpio-restart node

v2 -> v3:

- move interrupt related properties in PCA9539 to device dts
- move child i2c bus definitions in PCA9545 to device dts
- use actual SoC name "rtl8380" in second compatible of root

v3 -> v4:

- drop unnecessary "/delete-node/" of rtl8231 from dtsi

  .../rtl8380_panasonic_m8eg-pn28080k.dts   | 133 
  .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 195 ++
  target/linux/realtek/image/rtl838x.mk |  10 +
  3 files changed, 338 insertions(+)
  create mode 100644 target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-
pn28080k.dts
  create mode 100644 target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-
pn28xx0k.dtsi

diff --git a/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
new file mode 100644
index 000

[PATCH fstools v2] partname: check "PARTLABEL" in root= parameter

[INAGAKI Hiroshi]

This patch adds "PARTLABEL=" checking of root= parameter to
partname_volume_find function.

The Linux Kernel supports "root=PARTLABEL=" syntax, but fstools
doesn't and fail to parse the path to the root device.
So check the parameter and skip parsing, find partition from all block
devices if this syntax is used.

Note:
This change is required for I-O DATA HDL-A/HDL2-A. On they, kernel and
rootfs are stored in the storage device connected to SATA, port1 or
port2 and the path to the partition will be assigned dynamically. So
"root=PARTLABEL=" syntax is required instead of "/dev/sdXN".

Signed-off-by: INAGAKI Hiroshi 
---
 libfstools/partname.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f59c52e..fd499c7 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -128,12 +128,13 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
 
-   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam))) {
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam)) &&
+   strncmp(rootparam, "PARTLABEL=", 10)) {
rootdev = rootdevname(rootparam);
-   /* find partition on same device as rootfs */
+   /* root= is not PARTLABEL, find partition on same device as 
rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
} else {
-   /* no 'root=' kernel cmdline parameter, find on any block 
device */
+   /* PARTLABEL or no 'root=' kernel cmdline parameter, find on 
any block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
block_dir_name);
}
 
-- 
2.34.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH fstools] partname: add "fstools_use_partlabel" option to find part from label

[INAGAKI Hiroshi]

Hi Daniel,

Thank you for your review.

On 2022/03/12 19:57, Daniel Golle wrote:

On Sat, Mar 12, 2022 at 01:05:17PM +0900, INAGAKI Hiroshi wrote:

This patch adds "fstools_use_partlabel" option to partname driver.

The Linux Kernel supports "root=PARTLABEL=" syntax, but fstools
doesn't and fail to parse the path to the root device.
To use this syntax, add the option and find from all block devices.

Note:
This change is required for I-O DATA HDL-A/HDL2-A. On they, kernel and
rootfs are stored in the storage device connected to SATA, port1 or
port2 and the path to the partition will be assigned dynamically. So
"root=PARTLABEL=" syntax is required instead of "/dev/sdXN".

Signed-off-by: INAGAKI Hiroshi 
---
  libfstools/partname.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f59c52e..7e57311 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -121,6 +121,7 @@ static struct volume *partname_volume_find(char *name)
char *rootdev = NULL, *devname, *tmp;
int j;
bool found = false;
+   bool use_label = false;
glob_t gl;
  
  	if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", rootparam, sizeof(rootparam))) {

@@ -128,12 +129,17 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
  
-	if (get_var_from_file("/proc/cmdline", "root", rootparam, sizeof(rootparam))) {

+   if (get_var_from_file("/proc/cmdline", "fstools_use_partlabel", 
rootparam, sizeof(rootparam)))
+   if (!strcmp("1", rootparam))
+   use_label = true;
+
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, sizeof(rootparam)) 
&&
+   !use_label) {

Wouldn't it be easier to use strncmp() to match the PARTLABEL= prefix
in string stored at rootparam? In that case you won't have to introduce
a new 'fstools_use_partlabel' parameter and achieve the same result.



Ah indeed, you are right.

I'll update the patch and re-send.


rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
} else {
-   /* no 'root=' kernel cmdline parameter, find on any block 
device */
+   /* no 'root=' kernel cmdline parameter or use_label=true, find 
on any block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
block_dir_name);
}
  
--

2.34.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Thanks,
Hiroshi


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH fstools] partname: add "fstools_use_partlabel" option to find part from label

[INAGAKI Hiroshi]

This patch adds "fstools_use_partlabel" option to partname driver.

The Linux Kernel supports "root=PARTLABEL=" syntax, but fstools
doesn't and fail to parse the path to the root device.
To use this syntax, add the option and find from all block devices.

Note:
This change is required for I-O DATA HDL-A/HDL2-A. On they, kernel and
rootfs are stored in the storage device connected to SATA, port1 or
port2 and the path to the partition will be assigned dynamically. So
"root=PARTLABEL=" syntax is required instead of "/dev/sdXN".

Signed-off-by: INAGAKI Hiroshi 
---
 libfstools/partname.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f59c52e..7e57311 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -121,6 +121,7 @@ static struct volume *partname_volume_find(char *name)
char *rootdev = NULL, *devname, *tmp;
int j;
bool found = false;
+   bool use_label = false;
glob_t gl;
 
if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", 
rootparam, sizeof(rootparam))) {
@@ -128,12 +129,17 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
 
-   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam))) {
+   if (get_var_from_file("/proc/cmdline", "fstools_use_partlabel", 
rootparam, sizeof(rootparam)))
+   if (!strcmp("1", rootparam))
+   use_label = true;
+
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam)) &&
+   !use_label) {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
} else {
-   /* no 'root=' kernel cmdline parameter, find on any block 
device */
+   /* no 'root=' kernel cmdline parameter or use_label=true, find 
on any block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
block_dir_name);
}
 
-- 
2.34.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v4 2/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Panasonic Switch-M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
  - port 1-8: TP, RTL8218B (SoC)
  - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
  - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
  - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
  - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
image

rtk network on
tftpboot 0x8100
bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
filesystem in the flash

ffsmount c:/
ffsfmt c:/

this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
filesystem

updatert 

example:

  updatert pn28080k_v3.rom

this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

setenv loadaddr 0xb4e0
setenv bootcmd bootm
saveenv

10: Download the OpenWrt initramfs image and boot with it

tftpboot 0x8100 0101A8C0.img
bootm

11: On the initramfs image, download the sysupgrade image and perform
sysupgrade with it

sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
  Switch-M8eG has an another (old) model number ("PN28080"), it's not a
  Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
  GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
  fails to execute anything in "bootcmd" variable if the images are not
  exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
  firmware and it includes the stock images, configuration files and
  checksum files. It's unknown format, can't be managed on the OpenWrt.
  To get the enough space for OpenWrt, move the filesystem to the head
  of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

- On the other devices in the same series of Switch-M8eG PN28080K, the
  INT pin on the PCA9555 is not connected to anywhere.

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

   on U-Boot:

 setenv loadaddr
 setenv bootcmd 'bootm 0x8100'

   on OpenWrt:

 fw_setenv loadaddr
 fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

  on U-Boot:

reset

  on OpenWrt:

reboot

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes for kernel 5.4
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
  - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
  LEDs
- drop unnecessary default values from gpio-restart node

v2 -> v3:

- move interrupt related properties in PCA9539 to device dts
- move child i2c bus definitions in PCA9545 to device dts
- use actual SoC name "rtl8380" in second compatible of root

v3 -> v4:

- drop unnecessary "/delete-node/" of rtl8231 from dtsi

 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 133 
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 195 ++
 target/linux/realtek/image/rtl838x.mk |  10 +
 3 files changed, 338 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

diff --git a/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts 
b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
new file mode 100644
index 00..f9d58f5b66
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl838x.dtsi"
+#include "rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi"
+
+#include 
+
+/ {
+   compatible = "panasonic,m8eg-p

[PATCH v4 1/2] realtek: enable pca953x driver for rtl838x subtarget

[INAGAKI Hiroshi]

The system status LED on Panasonic Switch-M8eG PN28080K is connected to
a PCA9539PW. To use the LED as a status LED of OpenWrt while booting,
enable the pca953x driver and built-in to the kernel.
Also enable CONFIG_GPIO_PCA953X_IRQ to use interrupt via RTL83xx GPIO.

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes in config-5.4
- enable CONFIG_GPIO_PCA953X_IRQ to use interrupt

v2 -> v3:

(no changes)

v3 -> v4:

- update the title of this commit

 target/linux/realtek/rtl838x/config-5.10 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/realtek/rtl838x/config-5.10 
b/target/linux/realtek/rtl838x/config-5.10
index 1252aab11e..8e27af95ba 100644
--- a/target/linux/realtek/rtl838x/config-5.10
+++ b/target/linux/realtek/rtl838x/config-5.10
@@ -69,6 +69,8 @@ CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_GENERIC=y
+CONFIG_GPIO_PCA953X=y
+CONFIG_GPIO_PCA953X_IRQ=y
 CONFIG_GPIO_REALTEK_OTTO=y
 CONFIG_GPIO_RTL8231=y
 CONFIG_GRO_CELLS=y
@@ -166,6 +168,7 @@ CONFIG_REALTEK_OTTO_WDT=y
 CONFIG_REALTEK_PHY=y
 CONFIG_REALTEK_SOC_PHY=y
 CONFIG_REGMAP=y
+CONFIG_REGMAP_I2C=y
 CONFIG_REGMAP_MMIO=y
 CONFIG_RESET_CONTROLLER=y
 CONFIG_RTL83XX=y
-- 
2.34.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v4 0/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

This is a continuation of the PR in GitHub[1] and v1 patch series.

This patch series adds support for Panasonic Switch-M8eG PN28080K.

Panasonic Switch-M*eG PN28xx0K series has the following models:

- Switch-M8eG PN28080K (RTL8380M, 8 + 1 SFP)
  -  1-9 : RTL8380M (SoC)
- Switch-M16eG PN28160K (RTL8382M?, 14 + 2 combo)
  - ?
- Switch-M24eG PN28240K (RTL8382M, 22 + 2 combo)
  -  1-8 : RTL8218B
  -  9-16: RTL8382M (SoC)
  - 17-24: RTL8218FB
- Switch-M48eG PN28480K (RTL8393M, 44 + 4 combo)
  -  1-40: RTL8218B
  - 41-48: RTL8218FB

(Note: I don't have a Switch-M16eG PN28160K and the hardware specification
 is unknown)

These models have the many common parts, so 2nd commit creates a dtsi for
This series.

Note:

- "Switch-M*eG" is a model name and "PN28xx0K" is a model number.
  Each model has two model number, "PN28xx0" and "PN28xx0K". But the
  first one (PN28xx0) is a Broadcom SoC based hardware.

- This series uses the VxWorks-based kernel in stock firmware.

[1]: https://github.com/openwrt/openwrt/pull/4209

v1 -> v2:

- drop 5.4 changes
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
  - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
  LEDs
- drop unnecessary default values from gpio-restart node

v2 -> v3:

- move interrupt related properties in PCA9539 to device dts
- move child i2c bus definitions in PCA9545 to device dts
- use actual SoC name "rtl8380" in second compatible of root

v3 -> v4:

- update the title of the first commit
- drop unnecessary "/delete-node/" of rtl8231 from dtsi

INAGAKI Hiroshi (2):
  realtek: enable pca953x driver for rtl838x subtarget
  realtek: add support for Panasonic Switch-M8eG PN28080K

 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 133 
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 195 ++
 target/linux/realtek/image/rtl838x.mk |  10 +
 target/linux/realtek/rtl838x/config-5.10  |   3 +
 4 files changed, 341 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

-- 
2.34.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 1/2] realtek: enable pca953x driver for target

[INAGAKI Hiroshi]

Oops, I forgot to update the title of this commit...

I'll fix and re-send, please ignore this series. Sorry for noise...

Regards,
Hiroshi

On 2022/03/09 21:52, INAGAKI Hiroshi wrote:

The system status LED on Panasonic Switch-M8eG PN28080K is connected to
a PCA9539PW. To use the LED as a status LED of OpenWrt while booting,
enable the pca953x driver and built-in to the kernel.
Also enable CONFIG_GPIO_PCA953X_IRQ to use interrupt via RTL83xx GPIO.

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes in config-5.4
- enable CONFIG_GPIO_PCA953X_IRQ to use interrupt

v2 -> v3:

(no changes)

  target/linux/realtek/rtl838x/config-5.10 | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/target/linux/realtek/rtl838x/config-5.10 
b/target/linux/realtek/rtl838x/config-5.10
index 1252aab11e..8e27af95ba 100644
--- a/target/linux/realtek/rtl838x/config-5.10
+++ b/target/linux/realtek/rtl838x/config-5.10
@@ -69,6 +69,8 @@ CONFIG_GENERIC_TIME_VSYSCALL=y
  CONFIG_GPIOLIB=y
  CONFIG_GPIOLIB_IRQCHIP=y
  CONFIG_GPIO_GENERIC=y
+CONFIG_GPIO_PCA953X=y
+CONFIG_GPIO_PCA953X_IRQ=y
  CONFIG_GPIO_REALTEK_OTTO=y
  CONFIG_GPIO_RTL8231=y
  CONFIG_GRO_CELLS=y
@@ -166,6 +168,7 @@ CONFIG_REALTEK_OTTO_WDT=y
  CONFIG_REALTEK_PHY=y
  CONFIG_REALTEK_SOC_PHY=y
  CONFIG_REGMAP=y
+CONFIG_REGMAP_I2C=y
  CONFIG_REGMAP_MMIO=y
  CONFIG_RESET_CONTROLLER=y
  CONFIG_RTL83XX=y


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 2/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Panasonic Switch-M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
  - port 1-8: TP, RTL8218B (SoC)
  - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
  - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
  - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
  - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
image

rtk network on
tftpboot 0x8100
bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
filesystem in the flash

ffsmount c:/
ffsfmt c:/

this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
filesystem

updatert 

example:

  updatert pn28080k_v3.rom

this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

setenv loadaddr 0xb4e0
setenv bootcmd bootm
saveenv

10: Download the OpenWrt initramfs image and boot with it

tftpboot 0x8100 0101A8C0.img
bootm

11: On the initramfs image, download the sysupgrade image and perform
sysupgrade with it

sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
  Switch-M8eG has an another (old) model number ("PN28080"), it's not a
  Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
  GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
  fails to execute anything in "bootcmd" variable if the images are not
  exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
  firmware and it includes the stock images, configuration files and
  checksum files. It's unknown format, can't be managed on the OpenWrt.
  To get the enough space for OpenWrt, move the filesystem to the head
  of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

- On the other devices in the same series of Switch-M8eG PN28080K, the
  INT pin on the PCA9555 is not connected to anywhere.

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

   on U-Boot:

 setenv loadaddr
 setenv bootcmd 'bootm 0x8100'

   on OpenWrt:

 fw_setenv loadaddr
 fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

  on U-Boot:

reset

  on OpenWrt:

reboot

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes for kernel 5.4
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
  - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
  LEDs
- drop unnecessary default values from gpio-restart node

v2 -> v3:

- move interrupt related properties in PCA9539 to device dts
- move child i2c bus definitions in PCA9545 to device dts
- use actual SoC name "rtl8380" in second compatible of root

 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 133 
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 198 ++
 target/linux/realtek/image/rtl838x.mk |  10 +
 3 files changed, 341 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

diff --git a/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts 
b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
new file mode 100644
index 00..f9d58f5b66
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl838x.dtsi"
+#include "rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi"
+
+#include 
+
+/ {
+   compatible = "panasonic,m8eg-pn28080k", "realtek,rtl8380-soc";
+   model = "Panasonic Switch-M8e

[PATCH v3 1/2] realtek: enable pca953x driver for target

[INAGAKI Hiroshi]

The system status LED on Panasonic Switch-M8eG PN28080K is connected to
a PCA9539PW. To use the LED as a status LED of OpenWrt while booting,
enable the pca953x driver and built-in to the kernel.
Also enable CONFIG_GPIO_PCA953X_IRQ to use interrupt via RTL83xx GPIO.

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes in config-5.4
- enable CONFIG_GPIO_PCA953X_IRQ to use interrupt

v2 -> v3:

(no changes)

 target/linux/realtek/rtl838x/config-5.10 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/realtek/rtl838x/config-5.10 
b/target/linux/realtek/rtl838x/config-5.10
index 1252aab11e..8e27af95ba 100644
--- a/target/linux/realtek/rtl838x/config-5.10
+++ b/target/linux/realtek/rtl838x/config-5.10
@@ -69,6 +69,8 @@ CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_GENERIC=y
+CONFIG_GPIO_PCA953X=y
+CONFIG_GPIO_PCA953X_IRQ=y
 CONFIG_GPIO_REALTEK_OTTO=y
 CONFIG_GPIO_RTL8231=y
 CONFIG_GRO_CELLS=y
@@ -166,6 +168,7 @@ CONFIG_REALTEK_OTTO_WDT=y
 CONFIG_REALTEK_PHY=y
 CONFIG_REALTEK_SOC_PHY=y
 CONFIG_REGMAP=y
+CONFIG_REGMAP_I2C=y
 CONFIG_REGMAP_MMIO=y
 CONFIG_RESET_CONTROLLER=y
 CONFIG_RTL83XX=y
-- 
2.34.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 0/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

This is a continuation of the PR in GitHub[1] and v1 patch series.

This patch series adds support for Panasonic Switch-M8eG PN28080K.

Panasonic Switch-M*eG PN28xx0K series has the following models:

- Switch-M8eG PN28080K (RTL8380M, 8 + 1 SFP)
  -  1-9 : RTL8380M (SoC)
- Switch-M16eG PN28160K (RTL8382M?, 14 + 2 combo)
  - ?
- Switch-M24eG PN28240K (RTL8382M, 22 + 2 combo)
  -  1-8 : RTL8218B
  -  9-16: RTL8382M (SoC)
  - 17-24: RTL8218FB
- Switch-M48eG PN28480K (RTL8393M, 44 + 4 combo)
  -  1-40: RTL8218B
  - 41-48: RTL8218FB

(Note: I don't have a Switch-M16eG PN28160K and the hardware specification
 is unknown)

These models have the many common parts, so 2nd commit creates a dtsi for
This series.

Note:

- "Switch-M*eG" is a model name and "PN28xx0K" is a model number.
  Each model has two model number, "PN28xx0" and "PN28xx0K". But the
  first one (PN28xx0) is a Broadcom SoC based hardware.

- This series uses the VxWorks-based kernel in stock firmware.

[1]: https://github.com/openwrt/openwrt/pull/4209

v1 -> v2:

- drop 5.4 changes
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
  - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
  LEDs
- drop unnecessary default values from gpio-restart node

v2 -> v3:

- move interrupt related properties in PCA9539 to device dts
- move child i2c bus definitions in PCA9545 to device dts
- use actual SoC name "rtl8380" in second compatible of root

INAGAKI Hiroshi (2):
  realtek: enable pca953x driver for target
  realtek: add support for Panasonic Switch-M8eG PN28080K

 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 133 
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 198 ++
 target/linux/realtek/image/rtl838x.mk |  10 +
 target/linux/realtek/rtl838x/config-5.10  |   3 +
 4 files changed, 344 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

-- 
2.34.1.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2 2/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Hi Sander,

Thank you for the review.

On 2021/12/05 1:02, Sander Vanheule wrote:

Hi Hiroshi,

Thanks for the update. Some inline comments below.

On Tue, 2021-11-30 at 19:43 +0900, INAGAKI Hiroshi wrote:

Panasonic Switch-M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
   - port 1-8: TP, RTL8218B (SoC)
   - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
   - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
   - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
   - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
     the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
     and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
     image

     rtk network on
     tftpboot 0x8100
     bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
     filesystem in the flash

     ffsmount c:/
     ffsfmt c:/

     this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
     filesystem

     updatert 

     example:

   updatert pn28080k_v3.rom

     this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

     setenv loadaddr 0xb4e0
     setenv bootcmd bootm
     saveenv

10: Download the OpenWrt initramfs image and boot with it

     tftpboot 0x8100 0101A8C0.img
     bootm

11: On the initramfs image, download the sysupgrade image and perform
     sysupgrade with it

     sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
   Switch-M8eG has an another (old) model number ("PN28080"), it's not a
   Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
   GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
   fails to execute anything in "bootcmd" variable if the images are not
   exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
   firmware and it includes the stock images, configuration files and
   checksum files. It's unknown format, can't be managed on the OpenWrt.
   To get the enough space for OpenWrt, move the filesystem to the head
   of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

- On the other devices in the same series of Switch-M8eG PN28080K, the
   INT pin on the PCA9555 is not connected to anywhere.

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

    on U-Boot:

  setenv loadaddr
  setenv bootcmd 'bootm 0x8100'

    on OpenWrt:

  fw_setenv loadaddr
      fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

   on U-Boot:

     reset

   on OpenWrt:

     reboot

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes for kernel 5.4
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
   - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
   LEDs
- drop unnecessary default values from gpio-restart node

  .../rtl8380_panasonic_m8eg-pn28080k.dts   | 123 ++
  .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 229 ++
  target/linux/realtek/image/Makefile   |  10 +
  3 files changed, 362 insertions(+)
  create mode 100644 target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-
pn28080k.dts
  create mode 100644 target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-
pn28xx0k.dtsi

diff --git a/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
new file mode 100644
index 00..7b6bfc7991
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl838x.dtsi"
+#include "rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi"

I take it you chose to perform all the includes here because the larger switches
are RTL839x-based

[PATCH v2 2/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Panasonic Switch-M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
  - port 1-8: TP, RTL8218B (SoC)
  - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
  - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
  - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
  - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
image

rtk network on
tftpboot 0x8100
bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
filesystem in the flash

ffsmount c:/
ffsfmt c:/

this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
filesystem

updatert 

example:

  updatert pn28080k_v3.rom

this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

setenv loadaddr 0xb4e0
setenv bootcmd bootm
saveenv

10: Download the OpenWrt initramfs image and boot with it

tftpboot 0x8100 0101A8C0.img
bootm

11: On the initramfs image, download the sysupgrade image and perform
sysupgrade with it

sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
  Switch-M8eG has an another (old) model number ("PN28080"), it's not a
  Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
  GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
  fails to execute anything in "bootcmd" variable if the images are not
  exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
  firmware and it includes the stock images, configuration files and
  checksum files. It's unknown format, can't be managed on the OpenWrt.
  To get the enough space for OpenWrt, move the filesystem to the head
  of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

- On the other devices in the same series of Switch-M8eG PN28080K, the
  INT pin on the PCA9555 is not connected to anywhere.

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

   on U-Boot:

 setenv loadaddr
 setenv bootcmd 'bootm 0x8100'

   on OpenWrt:

 fw_setenv loadaddr
 fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

  on U-Boot:

reset

  on OpenWrt:

reboot

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes for kernel 5.4
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
  - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
  LEDs
- drop unnecessary default values from gpio-restart node

 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 123 ++
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 229 ++
 target/linux/realtek/image/Makefile   |  10 +
 3 files changed, 362 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

diff --git a/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts 
b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
new file mode 100644
index 00..7b6bfc7991
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl838x.dtsi"
+#include "rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi"
+
+#include 
+
+/ {
+   compatible = "panasonic,m8eg-pn28080k", "realtek,rtl838x-soc";
+   model = "Panasonic Switch-M8eG PN28080K";
+
+   aliases {
+   led-boot = &led_status_eco_green;
+   led-failsafe = &led_status_eco_amber;
+   led-running = &led_status_eco_green

[PATCH v2 0/2] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

This is a continuation of the PR in GitHub[1] and v1 patch series.

This patch series adds support for Panasonic Switch-M8eG PN28080K.

Panasonic Switch-M*eG PN28xx0K series has the following models:

- Switch-M8eG PN28080K (RTL8380M, 8 + 1 SFP)
  -  1-9 : RTL8380M (SoC)
- Switch-M16eG PN28160K (RTL8382M?, 14 + 2 combo)
  - ?
- Switch-M24eG PN28240K (RTL8382M, 22 + 2 combo)
  -  1-8 : RTL8218B
  -  9-16: RTL8382M (SoC)
  - 17-24: RTL8218FB
- Switch-M48eG PN28480K (RTL8393M, 44 + 4 combo)
  -  1-40: RTL8218B
  - 41-48: RTL8218FB

(Note: I don't have a Switch-M16eG PN28160K and the hardware specification
 is unknown)

These models have the many common parts, so 3rd commit creates a dtsi for
This series.

Note:

- "Switch-M*eG" is a model name and "PN28xx0K" is a model number.
  Each model has two model number, "PN28xx0" and "PN28xx0K". But the
  first one (PN28xx0) is a Broadcom SoC based hardware.

- This series uses the VxWorks-based kernel in stock firmware.

[1]: https://github.com/openwrt/openwrt/pull/4209

v1 -> v2:

- drop 5.4 changes
- add interrupt-related properties to the nodes of PCA9539 and PCA9555
  - use "gpio-keys" instead of "gpio-keys-polled"
- update/remove comments in mtd partitions
- use "led-*" scheme and add color/function properties for each node of
  LEDs
- drop unnecessary default values from gpio-restart node

INAGAKI Hiroshi (2):
  realtek: enable pca953x driver for target
  realtek: add support for Panasonic Switch-M8eG PN28080K

 target/linux/realtek/config-5.10  |   3 +
 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 123 ++
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 229 ++
 target/linux/realtek/image/Makefile   |  10 +
 4 files changed, 365 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

-- 
2.33.0.windows.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 1/2] realtek: enable pca953x driver for target

[INAGAKI Hiroshi]

The system status LED on Panasonic Switch-M8eG PN28080K is connected to
a PCA9539PW. To use the LED as a status LED of OpenWrt while booting,
enable the pca953x driver and built-in to the kernel.
Also enable CONFIG_GPIO_PCA953X_IRQ to use interrupt via RTL83xx GPIO.

Signed-off-by: INAGAKI Hiroshi 
---
v1 -> v2:

- drop changes in config-5.4
- enable CONFIG_GPIO_PCA953X_IRQ to use interrupt

 target/linux/realtek/config-5.10 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/realtek/config-5.10 b/target/linux/realtek/config-5.10
index f75cf92897..33409d693d 100644
--- a/target/linux/realtek/config-5.10
+++ b/target/linux/realtek/config-5.10
@@ -70,6 +70,8 @@ CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_GENERIC=y
+CONFIG_GPIO_PCA953X=y
+CONFIG_GPIO_PCA953X_IRQ=y
 CONFIG_GPIO_REALTEK_OTTO=y
 CONFIG_GPIO_RTL8231=y
 CONFIG_GPIO_RTL838X=y
@@ -165,6 +167,7 @@ CONFIG_REALTEK_OTTO_WDT=y
 CONFIG_REALTEK_PHY=y
 CONFIG_REALTEK_SOC_PHY=y
 CONFIG_REGMAP=y
+CONFIG_REGMAP_I2C=y
 CONFIG_REGMAP_MMIO=y
 CONFIG_RESET_CONTROLLER=y
 CONFIG_RTL838X=y
-- 
2.33.0.windows.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 0/3] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Hi Hauke,

Thank you for the guidance.

On 2021/11/30 6:37, Hauke Mehrtens wrote:

On 11/12/21 10:00 PM, Sander Vanheule wrote:

Hi,

On Sun, 2021-10-03 at 15:53 +0900, INAGAKI Hiroshi wrote:
[...]



INAGAKI Hiroshi (3):
   realtek: enable pca953x driver for target
   realtek: enable gpio-restart driver in target
   realtek: add support for Panasonic Switch-M8eG PN28080K

  target/linux/realtek/config-5.10  |   4 +
  target/linux/realtek/config-5.4   |   4 +
  .../rtl8380_panasonic_m8eg-pn28080k.dts   | 103 
  .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 216 
+

  .../rtl8380_panasonic_m8eg-pn28080k.dts   | 107 +
  .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 220 
++

  target/linux/realtek/image/Makefile   |  10 +
  7 files changed, 664 insertions(+)
  create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
  create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
  create mode 100644 
target/linux/realtek/dts-5.4/rtl8380_panasonic_m8eg-pn28080k.dts
  create mode 100644 
target/linux/realtek/dts-5.4/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi


I guess this is more a question for the maintainers: Since the 
realtek target now uses the
5.10 kernel in master, does it still make sense to add support for 
5.4? Hiroshi has
backported the upstream drivers for 5.10 (thanks again!), so both 
kernel version now have
different quirks. Personnaly, I would prefer not to have to put any 
energy in 5.4 anymore.


The realtek target already has KERNEL_PATCHVER set to 5.10 now. You 
do not have to add support for kernel 5.4 in your patches any more, 
if you want to it is fine with me, but we will probability delete 
the support for kernel 5.4 in 1 or 2 months anyway.


If you need special workarounds for kernel 5.4 I would suggest to go 
with kernel 5.10 only.
@Hiroshi I added some of the GPIO patches from Sander, could you 
please rebase your patch on top of that.


I see, OK. I'm preparing the v2 patch rebased from master, without 5.4 
changes :)




Hauke


Regards,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 3/3] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Hi Sander,

On 2021/11/14 17:52, Sander Vanheule wrote:

Hi Hiroshi,

On Sun, 2021-11-14 at 14:32 +0900, INAGAKI Hiroshi wrote:

Hi Sander,

Thank you for your review.

On 2021/11/13 7:46, Sander Vanheule wrote:

Hi Hiroshi,

On Sun, 2021-10-03 at 15:53 +0900, INAGAKI Hiroshi wrote:

Panasonic M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
    - port 1-8: TP, RTL8218B (SoC)
    - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
    - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
    - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
    - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

Looks quite convoluted. Kudos on working this out!

Thank you!


1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
  the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
  and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
  image

  rtk network on
  tftpboot 0x8100
  bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
  filesystem in the flash

  ffsmount c:/
  ffsfmt c:/

  this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
  filesystem

  updatert 

  example:

    updatert pn28080k_v3.rom

  this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

  setenv loadaddr 0xb4e0
  setenv bootcmd bootm
  saveenv

10: Download the OpenWrt initramfs image and boot with it

  tftpboot 0x8100 0101A8C0.img
  bootm

11: On the initramfs image, download the sysupgrade image and perform
  sysupgrade with it

  sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
    Switch-M8eG has an another (old) model number ("PN28080"), it's not a
    Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
    GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
    fails to execute anything in "bootcmd" variable if the images are not
    exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
    firmware and it includes the stock images, configuration files and
    checksum files. It's unknown format, can't be managed on the OpenWrt.
    To get the enough space for OpenWrt, move the filesystem to the head
    of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

     on U-Boot:

   setenv loadaddr
   setenv bootcmd 'bootm 0x8100'

     on OpenWrt:

   fw_setenv loadaddr
   fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

    on U-Boot:

  reset

    on OpenWrt:

  reboot

Signed-off-by: INAGAKI Hiroshi 
---

[...]


diff --git a/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
b/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
new file mode 100644
index 00..d41213f1fd
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include 
+#include 
+
+/ {
+   chosen {
+   bootargs = "console=ttyS0,9600";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   leds: leds {
+   compatible = "gpio-leds";
+
+   any_collision {
+   label = "amber:any_col";

Should we start using 'function' and 'color' on 5.10 instead of (or in addition 
to)
'label'? The functions are non-standard, but the #DEFINE-s in led-common.h are 
only
strings anyway.

As you said in your additional email, the replacement breaks led-*
aliases.
I think it's possible to add "color"/"function" properties as a
preparation without replacement.


I'll add "color"/"function" properties in v2 patch[1].

[

Re: [PATCH 3/3] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Hi Sander,

Thank you for your review.

On 2021/11/13 7:46, Sander Vanheule wrote:

Hi Hiroshi,

On Sun, 2021-10-03 at 15:53 +0900, INAGAKI Hiroshi wrote:

Panasonic M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
   - port 1-8: TP, RTL8218B (SoC)
   - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
   - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
   - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
   - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

Looks quite convoluted. Kudos on working this out!

Thank you!


1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
     the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
     and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
     image

     rtk network on
     tftpboot 0x8100
     bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
     filesystem in the flash

     ffsmount c:/
     ffsfmt c:/

     this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
     filesystem

     updatert 

     example:

   updatert pn28080k_v3.rom

     this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

     setenv loadaddr 0xb4e0
     setenv bootcmd bootm
     saveenv

10: Download the OpenWrt initramfs image and boot with it

     tftpboot 0x8100 0101A8C0.img
     bootm

11: On the initramfs image, download the sysupgrade image and perform
     sysupgrade with it

     sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
   Switch-M8eG has an another (old) model number ("PN28080"), it's not a
   Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
   GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
   fails to execute anything in "bootcmd" variable if the images are not
   exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
   firmware and it includes the stock images, configuration files and
   checksum files. It's unknown format, can't be managed on the OpenWrt.
   To get the enough space for OpenWrt, move the filesystem to the head
   of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

    on U-Boot:

  setenv loadaddr
  setenv bootcmd 'bootm 0x8100'

    on OpenWrt:

  fw_setenv loadaddr
      fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

   on U-Boot:

     reset

   on OpenWrt:

     reboot

Signed-off-by: INAGAKI Hiroshi 
---

[...]


diff --git a/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
b/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
new file mode 100644
index 00..d41213f1fd
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include 
+#include 
+
+/ {
+   chosen {
+   bootargs = "console=ttyS0,9600";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   leds: leds {
+   compatible = "gpio-leds";
+
+   any_collision {
+   label = "amber:any_col";

Should we start using 'function' and 'color' on 5.10 instead of (or in addition 
to)
'label'? The functions are non-standard, but the #DEFINE-s in led-common.h are 
only
strings anyway.
As you said in your additional email, the replacement breaks led-* 
aliases.
I think it's possible to add "color"/"function" properties as a 
preparation without replacement.



Speaking of following the dt-bindings... I'm aware that you've already 
discussed the node
names with Adrian, but leds-gpio.yaml currently specifies that child node names 
shall
match "(^led-[0-9a-f]$|led

Re: [PATCH 2/3] realtek: enable gpio-restart driver in target

[INAGAKI Hiroshi]

Hi,

On 2021/11/13 6:15, Sander Vanheule wrote:

As made clear by Paul Fertser, gpio-restart isn't actually used unless 
_machine_restart()
is also removed. Although I don't mind adding the correct nodes to the DTS 
already (maybe
others disagree). Adding the driver already would only have the effect 
(benefit?) of
grabbing the relevant GPIO, and preventing users from using it accidentally.

I definitely think this driver should definitely be enabled, but do we wait 
with enabling
it until we can remove _machine_restart? Or can this already be merged as some 
sort of
preparatory patch?
IMO, I think that there is no problem because the gpio-restart exists 
as a clear specification of this device, and even if the driver is 
enabled at the moment, it only does not work and does not interfere 
with others.


Regards,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/3] realtek: enable pca953x driver for target

[INAGAKI Hiroshi]

The system status LED on Panasonic Switch-M8eG PN28080K is connected to
a PCA9539PW. To use the LED as a status LED of OpenWrt while booting,
enable the pca953x driver and built-in to the kernel.

Signed-off-by: INAGAKI Hiroshi 
---
 target/linux/realtek/config-5.10 | 3 +++
 target/linux/realtek/config-5.4  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/target/linux/realtek/config-5.10 b/target/linux/realtek/config-5.10
index 1b050fc081..810bacbefa 100644
--- a/target/linux/realtek/config-5.10
+++ b/target/linux/realtek/config-5.10
@@ -69,6 +69,8 @@ CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_GENERIC=y
+CONFIG_GPIO_PCA953X=y
+# CONFIG_GPIO_PCA953X_IRQ is not set
 CONFIG_GPIO_REALTEK_OTTO=y
 CONFIG_GPIO_RTL8231=y
 CONFIG_GRO_CELLS=y
@@ -161,6 +163,7 @@ CONFIG_RATIONAL=y
 CONFIG_REALTEK_PHY=y
 CONFIG_REALTEK_SOC_PHY=y
 CONFIG_REGMAP=y
+CONFIG_REGMAP_I2C=y
 CONFIG_REGMAP_MMIO=y
 CONFIG_RESET_CONTROLLER=y
 CONFIG_RTL838X=y
diff --git a/target/linux/realtek/config-5.4 b/target/linux/realtek/config-5.4
index 5e29879798..8a353dfc32 100644
--- a/target/linux/realtek/config-5.4
+++ b/target/linux/realtek/config-5.4
@@ -72,6 +72,8 @@ CONFIG_GENERIC_SCHED_CLOCK=y
 CONFIG_GENERIC_SMP_IDLE_THREAD=y
 CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GPIOLIB=y
+CONFIG_GPIO_PCA953X=y
+# CONFIG_GPIO_PCA953X_IRQ is not set
 CONFIG_GPIO_RTL8231=y
 CONFIG_GPIO_RTL838X=y
 CONFIG_REALTEK_SOC_PHY=y
@@ -161,6 +163,7 @@ CONFIG_POWER_RESET_SYSCON=y
 CONFIG_PSB6970_PHY=y
 CONFIG_REALTEK_PHY=y
 CONFIG_REGMAP=y
+CONFIG_REGMAP_I2C=y
 CONFIG_REGMAP_MMIO=y
 CONFIG_RESET_CONTROLLER=y
 CONFIG_RTL838X=y
-- 
2.33.0.windows.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/3] realtek: enable gpio-restart driver in target

[INAGAKI Hiroshi]

On Panasonic Switch-M8eG PN28080K, a GPIO pin on PCA9539 chip is used
for for hard-reset of the system. To use this, enable gpio-restart
driver and built-in to the kernel.

Signed-off-by: INAGAKI Hiroshi 
---
 target/linux/realtek/config-5.10 | 1 +
 target/linux/realtek/config-5.4  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/linux/realtek/config-5.10 b/target/linux/realtek/config-5.10
index 810bacbefa..5a847a2bb1 100644
--- a/target/linux/realtek/config-5.10
+++ b/target/linux/realtek/config-5.10
@@ -158,6 +158,7 @@ CONFIG_PHYLIB=y
 CONFIG_PHYLINK=y
 CONFIG_PINCTRL=y
 CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
 CONFIG_POWER_RESET_SYSCON=y
 CONFIG_RATIONAL=y
 CONFIG_REALTEK_PHY=y
diff --git a/target/linux/realtek/config-5.4 b/target/linux/realtek/config-5.4
index 8a353dfc32..34e4b9028b 100644
--- a/target/linux/realtek/config-5.4
+++ b/target/linux/realtek/config-5.4
@@ -159,6 +159,7 @@ CONFIG_PHYLIB=y
 CONFIG_PHYLINK=y
 CONFIG_PINCTRL=y
 CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
 CONFIG_POWER_RESET_SYSCON=y
 CONFIG_PSB6970_PHY=y
 CONFIG_REALTEK_PHY=y
-- 
2.33.0.windows.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 0/3] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

This is a continuation of the PR in GitHub[1].

This patch series adds support for Panasonic Switch-M8eG PN28080K.

Panasonic Switch-M*eG PN28xx0K series has the following models:

- Switch-M8eG PN28080K (RTL8380M, 8 + 1 SFP)
  -  1-9 : RTL8380M (SoC)
- Switch-M16eG PN28160K (RTL8382M?, 14 + 2 combo)
  - ?
- Switch-M24eG PN28240K (RTL8382M, 22 + 2 combo)
  -  1-8 : RTL8218B
  -  9-16: RTL8382M (SoC)
  - 17-24: RTL8218FB
- Switch-M48eG PN28480K (RTL8393M, 44 + 4 combo)
  -  1-40: RTL8218B
  - 41-48: RTL8218FB

(Note: I don't have a Switch-M16eG PN28160K and the hardware specification
 is unknown)

These models have the many common parts, so 3rd commit creates a dtsi for
This series.

Note:

- "Switch-M*eG" is a model name and "PN28xx0K" is a model number.
  Each model has two model number, "PN28xx0" and "PN28xx0K". But the
  first one (PN28xx0) is a Broadcom SoC based hardware.

- This series uses the VxWorks-based kernel in stock firmware.

[1]: https://github.com/openwrt/openwrt/pull/4209

INAGAKI Hiroshi (3):
  realtek: enable pca953x driver for target
  realtek: enable gpio-restart driver in target
  realtek: add support for Panasonic Switch-M8eG PN28080K

 target/linux/realtek/config-5.10  |   4 +
 target/linux/realtek/config-5.4   |   4 +
 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 103 
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 216 +
 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 107 +
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 220 ++
 target/linux/realtek/image/Makefile   |  10 +
 7 files changed, 664 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
 create mode 100644 
target/linux/realtek/dts-5.4/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.4/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

-- 
2.33.0.windows.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 3/3] realtek: add support for Panasonic Switch-M8eG PN28080K

[INAGAKI Hiroshi]

Panasonic M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.

Specification:

- SoC   : Realtek RTL8380M
- RAM   : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet  : 10/100/1000 Mbps x8 + 1
  - port 1-8: TP, RTL8218B (SoC)
  - port 9  : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART  : RS-232 port on the front panel (connector: RJ-45)
  - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
  - 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
  - Plug: IEC 60320-C13
- Stock OS  : VxWorks based

Flash instruction using initramfs image:

1.  Prepare the TFTP server with the IP address 192.168.1.111
2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
the TFTP directory
3.  Download the official upgrading firmware (ex: pn28080k_v3.rom)
and place it to the TFTP directory
4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5.  Execute the following commands and boot with the OpenWrt initramfs
image

rtk network on
tftpboot 0x8100
bootm

6.  Backup mtdblock files to the computer by scp or anything and reboot
7.  Interrupt the U-Boot and execute the following commands to re-create
filesystem in the flash

ffsmount c:/
ffsfmt c:/

this step takes a long time, about ~ 4 mins

8.  Execute the following commands to put the official images to the
filesystem

updatert 

example:

  updatert pn28080k_v3.rom

this step takes about ~ 40 secs

9.  Set the environment variables of the U-Boot by the following commands

setenv loadaddr 0xb4e0
setenv bootcmd bootm
saveenv

10: Download the OpenWrt initramfs image and boot with it

tftpboot 0x8100 0101A8C0.img
bootm

11: On the initramfs image, download the sysupgrade image and perform
sysupgrade with it

sysupgrade 

12: Wait ~ 120 seconds to complete flashing

Note:

- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
  Switch-M8eG has an another (old) model number ("PN28080"), it's not a
  Realtek based hardware.

- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
  GPIO pin.

- The U-Boot checks the runtime images in the flash when booting and
  fails to execute anything in "bootcmd" variable if the images are not
  exsisting.

- A filesystem is formed in the flash (0x10-0x1DF) on the stock
  firmware and it includes the stock images, configuration files and
  checksum files. It's unknown format, can't be managed on the OpenWrt.
  To get the enough space for OpenWrt, move the filesystem to the head
  of "fs_reserved" partition by execution of "ffsfmt" and "updatert".

Back to the stock firmware:

1. Delete "loadaddr" variable and set "bootcmd" to the original value

   on U-Boot:

 setenv loadaddr
 setenv bootcmd 'bootm 0x8100'

   on OpenWrt:

 fw_setenv loadaddr
 fw_setenv bootcmd 'bootm 0x8100'

2. Perform reset or reboot

  on U-Boot:

reset

  on OpenWrt:

reboot

Signed-off-by: INAGAKI Hiroshi 
---
 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 103 
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 216 +
 .../rtl8380_panasonic_m8eg-pn28080k.dts   | 107 +
 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 220 ++
 target/linux/realtek/image/Makefile   |  10 +
 5 files changed, 656 insertions(+)
 create mode 100644 
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
 create mode 100644 
target/linux/realtek/dts-5.4/rtl8380_panasonic_m8eg-pn28080k.dts
 create mode 100644 
target/linux/realtek/dts-5.4/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi

diff --git a/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts 
b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
new file mode 100644
index 00..df470c377e
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl838x.dtsi"
+#include "rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi"
+
+/ {
+   compatible = "panasonic,m8eg-pn28080k", "realtek,rtl838x-soc";
+   model = "Panasonic Switch-M8eG PN28080K";
+
+   aliases {
+   led-boot = &led_status_eco_green;
+   led-failsafe = &led_status_eco_amber;
+   led-running = &led_status_eco_green;
+   led-upgrade = &led_status_eco_green;
+   };
+
+   sfp0: sfp-p9 {
+   compatible = "sff,sfp";
+   i2c-bus = <&i2c0>;
+   tx-fault-gp

Re: [PATCH] base-files: fix configuration generation of network if "bridge" exists

[INAGAKI Hiroshi]

Hi Rafał,

thank you for your reply.

On 2021/05/24 6:06, Rafał Miłecki wrote:

On 23.05.2021 13:30, INAGAKI Hiroshi wrote:

After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b
("base-files: generate "device UCI type section for bridge"), the 
wrong
network configuration is generated for the devices that already 
have the

bridge device section for VLAN, such as the devices in realtek target.

As a result, the bridge device by additional "device" section is
specified to the "ports" option in the "bridge-vlan" section and 
netifd
shuts down the switch and the ethernet when the network service 
started.


--- generated config ---

config device 'switch'
 option name 'switch'
 option type 'bridge'
 option macaddr '34:76:c5:xx:xx:a8'

config device
 option name 'br-wan'
 option type 'bridge'
 list ports 'lan1'
... (truncated)
 list ports 'lan9'

config bridge-vlan 'wan_vlan'
 option device 'switch'
 option vlan '1'
 option ports 'br-wan'

--- config end ---


Thanks for bringing this up Hiroshi.

I'm looking at existing code, at the commit be09c5a3cd65 ("base-files:
add board.d support for bridge device") and I have some problems
understanding those bridges.

If you can, please kindly answer me two questions:


1. Why realtek treats lan ports as WAN?

I mean this code:

for lan in /sys/class/net/lan*; do
lan_list="$lan_list $(basename $lan)"
done
ucidef_set_interface_wan "$lan_list"


It's for "standard switching hub behavior", to disable DHCP and allow
users to connect the device to other network, such as upstream.


2. What's up with the magic VLAN ID 100?

I found this:
ucidef_set_interface "lan" ifname "lan1n:t" protocol "static" vlan 100

Why "lan" logic interface requires VLAN ID 100?


It's a "management VLAN".

I haven't participated in the discussion that determines this
specification, so I don't know any further details, sorry.

There are some discussion about this in the forum[1] and there is a
patch series to improve the default configuration[2].

[1]: 
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/134
[2]: 
https://patchwork.ozlabs.org/project/openwrt/list/?series=238725&submitter=&state=*&q=&archive=both&delegate=




Finally: could you post your /etc/config/network from a working setup?

/etc/config/network:


config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fd34:7463:3cea::/48'

config device 'switch'
    option name 'switch'
    option type 'bridge'
    option macaddr '34:76:c5:d9:f0:a8'

config bridge-vlan 'wan_vlan'
    option device 'switch'
    option vlan '1'
    option ports 'lan1 lan10 lan11 lan12 lan13 lan14 lan15 lan16 
lan17 lan18 lan19 lan2 lan20 lan21 lan22 lan23 lan24 lan3 lan4 lan5 
lan6 lan7 lan8 lan9'


config interface 'wan'
    option ifname 'switch.1'
    option proto 'dhcp'

config device 'wan_switch_1_dev'
    option name 'switch.1'
    option macaddr '34:76:c5:d9:f0:a8'

config interface 'wan6'
    option ifname 'switch.1'
    option proto 'dhcpv6'

config bridge-vlan 'lan_vlan'
    option device 'switch'
    option vlan '100'
    option ports 'lan1:t'

config interface 'lan'
    option ifname 'switch.100'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'

config device 'lan_switch_100_dev'
    option name 'switch.100'
    option macaddr '36:76:c5:d9:f0:a8'


and /etc/board.json:


{
    "model": {
    "id": "iodata,bsh-g24mb",
    "name": "I-O DATA BSH-G24MB"
    },
    "bridge": {
    "name": "switch",
    "macaddr": "34:76:c5:d9:f0:a8"
    },
    "network": {
    "wan": {
    "ports": [
    "lan1",
    "lan10",
  

[PATCH] base-files: fix configuration generation of network if "bridge" exists

[INAGAKI Hiroshi]

After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b
("base-files: generate "device UCI type section for bridge"), the wrong
network configuration is generated for the devices that already have the
bridge device section for VLAN, such as the devices in realtek target.

As a result, the bridge device by additional "device" section is
specified to the "ports" option in the "bridge-vlan" section and netifd
shuts down the switch and the ethernet when the network service started.

--- generated config ---

config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr '34:76:c5:xx:xx:a8'

config device
option name 'br-wan'
option type 'bridge'
list ports 'lan1'
... (truncated)
list ports 'lan9'

config bridge-vlan 'wan_vlan'
option device 'switch'
option vlan '1'
option ports 'br-wan'

--- config end ---

--- log ---

root@OpenWrt:/# /etc/init.d/network start
root@OpenWrt:/# [  159.752015] Using MAC 3476c5d9f0a8
[  159.756993] RESETTING 8380, CPU_PORT 28
[  159.961309] rtl838x-eth bb00a300.ethernet eth0: configuring for 
fixed/internal link mode
[  159.970338] In rtl838x_mac_config, mode 1
[  159.975095] device eth0 left promiscuous mode
[  159.980356] In rtl838x_mac_config, mode 1
[  159.984896] rtl838x-eth bb00a300.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control off
[  160.005785] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  160.283111] device eth0 entered promiscuous mode
[  160.288322] rtl83xx-switch switch@bb00 lan1: configuring for phy/qsgmii 
link mode
[  160.308034] 8021q: adding VLAN 0 to HW filter on device lan1
[  160.340250] br-wan: port 1(lan1) entered blocking state
[  160.346104] br-wan: port 1(lan1) entered disabled state
[  160.352724] device lan1 entered promiscuous mode
... (truncated)
[  162.123430] rtl83xx-switch switch@bb00 lan9: configuring for 
phy/internal link mode
[  162.143153] 8021q: adding VLAN 0 to HW filter on device lan9
[  162.175597] br-wan: port 24(lan9) entered blocking state
[  162.181669] br-wan: port 24(lan9) entered disabled state
[  162.188327] device lan9 entered promiscuous mode
[  162.209932] device lan1 left promiscuous mode
[  162.215216] br-wan: port 1(lan1) entered disabled state
... (truncated)
[  162.827566] device lan9 left promiscuous mode
[  162.832938] br-wan: port 24(lan9) entered disabled state
[  162.844314] in rtl838x_eth_stop
[  162.847955] rtl838x-eth bb00a300.ethernet eth0: Link is Down
[  163.754337] Using MAC 3476c5d9f0a8
[  163.779357] RESETTING 8380, CPU_PORT 28
[  163.983666] rtl838x-eth bb00a300.ethernet eth0: configuring for 
fixed/internal link mode
[  163.992695] In rtl838x_mac_config, mode 1
[  163.997434] device eth0 left promiscuous mode
[  164.002670] In rtl838x_mac_config, mode 1
[  164.007209] rtl838x-eth bb00a300.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control off
[  164.044261] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  164.534390] device eth0 entered promiscuous mode
[  164.539704] rtl83xx-switch switch@bb00 lan1: configuring for phy/qsgmii 
link mode
[  164.559826] 8021q: adding VLAN 0 to HW filter on device lan1
[  164.592421] br-wan: port 1(lan1) entered blocking state
[  164.598270] br-wan: port 1(lan1) entered disabled state
[  164.604910] device lan1 entered promiscuous mode
... (truncated)
[  166.601998] rtl83xx-switch switch@bb00 lan9: configuring for 
phy/internal link mode
[  166.622328] 8021q: adding VLAN 0 to HW filter on device lan9
[  166.653459] br-wan: port 24(lan9) entered blocking state
[  166.659530] br-wan: port 24(lan9) entered disabled state
[  166.666195] device lan9 entered promiscuous mode
[  166.688759] device lan1 left promiscuous mode
[  166.694131] br-wan: port 1(lan1) entered disabled state
... (truncated)
[  167.310359] device lan9 left promiscuous mode
[  167.315636] br-wan: port 24(lan9) entered disabled state
[  167.326988] in rtl838x_eth_stop
[  167.331006] rtl838x-eth bb00a300.ethernet eth0: Link is Down

--- log end ---

root@OpenWrt:/# ifconfig
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:448 errors:0 dropped:0 overruns:0 frame:0
  TX packets:448 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:34944 (34.1 KiB)  TX bytes:34944 (34.1 KiB)

root@OpenWrt:/#

This patch fixes this issue.

Fixes: 43fc720657 ("base-files: generate "device" UCI type section for
bridge")

Signed-off-by: INAGAKI Hiroshi 
---
 package/base-files/files/bin/config_generate | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/base-files/

Re: [PATCH 0/5] mediatek: Add support for Buffalo WSR-2533DHP2

[INAGAKI Hiroshi]

Hi Hauke,

On 2021/03/10 8:52, Hauke Mehrtens wrote:

These patches are adding support for different TRX magics and later
support for the Buffalo WSR-2533DHP2.
This was developed mostly by INAGAKI Hiroshi and I did some fixes and
cleaned the patches up in the last days.

I added the two patches also for kernel 5.4, I needed this in the
beginning till I found out why kernel 5.10 is not booting. Now kernel
5.10 is working fine with this device. I can also remove the kernel 5.4
patches.

@Hiroshi: Could you please give your Signed-off-by if you are fine with this.

I'm fine, thank you :)

Signed-off-by: INAGAKI Hiroshi 


BTW, the word after the prefix in the commit titles may need to be 
lower-case[1].


[1]: https://openwrt.org/submitting-patches#submission_guidelines


Hauke Mehrtens (3):
   mediatek: Fix mtk parallel nand driver
   tools: otrx: allow own magic
   mediatek: Support non standard trx magic values

INAGAKI Hiroshi (2):
   mtd: Add option for TRX magic to fixtrx
   mediatek: Add support for Buffalo WSR-2533DHP2

  package/boot/uboot-envtools/files/mediatek|   3 +
  package/system/mtd/src/Makefile   |   1 +
  package/system/mtd/src/mtd.c  |  14 +-
  package/system/mtd/src/mtd.h  |   1 +
  package/system/mtd/src/trx.c  |   8 +-
  .../dts/mt7622-buffalo-wsr-2533dhp2.dts   | 336 ++
  target/linux/mediatek/image/mt7622.mk |  64 
  .../mt7622/base-files/etc/board.d/02_network  |   4 +
  .../base-files/etc/uci-defaults/09_fix_crc|  10 +
  .../mt7622/base-files/lib/upgrade/buffalo.sh  | 126 +++
  .../mt7622/base-files/lib/upgrade/platform.sh |  15 +
  target/linux/mediatek/mt7622/config-5.10  |   1 +
  ...trx-Allow-to-specify-trx-magic-in-DT.patch |  75 
  ...ove-dependency-to-BRCM-architectures.patch |  23 ++
  ...Fix-WAITRDY-break-condition-and-time.patch |  36 ++
  ...trx-Allow-to-specify-trx-magic-in-DT.patch |  75 
  ...ove-dependency-to-BRCM-architectures.patch |  23 ++
  tools/firmware-utils/src/otrx.c   |  15 +-
  18 files changed, 822 insertions(+), 8 deletions(-)
  create mode 100644 target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
  create mode 100644 
target/linux/mediatek/mt7622/base-files/etc/uci-defaults/09_fix_crc
  create mode 100644 
target/linux/mediatek/mt7622/base-files/lib/upgrade/buffalo.sh
  create mode 100644 
target/linux/mediatek/patches-5.10/350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch
  create mode 100644 
target/linux/mediatek/patches-5.10/351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch
  create mode 100644 
target/linux/mediatek/patches-5.10/360-mtd-rawnand-mtk-Fix-WAITRDY-break-condition-and-time.patch
  create mode 100644 
target/linux/mediatek/patches-5.4/0350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch
  create mode 100644 
target/linux/mediatek/patches-5.4/0351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch


Regards,

Hiroshi



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B

[INAGAKI Hiroshi]

Hello,

On 2020/12/20 4:38, Adrian Schmutzler wrote:

Hi,


-Original Message-
From: INAGAKI Hiroshi [mailto:musashino.o...@gmail.com]
Sent: Samstag, 19. Dezember 2020 14:54
To: Adrian Schmutzler ; openwrt-
de...@lists.openwrt.org
Subject: Re: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B

okay, looks like we can't fix it for now.

I'm considering to merge it in the current state, as the only unfixed issues 
appear to be the MAC address and the frequency limiting, so the device is 
generally working?

Yes, WRC-1167GS2-B and WRC-1167GST2 are generally working.


I've tried to mess with the DTSI files so we can reuse the existing 
mt7621_elecom_wrc-gs.dtsi. The result has been pushed to my staging:

https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/staging

Please tell me whether you like it or not. Not liking it is also okay ;-)

Best

Adrian


Thank you for your work, looks good to me :)


regards,

Hiroshi


Hello,

On 2020/12/19 9:22, Adrian Schmutzler wrote:

Hi,


Notes:

- there is no way to configure the correct MAC address for secondary

phy

 (5GHz) on MT7615D

This one seems to address a similar case (just scroll to the very bottom):

https://patchwork.ozlabs.org/project/openwrt/patch/1607939702-

85475-

1-

git-send-email-xinfa.d...@gl-inet.com/

Would this work for you as well (at least for the MAC address)?

Best

Adrian

I've tested it, but doesn't work.

I made the following change,

sorry, but would you test again please with the 10_fix_wifi_mac changes

and recent master?

There have been several changes to mt76 in

b837534f029da10abbd1069392867e0700134ace that might be
relevant/helping.

Best

Adrian

Thank you for letting me know.

I tried the same modification I did, but it still doesn't works. After that

bumping of mt76, secondary phy (ext_phy) uses the same MAC address with
primary

phy (for 2.4GHz) and the address for secondary phy cannot be configured by

10_fix_wifi_mac...


```

(WRC-1167GS2-B)

root@OpenWrt:/# iwinfo
wlan0 ESSID: unknown
    Access Point: 04:AB:18:58:2F:15
    Mode: Client  Channel: unknown (unknown)
    Tx-Power: 3 dBm  Link Quality: unknown/70
    Signal: unknown  Noise: -92 dBm
    Bit Rate: unknown
    Encryption: unknown
    Type: nl80211  HW Mode(s): 802.11bgnac
    Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
    TX power offset: none
    Frequency offset: none
    Supports VAPs: yes  PHY name: phy0

wlan1 ESSID: unknown
    Access Point: 04:AB:18:58:2F:15
    Mode: Client  Channel: unknown (unknown)
    Tx-Power: 20 dBm  Link Quality: unknown/70
    Signal: unknown  Noise: -92 dBm
    Bit Rate: unknown
    Encryption: unknown
    Type: nl80211  HW Mode(s): 802.11nac
    Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
    TX power offset: none
    Frequency offset: none
    Supports VAPs: yes  PHY name: phy1

root@OpenWrt:/# cat /sys/class/ieee80211/phy1/macaddress
04:ab:18:58:2f:15
root@OpenWrt:/# . /lib/functions.sh; . /lib/functions/system.sh
root@OpenWrt:/# mtd_get_mac_binary factory 0x4
04:ab:18:58:2f:16root@OpenWrt:/#

```

regards,

Hiroshi


```

diff --git
a/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
b/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
index b7a41f038c..f0093d4337 100644
---
a/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
+++
b/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
@@ -10,6 +10,14 @@ PHYNBR=${DEVPATH##*/phy}
    board=$(board_name)

    case "$board" in
+   elecom,wrc-1167gs2-b)
+   [ "$PHYNBR" = "1" ] && \
+   $(mtd_get_mac_binary factory 0x4) >
/sys${DEVPATH}/macaddress
+   ;;
+   elecom,wrc-1167gst2)
+   [ "$PHYNBR" = "1" ] && \
+   macaddr_add $(mtd_get_mac_binary factory
0xe006) 2 > /sys${DEVPATH}/macaddress
+   ;;
       linksys,ea7300-v1|\
       linksys,ea7300-v2|\
       linksys,ea7500-v2)

```

but iwinfo still reports the MAC address generated from phy0 by mt76

driver.

```

(WRC-1167GS2-B)

root@OpenWrt:/# iwinfo
wlan0 ESSID: unknown
     Access Point: 04:AB:18:58:2F:15
     Mode: Client  Channel: unknown (unknown)
     Tx-Power: 3 dBm  Link Quality: unknown/70
     Signal: unknown  Noise: unknown
     Bit Rate: unknown
     Encryption: unknown
     Type: nl80211  HW Mode(s): 802.11bgnac
     Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
     TX power offset: none
     Frequency offset: none
     Supports VAPs: yes  PHY name: phy0

wlan1 E

Re: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B

[INAGAKI Hiroshi]

Hello,

On 2020/12/19 9:22, Adrian Schmutzler wrote:

Hi,


Notes:

- there is no way to configure the correct MAC address for secondary phy
(5GHz) on MT7615D

This one seems to address a similar case (just scroll to the very bottom):

https://patchwork.ozlabs.org/project/openwrt/patch/1607939702-85475-

1-

git-send-email-xinfa.d...@gl-inet.com/

Would this work for you as well (at least for the MAC address)?

Best

Adrian

I've tested it, but doesn't work.

I made the following change,

sorry, but would you test again please with the 10_fix_wifi_mac changes and 
recent master?

There have been several changes to mt76 in 
b837534f029da10abbd1069392867e0700134ace that might be relevant/helping.

Best

Adrian


Thank you for letting me know.

I tried the same modification I did, but it still doesn't works. After 
that


bumping of mt76, secondary phy (ext_phy) uses the same MAC address 
with primary


phy (for 2.4GHz) and the address for secondary phy cannot be configured by

10_fix_wifi_mac...


```

(WRC-1167GS2-B)

root@OpenWrt:/# iwinfo
wlan0 ESSID: unknown
  Access Point: 04:AB:18:58:2F:15
  Mode: Client  Channel: unknown (unknown)
  Tx-Power: 3 dBm  Link Quality: unknown/70
  Signal: unknown  Noise: -92 dBm
  Bit Rate: unknown
  Encryption: unknown
  Type: nl80211  HW Mode(s): 802.11bgnac
  Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
  TX power offset: none
  Frequency offset: none
  Supports VAPs: yes  PHY name: phy0

wlan1 ESSID: unknown
  Access Point: 04:AB:18:58:2F:15
  Mode: Client  Channel: unknown (unknown)
  Tx-Power: 20 dBm  Link Quality: unknown/70
  Signal: unknown  Noise: -92 dBm
  Bit Rate: unknown
  Encryption: unknown
  Type: nl80211  HW Mode(s): 802.11nac
  Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
  TX power offset: none
  Frequency offset: none
  Supports VAPs: yes  PHY name: phy1

root@OpenWrt:/# cat /sys/class/ieee80211/phy1/macaddress
04:ab:18:58:2f:15
root@OpenWrt:/# . /lib/functions.sh; . /lib/functions/system.sh
root@OpenWrt:/# mtd_get_mac_binary factory 0x4
04:ab:18:58:2f:16root@OpenWrt:/#

```

regards,

Hiroshi


```

diff --git
a/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
b/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
index b7a41f038c..f0093d4337 100644
---
a/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
+++
b/target/linux/ramips/mt7621/base-
files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
@@ -10,6 +10,14 @@ PHYNBR=${DEVPATH##*/phy}
   board=$(board_name)

   case "$board" in
+   elecom,wrc-1167gs2-b)
+   [ "$PHYNBR" = "1" ] && \
+   $(mtd_get_mac_binary factory 0x4) >
/sys${DEVPATH}/macaddress
+   ;;
+   elecom,wrc-1167gst2)
+   [ "$PHYNBR" = "1" ] && \
+   macaddr_add $(mtd_get_mac_binary factory
0xe006) 2 > /sys${DEVPATH}/macaddress
+   ;;
      linksys,ea7300-v1|\
      linksys,ea7300-v2|\
      linksys,ea7500-v2)

```

but iwinfo still reports the MAC address generated from phy0 by mt76

driver.

```

(WRC-1167GS2-B)

root@OpenWrt:/# iwinfo
wlan0 ESSID: unknown
    Access Point: 04:AB:18:58:2F:15
    Mode: Client  Channel: unknown (unknown)
    Tx-Power: 3 dBm  Link Quality: unknown/70
    Signal: unknown  Noise: unknown
    Bit Rate: unknown
    Encryption: unknown
    Type: nl80211  HW Mode(s): 802.11bgnac
    Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
    TX power offset: none
    Frequency offset: none
    Supports VAPs: yes  PHY name: phy0

wlan1 ESSID: unknown
    Access Point: 86:AB:18:58:2F:15
    Mode: Client  Channel: unknown (unknown)
    Tx-Power: 3 dBm  Link Quality: unknown/70
    Signal: unknown  Noise: unknown
    Bit Rate: unknown
    Encryption: unknown
    Type: nl80211  HW Mode(s): 802.11nac
    Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
    TX power offset: none
    Frequency offset: none
    Supports VAPs: yes  PHY name: phy1

root@OpenWrt:/# cat /sys/class/ieee80211/phy1/macaddress
86:ab:18:58:2f:15

```


- Wi-Fi band on primary phy (2.4GHz) cannot be limitted by specifying
ieee80211-freq-limit
(fail to register secondary phy due to error)
- mtd-mac-address in the wifi node is required for using
mtd-mac-address-increment

Signed-off-by: INAGAKI Hiroshi 
---
   .../dts/mt7621_elecom_wrc-1167gs2-b.dts   |  57 ++
   .../dts/mt7621_elecom_wrc-1167gsxx.dtsi   | 179

++

   target/linux/ramips/image/mt7621.mk   |   

[PATCH 0/2] ramips: add support for ELECOM 2x2 11ac devices with MT7621

[INAGAKI Hiroshi]

_REJECT x_tables 
nf_reject_ipv6 nat46 ip6_tunnel tunnel6 leds_gpio gpio_button_hotplug
[   12.486568] CPU: 0 PID: 29 Comm: kworker/u8:1 Not tainted 5.4.75 #0
[   12.499091] Workqueue: phy0 0x86fb42e0
[   12.506553] Stack : 806071f8 87d3fc7c 8068 806c 87ce9080 80618d40 
8640123c 0009
[   12.523182] 865756a8 0001 0004 8007d620  0001 
87d3fc38 88093ab2
[   12.539810]   00dd  0030 00dd 
6870203a 30203079
[   12.556434]    00079d93  806e 
 8640123c
[   12.573060] 0009 865756a8 0001 0004 0001 80337ad4 
 8082
[   12.589686] ...
[   12.594544] Call Trace:
[   12.599424] [<8000b72c>] show_stack+0x30/0x100
[   12.608292] [<8055f738>] dump_stack+0xa4/0xdc
[   12.616970] [<8002c00c>] __warn+0xc0/0x10c
[   12.625117] [<8002c0b4>] warn_slowpath_fmt+0x5c/0xac
[   12.635072] [<8640123c>] wiphy_register+0xd80/0xd88 [cfg80211]
[   12.646838] [<865014ac>] ieee80211_register_hw+0x9bc/0xd8c [mac80211]
[   12.659716] [<86f523c0>] mt76_register_phy+0x18/0x38 [mt76]
[   12.670829] [<86fa31ec>] mt7615_register_ext_phy+0x274/0x2ac [mt7615_common]
[   12.684871] [<80045a70>] process_one_work+0x244/0x498
[   12.694919] [<80045e2c>] worker_thread+0x168/0x5ec
[   12.704459] [<8004b630>] kthread+0x140/0x148
[   12.712952] [<800068d8>] ret_from_kernel_thread+0x14/0x1c
[   12.724271] ---[ end trace 3c804470b09f795e ]---

[1]: 
https://github.com/openwrt/mt76/blob/066cc441eb8fcec7a3aeb6a320f5f9e6c21790f1/mt7615/debugfs.c#L522

INAGAKI Hiroshi (2):
  ramips: add support for ELECOM WRC-1167GS2-B
  ramips: add support for ELECOM WRC-1167GST2

 .../dts/mt7621_elecom_wrc-1167gs2-b.dts   |  57 ++
 .../ramips/dts/mt7621_elecom_wrc-1167gst2.dts |  57 ++
 .../dts/mt7621_elecom_wrc-1167gsxx.dtsi   | 179 ++
 target/linux/ramips/image/mt7621.mk   |  16 ++
 4 files changed, 309 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-b.dts
 create mode 100644 target/linux/ramips/dts/mt7621_elecom_wrc-1167gst2.dts
 create mode 100644 target/linux/ramips/dts/mt7621_elecom_wrc-1167gsxx.dtsi

-- 
2.28.0.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH RFT] ramips: mt7621: use lzma-loader for all devices

[INAGAKI Hiroshi]

Hello,

I tried this change in several routers.

In the following routers, kernel 5.4 without/with your patch works fine:

- Buffalo WSR-1166DHP
  U-Boot 1.1.3 (Dec 16 2014 - 14:38:30) 0.09, Ralink UBoot Version: 
4.2.1.0

- ELECOM WRC-1167GHBK2-S
  U-Boot 1.1.3 (Jan 23 2017 - 20:06:24), Ralink UBoot Version: 5.0.0.0
- I-O DATA WN-GX300GR
  U-boot Ver:1.0.4.11 2017/08/31 09:55:19, Senao Uboot Init Ver.1.0.0

But in I-O DATA WN-AX1167GR2, failed to start lzma-loader and hangs up:

===
    MT7621   stage1 code 10:33:11 (ASIC)
    CPU=5000 HZ BUS=1666 HZ
==
Change MPLL source from XTAL to CR...
do MEMPLL setting..
MEMPLL Config : 0x1110
3PLL mode + External loopback
=== XTAL-40Mhz === DDR-1200Mhz ===
PLL3 FB_DL: 0x4, 1/0 = 544/480 1100
PLL4 FB_DL: 0x7, 1/0 = 609/415 1D00
PLL2 FB_DL: 0x19, 1/0 = 568/456 6500
do DDR setting..[00320381]
Apply DDR3 Setting...(use customer AC)
  0    8   16   24   32   40   48   56   64   72   80 88   
96  104  112  120


:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0001:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0002:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0003:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0004:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0005:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0006:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0007:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0008:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0009:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
000A:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
000B:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
000C:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
000D:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
000E:|    0    0    0    0    0    0    0    0    0    0    0 1    
1    1    1    1
000F:|    0    0    0    0    0    0    1    1    1    1    1 1    
1    1    1    1
0010:|    1    1    1    1    1    1    1    1    1    1    1 0    
0    0    0    0
0011:|    1    1    1    1    1    0    0    0    0    0    0 0    
0    0    0    0
0012:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0013:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0014:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0015:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0016:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0017:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0018:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
0019:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
001A:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
001B:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
001C:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
001D:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
001E:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0
001F:|    0    0    0    0    0    0    0    0    0    0    0 0    
0    0    0    0

rank 0 coarse = 16
rank 0 fine = 40
B:|    0    0    0    0    0    0    0    0    0    1    1 1    0    
0    0    0

opt_dle value:10
DRAMC_R0DELDLY[018]=2121
==
    RX  DQS perbit delay software calibration
==
1.0-15 bit dq delay value
==
bit| 0  1  2  3  4  5  6  7  8  9
--
0 |    10 9 8 10 6 7 8 6 7 6
10 |    9 8 9 9 7 9
--

==
2.dqs window
x=pass dqs delay value (min~max)center
y=0-7bit DQ of every group
input delay:DQS0 =33 DQS1 = 33
==
bit DQS0 bit  DQS1
0  (1~65)33  8  (1~63)32
1  (1~66)33  9  (1~63)32
2  (0~62)31  10  (1~63)32
3  (1~66)33  11  (1~62)31
4  (1~63)32  12  (1~63)32
5  (1~66)33  13  (0~62)31
6 

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[INAGAKI Hiroshi]

On 2019/07/03 17:21, Kristian Evensen wrote:

Hi,

On Wed, Jul 3, 2019 at 9:55 AM Rafał Miłecki  wrote:

Why you didn't cc Alex, so he can ack your relicensing? You also
didn't care to let us know we need his ack!


While I don't appreciate your tone, I see now that I made a mistake.
When checking the history of the files that I relicense, there are
three more people that should be added to the CC-list (INAGAKI
Hiroshi, Mathias Kresin and Petr Štetiar). I have done so now, thanks
for spotting this and the mistake was of course not intentional.

BR,
Kristian
.



Sorry for late response, OK with me.

Acked-by: INAGAKI Hiroshi 

regards,
Hiroshi

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq806x: add ramdisk feature

[INAGAKI Hiroshi]

This commits adds "ramdisk" feature to ipq806x target. It helps
OpenWrt installing on some devices.

example:

- Buffalo WXR-2533DHP

  The U-Boot on WXR-2533DHP has recovery method. If boot it with
  holding "AOSS" button, it will try to downloading the firmware
  from TFTP server and booting with it. By using this, the user
  can install OpenWrt firmware without UART console access.

- NEC Aterm WG2600HP

  The U-Boot on WG2600HP is protected with the password. So users
  cannot access to the console on the U-Boot and cannot operate the
  commands necessary for installing OpenWrt.
  Therefore, on this device, when installing OpenWrt by the user,
  change bootcmd as follows so that WG2600HP downloads and executes
  initramfs image from TFTP server if necessary.

  ex.:
bootcmd="ping ${serverip} && tftpboot 0x4400 wg2600hp-initramfs.bin; 
bootipq"

Signed-off-by: INAGAKI Hiroshi 
---
 target/linux/ipq806x/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ipq806x/Makefile b/target/linux/ipq806x/Makefile
index 129ea2cda5..cd0e8b82ea 100644
--- a/target/linux/ipq806x/Makefile
+++ b/target/linux/ipq806x/Makefile
@@ -5,7 +5,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=ipq806x
 BOARDNAME:=Qualcomm Atheros IPQ806X
-FEATURES:=squashfs nand fpu
+FEATURES:=squashfs nand fpu ramdisk
 CPU_TYPE:=cortex-a15
 CPU_SUBTYPE:=neon-vfpv4
 MAINTAINER:=John Crispin 
-- 
2.17.1.windows.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: specify "firmware" partition format for remaining devices

[INAGAKI Hiroshi]

On 2018/12/14 1:16, Rafał Miłecki wrote:

From: Rafał Miłecki 

It results in calling the right MTD parser directly instead of trying
them one by one.

Signed-off-by: Rafał Miłecki 
---
I'm not sure about the AR670W.dts. It seems to be using WRG according to
the image generating code:
IMAGE/factory.bin := $$(sysupgrade_bin) | check-size (IMAGE_SIZE) | 
wrg-header wrgn16a_airlink_ar670w

On the other hand INAGAKI state it uses LZMA in the commit d70ec3008d4c
("ramips: specify "firmware" partition format").

INAGAKI: can you take a look at this, please?
---
  target/linux/ramips/dts/AR670W.dts  | 1 +
  target/linux/ramips/dts/DAP-1522-A1.dts | 1 +
  target/linux/ramips/dts/WCR-1166DS.dts  | 1 +
  3 files changed, 3 insertions(+)

diff --git a/target/linux/ramips/dts/AR670W.dts 
b/target/linux/ramips/dts/AR670W.dts
index 3ee39c1eb7..5f8a9a9593 100644
--- a/target/linux/ramips/dts/AR670W.dts
+++ b/target/linux/ramips/dts/AR670W.dts
@@ -39,6 +39,7 @@
};
  
  			partition@4 {

+   compatible = "wrg";
reg = <0x4 0x3c>;
label = "firmware";
};
diff --git a/target/linux/ramips/dts/DAP-1522-A1.dts 
b/target/linux/ramips/dts/DAP-1522-A1.dts
index bdd63ea96b..aad706df2e 100644
--- a/target/linux/ramips/dts/DAP-1522-A1.dts
+++ b/target/linux/ramips/dts/DAP-1522-A1.dts
@@ -40,6 +40,7 @@
};
  
  			partition@4 {

+   compatible = "wrg";
label = "firmware";
reg = <0x4 0x3a>;
};
diff --git a/target/linux/ramips/dts/WCR-1166DS.dts 
b/target/linux/ramips/dts/WCR-1166DS.dts
index ca715c8ba5..b8e86e496c 100644
--- a/target/linux/ramips/dts/WCR-1166DS.dts
+++ b/target/linux/ramips/dts/WCR-1166DS.dts
@@ -152,6 +152,7 @@
};
  
  			partition@5 {

+   compatible = "openwrt,trx";
label = "firmware";
reg = <0x5 0x7c>;
};



Hi Rafał,

I first made that commit in GitHub PR[1]. I thought that AR670W is using 
uImage because it is using wrg-header only for the factory and I wrote 
it as "uimage,denx" (it seems this was a misunderstanding).


After that, when checking by mkresin was done, the comment for AR670W 
was added into the commit message by him. At that time I was asked for a 
check, but I seem to have overlooked it.


Regards,
Hiroshi

[1]https://github.com/openwrt/openwrt/pull/1576

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 8/8] ipq806x: specify "firmware" partition format for NEC Aterm WG2600HP

[INAGAKI Hiroshi]

On 2018/12/10 1:44, Christian Lamparter wrote:

| For backwards compatibility partitions as direct subnodes of the flash device 
are
| supported. This use is discouraged.
| NOTE: also for backwards compatibility, direct subnodes that have a compatible
| string are not considered partitions, as they may be used for other bindings.

[0]

So it's because of backwards compatibility that this will never work.


Oh, I did not know it. Thanks for your information!

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel