Thanks @Zheng-Han that gives us clarity. Excited about the Omega3 !

thanks i have upgraded version to b256 version . now i can able to do use sd card as bootable root@Omega-BEA9:~# df -h Filesystem Size Used Available Use% Mounted on /dev/root 7.8M 7.8M 0 100% /rom tmpfs 60.9M 96.0K 60.8M 0% /tmp /dev/mmcblk0p1 14.5G 40.3M 13.7G 0% /overlay overlayfs:/overlay 14.5G 40.3M 13.7G 0% / tmpfs 512.0K 0 512.0K 0% /dev /dev/mmcblk0p1 14.5G 40.3M 13.7G 0% /mnt/mmcblk0p1 /dev/mtdblock6 22.1M 708.0K 21.4M 3% /mnt/mtdblock6 /dev/mtdblock7 512.0K 196.0K 316.0K 38% /mnt/mtdblock7

@UFD alright, thank you

It's likely you are facing one or possibly the combination of two known issues. One is that because an incompatible 32 megabyte SPI flash was used, accessing the whole of it requires putting it in a mode incompatible with boot, so unless something resets the flash chip when the CPU does, a warm boot will fail. Most other vendors avoided this by operating their 32-megabyte flash in 4-byte address mode all the time (but that would have required different strapping for the 16 meg and 32 meg versions). Another is that if you have anything connected, say a debug serial port, the data lines itself will keep the MT7688 alive enough that it won't do a clean power on reset . Potentially in this case you have a similar leakage path where an I/O is keeping your flash chip alive enough during the power interruption that it isn't losing the boot-incompatible 4-byte address mode state. Or you could have residual charge on a capacitor.

https://community.onion.io/topic/1524/would-someone-clarify-the-exact-function-of-these-omega2-pins/

Different USB drive maybe? Loose contact?

You wrote: Omega2+, probably 0.1.10 b160 ... [ 28.551976] device eth0.1 entered promiscuous mode [ 28.556855] device eth0 entered promiscuous mode [ 28.588837] br-wlan: port 1(eth0.1) entered forwarding state [ 28.594681] br-wlan: port 1(eth0.1) entered forwarding state [ 30.588807] br-wlan: port 1(eth0.1) entered forwarding state [ 32.028929] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 8701d944 [ 32.028929] [ 32.042988] Rebooting in 3 seconds.. I wrote in Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ... and a possible reason on 2017-02-05: Omega2+, 0.1.9 b150 (from 0.1.5 b130 to 0.1.9 b150 several FirmWares), without dock / with Arduino Dock 2 ... [ 20.900878] device eth0.1 entered promiscuous mode [ 20.905758] device eth0 entered promiscuous mode [ 20.940478] br-wlan: port 1(eth0.1) entered forwarding state [ 20.946310] br-wlan: port 1(eth0.1) entered forwarding state [ 22.939289] br-wlan: port 1(eth0.1) entered forwarding state [ 24.809528] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 8701d944 [ 24.809528] [ 24.823293] Rebooting in 3 seconds.. This Kernel panic is a known bug of the closed source MediaTek WiFi driver. Now we know it can not manage if there is a WiFi AP in the neighborhood with some Unicode character in its SSID. Onion @administrators deeply kept silent about this bug. It seems Onion's new WARP CORE driver (also closed source ???) can manage this situation. Unfortunately Onion @administrators do not say too much about this bug feature (as usual ;-). Since you did not mount the microSD card it is absolutely invisible for the bootloader (Das U-Boot). @Denys-Makogon said in [SOLVED] Kernel corrupted after factory reset: @György-Farkas kernel was corrupted for sure, that's something I can tell you with honesty. The device was literally dead, only after inserting a microSD card with a new firmware my device was able to update itself and become functional. Well... no one but you should know if this correct (or not

@Chris-Stratton oh thanks, i'm newbie in that. i will try

@ibrahim-price Please read your another post

Thank you @Zheng-Han - a little out of my depth with that for now I think I must rather focus on my original issue with the i2c driver freezing up randomly when fetching data from the arduino. I need to find a way to restart the driver without having to resort to a reboot and losing data.

@Kris-Kelvin https://wiki.openwrt.org/doc/howto/hardware.button#procdbuttons

@György-Farkas Thank you, but clearing the cache doesn't help. PuTTY's SSH solving the problem

I tested with other omega2 and works fine, the omega2 is broken

@György-Farkas That's the thing, I tried various images, every one of which gave the same error log. The omega-v0.1.5-b128.bin was the last one I tried prior to posting here. I already tried the omega2p-v0.1.10-b160.bin image (and checked the hash to make sure), with the same result. I will try again when I'm free though. Edit: still the same result after trying again but with different "magic number": ## Booting image at bc050000 ... Bad Magic Number,032DA956

Sorry. I did not see this: Restoring after a factory reset. Solved

@Douglas-Kryder Thank you, Sir