Has anyone tried to install Gentoo on a WRT device such as a Linksys WRT54G? That's what I'm beginning to work on at the moment and if anyone has successfully accomplished it any/all advice is greatly appreciated._________________Steve - Semper Fi

OpenWRT would definately be a better choice. Gentoo will not run on a WRT54G, or any other Broadcom-based wireless router. It's simply not our focus.

These are machines with very little memory (32MB) and no storage options whatsoever -- Gentoo simply is not intended for such crippled hardware.

You're welcome to try port Gentoo to such a device, but you're on your own... none of us on the Gentoo/MIPS team have the time or desire to support them. Gentoo Embedded, might have an interest, but you'd have to ask them._________________Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

It's quite possible to do this, but it definitely requires some "out of box" thinking, that box being the little router itself. I picked up one of the nice WRT54GS models (a v2.1) reasonably on Ebay and have been getting a crash course in embedded through this process, with the goal of a workable Gentoo system mounted off a remote filesystem.

Quote:

These are machines with very little memory (32MB) and no storage options whatsoever -- Gentoo simply is not intended for such crippled hardware.

On both points this is correct. But with a little clever filesystem trickery we can work around these issues, with some tradeoffs. I'm at work and have neither the time nor hardware and command logs to post the details at the moment, but basically you use a barebones OpenWRT and install the kernel module for NFS support. This will allow you to mount an external filesystem from another device like any other Linux kernel could.

Now, download the MIPS stage3 tarball at (http://gentoo.osuosl.org/experimental/mips/embedded/stages/) and install it to a spare drive (I used /opt/cross/gentoo_embedded/mipsel_rootfs). Ensure your NFS is set up properly and export the directory with the no_root_squash enabled so you get proper root access. You should then be able to mount this over NFS (be warned, it may take awhile but it will work). SSH into OpenWRT shell, create a mountpoint (I used /mnt/gentoo) and mount the remote filesystem here. mount /proc, copy over /etc/resolv.conf, and chroot into the mounted f/s.

There are several additional steps which can be taken to make this more usable, but so far I've met with limited success. I will post more detail and provide a better description of the process if anyone's interested. A distcc host (I was able to compile distcc and ccache natively on the WRT54GS, among several other applications out of the portage tree), mounting an external portage, and a few other steps may make this a feasible setup and it's definitely a cool idea._________________Sager NP6165 | i7-3610QM | GeForce 650M
Gigabyte GA-880GMA-USB3 | AMD 1100T | Radeon HD 4250
MSI P6N-SLI | Q6600 | Sapphire HD 6870

What you are saying sound nice as an experimental set. But in practical use, that may be a bit painful. Here are the reasons:

1) There are two points of failure now. The router and the machine exporting the filesystem.
2) A router usually needs to have 24/7 uptime. Now this is also required of the second system.

P.S: Frankly, I would myself try this with the linksys router and the slug (NSLU2 from Linksys. A nifty little device)._________________Power is about what you can control. Freedom is about what you can unleash.

Cool. I would say at this point, VERY experimental. Though it's amusing to chroot a router into what looks like Gentoo, I'm not sure how useful it is / could be, especially at this point. Give it a shot if you get the chance, maybe it's more than a toy idea. The compile/upgrade cycle is probably better performed elsewhere, though distcc cross-compile, is tolerable, portage itself is painfully slow as are autoconf/automake... but they DO work. I had better success with cross-compiling directly to the root but key parts of "emerge system" die a slow, painful, horrible death as they don't support cross-compilation at all.

Quote:

1) There are two points of failure now. The router and the machine exporting the filesystem.

Indeed. OpenWRT protects its own core (r/o squashfs) and userland, and chroot isolates our filesystem, so we can at least have basic connectivity, just running Gentoo atop that layer.

Quote:

P.S: Frankly, I would myself try this with the linksys router and the slug (NSLU2 from Linksys. A nifty little device).

I haven't experimented with this, but we have a few managed switches, firewalls and routers in our office. They all allow for a DHCP boot and configuration.

The thing is here that each component should be redundant in a high availability environment. That means that you would use more than one router, in this example, and would boot from one of at least two DHCP servers which are each appropriately configured to supply the correct boot image to the router's network card.

