@crispyoz said in p44-xx-open: a firmware for (home)automation:
BTW I've been using Ledchain 9 on OWRT 24.10rc3 and it's working perfectly.
Thanks to your contribution, that is! 
BTW: I will have a 5min lightning talk at 38c3 Chaos Computer Congress tomorrow about this, I hope this will also draw new people's attention to the Omega2! Also hope I won't be too nervous…
Today, I released firmware images, and everything needed to build these images for Omega2 and other platforms, as p44-xx-open on github
p44-xx-open is more or less the distillate of my work of the past 8 years using Omega2 as my main hardware platform for automation projects.
It is an 100% open source (mostly GPL) alternative firmware, made to use omega2 as a tiny, self-contained platform for (home)automation, with a focus on complex setups with WS28xx addressable LED (also known as neopixels), but far from limited to this. It even has a matter bridge (beta) included.
Self-contained means: there are no dependencies, everything is on board, including an IDE for script development and debugging.
Have a look at the README on github for an overview and more information & links. Enyoj 
!
Hi Onioneers,
I just got a bunch of WS2816 LEDs, which are similar to WS2812/13 but have 16bit PWM values instead of 8bits, so should have higher brightness resolution at low levels.
To test those, I upgraded my entire LED stack to 16bit capability, which includes the p44-ledchain driver for Omega2/MT7688 and the test utility p44ledchaintest.
Spoiler: with the chips I got, the higher precision does not help that much so far, because these start to emit light only at around PWM value 200 (and unevenly so between colors and individual chips), so the actual resolution is only a little better than the 8bits we're used to from WS2812,13,15.
But still, 9 or 10 bit resolution is better than 8, and future chips will most likely improve compared with the initial version (like WS2813 -> WS2813B...)
The WS2816 chips are not yet widely available, but you can get them for example from LCSC where I got mine.
@Lazar-Demin the v9 driver is fully backwards compatible, so could be included in the Omega FW. It also is a bit more efficient in memory usage - it only allocates the internal buffers on demand for the number of LEDs actually used (the previous version allocated according to the number specified at insmod)
I assume you are on the OpenWrt 19.x based version of the firmware?
I just tried on my OpenWrt 22.x, and your example and also 100 years later works fine:
date --set '2150-01-01 20:00:00'
Thu Jan 1 20:00:00 CET 2150
I know that musl (the libc replacement OpenWrt uses) has switched to 64bit time_t sometime between 19.x and 22.x as I had to fix some tools that were not prepared for 64bit time when I switched to 22.x
So if you upgrade to 22.x or later sometime in the next 14 years, you'll be fine 
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:
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...
While I understand the goal, I don't see how securing an MT7688 based system, which has no anchor for the needed chain of trust, could work at all.
For an attacker who has physical access to the device, reflashing or reading out the SPI chip directly is about as hard or easy as getting access to the uboot console. So just removing flash access commands from uboot does not help much, IMHO...
To protect against attackers without physical access, it is sufficient to have an update mechanism which checks signatures, like yours probably already does.
Am I missing something?
When you say "bricking", you mean not destroying it due to some HW mishap, but a software issue that prevents it from booting?
I have a few 1000 Omega2S out in the field and so far only ever had to software-level unbrick one (I actually burnt a few more due to PSU issues in one production charge, and soldering parameter errors in another, but these are different stories).
From that one I learnt that all you need to unbrick from any level of software brick, including ruined u-boot (which IMHO can't be repaired in the devkit) is
Only the first bullet point might be difficult (but usually manageable by cutting some tracks) if your PCB design does not provide for it. Accessing A8..A12 should always be possible; if you have to do it more than once, building an apdapter with 6 pogo-pins helps a lot.
With such a setup, you can write every single byte of the SPI flash chip inside the Omega2S, and with that, reflash any part of it that might be bricked.
That way, you don't need to unsolder the Omega2S completely to unbrick it
PS: if you can pull up GPIO38, have Ethernet and the serial console, and not bricked u-boot, but only openwrt, then unbricking is even simpler via the built-in recovery http server, see docs.
@DumTux the p44b script works from the information in the p44build directory you specify at init. It seems you tried with an older project that was still on 18.06.4. p44b works with 22.03 but I don't have a complete setup yet exactly because of the various detail issues I am still having.
But it's not easy for me as the gpio-mt7621.c seems like changed.
I agree 
, it takes an awful lot of time to dig into such things and get it right.
But by now, gpio-mt7621.c seems to be Linux mainline
Looking at the commit history of that file in Linux mainline, it seems that there were several changes related to IRQ handling in the past 2 years.
Maybe it would make more sense to try to use that latest mainline version and see if the changed IRQ handling now works correctly. Hoping this seems not too unrealistic to me - all the changes mostly seem to be generalisations, i.e. replacing mt7621 specific things by generic mechanisms that work for many other drivers, too.
@Gerhard-Bertelsmann said in CAN Bus: using MCP2515 with Omega2:
I switched to 22.03 but the problem is still present
Ok, interesting! So the rework did not catch that. Maybe I mixed it up in hindsight with the initialisation of GPIO output's initial value (did not work as expected in 19.07, I had to patch that too back then, but definitely this now works in 22.03 as is)
I would be interested in this patch
Note that this is a patch on top of a pristine openwrt v19.07.8 tree, which consists of adding kernel patches, which then are applied in the process of building the kernel. So the patch is kind of a "meta-patch", doing the following:
gpio-mt7621.c to a newer version from upstream. I had forgotten about that - it seems this newer version is quite near to today's 22.03 version.irq_ops with a modified copy to implement the select callback.OMEGA2.dtsi and (lines 718..) adds a new version for mt7628an.dtsi called mt7688newgpio.dtsi because the new driver now addresses the gpios by number, no longer by bank+offset.I package such changes into openwrt tree (meta)patches rather than forking the openwrt tree, because different projects need different patches, and I don't want a multitude of trees or branches, and keep the changes versioned per project in my own feeds, not openwrt.
The p44build script helps with that workflow in case you are interested.
@rdot said in Installing OpenWrt 22.03 on an Omega2S+:
We have a custom setup too and we've been seeing odd failures where we let the device run overnight and at some point it appears to factory reset itself.
This does not sound like something that could happen because of the "broken flash reset" to me.
To get a factory reset, active and quite specific write operations to the flash must happen (wiping the overlay partition). I cannot see how this could possibly be caused by the "broken reset" problem.
The "broken reset" issue is simply that the SPI flash chip must be in 3-byte address mode at the moment the MT7688 SoC resets, otherwise it won't reboot.
To access flash beyond 16MB, the SPI flash must be set to 4-byte mode. On systems without the "broken reset" problem, the SPI flash driver keeps the chip in that mode all the time because it is more efficient. On Omega2 and similar systems, the driver switches back to 3-byte as soon as possible, to minimize the periods of time when a reset would lead to a stuck system. Still, the problem cannot be avoided entirely, if you get a hardware reset exactly in the one of the remaining (short) periods of time when the SPI is in 4-byte mode, you're out of luck.
So if you don't need the ability to hardware-reset the SoC, you also don't need the extra circuitry which removes power from the SPI flash chip during reset (and thus resets it to 3-byte mode).
I'm not sure if it can happen that the MT7688 SoC internally hard-resets (brown-out, watchdog, maybe?) - if it can and does, not even the external circuit could avoid the hang.
But during normal operation, with no hardware reset involved, all this can't be what's causing your problem, IMHO.
@Gerhard-Bertelsmann Yes, the 19.07 version of gpio-mt7621.c interrupt routing implementation is broken for GPIO interrupts assigned via DT.
I made ugly patches to fix that back then, I can dig them out if someone wants to use them, but I can't exactly recommend (it was kind of an emergency hack for an urgent project).
As far as I know, the issue should be fixed in the 22.03 version of gpio-mt7621.c, as the entire driver has been reworked to align with other modern GPIO drivers and handles the banks differently.
But I haven't had the chance to test it so far, and the link to the OpenWrt forum you posted saying it is not yet fixed in 21.02 makes me doubt a bit, because I thought the rework already happened in the 21.02 time frame, but I can't verify or test that right now.