OpenWRT on the Omega 2(+)
-
Has anyone tried it yet? My understanding is that you should be able to flash a sysupgrade image for mt7688, but I don't have the ethernet expansion required to unbrick the Omega so I don't want to risk it right now.
It would be neat to get this working, though.
-
OnionOS for Omega2 is allegedly based on LEDE which is a fork of OpenWRT. This fork has been created for development philosophy differences, and it appears that LEDE will have a stronger development roadmap and stronger community. Personally, I wouldn't shed a sweat on OpenWRT.
-
@fossette said in OpenWRT on the Omega 2(+):
OnionOS for Omega2 is allegedly based on LEDE which is a fork of OpenWRT. This fork has been created for development philosophy differences, and it appears that LEDE will have a stronger development roadmap and stronger community. Personally, I wouldn't shed a sweat on OpenWRT.
LEDE would be fine too, but I'd like to have an environment set up to create custom builds.
-
@Fred-Rauch As @fossette said, the Omega2 FW is built on LEDE. At this time, it seems the LEDE board profile for the Omega2 is not published yet. I'm regularily checking the LEDE github repo and in particular the pull requests for it, hoping Omega2 support will soon land there.
But yes, I got it (partially) working already
The LinkItSmart7688 is a very close relative to the Omega2 (same chip, MT7688), so I just used the LinkIt profile.
An important difference is that the LinkitSmart uses ttyS2 as console, while Omega2 uses ttyS0. So I had to change the tty in the "bootargs" line in the "LINKIT7688.dts" device tree file, and remove the serial0-to-uart2 alias definition.
With that, I could build an image the Omega2 bootos up ok with, and gets accessible via the Ethernet expansion! WiFi access point also worked, but I didn't get it to connect to my WiFi as a client (didn't try hard, though).
For sure there are a lot of other details which are not exactly right in the LinkIt image for the Omega (e.g. LEDs, reset button). So this is for early experiments, but not for real use yet. We need to wait for the official platform support from Onion to appear in LEDE.
-
@luz said in OpenWRT on the Omega 2(+):
@Fred-Rauch As @fossette said, the Omega2 FW is built on LEDE. At this time, it seems the LEDE board profile for the Omega2 is not published yet. I'm regularily checking the LEDE github repo and in particular the pull requests for it, hoping Omega2 support will soon land there.
But yes, I got it (partially) working already
The LinkItSmart7688 is a very close relative to the Omega2 (same chip, MT7688), so I just used the LinkIt profile.
An important difference is that the LinkitSmart uses ttyS2 as console, while Omega2 uses ttyS0. So I had to change the tty in the "bootargs" line in the "LINKIT7688.dts" device tree file, and remove the serial0-to-uart2 alias definition.
With that, I could build an image the Omega2 bootos up ok with, and gets accessible via the Ethernet expansion! WiFi access point also worked, but I didn't get it to connect to my WiFi as a client (didn't try hard, though).
For sure there are a lot of other details which are not exactly right in the LinkIt image for the Omega (e.g. LEDs, reset button). So this is for early experiments, but not for real use yet. We need to wait for the official platform support from Onion to appear in LEDE.
great stuff, please keep us posted! thanks!
-
@luz I extracted the device-tree table from my Omega2+ and there aren't really too many differences between the MT7688 dts and the Omega2+ dts. Bootargs are "console=ttyS0,115200" and the alias-section contains
serial0 = &uartlite;and the LED is on gpio-port 1, pin 12, , ie. something like the following should do:gpio-leds { compatible = "gpio-leds"; system { label = "onion:amber:system"; gpios = <&gpio1 12 1>; default-state = "on"; }; };That's about it, no other differences there. The rest is userland-stuff.
-
@WereCatf thanks for that investigation!
But are you sure this is all? Because when I tried the LinkitSmart image, the MAC address provisioning didn't work ok, the network interfaces came up with a non-onion default MAC. Is that something handled in the DT at all (I'm a newbie regarding DT)? Afaik the MAC is stored in a non-rewritable uboot env var in the first place. How and when is that read into the network drivers?
What would you think - what files apart from board.d/*, diag.sh, ramips.sh upgrade/platform.sh might be relevant for Omega2-HW related stuff?
-
@luz It's board.d/02_network that sets the correct MAC-address. If you look through the file you'll find a mention to linkit in two different sections, with one section accessing the mtd-device and setting MAC-addresses -- add your profile there and POOF, you've got valid MAC-address.
I made an mt7688-based profile "omega2p" (this is what they call it in the official images, too) and grepped through the files to find any references to "linkit" (
grep -i -R "linkit") in base-files and modified the relevant sections for "omega2p," also. There were a few minor differences in the DTS-file that I didn't notice at first, so I modified those, too. If you'd like, I can share the changes I made as a patch-file.EDIT: Thought to mention, that with my custom profile the Omega2+ works just peachy, including the microSD-slot, WiFi as both a client and an ap and all that. You mentioned in your earlier post that WiFi-sta didn't work for you, but you must have just made some configuration-mistake as I didn't have to do anything special to get it going -- just a working config.
-
Eh, I actually went ahead and forked LEDE. I'll make a pull-request after I've tested my changes a bit more, but in the meanwhile grab it from https://github.com/WereCatf/source , if you wish.
-
@WereCatf Terrific! Thanks for the fork and PR, I'll check it out immediately!
BTW: the non-plus omega2 is called "omega2" in those board switch statement, in case you want to add this as well.
-
@luz said in OpenWRT on the Omega 2(+):
BTW: the non-plus omega2 is called "omega2" in those board switch statement, in case you want to add this as well.
Yeah, I was thinking of it, but I feel a bit iffy about it, since I can't test it. I mean, it should work fine, I just change the Flash-size to 16MB instead of 32MB, but I still would like to test it first before making any pull-requests. So, I dunno.
-
Out of simple boredom I've been toying around with optimizing LEDE and after a lot of fiddling and benchmarking I've come to the conclusion that using -Os (the default) is better than than -O2, simply because of the really small instruction-cache -- benchmarking e.g. openssl yields better results with -Os than with -O2. There is no noticeable speed-difference between -mips32r2 and -march=24kec, so may as well just use the default of -mips32r2 (besides, if you use anything other than -march=mips32r2 or -mips32r2 some packages fail to optimize their code correctly. A workaround would be to define -D_MIPS_ARCH_MIPS32R2 and -D_MIPS_ARCH="MIPS32R2" manually). Adding -mdsp, however, yields a real nice ~17% improvement for DES and ~21% improvement for 3DES with openssl, and a couple of percent with some of the other ciphers. It didn't reduce performance with any cipher at all, from what I can tell. This is to say, if one is compiling custom packages, -mdsp is most likely well worth adding, at least for math-heavy packages.
-
@WereCatf I installed openssl-utils. Calling it I get two errors:
COMP_zlib_cleanup: symbol not found
BIO-f-zlib: symbol not found
I have no idea what's wrong. Can you help?
-
@Claus-Kühnel The Onion-devs have compiled their openssl-libraries with different settings than the LEDE-devs. You could try to install the openssl-library from LEDE's repos, but you risk breaking other stuff, then, so I recommend against that. Another option would be to e.g. download the libopenssl-package and extract it to another location, then calling openssl-utils with LD_LIBRARY_PATH set to point to the extraced libopenssl.
-
@WereCatf I'm currently stuck regarding gpiomux (swiching pins between GPIO and special function). On regular omega2 there's the omega2-ctrl tool to query/switch pin groups. However, the source of that tool is not on github, so I cant build it. I pinged @Lazar-Demin about that but so far got no response.
I tried installing the prebuilt opkg. It is installable, but when called complains "unable to open mmap fileroot".
Any idea how to approach this until Onion manages to publish their LEDE branch?
BTW: Just a small but important detail for your omega2.dts: The Omega2 (non-plus) has only 64MB RAM, so the memory definition needs to be as follows, otherwise the Omega2 will crash during boot:
memory@0 { device_type = "memory"; reg = <0x0 0x4000000>; };
-
@luz said in OpenWRT on the Omega 2(+):
I tried installing the prebuilt opkg. It is installable, but when called complains "unable to open mmap fileroot".
Did you enable KERNEL_DEVMEM (menuconfig Global Build Settings -> /dev/mem virtual device support)?
BTW: Just a small but important detail for your omega2.dts: The Omega2 (non-plus) has only 64MB RAM, so the memory definition needs to be as follows, otherwise the Omega2 will crash during boot:
memory@0 {
device_type = "memory";
reg = <0x0 0x4000000>;
};Yeah, I'll just merge the Omega2-branch to master and fix that.
-
Is the memory define really needed?
I think you should remove the memory portion...and try it.
You may find it's not required...LOL
You may also wish to drop "mx25l25635e"
compatible = "jedec,spi-nor"; should be enough.
Since it's defined in jedec why do you need "mx25l25635e" and "mx25l12835e"So why do we need two dts files?
BTW .dts usually are in UPPER CASE....whereas dtsi files are normally lower case.
check some multi size devices such as WRTNODE or NIXCORE.
You will find they have a common dtsi that references the SoC dtsi and then a dts for each device.
-
@Larry-Pinney said in OpenWRT on the Omega 2(+):
Is the memory define really needed?
I think you should remove the memory portion...and try it.No. I don't care enough to bother trying something like that.
So why do we need two dts files?
BTW .dts usually are in UPPER CASE....whereas dtsi files are normally lower case.
check some multi size devices such as WRTNODE or NIXCORE.
You will find they have a common dtsi that references the SoC dtsi and then a dts for each device.You'd then have three files, instead of two. I don't see the improvement. Also, if you'd take a look, you'll find plenty of dts-files in lower-case there, including for ramips-targets -- I'm not changing the case.
-
You may do as you wish....and go against convention.
However...you will find that you do not need to define the memory line. (if you try)
Then you wouldn't need two dts files or even a dtsi file ...thus reducing the code to a single file.
and further there is no need to specify flash chips already defined by jedec.There are no all lower case dts files in /target/linux/ramips/dts ... only your omega2
-
SULU: You try to cross brains with Spock, he'll cut you to pieces every time.
-
@WereCatf said in OpenWRT on the Omega 2(+):
Did you enable KERNEL_DEVMEM (menuconfig Global Build Settings -> /dev/mem virtual device support)?
No, I was looking for something like that but didn't find it. Apparently, KERNEL_DEVMEM has been added to LEDE only a few days ago on December 24th, 2016, and I hadn't pulled changes since.
Thanks a lot for the hint! Worked :-)!! Now I can switch gpiomux when installing the binary package from the onion feed.
Probably I don't need dynamic reconfiguration for my application, so I can set the default pinctrl in the .dts and will not actually need the omega2-ctrl tool.
Still, I hope Omega2 support will soon be pushed to LEDE (or a LEDE fork on github soon!), and all referenced packages such as omega-ctrl will appear in github too...
