Here's an annotated Omega2 pinout which lists all possible pin functions and the actual MT7688 pin names (in boldface) as found in the datasheet. The red ones are those signals sampled by the MT7688 at reset to determine operation mode, so these must not have heavy load and/or pullup/downs.

I did that pinout for deciding which pins to use for what when designing a PCB for a Omega2 based project of mine. I hope it might be useful for others

[Update: the latest version, covering Omega2 and Omega2S, including additional info about pins with bootstrapping functions, can be downloaded here]

[Update: in case you are looking for a similarily annotated pinout for the Omega2S, look here]

@Luciano-S. It's a good thing LEDE and OpenWrt devs join forces again, sure!

However, it will not make any difference for the Omega firmware.

What would make a difference was when @Onion would finally fully open source their firmware build as promised, so that member of this community and Onion devs could join forces!

But as long as everything hinges on Onion folks finding time for it (which they don't, because they are too busy, and understandably so), progress stalls, and community enthusiasm is fading.

Onion, please allow us to help!

@Koos-du-Preez Here's an Eagle library which has Omega1 and Omega2 in it, plus a few other components such as the very affordable HLJ-6115ANL Ethernet connector with magnetics included.

I've been using this for some prototypes and had the PCBs made at oshpark.

The prototypes worked, so parts should be ok, but no guarantees…

PS: and don't ask me anything about Eagle - I've tried it only for that project, but moved to open source KiCAD since. Despite a few quirks I find KiCAD much easier to work with.

The standard WiFi driver for the MT7688 currently included in LEDE apparently neither works reliably, nor with acceptable throughput at this time (That driver is true open source work in progress, contributed by very dedicated LEDE developers in a very hostile field, so I'm not criticizing it at all - it's just not ready yet!)

Onion, for this reason, is using another (proprietary?) driver for the official Omega2 firmware, which works fine.

But using the Omega2 with a LEDE build currently means essentially having no WiFi.

That's how I happily used the Omega2 for in my projects of the last few months (always using wired Ethernet).

But now I'd like to mix the work of these months (e.g. the ledchain kernel module) with WiFi.

Easiest would be if Onion would fully publish their LEDE setup, but unfortunately all forum threads regarding this (for example here, here, here and here) and even contributing just stalled.

Now I wonder if it would be possible to somehow just extract the working wifi driver and use it with otherwise standard LEDE? Any ideas?

Three weeks ago I fixed gpio-irq to work on the Omgea2, because someone asked for it. I posted it as a pull request on github for OnionIOT.

But as I had zero feedback so far, I am wondering if creating a pull request maybe isn't the right way to bring contrubutions to the attention of the @onion @administrators. Should we notify specific persons directly? @Lazar-Demin? @Gabriel-Ongpauco? @Boken-Lin?

I mean, I'm not expecting immediate pulling, but some indication if the contribution was seen at all, and if so, whether it is welcome or not - that would be great!

BTW: just a few minutes ago, I also posted a pull request for omega2-ctrl as it was missing some useful mux configuration states.

Things are moving! Have a look at the github repo!

This does answer my original question - YES, Omega2 does use LEDE! Great! (see paragraph "the operating system")

Now I hope the LEDE fork actually used for the Omega2 will soon get available. Maybe it will be a while until Omega2 support becomes part of LEDE mainline (fully understandable, preparing and submitting patches takes time).

But please just publish Onion's LEDE fork as-is soon, including the .config. So the community can actually participate and contribute to the ongoing project.

@Luciano-S Sticking to an old kernel just to avoid kernel mismatch can't be the solution either. It all hinges on public availability of the exact same LEDE/OpenWrt tree + config which Onion uses internally for the firmware, that allows building packages against whatever kernel is used on the Omega. So again - development in the open is the key

Some background information about the reason for the "arcing" and "micro-welding" described above:

It is usually caused by inductive loads, like electromagnets, motors, transformers - pretty much anything that is based on a coil of some kind.

Coils have a surprising property - the current that flows through them cannot suddenly change. So if you have a motor running on, say, 200mA, and your relay breaks the circuit, the current needs some time to ebb, it cannot go from 200mA to zero at once.

But how is this possible with the circuit open? There's only one way - the voltage between the now open contacts will rise so high that the current can flow through the air between the contacts! High voltage can ionize air to make it conductive. In small scale this is called an electric arc, in large scale it's called lightning...

In both cases, it's very hot, and happening between relay contacts causes contact material to melt and micro-weld. Even if the relay spring is strong enough to rip the contacts apart eventually, and the relay does not stick, this ruins the contacts over time, and should be avoided.

But how?

If the circuit is DC, it's simple. You just need a so called flyback diode over the inductive load which allows the coil to discharge its energy without generating high voltage.
Note that this is also essential when driving a relay (a coil, too!) from an electronic circuit. If you forget the flyback diode, the high voltage will disturb or even destroy the electronics. See D3 and D5 on the Onion Relay Expansion schematics.

If the circuit switched by the relay is AC, a diode does not work (would short-cicuit half of the time and destroy itself). Instead, use a RC snubber, a capacitor in series with a resistor. For use with 230V AC, ~20..100nF/400V capacitor and a 100Ω/2W resistor works. The snubber consumes some energy of it's own, that's why the resistor should be a 2W type, and will produce some heat. There are also RC snubbers in a single part, like this one.

Hope this help to tame your relay circuits

As a side note: there are circuits where the high voltage caused by breaking the circuit of a coil is the desired result - ignition in combustion engines, electric cattle fences...

@DumTux said in CAN Bus: using MCP2515 with Omega2:

Is there a quick way to check if GPIO11 is released from Omega2's bootloader for general-purpose use?

If you can "export" it via the '/sys/class/gpio' interface (before loading your driver that may try to use it, and possibly block it even if not successful establishing it as IRQ), then it should be available.

However, when you are using unpatched 22.03, the /sys/class/gpio interface (deprecated by now) will have completely strange GPIO numbering: GPIO 0..31 -> 480..511, GPIO 32..63 = 448..479.
So you'd need to export GPIO 491 to get GPIO 11.

I am using a patch on top of 22.03 to bring back the gpio-base DT property which allows to revert the numbering back to what it was in 19.07. New projects should use the new gpiod interface, but this is not entirely ready yet, see my attempt to find out what the status of GPIOs in OpenWrt is.

@tony-ter-neuzen happy to hear you enjoy the freedom of making your own firmware (as I hoped you will)

i did just realize that i'm building SNAPHOT at the moment, but hopefully i'll find an easy way to step back to current stable without hours of tinkering on menuconfig again

Specifically for that, OpenWrt has a very useful mechanism called diffconfig (of course, it originates, like menuconfig, from the Linux kernel's build system). It allows to capture the changes in your .config (the one and only file make menuconfig touches) relative to the target's default configuration:

./scripts/diffconfig.sh >/my/safe/place/my_diffconfig

Now you can checkout another version of OpenWrt, and then:

cp /my/safe/place/my_diffconfig .config
make defconfig

The make defconfig expands your specific config changes in the context of the default config of the current openwrt into a full .config. The result is a config with all the subtleties that might have changed between OpenWrt versions, with your changes on top. Of course, there might be conflicts, but these are much easier to spot and solve this way.

Inspired by this mechanism (and way of thinking it implies), in my various OpenWrt based Omega2 projects, I nowadays strictly refrain from forking the OpenWrt tree, but keep all changes I need as a "diff" (consisting of diffconfig, but also a set of patches to OpenWrt I might need for one reason or another) separately.

After having done this manually for a while, I built a bash script named p44build that automates most of it. With p44build, lifting a project from an older OpenWrt version to a newer one is usually a minor task - IMHO a very important thing for OpenWrt based firmware to avoid sticking with an outdated OpenWrt too long just because upgrading a fork is a pain. p44build also allows switching between targets and projects on the same tree easily.

I think we should precisely differentiate three areas:

• There are bugs in the Mediatek MT7688, affecting SPI, I2S and I2C, see link in @György-Farkas' post above. If you blame Onion for using this chip, then please name a better one in the same price range having at least partially open specs. The MT7688 is nothing more than a slightly IoT-zed router chip. Its ethernet, USB, UART and WiFi hardware is solid, but its SPI was originally designed to connect the flash chip only, and things like PWM and I2C seem to have been added without much care. Sad, but certainly MediaTek's fault.
• There's not enough open documentation for the MT7688 to write solid drivers without a lot of try and error. As said, at least there is a publicly available datasheet (there was none for the Omega1's AR9331!), but it is little more than a list of register addresses and bits. No conceptual descriptions of any of the function blocks, very little context. So the drivers that exist in the open source LEDE stack have shortcomings just because the hardware is not documented properly. On the other hand, those developers who do have more information, are bound by NDAs so can't contribute to the open drivers, e.g. WiFi. This is the sad state of affairs around a only semi-open SoC chip.
• And then there's Onions strange way to (not) communicate all this properly to their users. It took an eternity until the LEDE build and uboot was opensourced, missing a lot of opportunity to get help from initially enthusiastic community members. And now, inexplicably, they don't respond to carefully collected information and hints like @Maximilian-Gerhardt 's excellent summary, and apparently don't update their firmware. IMHO, only that part is the real issue

Bottom line: there are compromises when building a $6 computer. You can argue Onion should have built another RPi instead for $30, but I am very happy they didn't, because once you know the limitations, the Omgea2 and Omega2S are fantastic devices to build small networked devices.

But Onion should actively communicate the pros and cons, admit problems, provide workarounds and quickly integrate work from others for the MT7688 into their firmware.

For example, this patch making hardware SPI usable by running it in half-duplex mode (full duplex is broken in MT7688 hardware).

As a side note: I am very curious to see how they will handle execution of the clock project - they'll need SPI for the display, probably I2S for sound, probably a ws2812 driver for the light bar. Sometimes developing a real application (vs. just cobbling together examples how to do cool stuff) helps improving the basics

hi @mauriziomeucci, I understand the necessity for efficient factory programming via Ethernet, but I am genuinely curious to learn what you need avahi for in this scenario.

I am factory programming omega2s via ethernet for many years now, but my script is using IPv6 neighbour discovery, which automatically provides the full MAC address of the omegas, as the MAC is part of the IPv6 link local address. Of course that requires IPv6 to be initially enabled, which was the case so far with omega2 in factory state. @Lazar-Demin77 I hope this will remain the case also for future factory firmware…

hi @baby-Onioneer, doesn't look so "baby" any more what you're doing here

Just to make sure: is this a Omega2+ with 128MB RAM? Because you definitely try to boot a "plus" kernel expecting 128MB:

[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]

0x0000000007ffffff = 128MB

The point in the startup sequence where it crashes is where a reference log of one of my omegas initializes (allocates?) some IP stack related tables, and if it tries to do that in the upper half of the supposedly installed RAM -> boom.

I guess you should look at mtd rather than dd. mtd is the tool sysupgrade uses to write the firmware partition.

At the uboot level, only 4 partitions exist, uboot, uboot_env, factory and firmware, the last one covering the entire remaining space of the flash.

firmware contains the uimage, which consists of a header, the kernel, and the compressed (squashfs) rootfs. It's is the mtd kernel driver which only later creates the kernel, rootfs and rootfs_data partitions on the fly, and also makes kernel and rootfs read-only (because these don't even align with erase blocks, you can see this in the output of dmesg)

