WiFi: HotSpot - OpenWRT cara Compile
Sumber: http://wiki.openwrt.org/doc/howto/build
Building OpenWrt
Pre-compiled images of the current OpenWrt release are always available, and easily found and downloaded from the OpenWrt website. These pre-compiled images are based on a default configuration, and only targeted at supported platforms/devices. There are several good reasons for why it is practical to build one's own images:
*
Custom configurations
*
Experimental platforms
*
Participation in testing and development
*
Or, simply keeping up-to-date
The best of it all is; that it in reality is quite simple to build an OpenWrt image. Prerequisites
Before you get started with the actual building a few practical details have to be in place; as with any other process of building the correct tools and materials have to be ready and at hand.
1.
A system for building the OpenWrt image
2.
Ensure that the needed dependencies are installed
3.
Copy of the OpenWrt source-code
First of all, you need to have access to a system which supports the building of OpenWrt. It is recommended to use a Linux system, either as a standalone installation or as a separate system running in a virtual environment (Vmware or Qemu). It is potentially possible to build OpenWrt images directly on a *BSD or Mac OSX systems, but success is not guaranteed. The following description assumes the use of a current Debian system which uses apt-get for package management. An alternative choice would be one of the Ubuntu variants (Kubuntu, Xubuntu etc.). Step two, is the practical installation of the needed dependencies, which includes compilers, unzip applications, specific libraries, etc. This is simply done by typing the following command (which normally requires root or sudo privileges) in your shell of choice:
- apt-get install g++ libncurses5-dev zlib1g-dev bison flex unzip autoconf gawk make
gettext gcc binutils patch bzip2 libz-dev libc headers asciidoc
Consult this Table of Correspondence in order to find your prerequisites.
Some of these dependencies might already be installed on the system, in which case apt-get will respond and ask what to do (ignore, re-install etc.). Finally, download a copy of the complete OpenWrt source-code to your build system. You have two choices: You can download the bleeding edge development snapshot (called "trunk") from svn, or you can download the latest stable release via ftp or svn.
If you want to download it via svn, you must have Subversion installed. Subversion, or SVN, is the current version control system used by the OpenWrt project, and it is quite similar to CVS in terms of interface and use. Again, this dependency is easily installed:
- apt-get install subversion
Obtain Source
When Subversion is installed, the simplest way to confirm that everything works as assumed is to fetch a clean copy of OpenWrt. First you create a new directory in which to store the source-code, then move to this new directory and issue the required Subversion command: Checkout Trunk
- mkdir OpenWrt
- cd OpenWrt/
- svn co svn://svn.openwrt.org/openwrt/trunk/
Before going ahead with the actual build process it is a good idea to take a look at the contents of the trunk/directory. Often it is just good to be able to compare the content of the directory before and after the actual build. Trunk is the current development branch and contains everything from documentation to experimental patches. Using Release Source
If you want to download the latest stable release, go here: http://downloads.openwrt.org/. As of this writing, Kamakaze is the latest release and I'll use that as an example only, choose the latest release there. As an example only, you might download and unpack this tar file:
- wget http://downloads.openwrt.org/kamikaze/8.09.1/kamikaze_8.09.1_source.tar.bz2
- tar -jxf kamikaze_8.09.1_source.tar.bz2
- cd kamikaze_8.09.1
Building in practice
The process of creating the correct image for your specific device consists of six simple steps:
1.
New check-out of trunk via Subversion
2.
Update package feeds - ./scripts/feeds update
3.
Build configuration – make defconfig
4.
Symlink packages and the build environment
5.
Configure the image(s) to build – make menuconfig
6.
Build command - make
Update Source
Since the OpenWrt development branch changes quickly over time, it is recommended to use the latest source. This is done with a short Subversion command:
- cd trunk
- svn up
Following this initial step it is needed to prepare and bring the build environment up-to-date. This first requires that the many package feeds are updated and made ready for use:
- ./scripts/feeds update
Then the downloaded packages need to be installed. The installation step means they will be available during the 'make menuconfig' step later. Without this step the packages are not selectable in 'make menuconfig'. Please not this step replaces the old method of creating symlinks, which can be still found on-line in many old forum and user-group entries
- ./scripts/feeds install -a
The feeds configuration file makes it easy to add new or experimental packages sources to the build system. Just edit the file and run the update command. Build Configuration
Next step, is to produce a general purpose configuration of the build system, this includes a check of dependencies etc.
- make defconfig
Should the defconfig command report an error about a missing dependency, then the problem is easily solved with installing the missing package and then run the command again.
Configuration of the image(s) you wish to build, based on the target platform at hand, is invoked by the menuconfing command:
- make menuconfig
As seen below, menuconfig is a text-based tool which handles the selection of target, packages to include in the build, kernel options etc. It has from the beginning on been the intention, with the development of 'menuconfig', to create a simple yet powerful environment for the configuration of individual OpenWrt images. Menuconfig is more or less self-explanatory, and even the most specialized configuration needs can be solved with its help. Depending on the the particular target platform, package requirements and kernel module needs, the standard process of configuration will include modifying:
1.
Target system
2.
Package selection
3.
Build system settings
4.
Kernel modules
Target system is selected from the extensive list of supported platforms, with the numerous target profiles – ranging from specific devices to generic profiles, all depending on the particular device at hand. Package selection has the option of either 'selecting all package', which might be un-practical in certain situation, or relying on the default set of packages will be adequate or make an individual selection. It is here needed to mention that some package combinations might break the build process, so it can take some experimentation before the expected result is reached. Added to this, the OpenWrt developers are themselves only maintaining a smaller set of packages – which includes all default packages – but, the feeds-script makes it very simple to handle a locally maintained set of packages and integrate them in the build-process. Source Mirrors
The 'Build system settings' include some efficient options for changing package locations which makes it easy to handle a local package set:
1.
Local mirror for source packages
2.
Download folder
In the case of the first option, you simply enter a full URL to the web or ftp server on which the package sources are hosted. Download folder would in the same way be the path to a local folder on the build system (or network). If you have a web/ftp-server hosting the tarballs, the OpenWrt build system will try this one before trying to download from the location(s) mentioned in the Makefiles . Similar if a local 'download folder', residing on the build system, has been specified. The 'Kernel modules' option is required if you need specific (non-standard) drivers and so forth – this would typically be things like modules for USB or particular network interface drivers etc. The final step before the process of compiling the intended image(s) is to exit 'menuconfig' – this also includes the option to save a specific configuration or load an already existing, and pre-configured, version.
If you want to use LuCI, you'll need to go to the Administration menu, then LuCI Components sub-menu, and select the first 3 packages: luci-admin-core, luci-admin-full, and luci-admin-mini.
If you don't need PPP, you can remove it by deselecting it under the Network menu.
Make sure you mark these packages as a '*' instead of just an 'M'. If you mark with a '*', the package will be built into the firmware you create. If you mark it with just an 'M', the package will be built but not installed.
Exit and save. Start Build Build image
Everything is now ready for building the image(s), which is done with a single command:
- make
Note: Compilation process could speed up by using more than 1 concurrent job process. e.g. to use 4 concurrent building jobs add -j4 option.
When the compilation has ended without errors the new image(s) are finished and can be found in the newly created bin/ directory.
- cd bin/
Build package
When developing or packaging a software in OpenWrt, its interesting to be able to build only desired package (e.g. with package cups):
- make package/cups/compile V=99
Cleanup
FIXME We need more explaination on clean targets (dirclean, target/linux/clean, package/name/clean, …)
Cleaning the trunk/ directory after the build process is simple and only requires:
- make clean
Note: It might be obvious to most people, but make sure to move the binaries to another location before issuing this command since it erases the contents of the "bin" directory, at least in OS X 10.5.8.
If complete cleaning of the build environment is required, then all what is takes is:
- make distclean
There a numerous of other functionalities in the OpenWrt build system, but the above should have covered some of the fundamentals. Installing OpenWrt
In comparison to the actual building of the desired image(s), the installation of the OpenWrt image can sometimes be a little, or more, of a challenge. The range spreads from a simple process of tftp firmware upload and reboot to extensive hardware modifications with the intent of enabling JTAG access. Though, generally installation is made possible via the bootloader (Redboot, Uboot etc.) or simple copying onto a CompactFlash-card – all depending on the specific device.