Compiling for Omega2+ on Red Hat Linux?
-
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.
-
@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 defconfigThis means that in menuconfig, where it appears TARGET
Atheros AR7xxx/AR9xxxyou have to chooserampis, etc.
Or you can copy and paste those 4 lines.
-
@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.)
-
@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.
-
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)
-
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 menuconfigand 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.
-
@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 usemake menuconfigand 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
-
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.
-
@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
-
I find myself nervous about selecting the right hardware options in
make menuconfig.Has anyone got a
.configfile for openwrt which you already know works with an Omega2+, which you'd be willing to share?
-
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.
-
@Chris-Stratton
I have the OpenWRT 15.05 source tree. But when I runmake menuconfig, and look at the options for Firmware, I'm presented with choices for everything from ar3k-firmware to wl18xx-firmware, none of which are selected, none of which I know whether to select or not. There's an even larger plethora of hardware bits to select from in the kernel modules. For instance, even if I don't plan on using it, I'm fairly confident that a stock Omega2+ has the kmod-ledtrig-morse kernel module installed, but it's not highlit by default in menuconfig; more seriously, not one of the kernel modules for network devices or wireless drivers is already chosen.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
.configthat 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.
-
You seem to have overlooked the comment about there not being any complete full source tree tuned to this board available, from onion or anyone else.
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.
-
As far as I know you can find a sdk
with omega2 and omega2+ configuration files on onions git hubWhen 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?
-
@Adrian-Rix said in Compiling for Omega2+ on Red Hat Linux?:
As far as I know you can find a sdk
with omega2 and omega2+ configuration files on onions git hubWhen 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.
-
Okay good to know that thanks for the Information.
Going to play around and learn about this custom image stuff with my second om2
I guess.
