Am I going to need to install a VM of a Debian-style OS, or something? Or is there an easier way?

Or is there an easier way?

I don't know ... did you see the docker solution?

when I try to 'make tools', the effort fails partway through.

When this happens while building a large software project it's useful to try to identify the first error and do web searches on it, and/or quote it in your request for help.

Also, the markdown to write inline code like make tools is with the ` symbol (from up left to rigth bottom).

The only possibly relevant changes to the system I can think of are that I installed the packages for Docker before I realized they were obsolete, including all the dependencies; and when I uninstalled the main Docker packages, the dependencies didn't go away. So maybe they were what my system needed. Or maybe my system just needed to try having make run a few times in a row to get past whatever the problem was.

In short: Looks like this thread is now unnecessary. (Unless something else turns up as I try to compile some particular thing.)

I'm trying to compile a module for BtrFS, for my Omega2+; so far, the result of my efforts is this file: http://www.datapacrat.com/temp/kmod-fs-btrfs_3.18.45-1_ar71xx.ipk

Unfortunately, when I bring that file onto my Omega, and try to use opkg to install it, I get an error. (And of course Putty doesn't seem to be letting me copy the error's text directly - yes, I know Putty is designed to use the mouse for that.) I run opkg install ./kmod-blah, and get...

Unknown package 'kmod-fs-btrfs'.
Collected errors:

• pkg_hash_fetch_best_installation_candidate: Packages for kmod-fs-btrfs found, but incompatible with the architectures configured
• opkg_install_cmd: Cannot install package kmod-fs-btrfs

... I have a suspicion that the error arises because the compilation instructions I've been working on were based on the first Omega, and need tweaking for the Omega2+. So, new question: When compiling for the Omega2+, what's different than when compiling for the original Omega?

Did you set the system type in menuconfig to ramips and then mt7688 specifically?

Otherwise you probably built a big-endian mips executable for an ar9331 as on the Omega1 rather than a little endian mips one with the mt7688 configuration details.

There might also be issues at the ipkg level, less familiar with that.

Subtarget should be something like MT7688

AR9xxx will definitely not work, that is their competitor, architecturally similar but ABI-incompatible due to the endian difference and more.

From my Dockerfile you can get how to configure it manually with menuconfig:

echo "CONFIG_TARGET_ramips=y" > .config  && \
echo "CONFIG_TARGET_ramips_mt7688=y" >> .config  && \
echo "CONFIG_TARGET_ramips_mt7688_DEVICE_omega2p=y" >> .config && \
make defconfig

This means that in menuconfig, where it appears TARGET Atheros AR7xxx/AR9xxx you have to choose rampis, etc.
Or you can copy and paste those 4 lines.

With that setting, I've now compiled https://www.datapacrat.com/temp/kmod-fs-btrfs_3.18.45-1_ramips_24kec.ipk ...

... and opkg is giving me the same errors it did before. Phooey; it looks like I won't be able to take the shortcut of just compiling the one module I need, I'll need to compile the whole set of packages. Looks like I've got a weekend project of looking up how to use the Omega2+'s built-in OS as a bootloader, and installing the actual OS onto my 32 GB microSD card. (I know I saw the instructions for that somewhere, I've just lost track of where.)

I'd recommend against using an SD card as a root filesystem if you can at all avoid it.

You can use the built-in U-Boot to or even the sysupgrade under the running Linux to write a completely different software install to the SPI flash; you can also build a kernel with the filesystem packed as an initramfs that will uncompress and run from RAM, especially if you want to tftp something in and give it a one-shot try without storing to flash. Modifying U-Boot to read such a build off a card or USB storage (which would then run from RAM) could be worthwhile.

Getting back will be trickier if your new image proves non-functional; you'd either need TFTP over wired ethernet or a USB stick to get the stock image back into U-Boot and then write it to flash.

(Or if you want a real adventure in hardware hacking there is JTAG or directly writing the flash chip with something else, if you contemplate changing U-Boot it would be good to have one of these in reserve)

I'd recommend against using an SD card as a root filesystem if you can at all avoid it.

May I ask why? I'm already using it as an overlay, and my plan is for most disk activity to be on the multi-terabyte BTRFS drive that's the whole point of this exercise.

you can also build a kernel with the filesystem packed as an initramfs that will uncompress and run from RAM

I suspect I'm going to have trouble enough just figuring out which kernel modules I'm going to need to include to support the Omega2+'s built-in hardware, so that I don't accidentally brick the thing. (I'm tempted to use make menuconfig and just select /all/ the blank items to compile as modules to be on the safe side...)

Honestly, I find myself amused at the contortions I'm having to go through to accomplish the goal of "stock Omega2+ or better, plus support for BtrFS". At this stage, if anyone here happens to have something I can download that includes that, I'm willing to forgo the current character-building learning experience.

@Chris-Stratton
... ... ...
I suspect I'm going to have trouble enough just figuring out which kernel modules I'm going to need to include to support the Omega2+'s built-in hardware, so that I don't accidentally brick the thing. (I'm tempted to use make menuconfig and just select /all/ the blank items to compile as modules to be on the safe side...)

Good luck with that Chances are that in selecting all* blank items will not work.
I have tried something similar and basically just gave up when there were several modules that:

• either just failed to build - even after tracking down the myriad dependencies
• or failed because the repo that needed to be accessed was password protected

Especially if the real goal is just to build enough to get a working toolchain rather than a complete bootable and functional system.

Hopefully the defaults would work.

Especially if the real goal is just to build enough to get a working toolchain rather than a complete bootable and functional system.

You should be OK with the defaults
Also, building the toolchain works and is usable - just make sure you select it in make menuconfig

Has anyone got a .config file for openwrt which you already know works with an Omega2+, which you'd be willing to share?

Note that there is not at present any complete, working, published source that specifically targets this board.

My worry is that if I don't pick exactly the right bits of hardware here, then when I try to use my home-compiled OS on my Omega2+, I'll have left out an important piece that will prevent me from even connecting to the Omega2+ again, effectively bricking the thing.

I'm hoping that if someone already has a .config that works, then I can safely use that as a guide to which modules for hardware support I need, and I can build from there. Failing that, maybe a simple list of which bits of hardware are on the Omega2+ (as opposed to the Omega) that need such software to be compiled would be enough to keep me from reproducing my earlier mistake of trying to compile for entirely the wrong board. Failing /that/... maybe I could try compiling a monolithic kernel that just includes support for everything, but that's hardly optimal.

Rephrased: My current problem is a lack of info on what chips and such are on the Omega2+ that need kernel/OS software compiled for them.

Probably the closest would be to get mediatek's tree for the linkit smart, though you may have to deal with some issues with the different flash chip chosen (or it might work anyway)

It is indeed likely that early self build attempts will not function, thus you will need to have a mechanism to get a new image in without a working one - likely either a USB drive to U-Boot, TFTP over wired ethernet to U-Boot, or less likely directly programming the SPI flash chip with someone else or using JTAG to load in the code and then U-Boot to write it.

you will need to have a mechanism to get a new image in without a working one - likely either a USB drive to U-Boot, TFTP over wired ethernet to U-Boot, or less likely directly programming the SPI flash chip with someone else or using JTAG to load in the code and then U-Boot to write it.

I am completely unfamiliar with those techniques. Do you have any references on any of them handy?

USB should be covered in onion docs, TFTP may be there or in openwrt docs.

The other two should only be attempted if you are already quite familiar with them in concept.

When configuring with "make menuconfig"
you will see sub options for omega2 and omega2+ if you select the mt7688 as target. Thats what I used for my images.

I never tested them cause atm I don't need them but as soon as I need custom kernel mods I will give them a try.

I remember that on Omega2 stock os your not able to install custom kernel mods.
At least it didn't work when I tried to install my "HelloWorld" kernel mod
I have accomplished to successfully comile :D.

When building the image with the build options from the onion sources I mentioned above will I then be able to install custom kernels?

As far as I know you can find a sdk
with omega2 and omega2+ configuration files on onions git hub

When configuring with "make menuconfig"
you will see sub options for omega2 and omega2+ if you select the mt7688 as target. Thats what I used for my images.

I never tested them cause atm I don't need them but as soon as I need custom kernel mods I will give them a try.

Had you tested them you would have discovered that basic functionality like wifi is missing.