U-Boot would be an example of a fully open source "bare-metal" program running on the MT7688.

Keep in mind though that you probably won't get the wifi radio working, without inordinate difficulty.

Also, if you do any more than learn about the chip by reading the U-Boot sources, you should consider if that means your work will be derivative enough to need to be under GPL; however, such should not be incompatible with an academic research project.

But take a step back, there are plenty of MIPS processors of various capability out there, many potentially a lot easier to get your code into and with more public documentation. If you need a system with a lot of DDR memory, then an MT7688 might be an economical choice - but even there, you probably want one without a shield can, modified to socket the SPI flash or at least let you get a programmer on all the pins while the processor is held in reset.

And you probably want JTAG working well. I was able to use it crudely to rescue some systems earlier this year, but there were incompletely understood parts that had an imperfect success rate and were "try until it works" - for kernel development, you'll want something where you can really reliably debug.

Given you don't have an application goal, the difference of a few dollars in module cost isn't what matters - pick instead something with the best documentation and the best understood debug interface.

That won't be the MT7688.

Realistically, your most efficient path will probably be to do all your theoretical work on a simulated machine, where you are completely free to stop it, examine anything, snapshot or restore a core/state file, etc. The only thing you really need hardware for is developing the low level drivers for hardware.

@anglo-marc said in Programming in C/C++?:

hope some serious support from official onion .

There have already been a lot of threads here explaining how to build C programs, both via building a LEDE cross toolchain as part of a "close enough" LEDE build, or by a ready-to-go docker virtual machine image that has been offered. For someone in a position to really do native development, these work fine, and are the standard approach for an Embedded Linux system of this category.

It might be important to recognize that C development isn't really a primary goal of the product, compared to scripting languages and web widgets. Rather than chasing every varied user request (and especially those such as this that are already well covered by the community), the onion team's time would be far better spent catching up on their overdue obligations for corresponding source releases - the thing that only they can do.

In comparison to something that some might call a success, like the Raspberry Pi, the key takeway has to be that the system vendor there is only providing the Hardware and the directly required GPL sources - most of the resources people think of in the pi ecosystem, including Raspbian itself, do not come from the hardware vendor. It's a rich ecosystem precisely because they have enabled their community, and not restricted it to the glacial pace of doing everything themselves.

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.

@Ghent - Mediatek's driver situation isn't exemplary, but at least for the linkit, if you follow their directions (and revert a few small things upstream repos subsequently broke), and type "make" you get a build with working WiFi, exactly the same as the build that ships on it, or optionally including your own customizations and bugfixes.

If Onion would do that, people might not be pleased, but would be far more understanding, as then they'd be able to fix the problems in all the other areas of the system and still end up with a useful build - that's a huge practical difference.

And yes, if the boot hang caused by the fatal flash chip selection mistake in the Omega 2+ got repeated in the 2S+ or fixed is indeed a very interesting question. This was unfixable in software - the only solution would be to a pick a more suitable flash chip.

Omega 2+ Flash is an MX25L25645GM2I-10G, which incidentally is a fatally erroneous choice for an MT7688 system, as due to its stateful addressing mode with power-on default of 3-byte mode cannot be operated to utilize its full capacity in a way that will allow the system to reliably restart after unexpected resets. Macronix's alternative MX25L25735F with permanent 4-byte addressing, or another vendor's chip with stateless addressing or configurable power-on default would have been a suitable choice. Note the U-Boot is typically imprecise in software differentiation of Macronix parts in terms of the messages printed.

DDR is an NT5TU64M16HG

The plain Omega2 will of course use different flash and RAM, and would not appear to have the same reset issue with flash selection.

-n tells it not to try to backup and restore your customizations

I'm not sure if the current system configuration supports doing that cleanly; if there's any question, doing a factory reset now or otherwise wiping the overlay would have the same effect at this point as having used the -n option in the upgrade.

It is indeed true that they are complicated systems which require care to apply well. If that is done, they do present a lot of possibilities.

But threads are making it clear that these are indeed not simply drop-in Arduino replacements, and are not ready for all the of the uses they've been imagined for, without additional engineering that is yet to be done by the user, supplier, or both.

It's really easy to understand the frustration from an end-user perspective; many engineers wear that hat too. However from an industry perspective, everything has issues - Arduinos are absurdly memory limited and in usual form have only a single UART, Pi's are weakend by the SD card dependency, irreproducibility and concealed internal details, while embedded WiFi stacks for micro-controllers take forever to wrestle to stability and require major rework for trivial changes, etc. Apart from the serious issue of missing source code, the main issue here is perhaps not so much the under-delivery, but the overly optimistic expectations that have been encouraged. Embedded is hard - one can admit that upfront, or discover it later.

My purpose for "bit bashing PWM" is confidential (sorry!) but suffice-it-to-say, it is non-linear, non-conventional, non-constant, and "human safety critical" - battling other peoples code and hardware to try and get my application to work with existing tools will be too much work and too high safety risk

This is precisely why you need a simple MCU for which you can obtain full engineering information, and not an MT7688 designed to run a complex operating system and for which you will never get the same level of detail out of the manufacturer.

Did you overlook that there's a second CPU in the package over which you have next to no control?

All of your requirements point away from trying to use this device for your purpose.

Additionally, you've presented absolutely no arguments for why it would even be desirable to try to use it for your purpose; it's unlikely that any convincing ones that could survive the most cursory scrutiny exist, but you haven't even tried.

Indeed, this is a bad idea.