The idea is called failover. (sorry, not trying to sound snotty if you already know this, just trying to be helpful if you're not aware)

Anyway, the idea is that any component is expendable, and if that component were to vanish in a puff of smoke you would only need to replace it, with no particular hurry since something else has taken over its function.

This happy state of affairs exists in one or two spots on my network, but alas routers are still not in those spots.

So I've seen, Linux seems designed to allow for possibilities that would blow the minds of the unwashed masses. It's quite humbling in many respects. Bootloading and file systems is one of them. I'm familiar with and have only marginal experience with netboot (TFTP and suchlike) only from a hobbyist-perspective, so bear with me.

Quote:

Anyway, the idea is that any component is expendable, and if that component were to vanish in a puff of smoke you would only need to replace it, with no particular hurry since something else has taken over its function.

Yes indeed.

Quote:

The idea is called failover. (sorry, not trying to sound snotty if you already know this, just trying to be helpful if you're not aware)

No problem, the tone is appreciated. We're here to learn something, after all.

My thoughts on the matter are that if you can preserve the core and delegate these basic functions to OpenWRT, the enhancement (to put it mildly) provided by Gentoo can occur without fear of compromising the main purpose of the router. Python and Perl would give a lot of options for sophisticated automation with pretty minimal code required. Emerge everything possible via cross-compiler and compile only what breaks on the router itself, and use distcc to spread the heavy workload among faster hosts than the little 200Mhz MIPS32.

as for the practical side of things... I can give only some raw basics right now - sorry if this is elementary; the importance is in the NFS options, ignore the IP and mask, this is my home network. Your /etc/exports must include something like:

Simple stuff, but maybe it saves some typing. Et voila, a no-frills unoptimized working Gentoo

Problems::
Do not bother with 'emerge -pe system' or any variant, mine didn't complete in over an hour. Definitely don't try to sync portage locally, I think the router would melt if you did this.

I know that Python in particular doesn't like cross-compilation and probably will not officially support it, and I lack the knowledge of its complex bootstrapping process (python is built with python scripts!) to work around it. I had much better luck cross-compiling a minimal system (busybox, uclibc, baselayout-lite, dropbear, iwconfig) under gcc-3.4.5-r1 + uclibc-0.9.28, but wanted to try the "hardware" approach also, with a fullblown stage3, from the other side.

A fusion of these approaches will eventually be required, unfortunately I don't have several hours to spare right now in banging my head against the problem. Also I had to reset the symlinks and restore uclibc 0.9.27 from the tarball after a "successful" emerge of uclibc-0.9.28 broke the stage3 dependencies (no more python... no more emerge... no more fun) but this could be due to stupidity as it was about 4 in the morning. Regardless, it's a LONG way from "emerge -e system" level. Much of the base system actually works via emerge from a cross-compiling buildhost, hats off to the gentoo-embedded developers for this, even if the humble Linksys WRT54G series was perhaps not an intended target._________________Sager NP6165 | i7-3610QM | GeForce 650M
Gigabyte GA-880GMA-USB3 | AMD 1100T | Radeon HD 4250
MSI P6N-SLI | Q6600 | Sapphire HD 6870

For anyone still following along, I made some small amount of progress on this notion of getting Gentoo onto the WRT54G series router. Although the WRT54G itself *will* run a standard compiler, the conditions are far from ideal for this and it is very time-consuming. Surprisingly however, the box never died and it maintained my two connections, in fact I was even able to connect to and use the web interface of OpenWrt a few times while all this nonsense was going on. It should not compromise your router as everything is being done in an isolated chroot, so the worst you can probably do is to write some nastiness to NVRAM, or run it out of memory. Either power cycle or a hard reset should fix any issue and you shouldn't play with OpenWrt in the first place if either of those steps or the possibility of blowing up the router scare you.

If there is interest in this, I will do an informal HOWTO when I have access to my bash history again. For now some high-level details and suggestions will have to suffice. I quickly discovered after a few broken filesystems, that the stage3 compiled by the gentoo-embedded folks was for me a dead end. Doing a system build from scratch ended up to be much more promising as I wanted a 0.9.28 uClibc.

before going further, these are the packages that I've gotten to compile so far, for my v2.1 WRT54GS:

Some of these are not particularly useful and were produced as part of the experimental attempt to build "emerge -e system". Other parts are far more encouraging. Building this set will yield a usable yet basic Gentoo chroot environment.

You first need to prepare the minimal OpenWrt. Gentoo will be resource-intensive on the small but serviceable router and we want as much memory available as possible especially if you try onboard compilation (it works; I built uclibc-0.28, coreutils-5.2-r1, and a few others natively but I would not expect the router to do much else when running a compile job). I built OpenWrt from buildroot but a precompiled binary should work just as well. You'll need to use ipkg (itsy package management system) for OpenWrt to include some extra kernel modules: support for NFS is required, and support for loopback file system is recommended.

What I've done so far, I would divide into 3 primary stages: bootstrap, minimal, and gentoo-base. I built a very minimal root with uclibc, busybox, a toolchain and some basic networking. Essentially I then went through from "emerge -e system" noting what compiled, what nearly compiled, and what broke.

To follow along, you need to build a cross-compiler for the mipsel-base Broadcom chip in the router. You then need to set up a proper cross-compilation environment after the basic bootstrap. I'll detail the process and give the scripts and settings I used to get this far in the hopes that others interested in this will try to replicate this on their own boxes, but wanted to let someone know that I have not abandoned the idea by any means, and intend to take it further as time permits. Feel free to message me if you want to get involved further, this could actually be an interesting project._________________Sager NP6165 | i7-3610QM | GeForce 650M
Gigabyte GA-880GMA-USB3 | AMD 1100T | Radeon HD 4250
MSI P6N-SLI | Q6600 | Sapphire HD 6870

Just FYI, I know of at least one person who is still following along. =)

I run Squawker's gentoo tarball on 2 of my 3 slugs and Open-WRT on my WRT54G, so this thread is tremendously interesting to me!

I wish I had the bandwidth to help, but I'm working two programming jobs and also currently struggling with getting my x800 running under XGL on my ~amd64 build in my spare time (haha spare time) - though I'm about to give up and just buy a NVidia 7900 and be done with it. Maybe after I make a spendy visit to Newegg I'll be able to kick in some time and try with you.

Just FYI, I know of at least one person who is still following along. =)

