OpenWRT on the Omega 2(+)

luz

@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>;
};

WereCatf

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

Larry Pinney

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.

WereCatf

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

Larry Pinney

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

Larry Pinney

@WereCatf

SULU: You try to cross brains with Spock, he'll cut you to pieces every time.

luz

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

WereCatf

@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

luz

@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?)

luz

@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.)

Kit Bishop

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

WereCatf

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

Kit Bishop

@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

WereCatf

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

Kit Bishop

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

fossette

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

Kit Bishop

@fossette Generally agree.

My Omega2+ (and expansion dock and arduino dock) finally just arrived today.

My initial experience has been OK - can access via WiFi and do basic operations.
Though a few things don't seem to quite work as I expected.
Also on initial investigation, there are clearly differences in the way the system software works.

My main concern is how to extend disk space using a USB drive - the instructions for the Omega1 (as in https://wiki.onion.io/Tutorials/Using-USB-Storage-as-Rootfs) clearly don't apply to the Omega2. Hopefully someone (the Omega devs?) will provide info on how to do it for the Omega2 (if I don't get it figured out first).

Fortunately, there are instructions for the different method of setting up swap space for the Omega2 - see https://docs.onion.io/omega2-docs/extending-omega-memory.html

WereCatf

I set up a new branch on my Github-repo for the LEDE for the Omega2(+). The new branch already includes a basic configuration and some extra files, including a firstrun-script, to produce a more fully-fledged image, ie. rsync, wget and all the expected buddies are included, repos for both LEDE-packages and Onion-packages are enabled and all you need to do to use them is connect to the Internet and run opkg update. I cannot promise that all the Onion-packages will work and I certainly can't be arsed to test every single one of them.

The differences between my version and the official ones are: I use the F/OSS WiFi-driver, so WiFi-performance isn't as good, with my images rebooting works, but shutdown doesn't, there aren't any Onion-packages by default and you'll have to install any you want yourself, and I have included Luci-SSL -- I find that Luci is very useful, especially for configuring network-settings, and it provides a graphical way of installing apps and stuff, too. You can install the Onion Console by deleting /www/index.html and installing the packages base-www and onion-console-base (though, when I tried it, it seemed that the onion-console-base in the repos was broken and didn't work right) -- Luci can still be accessed via http://omega-ABCD.local/luci.html

The firstrun-script included in this branch sets up an AP, similar to the official images, with a similar name and password.

Precompiled images and the corresponding kmods are available at https://dl.dropboxusercontent.com/u/11811685/omega2_images.tar.gz , if you just want a quick test, or you can build your own more-custom images quite simply:

git clone -b image https://github.com/WereCatf/source.git omega-sources
cd omega-sources
scripts/feeds update -a && scripts/feeds install -a
#Make any changes you wish to the image and any extra packages here
make menuconfig
make

If you rather want working shutdown, but broken reboot, delete omega-sources/target/linux/ramips/patches-4.4/101-spi-reset-to-3-byte-mode.patch

This branch is only meant for playing around with and it is as such only temporary -- I will most likely delete it one day when I deem it no longer necessary. Also, I take no responsibility for anything, whatsoever, in any way or form, and I have no interest in playing tech-support -- don't even attempt to try this stuff, unless you accept that things may not work how you'd like them to work. It's also not intended for total newbies.

Jeremy Fee

@WereCatf : +1 for open source

Jeremy Fee

@Kit-Bishop : try this for usb storage https://community.onion.io/topic/592/daft-question-re-usb-storage-as-rootfs/12