Yes .. I've already googled it.
All that comes up are instructions on how to do it on Unbuntu. It seems that the process might be entirely different (or impossible) on OpenWRT .. as the file(s) I'm supposed to modify don't exist anywhere on the system. That's why I'm here.
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.
You could probably use the Omega GPIO's through open collector transistors or mosfets to drive the LEDS, then you won't have to worry about the 5V supply as it is isolated from the Omega's 3.3V. Read up on which GPIO pins to use though as some have special functions and you need to disable them using the omega2-ctrl gpiomux command
@Caleb-Wiggins well, hologram does offer their own usb cellular device which is similar to the unit that they sold through onion kickstarter. but, i can't speak to if the device works well with the omega2[+]
That's where the boot up sequence terminated. After a little while the O2+ LED turned off. I thought I'd bricked it.
You've perhaps run into the fact that the Linkit and Omega2 use different serial ports and baud rates for their consoles. Your boot log stopped right at the point where Linux switches from the inherited serial configuration to its own.
An odd thing about the Linkit kernel is that it decides which serial port to use based on which on-chip hardware it finds configured (and does this in a way that gets easily confused if you enabled more than one in uboot).
Best guess: it's still on the port you are connected to but now at 57600 baud.
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....
If there's no hardware handshaking, have you considered software handshaking? Instead of firing a (e.g.) 20kByte buffer at your device at any given time, first write a small "write request" (which includes the length) on the UART, wait for a "write acknowledgement" from the device, then write the buffer. You could even do it chunk-wise with known chunk sizes and acknowledge each chunk (and resend if something was lost). Preferrably, the transfer on the receiver side from the UART peripheral into RAM should happen via an interrupt / ISR or be DMA accellerated. I think this would actually eliminate most of the problems you're seeing right now. How does it currently work? Does some application thread read the data from UART into RAM?
Looks like your connection to Onion Community was lost, please wait while we try to reconnect.