@Keitaro While opening the complete setup to build matching kernel modules is definitely something @onion should do (@administrators, @Lazar-Demin, hello again…), there's a ugly workaround for this: you can just force the module to load:
This is not without risk - if kernel internals have changed too much between the kernel you are running and the kernel the module has been compiled for, this will crash the system or cause any other undefined behaviour.
Having said that, the kernel APIs used by kmod-gpio-irq haven't changed between kernels 4.4.46 and 4.4.71, so it should work in this case.
@Ismas the architecture (target) in menuconfig is called "Ralink RT288x/RT3xxx", under which you find a subtarget "MT7688 based boards" and finally the Omega2 profiles.
Before starting to dig through Linux sources for these SoCs I hadn't realized how difficult it is to relate chip names to their architectures and drivers. There's little logic in it, but a lot of history.
How would one be able to guess the MediaTek 7688 goes under the "Ralink" architecture? Of course, once you know that Ralink was once a company that made MIPS based SoCs, and was aquired by MediaTek in 2011, it makes sense.
Still, support for the MT7688 can go by any names with "ralink", "rt", "mt76" "7621" and probably quite a few others. Comments in drivers often refer to subsystems that probably once were separate chips and thus had a completely different number. And all this being in the mostly proprietary SoC world (few proper datasheets) makes it hard to figure out what belongs where. So it took a while for a beginner like me to even start connecting dots... ;-)
@Armstead-Smith if the individual app is a package in a feed (can be a third party feed like Onion's, or your own), you can build it separately with
This will produce a *.opkg package in bin/packages/mipsel_24kc/FEEDNAME. This can then be copied to the omega2 and installed with opkg.
Setting up your own feed with your own packages is not entirely trivial, but not really difficult either (with some time invested in reading up). I think it's worth doing, to get a nicely organized build.
If all you need is cross-compiling a binary without packaging, you could probably directly use the tools from the toolchain LEDE has build for you in build_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.16. You'd need a bunch of environment settings to direct compiler and linker to the correct headers and libraries - but I don't have practical experience with that.
Kit's recommendation for using VirtualBox under Windows is the best option IMO too. As for the Linux system running inside your VirtualBox virtual machine guest, any Linux flavor should do. Go from your past experience, or Kit's suggestion actually proven to work. I will personally use FreeBSD when I receive my Omega 2. You won't have problem using C/C++. I tested Netbeans a little, and it seems nice so far for me. Check also for CodeBlocks. I like it better. Best of all, all this is Free or Open Source software. Your only cost, time and patience for the learning phase.
The omega bootloader (uboot) has a small http server built-in, which can run and accept a new firmware over ethernet (but not WiFi) completely independently from OpenWrt - this allows to recover even seriously mis-flashed units.
This feature saved my Omega a few times back when I just had started to build my own OpenWrt images and got important details wrong in the first few attempts...
I just noticed that even when you don't have the ethernet expansion, but a second Omega with dock, you can use that to reflash, see here
@Boken-Lin Thanks - that information clarifies things. Thanks :-)
Look forward to future developments in relation to generating Omega specific images - it would be a good thing - mainly to make life simpler.
however, i am now successfully building packages for the Omega which I can install using opkg so am currently happy with what we have :-)