A complex Linux system with many undocumented corners and unresolved bugs is the last thing you'd want for a flight computer. In the case of the Omega 2+ even simply compared to other boards with the MT7688 chip, there's also the issue that an error in the choice of the companion flash chip on the module means that if the MT7688 experiences an unprepared reboot (for example from a glitch, or a watchdog) without the flash chip power cycling, a disagreement of addressing mode means that it will hang and be unable to boot.

Actual flight controllers are quite simple computers. A few years ago they were typically 8-bit ATmegas or STM8's, though fortunately that era is now in the past. Today they are typically simple ARM Cortex M0, M1, or M3 parts, from the likes of STM, Gigadevices, Nuvoton, or Asia-only vendors relatively unknown in the west. These run with internal flash and ram and have the rich I/O that @ccs-hello mentioned. For these purposes they run simple main-loop style bare metal firmware, drastically simpler and more responsive than what you would get from a multithreaded architecture. If you're interested in experimenting with this the realm of tiny featherweight platforms, there are a number of published open source replacement firmwares for toys like the H8mini, CX10, etc - ironically, the smaller (and therefore twitchier) the aircraft, the faster the control system needs to be.

If you do choose to fly a system like the Omega 2+, it should be limited to optional features, for example, you might use it to log data that you'd like to have, but the loss of which would not cause the aircraft to crash.

@Theodore-Borromeo That is actually untrue. Swapping is per-page, and a program of any size to be an issue is going to have multiple code pages as well as data pages. If execution reaches a page that is not currently in memory, a page fault occurs and execution pauses while it is loaded, the same as would happen if access were attempted to a data page that was not resident in memory.

This is important, because a large program will have portions which are rarely needed. Going a step further, it varies by implementation, but ideally the program won't even all necessarily be loaded from disk into RAM at the start, but rather portions may only be loaded as needed, even though to the process itself, it will look as if it is all there - it's just those parts won't actually be there until an attempt is made to access them.

However swapping, especially writeable memory data to an SD scard (or even worse, the build-in SPI flash) is a poor solution. Likely the task is either being done with unnecessary inefficiency, or the wrong platform has been selected, or both.

Typically what is most useful in a situation like this is actually to run gdbserver on the embedded board, and run GDB itself (either bare or with a GUI driver) on your development machine where it can get at your sources.

But if you're actually building on the board or just want to run GDB locally, then yes, you can do that too.

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.

If you want something more OS independent you might look at the reported memory, since there seem to be differences (64, 128, or 512) - see /proc/meminfo or similar

@Andrey-Mor said in Omega2 WIFI off issue:

@Chris-Stratton Is "logic level serial" means PC serial?
I don't know but for me hw reset doesn't work (hw reset pin connects to "minus" for about 10 secs)

For most people today "logic level serial" means a little bare-PCB USB adapter or cable ending in discrete wires, like might be used with a pi or Arduino.

What you cannot use is a traditional RS232 level adapter or port, typically terminating in a D-sub connector. If you have that, you'd need an inverting level translator.

@Andrey-Mor

The hardware reset will work if done right.

You could also connect a logic level serial to the module and get a root shell that way

Do you only care if you are connected to WiFi, or do you also care if your packets can go anywhere upstream?

ie, how do you want to handle the case of being connected to a router, when the cable modem upstream of it is down?

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.

First step in debugging would probably be to explore what was ending up in the overlay.

One likely culprit is upgrading large amounts of system software (python, etc) or installing many new packages.

The other is having some ongoing task that creates log files or data objects

There are almost certainly ways to make this work, but they may take some non-trivial engineering.

• Understand and work around the SPI issues. They mostly have to do with simultaneous write/read operations and long transfers, both of which can usually be avoided at the cost of some efficiency
• Proxy the SPI through something else, for example a fixed-function chip (FTDI, etc) or a small MCU, hanging off either the USB or one of the UARTs
• See if you can use the I2S interface instead - this is normally meant to move audio data but it is not dissimilar to SPI. Many chips have offered functional blocks that did both SPI and I2S by configuring different details, which may be well within the range of what you can do with clever software
• Bitbang SPI on arbitrary GPIOs. Probably slow, though you can do the actually twiddling in kernel mode

Indeed, this is a bad idea.

A complex Linux system with many undocumented corners and unresolved bugs is the last thing you'd want for a flight computer. In the case of the Omega 2+ even simply compared to other boards with the MT7688 chip, there's also the issue that an error in the choice of the companion flash chip on the module means that if the MT7688 experiences an unprepared reboot (for example from a glitch, or a watchdog) without the flash chip power cycling, a disagreement of addressing mode means that it will hang and be unable to boot.

Actual flight controllers are quite simple computers. A few years ago they were typically 8-bit ATmegas or STM8's, though fortunately that era is now in the past. Today they are typically simple ARM Cortex M0, M1, or M3 parts, from the likes of STM, Gigadevices, Nuvoton, or Asia-only vendors relatively unknown in the west. These run with internal flash and ram and have the rich I/O that @ccs-hello mentioned. For these purposes they run simple main-loop style bare metal firmware, drastically simpler and more responsive than what you would get from a multithreaded architecture. If you're interested in experimenting with this the realm of tiny featherweight platforms, there are a number of published open source replacement firmwares for toys like the H8mini, CX10, etc - ironically, the smaller (and therefore twitchier) the aircraft, the faster the control system needs to be.

If you do choose to fly a system like the Omega 2+, it should be limited to optional features, for example, you might use it to log data that you'd like to have, but the loss of which would not cause the aircraft to crash.