So noted I am attempting to get a Slug up and running with Gentoo as well, unfortunately there are other obligations to deal with, like keeping bills paid. If I were still back in school I'd love to devote my weekends to projects like this but it's just not feasible atm. I'll get something posted this weekend, now that I have access to my logfiles again. Thanks for the word of support, a preliminary HOWTO will hopefully be coming along soon._________________Sager NP6165 | i7-3610QM | GeForce 650M
Gigabyte GA-880GMA-USB3 | AMD 1100T | Radeon HD 4250
MSI P6N-SLI | Q6600 | Sapphire HD 6870

Gentoo on Linksys WRT54G series HOWTO-in-progress Part One: Building Blocks

This isn't a full HOWTO, as I'm not yet to the point where that's a useful exercise, but I'll give some instructions as best I recall, for those who might want to follow along and perhaps advance the process. I quickly discovered after a few broken filesystems, that the stage3 compiled by the gentoo-embedded folks was for me a dead end. Doing a system build from scratch ended up to be much more promising.

Disclaimer / Caveat Emptor:
Following along with this tutorial should not be dangerous but this is experimental so if you b0rk the router and it becomes a nice brick, I hope you have a JTAG... I don't . As I said earlier this should not compromise your router as everything we're doing is being done in an isolated chroot, and we're doing this initial work outside the router itself. At worst a misbehaving program might inadvertently write junk to NVRAM, alter your routing table or temporarily lock you out of your router . A power cycle or hard reset should fix all of these issues in short order. If you are already willing to play with OpenWrt, you have already stepped past the bounds of normal use of a stock router. I also warn that the Linksys routers and router modification in general is a BIG topic and there is a lot to learn. This is as safe as I know how to make it, if you have further suggestions to make this foolproof they are most welcome.
Main rationale for the work:
OpenWrt is great, and I've only scratched the surface of what's possible with it. But the limits of a binary-based distribution are already too well-known to need comment; it is probably the reason many came to Gentoo in the first place! What we want to accompilsh is to have a usable experimental testbed allowing us to build newer versions of packages we want to work with. Since we can keep the "life-support" going on the router, and can fix nearly anything we do to the Wrt within the chroot, dangerous things like automating blocking of bad hosts, creating firewall rules on-the-fly or adding dynamically to hosts.deny cannot potentially lock us out of our own router as easily, if we do someething really dumb, or if a script goes awry.

Moving along then...
For the purposes of this HOWTO, I would divide this installation into 3 primary stages: bootstrap, minimal, and gentoo-base. These are preceeded by a preparatory step, in which we emerge, configure and set up our cross-compilation environment, and install OpenWrt itself on the router. This HOWTO will cover the preparatory step and bootstrap of the cross-compiler, as it is in actual fact the largest part of the whole task, the rest is largely experimentation and getting used to watching emerges fail This is intended as a work-in-progress. It is my hope that others will be interested in doing this for themselves, will follow, expand on, and correct what I lay out here, and can advance further into making this a serious application. Some of this will be elementary to people experienced with OpenWrt, but quite frankly I don't care, as this is intended to be a tutorial that anyone reasonably experienced in Linux should be able to follow even if OpenWrt is new to them.

Preparation: Installing OpenWrt.

OpenWrt is a fairly straightforward install if you know what you're doing and are comfortable with makefile-based build environments like the uClibc buildroot provides. It's (in my opinion!) not nearly as nice as an ebuild but it does get the job done. I am not going to attempt to teach how to work with OpenWrt and configure it and assume either A) you've done that, been there before or B) you'll learn about OpenWrt later, right now I want to see Gentoo on a router. I'll try to cover the minimal knowledge of OpenWrt which is needed to make it through the HOWTO, and the remaining configuration and customization is left to your discretion.

For OpenWrt, we have two basic options:
a) Install a pre-compiled kernel and core filesystem, and download prebuilt packages from official and/or unofficial OpenWrt sites.
b) Download and install the OpenWrt buildroot, configure and compile the kernel and critical maintenance filesystem ourselves, and selectively compile our own packages, installing them locally to the user-writable file system provided by OpenWrt.

Now make the buildroot. This should be as easy as 'make menuconfig' if you want to customize it, then 'make' to build the cross-compile toolchain, kernel, and the apps you chose. You don't need to configure much of this as it comes with a usable defaults, but may wish to activate busybox features, kernel abilities etc which are not enabled by default. Again, OpenWrt's defaults are chosen to provide a stable system so don't mess around too much unless you know what you're doing. I'd never worked with a WRT54GS before so I left most of this alone. OpenWrt will take a long time to build, I let it run overnight so I don't know exactly how long - it was well over 2 hours on my 1.6Ghz Pentium-M.

A few words of advice on configuring the OpenWrt are in order here. Packages you install are going into a user-writable area of flash memory on the Wrt, and this won't matter for our install, but these machines have quite limited RAM (16MB or 32MB). When you have your router chrooted to Gentoo, you're going to need all the memory you can muster and then some, so be stingy with what you load it up with, because those daemons will add up and eat RAM you're going to badly need later.
http://wiki.openwrt.org/OpenWrtDocs/Installing provides a comprehensive overview of the process of installation which applies to either a stock OpenWrt or one you've compiled from sources to an image file which is now available in your local buildroot. You can now install this to your Wrt, via the recommended tftp method. If you choose this way, ensure you have a proper tftp, which is in portage:

