Kamikaze Installation

From X-Wrt

Jump to: navigation, search

Contents

[edit] Installing OpenWrt Kamikaze and X-Wrt

[edit] X-Wrt: A package

X-Wrt is an improved webif (webinterface) for OpenWrt Kamikaze which is identical to the OpenWrt WhiteRussian version. However, X-Wrt for Kamikaze is still in development and parts of is either lacking or slightly unstable. On the other hand, for the most part it is functional and able to meet the most common needs.

X-Wrt for Kamikaze is a single, and complete, package which can be installed with the appropriate ipkg commands, or alternative as part of a pre-compiled image.

[edit] WhiteRussian versus Kamikaze

It is the intent of the X-Wrt developers to keep the two versions of the improved webif as identical as possible. The underlying versions of OpenWrt, eg. WhiteRussian and Kamikaze, are completely different branches which makes this a challenge.

There are several major difference between the two versions of OpenWrt, and a few are listed here:

  • Move away from nvram variables to standard configuration files
  • Expansion of the supported hardware platforms (not just Broadcom: the complete list is here)
  • Move from 2.4 to 2.6 Linux kernel (except when wifi is needed on Broadcom/brcm)

This is a clear indicator that OpenWrt Kamikaze is aimed at being a much more versatile embedded system, not only an alternative firmware for wireless routers.

At the same time it is needed to state that OpenWrt Kamikaze is in rapid development and due to this not completely stable. The OpenWrt project has moved Kamikaze to official cycle of release versions, but there are still numerous bugs in the code.

It is recommend to check the OpenWrt site for the most up-to-date information on the current Kamikaze release.

[edit] Notes on hardware

OpenWrt Kamikaze supports a broad list of platforms which can be unfolded to an even longer list of specific devices

[edit] Broadcom and all the other platforms

The original target platform of OpenWrt was the various Broadcom based devices (brcm), such as common routers from Linksys, Asus, Buffalo and so forth. The Broadcom platform is relatively easy to work with, but relies to some extent on proprietary drivers. There are presently numerous alternatives to the Broadcom based devices, especially Atheros and Infineon chipsets have recently become popular amongst developers and manufactures.

[edit] Bootloaders:

  • CFE
    • Basic information on the Broadcom Common Firmware Environment, or CFE
  • MyLoader
    • This is an alternative bootloader used by Compex. More information here
  • ADAM2
    • ADAM2 is a bootloader for Texas Instruments AR7-based devices.
  • PSPBoot
    • PSPBoot is another bootloader used on TI AR7-based devices.
  • other (?)

[edit] Installing on new hardware

[edit] Broadcom

It is a normally quite easy to install Kamikaze (with and without X-Wrt webif) on Broadcom based devices (brcm), which include most devices by Asus, Belkin, Linksys, Buffalo, and others.

Go to the X-Wrt Downloads page, which contains the same images as on openwrt.org, but including the webif² package. Decide whether you'd like to use a 2.4 kernel (brcm-2.4) or a 2.6 kernel (brcm47xx-2.6 - see caveats below), download the pre-compiled image (openwrt-brcm-2.4-squashfs.trx for most purposes, but you might find a specific image for your device there) and use the existing firmware upgrade function to upload the image to your device. Check out the OpenWrt Installation docs for more details.

There are a few things to be aware of:

  • Wireless for brcm devices is only supported on the 2.4 kernel
  • The wireless interface is as default disabled
  • Remember to download the correct image for your device :-)
  • After installation remember to enable boot_wait (as shown here)

[edit] RedBoot Devices

RedBoot is a boot-manager for Atheros-based embedded routers/devices. While they can be less user-friendly than Broadcom devices, there remains no easy point-and-click solution to installing OpenWrt Kamikaze. However, RedBoot offers several (possibly complicated) extensions, but these devices are very flexible and powerful so it can be worth the time invested in learning them.

RedBoot must be configured before installing Kamikaze. Refer to the following links for information and utilities needed for the following instructions.

[edit] Initial RedBoot setup

The number of Atheros 'System on a chip' (SoC) based routers are increasing, the most common are still the various Fonera versions or the Meraki Mini. Both are oem products manufactured by Accton, and Accton has just released the MR3202A model which from the outside seems to be identical to the Fonera+ (with two ethernet ports).

