Tweet
Embedded Linux and Android are worlds apart. EL is still mostly a Linux system with a squashed boot loader, Android is targeted for a smaller footprint that needs to take CPU accounting and power profiles into account. I.e. while you can put OSS servers on Android, they have no awareness of the special considerations of the platform.
EL is much simpler, just a skinnier version of a normal server. In the case of routers, the platform is about as powerful as a ‘90s Pentium, but memory and I/O are much slower. Sacrifices to operate in a < 20W footprint. Luckily 32-bit ARM and MIPSel binaries are tiny by modern comparison. The largest binary I have is Perl and its all of 4 megs, where it’s upwards of 20 on x86 when built as monolithic. RISC CPU’s are great for embedded.
The build environment uses the existing ipkg system and the packages are built to altroot depending on if they are being included in the trx file or added post-flash to an external file system. So, I can just tick off the packages to include and they all are bundled into the firmware. In that case, you need configuration files. That presents some challenges. You can employ JFFS as part of the MTD layout and store configs there, mapped to /jffs or if the config data is small enough, NVRAM has a facility to write out files to /etc on boot. Easiest is if I know that there will be storage attached is to redirect config files to /opt. As of now, I don’t have plugins for the GUI menu system to configure the servers that I add, and they are text UI over SSH only.
Overlaying config files is sort of an art, as well, EL has a really crude init, so I usually keep my own that manages the firewall and is a bit more robust than what comes with the build environment.
As for the binary packages, this is the toughest part, because you are porting to a target that not every software project supports. You have to know a decent amount of programming in some cases to build the patches to compile, Apache, for instance.
In any event, it’s not a system that is flexible enough to switch between models of installation (stand alone, storage attached), so a new build needs to be made for when things change too much. The MTD is just too small to build a fully configured Linux system that is that flexible.
Otherwise, it’s just like configuring a normal Linux server, except that you have to use ebtables and vlan configurations more and need to know how to configure NVRAM for your uses.
But, you can Tl;dr this whole post and just install one of the firmware offerings from WRT, Tomato, DD and with relative confidence have a more stable system than from the vendor. I recommend Advanced Tomato if you want to get started. Just make sure to go to their list of supported devices to check and make sure what you want is listed.
EL is much simpler, just a skinnier version of a normal server. In the case of routers, the platform is about as powerful as a ‘90s Pentium, but memory and I/O are much slower. Sacrifices to operate in a < 20W footprint. Luckily 32-bit ARM and MIPSel binaries are tiny by modern comparison. The largest binary I have is Perl and its all of 4 megs, where it’s upwards of 20 on x86 when built as monolithic. RISC CPU’s are great for embedded.
The build environment uses the existing ipkg system and the packages are built to altroot depending on if they are being included in the trx file or added post-flash to an external file system. So, I can just tick off the packages to include and they all are bundled into the firmware. In that case, you need configuration files. That presents some challenges. You can employ JFFS as part of the MTD layout and store configs there, mapped to /jffs or if the config data is small enough, NVRAM has a facility to write out files to /etc on boot. Easiest is if I know that there will be storage attached is to redirect config files to /opt. As of now, I don’t have plugins for the GUI menu system to configure the servers that I add, and they are text UI over SSH only.
Overlaying config files is sort of an art, as well, EL has a really crude init, so I usually keep my own that manages the firewall and is a bit more robust than what comes with the build environment.
As for the binary packages, this is the toughest part, because you are porting to a target that not every software project supports. You have to know a decent amount of programming in some cases to build the patches to compile, Apache, for instance.
In any event, it’s not a system that is flexible enough to switch between models of installation (stand alone, storage attached), so a new build needs to be made for when things change too much. The MTD is just too small to build a fully configured Linux system that is that flexible.
Otherwise, it’s just like configuring a normal Linux server, except that you have to use ebtables and vlan configurations more and need to know how to configure NVRAM for your uses.
But, you can Tl;dr this whole post and just install one of the firmware offerings from WRT, Tomato, DD and with relative confidence have a more stable system than from the vendor. I recommend Advanced Tomato if you want to get started. Just make sure to go to their list of supported devices to check and make sure what you want is listed.
Comment