Topics created by Chris Morgan

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]

The OpenWrt build system creates the feeds automatically, along with building the firmware image. After a complete build, all feeds can be found in bin/packages/mipsel_24kc (within the openwrt build directory). Just copy these files to a web server and let /etc/opkg/customfeeds.conf (on your Omega2) point to the feeds you need. Of course, you need the OpenWrt build system for the Omega2 to get started. To add your own feed, create a directory on your machine (or a git repository elsewhere) and put the packages you need there. You can copy whole package directories from other third party feeds, or of course create your own packages. To make the feed known to OpenWrt, edit feeds.conf (if it does not exist, copy feeds.conf.default to feeds.conf first), and add a line like: src-git myfeed https://myserver.com/feeds/myfeed.git;master src-link myfeed /path/to/myfeed (first is in case you have git repository, second is just linking a local feed directory). See openwrt docs for details. Then, you need to install the packages (meaning: make available for building, says nothing about actually building them, that's what you'll do in menuconfig, see below) using the ./scripts/feeds utility: ./scripts/feeds update myfeed ./scripts/feeds install -p myfeed mypackage (the -p myfeed part is only needed in case other feeds might also contain a package named mypackage, to make sure the version from your feed is preferred). After that, mypackage will show up as an option in make menuconfig. Now you can set it to M (build the package, but do not include it into the firmware image, which means that you can install it with opkg later) or * (build and include into firmware image). If you want an example for a custom feed for Omega2, you could have a look at my own custom feed.

@Chris-Morgan said in Is there a BT/BLE chip level option suggested for the Omega2+ or the Omega2S+?: s for mechanical and cost savings. Something t Hey Chris, You could purchase a nRF52832 module. Then flash it with this firmware: https://github.com/theBASTI0N/nrf52832_scanner I then created an application that will receive the BLE data over UART. It then decodes the data and sends it over MQTT. https://github.com/theBASTI0N/ble2mqtt Making your onion I nice BLE gateway. Also the aplication will work with Bluez compatable devices.

@rajvigneshtn please run make again with -j 1 V=s. Parameters and post the log.

Yes, there is A bit of context: OpenWrt (on which OnionOS is built) is a network router OS, and as such it needs to have a web-UI which can access and modify system configuration and status. This OpenWrt Web-UI is called LuCI ubus (u=µ, micro bus) is one part of the infrastructure for that, as it allows to query and command various system parts. uci (the unified configuration interface) is another part, it allows to manage more static configuration in a standardized way, and is accessible via ubus. So in order for LuCI to use ubus to do stuff, including using uci, there needs to be a http-to-ubus bridge, which comes in the form of a uhttpd plugin called uhttpd-mod-ubus. There's documentation about this here. As I'm a user of stock OpenWrt on Omega2, I'm not absolutely sure about the exact state of OnionOS, but judging from the .config on github uhttpd-mod-ubus is installed by default and should be working. So I guess you need to start at creating a ACL and read on to understand how how to login and get a session id via http.

Hi @György-Farkas. Same SD card works fine on another Omega2+ so I'm less likely to think its the card. Supply voltage looks good as well, 3.45v (need to adjust regulator resistors to bring that down to 3.3v) That's a good path to check and more data sheet driven then my approach of swapping the cards and performing a functional check. I saw that diagram with those pinouts as well but isn't EPHY_APGIO_AIO_EN set in software and not affected by the boot pins? After a few hours of experimenting here the issue turned out to be a relatively strong pulldown on GPIO45. This was affecting a boot pin. Looking at http://plan44.ch/downloads/Onion-Omega2-Pinout-annotated.png and the MT7688 data sheet though it isn't clear exactly what the issue is. Measuring the module itself there is a 4.7k pullup to 3.3V on that pin, so no need for external strapping. Pulling that pin down would appear to be enabling JTAG mode, page 33 of the MT7688 data sheet fyi. JTAG pins look entirely separate from SD interface pins though so maybe I'm close on the bootstrap pin issue but off on the effect? I still can't figure out why everything would boot fine if that GPIO45 was strapped low (overriding the 4.7k pullup) but just the SD card wouldn't be working......

@Chris-Morgan said in Where can I find the Omega2+ schematics (model: OM-O2P)?: That's the same url I posted above Yes. As you know the Onion Omega2+ is (only a little bit more than two (2) year old device. So I just drew your attention to this important info: Updates will occur on a regular basis, stay tuned! / @Lazar-Demin/

We've updated the build system and Docker image - the libwebsockets + mosquitto issue has been resolved. More info here: http://community.onion.io/topic/3666/plans-to-update-the-onion-omega2-source-docker-container/3

@György-Farkas alright, after the upgrade to 0.2.x content and configuration is persisting across power cycles. Thank you for your help. It's too bad the UI told me that the old version I had was the latest version. If it had prompted me to upgrade I wouldn't have had any of these issues! Now the new web interface is missing the "Settings" app. Trying to figure out what package that is contained in so I can install/reinstall that!

Please check out the post by Krzysztof Skiba in Will an official KiCAD library and footprint be released for the Omega2S?. The title is about the Omega2S, but Krzysztof Skiba gave us a link to files on Omega2 Kicad footprint & 3D shape.