We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Omega2 Cross Compiler and Kernel Sources



  • @luz said in Omega2 Cross Compiler and Kernel Sources:

    (but [read his disclaimer!]

    Everyone's referring to me as a "he" when it should be "she." I know it's irrelevant as to the topic, but it irks me anyways šŸ˜„



  • @WereCatf you really got me with this. Sorry! And thanks for the hint. It really makes me think, realizing how easy it is to still fall into that trap of blindly assuming a "he" behind a unknown nick in a tech forum. What would be the right thing to do? Google first? Use (s)he in general? Avoid pronouns? Just ask?



  • @luz Assume 'HE' unless the username is clear, or the user corrects you. šŸ˜‰ We are brainwashed by politically-correctness.



  • @fossette political correctness is not the point here (at least not for me) - what made me think is that I imagine a person when discussing, and imagined a "he" without thinking.



  • Tank you @luz

    I followed all your steps including the ones from the Onion tutorial
    but on my VMs I have not been able to compile the toolchain (or even the LEDE image).

    First I have tried to build it on Kubunu (newest LTS Version 64bit)
    afterwards I have tried to compile it on a complete new installation of Ubuntu (newest LTS Version 64bit)
    On both system the compiling process failed.

    This is the output I am getting on Ubuntu when using "make -j1 V=s"

    Bild Text

    Can you tell me how to fix this issue
    or at least what Linux Distribution you are using? šŸ˜•

    I have a working pre compiled Toolchain but I want to learn this whole stuff



  • @Adrian-Rix I haven't seen that message myself so far, but it seems to be related to the recent aim to create reproducible builds. Apparently, for some reason when building mkyaffs2image the SOURCE_DATE_EPOCH is not defined as it should be.

    What LEDE commit did you check out? @WereCatf's master?

    If mkyaffs2image is the only tool giving problems, and the omega does not need YAFFS at all, maybe there's a way to disable building that tool (apparently not via menuconfig, I just checked).

    Regarding my build platform - I'm using Mac OS X. Works great for me, the only thing I had to work around is that OpenWrt/LEDE needs a case sensitive file system, which OS X can do, but does not have by default. So I just have the LEDE tree within a separate, case sensitive disk volume (a mounted diskimage).



  • Good evening,
    managed to fix the problem.
    I was finally able to compile everything.

    The Problem was that I downloaded the sources not via console using git clone
    but via Firefox so the TOPDIR Folder had an other name.

    "onion-omega2" instead of "sources"

    The next Problem was that I tried to build it with an user with root-privileges.

    After i figured out everything I had no more problems.

    But just one thing I still have to ask:

    Where in the sources can I actually find the kernel sources.

    I have found all the compiled sources including the kernel modules but not the Kernel sources itselfe

    According to the output of one of the compiling tries I did
    the sources were downloaded before the got compiled.

    When I checked the kernel dir in the build root I only found dirs with just a makefile.

    Quiet confuseing.



  • @Adrian-Rix LEDE itself is no just a heap of sources + makefile to build something, as a single project (even the Linux kernel) is.

    LEDE is a "distribution build system", which means it is kind of a meta-level above what one usually refers to for building a tool or library from source.

    Yes, that's confusing when you see that for the first time (I remember well, started digging in not too long ago myself šŸ˜‰ )

    What this means is: LEDE's makefiles don't describe how to make the kernel (or anything else), but they describe what has to be done to get to the point to make the kernel:

    • get the sources (from upstream, meaning the original project)
    • patch the sources when some changes are needed specifically for LEDE that upstream does not contain
    • prepare everything around, in particular the toolchain (compilers, linkers, etc.) needed to build code for the target (=Omega2/MT7688 in our case) platform.
    • only then, the regular build process (often autoconf/configure/make, cmake but also others) is started.
    • once the build has completed, LEDE packages the results into installable packages or firmware images

    So in a freshly downloaded LEDE source you don't find the kernel sources, just the recipes (makefiles) how to obtain them. That's what you see in target/linux/ for a large number of different targets. "ours" is target/linux/ramips/ with some specifics in target/linux/ramins/mt7688.

    Similarily, package/ contains recipes for userland (and other not target specific) stuff, and /feeds contains collection of separately maintained recipes for more software. Feeds can be from third parties, like feeds/onion/ is.

    Now - where's the kernel source? When you type

    make target/linux/prepare
    

    in a fresh LEDE buildroot, a kernel tarball will be downloaded into dl/, then extracted into build_dir/target/target-mipsel_24kc_musl-1.1.15/linux-ramips_mt7688/linux-4-4.xx. From there, it will be built when you type just make or make target/linux/compile

    But note, dl/, build_dir/ and also staging_dir/ are temporary. As soon as the LEDE makefiles consider something changed, sources will be re-downloaded. So build_dir is not a good place to actually develop. There are mechanisms in LEDE to have it use an out-of-tree development folder for a package under development (keyword USE_SOURCE_DIR).

    This is just an attempt to make the overall picture more clear - head to OpenWrt's wiki and also to LEDE docs for more information.



  • Ok,
    thank you for the information.

    I have found everything I need and also a tutorial on how to build a simple kernel module
    using the package system.

    I was not able to build the kernel mod that I need but this should be cause of incompatibility with the newer kernel version or version of the other needed kernel mods like videobuff2_core. Guess I have to find an other way šŸ˜„

    Tank you for your help
    Now I know everything I need to know an the rest I can figure out myself (I guess šŸ˜„ ).



  • @luz
    I tried the above instructions, but menuconfig does not show a MediaaTek Ralink MIPS target. Is this still valid?



  • @Armstead-Smith Yes, the target still exists - no danger for it to go away anytime soon, the MT7688 is popular beyond the Omega2 šŸ˜‰

    Assuming you got a current LEDE, such as the stable 17.01 branch from github: In menuconfig, under Target System ---> (first menu option), you should be able to find the MediaTek Ralink MIPS option.

    Once this is selected (but not before!), in the Subtarget ---> menu you will find MT7688 based boards.

    Once this is selected (again - not before), in the Target Profile ---> menu Onion Omega2and Onion Omega2+ will appear.

    Then, you can type make and (depending on your machine) in 1-2 hours you'll have a stock LEDE image in bin/targets/ramips/mt7688 that will work with the Omega2. Note however that this is not the same as the Onion provided firmware - altough LEDE based as well, the latter is still not fully published, unfortunately.



  • @luz OK. I got it and it's all built. Thanks. How do I do cross-compiling for an individual app?



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

    make package/MYPACKAGENAME/compile
    

    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.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.