OpenWRT on the Omega 2(+)
-
@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...
-
@luz said in OpenWRT on the Omega 2(+):
Thanks a lot for the hint! Worked :-)!! Now I can switch gpiomux when installing the binary package from the onion feed.
I haven't played much with my Omega2p lately and I never actually tried if gpiomux or fast-gpio works in my images, so it's good that you got around to testing it and reporting back here. Maybe the information will come in useful for someone else, too.
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...
Here's hoping. I just don't quite understand why the devs keep the stuff private in the first place, it's not like it'd hurt them or their community. shrug
-
@Larry-Pinney I think you are arguing with the wrong guy
@WereCatf is just helping us mere mortals (meaning, LEDE/OpenWrt novices) with some quite useful practical hints.It's @onion who you should listen to you - you seem to have some experience as a LEDE mainline contributor, and that's what onion will hopefully become too, soon...
It's a pity they don't leverage the knowledge from people like you by opening their LEDE branch for inspection, test and improvements. This would improve the quality of a later PR to LEDE.
Out of cusiosity: why don't we need that memory def? The kernel needs to find the memory size somehow, how would it work without that def? (this is a real question, as a beginner, I really don't know - memory testing maybe? where? at the uboot level?)
-
@WereCatf said in OpenWRT on the Omega 2(+):
Here's hoping. I just don't quite understand why the devs keep the stuff private in the first place, it's not like it'd hurt them or their community. shrug
I don't understand it either.
I mean, most probably they are currently too busy with other things to take the time to clean up and prepare a PR to LEDE at this time. But just pushing their WIP fork of LEDE to a github repo would be instant and actually help us and them, as some of the cleanup work would be done by the community.
After all, it's nothing they can avoid - this is all GPLv2 stuff so the sources to build the shipping images must be made available (only fully onion-specific programs could possibly remain closed - yes, that would include omega2-ctrl, but not the basic setup, dts, profile, uboot etc.)
-
@luz Quite agree with all this.
It is a repeat of the situation with the Omega1 - despite frequent multiple requests for a copy of their repository for OpenWrt to enable us to deal with issues with that (probably most notably the recurrent kernel version mismatch issues for many packages) there never was any response - and probably now never will be
While my Omega2 still hasn't arrived, I am getting quite concerned about the number and type of issues that are getting reported in these forums. I will reserve final judgement until I do get my Omega2 and try things out myself, but am getting close to giving up on the Omega - reluctant to do that, I have invested quite a lot of effort over the last year with the Omega1 and it would be a shame to see the work go to waste - but eventually one has to cut one's losses
I am seriously considering switching to using a Raspberry Pi Zero (with Red Bear IoT pHAT for Wifi an BLE access) - physically bigger than the Omega but way more powerful.
-
@Kit-Bishop said in OpenWRT on the Omega 2(+):
I am seriously considering switching to using a Raspberry Pi Zero (with Red Bear IoT pHAT for Wifi an BLE access) - physically bigger than the Omega but way more powerful.
If you don't need a CSI-camera, might I suggest taking a look at C.H.I.P., too? It's already got WiFi and Bluetooth on-board and a free, full-size USB-port for any possible additions you might want. Personally, I find the built-in lipo-charger an exceedingly handy feature, too.
-
@WereCatf Thanks - C.H.I.P. looks interesting. The more one digs, the more viable alternatives to the Omega one finds - and at good prices with a good range of functionality
-
@Kit-Bishop Feel free to ask me if there's something you'd like to know about the C.H.I.P. before purchase, or go troll around on the forums at https://bbs.nextthing.co/ The one caveat I'd like to point out when compared to the Omega2 is the lack of option for an external antenna -- I don't know if it is an issue for you or not, but if the range ever becomes a problem you could always use a USB WiFi-stick with a proper antenna instead.
-
@WereCatf Cool, thanks
Have already found quite a bit about C.H.I.P. and it looks really interesting. WiFi range probably won't be an issue for me but will bear it in mind.
-
@Kit-Bishop said in OpenWRT on the Omega 2(+):
While my Omega2 still hasn't arrived, I am getting quite concerned about the number and type of issues that are getting reported in these forums.
Same here! Perhaps by the time we receive our order, all the bugs will be flushed out of the system!
C.H.I.P. is interesting! ARM instead of MIPS, variety is good. What I don't like, they are backordered for 3 months, and counting. SoC is a small market with lots of competition. We can't assess any company's longevity so the grass is not necessarily greener at the neighboring competitor.
