1. Home
  2. Omega Talk
  3. Upgrade to OpenWRT 21.02 coming soon?

Upgrade to OpenWRT 21.02 coming soon?

  • C

    I see a 21.02 branch of openwrt on GitHub, https://github.com/OnionIoT/source/tree/openwrt-21.02-dev, is this planned for release in the near future? I went and upgraded some tool revs, like node, and now the 18.06 image isn't able to build as the node rev is too old.

    Is 21.02 usable? Stable? Planned for release soon?

    0
  • V

    This post is deleted!
    0
  • C

    @Chris-Morgan Since OpenWrt hasn't specified any release date for 21.x, I'm not sure this is a reasonable request of Onion as their release would obviously follow that of OpenWrt.

    I can confirm that 21.02 RC3 does run on O2S+ but you need to manually configure the WiFi, same as 19.07. I've been running 21.x for 2 or 3 months on a POC custom board based on O2S+ and thus far no real issues. So far the only nagging concern is the WiFi connections seem to be a little slower than my 18.06 devices using Warp Core. Haven't had time to investigate in detail thus far so I may be wrong.

    1
  • S
    Banned

    This post is deleted!
    0
  • Lazar Demin
    administrators

    Wanted to weigh in here:

    That's right, we did some experimenting with and testing of OpenWRT 21.02 earlier this year. Hence the openwrt-21.02-dev branch on the OnionIoT/source repo.

    There's no plans to make an official release in the near term. As @crispyoz pointed out, there's no official release from OpenWRT yet - we'll see how they fare and adjust accordingly.

    That being said, there IS an experimental openwrt-21.02 image available for the Omega2+.
    The image can be found here: http://repo.onioniot.com/omega2/images/beta/

    It was built using the code in the OnionIoT/source repo openwrt-21.02 branch, following the instructions in the README in the onion directory

    We don't recommend using this image for any production environment, just for testing for now.

    What currently works

    • Wifi
      • Using the open source mt76 image
    • Ethernet
    • USB
    • SD Card
      • May need to install appropriate kmod-fs-* packages
    • I2C
      • Need to install kmod-i2c-mt7628 package
    • Python3
      • Can be installed from the OpenWRT package repo

    What does not work or is not included

    • All Onion packages
    • nodejs
      • Not included in the OpenWRT package repos, not yet being built by us

    Next Steps

    If you end up trying it out, let us know how it goes! We're interested in your feedback and to hear what should be done/added/changed next!

    0
  • M

    Hello Lazar,

    Any update after the post in July?

    The current image from Onion is running 18.06 which was EOL a year ago... šŸ˜ž

    According to openwrt.org:
    This lists the currently support or not supported OpenWrt versions.

    Version --Current status -----Projected EoL
    21.02 Fully supported
    19.07 Security maintenance March 2022
    18.06 End of life ---------- December 2020
    17.01 End of life EoL
    15.05 End of life EoL

    1
  • W
    Banned

    This post is deleted!
    0
  • W
    Banned

    This post is deleted!
    0
  • C

    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

    1
  • M

    oh yes. We are waitinig it too. Our customer needed supported OS.

    0
  • P

    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
    0
  • C

    @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

    0 P 1 Reply
  • P

    @crispyoz thank you

    0
  • P

    @Lazar-Demin any news on OpenWRT 21.02? (polite question)

    0
  • L

    @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?

    0
  • luz

    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 a base number for GPIO banks, or let the kernel automatically assign numbers by setting base to -1. The automatic assignment is in gpiochip_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 from ARCH_NR_GPIOS which 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 base at 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_OVERLAY in the kernel and having the dtc device 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 setting OF_OVERLAY. One also needs CONFIGFS_FS and a patchset that was rejected in OpenWrt mainline, which in turn allows loading DT overlays via configfs from userland when OF_CONFIGFS is 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 setting OF_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]

    0
openwrt 65 openwrt 21.02 1
Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.