Compiling for Omega2+ on Red Hat Linux?

Daniel Boese

I've tried to follow the relevant instructions, but Red Hat uses somewhat different package names than are suggested for Debian-style Linuxes. I've had no trouble using make to compile and install other bits of software, but when I try to 'make tools', the effort fails partway through.

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

Luciano S.

@Daniel-Boese said in Compiling for Omega2+ on Red Hat Linux?:

Or is there an easier way?

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

Daniel Boese

I saw the Docker thread, and even tried it, but the laptop in question is stuck with Red Hat 23 until I can figure out how to handle the partitioning system in Red Hat's upgrade process, and the Docker install instructions require RH24 or higher.

Chris Stratton

If you are trying to create a toolchain from the LEDE sources, you might look beyond onion resources to LEDE or OpenWRT instructions and see if you can find something on setting up your version of Redhat with the necessary packages to support a build, or failing that suggestions for cross compiling to some other embedded Linux target like a raspberry pi, beaglebone, or building Android from source. Many of the essential requirements will be the same, as they come down to the fact that you need to use the Linux kernel configuration and build system. Unique ones are more likely to be support for output compression types than anything unique to the specific chip/board you are targeting.

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.

José Luis Cánovas

@Daniel-Boese some people instead of docker used a virtualbox ubuntu VM and did a clean instalation and SDK build. The downside is the worse performance of a vm than docker or native instalation.

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

Daniel Boese

... Hunh. I started to run make in the openwrt directory, to generate the error messages to post here... but it kept going past where it stopped before, and after having let it run a while, it looks like it's actually successfully compiled.

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

Daniel Boese

And of course it couldn't be that easy.

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?

Chris Stratton

@Daniel-Boese

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.

Daniel Boese

@Chris-Stratton
The menuconfig I have is currently set to 'Atheros AR7xxx/AR9xxx'. ... I don't see any options resembling either 'ramips' or 'mt7688'. Am I looking in the wrong place? (I grabbed the openwrt files on Feb 4th, so going by my web history, it's the 15.05 version from http://git.openwrt.org/?p=15.05/openwrt.git;a=summary .)

Chris Stratton

Depending on version it might be called Ralink or Mediatek (who bought this line) or "MediaTek Ralink MIPS"

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.

José Luis Cánovas

@Daniel-Boese Use the LEDE files. There is even a Omega2/+ specific target.

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.

Daniel Boese

@Chris-Stratton
Ah, thank you, there we go: "Target System: Ralink RT288x/RT3xxx", "Subtarget: MT7688 based boards".

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

Daniel Boese

@José-Luis-Cánovas
I think I've got the settings to compile the openwrt packages; if I can't figure out how to get them to work, I'll give LEDE a try.

Chris Stratton

Keep in mind that while LEDE is a derivative of OpenWRT, they typically use different C libraries, so you face either an all-or-nothing switch, or some interesting times getting two different dynamic linkers to cohabitate.

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)

Daniel Boese

@Chris-Stratton

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.

Kit Bishop

@Daniel-Boese said in Compiling for Omega2+ on Red Hat Linux?:

@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

Chris Stratton

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.

Kit Bishop

@Chris-Stratton said in Compiling for Omega2+ on Red Hat Linux?:

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

Daniel Boese

I find myself nervous about selecting the right hardware options 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?

Chris Stratton

The issue is not the configuration file but the source code; if you have a suitable source tree, the source you got it from should (or resource that pointed you towards it) should be telling you how to proceed. Typically there would already be an appropriate board target. Then unless you are trying to change something you should be able to just use what that sets.

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