Code:

emerge net-ftp/linksys-tftp

.

Before going any further, it is very important that two conditions are met before you try to flash the firmware:
1) The soon-to-be OpenWrt box (our target) is disconnected from your Internet connection or any feed from another router providing such.
2) You have a direct, physical network connection - i.e. a piece of CAT5 cable - between your Gentoo box and the target router.
Under no circumstances should you attempt to do this over a wireless connection. Follow the recommended practices for firmware upgrade found in your router user manual, or do not expect sympathy or help from me, the OpenWrt community, or Linksys/Cisco if it screws up and... brick!

Using tftp is a bit tricky and the details can be found at the OpenWrt site. You must be sure to set the option "boot_wait" in NVRAM. Unfortunately you must "r00t" your router to do this or anything else with it! The easiest way to do this is to use the script I found here: www.topfx.com/dist/wrt54gcli.pl. It's a nice little perl script and you'll need a few basic libraries installed to use it, including Term::ReadLine and LWP. Depending on your router firmware version, this script may not work for you without some changes. I first used it on my primary router which is v4.2 stock firmware, in which Linksys patched the bug the script exploits (command injection into an unsecure HTML form that accepts backticks in its input) but left it open to a slight variant. I also was annoyed by the lack of a "quit" option in this fake shell, so I patched a simple option in for this:

Now reboot or power-cycle the router (i.e. yank the power, and plug it back in so it boots up again). Run the script again, and type:

Code:

/usr/sbin/nvram get boot_wait

You've now assured yourself that boot_wait is really set, and the setting will survive a reboot which might be required if you mess up.
Now you can follow the instructions at the OpenWrt site and tftp your firmware to the router. But an easier method exists. So why go to all that trouble? Without boot_wait set, unless you have a JTAG, if something goes really wrong, you now have a $50-70 brick. With boot_wait set you have at least a prayer if something goes wrong in trying to reflash the firmware, and can probably tftp in a fixed image.
Assuming you've got stock firmware, you should be able to use the standard "Firmware upgrade" utility of the router to do the dirty work of reflashing the firmware with your new image. I'm the paranoid sort, so I downloaded a compiled OpenWrt that I knew would work on my router and flashed it with the web interface after doing the boot_wait trick. If you do the same, you can then follow the instructions on the OpenWrt site to reflash from the command line (or try the web interface, I have not tested this). To do that, copy the proper firmware version's .trx file to your router (put it into the /tmp directory) and do:

Check your nvram setting of boot_wait if you're paranoid. It's still there. Reboot. The router will leave maintenance mode and will fire up a dropbear SSH server, plus do a lot of clever tricks to the filesystem. Relax, you're almost done with the router for awhile! When it comes back online (watch the router's LEDs for a status indicator, and give it a few minutes to do its thing), ssh into the box, and take the last few steps required.

We'll only be using the client features of NFS, so no further configuration should be required on this end. On the Gentoo host, ensure that NFS is supported by the kernel and that the NFS server is set up correctly. You need to prepare a directory where our Gentoo install will reside, and (optionally) you'll need to share out /usr/portage to, if you intend to do any compiling on the router itself. In this case, /etc/exports should include something like:

Reload your NFS to recognize the new shares, and the build host is ready for the router to connect. Now we need to prepare the build host and set up our cross-compiler.

Bootstrap: Setting up the MIPS cross-compiler.

You will need to set up a cross-compiling environment. It is not a task for an inexperienced linux user nor someone who's never personally used a compiler to try this stuff. My introduction to cross-compiling was patching by hand and scouring newsgroups and googling like mad as things broke, applying patch, re-compile, test, rinse lather repeat, on cygwin of all things, to eventually arrive at an ARM XScale cross-compiler for my Sharp Zaurus 5600. Fortunately the fine folks of Gentoo have made this a much less traumatic process for us now, with crossdev.

Ensure you first have crossdev as well as a full compilation toolchain installed. That's an easy task.

Code:

emerge crossdev

Now comes the tricky part. Crossdev is configured out-of-the box to build a serviceable cross-compiler but it will be totally unoptimized when we use it to build for our target architecture. On a little 200Mhz processor like the mips-based Broadcom chip in the WRT54G series of routers, this simply isn't going to be acceptable. Instead, we want to use a proper uClibc setup. Fortunately there is a perfectly good config sitting in the OpenWRT buildroot, either your custom configuration which is now sitting in the buildroot /staging directory, or the default uClibc for the platform, found at /opt/cross/openwrt/rc4/toolchain/uClibc/files/config.mips in our example.

As of version 0.9.28, the uClibc ebuild has an unsupported feature allowing us to use a pre-existing uClibc config file. This is precisely what we're going to do to get an optimized cross-compiler for our router's little-endian 32-bit mips CPU. Following the instruction provided by the ebuild, we copy this config file into the appropriate place.