I guess you'll be able to write something arbitrary into firmware using mtd, but I doubt just a 1:1 copy of the uboot partition will do, because as far as I understand, uboot needs to find that uimage header at the beginning of firmware to instruct uboot what to do with the contents (decompress, load into ram, call,...). So you probably need to prefix your second copy of uboot with a suitable uimage header such that it gets properly loaded and started.

Anyway, for such experiments, personally I'd try to do this from the uboot console, not from within linux, because the latter will work only one time (and then you'd need to recover via uboot http server or similar anyway).

[Update] If you have the openwrt sdk installed, you'll also have the mkimage tool in ./staging_dir/host/bin/mkimage which can generate uimage headers.

You might want to look at the preinit mechanism. This is similar to the /etc/init.d scripts, but runs much earlier.

The preinit scripts are in /lib/preinit/ and, according to my dmesg outputs (search for "init: - preinit -" line), start running around 3.5 seconds into the boot process.

However, when these start running, you have almost nothing ready yet. In particular, loading of additional kernel modules, such as the i2c driver, seems to happen only after preinit is done. Most of the preinit runtime seems to be mounting the jffs2 overlay, taking around 20 seconds. Only then, procd starts running, and kernel module autoload starts.

The main challenge might be: before the jffs overlay is up, you only have the files that are baked into the firmware image. So whatever custom things you want to do early, need to be part of a custom-built OpenWrt image and can't be just installed later on top.