The different FON and Meraki devices, with Atheros SoC, use the RedBoot bootloader and have either 4/16 or 8/32 MB of Flash/RAM and the default firmware is in both cases based on OpenWrt. It is fairly easy to substitute the existing system with the current OpenWrt Kamikaze release. The initial step required to install OpenWrt Kamikaze on these devices is the configuration of the RedBoot bootloader. It is possible to re-flash these devices without changing the bootloader configuration, but it is not recommended. The argument is quite simple: Recovery from a firmware re-flash gone bad is only possible if RedBoot is setup to accept "inquiries" before boot of the system, from the flash chip. Apart from this, the size of the kernel of Kamikaze has changed so it is needed to alter the layout of the partitions on the devices. Such re-partitioning is done with the help of RedBoot. The following section is partly based on an edited translation from Freifunk-Hannover.

[edit] Configuring RedBoot access

[edit] SSH

[edit] Fonera

Fonera routers have SSH disabled by default so you will have to use one of the following techniques depending on the firmware version on the specific router. This list is not complete.

[edit] Meraki

The Meraki Mini requires no extra configuration. It has SSH access enabled by default and its RedBoot comes setup with boot_wait.

[edit] Serial Console

To get serial console access to RedBoot you will have to stop the boot sequence. This is done by a quick CTRL+C immediately after the Fonera is powered on. Refer to the OpenWRT wiki for further instructions.

Once you see the RedBoot prompt, use the following configuration, substituting your own IP addresses if desired: 

RedBoot> fconfig bootp_my_ip 169.254.255.1
RedBoot> fconfig bootp_my_ip_mask 255.255.0.0
RedBoot> fconfig boot_script_timeout 10
RedBoot> reset

These commands define the IP address and netmask of the router and sets a waiting time between the boot loader coming up and the device itself booting. Reboot the device to enable these changes.

[edit] Telnet

Details on how to telnet into RedBoot are found in the OpenWrt Wiki

[edit] Ethernet

There are a few tricks for getting access to RedBoot via Ethernet without a serial connection. With the system up and running you can patch the configuration of the RedBoot bootloader by overwriting the existing configuration with one enabling a boot delay. During this wait the device can be accessed via telnet at 192.168.1.254 Port 9000.

As with SSH access, the firmware version of your Fonera determines how you can enable Ethernet access. For firmware versions later than 7.1, use the following RedBoot config. This can be done with a direct download as shown below, or by using SCP to place the out.hex file in the /tmp directory. 

root@OpenWRT:~# wget http://ipkg.k1k2.de/hack/out.hex
root@OpenWRT:~# mtd -e "RedBoot config" write out.hex "RedBoot config"
root@OpenWRT:~# reboot

For Fonera firmware revisions prior to 7.1 you will have to install a patched kernel to enable write access to the flash chip and RedBoot configuration. 

root@OpenWRT:~# wget http://ipkg.k1k2.de/hack/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
root@OpenWRT:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
root@OpenWRT:~# reboot

[edit] Installing on RedBoot devices

[edit] AP51-EasyFlash Utility

There are two versions of the AP51-EasyFlash Utility, respectively for Windows and Linux. The following example is utilizing the Linux version, on a Debian system. The above mentioned enabling of RedBoot access via ethernet is required for this procedure.

Before proceding to the actual installation it is needed to download the AP51-Easyflash utility and the pre-compiled files which are to be flashed onto the Atheros SoC devices (both Fonera and Meraki Mini). After downloading the correct files (a kernel and the needed root-file-system) they are placed in the same directory as the flash utility.

The Easyflash utility has to be executable, and to ensure that the various interfaces are active it is recommended to use either a cross-over cable or a switch. The Easyflash syntax is quite simple: 

root@Debian:~# ./easyflash eth1 openwrt-atheros-2.6-vmlinux.lzma openwrt-atheros-2.6-root.squashfs

It simply says; run the program while using the indicated interface and upload/flash with the mentioned files.

[edit] Manual flashing