I also tried pregenerated locale data as an experiment, hoping to speed up the compilation a bit, but setting that up is beyond the scope of this tutorial. Set your locales if you wish, otherwise take out the "userlocales" setting in package.use above. Now, at last, we are set to build our cross-compiling toolchain. Be sure to specify the proper kernel headers - RC4 runs on 2.4.30 so that's what I wanted to use. Unfortunately mips-headers as of this writing go only to 2.4.28 and are masked. I decided to sandwich the mipsel headers in case a newer version was or later became available, adding a constraint to unmask all 2.4.xx headers:

Crossdev will take care of adding the remaining entries to your portage configuration. We are not using the existing OpenWrt's uclibc in any way, so emerge whatever version crossdev gives you, and either back it down with a package mask if it breaks or tell crossdev which version it should emerge if it becomes a problem. the UCLIBC_CPU option is probably not needed, it is paranoia since I have a UCLIBC_CPU setting already in my global make.conf and didn't want to bother guessing whether the ebuild gave "savedconfig" or make.conf higher priority.

which should generate your cross-compilation toolchain, make an appropriate overlay, install the toolchain at /usr/mipsel-unknown-linux-uclibc, do the laundry and take out the garbage for you (ok, the last two are not true. but the script is pretty impressive even without them).

If it breaks...
If crossdev fails, all is not lost. You can go through the process manually and in so doing, learn to build a cross-compile toolchain yourself. It's fairly straightforward: with USE="nocxx" emerge binutils for the platform, emerge a bootstrap version of gcc, emerge the kernel headers, emerge uclibc, then build the full gcc with uclibc and kernel headers. On an ordinary (non-uclibc) toolchain build you would also do C++ support and compile the standard C++ library in a final 4th stage, which is how crossdev will do it. Figure out where crossdev failed and fix the problem (if feasible) rerun crossdev, or go back to that step and perform the rest manually:

Ok now, assuming that you now have a nice, shiny new cross-compile toolchain sitting in /usr/mipsel-unknown-linux-uclibc, there is (as is probably no surprise by now) more work to be done. To use the cross-compiler to build for our mipsel architecture, we need to be sure that emerge is operating under the right conditions, which will ensure we're building packages optimized for the Wrt.

Now, we will require a cross-compiling environment for our toolchain to play in.

To do this, basically we must write a wrapper around emerge which will set up our portage variables appropriately. It's not hard but requires some knowledge of how portage works "under the hood", the coding itself is trivial and consists of setting environment variables, to ensure we override our normal make.conf. The annoying part is that portage will stick all of our USE flags and other settings into the build for us, which will wreck our nice and simple USE flags with things like X, gnome, kde, and other things that are worthless to us. I had to temporarily comment out my USE flags in make.conf at one point. Eventually I wrote a script to help me with this process by altering make.conf for me when doing cross-compiles, but that is a topic for another post and it's still VERY alpha code. Here's an example wrapper:

This will wrap emerge with the proper variables needed by the cross-compiler. Some of the options may not be self-explanatory:
ARCH="mips"
The generic architecture is "mips" not "mipsel". We must tell the compiler we're little-endian in our CFLAGS

ACCEPT_KEYWORDS="~mips -mips"
We are an experimental build, and many things are still in testing on this architecture. Be careful though, since we are here unmasking everything which is hard-masked against MIPS. If this gets too annoying, take it out, but then you'll need to supply unmasks yourself, then back them out of your /etc/portage/package.unmask and keywords, which is almost more annoying.

CFLAGS="-march=mips32 -mtune=mips32 -LE -Os -pipe -fomit-frame-pointer"
This is the all-important part. -pipe is almost always a good idea, and it is safe to use omit-frame-pointer on this architecture, but I would not get crazy with optimizations here. -Os makes the most sense, this is a small processor with a relatively low amount of memory and -Os will probably outperform -O2. No comments on -O3, -O4 or -Oricer type settings. the arch and tune settings may be redundant. Without -LE nothing will work, this tells gcc that it's building for little-endian machines.

CHOST="mipsel-unknown-linux-uclibc"
This is absolutely required so that portage knows what architecture it's emerging for, hence uses the right cross-compiler. In some cases you may need to stick in CTARGET with the same value. In other cases CTARGET will break things.

USE="make-symlinks userlocales savedconfig uclibc uclibc-compat minimal buildpkg"
This is a totally mnimal set of USE flags on purpose, and is intended to feed the initial bootstrap. You'll need to modify these as new packages get added but this is where we start. If for some reason you don't want to build tarballs, leave that off. "uclibc-compat" is completely optional and will slightly inflate your uclibc. It was part of the experiment of trying to use the stage3, which is compiled with uclibc 0.9.27, and may be left off if you don't need compatibility - I did my initial bootstrap with 0.9.27.

UCLIBC_CPU="MIPS_ISA_MIPS32"
Discussed earlier, it's needed here as well since we'll be emerging this with the cross-compiler.

ROOT="/opt/cross/mipsel-uclibc"
I'm guessing you don't want to emerge mipsel binaries and libraries into your / directory. I started to worry that I'd forget to include the ROOT option, so I stuck it into the wrapper script to remove any doubts.

I also wanted to be able to override some of these variables if necessary, on a per-emerge basis, so that feature is included in the wrapper as well for several options, so if you want to get fancy and specify options at the command line, this script will allow that, and places them last for conflict-resolution purposes. Modify as you see fit,save with a convenient and easy-to-type (I called mine mipsel-unknown-linux-uclibc-emerge, which is neither), put it somewhere in your path, chmod +x, and you are all set.

