Are bare-metal and alternative OS programming possible for Omega2?



  • The question is pretty straightforward: is there a way to operate the Omega2/Omega2+ without the OpenWRT boot-up, either as a bare metal system, or loading some other OS?

    Allow me to explain why I am wondering about this.

    I am looking for a few different inexpensive hardware platforms of various types, for some experimental programming work; while most of the work can be done in emulation, I will soon need at least some live hardware to apply it to. While there are many options for ARM, the Omega2 is pretty much one of only three options for MIPS development which I have been able to find (the others being the Creator boards and the LinkIt 7688; I have reason to think that modifying a router would not be helpful, so I am focusing on maker-grade SBCs). I do not intend to work on IoT directly; my interest is solely in finding a platform for my software work. However, some of my goals would, if successful, have IoT applications.

    For various reasons, I would prefer to target MIPS for the first iteration of the project.

    My goal is to develop an experimental operating system, an assembly-language kernel called Alexia, after Alexia Massalin; the purpose of this first kernel, which is a separate project from the later design, is to test whether her Synthesis kernel model is viable with modern systems.

    This would be in support for a successor project, to develop a model for applying her runtime code synthesis methods to higher-level languages.

    One of the long-term goals for the later project is to developing a system by which partially compiled syntax trees could be used as a portable representation, as an alternative to bytecode representations such as JVM or .Net CLR; the program sections would be JIT compiled when the module is to be used on the specific system, in a way that tailors it to the specific hardware for maximum efficiency. Once compiled, the executable image would be cached for fast reuse.

    While I am not currently in a graduate program, the intent is to use these projects for when I pursue a masters (and eventually, doctoral) degree. When completed, the source code would be released, but since the goal is a purely experimental system, I would not want to develop it further, and would be inclined to dissuade others from doing so, recommending instead that they apply any valid results to improving established systems such as Linux (where possible - I don't actually see the intended approaches fitting in with any of the existing OS designs, TBH).

    As you can see, the Omega2 is not quite an ideal platform for me, but TBH, it is the best one I have found. Assuming, that is, that I can boot it into my custom OS.

    Does anyone know if this is possible, or have any other suggestions for me to explore?



  • 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.



  • OK, the point about GPL is a very good one; I wasn't planning on using GPL per se, but I did mean to use a similarly permissive license such as CC0 that would be compatible with it (I am pretty sure CC0 is, but I would need to check).

    As for emulation, yes, that was my intention; I was looking ahead to when I would need to compare the results of the emulated version with a live hardware system (experience with tools for x86 emulation such as Bochs and QEMU shows that emulation often doesn't perfectly replicate the hardware, and conversely, the hardware often doesn't match either the standards or its own documentation). Still, that's some ways off, so I can certainly hold off there.

    The point about using a better documented MIPS based system is an excellent one, especially given what you said about Onion's documentation. I should do more research into this before deciding on hardware; as already said, while I would like to get at it soon, it isn't pressing.

    Thank you, you have answered my question and then some.



  • With regard to CC0 vs GPL, it may (not sure) be possible that you can incorporate CC0 code into a GPL project and license the result as GPL. However is it definitely prohibited to use GPL code literally or via derivation in something licensed CC0. That is because a CC0 offering of a combined result would not preserve the irrevocable obligation to make a GPL license grant for derivative works of your derivative, hence such use cannot be permitted.

    With regard to documentation, since you are aiming for bare metal, the culprit for your specific difficulty is more Mediatek than Onion. I'm not sure if the Onion boards are perfectly documented, but that would be easy to reverse engineer, and besides, they'd be a bad choice of MT7688 platform, since you have access to neither the flash chip nor the JTAG pins without a very tricky operation of removing the shield can.



Looks like your connection to Onion Community was lost, please wait while we try to reconnect.