administrators

Wanted to weigh in here - getting an Expansion Dock + Ethernet Expansion or an Evaluation Board will save you lots of time and headaches!

This was an oversight on my end. It went unnoticed because the p44 ledchain package is not part of our default firmware. So we never ran into the issue.

Resolution:
We've updated the image builder profiles in the OnionIoT/openwrt-imagebuilder-wrapper and OnionIoT/openwrt-packages (openwrt-23.05 branch) repos to include the new repo (http://repo.onioniot.com/omega2/packages/openwrt-23.05.3/core/).

Now firmware images that include the kmod-p44-ledchain package can be built out of the box.

Why was this an issue?

• The kmod-p44-ledchain package is no longer being built with the build system, so it's no longer available in the http://downloads.onioniot.com/releases/23.05.3/targets/ramips/mt76x8/packages/ package repo, as @DocHardinger noticed above
• Now, the OpenWRT SDK is being used to build the kmod-p44-ledchain package, this involved creating a new package repo
• The new package repo was included in the firmware and in the OpenWRT SDK wrapper configuration, but not the image builder configuration

See the relevant thread for more details

@DocHardinger said in 23.05.3 iwinfo scan disconnects AP:

It seems there has something changed inside the wifi driver? @Lazar-Demin

Yes, there have definitely been changes in the wifi driver between the 22.03 and 23.05 firmware releases:

• The 22.03.5 firmware uses the mt76 wifi driver with datecode 2022-09-06
  (https://github.com/openwrt/openwrt/blob/v22.03.5/package/kernel/mt76/Makefile#L11)

• While the 23.05.3 firmware uses mt76 wifi driver datecode 2023-09-11 (https://github.com/openwrt/openwrt/blob/v23.05.3/package/kernel/mt76/Makefile#L11)

We're not as up to date on the internal changes since the new beta firmware uses the open source mt76 driver.
But since it's open source, the good news is you can investigate this directly and open an issue if needed: https://github.com/openwrt/mt76

Yep, production is complete and the units are all set to be shipped out to Crowd Supply. Just ironing out the final details with the Crowd Supply fulfillment team.

@MK I agree with @crispyoz that rc.local is the lowest impact file.

To make it even more low impact, I would suggest adding a uci defaults file that changes rc.local instead of overwriting the default rc.local.

UCI defaults are generally used to pre-configure the UCI configuration (/etc/config) in your images. But we also use this mechanism to pre-configure other things, like the login banner for example: https://github.com/OnionIoT/OpenWRT-Packages/blob/openwrt-23.05/omega2-base/files/etc/uci-defaults/14_banner

More info on uci defaults here: https://openwrt.org/docs/guide-developer/uci-defaults

@Mark-C We've actually been working with our distributors to make the Omega2 LTE Global variant more accessible!

We're happy to report both Mouser and Digikey have reduced their minimum order quantity for the OM-O2LTE-G. Find the purchase links here: https://onion.io/buy?p=OM-O2LTE-G

@crispyoz DT overlay packages unfortunately won't work in vanilla 24.10

DT overlay depends on a few patches to the kernel that we add to the build system (See patches 251-253 at https://github.com/OnionIoT/openwrt-buildsystem-wrapper/tree/openwrt-23.05/onion/patches)

@crispyoz I don't remember the exact reasoning, but in one kernel release all of the bitbang implementations of hw buses were taken out.
I really liked how flexible these modules were - you could specify which GPIOs did what in the insmod command that loaded the kernel module.

Like @luz mentioned, DT overlays are the best game in town for this at the moment.
We have the onion-dt-overlay-sw-spi package available, and we also recently put out a onion-dt-overlay-sw-spi-alt package that uses more readily accessible GPIOs:

sck -> gpio3
cs0 -> gpio2
mosi -> gpio1
miso -> gpio0

(coming soon to the documentation) See the Software SPI bus article in the new documentation for more details.

It's not as easy as using kmod-spi-gpio-custom , but if you're comfortable using the OnionIoT/openwrt-sdk-wrapper, you can work off onion-dt-overlay-sw-spi to spin your own software spi package that uses GPIOs that work for you!

@luz said in u-boot binary too large on compile:

having cross-links between build environments, pre-built x86 binaries etc. feels a bit brittle to me, so what I would like to do is getting uboot for omega2 built as an openwrt package.

I agree, it is brittle. It was something we put in place back when x86 was the only game in town for desktop computing

We also noticed the OpenWRT build system has an option to build the bootloader, but haven't explored that path yet.

Like I mentioned in the Omega2S+ sys_led pin thread, we're contemplating moving to a more modern u-boot. I think this would give us more impact for the time spent.
And we could set it up to be less brittle from the get go.

@luz @crispyoz let me know your thoughts and if you're interested in collaborating on this!

@luz said in Omega2S+ sys_led pin:

I would be much more nice to have:
//gpio44 gpio_dclr_1 644 clear bit12
RALINK_REG(RT2880_REG_PIORESET+0x04)=1<<12;

Agreed! There's many instances of this type of thing in the omega2-bootloader codebase, among other quirky code.
There were many different contributors and we didn't have coding standards or best practises defined at the time.

Our philosophy on this bootloader is currently "if it ain't broke, don't fix it." That said, we do welcome PRs if you're inspired.

Since we're on the topic of bootloaders:
We're also contemplating moving to modern u-boot. The issue there is the default bootloader binary is over 512kB, while the Omega2/2+ device definition only partitions 192kB for the bootloader.
So any devices with the new bootloader would be incompatible with the existing firmware images.
Alternatively, we could add a new variant/SKU that is the same hardware (as the Omega2S+) but runs the new bootloader. This involves logistical challenges.

We're open to suggestions on this front. Let us know what works for you, Onion Community!