It should be possible to re-flash Fonera devices with firmware versions above 7.1 directly - but, it should always be done with a bit of caution, and only after having enabled ethernet access to the RedBoot bootloader (in case of having to recover the device.

The actual process of manual re-flash is probably something which is more aimed at users who already have a current Kamikaze system installed. Then the process is as follows: 

root@OpenWRT:~# wget http://downloads.x-wrt.org/xwrt/kamikaze/7.09/atheros-2.6/openwrt-atheros-2.6-vmlinux.lzma
root@OpenWRT:~# wget http://downloads.x-wrt.org/xwrt/kamikaze/7.09/atheros-2.6/openwrt-atheros-2.6-root.jffs2-64k
root@OpenWRT:~# mtd -e vmlinux.bin.l7 write openwrt-atheros-2.6-vmlinux.lzma vmlinux.bin.l7
root@OpenWRT:~# mtd -e rootfs write openwrt-atheros-2.6-root.jffs2-64k rootfs
root@OpenWRT:~# reboot

[edit] Flashing with RedBoot

You can access the device using the serial or the telnet connection. Both methods use the similar RedBoot command except that you will need to append the -m <protocol> parameter to the load command when using the serial (or the http) connection.

[edit] Serial access

You need to setup the highest serial port speed first to be able load files in a reasonable time. If your terminal application does not feature the automatic speed detection, set the new port speed after the update your settings prompt. If you will not manage to change it in about 5 seconds, the speed setting returns back to the previous value.

Do not update the RedBoot non-volatile configuration after setting the serial port speed if you have not compiled your own kernel with modified console settings. 

RedBoot> baudrate -b 115200
Baud rate will be changed to 115200 - update your settings
Baud rate changed to 115200 - continue (y/n)? y
Update RedBoot non-volatile configuration - continue (y/n)? n

The redboot features only the xmodem or the ymodem serial protocols. You will need to append your preferred protocol in the subsequent load commands (-m ymodem or -m xmodem).

[edit] Telnet access

Setup with a switch or router between a computer and Fonera, as a way of ensuring active network-interfaces. If you have problems with hitting the right connection window, then use this Perl Script instead. 

perl redboot.pl <fonera_ip>

You can also use other methods for establishing the telnet connection. One example would be the Telnet Into RedBoot NSLU2 wiki article.

When the telnet connection is established you will se the RedBoot prompt: 

RedBoot>

Hereafter it is easy to configure your router's address, the subnet mask and the address of the TFTP/HTTP server. 

RedBoot> ip_addr -l 192.168.1.254/24 -h 192.168.1.23
IP: 192.168.1.254/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.23

[edit] Initialize the RedBoot's FIS

Initialize the RedBoot's Flash Image System by the command: 

RedBoot> fis init

You can list the flash image directory by the command: 

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xA8000000  0xA8000000  0x00030000  0x00000000
... available free space ...
FIS directory     0xA87E0000  0xA87E0000  0x0000F000  0x00000000
RedBoot config    0xA87EF000  0xA87EF000  0x00001000  0x00000000

Notice the free space between the RedBoot and the FIS directory entries.

[edit] Loading and flashing the kernel

Use the predefined alias %{FREEMEMLO} for the start of the free memory parameter and load the kernel image into the router's RAM. The meaning of parameters: -r - raw binary data, -v - verbose, -b - memory location, -m - the protocol: ymodem/xmodem or http or tftp (default is tftp when omitting the protocol parameter).

Serial: 

RedBoot> load -r -v -b %{FREEMEMLO} openwrt-atheros-2.6-vmlinux.lzma -m <ymodem/xmodem/http/tftp>

Ethernet: 

RedBoot> load -r -b %{FREEMEMLO} openwrt-atheros-2.6-vmlinux.lzma

Note: If you want to directly start the loaded kernel, you need to load it to the memory location 0x80041000 specified at the build time instead of the %{FREEMEMLO} alias.

The RedBoot will show you the used protocol: 

Using default protocol (TFTP)

Or when using the serial protocol: 

xyzModem - CRC mode, 6146(SOH)/0(STX)/0(CAN) packets, 3 retries

The RedBoot will show you also the information about loaded file after a successful download: 

Raw file loaded 0x80040800-0x801007ff, assumed entry at 0x80040800

You can verify the checksum and the length of the file in memory: 

RedBoot> cksum
Computing cksum for area 0x80040800-0x80100800
POSIX cksum = 2702583058 786432 (0xa1162512 0x000c0000)

against the original file: 

[root@tftpserver tftpboot]# cksum openwrt-atheros-2.6-vmlinux.lzma
2702583058 786432 openwrt-atheros-2.6-vmlinux.lzma

to be sure that the loaded file is not damaged and you are flashing the proper content.

Create the kernel flash image by the command (where -r - the load address, -e - the entry address, vmlinux.bin.l7 - name of the kernel image entry as used by the boot script): 

RedBoot> fis create -r 0x80041000 -e 0x80041000 vmlinux.bin.l7
... Erase from the actual flash memory addresses...
... Program from the actual flash memory addresses...
RedBoot>

You will have to wait approx. 1 min until the kernel has been written to the flash.

Note: The atheros-2.6 kernel is built with the load and entry address set at 0x80041000. After rebooting the IP address will be 192.168.1.1 (and not 192.168.1.254 as it was during RedBoot).

And verify the creation of the kernel image: 

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xA8000000  0xA8000000  0x00030000  0x00000000
vmlinux.bin.l7    0xA8030000  0x80041000  0x000C0000  0x80041000
...  available free space ...
FIS directory     0xA87E0000  0xA87E0000  0x0000F000  0x00000000
RedBoot config    0xA87EF000  0xA87EF000  0x00001000  0x00000000

[edit] Computing the remaining free space size

You will need to compute the remaining free space to use for your jffs2 partition. The size parameter is required for the rootfs creation command. If you do not provide the size parameter, there will be no space for the jffs2 partition and either the kernel will hang after booting unable to switch mini_fo to the jffs2 partition or your filesystem will be read only.

Use the fis free command to show the unused flash memory space: 

RedBoot> fis free
  0xA80F0000 .. 0xA87E0000

Use any calculator able to handle hexadecimal numbers and compute the difference between the end and the start of the free space (A87E0000 - A80F0000 = 6F0000). For example by using the command line arbitrary precision calculator: 

server:~# bc
obase=16
ibase=16
A87E0000 - A80F0000
6F0000

The emphasized text is the value of the size parameter for the image creation command below.

[edit] Loading and flashing the rootfs

Use the predefined alias %{FREEMEMLO} for the start of the free memory parameter and load the kernel image into router. Parameters meaning: -r - raw binary data, -v - verbose, -b - memory location, -m - the protocol: ymodem/xmodem, http or tftp (default is tftp when omitting the protocol parameter).

Serial: 

RedBoot> load -r -v -b %{FREEMEMLO} openwrt-atheros-2.6-root.squashfs -m <ymodem/xmodem/http/tftp>

Ethernet: 

RedBoot> load -r -b %{FREEMEMLO} openwrt-atheros-2.6-root.squashfs

The RedBoot will show you the used protocol: 

Using default protocol (TFTP)

Or when using the serial protocol: 

xyzModem - CRC mode, 6146(SOH)/0(STX)/0(CAN) packets, 3 retries

The RedBoot will show you also the information about loaded file after a successful download: 

Raw file loaded 0x80040800-0x803207ff, assumed entry at 0x80040800

You can verify the checksum and the length of the file in memory: 

RedBoot> cksum
Computing cksum for area 0x80040800-0x80320800
POSIX cksum = 229348867 3014656 (0x0dab9603 0x002e0000)

against the original file: 

[root@tftpserver tftpboot]# cksum openwrt-atheros-2.6-root.squashfs 
229348867 3014656 openwrt-atheros-2.6-root.squashfs

to be sure that the loaded file is not damaged and you are flashing the proper content.

Create the rootfs flash image using the previously computed free space size parameter (-l - the length of the image). Substitute your own value of the size parameter according to your free space size. 

RedBoot> fis create -l 0x6F0000 rootfs
... Erase from the actual flash memory addresses...
... Program from the actual flash memory addresses...
RedBoot>

You will have to wait approx. 4 min until the initial file system has been written to the flash.

And verify the creation of the rootfs image and its size (Length): 

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xA8000000  0xA8000000  0x00030000  0x00000000
vmlinux.bin.l7    0xA8030000  0xA8030000  0x000C0000  0xA8030000
rootfs            0xA80F0000  0x80040800  0x006F0000  0x80040800
FIS directory     0xA87E0000  0xA87E0000  0x0000F000  0x00000000
RedBoot config    0xA87EF000  0xA87EF000  0x00001000  0x00000000

Notice that there is no free space remaining in the flash memory.

[edit] Booting the new system

Load the kernel from the flash memory and execute it: 

RedBoot> fis load -l vmlinux.bin.l7
RedBoot> exec

or restart the router: 

RedBoot> reset

RedBoot's booting messages
kernel's booting messages

Please press Enter to activate this console.

[edit] Notes

  • The order of the vmlinux and the rootfs images is optional. This guide used the logical order as seen in most devices.
  • The RedBoot does not honour locking of an image. You are not protected against writing to the wrong memory addresses with the create command. Be sure not to use any of the hardcoded flash memory addresses from articles around the Internet. You might damage the RedBoot image.
  • Do not touch the RedBoot image in any case. All other parts of the flash image directory can be recreated by the RedBoot's commands. When you damage the RedBoot itself, you can revive the malfunctioning board only by using the JTAG cable.
  • You can use the CoreUtils binaries from the GnuWin32 project to be able to use the cksum in the Windows environment. See CoreUtils

[edit] Updating from WhiteRussian

An update from OpenWrt WhiteRussian to Kamikaze is a complete re-installation of the system, all existing configuration and setup will be erased.

The upgrade is easily done via the mtd command or the default OpenWrt webif - both work well.

When updating from WhiteRussian and wanting to use the X-Wrt webif package, it is advisable to use the pre-compiled firmware image based on the present Kamikaze release. These images - and you have to chose the correct image for your platform - are available from the X-Wrt Kamikaze download. You should choose an image from the most recent release directory.

In the case of starting out with a barebone Kamikaze install there is a small and basic instruction to commandline configuration here. The OpenWrt Kamikaze system is a very good learning platform, and it can only be recommended to teach yourself some of the common Linux/unix skills though direct interaction. Likewise, when you change settings through the X-Wrt webif try to login via SSH and take a look at the changes in the config files (just type less and the filename, and then 'q' when you'r finished reading)

[edit] Updating OpenWrt Kamikaze

In as much as the X-Wrt webif is a complete package it is conveniently added to an existing Kamikaze version through a simple set of ipkg commands, or just add the X-Wrt repository to the ipkg.conf list. the links which are listed in the various commands below, will over time have to be changed in accrodance with the release of new versions of Kamikaze (presently 7.09).

The examples below are both showing an installation of X-Wrt webif on a Broadcom device (brcm-2.4).

[edit] Changing ipkg.conf

I installed Kamikaze 7.09 on my WRT54GL and wanted the x-wrt web interface. So I added to the end of my `/etc/ipkg.conf`: 

src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/7.09/brcm-2.4/packages

My `/etc/ipkg.conf` now looks like: 

src release http://downloads.openwrt.org/kamikaze/7.09/brcm-2.4/packages
src packages http://downloads.openwrt.org/kamikaze/packages/mipsel
dest root /
dest ram /tmp
src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/7.09/brcm-2.4/packages

Finally I typed: 

root@OpenWrt:~# ipkg update
root@OpenWrt:~# ipkg install webif

[edit] Install X-Wrt manually

The X-Wrt webif depends on the Haserl package, so this has to be installed before the webif itself. In both cases the specific links are needed to point ipkg to the correct package. This requires internet access, but it is as alternative possible to SCP the packages onto the router (they should be placed in the /tmp directory). 

root@OpenWrt:~# ipkg install http://downloads.x-wrt.org/xwrt/kamikaze/7.09/brcm-2.4/packages/haserl_0.8.0-2_mipsel.ipk

Then afterwards you just need to type: 

root@OpenWrt:~# ipkg install http://downloads.x-wrt.org/xwrt/kamikaze/7.09/brcm-2.4/webif_latest.ipk

The installation of webif will automatically add the new X-Wrt repositories to ipkg.conf and run the 'ipkg update' command.

[edit] X-Wrt stable or daily builds

  • Currently there is not a stable kamikaze webif build, kamikaze webif status is here
Retrieved from "http://wiki.x-wrt.org/index.php/Kamikaze_Installation"
Personal tools