Upgrade to OpenWRT 21.02 coming soon?
-
This post is deleted!
-
This post is deleted!
-
I’m back working with the omega2s and I’d love to get the upgrade to the latest openwrt done as a part of that work. Is there any timeline on an official update to a newer openwrt?
Regards,
Chris
-
oh yes. We are waitinig it too. Our customer needed supported OS.
-
Hi, guys. How to enable ethernet and WiFi on this firmware?
root@Omega-3079:~# service network reload [ 1255.006885] rt3050-esw 10110000.esw: link changed 0x00 root@Omega-3079:~# [ 1259.065375] rt3050-esw 10110000.esw: link changed 0x01 root@Omega-3079:~# /etc/init.d/network reload [ 1308.682476] rt3050-esw 10110000.esw: link changed 0x00 root@Omega-3079:~# [ 1312.364129] rt3050-esw 10110000.esw: link changed 0x01 root@Omega-3079:~# ifconfig ..... eth0 Link encap:Ethernet HWaddr 40:A3:6B:C1:30:7A UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13104 errors:0 dropped:1 overruns:0 frame:0 TX packets:413 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1496552 (1.4 MiB) TX bytes:42273 (41.2 KiB) Interrupt:5 root@Omega-3079:~# wifisetup --help /bin/ash: wifisetup: not found
-
@Pavel-Negrobov wifisetup command is an Onion tool not available if you are using a standard OpenWrt firmware. You can refer to the OpneWrt documentation for how to configure your network.
https://openwrt.org/docs/guide-user/base-system/basic-networking
-
@crispyoz thank you
-
@Lazar-Demin any news on OpenWRT 21.02? (polite question)
-
@Lazar-Demin I hope all is good there.
I'm planning to upgrade to 19.07 or 21.02.
Can you please update us about the plans you have for this?
-
In the meantime, OpenWrt 22.03 is about to get released...
I have largely migrated my own firmware build already, and it works so far. I'm posting here in case anyone is interested in my status quo and/or cooperation to research/iron out the remaining problems.
All in all, the jump from 19.07 went quite smoothly, networking/wifi (mt76 though, not firecore) config just worked as-is.
At this time, I have two issues:
- gpio numbering got totally weird as in newer kernels, gpio numbers have become second class citizens, and gpio labels in the device tree are the recommended way to go. Still, /sys/class/gpio exists and works, but the numbers are offset by 416, but also swapped in order such that gpiochip2 ones come first.
[Update: I could track down the reason for this in the kernel sources: drivers could (and still can, but it's deprecated!) set abasenumber for GPIO banks, or let the kernel automatically assign numbers by settingbaseto -1. The automatic assignment is ingpiochip_find_base(), and explains the weird outcome: for each GPIO bank registered, it sets base such that the bank gets the highest available GPIO numbers, down fromARCH_NR_GPIOSwhich is 512 by default. So we get 480..511 for the GPIOs that used to be numbered 0..31, 448..479 for 32..63 (and, only theoretically because not exposed, 416..447 for 64..95).
The Linux kernel guys are quite eager to kill the "old" GPIO numbers, see these comments - "...drop this and assign a poison instead."
. So while one could add a patch to set baseat it was in older kernels to get the old numbers back, I doubt that would be a good way forward.] - kmod-spi/i2c-gpio-custom no longer exist. The way to go is probably using device tree overlays (like the raspberry folks already do for a long time), but that needs enabling
OF_OVERLAYin the kernel and having thedtcdevice tree compiler available. I'm about to build a fw with this and will start tinkering with dtc and overlays...
[Update2: I got dynamic device tree overlays working, once I found it involves more than just settingOF_OVERLAY. One also needsCONFIGFS_FSand a patchset that was rejected in OpenWrt mainline, which in turn allows loading DT overlays via configfs from userland whenOF_CONFIGFSis also set.
[Update:I had no luck yet with]OF_OVERLAY, altough I built the kernel with that option set, I did not get the/sys/kernel/config/device-tree/overlays/node for actually managing DT overlays yet. Any ideas what I'm doing wrong? Apparently there's more to it than just settingOF_OVERLAY
[Update2: I also made a post in the OpenWrt developer mailing list asking about general status of GPIOs in OpenWrt 22.03, got no feedback yet]
- gpio numbering got totally weird as in newer kernels, gpio numbers have become second class citizens, and gpio labels in the device tree are the recommended way to go. Still, /sys/class/gpio exists and works, but the numbers are offset by 416, but also swapped in order such that gpiochip2 ones come first.
