Hardware Reset issue on v23.05.3
-
Hi all, I'm experiencing an issue with Hardware Reset on my Onion Omega2 Pro after updating to OpenWrt v23.05.3 based image.
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
-
@matiaslao Is you use the factory reset process do you experience the same issue?
-
Hi @crispyoz! Thanks for taking care.
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
-
@matiaslao Before I try this myself can you clarify "bricked" please, can you still boot into u-boot and reflash the firmware or is the device unusable? Perhaps post the boot up log screen.
-
@crispyoz my bad, I should have been more specific.
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.
-
Hi @crispyoz, just wanted to check if you get my last response and also if you have any further questions.
This issue is becoming critical in my development.Best regards,
Matias
-
@matiaslao Apologies, I currently am recovering from 2 broken wrists so I'm a bit slow. My guess is that you're getting bitten by an addressing mismatch so the flash is in 4 byte mode when the cpu is booting in 3 byte mode.
Have a look at the docs related to special pins here it explains requirements for HW_RST_N
-
@crispyoz I’m so sorry to hear about your accident, and I wish you a smooth and full recovery.
Thanks for pointing out to that document. I went through it, and I have some questions and/or comments:
- 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.
- 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.
- 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