We now have a router set up with OpenWrt, loopback and NFS support. We have a cross-compiling toolchain optimized for the router's CPU, and we have an emerge wrapper to supply a proper environment for portage to emerge. It's time to move into emerging the bootstrap, and testing out our bootstrap chroot environment from within OpenWrt.

Stay tuned...
Part 2 is coming. I would find it very surprising if there are not mistakes in the above text; I'll do my best to address concerns/issues that are unclear or the result of errors I made. Much of this was written from memory so something may have slipped by._________________Sager NP6165 | i7-3610QM | GeForce 650M
Gigabyte GA-880GMA-USB3 | AMD 1100T | Radeon HD 4250
MSI P6N-SLI | Q6600 | Sapphire HD 6870

Has anyone tried to install Gentoo on a WRT device such as a Linksys WRT54G? That's what I'm beginning to work on at the moment and if anyone has successfully accomplished it any/all advice is greatly appreciated.

please reformulate this and your topig giving more details...
that would make think people that you doesn't want to have a full fetured desktop distribution on a router

but gentoo would be great for such devices
because actualy you have a choice between consistent distributions
that means that you have a compatrison tab and you must choose the one that fit most of your need

mabe you should create some docs about your atempt...and mabe tools for choosing what to "emerge"(cross compiling) on the router
and i wonder how web front-end are created...

why not making it a gentoo project at the end if it produce some interesting stuff?
(such as GNAP)

I agree completely, it is in fact why I tried this. Again, if you want a "quick fix" to see what might be possible, go and grab the stage3 tarball from gentoo-embedded, set it up in a chroot NFS similar to what I was describing earlier and a bit in the (unfinished) HOWTO, and see it for yourself.

Quote:

because actualy you have a choice between consistent distributions
that means that you have a compatrison tab and you must choose the one that fit most of your need

exactly. I can see many applications for the 'hobby hacker' interested in security automation, or captializing on Gentoo hardened and GLA security patches, or simply a hobbyist interested in emerging the 'latest and greatest' builds of things already in OpenWrt.

Quote:

mabe you should create some docs about your atempt...and mabe tools for choosing what to "emerge"(cross compiling) on the router
and i wonder how web front-end are created...

I'm not the original poster you addressed, but I made a hopefully decent initial attempt at showing how you might go about this. Anyone experienced with embedded will be able to springboard from here, and when I have time to spare, I'll write up the second part. And hopefully receive some feedback to incorporate after people have a chance to mull this over and experiment if they're so inclined.

Quote:

why not making it a gentoo project at the end if it produce some interesting stuff?

Yes. That would be great in fact. But I don't know if the gentoo-embedded folks would embrace it and certainly not standard gentoo devs, but I'm sure there are people out there who've at least had the same "what if..." sort of thoughts, and futhermore people with more experience than I have with embedded development. For now it would be a small group of dedicated hobbyists.

Quote:

(such as GNAP)

Yes. I had considered GNAP as a base for this actually. Gentoo is designed in such a way that you could make a very specialized bit of router software/firmare, turning it into a custom-tuned small computer with a specific purpose it is focused around, and people could share their 'emerge recipes' or combinations of software packages that work for this purpose. There is also nothing confining this to an NFS chroot, the intention is to provide an experimental platform, with little to no risk to the hardware, until we have a stable build, then nothing prevents altering the firmware or experimenting with alternate kernels eventually. It would however be suicidal to try that immediately. My immediate goal is to allow anyone to replicate what I've already done._________________Sager NP6165 | i7-3610QM | GeForce 650M
Gigabyte GA-880GMA-USB3 | AMD 1100T | Radeon HD 4250
MSI P6N-SLI | Q6600 | Sapphire HD 6870

if my memory is good the wrt54 use the 43xx chip
broadcom 43xx driver are avaliable in portage
They will be avaliable in the 2.6.17 kernel
(there are also the chip of airport extreme)

