With v0.3.4 (and earlier) images, I sent a reset pulse on CPU_RST line (pin 27 from J2 header) and the device was reset. However, after installing the latest image (onion_omega2p-23.05.3-20250709.bin), the behavior has changed. After sending the same reset pulse (500 ms width), the device gets bricked and becomes unresponsive. The only way to recover it is through a power-cycle.

I wonder if anybody else has observed the same issue and if there is any workaround for it.

Thanks!
Matias

I understand that factory reset via the reset button interacts with 'SW_RST' line (aka GPIO38 - pin 4) from Onion Omega. The issue I described is observed when generating a reset pulse on 'HW_RST_N' line (pin 5).

The SW reset works fine, both as a 'normal' reboot or a factory reset. I repeted the test after performing a factory reset and the unit got bricked too when the reset pulse was generated on HW_RST_N line.

Best regards,
Matias

After issuing the reset pulse, the device becomes 'unresponsive', meaning that it can't be accessed via SSH, it does not respond to ping commands, and if I'm connected over serial, I don't even see the echo to the input characters.

If I power-cycle the device, meaning I power it off and on, it boots normally. It is NOT necessary to run through any recovery process (e.g. u-boot, web recovery, etc).

Thank you for your assistance.

Best regards,
Matias

Have a look at the docs related to special pins here it explains requirements for HW_RST_N

Thanks for pointing out to that document. I went through it, and I have some questions and/or comments:

1. First of all, I'm using an Omega2Pro board. I understand that circuitry build around Q2 and Q1 FETs is intended to comply with this requirement for HW_RST_N since it removes power from the SPI flash memory when the reset pulse is issued.
2. Regarding the GPIO6 & GPIO11 HW_RST_N requirements, there is no external circuitry in the Omega2Pro board to comply with it. However, as mentioned in the bullet above, with old firmware versions, the SoC can be reset through the HW reset line.
3. Is it possible for you to program an Omega2Pro with the firmware based on OpenWrt v23.05.3 (e.g. onion_omega2p-23.05.3-20250709.bin) and confirm you are getting the same device behavior?

UPDATE: I think that this information might also be important for this issue. When forcing a kernel panic (with command echo c >> /proc/sysrq-trigger), the device behavior is the same than the one observed with the HW_RST_N line: it works on old firmware, but not with the new one.

Best regards,
Matias

Best regards,
Matias

Due to compliance with cybersecurity standards, we are required to update the OpenWrt version in our Zigbee gateways equipped with Onion devices. This makes the matter critical for us, and we would highly appreciate any feedback or guidance you can provide.

In the absence of updates and/or a solution, we may need to reassess our roadmap and start evaluating alternative SoM solutions for future developments.

Best regards,
Matias

Since this is an opensource product they have no requirement to support the product, but I think it would be nice if @Zheng-Han provided some sort of statement to users especially in light of the statement that Omega2 is going to be available until 2028

Perhaps another member can test, @luz may be able to assist.

Given your active presence in the forum, I had assumed you were part of Onion. I sincerely appreciate the clarity and proactivity you bring to each of your contributions.

The dissolution of Onion comes as a surprise to me, as one of the key factors in validating our design with the Omega was the assurance of production until 2028. May I ask if you know what will happen with ongoing production, or if another company has acquired the IP and continues to support the design?

Thank you once again for your valuable support and contributions.

Availability may just mean that if someone orders 500 units then they'll do a production run, I have no idea.

As my current work is on hold it's pushed my own planning out by about a year, so this is a concern for me. I think the uncertainty could be a killer.

I'll email Zheng directly and see what response I receive.

Best regards,
Matias

Right now, we’re fully focused on developing the next generation of Omega, which we expect to launch in mid-2026. The new Omega is designed to be sold alongside Omega2, not as a replacement. We have no near-term plans to end-of-life Omega2 and will likely extend its guaranteed availability as we approach 2028.

I’ll be sharing more updates about the new Omega early next year.

Anyway, I hope your reset issue could be sorted out in the meantime.

If I remember the difference between v23.5 and older versions correctly, the broken-flash-reset in the device tree has become a standard feature of the mtd/spi-nor subsystem, while before the workaround was a specific patch with no DT option, and implemented differenty.

In the new driver (if I am reading drivers/mtd/spi-nor/core.c correctly), the chip is kept in 4-byte mode most of the time, and only reverted to 3-byte when the device is removed or a shutdown occurs.

echo c >> /proc/sysrq-trigger crashes the kernel immediately, so the spi-nor driver will not get a chance to switch back to 3-byte and the reboot will fail.

The old workaround probably switched forth and back between 4-byte and 3-byte for every flash access, so a HW reset or kernel crash while no flash access was actually ongoing was fine.