Posts made by luz

Hi @chooks,

Are the original wiring instructions correct (Vcc->ground, GND->3.3V)

the original wiring instructions are definitely wrong. In digital electronics, the ground and Vcc are never swapped. It seems to be a copy/paste accident in that final wiring instruction (ping @Lazar-Demin, I guess that's a typo worth correcting quickly). Everything else above looks correct.

The photo also seems to be correct, hard to really definitely tell but it seems I see the black GND wire go to the blue rail and the red one to the red rail on the breadboard.

Since I powered it in both directions (one of which being wrong by definition) what is the best way to tell if I fried the chip?

Probably the chip is fried (otherwise the setup should work).

Does the Omega start when the breadboard is connected the correct way (Vcc->Vcc, GND->GND)? Only the LEDs not working?

• If not, then the chip is definitely fried (draws too much power and probably gets hot)
• If Omega does startup, it's hard to tell because there are all sorts of semi-fried states the chip can have now - but most likely not working 100% ok any more.

If you have an easy means to get a replacement (~$1), I would continue with a known-good new chip to see if it works then.

PS: if you eye some home automation eventually, you might want to look at this

I guess because the kernel changes are such that this is not very easy to do. I remember looking into it, finding some attempts from others trying without success, and then decided going the DTS overlay route was much more future proof (and enables not just what the few *-custom could do, but any standard driver).

Since then, I use software SPI as described in this post.

But I realize that by now it also comes pre-packaged and documented in the onion docs

@crispyoz ...maybe two heads are better than one.

certainly !

This is what I tried so far:

• on OpenWrt 22.03.5
• copied the existing uboot package from package/boot/uboot-ramips into my own package feed as plan44/uboot-omega2
• modified the package makefile to pull sources from omega2-bootloader instead of u-boot upstream as in the original Makefile. You can find the changed version here on github.
• Tried to make package/uboot-omega2/compile
• Realized that one of the main difference between official upstream way to build uboot and the omega version is that the omega2-bootloader repo is pre-configured, i.e. it contains .config, autoconf.h etc. prebuilt so I must prevent running config.mk, see this change
• Also I needed to disable the pre-built-toolchain in the uboot Makefile, see this change
• The other commits on top of omega2-bootloader were other details I had to fix while trying to compile, some probably caused by my platform (macOS on ARM64).
• At the moment, I also need to run
  export CROSS_COMPILE=mipsel-openwrt-linux-
  before calling make. Of course that should go into the package makefile later.

With this, the build runs through around 20 *.c files successfully and then stops in drivers/ohci-hcd.c with the aforementioned Error: operand 2 must be an immediate expression 'lb $2,$4($2)'problem.

In the meantime I found that this comes from the macros in io.h that are translating I/O port accesses (x86 architecture has separate I/O address space) into single-address space instructions like we have on the MT7688.

Most probably the problem is not in ohci-hcd.c nor in io.h, but in some parameter coming from the build environment, I guess… But I'm currently out of ideas of how to proceed...

I hoped that with OpenWrt natively providing a build environment for u-boot this would be relatively straightforward, but it seems quite the opposite right now

@crispyoz, @Lazar-Demin 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.

This is something that already exists (see package/boot/uboot-ramips) in openwrt for another MT76x8 target, the RAVPower RP-WD009.

So I copied that package to make an uboot-omega2 package and made it use my fork of omega2-bootloader (Once this builds, I'll kill the fork and make the needed changes a patchset in the uboot-omega2 package, but for now it's easier to work this way)

At the moment the build fails very early, because the openwrt u-boot.mk is made for the upstream u-boot sources whereas the omega2 version has forked off from 1.1.3 version from upstream about here and includes some static config that the standard build process is trying to generate.

Any help or pointers how to get that right are welcome, it's a bit of a mess right now

[Update hours later:] looks like a huge pain, nothing works as it should, down to C files giving errors because some 1000 fold-nested macros in io.h expand to invalid assembler instructions

{standard input}:2896: Error: operand 2 must be an immediate expression `lb $2,$4($2)'

somehow originating from assember generated from compilingdrivers/ohci-hcd.c:

#APP
 # 309 "/Volumes/CaseSens/openwrt-2/build_dir/target-mipsel_24kc_musl/uboot-omega2-plan44_p44dsbomega2/uboot-omega2-4.3.0.3/include/asm/io.h" 1
	lb	$2,$4($2)
 # 0 "" 2
$LVL204 = .
	.loc 3 309 1 view $LVU687
	.loc 3 309 1 is_stmt 0 view $LVU688
#NO_APP

@crispyoz I got here thanks to your hint in the GPIO44 question thread because to free GPIO44 from being switched to output I need to build my own bootloader.

Now I see that setup_env.sh as a first step unpacks a precompiled buildroot/toolchain for an x86 linux host. However I don't have such a thing, my platform is 64bit ARM.

But of course I do have a working mips toolchain built for 64bit ARM as part of the openwrt build. What is the reason to not use the openwrt build environment to build uboot and rather use that pre-packaged buildroot instead?

Thanks @crispyoz and @Lazar-Demin for the hints!

I found the lines that makes GPIO44 an output in uboot in lib_mips/board.c:3012:

//gpio44 output gpio_ctrl_1 bit3=1
val=RALINK_REG(RT2880_REG_PIODIR+0x04);
val|=1<<12;
RALINK_REG(RT2880_REG_PIODIR+0x04)=val;

(RT2880_REG_PIODIR+0x04 is MT7688's GPIO_CTRL_1 at 0x10000604)

Interestingly this was in the initial commit in 2016 by @youlian-troyanov, so GPIO44 being used by uboot seems to be something predating Omega2 related changes and is hard-coded for any lib_mips based setups.

As in many cases there will be the WLAN LED connected there, it makes sense also using it for some signalling in early boot stages.

And in fact, this is done in led_on() and led_off(), curiously using literal hex addresses for GPIO_DSET_1/GPIO_DSET_1, see lib_mips/board.c:3047ff:

void led_on( void )
{
	//gpio44 gpio_dclr_1 644 clear bit12
	RALINK_REG(0xb0000644)=1<<12;
}

void led_off( void )
{
	//gpio44 gpio_dset_1 634 set bit12
	RALINK_REG(0xb0000634)=1<<12;
}

I would be much more nice to have:

//gpio44 gpio_dclr_1 644 clear bit12
RALINK_REG(RT2880_REG_PIORESET+0x04)=1<<12;

and

//gpio44 gpio_dset_1 634 set bit12
RALINK_REG(RT2880_REG_PIOSET+0x04)=1<<12;

Another curious thing: Why is the address used in uboot 0xb0000000 based (RALINK_SYSCTL_BASE), while in the datasheet the addresses are 0x10000000 based? Probably because address decoding is 29 bits only, so the I/O block is mirrored at every 0x20000000?

Anyway, as GPIO44 is one of the few pins that allow pullups or pulldowns at startup and do not have another special function, I'll probably patch my uboot to leave it alone for my Omega2S devices.

What I still do not understand is how I could not notice GPIO44 flapping around in all the circuits I've done with the assumption it would not

@Lazar-Demin 5 years later - and I still have a question/problem related to GPIO44

I knew GPIO44 is the system LED in standard firmware, so I changed the DTS for my builds long ago to use the not exposed GPIO35 instead, as I needed GPIO44 for other things, in particular enabling some drivers that must not be active before firmware is fully up. This relies on GPIO44 remaining in reset state (configured as GPIO input), so an external pullup can keep the drivers disabled until my code gets active.

Today, debugging a device, I found that GPIO44 is getting configured as output and set to low actively somehow very early, like ~0.5 seconds after reset.

I use devmem in the earliest point where my code gets active to dump GPIO_CTRL_1, and it returns 0x00001008 which means GPIO44 and GPIO35 are set to output.
GPIO35 is expected because my DTS assigns it as system LED, but GPIO44 is not expected.

Any idea which part of the code would initialize GPIO44 as output before DTS gets active? Is this hard-coded in the omega2 uboot (which I haven't touched, so it is in factory state)?

I am confused by this because I've been using this type of driver enabling circuitry for a long time, and would think I'd have noticed this behaviour of GPIO44 long time ago...

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

• 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…