Yes, that's what I would be hoping too.
One of the hurdles to the other IP holders even contemplating open source would be the proprietary MIPS situation and NDA's etc. With that barrier overcome, it should be easier down the line to release code openly. But it would have to make business sense first of course.
The solution I used was to build a custom firmware with USB support compiled in and with the omega dts file modified such as to enable the u-boot and u-boot-env partitions as read/write.
Then with the O2+ in a mini-dock and dumps of the u-boot and u-boot-env from my kickstarter O2+ on a USB, I flashed the O2+ with the modified firmware and just wrote the kickstarter copies to the relevant partitions.
It was a total hack, so I have no idea whether this worked by design or I was just lucky that it worked.
Note, the officially sanctioned way to replace the bootloader is via an ethernet expansion installed in an expansion dock as documented here Firmware Flashing With Web Recovery Mode and I'd recommend anyone try that first before doing what I did.
Further, note this useful clarification regarding the documented procedure by @Pavel-Metrokhin in Bootloader for Omega2S and Omega2S+
Building the Onion software at the time I did this (Feb 2018) was a hit and miss affair, which is why I did it the way I did.
Apologies for the late reply, somehow I managed to miss your question in the past.
The underlying issue here has been covered many times before.
The Omega 2+ has an ill-chosen flash chip, which cannot expose its full capacity unless operated in a 4 byte mode which is incompatible with the configured expectation at boot.
There is no actual working poweroff command, and there never has been one. However, programs that reboot without putting the flash chip back in a boot compatible mode end up hanging in a tight loop at boot, giving the impression of being sort of "off".
Also note that unexpected reboots, such as triggered by a watchdog will also result in a hang, rather than a successful boot.
As the Omega 2 (non +) flash chip fits entirely in 3-byte addressing mode, it should not experience this problem.
Flash chip commands can be found in the relevant data sheets, as well as the U-Boot and Linux Kernel sources.
Yes, I remember skimming through them at the time, but now they're gone.
Anyway, I'd hazard a guess that the journey starts somewhere with learning MIPS programming at least. The closest I got to baremetal programming was x86 assembler on MS-DOS +/- 25 years ago, so I guess I'll try and reacquaint myself with that while I wait for my "See MIPS Run, 2nd edition" to arrive....
@cas said in Omega2+ losing power / powering off unexpectedly:
The pin pad underneath: <photo>
"Thermal pad is connected to GND layer through vias (recommend 4X4 pins and the aperture is 10mil)." /active-semi/
These holes are (thermal conducting) vias between the top and the bottom copper layers of the PCB.
The bottom of the dock was very hot to the touch, so I suspect I burnt out the ACT2801 which appears to have a pin pad underneath. Actually upon closer inspection of the pin pad, one if the holes appears to be blocked with a silver substance and I can't help wondering if that's solder (if that's at all possible).
Spot the mistake.... ;-)
It's a "perfect" solder material "bead" / "ball" - it's OK here - no problem.
I don't have Power Dock - so I'm speculating based on active-semi's ACT2801 data sheet and Onion's schematics only.
VIN Input Voltage nom. +5V (range +4.5 ... 5.5V), Absolute Max. +6.5V
VIN_OVP Over Voltage Protection typ. +6.0v (range +5.5 ... 6.5V)
So 5.4V was OK.
The IC has an Input Current limiter.
ILIM Input Current Limit - Omega's setting is R2=2.4kΩ about 1A - so the input current couldn't have been more than 1A. (It was 1.8A / 1.9A!)
Please try to recall. You might have done something else or something else might have happened.
Or simply this is one of those cases where Murphy's Law happened to be working.
I came across this thread while trying to solve this problem and found the above answer not to work for me. 'ethtool' is not installed by default and is not found in the opkg package manager. I wish to avoid installing packages if avoidable anyway. I hope my solution is useful to someone.
ifconfig | grep 'eth0 ' | cut -d ' ' -f 11
How it works:
On my Omega2, ifconfig returns a set of information about 4 network interfaces, br-wlan, eth0, eth0.1 and lo. I chose to extract the MAC address of 'eth0'. The output of ifconfig is piped into the grep command which extracts only lines containing 'eth0 ' (note the space on the end, it eliminates 'eth0.1'). The output of grep is only one line and it contains the search term, the MAC address we're looking for and other information we do not need. This is piped into 'cut' with arguments to make it to treat space characters as column delimiters and return only the 11th column.
I had hoped to come up with a cross platform solution but this has certain expectations of the output of ifconfig. For instance, it doesn't work on MacOS. If you're hoping to develop on another machine and test on the Omega2, you might want to use some kind of platform detection.
Looks like your connection to Community was lost, please wait while we try to reconnect.