i think you'll need to work on the memory footprint for gentoo
we need to test the memory footprint and the performance overhead(for example between -O2 and -Os (there isn't that much difference between O2 and O3 and i had Kdevelop break with O3 and not with O2))

you also need to compare the compressions such as:
-jffs2
-squashfs

there was a paper on the net for the squashfs and others standard compression filesystem

I don't know if using unionfs is a good idea because of the problems asociated to this thing

Hi,
Just to let you know that I appreciated you post very much. I have a large interest in Linux Embedded. I have successfully modified two X-BOXes to run Gentoo, and am working on getting a GameCube to run Gentoo as well. Of course, the GameCube is rather difficult since the network adapter causes such a huge bottleneck.

Having said that, I wish to tackle Gentoo on my ASUS WL-500g Premium. I have two USB ports at the ready on this device, although I will probably build over NFS, or even NBD to create my system. I am going to start with OpenWRT buildroot as a stepping stone into an embedded system for the router. Then I plan to follow the information you have given here to get it running some components of Gentoo, while using the least amount of resources. If DD-WRT (which I am currently using) can occupy only 4MB of RAM when being used, then maybe I can get everything I want running under Gentoo inside about 16MB of RAM, with all my packages, and some swap space just in case on a 2GB USB stick.

I appreciate your post so very much. I'm glad to know I'm not alone and that I don't have to start at square one like you did. I would be that keen to start there, so again thanks for saving me.

Michael Cassaniti_________________Need assistance with any of the following? Just PM me and I will see what I can do

freewrt is a modular firmware for routers
you can make your own squashfs or jffs2 image with the busybox option of your choice and the packages of your choice
gentoo desktop isn't enough modular for such embedded thing because busybox comes without all the option you want or don't want.
so if we want a modular distribution we could look at Freewrt and merge both gentoo and Freewrt...

i've a stupid question...is the source code of the packages changed for openwrt or freewrt in order to have a smaller footprint?
in the case we should have a different repository...

i'd love to have gentoo packages on my wrt54gs such as openssh with skeys or use flags for the packages
FreeWRT already has a similar system giving the choice of different packages with support for different database or systems
for example snort can be compiled with:
-debug
-inline
-mysql
-portgres sql

I agree that FreeWRT or another firmware might be a better solution nowadays... it was over a year ago since I did the original experiment w/OpenWRT, and I used what was available at the time. NFS mount of a stage3 mipsel could easily be performed with any number of base firmwares without a great number of changes, via a similar method - in fact any firmware that has NFS and loopback support to mount a disk image for swap should do the trick. Luckily there are more powerful routers out there now which contain niceties like USB/CF support and the like which may make this whole process unnecessary, ... but it will still work.

My memory may be a bit foggy, and I've been inactive here for several months (looks like I need to update my sig too ), a few inquiries about this project aside, but I'll offer what assistance I can here or via PM and have corresponded with a handful of people since writing the original HOWTO. I did end up with a cross-compiled OpenSSH from Gentoo portage incidentally (via cross-compiler with a ROOT= prefix, onto the NFS mounted root), along with a handful of other packages, but never got to bootstrapping a kernel, also python bootstrap compiles itself with python at one point, and thus would not support cross-compiling (as of 2.4.2 anyway), so stock portage on Wrt54G was a wash -- "emerge system" is impossible without python. Also there were some issues with the (now) old uclibc version I was using, but it's difficult to know how far an active project like that has come since I tried this. Unfortunately an untimely hard drive crash and finishing a masters' degree interfered with taking it much further at the time - a full-time job later, and the rest is a blur though I hope to return to it again. It's all rather academic until we can actually get to a gentoo base emerge system, then think about a kernel and the necessary jffs2/squashfs utilities to bootstrap ourselves and our fresh new kernel into the flash and move off the NFS root._________________Sager NP6165 | i7-3610QM | GeForce 650M
Gigabyte GA-880GMA-USB3 | AMD 1100T | Radeon HD 4250
MSI P6N-SLI | Q6600 | Sapphire HD 6870

abandoning is a bad idea and that wasn't what i meant
but Working in coordination with FreeWrt is a better idea and could be great for both them and us
because FreeWRT is a gentoo-like firmware adding some little things such as:
*more package =>benefit for both
*having a gentoo-ish configuration such as configuration in /etc/conf.d/ and using the gentoo baselayout could be great
*improoving their build system to suport use flags and similar(they have already basic support for that)

at the end we could have a firmware where you could choose between the gentoo way and the FreeWRT way

the thing that we must keep in mind is to stay embedded because there are devices that work without an external filesystem while supporting an external filesystem as an option(could be ram or usb or network filesystems)

we should also offer the option of compiling the kernel ourselves in order to support not common things such as:
->the linksys devices that has a pc-card or pcmcia interface for the nozimi card...we could add any other cards and add their drivers such as usb2.0 cards,Gigabit cards...others wireless cards
->the routers with a mini-pci card...here we could support others cards such as ralink ones with the rt2x00 driver in ap mode(the problem here is that mabe it's broken in the last git relase...i wasn't able to get help on the irc because i don't know if the interface that is ra0 correspond to the old wlan_master0 one)
->add support for a lot of usb devices such as network cards

abandoning is a bad idea and that wasn't what i meant
but Working in coordination with FreeWrt is a better idea and could be great for both them and us
because FreeWRT is a gentoo-like firmware adding some little things such as:
*more package =>benefit for both
*having a gentoo-ish configuration such as configuration in /etc/conf.d/ and using the gentoo baselayout could be great
*improoving their build system to suport use flags and similar(they have already basic support for that)

at the end we could have a firmware where you could choose between the gentoo way and the FreeWRT way

the thing that we must keep in mind is to stay embedded because there are devices that work without an external filesystem while supporting an external filesystem as an option(could be ram or usb or network filesystems)

we should also offer the option of compiling the kernel ourselves in order to support not common things such as:
->the linksys devices that has a pc-card or pcmcia interface for the nozimi card...we could add any other cards and add their drivers such as usb2.0 cards,Gigabit cards...others wireless cards
->the routers with a mini-pci card...here we could support others cards such as ralink ones with the rt2x00 driver in ap mode(the problem here is that mabe it's broken in the last git relase...i wasn't able to get help on the irc because i don't know if the interface that is ra0 correspond to the old wlan_master0 one)
->add support for a lot of usb devices such as network cards

by the way i realy wait for a firmware that can offer a 2.6 kernel with the broadcom cards with the 43xx driver.,..
do you know if it's already possible to have the master mode with theses cards?
because openwrt has 2.6 branches that have been relased but within theses branches the wireless doen't work

Neither did I, sorry if I came across that way. I was just pointing out that we're by no means bound to OpenWrt, it was just the means to an end at the time. FreeWrt sounds like a fairly natural match, being a source-based distribution itself.

Quote:

but Working in coordination with FreeWrt is a better idea and could be great for both them and us
because FreeWRT is a gentoo-like firmware adding some little things such as:
*more package =>benefit for both
*having a gentoo-ish configuration such as configuration in /etc/conf.d/ and using the gentoo baselayout could be great
*improoving their build system to suport use flags and similar(they have already basic support for that)

I was more interested in a Gentoo approach than a Gentoo-ified approach but there are other options including collaboration with an existing distribution to give a more Gentoo-like feel to working with it (as opposed to a modular but binary package-based approach like OpenWrt)

The Gentoo baselayout and init script style would certainly be more comfortable to a Gentoo user, albeit that the gentoo enthusiast interested in tiny embedded systems like WRT series is quite a small niche. My own view is, once you have a toolchain and the basic gnu libraries, you can build most anything that would be feasible or of interest for this platform's constraints. One cross-compiler toolchain allowed me to build a miniature system of [busybox/uclibc/dropbear/net-tools/wireless-tools] which is a very minimal set of packages , surprisingly functional but very far from a useful firmware on its own.

I absolutely agree with you about the need to stay on the 'embedded' side of things, and that the ability to compile a kernel is wholly necessary and would allow unprecedented flexibility for different hardware configurations (also including router hacks like SD card driver, etc that people have pulled off). Personally though, I don't want to compile on a 200Mhz broadcom chip any more than I absolutely have to, and favor a distributed approach like distcc with wrapper scripts. Meaning it would be totally dependent on the buildhost even after it was deployed, and would require a way to ensure that necessary system libraries stayed in sync between the host (building libraries to link against for cross-compilation) and target system (for which native libraries are built by the cross-compile process).

Quote:

by the way i realy wait for a firmware that can offer a 2.6 kernel with the broadcom cards with the 43xx driver.,..
do you know if it's already possible to have the master mode with theses cards?
because openwrt has 2.6 branches that have been relased but within theses branches the wireless doen't work

I was never involved with the project but know that Kamikaze has been around for quite awhile yet it's remained unreleased till recently (apparently Kamikaze was an apppropriate name in the early days, if you were sans JTAG [as I am]). I do remember seeing early 2.6 kernels for WRT series... maybe some day Broadcom would make wireless drivers available for 2.6 but until they do or someone re-engineers a driver for it (i.e. the 43xx driver project you mentioned), we the unwashed masses are out of luck. Rather like Sharp Zaurus, where OpenZaurus was stuck using 2.4 kernels forever due to lack of a new SD card driver, until someone wrote one from scratch. Yet another stroke in favor of open source I guess

No I haven't had a chance to play with FreeWrt yet. Have you successfully compiled python with its cross-compiler? I couldn't do so with my cross-compiler toolchain back when I wrote this howto, so assume it would still have to be done natively. Otherwise no python bootstrap, thus no python, thus no portage. Since python compiles and runs python to build python in its build process

GNUtoo wrote:

Quote:

Personally though, I don't want to compile on a 200Mhz broadcom chip any more than I absolutely have to

Hi,
Sorry it has been so long since my last reply. I was working on another project that is almost complete. I sucessfully installed FreeWRT to my ASUS router and found it useful enough. Problem with most of these WRT distros is that they all use a 2.4 kernel, and I need (yes need) a 2.6 kernel for some additional things I want my router to do.

Briefly, I want my router to do the following:

* Boot into a Linux based system that is simple to configure and does most of what the stock firmware does
* This system must contain kexec for mipsel, and a 2.6 kernel with the kexec system call
* A second system stored on a USB connected drive, with all the capabilities I want form a full Gentoo Linux distro

To implement the first point, I will use dd-wrt, which is, from my perspective, the Fedora of WRT distros. I will build a 2.6 kernel and kexec to go with dd-wrt, modifying the original image to fit these inside. Lastly, I will use another computer to load my Gentoo system from an external hard drive, and be able to use Gentoo on my router as if it was any other mipsel computer.

Because I want to be able to have the choice of either a basic distro suitable for a network appliance, and a full Gentoo distro, I have chosen to use kexec to switch between. If I wanted to have just the full distro, I could have made a firmware image that would boot my Gentoo system easily. I could have included the kernel and initramfs image within the firmware image (I have space enough), but I opted to keep these outside for a few reasons, one was to allow an easy upgrade of the Gentoo kernel without the need to reflash the firmware.

This thread seems to be looking at running Gentoo on the router as if it was any other mipsel based computer. Here I am looking at running both a network appliance setup (using dd-wrt) and Gentoo on the same hardware, but not simultaneously. I may later look more heavily into GNAP and embedded Gentoo, moving away from dd-wrt and across to a router that runs both systems as Gentoo. I still want to have an easy to configure system for the firmware image, one that uses either jffs or nvram to make changes to its configuration._________________Need assistance with any of the following? Just PM me and I will see what I can do