@Lazar-Demin said in ️ Beta Firmware Update: NodeJS v16.19, OpenWRT 22.03.3, and more! ️:

[...] we'll be look at your patches to see how they line up with what we've currently got in our backlog [...]

The "Possibility of using One Wire again" item in the backlog hints to a general problem. Not only w1-gpio-custom was removed, but all other of those *-gpio-custom drivers (spi, i2c and maybe others).

It does not seem re-establishing (and later maintaining) those would be a simple task.

That's why I took the route towards runtime loadable device tree overlays (patches 251..253). While these are not mainline linux, these patches are in use in RaspberryPi for a long time, offering the same as, and much more than, the *-gpio-custom drivers did: configuring standard hardware drivers at runtime, in general.

The overlay directory in the RaspberryPi kernel tree on github gives a lot of examples - there's also one for the w1-gpio driver we could glean from

I did not try W1 yet, but I did try software SPI. This works on device running a build with patches 251..253 and dtc installed (the latter is a menuconfig option):

# create overlay definition
cd /tmp
cat >sw-spi.dts <<ENDOVERLAY
/dts-v1/;
/plugin/;
/ {
  fragment@0 {
    target-path = "/";
    __overlay__ {
      sw-spi {
        compatible = "spi-gpio";
        #address-cells = <0x1>;
        #size-cells = <0x0>;
        sck-gpios = <&gpio 11 0>;
        mosi-gpios = <&gpio 5 0>;
        miso-gpios = <&gpio 4 0>;
        cs-gpios = <&gpio 23 0>;
        num-chipselects = <1>;

        spi-max-frequency = <100000>;
        spi-cs-high;

        /* clients */
        spidev@0 {
          compatible = "linux,spidev";
          reg = <0>;
          spi-max-frequency = <10000000>;
        };

      };

    };
  };
};
ENDOVERLAY

