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.
-
Very late to the game here, but this is a perfectly fine platform for baremetal or make your own OS programming. IMO there is no reason to replace u-boot, just use it as a launching pad for your programs just like one would to launch Linux or freebsd or other. You certainly dont want to get into the ddr init and other things, for this or any platform.
Been beating my head on this platform for a number of days now mostly turns out because I am an ARM person and not so much MIPS, so ran into some elementary MIPS things I needed to learn (address space). Dont know why ARM beat MIPS to world domination, but true there are very few MIPS choices out there which is why I was happy to see this one come along.
Easier to place your program on the flash than other u-boot based platforms, not quite as simple as the raspberry pi, at the same time the pi3 is quad core, so depending on where you attack it you have to "sort the cores" and deal with other stuff...On par with the pi-zero as far as ease of use (for baremetal programming).
I have some examples to get you started if still interested...
In short I recommend building for 0xA0000000 then take your binary and create an omega2.bin from it using mkimage
mkimage -A mips -O linux -T standalone -C none -a 0xA0000000 -e 0xA0000000 -n "myprogram" -d myprog.bin omega2.bin
You need the expansion board with the usb interface. Put omega2.bin on a (FAT32) thumb drive, plug that in the board, hold the reset button down, flip the switch off and on, on the serial/uart terminal press 2 to flash firmware from USB storage. It then automates the process of burning omega2.bin into the flash and resetting into it. Now when you power on without reset pressed it runs your firmware.
My preference is to have a Motorola S-record based bootloader (since they removed these nice features from u-boot, press a key to stop loads to srecord load) in nand flash, and my programs under test are downloaded into that and launched from there. You can pretty much make whatever bootloader you want of course, or do the usb dance for every experiment if that is your preference.
Like the pi and allwinner chips and others the documentation here isnt the best, but not the worst either. The docs.onion.io is very good actually but mostly geared toward users not (baremetal/roll-your-own) developers. They claim it is a 24KEc, but the productid of the core shows 24KE (0x96 not 0x93) but cant yet find a MIPS document to prove that, and building for 24KEc with gcc makes software that crashes (eventually once your project tickles the right instructions being generated). But this is all part of the fun of baremetal programming.
My two cents at the moment is go with the omega2 and the pi-zero for your project. Have yet to find a baremetal community that remotely comes close to that of the raspberry pi, would like to see one for this platform.
Sorry so long and sorry so late to the game didnt know about this platform unitl sparkfun picked it up...
