Re: Regarding the real-name-only contribution policy
After the xz backdoor incident, I don't think it would be very wise to
start allowing usernames. Not just that, anyone with a full name that
cannot be tied to a real person through either public knowledge on the
internet, or information privately provided to the maintainers of the
project is a potential infiltrator in my eyes.
But, I think usernames should be allowed for submissions, and the
submissions must be reviewed thoroughly. Becoming a maintainer or a member
of the project on the other hand, must not be possible unless the person's
real life identity is privately provided.
Arınç
On 18/06/2024 21.01, sudobash418 wrote:
Hello everyone,
I am new to contributing to OpenWrt, and have recently opened a couple of PRs
against the openwrt repo:
- https://github.com/openwrt/openwrt/pull/15684
- https://github.com/openwrt/openwrt/pull/15695
I have authored and signed-off on each commit using my username, `sudoBash418`,
as I have for all my OSS contributions in the past.
At the time, the wiki page on submitting patches stated that using a "known
identity" was permitted [1].
[1]: https://openwrt.org/submitting-patches?rev=1704903503#submission_guidelines
However, I have since been informed that the official project policy requires a
"real name", and that a known identity such as my username does not qualify [2].
The wiki has since been updated to reflect this policy.
[2]: https://github.com/openwrt/openwrt/pull/15684#issuecomment-2172752403
I've now read through:
- The history of the submitting-patches page on the OpenWrt Wiki [3]
- The "Real name vs. known identity in contributions" thread on openwrt-adm,
started 2023-02-27 [4]
- A revival of that thread on openwrt-devel, started 2024-01-10 [5]
- The "here we are again: real name 'discussion'" thread on openwrt-devel,
started 2024-03-26 [6]
- Numerous PRs across the OpenWrt project, including:
- openwrt/openwrt#14380 ("ci: no longer require real name") [7]
- openwrt/packages#23084 ("ci: no longer require real name") [8]
- openwrt/packages#17993 ("[21.02] Bump yggdrasil to 0.4.3") [9]
- openwrt/packages#23072 ("yggdrasil-jumper: add new package") [10]
[3]: https://openwrt.org/submitting-patches?do=revisions
[4]: https://lists.openwrt.org/pipermail/openwrt-adm/2023-February/002358.html
[5]: https://lists.openwrt.org/pipermail/openwrt-devel/2024-January/042058.html
[6]: https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042472.html
[7]: https://github.com/openwrt/openwrt/pull/14380
[8]: https://github.com/openwrt/packages/pull/23084
[9]: https://github.com/openwrt/packages/pull/17993#issuecomment-1059783673
[10]: https://github.com/openwrt/packages/pull/23072#issuecomment-2023805052
As I understand it, the question of whether OpenWrt should change its policy on
names to match the Linux kernel's has never been *formally* answered (via a
vote), despite being raised over 15 months ago.
Therefore, I would like to request that the OpenWrt committers hold a formal
vote in accordance with the OpenWrt rules [11], and that they do so in a timely
manner (i.e. not stalling for months without cause).
[11]: https://openwrt.org/rules
Thank you from hopefully a future contributor,
sudoBash418
___
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: OpenWrt's out-of-tree 204-module_strip.patch causes issues
On 02/06/2024 00.48, Daniel Golle wrote: On 1 June 2024 20:23:20 UTC, "Arınç ÜNAL" wrote: I've been working on porting MP-DCCP to Teltonika SDK 7.6.10. The SDK is based off of OpenWrt, close to 22.03.6. After spending hours on figuring out why my MP-DCCP port works on the vanilla 5.10.201 but not OpenWrt's 5.10.201, I've started looking for OpenWrt's out-of-tree kernel patches. I was able to pinpoint it to target/linux/generic/hack-5.10/204-module_strip.patch. I see that this patch is still there for 6.6 on the main branch of the OpenWrt repository. I guess that's the price to pay for space reduction And I guess the fact that Teltonika bases their OS on OpenWrt is also because they manage to implement a dual-boot system with 16MB of flash, so there is some direct causal connection here, SPI-NOR still being much more reliable and cheaper than an eMMC which could fit Debian or whatever other OS... Anyway, does that warning also occur if CONFIG_MODULE_STRIPPED isn't selected? And is there any functional impact besides that warning? The warning doesn't occur when CONFIG_MODULE_STRIPPED isn't selected. internal_create_group() will return -EINVAL when this warning is caused so it breaks functionality. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt's out-of-tree 204-module_strip.patch causes issues
I've been working on porting MP-DCCP to Teltonika SDK 7.6.10. The SDK is based off of OpenWrt, close to 22.03.6. After spending hours on figuring out why my MP-DCCP port works on the vanilla 5.10.201 but not OpenWrt's 5.10.201, I've started looking for OpenWrt's out-of-tree kernel patches. I was able to pinpoint it to target/linux/generic/hack-5.10/204-module_strip.patch. I see that this patch is still there for 6.6 on the main branch of the OpenWrt repository. For my case, I just removed this patch and moved on. I'm only sending this email as proof that OpenWrt's out-of-tree patches cause issues. [1.897757] [ cut here ] [1.902441] WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:116 internal_create_group+0x3ac/0x3d4 [1.911179] Modules linked in: [1.914253] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.201 #0 [1.920346] Hardware name: Mediatek Cortex-A7 (Device Tree) [1.925936] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [1.933688] [] (show_stack) from [] (dump_stack+0x88/0x9c) [1.940917] [] (dump_stack) from [] (__warn+0x9c/0xf8) [1.947796] [] (__warn) from [] (warn_slowpath_fmt+0x68/0x78) [1.955287] [] (warn_slowpath_fmt) from [] (internal_create_group+0x3ac/0x3d4) [1.964258] [] (internal_create_group) from [] (mpdccp_link_sysfs_init+0x90/0xb4) [1.973489] [] (mpdccp_link_sysfs_init) from [] (mpdccp_link_module_init+0x24/0xdc) [1.982889] [] (mpdccp_link_module_init) from [] (do_one_initcall+0x54/0x1f4) [1.991769] [] (do_one_initcall) from [] (kernel_init_freeable+0x22c/0x280) [2.000474] [] (kernel_init_freeable) from [] (kernel_init+0x8/0x118) [2.008657] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [2.016229] Exception stack(0xc1079fb0 to 0xc1079ff8) [2.021282] 9fa0: [2.029465] 9fc0: [2.037645] 9fe0: 0013 [2.044348] ---[ end trace a1a1b229e3c1a883 ]--- Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/2] Add support for ASUS RT-AC3200 and ASUS RT-AC5300
Hello.
This patch series brings support for ASUS RT-AC3200 and ASUS RT-AC5300 on
OpenWrt.
Note to Rafał, please apply this after backporting the device tree patches
for these devices.
Signed-off-by: Arınç ÜNAL
---
Arınç ÜNAL (2):
bcm53xx: add support for ASUS RT-AC3200 and ASUS RT-AC5300
packages: nvram: add asus,rt-ac{3200,5300} to set_wireless_led_behaviour
package/utils/nvram/Makefile | 2 +-
package/utils/nvram/files/nvram-bcm53xx.init | 11 +--
target/linux/bcm53xx/image/Makefile | 16
3 files changed, 26 insertions(+), 3 deletions(-)
---
base-commit: 1b190dfd3ae2f9317c0dbca3123ed6c92701489c
change-id: 20240428-asus-rt-ac3200-ac5300-909fa1c42a37
Best regards,
--
Arınç ÜNAL
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] packages: nvram: add asus,rt-ac{3200,5300} to set_wireless_led_behaviour
From: Arınç ÜNAL
Add ASUS RT-AC3200 and ASUS RT-AC5300 to the set wireless LED behaviour
quirk. ASUS RT-AC3200's wireless chip is different than ASUS RT-AC5300's,
the environment variables for it are 0:ledbh10 and 1:ledbh10.
Signed-off-by: Arınç ÜNAL
---
package/utils/nvram/Makefile | 2 +-
package/utils/nvram/files/nvram-bcm53xx.init | 11 +--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/package/utils/nvram/Makefile b/package/utils/nvram/Makefile
index 8547bfa2d6..ef65ae0cc2 100644
--- a/package/utils/nvram/Makefile
+++ b/package/utils/nvram/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=nvram
-PKG_RELEASE:=12
+PKG_RELEASE:=13
PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)
diff --git a/package/utils/nvram/files/nvram-bcm53xx.init
b/package/utils/nvram/files/nvram-bcm53xx.init
index f47c944897..d17d301c45 100755
--- a/package/utils/nvram/files/nvram-bcm53xx.init
+++ b/package/utils/nvram/files/nvram-bcm53xx.init
@@ -19,16 +19,23 @@ clear_partialboots() {
set_wireless_led_behaviour() {
# set Broadcom wireless LED behaviour for both radios
- # 0:ledbh9 -> Behaviour of 2.4GHz LED
- # 1:ledbh9 -> Behaviour of 5GHz LED
+ # 0:ledbh9 -> Behaviour of 2.4GHz LED of Broadcom BCM4366
+ # 1:ledbh9 -> Behaviour of 5GHz LED of Broadcom BCM4366
+ # 0:ledbh10 -> Behaviour of 2.4GHz LED of Broadcom BCM43602
+ # 1:ledbh10 -> Behaviour of 5GHz LED of Broadcom BCM43602
# 0x7 makes the wireless LEDs on, when radios are enabled, and blink
when there's activity
case $(board_name) in
asus,rt-ac3100|\
+ asus,rt-ac5300|\
asus,rt-ac88u)
COMMIT=1
nvram set 0:ledbh9=0x7 set 1:ledbh9=0x7
;;
+ asus,rt-ac3200)
+ COMMIT=1
+ nvram set 0:ledbh10=0x7 set 1:ledbh10=0x7
+ ;;
esac
}
--
2.40.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] bcm53xx: add support for ASUS RT-AC3200 and ASUS RT-AC5300
From: Arınç ÜNAL ASUS RT-AC3200 and ASUS RT-AC5300 are AC3200 and AC5300 routers, respectively, featuring 5 Ethernet ports over the integrated Broadcom switch. ASUS RT-AC3200 hardware info: * Processor: Broadcom BCM4709A0 dual-core @ 1.0 GHz * Switch: BCM53012 in BCM4709A0 * DDR3 RAM: 256 MB * Flash: 128 MB * 2.4GHz: BCM43602 3x3 single chip 802.11b/g/n SoC * 5GHz: BCM43602 3x3 two chips 802.11a/n/ac SoC * Ports: 4 LAN Ports, 1 WAN Port ASUS RT-AC5300 hardware info: * Processor: Broadcom BCM4709C0 dual-core @ 1.4 GHz * Switch: BCM53012 in BCM4709C0 * DDR3 RAM: 512 MB * Flash: 128 MB * 2.4GHz: BCM4366 4x4 single chip 802.11b/g/n SoC * 5GHz: BCM4366 4x4 two chips 802.11a/n/ac SoC * Ports: 4 LAN Ports, 1 WAN Port Flashing instructions: * Boot to CFE Recovery Mode by holding the reset button while power-on. * Connect to the router with an ethernet cable. * Set IPv4 address of the computer to 192.168.1.2 subnet 255.255.255.0. * Head to http://192.168.1.1. * Reset NVRAM. * Upload the OpenWrt image. CFE bootloader may reject flashing the image due to image integrity check. In that case, follow the instructions below. * Rename the OpenWrt image as firmware.trx. * Run a TFTP server and make it serve the firmware.trx file. * Run the URL below on a browser or curl. http://192.168.1.1/do.htm?cmd=flash+-noheader+192.168.1.2:firmware.trx+flash0.trx Signed-off-by: Arınç ÜNAL --- target/linux/bcm53xx/image/Makefile | 16 1 file changed, 16 insertions(+) diff --git a/target/linux/bcm53xx/image/Makefile b/target/linux/bcm53xx/image/Makefile index 88590c3755..a263e2caed 100644 --- a/target/linux/bcm53xx/image/Makefile +++ b/target/linux/bcm53xx/image/Makefile @@ -180,6 +180,22 @@ define Device/asus_rt-ac3100 endef TARGET_DEVICES += asus_rt-ac3100 +define Device/asus_rt-ac3200 + $(call Device/asus) + DEVICE_MODEL := RT-AC3200 + DEVICE_PACKAGES := $(BRCMFMAC_43602A1) $(USB3_PACKAGES) + ASUS_PRODUCTID := RT-AC3200 +endef +TARGET_DEVICES += asus_rt-ac3200 + +define Device/asus_rt-ac5300 + $(call Device/asus) + DEVICE_MODEL := RT-AC5300 + DEVICE_PACKAGES := $(BRCMFMAC_4366B1) $(BRCMFMAC_4366C0) $(USB3_PACKAGES) + ASUS_PRODUCTID := RT-AC5300 +endef +TARGET_DEVICES += asus_rt-ac5300 + define Device/asus_rt-ac56u $(call Device/asus) DEVICE_MODEL := RT-AC56U -- 2.40.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt Summit 2024 & Battlemesh v16 Announcement
Hello everyone! We're doing an OpenWrt summit this year. We're inviting all OpenWrt enthusiasts to join us at the event. We will auction off one or two OpenWrt One. And we will have a big cake for OpenWrt's 20 year anniversary. It's going to be a relaxed event full of social activities with visits to very special places. Date: 18-19 May 2024, 2 days Venue: Tatlısu/Ακάνθου/Akanthou, Cyprus We're also hosting the Battlemesh v16 event starting 15 May 2024. We have visits to very special places on 15 and 19 May. I suggest arriving in Cyprus on 14 May and departing on 20 May. The event is free of charge and open for all. Registering: Add yourself to the participants list. I will use the participants list to fill the visit request form to enter the Nicosia airport, read the event page below for more information. If you'd rather not have your name there, please send an email to the organisation team with the same information displayed on the participants list. https://www.battlemesh.org/BattleMeshV16/Participants Accomodation Package: We've agreed on a discounted price with the Olive Tree Hotel. Single room 60€ per night, double room 80€ per night. Breakfast and dinner is included. The hotel guarantees availability to host 50 people for a 6-night stay; check-in on 14 May and check-out on 20 May. Please make a reservation by adding yourself to the participants list two days prior to your check-in date. Taking the accomodation package is, of course, optional. For those coming from abroad, we suggest you arrive to Larnaca International Airport. More information: https://www.battlemesh.org/BattleMeshV16 Please help us spread the word by sharing this announcement. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware
On 5.02.2024 22:10, Rafał Miłecki wrote: On 5.02.2024 15:15, Robert Marko wrote: On Mon, 5 Feb 2024 at 14:23, Rafał Miłecki wrote: From: Rafał Miłecki Aquantia AQR113C is PHY that needs loading a firmware. Some devices may have it stored on flash and some need filesystem to provide it. MediaTek holds its own AQR113C firmware file for its boards. Package it. Hi Rafal, not going into details of this patch, but what is the license situation with redistributing the AQR firmware? Good question. I don't know. Cc linux-mediatek@ Can we get some licensing help, please? Initial firmware file Rhe-05.06-Candidate7-AQR_Mediatek_23B_StartOff_ID45623_VER36657.cld was added in the commit: commit 24ba51c5be18613127b2d8407b0223174624b130 Author: developer Date: Tue Nov 15 11:22:46 2022 +0800 [][kernel][mt7988][eth][Change AQR113C firmware download method to MDIO gangload] [Description] Change AQR113C firmware download method to MDIO gangload. If without this patch, AQR113C cannot boot from MDIO gangload. [Release-log] N/A Change-Id: Iddc29f5e1c73c772bcea9313938b6daccc10025a Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/6781059 with not licensing details. Later there was a firmware update update handled by adding file: Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld in the commit: commit 405b1e31f924b97d379719fb39f0d28c0fac43a9 Author: developer Date: Tue Mar 28 17:00:41 2023 +0800 [][kernel][mt7988][eth][Fix AQR113C 5GBASE-T compliance test mode4 tone1 fail issue] [Description] Fix AQR113C 5GBASE-T compliance test mode4 tone1 fail issue by updating firmware version to Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld. If without this patch, AQR113C might not pass the 5GBASE-T mode4 tone1 items for the compliance test. [Release-log] N/A Change-Id: I3b2c6e6cf1a6ba8183daa7e30110ff2c839c5989 Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/7305781 but again with not licensing info. I also can't find any readme file specifying licensing of those files. Maybe these should be submitted to the linux-firmware repository (by MediaTek or with MediaTek's approval) and the license specified on the WHENCE file. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
John hello. I like this project quite a lot. I'm very excited to see it happen and would love to be involved! The company I work with, Xeront, has some PCB designs of their own. I can happily connect you with folks for any discussions about the electronic engineering and manufacturing aspects of the project, should you need. We're here to help! On 9.01.2024 13:49, John Crispin wrote: How will the device be distributed? OpenWrt itself cannot handle this for a ton of reasons. This is why we spoke with the SFC early. The idea is that BPi will distribute the device using the already established channels and for every device sold a donation will be made to ourSFC earmarked fund for OpenWrt. This money can then be used to cover hosting expenses or maybe an OpenWrt summit. I've been organising an OpenWrt summit in Cyprus along with Battlemesh v16 in May. I've been coordinating with Hauke on this. I've made a small announcement here [1] giving out the dates for the summit, 18-19 May 2024. This project would be a great talking point for the summit. If you or anyone on the list can give us a hand with funding the event, and finding local folks to help in the field, that'd be great. [1] http://lists.openwrt.org/pipermail/openwrt-devel/2023-December/041957.html Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Battlemesh v16 x OpenWrt Summit Date Announcement
Hello everyone! Thanks to all who voted on the polls, we have decided the dates for the Battlemesh v16 and OpenWrt Summit joint event. Date: 15-19 May 2024, 5 days Location: Kyrenia/Girne/Κερύνεια The OpenWrt Summit will be held on 18-19 May 2024. This is a small announcement for people that need to make flight bookings and arrange off-time as soon as possible. We will make a final announcement when the accomodation packages are ready. For those coming from abroad, we suggest you make your flight bookings to Larnaca International Airport. Please add yourself to the participants list if you're planning to attend to the event: https://www.battlemesh.org/BattleMeshV16/Participants We will start filling the Battlemesh v16 x OpenWrt Summit wiki page with more information: https://www.battlemesh.org/BattleMeshV16 Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
United Nations Announcement for Battlemesh x OpenWrt summit
Hey everyone. For the joint Battlemesh and OpenWrt summit event in May 2024, I, as the head organiser, have requested from the United Nations Peacekeeping Force in Cyprus (UNFICYP) to have a tour of the old Nicosia International Airport on the date of the event. For those of you who are not aware, the Nicosia International Airport is stuck in the buffer zone controlled by UNFICYP. It's like a time capsule in there, the ad posters from the 70s are still there. Today, I have received word from UNFICYP. They'd like to know which date and how many people we would like to bring with us on the tour. If you haven't done it yet, please vote on the poll which will determine the date and the amount of people joining the event. https://framadate.org/M4I9AYvKYypQTmGB Please vote also on this poll to determine when the OpenWrt summit should be done in coordination with Battlemesh. https://framadate.org/oGXhCQkygdpXGiTh Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Battlemesh x OpenWrt meeting in Cyprus?
I've just created a poll to decide the OpenWrt summit dates, see below. I also aim to see how many people are interested in the summit with this poll so please vote to decide the dates for the OpenWrt summit. https://framadate.org/oGXhCQkygdpXGiTh The "with Battlemesh" option represents the suggestion Hauke has made, the last 2 days of Battlemesh in parallel. Beware if you're on mobile, there are 6 choices. On 11/25/23 18:14, Hauke Mehrtens wrote: Hi Arınç and Paul, Thank you Arınç for organizing the Battlemesh in Cyprus. I will probably join the Battlemesh again, but I wont have much time to organize stuff. The following dates are currently proposed: May 15 - 19 May 22 - 26 Wednesday - Sunday, 5 days. Everyone who wants to join, please take part in the poll: https://framadate.org/M4I9AYvKYypQTmGB It is hard to get people together. I would suggest to plan an OpenWrt track on the last 2 days of Battlemesh in parallel. Who would like to join? Hauke On 11/25/23 12:59, Arınç ÜNAL wrote: Hello! I am the head organiser of the next Battlemesh. I will also be involved the most on organising the OpenWrt summit. Let me know if you've got any questions. My website from my email address includes the channels other than email to reach me more easily. Arınç On 23 November 2023 23:54:16 EET, Paul Spooren wrote: Hi all, While attending this years Battlemesh in Spain some fellow mesh people asked why there weren’t more OpenWrt people around. I’m guessing it was mostly due to the lack of communication in advance, so I’d like to raise the topic here: Are people from the OpenWrt community, specially members and maintainers interested in collaborating with and attending the Battlemesh next year? They’d do most of the heavy lifting and would offer us to take some slots/space to do our own little OpenWrt meeting (remember the good and productive days in Hamburg anno 2019). Ideally at least one OpenWrt member would join their organizing team, I could do it but would also be happy if someone else jumps in. The general idea is to have a week long Battlemesh event in Cyprus, the OpenWrt part could happen both within the week, before or after, the full length or only a weekend etc. To my knowledge Cyprus offers an easier VISA process so more folks could join, I remember last time people wouldn’t get a VISA in time. If we participate we should raise some donations to offer travel stipends and come up with some (lighting) talks and presentations. I think the timeframe is “somewhen in May 2024”, this will be further discussed on the Battlemesh mailing list. Looking forward to meet you all again! Sunshine, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Battlemesh x OpenWrt meeting in Cyprus?
Hello! I am the head organiser of the next Battlemesh. I will also be involved the most on organising the OpenWrt summit. Let me know if you've got any questions. My website from my email address includes the channels other than email to reach me more easily. Arınç On 23 November 2023 23:54:16 EET, Paul Spooren wrote: >Hi all, > >While attending this years Battlemesh in Spain some fellow mesh people asked >why there weren’t more OpenWrt people around. I’m guessing it was mostly due >to the lack of communication in advance, so I’d like to raise the topic here: >Are people from the OpenWrt community, specially members and maintainers >interested in collaborating with and attending the Battlemesh next year? > >They’d do most of the heavy lifting and would offer us to take some >slots/space to do our own little OpenWrt meeting (remember the good and >productive days in Hamburg anno 2019). Ideally at least one OpenWrt member >would join their organizing team, I could do it but would also be happy if >someone else jumps in. > >The general idea is to have a week long Battlemesh event in Cyprus, the >OpenWrt part could happen both within the week, before or after, the full >length or only a weekend etc. To my knowledge Cyprus offers an easier VISA >process so more folks could join, I remember last time people wouldn’t get a >VISA in time. > >If we participate we should raise some donations to offer travel stipends and >come up with some (lighting) talks and presentations. > >I think the timeframe is “somewhen in May 2024”, this will be further >discussed on the Battlemesh mailing list. > >Looking forward to meet you all again! > >Sunshine, >Paul >___ >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] bcm53xx: Unconditionally build U-Boot for DIR-890L
On 4.09.2023 23:58, Linus Walleij wrote: On Mon, Sep 4, 2023 at 12:03 PM Rafał Miłecki wrote: I don't see anything incorrect with Linus's original patch. Maybe we just have some dependency handling issue in u-boot generic .mk code? I have transient problem with the dependencies at times, then I just chose another target (entirely different!) in menuconfig and then back to the intended target. Problem fixed, dependency selected. It feels a bit shaky though, but usually all autobuilds work fine. Perhaps I wasn't clear enough to explain the issue. As Rafał has already said, there's nothing wrong with enabling the package when DIR-890L is selected as the device. The problem is when another device is selected. OpenWrt SDK shouldn't compile an image for the devices that are not selected on menuconfig. Yet it does anyway. This is the first time on the bcm53xx target that compiling the image for a device requires a package to be built first. This has exposed an underlying issue. When a device that is not DIR-890L is selected, the u-boot package won't be enabled. An image for DIR-890L will be attempted to be compiled which will fail because the u-boot package is not enabled. To make it clear, what needs fixing is making OpenWrt SDK not compile an image for the devices that are not selected on menuconfig. I don't know GNU Make very well to figure out why this happens on the bcm53xx target. I don't see this happening on the mt7621 subtarget of the ramips target. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 3/5] bcm53xx: Add support for D-Link DIR-890L
On 19.06.2023 09:36, Linus Walleij wrote:
The DIR-890L is very similar to DIR-885L, but has both USB2
and USB3. The signature for the wrgac36 board was copied from
DD-Wrt.
The DIR-890L bootstrap will only load the first 2 MB after
the SEAMA header in the NAND flash, uncompress it with LZMA
and execute it. Since the compressed kernel will not fit in
2 MB we have a problem. Solve this by putting a LZMA
compressed U-Boot into the first 128 KB of the flash
followed by the kernel. The bootstrap will then uncompress
and execute U-Boot and then we let U-Boot read the kernel
from flash and execute it.
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Rebased on master
- Test with kernel v6.1
ChangeLog v1->v2:
- Rebased on master
---
.../base-files/etc/uci-defaults/09_fix_crc| 3 ++-
.../base-files/lib/upgrade/platform.sh| 1 +
target/linux/bcm53xx/image/Makefile | 21 +++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
b/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
index 89ce8970d75a..c39625b86536 100644
--- a/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
+++ b/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
@@ -13,7 +13,8 @@ fixseama() {
}
case "$board" in
-dlink,dir-885l)
+dlink,dir-885l | \
+dlink,dir-890l)
fixseama
;;
*)
diff --git a/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh
b/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh
index 3ebde77d3f94..958a9fd247ab 100644
--- a/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh
@@ -37,6 +37,7 @@ platform_expected_image() {
case "$machine" in
"dlink,dir-885l") echo "seamaseal
wrgac42_dlink.2015_dir885l"; return;;
+ "dlink,dir-890l") echo "seamaseal
wrgac36_dlink.2013gui_dir890"; return;;
"luxul,abr-4500-v1") echo "lxl ABR-4500"; return;;
"luxul,xap-810-v1") echo "lxl XAP-810"; return;;
"luxul,xap-1410v1") echo "lxl XAP-1410"; return;;
diff --git a/target/linux/bcm53xx/image/Makefile
b/target/linux/bcm53xx/image/Makefile
index defa68e59f98..eb9f27c91eb5 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -88,6 +88,12 @@ define Build/luxul-lxl
mv $@.new $@
endef
+# Outputs a lzma compressed U-Boot that start at 0x8000
+# just like the D-Link boot loaders expect
+define Build/dlink-uboot-bin
+ $(STAGING_DIR_HOST)/bin/lzma e
$(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot.bin -d16 $@
+endef
I see this patch is applied. $(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot.bin
won't be created unless PACKAGE_u-boot-dir-890l is enabled. For some
reason, regardless of which device is selected on menuconfig, the OpenWrt
SDK will compile an image for every device on the target. So if any device
other than D-Link DIR-890L is selected on menuconfig,
PACKAGE_u-boot-dir-890l won't be enabled. Therefore, the compilation
process will fail while preparing an image for DIR-890L.
/mnt/Work/openwrt/staging_dir/host/bin/lzma e
/mnt/Work/openwrt/staging_dir/target-arm_cortex-a9_musl_eabi/image/dlink_dir-890l-u-boot.bin
-d16
/mnt/Work/openwrt/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/dlink_dir-890l-kernel.bin
Error: can not open input file
/mnt/Work/openwrt/staging_dir/target-arm_cortex-a9_musl_eabi/image/dlink_dir-890l-u-boot.bin
make[5]: *** [Makefile:536:
/mnt/Work/openwrt/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/dlink_dir-890l-kernel.bin]
Error 1
make[5]: Leaving directory '/mnt/Work/openwrt/target/linux/bcm53xx/image'
make[4]: *** [Makefile:30: install] Error 2
make[4]: Leaving directory '/mnt/Work/openwrt/target/linux/bcm53xx'
make[3]: *** [Makefile:11: install] Error 2
make[3]: Leaving directory '/mnt/Work/openwrt/target/linux'
time: target/linux/install#16.33#2.41#12.48
ERROR: target/linux failed to build.
make[2]: *** [target/Makefile:30: target/linux/install] Error 1
make[2]: Leaving directory '/mnt/Work/openwrt'
make[1]: *** [target/Makefile:24:
/mnt/Work/openwrt/staging_dir/target-arm_cortex-a9_musl_eabi/stamp/.target_install]
Error 2
make[1]: Leaving directory '/mnt/Work/openwrt'
make: *** [/mnt/Work/openwrt/include/toplevel.mk:232: world] Error 2
Arınç
+
define Build/seama-nand
# Seama entity
$(STAGING_DIR_HOST)/bin/oseama \
@@ -266,6 +272,21 @@ define Device/dlink_dir-885l
endef
TARGET_DEVICES += dlink_dir-885l
+define Device/dlink_dir-890l
+ DEVICE_VENDOR := D-Link
+ DEVICE_MODEL := DIR-890L
+ DEVICE_PACKAGES := $(BRCMFMAC_43602A1) $(USB2_PACKAGES) $(USB3_PACKAGES)
+ # Layout: U-boot (128kb max) followed by kernel and appended DTB.
+ # This is done because the boot loader will only read the first 2 MB
+ # from the flash and decompress the LZMA it finds
Re: [PATCH] bcm53xx: add nand subtarget
On 20.08.2023 23:54, Rafał Miłecki wrote: niedz., 20 sie 2023 o 20:50 Arınç ÜNAL napisał(a): On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" wrote: sob., 19 sie 2023 o 17:12 Arınç ÜNAL napisał(a): The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It causes the devices with NVRAM in NAND to bootloop. Create a subtarget for NAND devices and disable the driver on it. Disable NVMEM too as the bgmac_bcma driver will hang trying to retrieve the MAC address without NVMEM_BRCM_NVRAM enabled. Adding a new subtarget just because one driver doesn't work correctly is an overkill. I'll handle that in some simple solution after holidays. Rafał, you've been aware of this problem and reportedly working on at least diagnosing it for the last 6 months. You did not come up with anything yet. Forgive me if I find it hard to believe that you will come up with a solution in a short amount of time, if that's what you mean by after holidays as I don't know what holidays you're referring to. In the meantime, there is a good amount of users unable to use the newer OpenWrt versions on the affected devices because of a driver that provides a rather trivial feature. I would like these devices to work again as soon as possible as we've already lost a lot of time. To have these devices work again, I see these solutions: - First and the most obvious, fix the driver. I do not know the NVMEM subsystem well enough to do it and am currently not interested to spend time studying it. - Prevent the driver to read from the flash if NAND flash is detected. Once the underlying cause is fixed, this can then be reverted. Like I stated above, I lack the knowledge to do this. - This patch. It can be easily reverted in the future when or should the issue be fixed. - My other patch submitted here that disables the driver for the whole target. Currently, only four devices do not have NAND flash and two of these devices are not set to be compiled anyway. I'd rather prefer this than convoluting OpenWrt with another subtarget. I'd much rather prefer two devices not benefiting the future provided by this driver compared to a lot more devices being unable to boot. I feel like writing this mail has been a waste of time as lately I've never seen you reply or in any way acknowledge that you've read any of my responses, yet I've done it anyway, at least for the mailing list. I'm not going to argue I handled it properly. It looked at it once then forgot it. My maintenance time is very limited and I'm not denying this. I assumed holidays end for most people with the end of August. I'm on a 1-week holiday family trip and I don't have time for development or hardware for testing. In my very personal opinion I prefer to leave support for those devices broken for another week (given it has been 6 months now) rather than push a (in my opinion) pretty hacky workaround. I agree. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm53xx: add nand subtarget
On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" wrote: >sob., 19 sie 2023 o 17:12 Arınç ÜNAL napisał(a): >> The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It >> causes the devices with NVRAM in NAND to bootloop. Create a subtarget for >> NAND devices and disable the driver on it. >> >> Disable NVMEM too as the bgmac_bcma driver will hang trying to retrieve the >> MAC address without NVMEM_BRCM_NVRAM enabled. > >Adding a new subtarget just because one driver doesn't work correctly >is an overkill. > >I'll handle that in some simple solution after holidays. Rafał, you've been aware of this problem and reportedly working on at least diagnosing it for the last 6 months. You did not come up with anything yet. Forgive me if I find it hard to believe that you will come up with a solution in a short amount of time, if that's what you mean by after holidays as I don't know what holidays you're referring to. In the meantime, there is a good amount of users unable to use the newer OpenWrt versions on the affected devices because of a driver that provides a rather trivial feature. I would like these devices to work again as soon as possible as we've already lost a lot of time. To have these devices work again, I see these solutions: - First and the most obvious, fix the driver. I do not know the NVMEM subsystem well enough to do it and am currently not interested to spend time studying it. - Prevent the driver to read from the flash if NAND flash is detected. Once the underlying cause is fixed, this can then be reverted. Like I stated above, I lack the knowledge to do this. - This patch. It can be easily reverted in the future when or should the issue be fixed. - My other patch submitted here that disables the driver for the whole target. Currently, only four devices do not have NAND flash and two of these devices are not set to be compiled anyway. I'd rather prefer this than convoluting OpenWrt with another subtarget. I'd much rather prefer two devices not benefiting the future provided by this driver compared to a lot more devices being unable to boot. I feel like writing this mail has been a waste of time as lately I've never seen you reply or in any way acknowledge that you've read any of my responses, yet I've done it anyway, at least for the mailing list. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] bcm53xx: add nand subtarget
The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It causes the devices with NVRAM in NAND to bootloop. Create a subtarget for NAND devices and disable the driver on it. Disable NVMEM too as the bgmac_bcma driver will hang trying to retrieve the MAC address without NVMEM_BRCM_NVRAM enabled. Signed-off-by: Arınç ÜNAL --- target/linux/bcm53xx/Makefile| 8 +- target/linux/bcm53xx/generic/target.mk | 4 + target/linux/bcm53xx/image/Makefile | 338 +-- target/linux/bcm53xx/image/generic.mk| 43 +++ target/linux/bcm53xx/image/nand.mk | 293 target/linux/bcm53xx/nand/config-default | 3 + target/linux/bcm53xx/nand/target.mk | 6 + 7 files changed, 352 insertions(+), 343 deletions(-) create mode 100644 target/linux/bcm53xx/image/generic.mk create mode 100644 target/linux/bcm53xx/image/nand.mk create mode 100644 target/linux/bcm53xx/nand/config-default create mode 100644 target/linux/bcm53xx/nand/target.mk diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile index 84f08f1f80..6bf8ebbd18 100644 --- a/target/linux/bcm53xx/Makefile +++ b/target/linux/bcm53xx/Makefile @@ -7,17 +7,13 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=bcm53xx BOARDNAME:=Broadcom BCM47xx/53xx (ARM) -FEATURES:=squashfs nand usb pci pcie gpio pwm +FEATURES:=squashfs usb pci pcie gpio pwm CPU_TYPE:=cortex-a9 -SUBTARGETS:=generic +SUBTARGETS:=generic nand KERNEL_PATCHVER:=5.15 KERNEL_TESTING_PATCHVER:=6.1 -define Target/Description - Build firmware images for Broadcom based BCM47xx/53xx routers with ARM CPU, *not* MIPS. -endef - include $(INCLUDE_DIR)/target.mk KERNELNAME:=zImage dtbs diff --git a/target/linux/bcm53xx/generic/target.mk b/target/linux/bcm53xx/generic/target.mk index f5cb1fb19b..2b55583077 100644 --- a/target/linux/bcm53xx/generic/target.mk +++ b/target/linux/bcm53xx/generic/target.mk @@ -1 +1,5 @@ BOARDNAME:=Generic + +define Target/Description + Build firmware images for Broadcom based BCM47xx/53xx routers with ARM CPU, *not* MIPS. +endef diff --git a/target/linux/bcm53xx/image/Makefile b/target/linux/bcm53xx/image/Makefile index 5158b432b3..4af12d0222 100644 --- a/target/linux/bcm53xx/image/Makefile +++ b/target/linux/bcm53xx/image/Makefile @@ -105,22 +105,6 @@ define Build/seama-nand -i $@.entity endef -define Build/dwl8610ap-image - mkdir -p $@.tmptar - # The DWL8610AP pretends to be a Broadcom reference design - echo "bcm953012er" > $@.tmptar/board - echo "LVL7" > $@.tmptar/model - # Something high beyond what D-Link has put out - echo "5.0.0.0" > $@.tmptar/version - # Create rootfs.bin, this is just a NAND image including everything - cp $@ $@.tmptar/rootfs.bin - # Hash the rootfs.bin - cat $@.tmptar/rootfs.bin | md5sum > $@.tmptar/rootfs.md5 - cd $@.tmptar && tar -c -f $@.new * - rm -rf $@.tmptar - mv $@.new $@ -endef - DEVICE_VARS += ASUS_PRODUCTID DEVICE_VARS += BUFFALO_TAG_PLATFORM BUFFALO_TAG_VERSION BUFFALO_TAG_MINOR DEVICE_VARS += SIGNATURE @@ -159,54 +143,6 @@ define Device/asus IMAGE/trx := append-ubi | trx-nand | asus-trx endef -define Device/asus_rt-ac3100 - $(call Device/asus) - DEVICE_MODEL := RT-AC3100 - DEVICE_PACKAGES := $(BRCMFMAC_4366B1) $(BRCMFMAC_4366C0) $(USB3_PACKAGES) - ASUS_PRODUCTID := RT-AC3100 -endef -TARGET_DEVICES += asus_rt-ac3100 - -define Device/asus_rt-ac56u - $(call Device/asus) - DEVICE_MODEL := RT-AC56U - DEVICE_PACKAGES := $(B43) $(USB3_PACKAGES) - ASUS_PRODUCTID := RT-AC56U -endef -TARGET_DEVICES += asus_rt-ac56u - -define Device/asus_rt-ac68u - $(call Device/asus) - DEVICE_MODEL := RT-AC68U - DEVICE_PACKAGES := $(USB3_PACKAGES) - ASUS_PRODUCTID := RT-AC68U -endef -TARGET_DEVICES += asus_rt-ac68u - -define Device/asus_rt-ac87u - $(call Device/asus) - DEVICE_MODEL := RT-AC87U - DEVICE_PACKAGES := $(USB3_PACKAGES) - ASUS_PRODUCTID := RT-AC87U -endef -TARGET_DEVICES += asus_rt-ac87u - -define Device/asus_rt-ac88u - $(call Device/asus) - DEVICE_MODEL := RT-AC88U - DEVICE_PACKAGES := $(BRCMFMAC_4366B1) $(BRCMFMAC_4366C0) $(USB3_PACKAGES) - ASUS_PRODUCTID := RT-AC88U -endef -TARGET_DEVICES += asus_rt-ac88u - -define Device/asus_rt-n18u - $(call Device/asus) - DEVICE_MODEL := RT-N18U - DEVICE_PACKAGES := $(USB3_PACKAGES) - ASUS_PRODUCTID := RT-N18U -endef -TARGET_DEVICES += asus_rt-n18u - # Buffalo devices have TFTP recovery mode which can work nicely with initramfs # kernels. # We should have two initramfs images for Buffalo: plain initramfs kernel and @@ -218,186 +154,18 @@ define Device/buffalo/Default KERNEL_INITRAMFS = $$(KERNEL) endef -define Device/buffalo_wxr-1900dhp - $(call Device/buffalo/Default) - DEVICE_MODEL := WXR-1900DHP - DEVICE_PACKAGES := $(USB3_PACKAGES) -endef -TARGET_DEVICES += buffalo_wxr-1900dhp - -define Devi
[PATCH 1/3] bcm53xx: backport DT changes for ASUS RT-AC3100 queued for v6.6
Backport the patch that adds the DT for ASUS RT-AC3100.
Signed-off-by: Arınç ÜNAL
---
...s-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch | 431 ++
...RM-BCM5301X-Add-DT-for-Netgear-R7900.patch | 2 +-
...s-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch | 431 ++
...RM-BCM5301X-Add-DT-for-Netgear-R7900.patch | 2 +-
4 files changed, 864 insertions(+), 2 deletions(-)
create mode 100644
target/linux/bcm53xx/patches-5.15/037-v6.6-0016-ARM-dts-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch
create mode 100644
target/linux/bcm53xx/patches-6.1/032-v6.6-0016-ARM-dts-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch
diff --git
a/target/linux/bcm53xx/patches-5.15/037-v6.6-0016-ARM-dts-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch
b/target/linux/bcm53xx/patches-5.15/037-v6.6-0016-ARM-dts-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch
new file mode 100644
index 00..6c2af02589
--- /dev/null
+++
b/target/linux/bcm53xx/patches-5.15/037-v6.6-0016-ARM-dts-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch
@@ -0,0 +1,431 @@
+From 2900083269f7c0f0ff430bffc6ced2038aed9b6b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=
+Date: Thu, 3 Aug 2023 10:14:54 +0300
+Subject: [PATCH] ARM: dts: BCM5301X: Add DT for ASUS RT-AC3100
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+ASUS RT-AC3100 is ASUS RT-AC88U without the external switch. Move the
+shared bindings to bcm47094-asus-rt-ac3100.dtsi.
+
+Remove the fixed-link node on port@7 as commit ba4aebce23b2 ("ARM: dts:
+BCM5301X: Describe switch ports in the main DTS") states it's not
+necessary.
+
+Replace the copyright notice with an author notice.
+
+Rename the model name from Asus to ASUS on bcm47094-asus-rt-ac88u.dts.
+
+Signed-off-by: Arınç ÜNAL
+Reviewed-by: Linus Walleij
+Link: https://lore.kernel.org/r/20230803071454.5902-2-arinc.u...@arinc9.com
+Signed-off-by: Florian Fainelli
+---
+ arch/arm/boot/dts/Makefile | 1 +
+ .../dts/bcm47094-asus-rt-ac3100.dts | 23 +++
+ .../dts/bcm47094-asus-rt-ac3100.dtsi | 163 ++
+ .../dts/bcm47094-asus-rt-ac88u.dts | 155 +
+ 4 files changed, 190 insertions(+), 152 deletions(-)
+ create mode 100644 arch/arm/boot/dts/bcm47094-asus-rt-ac3100.dts
+ create mode 100644 arch/arm/boot/dts/bcm47094-asus-rt-ac3100.dtsi
+
+--- a/arch/arm/boot/dts/Makefile
b/arch/arm/boot/dts/Makefile
+@@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
+ bcm4709-netgear-r7000.dtb \
+ bcm4709-netgear-r8000.dtb \
+ bcm4709-tplink-archer-c9-v1.dtb \
++ bcm47094-asus-rt-ac3100.dtb \
+ bcm47094-asus-rt-ac88u.dtb \
+ bcm47094-dlink-dir-885l.dtb \
+ bcm47094-dlink-dir-890l.dtb \
+--- /dev/null
b/arch/arm/boot/dts/bcm47094-asus-rt-ac3100.dts
+@@ -0,0 +1,23 @@
++// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
++/*
++ * Author: Arınç ÜNAL
++ */
++
++/dts-v1/;
++
++#include "bcm47094-asus-rt-ac3100.dtsi"
++
++/ {
++ compatible = "asus,rt-ac3100", "brcm,bcm47094", "brcm,bcm4708";
++ model = "ASUS RT-AC3100";
++
++ nvram@1c08 {
++ et0macaddr: et0macaddr {
++ };
++ };
++};
++
++&gmac0 {
++ nvmem-cells = <&et0macaddr>;
++ nvmem-cell-names = "mac-address";
++};
+--- /dev/null
b/arch/arm/boot/dts/bcm47094-asus-rt-ac3100.dtsi
+@@ -0,0 +1,163 @@
++// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
++/*
++ * Author: Arınç ÜNAL
++ */
++
++#include "bcm47094.dtsi"
++#include "bcm5301x-nand-cs0-bch8.dtsi"
++
++/ {
++ chosen {
++ bootargs = "earlycon";
++ };
++
++ memory@0 {
++ device_type = "memory";
++ reg = <0x 0x0800>,
++<0x8800 0x1800>;
++ };
++
++ nvram@1c08 {
++ compatible = "brcm,nvram";
++ reg = <0x1c08 0x0018>;
++ };
++
++ leds {
++ compatible = "gpio-leds";
++
++ led-power {
++ label = "white:power";
++ gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
++ linux,default-trigger = "default-on";
++ };
++
++ led-wan-red {
++ label = "red:wan";
++ gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
++ };
++
++ led-lan {
++ label = "white:lan";
++ gpios = <&chipcommon 21 GPIO_ACTIVE_LOW>;
++ };
++
++ led-usb2 {
++ label = "white:usb2";
++ gpios = <&chipcommon 16 GPIO_ACTIVE_LOW>;
++ trigger-sources = <&ehci_port2>;
++
[PATCH 2/3] bcm53xx: add support for ASUS RT-AC3100
ASUS RT-AC3100 is ASUS RT-AC88U without the external switch. OpenWrt forum users effortless and ktmakwana have confirmed that there are revisions with either 4366b1 or 4366c0 wireless chips. Therefore, include firmware for 4366b1 along with 4366c0. This way, all hardware revisions of the router will be supported by having brcmfmac use the firmware file for the wireless chip it detects. Signed-off-by: Arınç ÜNAL --- target/linux/bcm53xx/image/Makefile | 8 1 file changed, 8 insertions(+) diff --git a/target/linux/bcm53xx/image/Makefile b/target/linux/bcm53xx/image/Makefile index b1eb4277b7..5158b432b3 100644 --- a/target/linux/bcm53xx/image/Makefile +++ b/target/linux/bcm53xx/image/Makefile @@ -159,6 +159,14 @@ define Device/asus IMAGE/trx := append-ubi | trx-nand | asus-trx endef +define Device/asus_rt-ac3100 + $(call Device/asus) + DEVICE_MODEL := RT-AC3100 + DEVICE_PACKAGES := $(BRCMFMAC_4366B1) $(BRCMFMAC_4366C0) $(USB3_PACKAGES) + ASUS_PRODUCTID := RT-AC3100 +endef +TARGET_DEVICES += asus_rt-ac3100 + define Device/asus_rt-ac56u $(call Device/asus) DEVICE_MODEL := RT-AC56U -- 2.39.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] packages: nvram: add asus,rt-ac3100 to set_wireless_led_behaviour quirk
Add ASUS RT-AC3100 to the set wireless LED behaviour quirk.
Signed-off-by: Arınç ÜNAL
---
package/utils/nvram/Makefile | 2 +-
package/utils/nvram/files/nvram-bcm53xx.init | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/utils/nvram/Makefile b/package/utils/nvram/Makefile
index b957211283..8547bfa2d6 100644
--- a/package/utils/nvram/Makefile
+++ b/package/utils/nvram/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=nvram
-PKG_RELEASE:=11
+PKG_RELEASE:=12
PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)
diff --git a/package/utils/nvram/files/nvram-bcm53xx.init
b/package/utils/nvram/files/nvram-bcm53xx.init
index 0502cd28b6..2e9c9f3fce 100755
--- a/package/utils/nvram/files/nvram-bcm53xx.init
+++ b/package/utils/nvram/files/nvram-bcm53xx.init
@@ -23,6 +23,7 @@ set_wireless_led_behaviour() {
# 0x7 makes the wireless LEDs on, when radios are enabled, and blink
when there's activity
case $(board_name) in
+ asus,rt-ac3100|\
asus,rt-ac88u)
COMMIT=1
nvram set 0:ledbh9=0x7 set 1:ledbh9=0x7
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
bgmac_bcma driver hangs if NVMEM driver is enabled
Hi. The bgmac_bcma driver will hang trying to retrieve the MAC address if NVMEM is enabled without NVMEM_BRCM_NVRAM enabled. The device bootloops if NVMEM_BRCM_NVRAM is enabled so I can't tell whether the bgmac_bcma driver would still hang if NVMEM_BRCM_NVRAM was enabled and didn't cause bootloop. I've attached the kernel log with NVMEM enabled and disabled. Tested on ASUS RT-AC88U. An nvram node, the variable that stores the MAC address, and the bindings to retrieve the MAC address from the variable for gmac1 are defined on the bindings for this device. Arınç[0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.10.176 (arinc9@arinc9-PC) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2.0 r20028-43d71ad93e) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Thu Apr 27 20:28:15 2023 [0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Asus RT-AC88U [0.00] earlycon: ns16550 at MMIO 0x18000300 (options '115200n8') [0.00] printk: bootconsole [ns16550] enabled [0.00] Memory policy: Data cache writealloc [0.00] Hit pending asynchronous external abort (FSR=0x1c06) during first unmask, this is most likely caused by a firmware/bootloader bug. [0.00] Zone ranges: [0.00] Normal [mem 0x-0x07ff] [0.00] HighMem [mem 0x0800-0x9fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x07ff] [0.00] node 0: [mem 0x8800-0x9fff] [0.00] Initmem setup node 0 [mem 0x-0x9fff] [0.00] On node 0 totalpages: 131072 [0.00] Normal zone: 288 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32768 pages, LIFO batch:7 [0.00] HighMem zone: 98304 pages, LIFO batch:31 [0.00] percpu: Embedded 14 pages/cpu s27340 r8192 d21812 u57344 [0.00] pcpu-alloc: s27340 r8192 d21812 u57344 alloc=14*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 130784 [0.00] Kernel command line: earlycon [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 509296K/524288K available (5993K kernel code, 562K rwdata, 1360K rodata, 1024K init, 286K bss, 14992K reserved, 0K cma-reserved, 393216K highmem) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] rcu: Hierarchical RCU implementation. [0.00] Tracing variant of Tasks RCU enabled. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] L2C: DT/platform modifies aux control register: 0x0a13 -> 0x3a53 [0.00] L2C-310 enabling early BRESP for Cortex-A9 [0.00] L2C-310 full line of zeros enabled for Cortex-A9 [0.00] L2C-310 ID prefetch enabled, offset 1 lines [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled [0.00] L2C-310 cache controller enabled, 16 ways, 256 kB [0.00] L2C-310: CACHE_ID 0x41c8, AUX_CTRL 0x7e530001 [0.11] sched_clock: 64 bits at 700MHz, resolution 1ns, wraps every 4398046511103ns [0.008081] clocksource: arm_global_timer: mask: 0x max_cycles: 0xa17102bcf3, max_idle_ns: 440795224838 ns [0.019255] Switching to timer-based delay loop, resolution 1ns [0.025413] Calibrating delay loop (skipped), value calculated using timer frequency.. 1400.00 BogoMIPS (lpj=700) [0.036139] pid_max: default: 32768 minimum: 301 [0.040883] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.048306] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.056654] CPU: Testing write buffer coherency: ok [0.061607] CPU0: Spectre v2: using BPIALL workaround [0.066922] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.073127] Setting up static identity map for 0x10 - 0x10003c [0.079511] rcu: Hierarchical SRCU implementation. [0.084462] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build [0.092405] smp: Bringing up secondary CPUs ... [0.097593] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.097600] CPU1: Spectre v2: using BPIALL workaround [0.108473] smp: Brought up 1 node, 2 CPUs [0.112594] SMP: Total of 2 processors activated (2800.00 BogoMIPS). [0.119033] CPU: WARNING: CPU(s) started in w
Re: [PATCH] bcm53xx: disable NVMEM driver
On 1.08.2023 15:28, Arınç ÜNAL wrote: On 1.08.2023 15:16, Rafał Miłecki wrote: On 2023-08-01 12:42, Arınç ÜNAL wrote: The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It causes the devices with NVRAM in NAND, such as ASUS RT-AC88U, to bootloop. Until the driver is fixed, disable it. Driver works and it useful for non-NAND devices. By disabling it you regress those devices. Surely this can be handled better. How about making a subtarget for NAND devices? The kernel config will be separate so we can disable NVMEM for that subtarget. Do you approve this? I don't intend to send another patch for you to shoot down. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm53xx: disable NVMEM driver
On 1.08.2023 15:16, Rafał Miłecki wrote: On 2023-08-01 12:42, Arınç ÜNAL wrote: The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It causes the devices with NVRAM in NAND, such as ASUS RT-AC88U, to bootloop. Until the driver is fixed, disable it. Driver works and it useful for non-NAND devices. By disabling it you regress those devices. Surely this can be handled better. How about making a subtarget for NAND devices? The kernel config will be separate so we can disable NVMEM for that subtarget. You mentioned contacting Broadcom regarding this issue around 6 months ago. Any news on that? Disable NVMEM too as the bgmac_bcma driver will hang trying to retrieve the MAC address without NVMEM_BRCM_NVRAM enabled. This would be nice to fix instead hiding the bug. I've got no interest to learn the NVMEM subsystem to take a crack at fixing it at the moment. For now, the best I can do is send a separate mail to openwrt-devel as a mean to report this bug. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm53xx: disable NVMEM driver
I've attached the kernel log with NVMEM enabled and disabled for reference. Arınç On 1.08.2023 13:42, Arınç ÜNAL wrote: The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It causes the devices with NVRAM in NAND, such as ASUS RT-AC88U, to bootloop. Until the driver is fixed, disable it. Disable NVMEM too as the bgmac_bcma driver will hang trying to retrieve the MAC address without NVMEM_BRCM_NVRAM enabled. Link: https://forum.openwrt.org/t/asus-rt-ac88u-hw-a6-broken-in-22-03-3/147882/40 Signed-off-by: Arınç ÜNAL --- target/linux/bcm53xx/config-5.15 | 3 --- target/linux/bcm53xx/config-6.1 | 3 --- 2 files changed, 6 deletions(-) diff --git a/target/linux/bcm53xx/config-5.15 b/target/linux/bcm53xx/config-5.15 index 9cd1f079d1..6b7fa3c4ad 100644 --- a/target/linux/bcm53xx/config-5.15 +++ b/target/linux/bcm53xx/config-5.15 @@ -223,9 +223,6 @@ CONFIG_NET_FLOW_LIMIT=y CONFIG_NET_SELFTESTS=y CONFIG_NET_SWITCHDEV=y CONFIG_NR_CPUS=2 -CONFIG_NVMEM=y -CONFIG_NVMEM_BRCM_NVRAM=y -CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y diff --git a/target/linux/bcm53xx/config-6.1 b/target/linux/bcm53xx/config-6.1 index d96beb687d..c9d9dbd652 100644 --- a/target/linux/bcm53xx/config-6.1 +++ b/target/linux/bcm53xx/config-6.1 @@ -224,9 +224,6 @@ CONFIG_NET_FLOW_LIMIT=y CONFIG_NET_SELFTESTS=y CONFIG_NET_SWITCHDEV=y CONFIG_NR_CPUS=2 -CONFIG_NVMEM=y -CONFIG_NVMEM_BRCM_NVRAM=y -CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y[0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.10.176 (arinc9@arinc9-PC) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2.0 r20028-43d71ad93e) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Thu Apr 27 20:28:15 2023 [0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Asus RT-AC88U [0.00] earlycon: ns16550 at MMIO 0x18000300 (options '115200n8') [0.00] printk: bootconsole [ns16550] enabled [0.00] Memory policy: Data cache writealloc [0.00] Hit pending asynchronous external abort (FSR=0x1c06) during first unmask, this is most likely caused by a firmware/bootloader bug. [0.00] Zone ranges: [0.00] Normal [mem 0x-0x07ff] [0.00] HighMem [mem 0x0800-0x9fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x07ff] [0.00] node 0: [mem 0x8800-0x9fff] [0.00] Initmem setup node 0 [mem 0x-0x9fff] [0.00] On node 0 totalpages: 131072 [0.00] Normal zone: 288 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32768 pages, LIFO batch:7 [0.00] HighMem zone: 98304 pages, LIFO batch:31 [0.00] percpu: Embedded 14 pages/cpu s27340 r8192 d21812 u57344 [0.00] pcpu-alloc: s27340 r8192 d21812 u57344 alloc=14*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 130784 [0.00] Kernel command line: earlycon [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 509300K/524288K available (6000K kernel code, 562K rwdata, 1364K rodata, 1024K init, 286K bss, 14988K reserved, 0K cma-reserved, 393216K highmem) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] rcu: Hierarchical RCU implementation. [0.00] Tracing variant of Tasks RCU enabled. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] L2C: DT/platform modifies aux control register: 0x0a13 -> 0x3a53 [0.00] L2C-310 enabling early BRESP for Cortex-A9 [0.00] L2C-310 full line of zeros enabled for Cortex-A9 [0.00] L2C-310 ID prefetch enabled, offset 1 lines [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled [0.00] L2C-310 cache controller enabled, 16 ways, 256 kB [0.00] L2C-310: CACHE_ID 0x41c8, AUX_CTRL 0x7e530001 [0.09] sched_clock: 64 bits at 700MHz, resolution 1ns, wraps every 4398046511103ns [0.008072] clocksource: arm_global_timer: mask: 0x max_cycles: 0xa17102bcf3, max_idle_ns: 440795224838 ns [0.019203] Switching to timer-based delay loop, resolution 1ns [0.025361] Calibrating delay loop (skipped), value calculated using timer frequency.
[PATCH] bcm53xx: disable NVMEM driver
The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It causes the devices with NVRAM in NAND, such as ASUS RT-AC88U, to bootloop. Until the driver is fixed, disable it. Disable NVMEM too as the bgmac_bcma driver will hang trying to retrieve the MAC address without NVMEM_BRCM_NVRAM enabled. Link: https://forum.openwrt.org/t/asus-rt-ac88u-hw-a6-broken-in-22-03-3/147882/40 Signed-off-by: Arınç ÜNAL --- target/linux/bcm53xx/config-5.15 | 3 --- target/linux/bcm53xx/config-6.1 | 3 --- 2 files changed, 6 deletions(-) diff --git a/target/linux/bcm53xx/config-5.15 b/target/linux/bcm53xx/config-5.15 index 9cd1f079d1..6b7fa3c4ad 100644 --- a/target/linux/bcm53xx/config-5.15 +++ b/target/linux/bcm53xx/config-5.15 @@ -223,9 +223,6 @@ CONFIG_NET_FLOW_LIMIT=y CONFIG_NET_SELFTESTS=y CONFIG_NET_SWITCHDEV=y CONFIG_NR_CPUS=2 -CONFIG_NVMEM=y -CONFIG_NVMEM_BRCM_NVRAM=y -CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y diff --git a/target/linux/bcm53xx/config-6.1 b/target/linux/bcm53xx/config-6.1 index d96beb687d..c9d9dbd652 100644 --- a/target/linux/bcm53xx/config-6.1 +++ b/target/linux/bcm53xx/config-6.1 @@ -224,9 +224,6 @@ CONFIG_NET_FLOW_LIMIT=y CONFIG_NET_SELFTESTS=y CONFIG_NET_SWITCHDEV=y CONFIG_NR_CPUS=2 -CONFIG_NVMEM=y -CONFIG_NVMEM_BRCM_NVRAM=y -CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y -- 2.39.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: replace "mac-address-ascii" with "mac-base"
Hi Rafał.
I am late to this so I just wanted to say thanks for doing this. We're
one step closer to mainlining the DTs of the MT7621 SoC devices.
Arınç
On 14.07.2023 16:11, Rafał Miłecki wrote:
From: Rafał Miłecki
With upstream accepted "mac-base" binding there is no need for a
downstream "mac-address-ascii" workaround anymore.
Signed-off-by: Rafał Miłecki
---
.../dts/mt7621_raisecom_msg1500-x-00.dts | 32 ++---
.../ramips/dts/mt7621_tplink_ec330-g5u-v1.dts | 34 +++
2 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_raisecom_msg1500-x-00.dts
b/target/linux/ramips/dts/mt7621_raisecom_msg1500-x-00.dts
index 5d713c0098..07297df083 100644
--- a/target/linux/ramips/dts/mt7621_raisecom_msg1500-x-00.dts
+++ b/target/linux/ramips/dts/mt7621_raisecom_msg1500-x-00.dts
@@ -82,15 +82,23 @@
read-only;
compatible = "nvmem-cells";
- #address-cells = <1>;
- #size-cells = <1>;
-
- macaddr_config_8014: macaddr@8014 {
- reg = <0x8014 0x11>;
- };
- macaddr_config_8036: macaddr@8036 {
- reg = <0x8036 0x11>;
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_config_8014: macaddr@8014 {
+ compatible = "mac-base";
+ reg = <0x8014 0x11>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ macaddr_config_8036: macaddr@8036 {
+ compatible = "mac-base";
+ reg = <0x8036 0x11>;
+ #nvmem-cell-cells = <1>;
+ };
};
};
@@ -137,8 +145,8 @@
};
&gmac0 {
- nvmem-cells = <&macaddr_config_8014>;
- nvmem-cell-names = "mac-address-ascii";
+ nvmem-cells = <&macaddr_config_8014 0>;
+ nvmem-cell-names = "mac-address";
};
&gmac1 {
@@ -146,8 +154,8 @@
label = "wan";
phy-handle = <ðphy4>;
- nvmem-cells = <&macaddr_config_8036>;
- nvmem-cell-names = "mac-address-ascii";
+ nvmem-cells = <&macaddr_config_8036 0>;
+ nvmem-cell-names = "mac-address";
};
&mdio {
diff --git a/target/linux/ramips/dts/mt7621_tplink_ec330-g5u-v1.dts
b/target/linux/ramips/dts/mt7621_tplink_ec330-g5u-v1.dts
index 6c9cc40701..537b6f70a7 100644
--- a/target/linux/ramips/dts/mt7621_tplink_ec330-g5u-v1.dts
+++ b/target/linux/ramips/dts/mt7621_tplink_ec330-g5u-v1.dts
@@ -230,12 +230,20 @@
read-only;
compatible = "nvmem-cells";
- #address-cells = <1>;
- #size-cells = <1>;
- macaddr_factory_165: macaddr@165 {
- reg = <0x165 0x11>;
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_factory_165: macaddr@165 {
+ compatible = "mac-base";
+ reg = <0x165 0x11>;
+ #nvmem-cell-cells = <1>;
+ };
};
+
+
};
partition@0_wholeflash {
@@ -257,8 +265,8 @@
mediatek,mtd-eeprom = <&factory 0x8000>;
ieee80211-freq-limit = <240 250>;
- nvmem-cells = <&macaddr_factory_165>;
- nvmem-cell-names = "mac-address-ascii";
+ nvmem-cells = <&macaddr_factory_165 0>;
+ nvmem-cell-names = "mac-address";
};
};
@@ -269,15 +277,14 @@
mediatek,mtd-eeprom = <&factory 0x14000>;
ieee80211-freq-limit = <500 600>;
- nvmem-cells = <&macaddr_factory_165>;
- nvmem-cell-names = "mac-address-ascii";
- mac-address-increment = <(2)>;
+ nvmem-cells = <&macaddr_factory_165 2>;
+ nvmem-cell-names = "mac-address";
};
};
&gmac0 {
- nvmem-cells = <&macaddr_factory_165>;
- nvmem-cell-names = "mac-address-ascii";
+ nvmem-cells = <&macaddr_factory_165 0>;
+ nvmem-cell-names = "mac-address";
};
&gmac1 {
@@ -285,9 +292,8 @@
label = "wan";
phy-handle = <ðphy0>;
- nvmem-cells = <&macaddr_factory_165>;
- nvmem-cell-names = "mac-address-ascii";
- mac-address-increment = <(1)>;
+ nvmem
Re: [PATCH 4/4] gemini: Bump to kernel v6.1
On 2.06.2023 10:18, Linus Walleij wrote: On Thu, Jun 1, 2023 at 11:20 PM Christian Lamparter wrote: I looked into "how to get the old and new usb-fotg210" into one "define KernelPackage/usb-fotg210". Thing is, you put backported fotg's 6.2 infrastructure into your gemini's patches: 0002-usb-fotg210-Collect-pieces-of-dual-mode-controller.patch (that's a big one!) ... So, your gemini's 6.1 isn't the same as every other target in regard to fotg210 there (that said, gemini is currently the only user due to @TARGET_gemini. phew!). Due to the Makefile and KConfig changes: in OpenWrt's vanilla 6.1 the module is still fotg210-hcd(.ko), whereas gemini's 6.1 its been changed to fotg210(.ko). So, to deal with this at least a little bit, I just moved it to target/linux/gemini/modules.mk . I checked it, wow these @lt6.1 etc I would never have figured out so thanks a lot for stepping in on this! That said: This should be worth it? Reason being that since all this extra time spend, should make the target+fotg210 ready for the upcoming, next stable release (v6.6/7?), right? Apart from tidying up the code, it makes the device mode work on the DNS-313 actually, so it's not just cosmetic, I have been able to use the USB port for serial, I just need to figure out how to get OpenWrt to open a secondary console on it and people can get serial access without soldering. (The original use of the device USB port on that device is USB mass storage, but that was an extreme hack on the original device, including a plastic cover that shift over the USB port when connected to network so you cannot use network and USB at the same time to access the same file partition...) BTW: Do you have some time to look into realtek's DSA for the RTL8363SB? I'm converting some of the APM821xx Devices to DSA and the rtl8365mb seems promising. I've seen that you did some major work there. But there are some snags that I'm not sure are limited to the RTL8363SB (access through MDIO needs different code. And what's up with the CPU-Port or Extif?) or not. (will post to the appropriate ML for that in the "upcoming months") I don't have any device with this DSA on it, but certainly I'm available for questions and review. But Alvin Šipraga and Luiz Angelo Daros de Luca have been very helpful with the upstream code for RTL8365MB, and it also "should" support RTL8363SC so I would be surprised if RTL8363SB is any different. So best case if you can boot the upstream kernel (or backport all the patches to drivers/net/dsa/realtek...) the RTL8365MB driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/realtek/rtl8365mb.c just edit rtl8365mb_chip_infos[] to include the magic for RTL8363SB and see if it magically works. You probably need a jam table magic sequence from the vendor driver if you have that. The upstream device tree for ASUS RT AC88U has the 8365MB courtesy of Arınç ÜNAL : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/bcm47094-asus-rt-ac88u.dts If you just copy/paste that +/- some changes it should probe, all devices use compatible = "realtek,rtl8365mb"; no matter which variant it is. Arınç has also been very helpful with this code, and I think we wanna bring in the RTL8365MB patches at least for BCM53xx for v6.1 (but I think we should probably put them into linux/generic). I think Arınç already has plans to bring this to OpenWrt for v6.1 though, Arınç? I prefer to stay away from backporting features to older Linux versions. The reasons being: - OpenWrt will eventually use a kernel version by default which will have the feature. It doesn't satisfy me to do all that work just for some OpenWrt devices to use this feature earlier. I would rather just make OpenWrt use the kernel version that's already got the feature. I already have some efforts to improve the current way to do this, I had a presentation on Battlemesh v15 regarding this and more. - The backporting process can become messy, and the backported code is prone to all sorts of possible issues. I don't want to debug any issues either caused or possibly caused by backporting features. These aside, I would refrain from using the RTL8365MB DSA subdriver until the bridge offloading feature is implemented. Me, Luiz, and Alvin had a private conversation regarding this back on 15th of January 2023. Shortly put, Alvin's working on an implementation which uses Independent VLAN Learning (IVL) rather than Shared VLAN Learning, and makes use of isolated filtering databases. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Any plans to submit realtek target drivers to mainline Linux?
Hi. I see a lot of development on the network drivers like DSA, PHY, etc. Are there any plans to put all these drivers on the realtek target on mainline Linux? To fully support these SoCs on mainline Linux? Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 15.04.2023 20:02, Sam Kuper wrote: On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. [...] https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb Please can you post the contents of that page as an email in this thread? Doing so will yield the following advantages: 1. People (like me) whose browsers/OSes are set up to accommodate accessibility issues will be able to read it. (Currently, if I visit that URL I only get a blank page. Maybe that is fixable in some way but it would probably take a lot of work, whereas a plain text email would be completely accessible to me.) 2. People reading the mailing list archives will be able to make sense of the discussion, even if the URL above has succumbed to entropy in the meantime. Sure. Here's a markdown version below. Keep in mind you did not send this mail to me, I've only seen it by manually checking the mailing list. # OpenWrt next-gen ideas ## Contribution to the Linux Kernel - Contribute defconfigs and all the devicetrees on OpenWrt to Linux. - Create a Linux branch for that and maintain it. - Submit pull requests to the Linux mailing list regularly to get them applied. - Either submit all out-of-tree patches on OpenWrt to Linux or get rid of them and find a better solution for what the unacceptable patch does. - Architecture specific patches for Linux should be about backporting DTs and defconfigs. - Bugfix backporting should happen only after it's accepted to Linux. The patch must be identical to the commit on Linux. - Feature backporting should be done only if it's thoroughly tested. - An issue caused by feature backporting. [https://github.com/openwrt/openwrt/issues/9420](https://github.com/openwrt/openwrt/issues/9420) ## OpenWrt Kernel Configuration Solution - defconfig for each device instead of config for each (sub)target. - Should lower kernel size greatly. - OpenWrt provides own kernel module packages. The SDK must disable the kernel symbol on the defconfig which matches the enabled kernel module on OpenWrt SDK before compiling. - Instead of this, just `make target_defconfig && make mod2noconfig`, then compile normally with kernel module packages. This way, OpenWrt compiles a kernel with the least amount of kernel modules (or rather, it compiles the kernel like it always did), and people compiling the kernel outside of OpenWrt can choose to remove the kernel modules they don't need. - defconfig for each (sub)target is much easier to maintain. - The most basic options and network drivers should be built into the kernel. The rest should be selected as kernel modules. ### Incorporating defconfigs with OpenWrt's kernel config system - Treat defconfigs as the generic kernel config. Only keep (sub)target configs on OpenWrt. These configs would do changes specific to OpenWrt. - Booting the image, `CONFIG_CMDLINE`, etc. - Filesystem solution, `CONFIG_UBIFS_FS`, `CONFIG_SQUASHFS`, `CONFIG_JFFS2_FS`, etc. - Non-mainline drivers. - First, turn the defconfig to a full config with `make target_defconfig`, like the generic config is. Then, apply the target config. - This should greatly simplify the kernel configs on OpenWrt and grant people outside of the OpenWrt environment to compile the kernel for their device. - For submitting defconfigs to mainline Linux, we take out the OpenWrt-specific things from the config. - Similar to the current process of moving kernel symbols from the target config to the generic kernel, move the kernel symbols to .config, run `make savedefconfig` and move the defconfig file back to `arch/*/configs/target_defconfig`, then submit a patch which updates the defconfig file to our OpenWrt Linux submissions repository. - Implementation should happen progressively. Put the defconfig on Linux, backport it on OpenWrt, start using the defconfig instead of the generic config, specifically on that (sub)target. - Quotes - The explanation of OpenWrt's kernel config system from Felix Fietkau. > I believe the current OpenWrt kernel config system ist vastly superior for keeping target kernel configs in sync while at the same time making it easy to keep an overview of target specific overrides as well. This is especially relevant for updating the kernel version. > > > We do have a lot of config options that we set as default for all > targets. With our current system, we keep them in a file in > > target/linux/generic/config- > > A target can override any of those with its target specific config > overlay. The clever bit of our kernel config system is that this overlay > is not
Re: OpenWrt Next Generation Ideas
On 31.03.2023 20:15, Felix Fietkau wrote: On 31.03.23 18:55, Arınç ÜNAL wrote: On 31.03.2023 19:45, Felix Fietkau wrote: On 31.03.23 18:40, Arınç ÜNAL wrote: I just thought of this. Why don't we just, for example, 'make mt7621_defconfig && make mod2noconfig', then compile normally with kernel module packages. This way, OpenWrt compiles a kernel with the least amount of kernel modules (or rather, it compiles the kernel like it always did), and people compiling the kernel outside of OpenWrt can choose to remove the kernel modules they don't need. Because I believe the current OpenWrt kernel config system ist vastly superior for keeping target kernel configs in sync while at the same time making it easy to keep an overview of target specific overrides as well. This is especially relevant for updating the kernel version. Hmm, well I'll take your word for it but feel free to explain more if you'd like. We do have a lot of config options that we set as default for all targets. With our current system, we keep them in a file in target/linux/generic/config- A target can override any of those with its target specific config overlay. The clever bit of our kernel config system is that this overlay is not handwritten. You can use make kernel_menuconfig or kernel_oldconfig to make changes to it, and it will automatically filter out the defaults from the generic config. When updating to a newer kernel for the first time, you can pick any target, copy the old version and run make kernel_oldconfig. Afterwards you can look through the diff and move any newly added items that should be generic over to the generic config template, so you won't be asked about it for the next target. The expectation is that target configs should share as many options as possible, so it helps that you can simply go through the target config overlays and look at each line to see if it should stay target specific or if it should be moved to the generic config instead. Also, OpenWrt commits that change settings for all targets are much easier to review compared to a set of full configs, because you don't have to manually verify if you properly applied them to all targets. It would definitely be possible to build a workflow around full configs as well to try to achieve something similar, but the problem that I see there is that the relevant information for maintaining would not be as readily available. And it would be easier for configs to accidentally drift apart, causing spurious build issues when dealing with the configurability of our module packages. Thanks a lot of for explaining it. Reading this and looking around the kernel configs myself, I can see that OpenWrt's kernel config system is very necessary for the reasons of configuring the kernel for OpenWrt-specific reasons like booting the image, filesystem solution, and non-mainline drivers. What about this: Incorporating defconfigs with OpenWrt's kernel config system. Treat defconfigs as the generic kernel config. Only keep (sub)target configs on OpenWrt. These configs would do changes specific to OpenWrt. - Booting the image, `CONFIG_CMDLINE`, etc. - Filesystem solution, `CONFIG_UBIFS_FS`, `CONFIG_SQUASHFS`, `CONFIG_JFFS2_FS`, etc. - Non mainline drivers. First, turn the defconfig to a full config with 'make target_defconfig', like the generic config is. Then, apply the target config. This should greatly simplify the kernel configs on OpenWrt and grant people outside of the OpenWrt environment to compile the kernel for their device. I made a defconfig for ramips/mt7621 from the .config file on the kernel directory after generic and target configs were applied. We take out the OpenWrt-specific things from there, then submit it to mainline Linux. This is the defconfig for ramips/mt7621. You can see how small it is even though it's the end result of the generic and target configs. # CONFIG_LOCALVERSION_AUTO is not set CONFIG_KERNEL_XZ=y CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_NO_HZ_IDLE=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_CPU_ISOLATION is not set CONFIG_BLK_DEV_INITRD=y # CONFIG_RD_GZIP is not set # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set # CONFIG_RD_ZSTD is not set CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y # CONFIG_SGETMASK_SYSCALL is not set # CONFIG_SYSFS_SYSCALL is not set # CONFIG_FHANDLE is not set # CONFIG_IO_URING is not set # CONFIG_KALLSYMS is not set CONFIG_BPF_SYSCALL=y CONFIG_BPF_UNPRIV_DEFAULT_OFF=y # CONFIG_RSEQ is not set CONFIG_EMBEDDED=y # CONFIG_VM_EVENT_COUNTERS is not set # CONFIG_SLUB_DEBUG is not set # CONFIG_COMPAT_BRK is not set CONFIG_RALINK=y CONFIG_SOC_MT7621=y CONFIG_CPU_MIPS32_R2=y # CONFIG_MIPS_FP_SUPPORT is not set CONFIG_SCHED_SMT=y CONFIG_MIPS_CPS=y CONFIG_HIGHMEM=y CONFIG_NR_CPUS=4 CONFIG_HZ_100=y C
Re: OpenWrt Next Generation Ideas
On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Some Modest Virtualization Observations How is this related? Virtualization (with OpenWrt being the guest) matters on x86 which is usually not that space-constraint. And maybe armvirt. If space is a problem for older x86 boards, let's disable guest support in x86/legacy. Contribute defconfigs and all the devicetrees on OpenWrt to Linux. For devicetrees this would of course be desirable, but also implies a lot of work and discussions. If you are up to get it started (ie. setup a tree to collect cleaned-up and ready to submit dts), I think it would be worth the effort, at least for more recent targets/SoCs. Regarding defconfigs I don't think we need an individual defconfig for each board. The problem here is also that OpenWrt currently has a layered approach (generic->target->subtarget) approach while Linux itself has a flat approach, and using that would result in a lot of duplication, which would in turn make keeping all those defconfigs up-to-date quite a lot of work... Either submit all out-of-tree patches on OpenWrt to Linux or get rid of them and find a better solution for what the unacceptable patch does. This would of course be great, but especially for legacy devices it may not be possible in many cases. Think of all the devices stuck on swconfig, just to name one example... Think of all the completely broken vendor bootloaders which require hacks (mangeling kernel cmdline and such) and cannot easily be replaced... Bugfix backporting should happen only after it's accepted to Linux. The patch must be identical to the commit on Linux. The wording here might be a bit too strict to support our existing mess, but I generally agree. So I'd say 'should' instead of 'must', but otherwise agree. Feature backporting should be done only if it's thoroughly tested. ... and testing often happens in the OpenWrt tree. So it's a bit of a chicken-egg problem, as often developers don't even have all the different hardware needed for testing. But generally I agree. A way to ease testing *before* pushing to openwrt.git or posting to upstream mailing lists would be to have snapshot builds also for developers' staging trees. Kernel Solution Make a mode menu. Filesystem only. So which kernel headers should be used to build e.g. libc and netlink users? I forgot to answer this. I was thinking something similar to what Buildroot does. You can choose the kernel headers on the toolchain options. The default option is the headers of the latest longterm kernel. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.2023 19:45, Felix Fietkau wrote: On 31.03.23 18:40, Arınç ÜNAL wrote: I just thought of this. Why don't we just, for example, 'make mt7621_defconfig && make mod2noconfig', then compile normally with kernel module packages. This way, OpenWrt compiles a kernel with the least amount of kernel modules (or rather, it compiles the kernel like it always did), and people compiling the kernel outside of OpenWrt can choose to remove the kernel modules they don't need. Because I believe the current OpenWrt kernel config system ist vastly superior for keeping target kernel configs in sync while at the same time making it easy to keep an overview of target specific overrides as well. This is especially relevant for updating the kernel version. Hmm, well I'll take your word for it but feel free to explain more if you'd like. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.2023 19:35, Felix Fietkau wrote: On 31.03.23 18:22, Arınç ÜNAL wrote: On 31.03.2023 19:04, Felix Fietkau wrote: On 31.03.23 14:52, Arınç ÜNAL wrote: On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Hmm, what about we enable the bare minimum of kernel options for a target, which is already how it is, then select the rest as kernel modules (like on the makefile of a target for each device) on the defconfig for each device? So, in the end, it wouldn't be any different than selecting a kernel module package from the OpenWrt SDK which, I believe, does not change the symbol offsets in the kernel stack. My reason for pushing for the use defconfigs is that anyone can build the Linux kernel for their device, without needing OpenWrt. So the work for adding support for a device would benefit far more people. There are a lot of options in the OpenWrt menuconfig (including kmod package selections) which *do* affect the kernel compilation in a major way. They can change struct sizes, enabled features, affect compiled-in code inside functions, etc. For maintenance, I strongly believe that switching from the current system to maintaining full kernel config files is a huge step backwards, because maintaining individual config files makes them so much easier to accidentally go out of sync with each other. If you want to make it easier to build per-device kernels outside of OpenWrt, I'd recommend adding a build system feature to export target defconfig files. I agree that it'd be a lot to maintain. A defconfig per (sub)target is much better. It's not so different than what we already have in OpenWrt except that it will be on mainline Linux so even people outside of the OpenWrt environment can benefit from it. I'm starting this off by making a defconfig for the ramips/mt7621 subtarget. Sure, sending such defconfig files to mainline is a good idea, as long as there is no expectation that these will be used by OpenWrt directly in any way. I just thought of this. Why don't we just, for example, 'make mt7621_defconfig && make mod2noconfig', then compile normally with kernel module packages. This way, OpenWrt compiles a kernel with the least amount of kernel modules (or rather, it compiles the kernel like it always did), and people compiling the kernel outside of OpenWrt can choose to remove the kernel modules they don't need. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.2023 19:04, Felix Fietkau wrote: On 31.03.23 14:52, Arınç ÜNAL wrote: On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Hmm, what about we enable the bare minimum of kernel options for a target, which is already how it is, then select the rest as kernel modules (like on the makefile of a target for each device) on the defconfig for each device? So, in the end, it wouldn't be any different than selecting a kernel module package from the OpenWrt SDK which, I believe, does not change the symbol offsets in the kernel stack. My reason for pushing for the use defconfigs is that anyone can build the Linux kernel for their device, without needing OpenWrt. So the work for adding support for a device would benefit far more people. There are a lot of options in the OpenWrt menuconfig (including kmod package selections) which *do* affect the kernel compilation in a major way. They can change struct sizes, enabled features, affect compiled-in code inside functions, etc. For maintenance, I strongly believe that switching from the current system to maintaining full kernel config files is a huge step backwards, because maintaining individual config files makes them so much easier to accidentally go out of sync with each other. If you want to make it easier to build per-device kernels outside of OpenWrt, I'd recommend adding a build system feature to export target defconfig files. I agree that it'd be a lot to maintain. A defconfig per (sub)target is much better. It's not so different than what we already have in OpenWrt except that it will be on mainline Linux so even people outside of the OpenWrt environment can benefit from it. I'm starting this off by making a defconfig for the ramips/mt7621 subtarget. Either submit all out-of-tree patches on OpenWrt to Linux or get rid of them and find a better solution for what the unacceptable patch does. This would of course be great, but especially for legacy devices it may not be possible in many cases. Think of all the devices stuck on swconfig, just to name one example... Think of all the completely broken vendor bootloaders which require hacks (mangeling kernel cmdline and such) and cannot easily be replaced... Those can stay until eventually the support for them will be dropped on newer OpenWrt versions. I believe there are a lot of out-of-tree patches that are not for old devices and can be on mainline Linux. I believe that we will always need to carry some patches even for newer platforms which will never be accepted upstream, and probably have no place there. One example is the NMBM NAND mapping code on MTK platforms. It was written by MTK long after UBI had already established itself as a much better solution. And yet, we still have to deal with it because we don't want to make it a hard requirement to reflash U-Boot on every single newer NAND based MTK device. We also need to carry some hacks to Kconfig files to support our kmod selection and our out-of-tree mac80211/cfg80211 builds. Makes sense, we'll see how it goes. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.2023 18:36, Daniel Golle wrote: On Fri, Mar 31, 2023 at 05:35:22PM +0300, Arınç ÜNAL wrote: On 31.03.2023 16:47, Daniel Golle wrote: On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote: On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Hmm, what about we enable the bare minimum of kernel options for a target, which is already how it is, then select the rest as kernel modules (like on the makefile of a target for each device) on the defconfig for each device? So, in the end, it wouldn't be any different than selecting a kernel module package from the OpenWrt SDK which, I believe, does not change the symbol offsets in the kernel stack. My reason for pushing for the use defconfigs is that anyone can build the Linux kernel for their device, without needing OpenWrt. So the work for adding support for a device would benefit far more people. This is pretty much what we are currently doing. The exception are network drivers to allow for failsafe mode to work and provide SSH access **before** any modules are loaded. Got it, network drivers should also be built into the kernel on the defconfigs then. Some Modest Virtualization Observations How is this related? Virtualization (with OpenWrt being the guest) matters on x86 which is usually not that space-constraint. And maybe armvirt. If space is a problem for older x86 boards, let's disable guest support in x86/legacy. It was a broad example without any explanation. What caught my attention there is the configuration of the kernel that causes problems, if I understand correctly. Contribute defconfigs and all the devicetrees on OpenWrt to Linux. For devicetrees this would of course be desirable, but also implies a lot of work and discussions. If you are up to get it started (ie. setup a tree to collect cleaned-up and ready to submit dts), I think it would be worth the effort, at least for more recent targets/SoCs. I've been meaning to do this for the mt7621 SoC devices for months. The main roadblock is that some drivers are out-of-tree, like the NAND flash so it makes no sense to have them defined on the devicetree. Getting the out-of-tree patches on mainline Linux is another step so it'll happen eventually. Hm, I thought that Weijie had sent the mt7621-nand driver also upstream, but I haven't been following the process... I haven't checked for a while too, maybe it did get in. Then there's the mac incrementing on the devicetree which doesn't exist on mainline Linux. I think Rafal has been taking care of that lately, but I might be wrong. label-mac also is a downstream use of DTS specific to OpenWrt which didn't yet make it upstream. I'll get this started with my Linux fork on GitHub. Very nice, I will join in there. I'm leaving the link here for future reference. https://github.com/arinc9/linux Thank you! Regarding defconfigs I don't think we need an individual defconfig for each board. The problem here is also that OpenWrt currently has a layered approach (generic->target->subtarget) approach while Linux itself has a flat approach, and using that would result in a lot of duplication, which would in turn make keepin
Re: OpenWrt Next Generation Ideas
On 31.03.2023 16:47, Daniel Golle wrote: On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote: On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Hmm, what about we enable the bare minimum of kernel options for a target, which is already how it is, then select the rest as kernel modules (like on the makefile of a target for each device) on the defconfig for each device? So, in the end, it wouldn't be any different than selecting a kernel module package from the OpenWrt SDK which, I believe, does not change the symbol offsets in the kernel stack. My reason for pushing for the use defconfigs is that anyone can build the Linux kernel for their device, without needing OpenWrt. So the work for adding support for a device would benefit far more people. This is pretty much what we are currently doing. The exception are network drivers to allow for failsafe mode to work and provide SSH access **before** any modules are loaded. Got it, network drivers should also be built into the kernel on the defconfigs then. Some Modest Virtualization Observations How is this related? Virtualization (with OpenWrt being the guest) matters on x86 which is usually not that space-constraint. And maybe armvirt. If space is a problem for older x86 boards, let's disable guest support in x86/legacy. It was a broad example without any explanation. What caught my attention there is the configuration of the kernel that causes problems, if I understand correctly. Contribute defconfigs and all the devicetrees on OpenWrt to Linux. For devicetrees this would of course be desirable, but also implies a lot of work and discussions. If you are up to get it started (ie. setup a tree to collect cleaned-up and ready to submit dts), I think it would be worth the effort, at least for more recent targets/SoCs. I've been meaning to do this for the mt7621 SoC devices for months. The main roadblock is that some drivers are out-of-tree, like the NAND flash so it makes no sense to have them defined on the devicetree. Getting the out-of-tree patches on mainline Linux is another step so it'll happen eventually. Hm, I thought that Weijie had sent the mt7621-nand driver also upstream, but I haven't been following the process... I haven't checked for a while too, maybe it did get in. Then there's the mac incrementing on the devicetree which doesn't exist on mainline Linux. I'll get this started with my Linux fork on GitHub. Very nice, I will join in there. I'm leaving the link here for future reference. https://github.com/arinc9/linux Regarding defconfigs I don't think we need an individual defconfig for each board. The problem here is also that OpenWrt currently has a layered approach (generic->target->subtarget) approach while Linux itself has a flat approach, and using that would result in a lot of duplication, which would in turn make keeping all those defconfigs up-to-date quite a lot of work... Not really, once you make a defconfig for a device, the only case for it to change in the future is if a kernel option was renamed, which is very rare. Anyway, even in that case, there are known ways to update them by bulk. https://l
Re: OpenWrt Next Generation Ideas
On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Hmm, what about we enable the bare minimum of kernel options for a target, which is already how it is, then select the rest as kernel modules (like on the makefile of a target for each device) on the defconfig for each device? So, in the end, it wouldn't be any different than selecting a kernel module package from the OpenWrt SDK which, I believe, does not change the symbol offsets in the kernel stack. My reason for pushing for the use defconfigs is that anyone can build the Linux kernel for their device, without needing OpenWrt. So the work for adding support for a device would benefit far more people. Some Modest Virtualization Observations How is this related? Virtualization (with OpenWrt being the guest) matters on x86 which is usually not that space-constraint. And maybe armvirt. If space is a problem for older x86 boards, let's disable guest support in x86/legacy. It was a broad example without any explanation. What caught my attention there is the configuration of the kernel that causes problems, if I understand correctly. Contribute defconfigs and all the devicetrees on OpenWrt to Linux. For devicetrees this would of course be desirable, but also implies a lot of work and discussions. If you are up to get it started (ie. setup a tree to collect cleaned-up and ready to submit dts), I think it would be worth the effort, at least for more recent targets/SoCs. I've been meaning to do this for the mt7621 SoC devices for months. The main roadblock is that some drivers are out-of-tree, like the NAND flash so it makes no sense to have them defined on the devicetree. Getting the out-of-tree patches on mainline Linux is another step so it'll happen eventually. I'll get this started with my Linux fork on GitHub. Regarding defconfigs I don't think we need an individual defconfig for each board. The problem here is also that OpenWrt currently has a layered approach (generic->target->subtarget) approach while Linux itself has a flat approach, and using that would result in a lot of duplication, which would in turn make keeping all those defconfigs up-to-date quite a lot of work... Not really, once you make a defconfig for a device, the only case for it to change in the future is if a kernel option was renamed, which is very rare. Anyway, even in that case, there are known ways to update them by bulk. https://lore.kernel.org/kernel-janitors/20220929090645.1389-1-lukas.bulw...@gmail.com/ Either submit all out-of-tree patches on OpenWrt to Linux or get rid of them and find a better solution for what the unacceptable patch does. This would of course be great, but especially for legacy devices it may not be possible in many cases. Think of all the devices stuck on swconfig, just to name one example... Think of all the completely broken vendor bootloaders which require hacks (mangeling kernel cmdline and such) and cannot easily be replaced... Those can stay until eventually the support for them will be dropped on newer OpenWrt versions. I believe there are a lot of out-of-tree patches that are not for old devices and can be on mainline Linux. Bugfix backporting
OpenWrt Next Generation Ideas
Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Meeting Notes March 2023
Kudos on the master to main change. Arınç On 29.03.2023 23:43, Paul Spooren wrote: Hi, Another month, another developer meeting - short and sweet: https://openwrt.org/meetings/20230328 Best, Paul ___ 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: OpenWrt @ Battlemesh
On 8.03.2023 02:25, Hauke Mehrtens wrote: Hi, Wireless Battlemesh v15 is coming up in May 8-14. https://battlemesh.org/BattleMeshV15 Battlemesh will take place this year in Calafou, Vallbona d'Anoia, Barcelona. We were thinking to do a OpenWrt meeting in parallel or before/after Battlemesh. I would like to know if it makes sense to organize an OpenWrt meeting at Battelmesh or before/after Battlemesh. I think we have 3 options. OpenWrt meetup at 7 and 8 of May. OpenWrt meetup at 14 and 15 of May. OpenWrt meetup sometime between 8 and 14 of May. I probably need to be back in Türkiye on 14th of May as the election will probably be on the 14th. So the first and last options work for me. If someone wants to do presentations or workshops we can do this also as part of the Battlemesh and offer it to everyone joining Battlemesh too. The main purpose of such a meetup would be to to align on some strategies on what to do next in OpenWrt and how to do it from my point of view. I've got some serious ideas that concerns everything about OpenWrt which I should properly discuss with you before I take it as a presentation. The advantage of doing it around Battlemesh is that we have to organize less ourselves. What do you think about this plan? Who would join such a meetup? I would. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/6] realtek: fix management of mdb entries
On 4.03.2023 00:48, Jan Hoffmann wrote: This series fixes multiple issues related to the L2 table and multicast table. That includes an issue that causes corruption of the port mask for unknown multicast forwarding, which can occur even when multicast snooping is disabled. With these patches, multicast snooping should be mostly working. However, one important missing piece is forwarding of all multicast traffic to multicast router ports (as specified in section 2.1.2-1 of RFC4541). As far as I can see, this is a general issue that affects all DSA switches, and cannot be fixed without changes to the DSA subsystem. Do you plan to discuss this on the netdev mailing list with Vladimir? Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ramips: add support for Huasifei WS1208V2
On 3.02.2023 16:03, Hauke Mehrtens wrote:
On 1/27/23 14:57, arinc9.u...@gmail.com wrote:
From: Arınç ÜNAL
The Huasifei WS1208V2 is an AC1200 router featuring 5 Ethernet ports
with a
Quectel RM520N-GL cellular modem which supports QMI and MBIM modes.
Specifications:
- MT7621AT, 256 MiB RAM, 16 MiB SPI Flash
- MT7603EN 2.4 GHz & MT7612EN 5 GHz WLAN
- Quectel RM520N-GL Cellular Modem
- 2 WLAN & 4 Cellular Antennas
- 5 Gigabit Ethernet Ports
- 1 USB 2.0 port
- 1 PCI-E Slot
- 1 M.2 slot
- 1 SIM card slot
- 1 SD card slot
Installation:
- Install sysupgrade image via ROOter OS.
TFTP Recovery:
- Connect to serial console.
- Boot initramfs image by choosing option 1 when U-Boot prompts.
- Install sysupgrade image via OpenWrt.
Link: https://www.huasifei.com/a/Products/5G%20CPE/240.html
Signed-off-by: Arınç ÜNAL
---
v2: Add recovery information.
---
.../ramips/dts/mt7621_huasifei_ws1208v2.dts | 187 ++
target/linux/ramips/image/mt7621.mk | 12 ++
.../mt7621/base-files/etc/board.d/01_leds | 3 +
3 files changed, 202 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
diff --git a/target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
b/target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
new file mode 100644
index 00..c69f05a0f4
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
@@ -0,0 +1,187 @@
.
+&factory {
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_factory_e000: macaddr@e000 {
+ reg = <0xe000 0x6>;
+ };
+};
Please move this directly where you defined the factory partition in the
partitions node.
Will do.
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index 2269833e48..bbd25e5be0 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -996,6 +996,18 @@ define Device/humax_e10
endef
TARGET_DEVICES += humax_e10
+define Device/huasifei_ws1208v2
+ $(Device/dsa-migration)
+ $(Device/uimage-lzma-loader)
+ IMAGE_SIZE := 16064k
+ DEVICE_VENDOR := Huasifei
+ DEVICE_MODEL := WS1208V2
+ DEVICE_PACKAGES := kmod-ata-ahci kmod-mt7603 kmod-mt76x2
kmod-sdhci-mt7620 \
+ kmod-usb3 kmod-usb-net-cdc-mbim kmod-usb-net-qmi-wwan \
+ kmod-usb-serial-option -wpad-basic-wolfssl
Why do you remove wpad-basic-wolfssl?
This shouldn't be there, thanks for pointing it out.
What is kmod-usb-net-cdc-mbim needed for?
That's to manage the cellular modem using the MBIM specification.
ModemManager or umbim can be used for this. Speaking of umbim, it would
be great if you could apply these fixes on umbim.
https://github.com/openwrt/openwrt/pull/4405
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Huasifei WS1208V2
On 26.01.2023 22:31, Enrico Mioso wrote: On Thu, 26 Jan 2023, arinc9.u...@gmail.com wrote: Date: Thu, 26 Jan 2023 19:35:27 From: arinc9.u...@gmail.com To: openwrt-devel@lists.openwrt.org Cc: Arınç ÜNAL Subject: [PATCH] ramips: add support for Huasifei WS1208V2 From: Arınç ÜNAL The Huasifei WS1208V2 is an AC1200 router featuring 5 Ethernet ports with a Quectel RM520N-GL cellular modem which supports QMI and MBIM modes. Specifications: - MT7621AT, 256 MiB RAM, 16 MiB SPI Flash - MT7603EN 2.4 GHz & MT7612EN 5 GHz WLAN - Quectel RM520N-GL Cellular Modem - 2 WLAN & 4 Cellular Antennas - 5 Gigabit Ethernet Ports - 1 USB 2.0 port - 1 PCI-E Slot - 1 M.2 slot - 1 SIM card slot - 1 SD card slot Installation: - Install sysupgrade image via ROOter OS. Thanks a lot! Seems a nice device. Does it offer any recovery mechanism? In case it does, would you mind adding the procedure description to this commit? Thanks! No special recovery mechanism is there. It's the usual tftp recovery with U-Boot. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 22.01.2023 20:44, Daniel Santos wrote: On 1/22/23 00:23, Arınç ÜNAL wrote: On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos wrote: On 1/21/23 15:19, Arınç ÜNAL wrote: On 21.01.2023 21:32, Daniel Santos wrote: ... You can use this to see what the valid values are for each group, because until this all goes yaml, there's nothing to tell you if you've used an invalid value. Speaking of which: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=4e5410668af5475681793df2bb8c7d8dc6f9c327 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=0c9a567651c3b5d433429da2c7d8e8406ddf1076 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=b4ac84395820eaa0b99ec56816e53c9386ca8b38 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=844bca60927f3aae6baafafb1edd218b624254a1 Arınç OH FUCK YES!!! Arınç, you and I are friends now!! :D Haha hello there! Arınç I don't want to spam the group with this, but you have no idea how much bullshit I've been through that turned out to be a mistake in my device tree file for which there was no warning about. I almost re-wrote the ramips arch code over it, but I had to pull myself back when it was clear that it was unnecessary for my project and hard to justify billing for it. I have that ADHD thing, so I have to stay on track. Glad to read this helps you tremendously. By the way, you didn't CC anyone else so the list didn't receive it ;). Anyway, I'm really pleased to see this and it reminds me that I have a lot of kernel patches I need to submit both to OpenWRT and upstream, including fixing a command line bug for ramips. Speaking of fixing stuff, if you take a look at the yaml for mt7620 and rt305x, some functions got multiple lists for groups. Like refclk on mt7620. Because mt7620 and mt7628/mt7688 SoCs use the same compatible string, it's impossible to differentiate on the binding which SoC your DT is actually for. Therefore, the binding will allow all groups listed for that function. For example if your SoC is mt7620, you can only use the refclk function for the mdio group. If you were to put "spi cs1" as the function there, you wouldn't get a warning. I want to fix this by actually separating mt7628/mt7688 from mt7620 on the pinctrl driver, then split the dt-binding, but I don't know C good enough to do this myself. I have a lot of things I can actually do right now on my task list which could take more than a year (if nothing new is added on top) to complete, so I'm very slowly learning it. It's also the first programming language I ever attempt to learn so understanding the logic of programming is another challenge I've got to deal with. I'd appreciate it greatly if you could help me out on this as you seem to know C. However, I have to send a mail to pinctrl mailing list, see if I can justify breaking the ABI with the maintainers since we would be changing the compatible string for certain SoCs. I've done it once. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos wrote: >On 1/21/23 15:19, Arınç ÜNAL wrote: >> On 21.01.2023 21:32, Daniel Santos wrote: >>> ... You can use this to see what the valid values are for each group, >>> because until this all goes yaml, there's nothing to tell you if you've >>> used an invalid value. >> >> Speaking of which: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=4e5410668af5475681793df2bb8c7d8dc6f9c327 >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=0c9a567651c3b5d433429da2c7d8e8406ddf1076 >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=b4ac84395820eaa0b99ec56816e53c9386ca8b38 >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=844bca60927f3aae6baafafb1edd218b624254a1 >> >> >> Arınç > >OH FUCK YES!!! Arınç, you and I are friends now!! :D Haha hello there! Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
By the way, I just got an "undelivered mail returned to sender" for John's mail address. I don't think they'll be replying here any time soon. ;) Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 21.01.2023 21:32, Daniel Santos wrote:
Hello all,
I saw this a few days ago, but was too busy to answer then -- sorry
about that. I've dug into this code a bit, but for the mt7620.
On 1/21/23 08:51, Sergio Paracuellos wrote:
Hi,
[+cc John Crispin]
On Sat, Jan 21, 2023 at 2:45 PM Arınç ÜNAL wrote:
On 21.01.2023 10:56, Sergio Paracuellos wrote:
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL
wrote:
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
GPIO by default. Requesting a gpio by either from devicetree or `echo
203 > /sys/class/gpio/export` won't change anything. You have to
claim
the pin group as gpio on the devicetree.
Yes, you have to claim the pin group as gpio on the device tree to
make this work. Ralink has the concept of "GPIO mode" but actually is
just an electrical configuration for a certain device. So if the mode
(function) is not requested as a real GPIO nothing is going to work.
So in your board's dts file you have to add something like the
following with the groups you want to claim as real gpio function:
#include "mt7621.dtsi"
...
&state_default {
gpio {
groups = "jtag", "uart3", "wdt";
function = "gpio";
};
};
First of all, to better understand what you're working with I highly
recommend you download the mt7621 Data Sheet and took at §2.4 Pin
Sharing Schemes. Here's a link to one I've found:
https://www.t-firefly.com/download/FireWRT/hardware/MT7621.pdf .
Microcontrollers come with a lot of nifty hardware -- more than they
have external pins for. So if you don't need a piece of hardware, you
can option to use that pin as a GPIO instead.
The kernel code for the other end of this device tree snippet that
Sergio gave you is in arch/mips/ralink/mt7621.c, which you'll probably
find in your OpenWRT build tree under
build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux-5.4.143/.
The various struct rt2880_pmx_func variables contain the valid values
for each of these sets of pins except for "gpio" -- which is implicit
for each one (not my favorite design choice, but oh well). Finally, each
of those are glued together with the struct rt2880_pmx_group
mt7621_pinmux_data[] array on line 96. You can use this to see what the
valid values are for each group, because until this all goes yaml,
there's nothing to tell you if you've used an invalid value.
Speaking of which:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=4e5410668af5475681793df2bb8c7d8dc6f9c327
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=0c9a567651c3b5d433429da2c7d8e8406ddf1076
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=b4ac84395820eaa0b99ec56816e53c9386ca8b38
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=844bca60927f3aae6baafafb1edd218b624254a1
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 21.01.2023 10:56, Sergio Paracuellos wrote:
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
GPIO by default. Requesting a gpio by either from devicetree or `echo
203 > /sys/class/gpio/export` won't change anything. You have to claim
the pin group as gpio on the devicetree.
Yes, you have to claim the pin group as gpio on the device tree to
make this work. Ralink has the concept of "GPIO mode" but actually is
just an electrical configuration for a certain device. So if the mode
(function) is not requested as a real GPIO nothing is going to work.
So in your board's dts file you have to add something like the
following with the groups you want to claim as real gpio function:
#include "mt7621.dtsi"
...
&state_default {
gpio {
groups = "jtag", "uart3", "wdt";
function = "gpio";
};
};
Quoting my response from [0]:
state_default is there to explicitly set the function of a pin group to gpio,
this is done because the bootloader may have set the function of a pin group to
something else before booting OpenWrt which would render the pins of that group
uncontrollable for general purpose aka GPIO.
Actually I think @arinc9 did some work around that.
Not yet, I plan to modify the gpio_request_enable pinmux operation to set the
pin group as gpio when there's a gpio request for a pin in that pin group.
gpio_request_enable pinmux operation can only set the function of an individual
pin currently. Since ralink pinctrl driver can only set the function of a group
of pins, the operation currently cannot be used.
If we make it work, any GPIO defined on devicetree or exported from userspace
will automatically have the function of the pin group it's in set to gpio,
completely getting rid of the need for explicitly defining functions of certain
pin groups on the devicetree.
Of course when I said "I plan to modify this code" I actually meant I
was going to talk this through with Sergio but I never had the
opportunity to do so. I guess this thread is a good place to start
talking about this.
I had this case on a user:
They got an LED wired to wdt pin. GPIO is already exported on the DT.
However their LED just won't work.
It turns out the bootloader sets the wdt pin's function to something
other than gpio. And when OpenWrt boots, the pinctrl driver makes no
changes to the pin's function.
Bootloader always sets its own configuration for the pinctrl. The
linux pinctrl driver sets every single group default mode [0] as it is
in the Mediatek's Mt7621 datasheet.
So we had to specifically claim that pin as gpio to make the LED work.
Now there is already a solution for this which is the
gpio_request_enable pinmux operation but it's not supposed to be used on
pinctrl drivers that cannot control pins individually.
Sergio, you think we can somehow make this pinmux operation mux a pin
group as gpio instead of a single pin?
I am not an expert in pinmux drivers but I think there are strong
reasons why only a single pin is allowed to be requested.
See kernel doc about this here: [1]
Or introduce a new pinmux operation that can do this?
I think you should send an email to kernel gpio / pinctrl kernel mail
list to get feedback from Bart and Linus as gpio and pin control
maintainers to properly understand the way to go but I don't really
understand what is the problem requesting the group as gpio in the
device tree like any other single platform is doing and seems to be
the correct way to go. Maybe I am missing something :)
From what I understand, a gpio is requested by exporting a gpio by
either from devicetree or `echo 203 > /sys/class/gpio/export`.
Now, the pinctrl driver must somehow know that the pin which translates
to the GPIO number needs to function as gpio.
Doing this manually on DT bindings is an option but it's not very
viable. I believe this is why the gpio_request_enable operation was made
for pinctrl drivers to implement. Now a pin can be made to function as
GPIO from userspace dynamically instead of hardcoding it on the devicetree.
Boards with pinouts, like Raspberrypi, Bananapi, etc. benefit this the
most. Because it'd be extremely hard to hardcode every pin with pinouts
on the devicetree for each different device.
For example, my Unielec U7621 board uses the rgmii2 pins for ethernet
but at the same time it's got pinouts for them. If the pinmux operation
worked, I could just export the gpio number and the pin would function
as gpio. When I'm done, I could just unexport and the pin group would go
back to function as an rgmii bus.
I believe this is already the case with pinctrl drivers that can control
pins individually. There's no state-default node on DT where some pins
are hardcoded to functi
Re: mt7621 GPIO mapping mystery
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as GPIO by default. Requesting a gpio by either from devicetree or `echo 203 > /sys/class/gpio/export` won't change anything. You have to claim the pin group as gpio on the devicetree. Quoting my response from [0]: state_default is there to explicitly set the function of a pin group to gpio, this is done because the bootloader may have set the function of a pin group to something else before booting OpenWrt which would render the pins of that group uncontrollable for general purpose aka GPIO. Actually I think @arinc9 did some work around that. Not yet, I plan to modify the gpio_request_enable pinmux operation to set the pin group as gpio when there's a gpio request for a pin in that pin group. gpio_request_enable pinmux operation can only set the function of an individual pin currently. Since ralink pinctrl driver can only set the function of a group of pins, the operation currently cannot be used. If we make it work, any GPIO defined on devicetree or exported from userspace will automatically have the function of the pin group it's in set to gpio, completely getting rid of the need for explicitly defining functions of certain pin groups on the devicetree. Of course when I said "I plan to modify this code" I actually meant I was going to talk this through with Sergio but I never had the opportunity to do so. I guess this thread is a good place to start talking about this. I had this case on a user: They got an LED wired to wdt pin. GPIO is already exported on the DT. However their LED just won't work. It turns out the bootloader sets the wdt pin's function to something other than gpio. And when OpenWrt boots, the pinctrl driver makes no changes to the pin's function. So we had to specifically claim that pin as gpio to make the LED work. Now there is already a solution for this which is the gpio_request_enable pinmux operation but it's not supposed to be used on pinctrl drivers that cannot control pins individually. Sergio, you think we can somehow make this pinmux operation mux a pin group as gpio instead of a single pin? Or introduce a new pinmux operation that can do this? [0] https://github.com/openwrt/openwrt/pull/4470#issuecomment-1243345944 Arınç On 20.01.2023 22:24, Peter Naulls wrote: I posted previously on GPIOs, which caused some debate; this may or may not be relevant, but I'd be remiss to not mention it: http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt 5.10.161 etc kernels. In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17 and 22-24 are LEDs, so their operation should be immediately obvious. The are all active high and are all wired as you'd expect. This all works as expected on a previous 4.14 kernel. To say that there have been significant changes in drivers, GPIO handling and device tree since that kernel would be an understatement. I have tried exporting the GPIOS as LEDs, named GPIOs, direct manipulation in /sys/class/gpio and libgpiod, but something is amiss. The actual value of the GPIO as seen in software can manipulated in all cases, but the physical value does not change. Suspiciously, MDIO/MDC are at GPIOs 20 and 21, so I don't know if these are upsetting the physical mapping. I've also turned off as much as possible in the device tree, and built the kernel without switch and ethernet drivers, etc. I'm tearing my hair out here, so any clues at all would be appreciated. Thanks! ___ 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: BCM53xx on D-Link DIR-890L - 2MB max problem
On 15.01.2023 23:13, Linus Walleij wrote: On Sun, Jan 15, 2023 at 9:02 PM Arınç ÜNAL wrote: On 15.01.2023 17:54, Linus Walleij wrote: On Fri, Jan 13, 2023 at 11:11 PM Arınç ÜNAL wrote: Side question, did you risk writing your test builds to the flash or have you already got the flash in an easily reprogrammable set up? This device has the boot prom in NOR so firmware is only flashed to the NAND flash, no risk of overwriting the boot loader. Sorry, I don't follow. What's a boot prom? There are 2 flash chips in the device one NOR flash for the CFE and NVRAM, and one NAND flash for all other firmware. Got it. You didn't overwrite CFE when you booted U-Boot? I was asking how did you write U-Boot to flash if it wasn't clear. No, I let CFE boot U-boot instead of the kernel. Oh nice. Did you have to disable some initialisation stuff like SKIP_LOWLEVEL_INIT_ONLY as pointed out on this post? https://lunarius.fe80.eu/blog/openwrt-u-boot-boot-u-boot.html I tried booting U-Boot via U-Boot on my MT7621 MIPS board but there's nothing about initalisation to disable for MIPS. It just hangs when I try to boot the uImage with bootm. Flashing is done with the manufacturing method: holding in RESET and powering on, then a rescue mode web server flash tool appears (super convenient). I've just spotted SYS_BOOTM_LEN in the same menu as CMD_BOOTZ: This is the maximum size of the buffer that is used to decompress the OS image in to, if passing a compressed image to bootm/booti/bootz. This is set to 0x200 (32 MiB) on the U-Boot I was testing the compressed kernel images on. The lzma compressed image at 19134142 bytes (~18.2477 MiB) must've exceeded 32 MiB when decompressed. Maybe there's an option like this for CFE. I don't know if you're able to compile a custom CFE and boot it somehow. No need for me, I just leave CFE as it is. Maybe a but clunky but it works... Alright, U-Boot is the way to go I suppose. Did you try booting a kernel on this Northstar SoC with U-Boot? Haven't gotten there yet, I need to implement SEAMA support (the D-Link preferred NAND image format) first, because it totally scrambles the stuff written to flash. I guess tftpboot is out of question, no network support yet? TFTPBOOT actually works with CFE! ifconfig -addr=192.168.1.35 eth0 boot -raw -addr=0x01097000 -max=0x200 -tftp 192.168.1.2:zImage ...so I managed to develop and test the kernel with this. Device tree is complete and all. But now I want something that is convenient and easy for OpenWrt users without UART etc to use. So I need to fix installation into NAND. Hmm, is your plan to boot U-Boot from CFE then boot the kernel, and ship this all as an OpenWrt image? Cheers. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: BCM53xx on D-Link DIR-890L - 2MB max problem
On 15.01.2023 17:54, Linus Walleij wrote: On Fri, Jan 13, 2023 at 11:11 PM Arınç ÜNAL wrote: Side question, did you risk writing your test builds to the flash or have you already got the flash in an easily reprogrammable set up? This device has the boot prom in NOR so firmware is only flashed to the NAND flash, no risk of overwriting the boot loader. Sorry, I don't follow. What's a boot prom? You didn't overwrite CFE when you booted U-Boot? I was asking how did you write U-Boot to flash if it wasn't clear. I tried letting U-Boot's lzmadec decompress the kernel image. Decompressing fails when the kernel size reaches a certain point. Hm haven't tried that, I used a zImage and I added u-boot CMD_BOOTZ to U-boot so it can start it directly without any external compression or funny uImage stuff. I've just spotted SYS_BOOTM_LEN in the same menu as CMD_BOOTZ: This is the maximum size of the buffer that is used to decompress the OS image in to, if passing a compressed image to bootm/booti/bootz. This is set to 0x200 (32 MiB) on the U-Boot I was testing the compressed kernel images on. The lzma compressed image at 19134142 bytes (~18.2477 MiB) must've exceeded 32 MiB when decompressed. Maybe there's an option like this for CFE. I don't know if you're able to compile a custom CFE and boot it somehow. Since the image is compressed in the end, I can't exactly add bytes and predict what the size of the compressed file will be. So after a lot of compiling and trying on the board, this is the closest I got. LZMA compressed kernel size in bytes which U-Boot’s lzmadec can decompress: 19134096 LZMA compressed kernel size in bytes which U-Boot’s lzmadec fails to decompress: 19134142 (...) I was wondering if there's a limit the bootloader sets for the lzma decompressor. I assume it's 2 MiB for CFE. Hm. I guess this could be a limitation in some implementations of the algorithm simply... Even if there is, I don't think I've hit it yet. Did you try booting a kernel on this Northstar SoC with U-Boot? Haven't gotten there yet, I need to implement SEAMA support (the D-Link preferred NAND image format) first, because it totally scrambles the stuff written to flash. I guess tftpboot is out of question, no network support yet? Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: BCM53xx on D-Link DIR-890L - 2MB max problem
On 12.01.2023 23:51, Linus Walleij wrote: On Sun, Jan 8, 2023 at 12:33 AM Linus Walleij wrote: I guess trying to figure out what lzma-loader does and implement the same for ARM is the way to go, or at some point I felt like implementing U-Boot for the BCM53xx and implement SEAMA loading from NAND in U-Boot is maybe easier... How hard can it be :P U-Boot 2023.01-00442-g6b75c294818f-dirty (Jan 12 2023 - 21:46:18 +0100)Broadcom Northstar BCMNS Northstar SoC Model: Northstar model DRAM: 128 MiB (effective 256 MiB) WARNING: Caches not enabled Core: 13 devices, 7 uclasses, devicetree: embed MMC: Loading Environment from nowhere... OK In:serial@300 Out: serial@300 Err: serial@300 Model: Northstar model Net: No ethernet found. northstar> northstar> northstar> Nice work! I caught something with decompressing lzma compressed images with U-Boot's lzmadec but had to take a quick detour to Greece before I could conclude my test. Side question, did you risk writing your test builds to the flash or have you already got the flash in an easily reprogrammable set up? I'm doing this on a UniElec U7621-06 (MediaTek MT7621 SoC) which has got 256 MiB DRAM. Running Linux 6.2.0-rc3 with mainline U-Boot. DRAM base is at 0x8000 so I can use the 0x8000 - 0x9000 range (256 MiB) for writing to memory. I tried letting U-Boot's lzmadec decompress the kernel image. Decompressing fails when the kernel size reaches a certain point. => tftpboot 0x8300 test-uImage.lzma; tftpboot 0x84f0 mt7621-unielec-u7621-06-16m.dtb; bootm 0x8300 - 0x84f0 [...] ## Booting kernel from Legacy Image at 8300 ... Image Name: Linux-6.2.0-rc3+ Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size:19134142 Bytes = 18.2 MiB Load Address: 80001000 Entry Point: 80ed84c4 Verifying Checksum ... OK ## Flattened Device Tree blob at 84f0 Booting using the fdt blob at 0x84f0 Working FDT set to 84f0 Uncompressing Kernel Image lzma compressed: uncompress error 1 Must RESET board to recover => To figure out at what size lzmadec fails, I added a file with randomly generated data to the root filesystem so the LZMA compressor can't do much to shrink it. head -c 2M < /dev/urandom > file.bin Since the image is compressed in the end, I can't exactly add bytes and predict what the size of the compressed file will be. So after a lot of compiling and trying on the board, this is the closest I got. LZMA compressed kernel size in bytes which U-Boot’s lzmadec can decompress: 19134096 LZMA compressed kernel size in bytes which U-Boot’s lzmadec fails to decompress: 19134142 However booting a kernel with self extracting works fine. => tftpboot 0x8300 test-uzImage.bin; tftpboot 0x84f0 mt7621-unielec-u7621-06-16m.dtb; bootm 0x8300 - 0x84f0 [...] ## Booting kernel from Legacy Image at 8300 ... Image Name: Linux-6.2.0-rc3+ Image Type: MIPS Linux Kernel Image (uncompressed) Data Size:19138320 Bytes = 18.3 MiB Load Address: 82011000 Entry Point: 82011000 Verifying Checksum ... OK ## Flattened Device Tree blob at 84f0 Booting using the fdt blob at 0x84f0 Working FDT set to 84f0 Loading Kernel Image Loading Device Tree to 8fcf6000, end 8fcfb365 ... OK Working FDT set to 8fcf6000 (It takes a while here to decompress...) [0.00] Linux version 6.2.0-rc3+ (arinc9@arinc9-PC) (mips-linux-gnu-gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #75 SMP Fri Jan 13 14:41:56 +03 2023 [0.00] SoC Type: MediaTek MT7621 ver:1 eco:3 [0.00] printk: bootconsole [early0] enabled [0.00] CPU0 revision is: 0001992f (MIPS 1004Kc) [0.00] MIPS: machine is UniElec U7621-06 (16M flash) [...] I was wondering if there's a limit the bootloader sets for the lzma decompressor. I assume it's 2 MiB for CFE. Did you try booting a kernel on this Northstar SoC with U-Boot? Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Compile only root filesystem like Buildroot
On 11.01.2023 01:19, Linus Walleij wrote: On Sun, Jan 8, 2023 at 5:38 PM Arınç ÜNAL wrote: Is it possible to create a root filesystem archive? Is there a directory where the final filesystem is extracted before turned to a squashfs image? It's right there in the Kconfig menu: Target Images -> * .tar.gz Appears in your bin/ ... along with the rest. Just tar xvfz as root in some USB stick or so. Thanks. I extracted it to include an init file at / (see other mail on the thread for why) and fed the directory as initramfs source on the kernel config. I'm currently studying how I would write a squashfs filesystem to SPI flash. I know how to write a file to SPI flash but the remaining is currently a mystery to me. By the way, I'm also doing some tests with lzma decompression on U-Boot. I'll reply on your thread when I have some results. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Compile only root filesystem like Buildroot
Quoting me and Luiz's message. On 9.01.2023 05:17, Luiz Angelo Daros de Luca wrote: Hi Arınç, Is it possible to create a root filesystem archive? CONFIG_TARGET_ROOTFS_TARGZ ? Ah, of course. Thanks. OpenWrt filesystem hasn’t got /init. I get this error when I link the filesystem with the kernel. [3.495199] List of all partitions: [3.498698] No filesystem could mount root, tried: [3.498706] [3.505060] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [3.513308] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- Configuring CONFIG_DEFAULT_INIT to /sbin/init on kernel or adding init=/sbin/init to kernel command line surprisingly won’t change anything. So I put this as /init. Now it boots fine. #!/bin/sh exec /sbin/init "$@" Is there a directory where the final filesystem is extracted before turned to a squashfs image? build_dir/target-mipsel_24kc_musl/root-ramips/ ? I know there's buildroot for this but I want to use LuCI, buildroot seems to only have uci. BTW, I'm working back with rtl8365mb driver. I implemented forwarding offload and mtu change but it breaks vlan security. We need a proper vlan support before the HW does the forwarding. I'm working on that right now. Hey that's great! Not to put more work on you but could you take a look at supporting the BR_ISOLATED port flag once you're done? My folks did some work messing with the port matrix on mt7530.c to support port isolation for DSA interfaces on MT7530 and MT7531 switches. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Compile only root filesystem like Buildroot
Is it possible to create a root filesystem archive? Is there a directory where the final filesystem is extracted before turned to a squashfs image? I know there's buildroot for this but I want to use LuCI, buildroot seems to only have uci. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] ramips: mt7621: Add Arcadyan WE420223-99 support
On 8.01.2023 19:03, Harm Berntsen wrote: The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access point distributed as Experia WiFi by KPN in the Netherlands. It features two ethernet ports and 2 internal antennas. Specifications -- SOC : Mediatek MT7621AT ETH : Two 1 gigabit ports, built into the SOC WIFI : MT7615DN BUTTON: Reset BUTTON: WPS LED : Power (green+red) LED : WiFi (green+blue) LED : WPS (green+red) LED : Followme (green+red) Power : 12 VDC, 1A barrel plug Winbond variant: RAM : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM Flash : Winbond W25Q256JVFQ, 256Mb SPI U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1 Macronix variant: RAM : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM Flash : MX25l25635FMI-10G, 256Mb SPI U-Boot: 1.1.3 (Dec 4 2017 - 11:37:57), Ralink 5.0.0.1 Serial -- The serial port needs a TTL/RS-232 3V3 level converter! The Serial setting is 57600-8-N-1. The board has an unpopulated 2.54mm straight pin header. The pinout is: VCC (the square), RX, TX, GND. Installation See the Wiki page [1] for more details, it comes down to: 1. Open the device, take off the heat sink 2. Connect the SPI flash chip to a flasher, e.g. a Raspberry Pi. Also connect the RESET pin for stability (thanks @FPSUsername for reporting) 3. Make a backup in case you want to revert to stock later 4. Flash the squashfs-factory.trx file to offset 0x5 of the flash 5. Ensure the bootpartition variable is set to 0 in the U-Boot environment located at 0x3 Note that the U-Boot is password protected, this can optionally be removed. See the forum [2] for more details. MAC Addresses(stock) +--+--+---+ | use | address | example | +--+--+---+ | Device | label| 00:00:00:11:00:00 | | Ethernet | + 3 | 00:00:00:11:00:03 | | 2g | + 0x02f1 | 02:00:00:01:00:01 | | 5g | + 1 | 00:00:00:11:00:01 | +--+--+---+ The label address is stored in ASCII in the board_data partition Notes - - This device has a dual-boot partition scheme, but OpenWRT will claim both partitions for more storage space. Known issues - 2g MAC address does not match stock due to missing support for that in macaddr_add - Only the power LED is configured by default References -- [1] https://openwrt.org/inbox/toh/arcadyan/astoria/we420223-99 [2] https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653 Signed-off-by: Harm Berntsen Acked-by: Arınç ÜNAL Hold on to this next time. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: BCM53xx on D-Link DIR-890L - 2MB max problem
Funny Linus thought to mention me since I've been working on booting stuff on arm and mips boards very recently. On 8.01.2023 06:18, Chuanhong Guo wrote: Hi! On Sun, Jan 8, 2023 at 7:38 AM Linus Walleij wrote: I guess trying to figure out what lzma-loader does and implement the same for ARM is the way to go, or at some point I felt like implementing U-Boot for the BCM53xx and implement SEAMA loading from NAND in U-Boot is maybe easier... The ARM zImage is supposed to be self-extracting, right? Is it possible to package that as an uncompressed code for u-boot? That's correct, take a look at this answer. https://stackoverflow.com/a/22338835 lzma-loader was created at the time when MIPS didn't have zboot support. In ramips, the lzma-loader does the same work as the kernel zboot image: It's a loader which extracts the actual kernel code to the memory. The compressed kernel is linked as a part of the lzma-loader so it doesn't need any flash access. Then why is it CFE that tries to decompress the image in this case? This is what I understand when I look at the log Linus put. It should see the image on NAND memory as uncompressed and just leave it to the lzma-loader linked with the kernel code to decompress. We can add compression information of the kernel for U-Boot with mkimage but I don't know how it works with CFE. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] ramips: mt7621: Add Arcadyan WE420223-99 support
On 2.01.2023 19:36, Harm Berntsen wrote: The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access point distributed as Experia WiFi by KPN in the Netherlands. It features two ethernet ports and 2 internal antennas. Specifications -- SOC : Mediatek MT7621AT ETH : Two 1 gigabit ports, built into the SOC WIFI : MT7615DN BUTTON: Reset BUTTON: WPS LED : Power (green+red) LED : WiFi (green+blue) LED : WPS (green+red) LED : Followme (green+red) Power : 12 VDC, 1A barrel plug Winbond variant: RAM : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM Flash : Winbond W25Q256JVFQ, 256Mb SPI U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1 Macronix variant: RAM : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM Flash : MX25l25635FMI-10G, 256Mb SPI U-Boot: 1.1.3 (Dec 4 2017 - 11:37:57), Ralink 5.0.0.1 Serial -- The serial port needs a TTL/RS-232 3V3 level converter! The Serial setting is 57600-8-N-1. The board has an unpopulated 2.54mm straight pin header. The pinout is: VCC (the square), RX, TX, GND. Installation See the Wiki page [1] for more details, it comes down to: 1. Open the device, take off the heat sink 2. Connect the SPI flash chip to a flasher, e.g. a Raspberry Pi. Also connect the RESET pin for stability (thanks @FPSUsername for reporting) 3. Make a backup in case you want to revert to stock later 4. Flash the squashfs-factory.trx file to offset 0x5 of the flash 5. Ensure the bootpartition variable is set to 0 in the U-Boot environment located at 0x3 Note that the U-Boot is password protected, this can optionally be removed. See the forum [2] for more details. MAC Addresses(stock) +--+--+---+ | use | address | example | +--+--+---+ | Device | label| 00:00:00:11:00:00 | | Ethernet | + 3 | 00:00:00:11:00:03 | | 2g | + 0x02f1 | 02:00:00:01:00:01 | | 5g | + 1 | 00:00:00:11:00:01 | +--+--+---+ The label address is stored in ASCII in the board_data partition Notes - - This device has a dual-boot partition scheme, but OpenWRT will claim both partitions for more storage space. Known issues - 2g MAC address does not match stock due to missing support for that in macaddr_add - Only the power LED is configured by default References -- [1] https://openwrt.org/inbox/toh/arcadyan/astoria/we420223-99 [2] https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653 Signed-off-by: Harm Berntsen Acked-by: Arınç ÜNAL Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] ramips: mt7621: Add Arcadyan WE420223-99 support
On 2.01.2023 18:34, Harm Berntsen wrote:
On Mon, 2023-01-02 at 18:18 +0300, Arınç ÜNAL wrote:
On 2.01.2023 18:03, Harm Berntsen wrote:
On Wed, 2022-12-28 at 23:11 +0300, Arınç ÜNAL wrote:
The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band
access
point distributed as Experia WiFi by KPN in the Netherlands. It
features
two ethernet ports and 2 internal antennas.
Specifications
--
SOC : Mediatek MT7621AT
ETH : Two 1 gigabit ports, built into the SOC
WIFI : MT7615DN
BUTTON: Reset
BUTTON: WPS
LED : Power (green+red)
LED : WiFi (green+blue)
LED : WPS (green+red)
LED : Followme (green+red)
Power : 12 VDC, 1A barrel plug
Winbond variant:
RAM : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM
Flash : Winbond W25Q256JVFQ, 256Mb SPI
U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1
Macronix variant:
RAM : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM
Flash : MX25l25635FMI-10G, 256Mb SPI
U-Boot: 1.1.3 (Dec 4 2017 - 11:37:57), Ralink 5.0.0.1
Serial
--
The serial port needs a TTL/RS-232 3V3 level converter! The
Serial
setting is 57600-8-N-1. The board has an unpopulated 2.54mm
straight pin
header.
The pinout is: VCC (the square), RX, TX, GND.
Installation
1. Open the device, take off the heat sink
2. Connect the SPI flash chip to a flasher, e.g. a Raspberry
Pi.
Also
connect the RESET pin for stability (thanks @FPSUsername
for
reporting)
3. Make a backup in case you want to revert to stock later
4. Flash the squashfs-factory.trx file to offset 0x5 of the
flash
5. Ensure the bootpartition variable is set to 0 in the U-Boot
environment located at 0x3
Note that the U-Boot is password protected, this can optionally
be
removed. See the forum for more details [1]
MAC Addresses(stock)
+--+--+---+
use | address | example |
+--+--+---+
Device | label | 00:00:00:11:00:00 |
Ethernet | + 3 | 00:00:00:11:00:03 |
2g | + 0x02f1 | 02:00:00:01:00:01 |
5g | + 1 | 00:00:00:11:00:01 |
+--+--+---+
The label address is stored in ASCII in the board_data
partition
Known issues
- 2g MAC address does not match stock due to missing support
for
that in
macaddr_add
- Only the power LED is configured by default
References
--
[1]
https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653?u=harm
Signed-off-by: Harm Berntsen
---
package/boot/uboot-envtools/files/ramips | 3 +
.../dts/mt7621_arcadyan_we420223-99.dts | 210
++
target/linux/ramips/image/mt7621.mk | 25 +++
.../mt7621/base-files/etc/board.d/02_network | 8 +
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 9 +
.../mt7621/base-files/lib/upgrade/platform.sh | 1 +
6 files changed, 256 insertions(+)
create mode 100644
target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
diff --git a/package/boot/uboot-envtools/files/ramips
b/package/boot/uboot-envtools/files/ramips
index f7f4821cef..8d4960e7a3 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -17,6 +17,9 @@ alfa-network,awusfree1|\
alfa-network,quad-e4g|\
alfa-network,r36m-e4g|\
alfa-network,tube-e4g|\
+arcadyan,we420223-99)
+ ubootenv_add_uci_config "/dev/mtd2" "0x0" "0x1000"
"0x1000"
+ ;;
engenius,esr600h|\
sitecom,wlr-4100-v1-002)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000"
"0x1000"
diff --git a/target/linux/ramips/dts/mt7621_arcadyan_we420223-
99.dts b/target/linux/ramips/dts/mt7621_arcadyan_we420223-
99.dts
new file mode 100644
index 00..f68d79af15
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "Arcadyan WE420223-99";
+ compatible = "arcadyan,we420223-99", "mediatek,mt7621-
soc";
+
+ aliases {
+ led-boot = &led_power_green;
+ led-failsafe = &led_power_red;
+ led-running = &led_power_green;
+ led-upgrade = &led_wps_green;
+ led-wifi = &led_wifi_green;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600 ubi.mtd=5
root=/dev/ubiblock0_0";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+
Re: [PATCH 1/2] ramips: mt7621: Add Arcadyan WE420223-99 support
On 2.01.2023 18:03, Harm Berntsen wrote:
On Wed, 2022-12-28 at 23:11 +0300, Arınç ÜNAL wrote:
The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access
point distributed as Experia WiFi by KPN in the Netherlands. It
features
two ethernet ports and 2 internal antennas.
Specifications
--
SOC : Mediatek MT7621AT
ETH : Two 1 gigabit ports, built into the SOC
WIFI : MT7615DN
BUTTON: Reset
BUTTON: WPS
LED : Power (green+red)
LED : WiFi (green+blue)
LED : WPS (green+red)
LED : Followme (green+red)
Power : 12 VDC, 1A barrel plug
Winbond variant:
RAM : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM
Flash : Winbond W25Q256JVFQ, 256Mb SPI
U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1
Macronix variant:
RAM : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM
Flash : MX25l25635FMI-10G, 256Mb SPI
U-Boot: 1.1.3 (Dec 4 2017 - 11:37:57), Ralink 5.0.0.1
Serial
--
The serial port needs a TTL/RS-232 3V3 level converter! The Serial
setting is 57600-8-N-1. The board has an unpopulated 2.54mm
straight pin
header.
The pinout is: VCC (the square), RX, TX, GND.
Installation
1. Open the device, take off the heat sink
2. Connect the SPI flash chip to a flasher, e.g. a Raspberry Pi.
Also
connect the RESET pin for stability (thanks @FPSUsername for
reporting)
3. Make a backup in case you want to revert to stock later
4. Flash the squashfs-factory.trx file to offset 0x5 of the
flash
5. Ensure the bootpartition variable is set to 0 in the U-Boot
environment located at 0x3
Note that the U-Boot is password protected, this can optionally be
removed. See the forum for more details [1]
MAC Addresses(stock)
+--+--+---+
use | address | example |
+--+--+---+
Device | label | 00:00:00:11:00:00 |
Ethernet | + 3 | 00:00:00:11:00:03 |
2g | + 0x02f1 | 02:00:00:01:00:01 |
5g | + 1 | 00:00:00:11:00:01 |
+--+--+---+
The label address is stored in ASCII in the board_data partition
Known issues
- 2g MAC address does not match stock due to missing support for
that in
macaddr_add
- Only the power LED is configured by default
References
--
[1]
https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653?u=harm
Signed-off-by: Harm Berntsen
---
package/boot/uboot-envtools/files/ramips | 3 +
.../dts/mt7621_arcadyan_we420223-99.dts | 210
++
target/linux/ramips/image/mt7621.mk | 25 +++
.../mt7621/base-files/etc/board.d/02_network | 8 +
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 9 +
.../mt7621/base-files/lib/upgrade/platform.sh | 1 +
6 files changed, 256 insertions(+)
create mode 100644
target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
diff --git a/package/boot/uboot-envtools/files/ramips
b/package/boot/uboot-envtools/files/ramips
index f7f4821cef..8d4960e7a3 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -17,6 +17,9 @@ alfa-network,awusfree1|\
alfa-network,quad-e4g|\
alfa-network,r36m-e4g|\
alfa-network,tube-e4g|\
+arcadyan,we420223-99)
+ ubootenv_add_uci_config "/dev/mtd2" "0x0" "0x1000" "0x1000"
+ ;;
engenius,esr600h|\
sitecom,wlr-4100-v1-002)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000"
diff --git a/target/linux/ramips/dts/mt7621_arcadyan_we420223-
99.dts b/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
new file mode 100644
index 00..f68d79af15
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "Arcadyan WE420223-99";
+ compatible = "arcadyan,we420223-99", "mediatek,mt7621-soc";
+
+ aliases {
+ led-boot = &led_power_green;
+ led-failsafe = &led_power_red;
+ led-running = &led_power_green;
+ led-upgrade = &led_wps_green;
+ led-wifi = &led_wifi_green;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600 ubi.mtd=5
root=/dev/ubiblock0_0";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+
Re: [PATCH v2 2/2] ramips: mt7621-dts: we420223-99: mux phy0->gmac1
This gives each port an individual link to the CPU, like in f1c9afd801 (ramips: mt7621-dts: mux phy0/4 to gmac1, 2022-07-06). The advantage of this is that it can now route packets faster between the ports (before the CPU only had a single 1Gb link to the switch that has to be shared between both ports. Another advantage is that in Linux 5.10 you can now bridge a VLAN to a non-vlan port. Without this patch, you're not getting any data across the bridge. That is fixed in Linux 5.15 but is still handled by the CPU in any case. So therefore this patch is advantageous in all cases except for when you need the device as a simple switch without VLANs. For that case it's better to revert this and the switch hardware will forward traffic without bothering the CPU. Signed-off-by: Harm Berntsen You don't need to split this to another patch. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] ramips: mt7621: Add Arcadyan WE420223-99 support
The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access
point distributed as Experia WiFi by KPN in the Netherlands. It features
two ethernet ports and 2 internal antennas.
Specifications
--
SOC : Mediatek MT7621AT
ETH : Two 1 gigabit ports, built into the SOC
WIFI : MT7615DN
BUTTON: Reset
BUTTON: WPS
LED : Power (green+red)
LED : WiFi (green+blue)
LED : WPS (green+red)
LED : Followme (green+red)
Power : 12 VDC, 1A barrel plug
Winbond variant:
RAM : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM
Flash : Winbond W25Q256JVFQ, 256Mb SPI
U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1
Macronix variant:
RAM : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM
Flash : MX25l25635FMI-10G, 256Mb SPI
U-Boot: 1.1.3 (Dec 4 2017 - 11:37:57), Ralink 5.0.0.1
Serial
--
The serial port needs a TTL/RS-232 3V3 level converter! The Serial
setting is 57600-8-N-1. The board has an unpopulated 2.54mm straight pin
header.
The pinout is: VCC (the square), RX, TX, GND.
Installation
1. Open the device, take off the heat sink
2. Connect the SPI flash chip to a flasher, e.g. a Raspberry Pi. Also
connect the RESET pin for stability (thanks @FPSUsername for reporting)
3. Make a backup in case you want to revert to stock later
4. Flash the squashfs-factory.trx file to offset 0x5 of the flash
5. Ensure the bootpartition variable is set to 0 in the U-Boot
environment located at 0x3
Note that the U-Boot is password protected, this can optionally be
removed. See the forum for more details [1]
MAC Addresses(stock)
+--+--+---+
| use | address | example |
+--+--+---+
| Device | label| 00:00:00:11:00:00 |
| Ethernet | + 3 | 00:00:00:11:00:03 |
| 2g | + 0x02f1 | 02:00:00:01:00:01 |
| 5g | + 1 | 00:00:00:11:00:01 |
+--+--+---+
The label address is stored in ASCII in the board_data partition
Known issues
- 2g MAC address does not match stock due to missing support for that in
macaddr_add
- Only the power LED is configured by default
References
--
[1]
https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653?u=harm
Signed-off-by: Harm Berntsen
---
package/boot/uboot-envtools/files/ramips | 3 +
.../dts/mt7621_arcadyan_we420223-99.dts | 210 ++
target/linux/ramips/image/mt7621.mk | 25 +++
.../mt7621/base-files/etc/board.d/02_network | 8 +
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 9 +
.../mt7621/base-files/lib/upgrade/platform.sh | 1 +
6 files changed, 256 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
diff --git a/package/boot/uboot-envtools/files/ramips
b/package/boot/uboot-envtools/files/ramips
index f7f4821cef..8d4960e7a3 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -17,6 +17,9 @@ alfa-network,awusfree1|\
alfa-network,quad-e4g|\
alfa-network,r36m-e4g|\
alfa-network,tube-e4g|\
+arcadyan,we420223-99)
+ ubootenv_add_uci_config "/dev/mtd2" "0x0" "0x1000" "0x1000"
+ ;;
engenius,esr600h|\
sitecom,wlr-4100-v1-002)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000"
diff --git a/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
b/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
new file mode 100644
index 00..f68d79af15
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "Arcadyan WE420223-99";
+ compatible = "arcadyan,we420223-99", "mediatek,mt7621-soc";
+
+ aliases {
+ led-boot = &led_power_green;
+ led-failsafe = &led_power_red;
+ led-running = &led_power_green;
+ led-upgrade = &led_wps_green;
+ led-wifi = &led_wifi_green;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600 ubi.mtd=5
root=/dev/ubiblock0_0";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power_green: power_green {
+ label = "green:power";
+ gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
+ color = ;
+
Re: at803x SFP support regression in 22.03
There's this reply under one of David's patches. Give this a try. Let me know if you need help with git. https://github.com/openwrt/openwrt/commit/15167671b0d7cf0c95568dd6f9620db082df5d96#commitcomment-51920086 Arınç On 1.12.2022 15:07, Arınç ÜNAL wrote: David Bauer also did some work on it. CC'ing. On 1.12.2022 15:01, Arınç ÜNAL wrote: René van Dorst worked on this here: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/710-at803x.patch Their mail doesn't seem to work anymore. Arınç On 30.11.2022 14:49, David Collett wrote: Hi All, I am using an SFP module in a MikroTik RouterBOARD 760iGS. It works in Openwrt 21.02.x but does not in 22.03. I have documented the problem in the issue tracker here: https://github.com/openwrt/openwrt/issues/10892 I suspect the likely culprit is the updated at803x driver in the newer 22.03 kernel. Can someone familiar with the SFP support in the driver take a look? There are some logs etc there. I am happy to help test to resolve the issue. Thanks, Dave ___ 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: at803x SFP support regression in 22.03
David Bauer also did some work on it. CC'ing. On 1.12.2022 15:01, Arınç ÜNAL wrote: René van Dorst worked on this here: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/710-at803x.patch Their mail doesn't seem to work anymore. Arınç On 30.11.2022 14:49, David Collett wrote: Hi All, I am using an SFP module in a MikroTik RouterBOARD 760iGS. It works in Openwrt 21.02.x but does not in 22.03. I have documented the problem in the issue tracker here: https://github.com/openwrt/openwrt/issues/10892 I suspect the likely culprit is the updated at803x driver in the newer 22.03 kernel. Can someone familiar with the SFP support in the driver take a look? There are some logs etc there. I am happy to help test to resolve the issue. Thanks, Dave ___ 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: at803x SFP support regression in 22.03
René van Dorst worked on this here: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/710-at803x.patch Their mail doesn't seem to work anymore. Arınç On 30.11.2022 14:49, David Collett wrote: Hi All, I am using an SFP module in a MikroTik RouterBOARD 760iGS. It works in Openwrt 21.02.x but does not in 22.03. I have documented the problem in the issue tracker here: https://github.com/openwrt/openwrt/issues/10892 I suspect the likely culprit is the updated at803x driver in the newer 22.03 kernel. Can someone familiar with the SFP support in the driver take a look? There are some logs etc there. I am happy to help test to resolve the issue. Thanks, Dave ___ 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 v4 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 30.11.2022 23:35, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind Acked-by: Arınç ÜNAL Keep this if you send a new version. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] treewide: remove label = "cpu" from DSA dt-binding
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc115d8d6f73dd260de1609182f3645844d6907
Signed-off-by: Arınç ÜNAL
---
Here's how I did it, for the interested (or suggestions):
Find the targets which have got 'label = "cpu";' defined.
grep -rnw target/ -e 'label = "cpu";'
Remove the line where 'label = "cpu";' is included.
sed -i /'label = "cpu";'/,+d target/linux/*/dts/*.dts*
sed -i /'label = "cpu";'/,+d target/linux/kirkwood/files/arch/arm/boot/dts/*
sed -i /'label = "cpu";'/,+d
target/linux/mvebu/files/arch/arm64/boot/dts/marvell/*
sed -i /'label = "cpu";'/,+d
target/linux/qoriq/files/arch/powerpc/boot/dts/fsl/*
sed -i /'label = "cpu";'/,+d
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/*
sed -i /'label = "cpu";'/,+d
target/linux/mediatek/files-5.15/arch/arm64/boot/dts/mediatek/*
v2: Bindings on the DTs below are not DSA dt-bindings so drop them.
target/linux/bcm63xx/dts/bcm63169-comtrend-vg-8050.dts
target/linux/bcm63xx/dts/bcm6362-huawei-hg253s-v2.dts
target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
target/linux/bcm63xx/dts/bcm6369-comtrend-wap-5813n.dts
target/linux/mpc85xx/files/arch/powerpc/boot/dts/panda.dts
Arınç
---
target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts | 1 -
target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts| 1 -
target/linux/bmips/dts/bcm6318.dtsi | 1 -
target/linux/bmips/dts/bcm63268.dtsi| 1 -
target/linux/bmips/dts/bcm6328.dtsi | 1 -
target/linux/bmips/dts/bcm6362.dtsi | 1 -
target/linux/bmips/dts/bcm6368.dtsi | 1 -
.../kirkwood/files/arch/arm/boot/dts/kirkwood-4i-edge-200.dts | 1 -
.../linux/kirkwood/files/arch/arm/boot/dts/kirkwood-ea3500.dts | 1 -
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9.dtsi| 1 -
target/linux/mediatek/dts/mt7622-elecom-wrc-x3200gst3.dts | 1 -
target/linux/mediatek/dts/mt7622-linksys-e8450.dtsi | 1 -
target/linux/mediatek/dts/mt7622-ruijie-rg-ew3200gx-pro.dts | 1 -
target/linux/mediatek/dts/mt7622-xiaomi-redmi-router-ax6s.dts | 1 -
target/linux/mediatek/dts/mt7623a-unielec-u7623-02.dtsi | 1 -
target/linux/mediatek/dts/mt7629-iptime-a6004mx.dts | 1 -
target/linux/mediatek/dts/mt7986a-bananapi-bpi-r3.dts | 1 -
.../linux/mediatek/dts/mt7986a-xiaomi-redmi-router-ax6000.dts | 1 -
.../files-5.15/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtsi| 1 -
.../files-5.15/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts | 1 -
.../arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts| 1 -
.../files/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts | 1 -
.../files/arch/arm64/boot/dts/marvell/armada-7040-mochabin.dts | 1 -
.../files/arch/powerpc/boot/dts/fsl/watchguard-firebox-m300.dts | 2 --
target/linux/ramips/dts/mt7621.dtsi | 1 -
25 files changed, 26 deletions(-)
diff --git a/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
b/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
index 915b4414dd..2ee7ab56c5 100644
--- a/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
+++ b/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
@@ -160,7 +160,6 @@
phy0: port8@8 {
reg = <8>;
- label = "cpu";
ethernet = <ð0>;
fixed-link {
diff --git a/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
b/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
index 58586eb036..106ca56e7e 100644
--- a/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
+++ b/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
@@ -99,7 +99,6 @@
port@5 {
reg = <5>;
- label = "cpu";
ethernet = <ð0>;
};
};
diff --git a/target/linux/bmips/dts/bcm6318.dtsi
b/target/linux/bmips/dts/bcm6318.dtsi
index 9f613ad47a..13e1bf1144 100644
--- a/target/linux/bmips/dts/bcm6318.dtsi
+++ b/target/linux/bmips/dts/bcm6318.dtsi
@@ -400,7 +400,6 @@
port@8 {
reg = <8>;
- label = "cpu";
phy-mode = "internal";
ethernet = <ðernet>;
diff --git a/target/linux/bmips/dts/bcm63268.dtsi
b/target/li
Re: [PATCH] treewide: remove label = "cpu" from DSA dt-binding
On 30.11.2022 19:50, Jonas Gorski wrote: On Wed, 30 Nov 2022 at 15:43, Arınç ÜNAL wrote: This is not used by the DSA dt-binding, so remove it from all devicetrees. Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc115d8d6f73dd260de1609182f3645844d6907 Signed-off-by: Arınç ÜNAL --- These devicetrees do not define the ethernet property for CPU ports. target/linux/bcm63xx/dts/bcm63169-comtrend-vg-8050.dts target/linux/bcm63xx/dts/bcm6362-huawei-hg253s-v2.dts target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts target/linux/bcm63xx/dts/bcm6369-comtrend-wap-5813n.dts target/linux/mpc85xx/files/arch/powerpc/boot/dts/panda.dts There might be OpenWrt maintained code somewhere that checks for label cpu on these. If anyone has got one of these devices, please test network connectivity with this patch applied. The swconfig b53 driver uses the label to identify the cpu port, so NAK for bcm63xx, and I guess panda / mpc85xx/p1020. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/net/phy/b53/b53_common.c;h=87d731ec3e2a868dc8389f554b1dc9ab42c30be2;hb=HEAD#l1508 Thanks for pointing this out. Bindings on bcm63xx and panda DTs are not DSA dt-bindings so I'll drop them. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 30.11.2022 19:44, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind I assume everything works fine now? Acked-by: Arınç ÜNAL Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] treewide: remove label = "cpu" from DSA dt-binding
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc115d8d6f73dd260de1609182f3645844d6907
Signed-off-by: Arınç ÜNAL
---
These devicetrees do not define the ethernet property for CPU ports.
target/linux/bcm63xx/dts/bcm63169-comtrend-vg-8050.dts
target/linux/bcm63xx/dts/bcm6362-huawei-hg253s-v2.dts
target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
target/linux/bcm63xx/dts/bcm6369-comtrend-wap-5813n.dts
target/linux/mpc85xx/files/arch/powerpc/boot/dts/panda.dts
There might be OpenWrt maintained code somewhere that checks for label cpu
on these. If anyone has got one of these devices, please test network
connectivity with this patch applied.
Here's how I did it, for the interested (or suggestions):
Find the targets which have got 'label = "cpu";' defined.
grep -rnw target/ -e 'label = "cpu";'
Remove the line where 'label = "cpu";' is included.
sed -i /'label = "cpu";'/,+d target/linux/*/dts/*.dts*
sed -i /'label = "cpu";'/,+d target/linux/kirkwood/files/arch/arm/boot/dts/*
sed -i /'label = "cpu";'/,+d target/linux/mpc85xx/files/arch/powerpc/boot/dts/*
sed -i /'label = "cpu";'/,+d
target/linux/mvebu/files/arch/arm64/boot/dts/marvell/*
sed -i /'label = "cpu";'/,+d
target/linux/qoriq/files/arch/powerpc/boot/dts/fsl/*
sed -i /'label = "cpu";'/,+d
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/*
sed -i /'label = "cpu";'/,+d
target/linux/mediatek/files-5.15/arch/arm64/boot/dts/mediatek/*
Arınç
---
target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts | 1 -
target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts| 1 -
target/linux/bcm63xx/dts/bcm63169-comtrend-vg-8050.dts | 1 -
target/linux/bcm63xx/dts/bcm6362-huawei-hg253s-v2.dts | 1 -
target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts| 1 -
target/linux/bcm63xx/dts/bcm6369-comtrend-wap-5813n.dts | 1 -
target/linux/bmips/dts/bcm6318.dtsi | 1 -
target/linux/bmips/dts/bcm63268.dtsi| 1 -
target/linux/bmips/dts/bcm6328.dtsi | 1 -
target/linux/bmips/dts/bcm6362.dtsi | 1 -
target/linux/bmips/dts/bcm6368.dtsi | 1 -
.../kirkwood/files/arch/arm/boot/dts/kirkwood-4i-edge-200.dts | 1 -
.../linux/kirkwood/files/arch/arm/boot/dts/kirkwood-ea3500.dts | 1 -
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9.dtsi| 1 -
target/linux/mediatek/dts/mt7622-elecom-wrc-x3200gst3.dts | 1 -
target/linux/mediatek/dts/mt7622-linksys-e8450.dtsi | 1 -
target/linux/mediatek/dts/mt7622-ruijie-rg-ew3200gx-pro.dts | 1 -
target/linux/mediatek/dts/mt7622-xiaomi-redmi-router-ax6s.dts | 1 -
target/linux/mediatek/dts/mt7623a-unielec-u7623-02.dtsi | 1 -
target/linux/mediatek/dts/mt7629-iptime-a6004mx.dts | 1 -
target/linux/mediatek/dts/mt7986a-bananapi-bpi-r3.dts | 1 -
.../linux/mediatek/dts/mt7986a-xiaomi-redmi-router-ax6000.dts | 1 -
.../files-5.15/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtsi| 1 -
.../files-5.15/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts | 1 -
target/linux/mpc85xx/files/arch/powerpc/boot/dts/panda.dts | 1 -
.../arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts| 1 -
.../files/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts | 1 -
.../files/arch/arm64/boot/dts/marvell/armada-7040-mochabin.dts | 1 -
.../files/arch/powerpc/boot/dts/fsl/watchguard-firebox-m300.dts | 2 --
target/linux/ramips/dts/mt7621.dtsi | 1 -
30 files changed, 31 deletions(-)
diff --git a/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
b/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
index 915b4414dd..2ee7ab56c5 100644
--- a/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
+++ b/target/linux/ath79/dts/ar7242_ubnt_edgeswitch-8xp.dts
@@ -160,7 +160,6 @@
phy0: port8@8 {
reg = <8>;
- label = "cpu";
ethernet = <ð0>;
fixed-link {
diff --git a/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
b/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
index 58586eb036..106ca56e7e 100644
--- a/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
+++ b/target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts
@@ -99,7 +99,6 @@
port@5 {
reg = <5>;
- label = "cpu";
ethernet = <ð0>;
};
Re: [PATCH v2 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 30.11.2022 12:53, Jan-Niklas Burfeind wrote: On 11/30/22 10:41, Arınç ÜNAL wrote: On 30.11.2022 12:33, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind Acked-by: Arınç ÜNAL Arınç Something must've gone wrong. Connecting the lan port does not trigger a log message anymore. WAN still does: 982.295568] mtk_soc_eth 1e10.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx Arınç: Could you have a look at the diff, whether I deleted the node in the way you intended? Not sure what I'm missing now; worked before. Your compatible string on the DT is wavlink,ws-wn572hp3-4g but you put wavlink,ws-wn572hp3 on 02_network. You should fix this and if it still won't work, attach the bootlog. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 30.11.2022 12:33, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind Acked-by: Arınç ÜNAL Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02] ramips: mt7621-dts: revert nvmem implementation to mtd-mac-address
There's no nvmem implementation on 21.02. Revert to mtd-mac-address.
Fixes: d604032c2a50 ("ramips: fix GB-PC1 and GB-PC2 device support")
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index 8d0eaee1d4..e27c4e4d47 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -119,8 +119,7 @@
label = "ethyellow";
phy-handle = <ðphy5>;
- nvmem-cells = <&macaddr_factory_e000>;
- nvmem-cell-names = "mac-address";
+ mtd-mac-address = <&factory 0xe000>;
};
&mdio {
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 30.11.2022 01:12, Jan-Niklas Burfeind wrote:
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None - only used internally
* LTE Modem: Quectel EC200T-EU
* UART: 115200 baud
* LEDs:
* 7 blue at the front
* 1 Power
* 2 LAN / WAN
* 1 Status
* 3 RSSI (annotated 4G)
* 1 green at the bottom (4G LED)
* Buttons: 1 reset button
Installation:
* press and hold the reset button while powering on the device
* keep it pressed for ten seconds
* connect to 192.168.10.1 via webbrowser (chromium/chrome works, at
least Firefox 106.0.3 does not)
* upload the sysupgrade image, confirm the checksum, wait 2 minutes
until the device reboots
Revert to stock firmware:
* same as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
---
.../dts/mt7621_wavlink_ws-wn572hp3-4g.dts | 186 ++
target/linux/ramips/image/mt7621.mk | 17 ++
2 files changed, 203 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
diff --git a/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
new file mode 100644
index 00..89f7bb218d
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,ws-wn572hp3-4g", "mediatek,mt7621-soc";
+ model = "Wavlink WS-WN572HP3 4G";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ led-boot = &led_status_blue;
+ led-failsafe = &led_status_blue;
+ led-running = &led_status_blue;
+ led-upgrade = &led_status_blue;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset Button";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssihigh {
+ label = "blue:rssihigh";
+ gpios = <&gpio 68 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "blue:rssimedium";
+ gpios = <&gpio 81 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow {
+ label = "blue:rssilow";
+ gpios = <&gpio 80 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_blue: status_blue {
+ label = "blue:status";
+ gpios = <&gpio 67 GPIO_ACTIVE_LOW>;
+ };
+
+ // gpio 79 would be Quectels PWRKEY if used
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "config";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,fit";
+ label = "firmware";
+ reg = <0x5 0xf3>;
+ };
+
+ partition@f0 {
+ label = "vendor";
+ reg = <0xf8 0x8>;
+ read-only;
+ };
+ };
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&pcie0 {
+ wifi0: mt76@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = <&factory 0x0>;
+ };
+};
+
+&pcie1 {
+ wifi1: mt76@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = <&fac
Re: [PATCH] ramips: mt7621-dts: change DSA port labels to generic naming
On 29.11.2022 14:35, Bjørn Mork wrote: Arınç ÜNAL writes: Change the labels of the DSA ports to generic naming for switch ports. Probably stupid question, but why? Not stupid at all. The labels aren't required. Just drop them if no one depends on the current default. I wouldn't prefer removing the labels altogether. Having labels for switch ports defined on the SoC devicetree is necessary for any device that would not have its own naming over it. Especially, evaluation or development boards (which their DTs are not necessarily on mainline Linux or OpenWrt) do this. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: mt7621-dts: change DSA port labels to generic naming
Change the labels of the DSA ports to generic naming for switch ports.
Signed-off-by: Arınç ÜNAL
---
I've made sure every devicetree which includes mt7621.dtsi has got its own
label property. This won't break anything.
Arınç
---
target/linux/ramips/dts/mt7621.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621.dtsi
b/target/linux/ramips/dts/mt7621.dtsi
index 0eae4bb871..d4a920f8c4 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -529,31 +529,31 @@
port@0 {
status = "disabled";
reg = <0>;
- label = "lan0";
+ label = "swp0";
};
port@1 {
status = "disabled";
reg = <1>;
- label = "lan1";
+ label = "swp1";
};
port@2 {
status = "disabled";
reg = <2>;
- label = "lan2";
+ label = "swp2";
};
port@3 {
status = "disabled";
reg = <3>;
- label = "lan3";
+ label = "swp3";
};
port@4 {
status = "disabled";
reg = <4>;
- label = "lan4";
+ label = "swp4";
};
port@6 {
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: mt7621-dts: fix phy-mode of external phy on GB-PC2
Also, please cherry-pick to 22.03. Thanks a bunch Hauke! Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: mt7621-dts: fix phy-mode of external phy on GB-PC2
The phy-mode property must be defined on the MAC instead of the PHY. Define
phy-mode under gmac1 which the external phy is connected to.
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index 6199511cff..c18f102502 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -118,6 +118,7 @@
&gmac1 {
status = "okay";
label = "ethyellow";
+ phy-mode = "rgmii-rxid";
phy-handle = <ðphy5>;
nvmem-cells = <&macaddr_factory_e000>;
@@ -127,7 +128,6 @@
&mdio {
ethphy5: ethernet-phy@5 {
reg = <5>;
- phy-mode = "rgmii-rxid";
};
};
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router?
On 16.11.2022 11:35, Turritopsis Dohrnii Teo En Ming wrote: On Wed, 16 Nov 2022 at 20:31, Arınç ÜNAL wrote: On 15.11.2022 17:16, Turritopsis Dohrnii Teo En Ming wrote: Subject: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router? Good day from Singapore, Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router? I have searched the Table of Hardware but my device is not listed. Is it not supported? Looks like it isn't. This device has got bcm47189 / bcm53573 SoC which is supported on mainline Linux. Shouldn't be too hard to support this device. I'm not sure about wireless though. Looking at the pictures from the FCC[1], There's an 802.11n PHY, Broadcom BCM43217. It seems to be supported on mainline[2]. I can't make out the 802.11ac PHY though. If you can open the device and send me a picture, I can check if it's supported. Hi, I don't think I want to open my Asus RT-AC1200G+ wireless router. I don't want to damage it. Sure. The 802.11ac PHY is in the BCM47189 SoC and there's currently no support for that. I can build an image for you to test 2.4 GHz Wi-Fi. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router?
On 15.11.2022 17:16, Turritopsis Dohrnii Teo En Ming wrote: Subject: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router? Good day from Singapore, Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router? I have searched the Table of Hardware but my device is not listed. Is it not supported? Looks like it isn't. This device has got bcm47189 / bcm53573 SoC which is supported on mainline Linux. Shouldn't be too hard to support this device. I'm not sure about wireless though. Looking at the pictures from the FCC[1], There's an 802.11n PHY, Broadcom BCM43217. It seems to be supported on mainline[2]. I can't make out the 802.11ac PHY though. If you can open the device and send me a picture, I can check if it's supported. [1] https://fccid.io/MSQ-RT1E00/Internal-Photos/Internal-Photos-2825673 [2] https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/drivers/net/wireless/broadcom/b43/Kconfig#L116 Arınç Please advise. Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com ___ 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: do not use GPIO function on switch pins on certain devices
The pins of the MT7530 switch that translate to GPIO 0, 3, 6, 9 and 12 has
got a function, by default, which does the same thing as the netdev
trigger. Because of bridge offloading on DSA, the netdev trigger won't see
the frames between the switch ports whilst the default function will.
Do not use the GPIO function on switch pins on devices that fall under this
category.
Keep it for:
mt7621_belkin_rt1800.dts: There's only one LED which is for the wan
interface and there's no bridge offloading between the "wan" interface and
other interfaces.
mt7621_yuncore_ax820.dts: There's no bridge offloading between the "wan"
and "lan" interfaces.
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_linksys_e7350.dts | 37 ---
.../ramips/dts/mt7621_netgear_wax202.dts | 18 -
.../ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi | 37 ---
.../mt7621/base-files/etc/board.d/01_leds | 17 -
4 files changed, 109 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_linksys_e7350.dts
b/target/linux/ramips/dts/mt7621_linksys_e7350.dts
index d7b8c214b9..ea8a684148 100644
--- a/target/linux/ramips/dts/mt7621_linksys_e7350.dts
+++ b/target/linux/ramips/dts/mt7621_linksys_e7350.dts
@@ -57,40 +57,6 @@
function = LED_FUNCTION_WAN;
gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
};
-
- led-wan2 {
- color = ;
- function = LED_FUNCTION_WAN;
- gpios = <&switch0 0 GPIO_ACTIVE_LOW>;
- };
-
- led-lan4 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <4>;
- gpios = <&switch0 3 GPIO_ACTIVE_LOW>;
- };
-
- led-lan3 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <3>;
- gpios = <&switch0 6 GPIO_ACTIVE_LOW>;
- };
-
- led-lan2 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <2>;
- gpios = <&switch0 9 GPIO_ACTIVE_HIGH>;
- };
-
- led-lan1 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <1>;
- gpios = <&switch0 12 GPIO_ACTIVE_LOW>;
- };
};
};
@@ -185,9 +151,6 @@
};
&switch0 {
- gpio-controller;
- #gpio-cells = <2>;
-
ports {
port@1 {
status = "okay";
diff --git a/target/linux/ramips/dts/mt7621_netgear_wax202.dts
b/target/linux/ramips/dts/mt7621_netgear_wax202.dts
index f17a805363..02f540d743 100644
--- a/target/linux/ramips/dts/mt7621_netgear_wax202.dts
+++ b/target/linux/ramips/dts/mt7621_netgear_wax202.dts
@@ -53,31 +53,16 @@
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
- led_lan1_green: lan1_green {
- label = "green:lan1";
- gpios = <&switch0 3 GPIO_ACTIVE_LOW>;
- };
-
led_lan1_orange: lan1_orange {
label = "orange:lan1";
gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
};
- led_lan2_green: lan2_green {
- label = "green:lan2";
- gpios = <&switch0 6 GPIO_ACTIVE_LOW>;
- };
-
led_lan2_orange: lan2_orange {
label = "orange:lan2";
gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
};
- led_lan3_green: lan3_green {
- label = "green:lan3";
- gpios = <&switch0 12 GPIO_ACTIVE_LOW>;
- };
-
led_lan3_orange: lan3_orange {
label = "orange:lan3";
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
@@ -256,9 +241,6 @@
};
&switch0 {
- gpio-controller;
- #gpio-cells = <2>;
-
ports {
port@1 {
status = "okay";
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
index f19cb4db17..59fab90ed1 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
@@ -51,40 +51,6 @@
gpios = <&
[PATCH] bcm53xx: enable Broadcom 4366b1 firmware for Asus RT-AC88U
On some of the hardware revisions of Asus RT-AC88U, brcmfmac detects the 4366b1 wireless chip and tries to load the firmware file which doesn't exist because it's not included in the image. Therefore, include firmware for 4366b1 along with 4366c0. This way, all hardware revisions of the router will be supported by having brcmfmac use the firmware file for the wireless chip it detects. Signed-off-by: Arınç ÜNAL --- Hauke, please cherry-pick this to 22.03. Arınç --- target/linux/bcm53xx/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/bcm53xx/image/Makefile b/target/linux/bcm53xx/image/Makefile index d101ff95a7..ed0b755364 100644 --- a/target/linux/bcm53xx/image/Makefile +++ b/target/linux/bcm53xx/image/Makefile @@ -170,7 +170,7 @@ TARGET_DEVICES += asus_rt-ac87u define Device/asus_rt-ac88u $(call Device/asus) DEVICE_MODEL := RT-AC88U - DEVICE_PACKAGES := $(BRCMFMAC_4366C0) $(USB3_PACKAGES) + DEVICE_PACKAGES := $(BRCMFMAC_4366B1) $(BRCMFMAC_4366C0) $(USB3_PACKAGES) ASUS_PRODUCTID := RT-AC88U endef TARGET_DEVICES += asus_rt-ac88u -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 21.02 2/2] ramips: fix GB-PC1 and GB-PC2 LEDs
Add the missing LEDs for GB-PC2. Some of these LEDs don't exist on the
device schematics. Tests on a GB-PC2 by me and Petr proved otherwise.
Remove ethblack-green and ethblue-green LEDs for GB-PC1. They are not wired
to GPIO 3 or 4 and the wiring is currently unknown.
Set ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
v2: Correct misinformation in the patch log.
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10 --
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 18 ++
.../mt7621/base-files/etc/board.d/01_leds | 4 +---
3 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index 28601445e5..5910f112f6 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -27,16 +27,6 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
- gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
- };
-
- ethblue_act {
- label = "green:ethblue_act";
- gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
- };
-
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index c25ca886ae..8d0eaee1d4 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -27,16 +27,26 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
+ ethblack-green {
+ label = "green:ethblack";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- ethblue_act {
- label = "green:ethblue_act";
+ ethblue-green {
+ label = "green:ethblue";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
+ ethyellow-green {
+ label = "green:ethyellow";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ ethyellow-orange {
+ label = "orange:ethyellow";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index 5234a773ef..d9df98c63f 100755
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -42,10 +42,8 @@ dlink,dir-882-a1|\
dlink,dir-882-r1)
ucidef_set_led_netdev "wan" "wan" "green:net" "wan"
;;
-gnubee,gb-pc1|\
gnubee,gb-pc2)
- ucidef_set_led_netdev "ethblack_act" "ethblack act"
"green:ethblack_act" "ethblack" "tx rx"
- ucidef_set_led_netdev "ethblue_act" "ethblue act" "green:ethblue_act"
"ethblue" "tx rx"
+ ucidef_set_led_netdev "ethyellow" "ethyellow" "orange:ethyellow"
"ethyellow" "link tx rx"
;;
linksys,e5600)
ucidef_set_led_netdev "wan" "wan link" "blue:wan" "wan" "link"
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 21.02 1/2] ramips: fix GB-PC1 and GB-PC2 device support
Change switch port labels to ethblack & ethblue.
Change lan1 & lan2 LEDs to ethblack_act & ethblue_act and fix GPIO pins.
Add the external phy with ethyellow label on the GB-PC2 devicetree.
Do not claim rgmii2 as gpio, it's used for ethernet with rgmii2 function.
Enable ICPlus PHY driver for IP1001 which GB-PC2 has got.
Update interface name and change netdev function.
Enable lzma compression to make up for the increased size of the kernel.
Make spi flash bindings on par with mainline Linux to fix read errors.
Tested on GB-PC2 by Petr.
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 43 ++--
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 69 ++-
target/linux/ramips/image/mt7621.mk | 2 +
.../mt7621/base-files/etc/board.d/01_leds | 4 +-
.../mt7621/base-files/etc/board.d/02_network | 6 +-
target/linux/ramips/mt7621/config-5.4 | 1 +
6 files changed, 69 insertions(+), 56 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index c218521c03..28601445e5 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -8,10 +8,10 @@
model = "GB-PC1";
aliases {
- led-boot = &led_status;
- led-failsafe = &led_status;
- led-running = &led_status;
- led-upgrade = &led_status;
+ led-boot = &led_system;
+ led-failsafe = &led_system;
+ led-running = &led_system;
+ led-upgrade = &led_system;
};
keys {
@@ -27,24 +27,26 @@
leds {
compatible = "gpio-leds";
- system {
- label = "green:system";
- gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
+ ethblack_act {
+ label = "green:ethblack_act";
+ gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- led_status: status {
- label = "green:status";
- gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ ethblue_act {
+ label = "green:ethblue_act";
+ gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
- lan1 {
- label = "green:lan1";
- gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
+ power {
+ label = "green:power";
+ gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
};
- lan2 {
- label = "green:lan2";
- gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
+ led_system: system {
+ label = "green:system";
+ gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "disk-activity";
};
};
};
@@ -59,9 +61,8 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <8000>;
+ spi-max-frequency = <5000>;
broken-flash-reset;
- m25p,fast-read;
partitions {
compatible = "fixed-partitions";
@@ -107,19 +108,19 @@
ports {
port@0 {
status = "okay";
- label = "lan1";
+ label = "ethblack";
};
port@4 {
status = "okay";
- label = "lan2";
+ label = "ethblue";
};
};
};
&state_default {
gpio {
- groups = "jtag", "rgmii2", "uart3", "wdt";
+ groups = "jtag", "uart3", "wdt";
function = "gpio";
};
};
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index 613524d1da..c25ca886ae 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -8,10 +8,10 @@
model = "GB-PC2";
aliases {
- led-boot = &led_status;
- led-failsafe = &led_status;
- led-running = &led_status;
- led-upgrade = &led_status;
[PATCH v2 1/2] ramips: fix GB-PC1 and GB-PC2 LEDs
Add the missing LEDs for GB-PC2. Some of these LEDs don't exist on the
device schematics. Tests on a GB-PC2 by me and Petr proved otherwise.
Remove ethblack-green and ethblue-green LEDs for GB-PC1. They are not wired
to GPIO 3 or 4 and the wiring is currently unknown.
Set ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
v2: Correct misinformation in the patch log.
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10 --
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 18 ++
.../mt7621/base-files/etc/board.d/01_leds | 4 +---
3 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index 29f9f09ee5..809df6dde3 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -27,16 +27,6 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
- gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
- };
-
- ethblue_act {
- label = "green:ethblue_act";
- gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
- };
-
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index cd72ea1d62..6199511cff 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -27,16 +27,26 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
+ ethblack-green {
+ label = "green:ethblack";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- ethblue_act {
- label = "green:ethblue_act";
+ ethblue-green {
+ label = "green:ethblue";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
+ ethyellow-green {
+ label = "green:ethyellow";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ ethyellow-orange {
+ label = "orange:ethyellow";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index 0ac67e9670..5ffa4ecb3a 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -67,10 +67,8 @@ dlink,dir-882-a1|\
dlink,dir-882-r1)
ucidef_set_led_netdev "wan" "wan" "green:net" "wan"
;;
-gnubee,gb-pc1|\
gnubee,gb-pc2)
- ucidef_set_led_netdev "ethblack_act" "ethblack act"
"green:ethblack_act" "ethblack" "tx rx"
- ucidef_set_led_netdev "ethblue_act" "ethblue act" "green:ethblue_act"
"ethblue" "tx rx"
+ ucidef_set_led_netdev "ethyellow" "ethyellow" "orange:ethyellow"
"ethyellow" "link tx rx"
;;
linksys,e5600)
ucidef_set_led_netdev "wan" "wan link" "blue:wan" "wan" "link"
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/2] ramips: mt7621-dts: change phy-mode of gmac1 to rgmii
Change phy-mode of gmac1 to rgmii on mt7621.dtsi. Same code path is
followed for delayed rgmii and rgmii phy-mode on mtk_eth_soc.c.
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts/mt7621.dtsi
b/target/linux/ramips/dts/mt7621.dtsi
index c9f50a62f3..0eae4bb871 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -505,7 +505,7 @@
compatible = "mediatek,eth-mac";
reg = <1>;
status = "disabled";
- phy-mode = "rgmii-rxid";
+ phy-mode = "rgmii";
};
mdio: mdio-bus {
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 22.03] ramips: fix GB-PC1 and GB-PC2 LEDs
Add the missing LEDs for GB-PC2. Some of these LEDs don't exist on the
device schematics. Tests on a GB-PC2 by me and Petr proved otherwise.
Remove ethblack-green and ethblue-green LEDs for GB-PC1. They are not wired
to GPIO 3 or 4 and the wiring is currently unknown.
Set ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
v2: Correct misinformation in the patch log.
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10 --
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 18 ++
.../mt7621/base-files/etc/board.d/01_leds | 4 +---
3 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index 21a1839127..a969c93e98 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -27,16 +27,6 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
- gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
- };
-
- ethblue_act {
- label = "green:ethblue_act";
- gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
- };
-
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index cd72ea1d62..6199511cff 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -27,16 +27,26 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
+ ethblack-green {
+ label = "green:ethblack";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- ethblue_act {
- label = "green:ethblue_act";
+ ethblue-green {
+ label = "green:ethblue";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
+ ethyellow-green {
+ label = "green:ethyellow";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ ethyellow-orange {
+ label = "orange:ethyellow";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index 15e33e2f16..aad2e32b36 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -50,10 +50,8 @@ dlink,dir-882-a1|\
dlink,dir-882-r1)
ucidef_set_led_netdev "wan" "wan" "green:net" "wan"
;;
-gnubee,gb-pc1|\
gnubee,gb-pc2)
- ucidef_set_led_netdev "ethblack_act" "ethblack act"
"green:ethblack_act" "ethblack" "tx rx"
- ucidef_set_led_netdev "ethblue_act" "ethblue act" "green:ethblue_act"
"ethblue" "tx rx"
+ ucidef_set_led_netdev "ethyellow" "ethyellow" "orange:ethyellow"
"ethyellow" "link tx rx"
;;
linksys,e5600)
ucidef_set_led_netdev "wan" "wan link" "blue:wan" "wan" "link"
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02 1/2] ramips: fix GB-PC1 and GB-PC2 device support
Change switch port labels to ethblack & ethblue.
Change lan1 & lan2 LEDs to ethblack_act & ethblue_act and fix GPIO pins.
Add the external phy with ethyellow label on the GB-PC2 devicetree.
Do not claim rgmii2 as gpio, it's used for ethernet with rgmii2 function.
Enable ICPlus PHY driver for IP1001 which GB-PC2 has got.
Update interface name and change netdev function.
Enable lzma compression to make up for the increased size of the kernel.
Make spi flash bindings on par with mainline Linux to fix read errors.
Tested on GB-PC2 by Petr.
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 43 ++--
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 69 ++-
target/linux/ramips/image/mt7621.mk | 2 +
.../mt7621/base-files/etc/board.d/01_leds | 4 +-
.../mt7621/base-files/etc/board.d/02_network | 6 +-
target/linux/ramips/mt7621/config-5.4 | 1 +
6 files changed, 69 insertions(+), 56 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index c218521c03..28601445e5 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -8,10 +8,10 @@
model = "GB-PC1";
aliases {
- led-boot = &led_status;
- led-failsafe = &led_status;
- led-running = &led_status;
- led-upgrade = &led_status;
+ led-boot = &led_system;
+ led-failsafe = &led_system;
+ led-running = &led_system;
+ led-upgrade = &led_system;
};
keys {
@@ -27,24 +27,26 @@
leds {
compatible = "gpio-leds";
- system {
- label = "green:system";
- gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
+ ethblack_act {
+ label = "green:ethblack_act";
+ gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- led_status: status {
- label = "green:status";
- gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ ethblue_act {
+ label = "green:ethblue_act";
+ gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
- lan1 {
- label = "green:lan1";
- gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
+ power {
+ label = "green:power";
+ gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
};
- lan2 {
- label = "green:lan2";
- gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
+ led_system: system {
+ label = "green:system";
+ gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "disk-activity";
};
};
};
@@ -59,9 +61,8 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <8000>;
+ spi-max-frequency = <5000>;
broken-flash-reset;
- m25p,fast-read;
partitions {
compatible = "fixed-partitions";
@@ -107,19 +108,19 @@
ports {
port@0 {
status = "okay";
- label = "lan1";
+ label = "ethblack";
};
port@4 {
status = "okay";
- label = "lan2";
+ label = "ethblue";
};
};
};
&state_default {
gpio {
- groups = "jtag", "rgmii2", "uart3", "wdt";
+ groups = "jtag", "uart3", "wdt";
function = "gpio";
};
};
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index 613524d1da..c25ca886ae 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -8,10 +8,10 @@
model = "GB-PC2";
aliases {
- led-boot = &led_status;
- led-failsafe = &led_status;
- led-running = &led_status;
- led-upgrade = &led_status;
[PATCH 21.02 2/2] ramips: fix GB-PC1 and GB-PC2 LEDs
Add the missing LEDs for GB-PC2. Some of these LEDs don't exist on the
device schematics. Tests on a GB-PC2 by me and Petr proved otherwise.
Remove ethblack-green and ethblue-green LEDs for GB-PC1. They are wired to
the switch pins and have their own function for link state and activity.
Set ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10 --
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 18 ++
.../mt7621/base-files/etc/board.d/01_leds | 4 +---
3 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index 28601445e5..5910f112f6 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -27,16 +27,6 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
- gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
- };
-
- ethblue_act {
- label = "green:ethblue_act";
- gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
- };
-
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index c25ca886ae..8d0eaee1d4 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -27,16 +27,26 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
+ ethblack-green {
+ label = "green:ethblack";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- ethblue_act {
- label = "green:ethblue_act";
+ ethblue-green {
+ label = "green:ethblue";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
+ ethyellow-green {
+ label = "green:ethyellow";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ ethyellow-orange {
+ label = "orange:ethyellow";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index 5234a773ef..d9df98c63f 100755
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -42,10 +42,8 @@ dlink,dir-882-a1|\
dlink,dir-882-r1)
ucidef_set_led_netdev "wan" "wan" "green:net" "wan"
;;
-gnubee,gb-pc1|\
gnubee,gb-pc2)
- ucidef_set_led_netdev "ethblack_act" "ethblack act"
"green:ethblack_act" "ethblack" "tx rx"
- ucidef_set_led_netdev "ethblue_act" "ethblue act" "green:ethblue_act"
"ethblue" "tx rx"
+ ucidef_set_led_netdev "ethyellow" "ethyellow" "orange:ethyellow"
"ethyellow" "link tx rx"
;;
linksys,e5600)
ucidef_set_led_netdev "wan" "wan link" "blue:wan" "wan" "link"
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 22.03] ramips: fix GB-PC1 and GB-PC2 LEDs
Add the missing LEDs for GB-PC2. Some of these LEDs don't exist on the
device schematics. Tests on a GB-PC2 by me and Petr proved otherwise.
Remove ethblack-green and ethblue-green LEDs for GB-PC1. They are wired to
the switch pins and have their own function for link state and activity.
Set ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10 --
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 18 ++
.../mt7621/base-files/etc/board.d/01_leds | 4 +---
3 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index 21a1839127..a969c93e98 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -27,16 +27,6 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
- gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
- };
-
- ethblue_act {
- label = "green:ethblue_act";
- gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
- };
-
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index cd72ea1d62..6199511cff 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -27,16 +27,26 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
+ ethblack-green {
+ label = "green:ethblack";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- ethblue_act {
- label = "green:ethblue_act";
+ ethblue-green {
+ label = "green:ethblue";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
+ ethyellow-green {
+ label = "green:ethyellow";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ ethyellow-orange {
+ label = "orange:ethyellow";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index 15e33e2f16..aad2e32b36 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -50,10 +50,8 @@ dlink,dir-882-a1|\
dlink,dir-882-r1)
ucidef_set_led_netdev "wan" "wan" "green:net" "wan"
;;
-gnubee,gb-pc1|\
gnubee,gb-pc2)
- ucidef_set_led_netdev "ethblack_act" "ethblack act"
"green:ethblack_act" "ethblack" "tx rx"
- ucidef_set_led_netdev "ethblue_act" "ethblue act" "green:ethblue_act"
"ethblue" "tx rx"
+ ucidef_set_led_netdev "ethyellow" "ethyellow" "orange:ethyellow"
"ethyellow" "link tx rx"
;;
linksys,e5600)
ucidef_set_led_netdev "wan" "wan link" "blue:wan" "wan" "link"
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] ramips: mt7621-dts: change phy-mode of gmac1 to rgmii
Change phy-mode of gmac1 to rgmii on mt7621.dtsi. Same code path is
followed for delayed rgmii and rgmii phy-mode on mtk_eth_soc.c.
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts/mt7621.dtsi
b/target/linux/ramips/dts/mt7621.dtsi
index c9f50a62f3..0eae4bb871 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -505,7 +505,7 @@
compatible = "mediatek,eth-mac";
reg = <1>;
status = "disabled";
- phy-mode = "rgmii-rxid";
+ phy-mode = "rgmii";
};
mdio: mdio-bus {
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] ramips: fix GB-PC1 and GB-PC2 LEDs
Add the missing LEDs for GB-PC2. Some of these LEDs don't exist on the
device schematics. Tests on a GB-PC2 by me and Petr proved otherwise.
Remove ethblack-green and ethblue-green LEDs for GB-PC1. They are wired to
the switch pins and have their own function for link state and activity.
Set ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10 --
.../linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 18 ++
.../mt7621/base-files/etc/board.d/01_leds | 4 +---
3 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
index 29f9f09ee5..809df6dde3 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts
@@ -27,16 +27,6 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
- gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
- };
-
- ethblue_act {
- label = "green:ethblue_act";
- gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
- };
-
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
index cd72ea1d62..6199511cff 100644
--- a/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
+++ b/target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts
@@ -27,16 +27,26 @@
leds {
compatible = "gpio-leds";
- ethblack_act {
- label = "green:ethblack_act";
+ ethblack-green {
+ label = "green:ethblack";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
- ethblue_act {
- label = "green:ethblue_act";
+ ethblue-green {
+ label = "green:ethblue";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
+ ethyellow-green {
+ label = "green:ethyellow";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ ethyellow-orange {
+ label = "orange:ethyellow";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
power {
label = "green:power";
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index 0ac67e9670..5ffa4ecb3a 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -67,10 +67,8 @@ dlink,dir-882-a1|\
dlink,dir-882-r1)
ucidef_set_led_netdev "wan" "wan" "green:net" "wan"
;;
-gnubee,gb-pc1|\
gnubee,gb-pc2)
- ucidef_set_led_netdev "ethblack_act" "ethblack act"
"green:ethblack_act" "ethblack" "tx rx"
- ucidef_set_led_netdev "ethblue_act" "ethblue act" "green:ethblue_act"
"ethblue" "tx rx"
+ ucidef_set_led_netdev "ethyellow" "ethyellow" "orange:ethyellow"
"ethyellow" "link tx rx"
;;
linksys,e5600)
ucidef_set_led_netdev "wan" "wan link" "blue:wan" "wan" "link"
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
On 13.09.2022 22:56, Jo-Philipp Wich wrote: Hi, IMHO changing, in /etc/config/network: "config interface" -> "config network" "config device" -> "config interface" would eliminate this semantic inconsistency and bring the naming convention more in line with what Rich referred to in his comments above. This cannot be done in a sane manner though as it would render future versions entirely backwards incompatible. Renaming `config interface` to `config network` makes sense and can be implemented easily. However we would still need to treat `config interface` as synonym for it in the forseeable future in order to retain compatibility, which means that we cannot reuse `interface` for something else. So changing `config interface` to `config network` would be possible assuming that `config device` remains `config device` (or is renamed to something other than `interface`). Jo, I think you missed my response related to this: Anyhow, so while I agree that: Interfaces section should be called Networks. Devices section should be called Interfaces. ... it will directly contradict /etc/config/network, where networks are called `config interface` and interfaces are called `config device` likely leading to even more confusion. How about we change "config interface" to "config network" while also allowing interface or automatically converting to network for backwards compatibility, and keep "config device" intact as it's an acceptable term anyway? Sounds good. Incidentally, the config/network « interface » is referred to as « network » in config/firewall, so we already halfway there. I think changing devices to interfaces on LuCI entries is fine. If we keep « devices » (which I think is fine), I believe LuCI and uci should agree on the term. Otherwise we would still have confusion. Well, it would still be less confusing than the state we're currently in. Anyway, converting "config interface" to "config network" and "config device" to "config iface" is an option. What do you say Jo? --- At the same time, the `wifi-iface` section type in /e/c/network should be changed to `wifi-network` in order to remain consistent. Sounds good to me. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
Hey Rich, On 13.09.2022 05:43, Rich Brown wrote: Hello Arınç, Thank you for persisting in correcting my understanding. I appreciate the link to the dsa.rst document. I now realize that as you and jow have said, "DSA is simply a way to give each port of a switch its own name" so it can be configured. But if I'm reading it right, there's a clash between your definitions (say, in https://openwrt.org/playground/arinc9/network.interfaces) and the LuCI interface and the /etc/config/wirelsss terminology. If I'm reading it right, "config device" controls the configuration of interfaces, while "config interface" does what your DSA terminology calls "networks". Is this correct? Exactly. Slight correction, it's computer networking rather than DSA terminology. If my observation is correct, how can we correct the terminology across all of OpenWrt? Thanks. This is roughly the pages I'd like under the "Networking" section of the OpenWrt Wiki: - Network & Network Interfaces - DSA interfaces should be put and the dsa.rst document linked here. - Bridge VLAN Filtering - Configuring Networks & Interfaces - This can be a more generic, simple version of the "Network basics /etc/config/network" page. That page needs improvements in any case. - Converting to DSA should be included here. - Configuring the DSA interfaces on DSA Mini-Tutorial should be included here. The page structure is all blurry at the moment. Bridge VLAN filtering could be explained under the bridge interface on the "Network & Network Interfaces page." The "Configuring Networks & Interfaces" page could be merged with "Network basics /etc/config/network". It should progressively get better as we work on it. Rich PS I edited the DSA Mini-tutorial to strike through the entire Terminology section pending the outcome of this discussion. Thanks again. That part should be corrected with my comments and put on the "Network & Network Interfaces" page. I'll handle that. In a few weeks. Hopefully. Arınç On Sep 11, 2022, at 6:45 PM, Arınç ÜNAL wrote: On 12.09.2022 00:28, Rich Brown wrote: I think I see where I went wrong. I have updated the definitions in the DSA Terminology page to incorporate what I understand from this conversation. See: https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology Is this getting closer to a set of good definitions? Thanks. It's much better than before. Though, the terminology section explains computer networking rather than DSA. Interfaces and networks are beyond any sort of classification under any OSI layer. Interface is what makes the data transfer happen. It's not a protocol you can classify under an OSI layer. Network is the representation of computers (anything with the ability of computing) sending data to each other through interfaces. It represents the EVERY THING of communication. Each network entry on OpenWrt would mean that your router is a part of that network connected through an interface. Then, you can configure your computer (call this our router) to transmit and receive data in certain way. For this network which we're connected to, through this interface: Send data with this IP address, analyse received data for this range of IP addresses and act different when something we defined matches. Send data with this MAC address, listen for this MAC address on the received data. Send DHCP packets, listen for DHCP packets, etc. Does this make sense? Getting back to DSA, DSA doesn't have much to do with any of these. Like it's said multiple times in this thread (under a few different subjects), at its core, it creates a network interface for each switch port. This documentation should be enough to explain the terminology. https://github.com/torvalds/linux/blob/master/Documentation/networking/dsa/dsa.rst On top of this, I'd like to give two configuration examples for any ethernet interfaces, including the interfaces created by DSA. - One without bridge VLAN filtering - Only lan interfaces on the bridge, VLAN-unaware forwarding. - Keep wan interface separate. - No bridge, use each interface separately. - One with bridge VLAN filtering - All interfaces on the bridge, VLAN-aware forwarding. My "Converting to DSA" page already follows the second configuration. Arınç Rich On Sep 10, 2022, at 9:47 AM, Arınç ÜNAL wrote: On 10.09.2022 14:59, Rich Brown wrote: I got the following definitions from Arınç, I am taking the liberty of opening this to the entire list, so we can refine these definitions together. I include some questions in-line to clarify the definitions. As a start, certain terms have cropped up multiple times in this discussion. Could I ask for definitions for the following terms? Network: A network repre
Re: DSA Terminology
On 12.09.2022 00:28, Rich Brown wrote: I think I see where I went wrong. I have updated the definitions in the DSA Terminology page to incorporate what I understand from this conversation. See: https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology Is this getting closer to a set of good definitions? Thanks. It's much better than before. Though, the terminology section explains computer networking rather than DSA. Interfaces and networks are beyond any sort of classification under any OSI layer. Interface is what makes the data transfer happen. It's not a protocol you can classify under an OSI layer. Network is the representation of computers (anything with the ability of computing) sending data to each other through interfaces. It represents the EVERY THING of communication. Each network entry on OpenWrt would mean that your router is a part of that network connected through an interface. Then, you can configure your computer (call this our router) to transmit and receive data in certain way. For this network which we're connected to, through this interface: Send data with this IP address, analyse received data for this range of IP addresses and act different when something we defined matches. Send data with this MAC address, listen for this MAC address on the received data. Send DHCP packets, listen for DHCP packets, etc. Does this make sense? Getting back to DSA, DSA doesn't have much to do with any of these. Like it's said multiple times in this thread (under a few different subjects), at its core, it creates a network interface for each switch port. This documentation should be enough to explain the terminology. https://github.com/torvalds/linux/blob/master/Documentation/networking/dsa/dsa.rst On top of this, I'd like to give two configuration examples for any ethernet interfaces, including the interfaces created by DSA. - One without bridge VLAN filtering - Only lan interfaces on the bridge, VLAN-unaware forwarding. - Keep wan interface separate. - No bridge, use each interface separately. - One with bridge VLAN filtering - All interfaces on the bridge, VLAN-aware forwarding. My "Converting to DSA" page already follows the second configuration. Arınç Rich On Sep 10, 2022, at 9:47 AM, Arınç ÜNAL wrote: On 10.09.2022 14:59, Rich Brown wrote: I got the following definitions from Arınç, I am taking the liberty of opening this to the entire list, so we can refine these definitions together. I include some questions in-line to clarify the definitions. As a start, certain terms have cropped up multiple times in this discussion. Could I ask for definitions for the following terms? Network: A network represents a group of computers communicating with each other. Are there other constraints for what comprises a network? For example, which of these would be considered to be "a network" in our DSA discussion? - Computers in the same subnet range That's a network. - Computers on the same VLAN That's a network. - Computers physically attached to a switch or bridge (perhaps on different subnets) That'd be multiple networks but I guess that's technically a single network since computers on different subnets can still communicate with each other at the second layer. The means of delivering data in between (switch, bridge etc.) is also expected on the examples above. - Are there other synonyms for "network"? I don't believe so. Network Interface: A network interface is the point of interconnection, implemented on the software, between computers. - I had earlier written "... physical connections that convey bits/frames to other computers ... such as individual Ethernet switch ports, wireless radios, USB networking devices, VLANs, or virtual ethernets." - How much of this is correct? What should be added or removed? - What about bridges, tunnels, alias interfaces - include or exclude them? Why? - Must a network interface to be "implemented in software"? That's what a network interface is. It's a software term. - Or do you mean that the network interface is the "software representation" of a physical connection? Software representation of interconnection, doesn't have to be physical. Interface: Short for network interface. - Can we *always* treat this as a synonym for "network interface"? I believe so. Device: Another term for network interface, used a lot on Linux kernel development. - Can we *always* treat this as a synonym for "network interface"? No. Outside of Linux driver development, I don't see this widely used in computer networking software. Netdev: A mailing list for all network-related Linux stuff. https://docs.kern
Re: DSA Terminology
On 10.09.2022 14:59, Rich Brown wrote: I got the following definitions from Arınç, I am taking the liberty of opening this to the entire list, so we can refine these definitions together. I include some questions in-line to clarify the definitions. As a start, certain terms have cropped up multiple times in this discussion. Could I ask for definitions for the following terms? Network: A network represents a group of computers communicating with each other. Are there other constraints for what comprises a network? For example, which of these would be considered to be "a network" in our DSA discussion? - Computers in the same subnet range That's a network. - Computers on the same VLAN That's a network. - Computers physically attached to a switch or bridge (perhaps on different subnets) That'd be multiple networks but I guess that's technically a single network since computers on different subnets can still communicate with each other at the second layer. The means of delivering data in between (switch, bridge etc.) is also expected on the examples above. - Are there other synonyms for "network"? I don't believe so. Network Interface: A network interface is the point of interconnection, implemented on the software, between computers. - I had earlier written "... physical connections that convey bits/frames to other computers ... such as individual Ethernet switch ports, wireless radios, USB networking devices, VLANs, or virtual ethernets." - How much of this is correct? What should be added or removed? - What about bridges, tunnels, alias interfaces - include or exclude them? Why? - Must a network interface to be "implemented in software"? That's what a network interface is. It's a software term. - Or do you mean that the network interface is the "software representation" of a physical connection? Software representation of interconnection, doesn't have to be physical. Interface: Short for network interface. - Can we *always* treat this as a synonym for "network interface"? I believe so. Device: Another term for network interface, used a lot on Linux kernel development. - Can we *always* treat this as a synonym for "network interface"? No. Outside of Linux driver development, I don't see this widely used in computer networking software. Netdev: A mailing list for all network-related Linux stuff. https://docs.kernel.org/process/maintainer-netdev.html#what-is-netdev - Is "netdev" used commonly in DSA/OpenWrt as a formal term? - If not (and if we need to rename something in config files), could the term "netdev" provide a new word that isn't ambiguous? I don't understand what you're getting at? Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
On 10.09.2022 14:52, David Lang wrote: On Sat, 10 Sep 2022, Arınç ÜNAL wrote: As a start, certain terms have cropped up multiple times in this discussion. Could I ask for definitions for the following terms? Here's my understanding. There is a difference between a physical device that passes bits and the logical interface that communicates with a network range. A given physical devices can have multiple logical interfaces on them, and a logical interface can use multiple physical devices to communicate (i.e. it's not a 1:1 relationship between logical interfaces and physical devices. Agreed. I don't see my writing below contradicting this. All I talk about is software, there's no physical remarks. LUCI is inconsistant and sometimes calls physical devices 'interfaces' and sometimes calls logical interfaces 'interfaces' I find it nonsensical to bring physical devices into software definitions. It's not physical device that is being called interface, it's the driver creating an interface on software by making use of the physical device. Be it software feature (vlan, bridging, tunnelling) or a physical device (a switch, a NIC, a wireless NIC), they're all called network interfaces on software. I believe I explained types of network interfaces here in a sensible fashion: https://openwrt.org/playground/arinc9/network.interfaces#certain_types_of_network_interfaces I would have to go back over this thread to give a better definition for each term, but they are not all names for the same thing as described below (well, they can be in simple configurations, but much more complex configurations are possible, and as people start using the power, the confusion of terms causes problems) David Lang Network: A network represents a group of computers communicating with each other. Interface: Short for network interface. Network Interface: A network interface is the point of interconnection, implemented on the software, between computers. Device: Another term for network interface, used a lot on Linux kernel development. Netdev: A mailing list for all network-related Linux stuff. https://docs.kernel.org/process/maintainer-netdev.html#what-is-netdev Other terms? I think this is inclusive enough. Arınç ___ 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 Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
On 10.09.2022 03:04, Rich Brown wrote: Thanks for all this discussion. I have read everyone's notes carefully, but I feel as if I am falling farther and farther behind. I don't understand the distinctions between the terms that everyone is using. (The networking field is replete with synonyms for the same thing: "interface" (and device, port, jack, socket, interface, etc.) might refer to that hole in the back of a computer that receives an RJ-45 connector. And "interface" (and network, subnet, address range and others) might apply to the 192.168.1.1 .. 255 concept. I think that's what's happening here.) Perhaps I have missed a glossary for these terms. Just point me to one that works for this DSA discussion. If there isn't one, we need to make one. As a start, certain terms have cropped up multiple times in this discussion. Could I ask for definitions for the following terms? Here's my understanding. Network: A network represents a group of computers communicating with each other. Interface: Short for network interface. Network Interface: A network interface is the point of interconnection, implemented on the software, between computers. Device: Another term for network interface, used a lot on Linux kernel development. Netdev: A mailing list for all network-related Linux stuff. https://docs.kernel.org/process/maintainer-netdev.html#what-is-netdev Other terms? I think this is inclusive enough. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hey Luiz, On 8.09.2022 06:28, Luiz Angelo Daros de Luca wrote: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled Bridging virtual 802.1q interfaces might fail in some scenarios, like when you use vlan1 or mix tagged with untagged traffic (https://github.com/openwrt/openwrt/issues/9066) I do recommend bridge-vlan as the first option, although ip-bridge is not installed by default. I know that it is a little bit off topic but I would love some transitioning code that could mimic swconfig devices as if they were DSA. Instead of using swconfig settings for tagged vlans/isolated ports, just create fake lan1, lan2, wan interfaces (802.1q) and derive the swconfig settings from that. I've been doing that for some time, creating switch_vlan configs from bridge+bridge-vlan and replacing the user ports with the CPU port in every related bridge-vlan. This way I can share the config with swconfig, DSA and even devices without switches (VM like gns3) if I rename eth0, eth1, eth2 to lan1, wan, lan2. The only downsides are that untagged bridging is done using software bridge and the config is generated as a single-shot step (uci-default). However, if that mapping is done inside netifd, I believe it might be able to better handle those cases. I tried this two months ago, here are the steps I took to be precise: ## Set up the Interfaces - Put each port on a different VLAN as untagged, set the CPU port tagged. - Rename ethX.y to the switch port name you want (optional). - There’s currently no way. So just ignore ethX.y interfaces and manually create VLAN interfaces of ethX with the interface name mimicking DSA. - Put the manually created interfaces on a VLAN filtering enabled bridge. ## Untagged - Set a VLAN ID as untagged on the manually created interfaces. - Configure LAN with that VLAN interface of the bridge to be able to reach the router from the switch ports. This works great until tagged frames are involved: ## Tagged - Set a VLAN ID as tagged for a manually created interface. - Create a new network with that VLAN interface of the bridge. Set IP to 192.168.1.1/24 and use a firewall zone with everything allowed. - Set that VLAN ID on the computer and set IP to 192.168.1.2/24. - Ping 192.168.1.2 from the router. - See if tagged frames pass the switch port with the bridge VLAN filtering feature. - Tagged frames leave the switch port. However, tagged frames coming in will be dropped since the port was configured to only allow untagged frames. If someone is confused like I was before, swconfig’s VLAN filtering won’t interfere with bridge VLAN filtering because they are separate systems. With these findings, there are two changes I can see being made to swconfig: - Allow custom names for the VLAN interface of the CPU port. - Allow forwarding tagged frames to the CPU port coming from a switch port set as untagged. Nonetheless, this is extremely hacky so I just put this out here for some fun talk. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