# compile overlay definition
dtc -b 0 -@ -O dtb sw-spi.dts -o sw-spi.dtbo

# apply overlay definition
mkdir /sys/kernel/config/device-tree/overlays/swspi
cat sw-spi.dtbo >/sys/kernel/config/device-tree/overlays/swspi/dtbo

# have a look at kernel messages for errors
dmesg

# check overlay status (should return "applied")
cat /sys/kernel/config/device-tree/overlays/swspi/status

The patchset also includes a startup script that will automatically load compiled device tree overlays placed in /lib/firmware/device-tree/overlays/*.dto at startup.

So future hardware configuration for the Omega2 might become as simple as choosing an overlay file from a library, and copying it to /lib/firmware/device-tree/overlays/...

@Lazar-Demin Hi Lazar, I'm exited to see OpenWrt-buildsystem-wrapper essentially replicating p44build - available for years on github and mentioned several times online and offline, when discussing openwrt level patches, e.g here!

I guess the need for this approach was more urgent for me, having not one, but several different targets on top of openwrt, where maintaining a fork for each of them was simply a nightmare

So I'm very happy to see OnionOS is becoming a set of patches, config and custom packages on top of the original OpenWrt tree, too!

It seems to me from the first quick look, that while the workflows your build.sh and my p44b support are a bit different, the assets (patches, configs) they work with are probably 100% compatible, so using the Onion patchset under p44b and my patches under build.sh should work

So, to contribute more than words, I just created a new p44b-onion "umbrella" package in the plan44 feed aimed at becoming a way to build the Onion Firmware with p44b. It does not work for that, yet, but it contains hopefully useful patches which I created over the years for my Omega2 + OpenWrt projects and should be easily portable/usable in OpenWrt-buildsystem-wrapper:

• hardware PWM (204)
• I2S sound (210)
• runtime loadable device tree overlays (251..253)
• Modern GPIO via cdev support (252)
• re-introducing mt7621 GPIO "base" of-property to keep SoC pin based GPIO numbering (257, 281)

I am really excited about this, because I see great potential for the Onion community to share openwrt level work more easily than in the past, where the hurdle of diverging trees made it hard to "just try" the latest changes of someone else.

@huntc said in Secured uboot image:

@luz Is this the case if there is no additional external flash i.e. just the flash integrated with the Omega device itself?

Yes. The pins needed to access the internal flash are exposed (the SPI pins of the Omega), as is the VDD of the flash chip, so it can be accessed easily. Which is, for non-backbox applications, mostly an advantage. It allows for efficient factory flashing and debricking even of the bootloader.

I'd be genuinely interested in understanding the background of wanting to prevent reading out firmware in the first place.

Does it contain real secrets such as key material? Hopefully not. Or is it just not disclosing some algorithms? For both I cannot imagine an attacker for whom that kind of low level information is valuable/useful but who would not be capable of surmounting any protection short of a completely secured (iPhone-style) platform...

@Jim-W Not exactly the same pins as those on the devboard, but I got really well working ones called FlexyPins from solder.party from their lectronz store.

I needed them for a small programmer board for flashing O2S via Ethernet.

@nsmith said in Secured uboot image:

So there is no way to prevent the code (either the one in the flash, or the one running in memory) from getting read out and recreated?

No.

I completely agree with @crispyoz that all security is relative!

But I‘d like to point out that reading out the flash in a SoC designed like the MT7688 (as a cost effective network router chip) is particularily easy. It does not even require unsoldering or opening the Omega. You might need to cut a single track on the PCB and contact a few SPI pins, then you can access the flash contents with anything that can speak SPI, like another Omega or Raspberry or CH431A ultra-cheap SPI programmer…

@crispyoz ok, but who else but a at least moderately technically skilled snoop would want to get at a embedded device's firmware binary in the first place? Just wondering - without knowing what @huntc's threat model actually is and what type of secrets are to be proteced, it's hard to guess...