Category Archives: embedded

Using qemu-user to chroot and bootstrap other architectures on #FreeBSD

My last post spawned enough feedback that I thought I would dump some notes here for those interested in building a chroot on FreeBSD that allows you to test and prototype architectures, e.g. ARMv6 on AMD64.

The FreeBSD buildsys has many targets used for many things, the two we care about here are buildworld and distribution.  We will also be changing the output architecture through the use of TARGET and TARGET_ARCH command line variables.  I’ll assume csh is your shell here, just for simplicity.  You’ll need 10stable or 11current to do this, as it requires the binary activator via binmiscctl(8) which has not appeared in a release version of FreeBSD yet.

Checkout the FreeBSD source tree somewhere, your home directory will be fine and start a buildworld.  This will take a while, so get a cup of tea and relax.

make -s -j <number of cpus on your machine> buildworld TARGET=mips TARGET_ARCH=mips64 MAKEOBJDIRPREFIX=/var/tmp

Some valid combinations of TARGET/TARGET_ARCH are:

mips:mips

mips:mip64

arm:armv6

sparc64:sparc64

powerpc:powerpc

powerpc:powerpc64

i386:i386

amd64:amd64

Once this is done, you have an installable tree in /var/tmp.  You need to be root for the next few steps, su now and execute these steps:

make -s installworld TARGET=mips TARGET_ARCH=mips64 MAKEOBJDIRPREFIX=/var/tmp DESTDIR=/opt/test

DESTDIR is where you intend on placing the installed FreeBSD system.  I chose /opt/test here only because I wanted to be FAR away from anything in my running system.  Just to be clear here, this will crush and destroy your host computer without DESTDIR set.

Next, there are some tweaks that have to be done by the buildsys, so run this command as root:

make -s distribution TARGET=mips TARGET_ARCH=mips64 MAKEOBJDIRPREFIX=/var/tmp DESTDIR=/opt/test

Now we need to install the emulator tools (QEMU) to allow us to use the chroot on our system.  I suggest using emulators/qemu-user-static for this as Juergen Lock has set it up for exactly this purpose.  It will install only the tools you need here.

Once that is installed, via pkg or ports, setup your binary activator module for the architecture of your chroot.  Use the listed options on the QEMU user mode wiki page for the architecture you want.  I know the arguments are not straight forward, but there should be examples for the target that you are looking for.

For this mips/mips64 example:

binmiscctl add mips64elf –interpreter “/usr/local/bin/qemu-mips64-static”
–magic “x7fx45x4cx46x02x02x01x00x00x00x00x00x00x00x00x00x00x02x00x08″
–mask “xffxffxffxffxffxffxffx00xffxffxffxffxffxffxffxffxffxfexffxff”
–size 20 –set-enabled

Copy the binary qemu that you setup in this step *into* the chroot environment:

mkdir -p /opt/tmp/usr/local/bin

cp /usr/local/bin/qemu-mips64-static /opt/tmp/usr/local/bin/

Mount devfs into the chroot:

mount -t devfs devfs /opt/tmp/dev

Want to try building ports in your chroot?  Mount the ports tree in via nullfs:

mkdir /opt/tmp/usr/ports

mount -t nullfs /usr/ports /opt/tmp/usr/ports

And now, through the QEMU and FreeBSD, you can simply chroot into the environment:

chroot /opt/tmp

Hopefully, you can now “do” things as though you were running on a MIPS64 or whatever architecture machine you have as a target.

arm:armv6, mips:mips, mips:mips64 are working at about %80-90 functionality.  powerpc:powerpc64 and powerpc:powerpc are still a work in progress and need more work.  sparc64:sparc64 immediately aborts and probably needs someone with an eye familiar with the architecture to give QEMU a look.  If you are interested in further development of the qemu-user targets, please see my github repo and clone away.

If you are looking to see what needs to be done, Stacey Son has kept an excellent log of open item on the FreeBSD Wiki

Sometimes you have to sit down and write #FreeBSD documentation

When working on new projects or hacks, sometimes you just have to stop, think and start writing down your processes and discoveries. While working on bootstrapping the DLink DIR-825C1, I realized that I had accumulated a lot of new (to me) knowledge from the FreeBSD Community (namely, Adrian Chadd and Warner Losh).

There is a less than clear way of constructing images for these embedded devices that has an analogue in the Linux community under the OpenWRT project. Many of the processes are the same, but enough are different that I thought it wise to write down some of the processes into the beginning of a hacker’s guide to doing stuff and/or things in this space.

The first document I came up with was based on the idea that we can netboot these little devices without touching the on-board flash device. This is what you should use to get the machine bootstrapped and figure out where all the calibration data for the wireless adapters exist. This is crucial to not destroying your device. The wireless calibration data (ART) is unique to each device, destroying it will mean you have to RMA this device.

The second document I’ve created is a description of how to construct the flash device hints entries in the kernel hints file for FreeBSD. I found the kernel hints file to be cumbersome in comparison to the linux kernel way of using device specific C files for unique characteristics.

Its interesting stuff if you have the hankering to dig a bit deeper into systems that aren’t PC class machines.

Wait

We recently “destroyed” an Dell Poweredge R720 at the office and it was to be retired to the dust bin.  We ran the Dell updates for firmware things and the machine now is completely unbootable.  Too bad, it was a very nice machine.

But, this led me down an interesting road.  I cracked open the server and started removing components one by one.  Lo and behold I noted that there was a very interesting 4 pin connector on the motherboard labeled “DRAC UART”.  Hmmm … I thought this sounded interesting.  After scrounging up a multimeter, I verified that it was indeed a 3.3 volt connection and seemed to have a ground pin as well.

I grabbed a TTL to USB converted off of my coworkers desk and proceeded to hook it up.  I was surprised and amused to find out that the Dell DRAC 7 seems to be nothing more than a fancy OpenWRT instance running on a Hitachi SH4A 32bit microprocessor.

FreeBSD on PicoStation M2HP

After tplink, it was time to play with picostation m2hp.
image

image

I’ve learned a bunch of things from this experience and this entire bring up would have been impossible without the help from loos@ and adrian@

First of all, a usb-ttl serial adapter is needed to connect to the board:
image

Here,
black – GND
white – TX
green – RX

When you power it on, the boot up sequence looks like this:

U-Boot 1.1.4.2-s564 (Jul 19 2012 - 10:41:56)

Board: Ubiquiti Networks XM board (rev 1.0 e302)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0, eth1
Hit any key to stop autoboot: 0

Here is where you should top the autoboot and it will drop into uboot>.

ar7240> printenv
bootdelay=1
baudrate=115200
ethaddr=00:15:6d:0d:00:00
mtdids=nor0=ar7240-nor0
partition=nor0,0
mtddevnum=0
mtddevname=u-boot
filesize=10000
fileaddr=81000000
serverip=192.168.1.254
ethact=eth0
mtdparts=mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),5760k(rootfs),256k(cfg),64k(EEPROM)
bootcmd=bootm 0x9f050000
bootargs=console=tty0 root=31:03 rootfstype=squashfs init=/init
ipaddr=192.168.1.20
stdin=serial
stdout=serial
stderr=serial

Environment size: 452/65532 bytes
ar7240>

Again, mtdparts an important piece here to see how uboot expects the image layout:

mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),5760k(rootfs),256k(cfg),64k(EEPROM)

I picked up a working openwrt image and tried to load it.
My setup looks like this:
image

Black power adapter has 2 cables going to it:
o POE (yellow)- power over ethernet – which connects to the board
o LAN (green)- which connects to my working router

Laptop act as a tftp server here which is also connected to the router (via gray cable). This way laptop and board are both in the same network.
laptop has a tftp server running and I’ve assigned 192.168.1.254 to that network interface (em0 in my case) with “ifconfig alias”. This is because as you can see in uboot’s printenv, uboot expects the tftp server to be running at that address.
The board will obviously act as a tftp client.

Now, to transfer the image, after generating the image (which we will look into in a bit), copy that into /tftpboot on the server.

This is how you put board into “urescue” mode:

Board: Ubiquiti Networks XM board (rev 1.0 e302)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0, eth1
Hit any key to stop autoboot: 0
ar7240> ping 192.168.1.254
Using eth0 device
host 192.168.1.254 is alive
ar7240> urescue
Setting default IP 192.168.1.20
Starting TFTP server...
Using eth0 (192.168.1.20), address: 0x81000000
Waiting for connection: /

Now, board is waiting for image. Send it from the tftp server:

% tftp 192.168.1.20
tftp> bin
tftp> put PICOSTATION_M2HP.initial.img
Sent 5994346 bytes during 15.2 seconds in 11709 blocks
tftp>

board receiving the image:

Receiving file from 192.168.1.18:18401
Received 6040751 bytes
Firmware Version: XM.ar7240.FreeBSD

Alright this was the basics of how to upload a valid image onto the board. Fun part is to generate a *valid* image that board will accept.
I tried a bunch of different kenrconf’s available in the freebsd-wifi-build project but board was not accepting the generated images. After accepting the image, it used to fail like this:

Firmware check failed! (-2)

This error was coming from uboot which was proprietary and I could not find this error in any opensourced version of uboot.

General consensus about the reasons for this error was:
- bad layout of the firmware image
- wrong header (something that this uboot is not liking)

loos@ showed me a trick to look at images with hexdum. After looking at openwrt’s working image by “hexdump -c image”, I found out that uboot was expecting something along the lines of “XS2.ar7240.FreeBSD” as version string in its header. If it does not see “ar7240″ in the header, it would fail the check.

So, after all that and with ray@ suggestion of using lzma’ed kernel, I could boot up the board which later failed at mounting the rootfs:

U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07)

Board: Ubiquiti Networks XM board (rev 1.0 e302)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0, eth1
Hit any key to stop autoboot: 0
ar7240> rescu
Unknown command 'rescu' - try 'help'
ar7240> uresc

Setting default IP 192.168.1.20
Starting TFTP server...
Using eth0 (192.168.1.20), address: 0x81000000
Waiting for connection: \
Receiving file from 192.168.1.254:57971
Received 5917237 bytes

Firmware Version: XS2.ar7240.FreeBSD
Setting U-Boot environment variables
Un-Protected 1 sectors
Erasing Flash.... done
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
Copying partition 'kernel' to flash memory:
erasing range 0x9F050000..0x9F12FFFF: .............. done
Erased 14 sectors
writing to address 0x9f050000, length 0x000e0000 ...
Copying partition 'rootfs' to flash memory:
erasing range 0x9F130000..0x9F5FFFFF: ............................................................................. done
Erased 77 sectors
writing to address 0x9f130000, length 0x004d0000 ...

Firmware update complete.

Resetting...

U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07)

Board: Ubiquiti Networks XM board (rev 1.0 e302)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0, eth1
Hit any key to stop autoboot: 0
## Booting image at 9f050000 ...
Image Name: FreeBSD
Created: 2013-08-26 14:51:52 UTC

Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 893021 Bytes = 872.1 kB

Load Address: 80050000
Entry Point: 80050100
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...

CPU platform: Atheros AR7241 rev 1
CPU Frequency=390 MHz
CPU DDR Frequency=390 MHz
CPU AHB Frequency=195 MHz
platform frequency: 390000000
CPU reference clock: 5 MHz
arguments:
a0 = 00000006
a1 = a1f4bfb0
a2 = a1f4c450
a3 = 00000000

Cmd line:argv is invalid
Environment:
envp is invalid
Cache info:
picache_stride = 4096
picache_loopcount = 16
pdcache_stride = 4096
pdcache_loopcount = 8
cpu0: MIPS Technologies processor v116.147
MMU: Standard TLB, 16 entries
L1 i-cache: 4 ways of 512 sets, 32 bytes per line
L1 d-cache: 4 ways of 256 sets, 32 bytes per line
Config1=0x9ee3519e
Config3=0x20
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0 r254676: Thu Aug 22 18:05:52 UTC 2013
[email protected]:/usr/home/hirenp/work/freebsd/head/obj/mipseb/mips.mips/usr/home/hirenp/work/freebsd/head/src/sys/AP91 mips

gcc version 4.2.1 20070831 patched [FreeBSD]
real memory = 16777216 (16384K bytes)
avail memory = 12087296 (11MB)

random device not loaded; using insecure entropy
nexus0:
nexus0: failed to add child: arge0
clock0: on nexus0
Timecounter "MIPS32" frequency 195000000 Hz quality 800
Event timer "MIPS32" frequency 195000000 Hz quality 800
argemdio0: at mem 0x19000000-0x19000fff on nexus0

mdio0: on argemdio0
mdioproxy0: on mdio0
arswitch0: on mdio0
arswitch0: attaching PHY 0 failed
arswitch0: attaching PHY 1 failed
arswitch0: attaching PHY 2 failed
arswitch0: attaching PHY 3 failed
device_attach: arswitch0 attach returned 6
apb0 at irq 4 on nexus0
uart0: on apb0
uart0: console (115200,n,8,1)
pcib0 at irq 0 on nexus0
pcib0: found EEPROM at 0x1fff1000 on 0.0.0
pcib0: EEPROM firmware: 0x1fff1000 @ 4096 bytes
pcib0: device EEPROM 'pcib.0.bus.0.0.0.eeprom_firmware' registered
pci0: on pcib0
pci0: at device 0.0 (no driver attached)
arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0
miiproxy0: on arge0
arge0: can't attach proxy
arge0: finishing attachment, phymask 0010, proxy null
arge0: unable to attach PHY 4: 6
device_attach: arge0 attach returned 6
arge1: at mem 0x1a000000-0x1a000fff irq 3 on nexus0
arge1: finishing attachment, phymask 0000, proxy null
arge1: Ethernet address: 62:73:64:dd:03:41

spi0: at mem 0x1f000000-0x1f00000f on nexus0
spibus0: on spi0
mx25l0: at cs 0 on spibus0
mx25l0: w25q64, sector 65536 bytes, 128 sectors
ar71xx_wdog0: on nexus0
ar71xx_wdog0: Previous reset was due to watchdog timeout
Timecounters tick every 1.000 msec
Trying to mount root from ufs:/dev/map/rootfs.uncompress []...
mountroot: waiting for device /dev/map/rootfs.uncompress ...
Mounting from ufs:/dev/map/rootfs.uncompress failed with error 19.

Loader variables:

Manual root filesystem specification:
: [options]
Mount using filesystem
and with the specified (optional) option list.

eg. ufs:/dev/da0s1a
zfs:tank
cd9660:/dev/acd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /)

? List valid disk boot devices
. Yield 1 second (for background tasks)
Abort manual input

mountroot>

jmg@ suspected that /dev/map/rootfs.uncompress doesn’t exist for some reason as error: 19 is ENODEV and asked me to enable debugging in g_uncompress.c
I did not find anything useful after enabling debugs:

flash/spi0.uncompress: media sectorsize 512, mediasize 8388608
flash/spi0.uncompress: no CLOOP magic
map/u-boot.uncompress: media sectorsize 512, mediasize 262144
map/u-boot.uncompress: no CLOOP magic
map/u-boot-env.uncompress: media sectorsize 512, mediasize 65536
map/u-boot-env.uncompress: no CLOOP magic
map/kernel.uncompress: media sectorsize 512, mediasize 1048576
map/kernel.uncompress: no CLOOP magic
map/rootfs.uncompress: media sectorsize 512, mediasize 6684672
map/rootfs.uncompress: no CLOOP magic
map/cfg.uncompress: media sectorsize 512, mediasize 262144
map/cfg.uncompress: no CLOOP magic
map/eeprom.uncompress: media sectorsize 512, mediasize 65536
map/eeprom.uncompress: no CLOOP magic

Trying to mount root from ufs:/dev/map/rootfs.uncompress []...
mountroot: waiting for device /dev/map/rootfs.uncompress ...
Mounting from ufs:/dev/map/rootfs.uncompress failed with error 19.

Loader variables:

Manual root filesystem specification:
: [options]
Mount using filesystem
and with the specified (optional) option list.

eg. ufs:/dev/da0s1a
zfs:tank
cd9660:/dev/acd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /)

? List valid disk boot devices
. Yield 1 second (for background tasks)
Abort manual input

mountroot> ?

List of GEOM managed disk devices:
map/eeprom map/cfg map/rootfs map/kernel map/u-boot-env map/u-boot flash/spi0

mountroot>

Later loos@ caught that the problem was the rootfs start point in the hints file.

Specially we had to specify:
hint.map.3.start=0×130000

Because mtdparts specify 0×130000 as rootfs offset.

After this bring up part was done:

U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07)

Board: Ubiquiti Networks XM board (rev 1.0 e302)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0, eth1
Hit any key to stop autoboot: 0
ar7240> ures

Setting default IP 192.168.1.20
Starting TFTP server...
Using eth0 (192.168.1.20), address: 0x81000000
Waiting for connection: |
Receiving file from 192.168.1.254:57971
Received 5966201 bytes
Firmware Version: XM.ar7240.FreeBSD

Setting U-Boot environment variables
Un-Protected 1 sectors
Erasing Flash.... done
Erased 1 sectors
Writing to Flash... done

Protected 1 sectors
Copying partition 'kernel' to flash memory:
erasing range 0x9F050000..0x9F12FFFF: .............. done
Erased 14 sectors
writing to address 0x9f050000, length 0x000e0000 ...
Copying partition 'rootfs' to flash memory:
erasing range 0x9F130000..0x9F5FFFFF: ............................................................................. done
Erased 77 sectors
writing to address 0x9f130000, length 0x004d0000 ...
Copying partition 'cfg' to flash memory:
erasing range 0x9F6F0000..0x9F6FFFFF: . done
Erased 1 sectors
writing to address 0x9f6f0000, length 0x00010000 ...

Firmware update complete.

Resetting...

U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07)

Board: Ubiquiti Networks XM board (rev 1.0 e302)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0, eth1
Hit any key to stop autoboot: 0
## Booting image at 9f050000 ...
Image Name: FreeBSD
Created: 2013-08-27 11:12:34 UTC

Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 892769 Bytes = 871.8 kB
FreeBSD 10.0-CURRENT #6 r254676M: Tue Aug 27 11:11:27 UTC 2013

[email protected]:/usr/home/hirenp/work/freebsd/head/obj/mipseb/mips.mips/usr/home/hirenp/work/freebsd/head/src/sys/AP91 mips
gcc version 4.2.1 20070831 patched [FreeBSD]
real memory = 16777216 (16384K bytes)
avail memory = 12087296 (11MB)
random device not loaded; using insecure entropy
nexus0:
clock0: on nexus0
Timecounter "MIPS32" frequency 195000000 Hz quality 800
Event timer "MIPS32" frequency 195000000 Hz quality 800
argemdio0: at mem 0x1a000000-0x1a000fff on nexus0

mdio0: on argemdio0
mdioproxy0: on mdio0
arswitch0: on mdio0
miibus0: on arswitch0
ukphy0: PHY 0 on miibus0
ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
miibus1: on arswitch0
ukphy1: PHY 1 on miibus1
ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
miibus2: on arswitch0
ukphy2: PHY 2 on miibus2
ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
miibus3: on arswitch0
ukphy3: PHY 3 on miibus3
ukphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
etherswitch0: on arswitch0
mdio1: on arswitch0
mdioproxy1: on mdio1

apb0 at irq 4 on nexus0
uart0: on apb0
uart0: console (115200,n,8,1)
pcib0 at irq 0 on nexus0
pcib0: found EEPROM at 0x1fff1000 on 0.0.0
pcib0: EEPROM firmware: 0x1fff1000 @ 4096 bytes
pcib0: device EEPROM 'pcib.0.bus.0.0.0.eeprom_firmware' registered
pci0: on pcib0
pci0: at device 0.0 (no driver attached)
arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0
arge0: Overriding MAC from EEPROM
miiproxy0: on arge0
miiproxy0: attached to target mdio1
arge0: finishing attachment, phymask 0010, proxy set
miibus4: on miiproxy0
ukphy4: PHY 4 on miibus4
ukphy4: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
arge0: Ethernet address: 12:00:00:18:3c:02

arge1: at mem 0x1a000000-0x1a000fff irq 3 on nexus0
arge1: finishing attachment, phymask 0000, proxy null
arge1: Ethernet address: 12:00:00:18:3c:03

spi0: at mem 0x1f000000-0x1f00000f on nexus0
spibus0: on spi0
mx25l0: at cs 0 on spibus0
mx25l0: w25q64, sector 65536 bytes, 128 sectors
ar71xx_wdog0: on nexus0
ar71xx_wdog0: Previous reset was due to watchdog timeout
Timecounters tick every 1.000 msec
arswitch0port1: link state changed to DOWN
arswitch0port2: link state changed to DOWN
arswitch0port3: link state changed to DOWN
arswitch0port4: link state changed to DOWN
map/rootfs.uncompress: GEOM_ULZMA image found
map/rootfs.uncompress: 173 x 131072 blocks

Trying to mount root from ufs:/dev/map/rootfs.uncompress []...
warning: no time-of-day clock registered, system time will not be set accurately
Aug 27 11:11:45 init: login_getclass: unknown class 'daemon'
*** Populating /var ..
*** Loading configuration files ..
*** Restoring from /dev/map/cfg ..
gunzip: unknown compression format
0 blocks
*** Completed.
*** setting up hostname
*** Load kernel modules
random: initialized
*** bringing up loopback ..
*** Starting networking via /etc/rc.d/base/net
sysctl: unknown oid 'dev.ath.0.txq_mcastq_maxdepth': No such file or directory
sysctl: unknown oid 'dev.ath.1.txq_mcastq_maxdepth': No such file or directory
*** Interface: arge0: start
arge0: link state changed to UP
*** Interface: arge0: done
*** Interface: bridge0: start
bridge0: Ethernet address: d2:c4:a8:63:0e:57
arge0: promiscuous mode enabled
bridge0: link state changed to UP
*** Interface: bridge0: done
*** Default password/login databases ..
*** inetd
*** Done!

FreeBSD/mips (freebsd-wifi-build) (ttyu0)

login: root
No home directory.
Logging in with home = "/".
# uname -a
FreeBSD freebsd-wifi-build 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r254676M: Tue Aug 27 11:11:27 UTC 2013 [email protected]:/usr/home/hirenp/work/freebsd/head/obj/mipseb/mips.mips/usr/home/hirenp/work/freebsd/head/src/sys/AP91 mips
# df -k
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/map/rootfs.uncompress 21851 20633 -529 103% /
devfs 1 1 0 100% /dev
/dev/md0 828 8 756 1% /tmp
/dev/md1 828 56 708 7% /var
/dev/md2 828 436 328 57% /etc
# pciconf -lv
none0@pci0:0:0:0: class=0x028000 card=0xe3020777 chip=0x002a168c rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR928X Wireless Network Adapter (PCI-Express)'
class = network
# ifconfig
arge0: flags=8943 metric 0 mtu 1500
options=80000
ether 12:00:00:18:3c:02
media: Ethernet autoselect (100baseTX )
status: active
arge1: flags=8802 metric 0 mtu 1500
ether 12:00:00:18:3c:03
media: Ethernet 1000baseT
status: active
lo0: flags=8049 metric 0 mtu 16384
options=600003
inet 127.0.0.1 netmask 0xff000000
bridge0: flags=8843 metric 0 mtu 1500
ether d2:c4:a8:63:0e:57
inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: arge0 flags=143
ifmaxaddr 0 port 5 priority 128 path cost 200000
#

Next up was figuring out networking.

I loaded all needed modules:

# kldstat
Id Refs Address Size Name
1 22 0x80050000 2d8f10 kernel
2 1 0xc0081000 1078 if_ath_pci.ko
3 1 0xc0083000 11e4bc if_ath.ko
4 4 0xc01a2000 606fc wlan.ko
5 2 0xc0203000 4924 bridgestp.ko
6 1 0xc0208000 6d90 if_bridge.ko
7 1 0xc020f000 a5e0 random.ko
8 1 0xc021a000 3ac wlan_xauth.ko
9 1 0xc021b000 27e4 wlan_tkip.ko
#

But if loading if_ath_pci failed in:

ath0: at device 0.0 on pci0
ath0: ath_pci_attach: EEPROM firmware @ 0x8046c000
[ath]: default pwr offset: -5 dBm != EEPROM pwr offset: 0 dBm; curves will be adjusted.
ath0: ath_getchannels: unable to collect channel list from hal, status 12
device_attach: ath0 attach returned 22

Turning up debugging level:

# sysctl hw.ath.hal.debug=25600000000
hw.ath.hal.debug: 0 -> 2147483647

# kldload if_ath_pci
ath0: mem 0x10000000-0x1000ffff irq 0 at device 0.0 on pci0

ath0: ath_pci_attach: EEPROM firmware @ 0x8046c000
ar9280Attach: sc 0xc090d000 st 0x803006b4 sh 0xb0000000
ar5416SetReset Applying descriptor swap
ar5416SetPowerMode: AWAKE -> AWAKE (set chip )
ar9280Attach: ID 0x802ff VERSION 0x2 TYPE 0x0 REVISION 0x2
ath_hal_v14EepromAttach Eeprom Version 14.22
v14EepromReadCTLInfo Numctls = 11
ar5416SetPowerMode: AWAKE -> AWAKE (set chip )
ar9280RfAttach: attach AR9280 radio
[ath]: default pwr offset: -5 dBm != EEPROM pwr offset: 0 dBm; curves will be adjusted.
enableAniMIBCounters: Enable mib counters: OfdmPhyErrBase 0xbffe0c cckPhyErrBase 0xbfff38
ar9280Attach: return
getchannels: cc 0 regDmn 0xf0 mode 0xffffff ecm
isEepromValid: invalid regulatory domain/country code 0x2a
getregstate: invalid EEPROM contents
ath0: ath_getchannels: unable to collect channel list from hal, status 12
ar5416Detach:
ar5416SetPowerMode: AWAKE -> AWAKE (set chip )
Detaching Ani
Disable MIB counters
ar5416SetPowerMode: AWAKE -> AWAKE (set chip )
ar5416SetReset Applying descriptor swap
ar5416SetPowerMode: AWAKE -> FULL-SLEEP (set chip )

device_attach: ath0 attach returned 22

Error here was: isEepromValid: invalid regulatory domain/country code 0x2a
What it meant was that hal regdomain needed to be updated with country code 0x2a

Just to hack that up for time being, adrian@ suggested to set it to 0×0 which worked.


Index: dev/ath/ath_hal/ah_regdomain.c
===================================================================
--- dev/ath/ath_hal/ah_regdomain.c (revision 255320)
+++ dev/ath/ath_hal/ah_regdomain.c (working copy)
@@ -169,6 +169,10 @@
if (regDomainPairs[i].regDmnEnum == rd)
return AH_TRUE;
}
+ if (rd == 42) {
+ rd = 0;
+ return AH_TRUE;
+ }
HALDEBUG(ah, HAL_DEBUG_REGDOMAIN,
"%s: invalid regulatory domain/country code 0x%x\n", __func__, rd);
return AH_FALSE;

The kernconf and hints file are committed as r255086.

This is how you can generate the image:

$ cd ~
$ mkdir -p work/freebsd/head
$ cd work/freebsd/head
$ svn checkout svn://svn.freebsd.org/base/head src
$ svn checkout http://freebsd-wifi-build.googlecode.com/svn/trunk/ build
$ cd build/programs/ubnt-mkfwimage
$ make
$ su
# make install
# exit
$ cd ~/work/freebsd/head/src
$ ../build/build/bin/build picostation_m2hp buildworld buildkernel
$ su
# mkdir /tftpboot
# ../build/build/bin/build picostation_m2hp installworld installkernel distribution mfsroot fsimage uboot ubnt
# exit

On successful completion, resulting image PICOSTATION_M2HP.initial.img will be in /tftpboot.

My entire effort/rant has been also recorded at freebsd-embedded@

How to fry a router in X-1 steps, The Serial Console complete

If you saw my first post  regarding my attempts to use a DLink DIR-825 with FreeBSD, you noted that I was busily trying to get the serial console working.  I won’t go over the reasons for it in this new post, but get straight into the fun and games.

My motivation here is to make the serial console available without ripping open the case every time there is an issue.  FreeBSD in a OpenWRT/DD-WRT style configuration is a very open universe right now and there will be lots of changes to come.

For now, let’s start with the ingredient list:

  1. DLink DIR-825 rev. B1
  2. Soldering Iron, solder, solder braid, good tweezers, scissors, exacto-knife
  3. Jumper wire leads, F-F
  4. OSEPP FTDI Breakout Board kit
  5. Circuit Board safe superglue

Step 1 of this operation is to open the DIR-825, remove the main board and solder on pins to JP1 on the board.

Once that is secure and you’ve validated that you can use your USB TTL adapter to get a serial console then you can move forward to setup the internal mounting and give yourself an external connector.

The case is used in 2 and 3 antenna models.  This unit leaves us the center antenna mount as a  very convient place to secure our TTL USB adapter.  Get your exacto-knife and cut out the black label area covering this hole.  Then gently cut out the top half of the innner plastic ring as I have shown in this photo.

DLink_USB_Mod_CaseSee how nicely the USB connector presents itself?  Its as though we planned this out!

Next, I modified the TTL adapter itself.  I needed to remove the jumper at the center of the adapter as it collides with the capacitor directly adjacent to the mounting point.

DIR825-USB-solderingI then was able to solder a very small length of wire to short the 3.3v selector permanently.  You’ll need a steady hand and the tweezers to pull out the pins and insert the wire.DIR825-USB-33v

You’ll note that I’ve removed the pin header that comes with the adapter.  This was accomplished with a sharp pair of scissors and then using the soldering iron to extract the remainder of the pins with judicious use of tweezers.

Once that was done, I soldered on individual pins for TX, RX and ground. Note that I’ve bent the pins at a 45 degree angle.  This will avoid any issues with the pins making contact with the mainboard.

Now that you have all the pieces ready to go, its time to break out the superglue and mount the thing.  When choosing a glue, you’ll need to get one that is safe for PCB and plasitc in general, your local electronics and hobby shop can direct you to the proper stuffs.

I mounted the TTL adapter upside down so that the connector can reach the opening on the case and there are two lower points of contact for the glue to set correctly.DIR825-USB-mount

I applied glue to the two corners next to the USB header, flipped it over and brought it into firm contact with the antenna mount.  After about 1 minute, I released pressure and applied a line of glue across the surface of the TTL adapter such that it sealed against the case of the router.

DIR825-USB-GLUE2Now … WALK AWAY for at least 6 hours.  If you’re using the right kind of glue, there’s some science happening here and you need to let the glue/plastic cure to get a secure mount.DIR825-USB-FINAL

Wire up your TX, RX and ground leads, reattach the case housing and connect up your new USB serial interface to a PC.  On FreeBSD, you should see a new serial port appear.

ugen5.2: <FTDI> at usbus5
uftdio0: <FT232R USB UART> on usbus5

Go ahead, open it with your handy, dandy comm utility, cu:

cu -l /dev/ttyU0 -s 115200

If you’ve done everything right, congrats, you’ll now see the embedded linux distribution boot up.  You are now at Step 0 getting your FreeBSD based home router running.

How to fry a router, in X easy steps: The Serial Console

DIR 825I’ve started to hack on my DLink DIR-825 B1 to get it running FreeBSD and have had some great success.  Adrian Chadd, [email protected] put together a build system for this router and committed some of the needed changes to get this Atheros MIPS 24k based router working for us and I’ll try to document my steps in getting it working.

These things come with a variant of Linux installed, so the first step is to get a working serial console on it.  By default the serial console is 115200, 8N1.  There are 4 pins providing a 3.3v TTL RS-232 connection on the board, but you have to solder the pins on yourself.  Removing the board requires removal of the 2 screws underneath the small, black rubber feet on the bottom of the case.TTL Adapter

Opening the case requires a bit of pressure, but it will come apart and the top half of the case will detach, giving you access to the interior.  Next remove the two screws securing the LED shroud and main board to the case.  There may be bits of tape holding the DIR-825 B1 interior and shroud in place, so remove them and you should be able to remove the router from its case.

Your goal now is to get 4 pins soldered onto the board at JP1.  This will give you a VCC, Ground, TX and RX connection of a TTL serial adapter.  I recommend purchasing the cheap, Open Source Hardware version, either from Fry’s or online.  This will give you the flexibility to do 3.3v or 5v TTL serial and let you use any mini USB cable you have lying around to get the console working.

Once you have soldered your pins, connect them to your serial adapter.  OpenWRT has the pinouts you need.  Pin #1 is the connection closest to the label JP1 on my board.  The VCC connection is identified with a full square around the pin.  You will not need to connect up the VCC connection in any way, so leave it alone.

At this point, connect your TTL serial adapter to the USB port of your PC and open a connection to it via your favourite serial port application (minicom, cu, etc).  You should be able to power on the DIR-825 and watch the system boot up now.

Why is this important?  We have no way of interacting with the unit if we fail to boot.  Developing the O/S images for deployment require many mistakes, most of which end up requiring reboots.  There’s no easy way to determine what went wrong without some kind of log, the serial console is your most important interface to managing your router.  Besides which, its TOTALLY RAD to hack on your equipment and see the results of your work when you get the serial console working.  You don’t have to know how to code, nor do you have to even be an o/s developer to think that this is cool.

Making TL-WR1043ND do networking

This is a followup post to Installing FreeBSD on TP-Link TL-WR1043ND

I’ve learned a few very basic networking things while trying to make this work.

After having FreeBSD run on the board, next thing was to make it do networking. How Adrian’s scripts work is, it has configuration in /etc/cfg/


# pwd
/etc/cfg
# ls
hostapd.wlan0.conf manifest rc.conf
#

Here,
manifest file has list of files to be stored in flash on “cfg_save”. Basic workflow is that you make changes you want and do “cfg_save” which writes things to flash and then “reboot”. So router comes up with the saved settings.

To create a wifi network for let’s say wlan0, we need to create a hostapd file for it:

# cat hostapd.wlan0.conf
interface=wlan0
driver=bsd
ssid=STRCDR_11N
wpa=3
wpa_key_mgmt=WPA-PSK
wpa_passphrase=NotAdminORPassword
wpa_pairwise=CCMP TKIP
ctrl_interface=/var/run/hostapd

As this is a new file and we want to preserve it across reboots, we should add an entry for this file into manifest file. This is how manifest file looks:

# cat manifest
etc/cfg/manifest
etc/master.passwd
etc/group
etc/cfg/rc.conf
etc/cfg/hostapd.wlan0.conf

rc.conf is where you specify your networking configuration:

# cat rc.conf
# Set the default system hostname
system_hostname="freebsd-wifi-build"

# Modules to load
kernel_modules="bridgestp if_bridge random"

# These interfaces are configured in-order
network_interfaces="arge0 wlan0 bridge0"

# Create arge0, no interface address
netif_arge0_enable="YES"
netif_arge0_type="ether"
netif_arge0_addrtype="none"
netif_arge0_descr="default"
netif_arge0_name="arge0"

# Create a bridge, flip on an IPv4 static address
netif_bridge0_type="bridge"
netif_bridge0_addrtype="static"
netif_bridge0_descr="default"
netif_bridge0_name="bridge0"
# These are bridge members w/ STP enabled
netif_bridge0_members_stp="arge0"
# These are bridge members w/ STP disabled
netif_bridge0_members="arge0 wlan0"
netif_bridge0_ipv4_address="192.168.1.20"
netif_bridge0_ipv4_netmask="255.255.255.0"
netif_wlan0_enable="YES"
netif_wlan0_type="wifi"
netif_wlan0_wifi_mode="hostap"
netif_wlan0_descr="default"
netif_wlan0_addrtype="none"
netif_wlan0_name="wlan0"
netif_wlan0_wifi_parent="ath0"
netif_wlan0_wifi_createargs1="country US regdomain FCC3"
netif_wlan0_wifi_createargs2="channel 1:ht/20 up"
netif_wlan0_wifi_hostapd_enable="yes"
netif_wlan0_wifi_hostapd_conf="/etc/cfg/hostapd.wlan0.conf"

A few things to notice here:
* arge0 is the ethernet interface
* wlan0 is the wifi interface
* bridge0 is the bridge interface connecting all of it together. It does the bridging of ethernet and wifi interfaces to send and receive bits (and bytes).

After making changes, to save them do:

# cfg_save
*** Storing configuration files from /etc/cfg/manifest -> /dev/map/cfg..
etc/cfg/manifest
etc/master.passwd
etc/group
etc/cfg/rc.conf
etc/cfg/hostapd.wlan0.conf
8 blocks
dd: /dev/map/cfg: end of device
0+2 records in
1+0 records out
65536 bytes transferred in 0.479322 secs (136726 bytes/sec)

And “reboot” the router. When it comes back, it _should_ have everything ready and setup which was not the case with my setup.

This is how interfaces looked:

# ifconfig
arge0: flags=8943 metric 0 mtu 1500
ether 64:70:02:cd:94:56
inet6 fe80::6670:2ff:fecd:9456%arge0 prefixlen 64 scopeid 0x6
nd6 options=21
media: Ethernet 1000baseT
status: active
arge1: flags=8802 metric 0 mtu 1500
ether 64:70:02:cd:94:57
nd6 options=21
media: Ethernet 100baseTX
status: active
ath0: flags=8843 metric 0 mtu 2290
ether 00:19:e0:66:66:68
nd6 options=21
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
status: running
lo0: flags=8049 metric 0 mtu 16384
options=600003
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x9
inet 127.0.0.1 netmask 0xff000000
nd6 options=21
wlan0: flags=8943 metric 0 mtu 1500
ether 00:19:e0:66:66:68
inet6 fe80::219:e0ff:fe66:6668%wlan0 prefixlen 64 scopeid 0xa
nd6 options=21
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
status: running
ssid STRCDR_11N channel 1 (2412 MHz 11g ht/20) bssid 00:19:e0:66:66:68
regdomain FCC3 country US ecm authmode WPA1+WPA2/802.11i
privacy MIXED deftxkey 3 TKIP 2:128-bit TKIP 3:128-bit txpower 30
scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 shortgi wme
burst dtimperiod 1 -dfs
bridge0: flags=8843 metric 0 mtu 1500
ether 96:ce:f3:c8:09:b4
inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=21
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: wlan0 flags=143
ifmaxaddr 0 port 10 priority 128 path cost 33333
member: arge0 flags=143
ifmaxaddr 0 port 6 priority 128 path cost 2000000
#

As you can see everything looked sane and I could see it advertizing wifi network but when a client tries to associate, it would get stuck on “Obtaining IP address” and even if you assign static IP, client does not receive any packets.

We then looked at “etherswitchcfg” which provides ethernet connectivity for the board:

# etherswitchcfg
port0:
vlangroup: 1
media: Ethernet autoselect (100baseTX )
status: active
port1:
vlangroup: 0
media: Ethernet autoselect (none)
status: no carrier
port2:
vlangroup: 0
media: Ethernet autoselect (none)
status: no carrier
port3:
vlangroup: 0
media: Ethernet autoselect (none)
status: no carrier
port4:
vlangroup: 0
media: Ethernet autoselect (none)
status: no carrier
port5:
vlangroup: 0
media: Ethernet 1000baseT
status: active
vlangroup0:
vlan: 1
members 1,2,3,4,5
vlangroup1:
vlan: 2
members 0,5t
#

Now, as you can see the ethernet cable in WAN (blue) port shows up as port0 and it is in vlangroup1. But vlangroup1 is in vlan 2 and it is tagged. Moving ethernet cable from WAN port to one of the LAN ports fixed the problem.


# etherswitchcfg
port0:
vlangroup: 1
media: Ethernet autoselect (none)
status: no carrier
port1:
vlangroup: 0
media: Ethernet autoselect (100baseTX )
status: active
port2:
vlangroup: 0
media: Ethernet autoselect (none)
status: no carrier
port3:
vlangroup: 0
media: Ethernet autoselect (none)
status: no carrier
port4:
vlangroup: 0
media: Ethernet autoselect (none)
status: no carrier
port5:
vlangroup: 0
media: Ethernet 1000baseT
status: active
vlangroup0:
vlan: 1
members 1,2,3,4,5
vlangroup1:
vlan: 2
members 0,5t
#

Now a client could associate and get an IP via dhcp from the incoming ethernet connection on the router. (No dhcpd is needed/running on the router itself).

To look at connected clients:

# ifconfig wlan0 list sta
ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
08:11:96:f9:b2:ec 1 1 144M 38.5 0 4012 27616 EPS AQEHTRS RSN HTCAP WME

To debug, we can look at individual ports with “tcpdump -ni “.

Verbose debugging from ath wifi stack can be obtained by:

# wlandebug -i wlan1 +assoc
net.wlan.1.debug: 0x0 => 0x800000

Just as a side-note, hostapd proc is using the configuration we provided and is running:

# ps awwux | grep hostapd
root 176 0.0 6.6 13104 2176 - Ss 6:56PM 0:00.13 hostapd -P /var/run/hostapd.wlan0.pid -B /etc/cfg/hostapd.wlan0.conf

Again a *HUGE* Thanks to Mr FreeBSD Wifi (Adrian Chadd) for all the build scripts and help with the bring-up.

The sacrifices we must make for science!

Interesting day on the phone with DLink.  When I say “day”, I do mean DAY.  More or less, Monday must be DLink’s crazy time when everyone comes back from work and finds their office routers dead or something.

The DIR-825 model C1 that I initially bought to test out MIPS on FreeBSD died a noble death for science last month, so I thought I’d see if I could get DLink to replace it for me.  Long story short, they gave me an RMA for it and the new one will be here next week.  Short story long, wow.

I think I was on hold for close to an hour to get to the level 1 technician.  This tech was super nice but awfully frustrating to deal with.  She didn’t ask if I had an existing case number, she didn’t ask what I had already done to try and resolve the issue nor did she understand that I had already gone through all the reset procedures on their web site in order to resolve this issue in the first place.  However, in the technician’s defence, I am kind of a tool.  Not to mention that she absolutely has a script that she must follow AND most people calling in are not nearly as technically savvy as I was to detonate the router in the first place.

So 1 hour on hold, then 2 hours with the level 1 technician.  In frustration, I started to ask about getting a replacement.  I assume that this is a key phrase that triggers escalation to level 2.  That’s right, LEVEL 2.  Speaking with the senior technician at level 2, it became very clear that we were speaking the same language.  Heck, the technician actually asked me what my Unix boxes see from a DHCP request.  AMAZING.  When I passed on the information that, no its quite dead now, getting to the RMA stage was almost trivial.

I wonder, what could make this situation easier for DLink and easier for their users.  I mean, most cases they deal with are just simple configuration mistakes, not real hardware issues.  My case was the exception, not the rule in their universe.  I think this means that Internet is hard.

I’ll go into more details on my science tomorrow, when I get the RMA sent off and can deal with the DIR-825 Model B1 that is totally working with FreeBSD MIPS now.  By the way, totally awesome.  SCIENCE!

New Device Tree Compiler

This week, I imported a new device tree compiler, dtc(1). This is the tool that is used to translate between different representations of a Flattened Device Tree (FDT), a way of representing boot-time configuration information. The FDT contains more or less the same information as an OpenFirmware device tree, for example the locations of memory-mapped peripherals, reserved sections of RAM, interrupt routing information, and so on.

FreeBSD/ARM makes a lot of use of FDTs, as they’re the standard way of getting information from the bootloader. They are used in two ways. The ideal way is for the bootloader to provide the tree to the kernel at boot time. This allows a single kernel to be used with multiple SoCs. Alternatively, the device tree can be compiled into the kernel.

The device tree in both cases is in the form of a Device Tree Blob (DTB), a binary representation of the tree. The ‘flattened’ in the name comes from the fact that the tree is represented in a linear structured format, like HTML, with explicit delimiters for starts and ends of child nodes, rather than in a format with pointers between elements. The other representation, the Device Tree Source is a human-readable tree using braces to delimit children and is rather similar to the OpenStep property list format or JSON.

The device tree compiler is responsible for converting between these formats. In the FreeBSD tree, we have a number of DTS files that represent supported platforms where the bootloader doesn’t provide the DTB. During the build process, the DTB is generated and linked into the kernel.

Unfortunately, the existing tool was released under the GPL. We try to minimise the amount of GPL’d code installed by default, and intend to remove all of it by 10.0, so dtc was not installed unless your target platform used it (a bit silly, as you want to use it on your host platform when doing embedded device development). The new tool is a (BSD-licensed) from-scratch rewrite that I did over Christmas. It shares no code with the original, but works as a drop-in replacement in our build system.

It is now used by default, although the old GPL’d tool will remain available as an option for a while until I’m confident that we aren’t breaking out-of-tree dtc users. So, if you’re using FDTs and don’t have the DTS in the tree, please test it. Otherwise, this is just another step on the way to a fully GPL-free base system.

Rearranging the deck chairs in the ARM port

Recently, I've been trying to catch up with some of the technical debt that the FreeBSD/arm port has accumulated.  Some of that technical debt was my fault, of course, but some of it wasn't.  I don't really much care whose fault things were,  but I would like to get things cleaned up.  Some of these are paths not taken.  Some are porting shims that never got properly connected.  There's also some features that were poo-poo-ed by some (including me) years ago that seem to make more sense now.

None of this stuff is terribly sexy.  Some of it will be addressed by the summer of code project that's working its way through some of the maze of twisty passages in initarm() that are subtly different between the different boards for no good reason.

We have no common place for boot loader code.  Some arm ports do use a common routine to fake up just enough metadata that debugging and other symbols work.  Some arm ports assume a full /boot/loader is present.  However, there's no common facility for getting information from via the Linux boot protocol, nor is there any provisions for having multiple boards supported by a single kernel.  There's no uniform interface to get this information that might be passed in by other means.  There's no real way for a board to get control early enough to get at meta-data a custom boot loader might pass in.

The first big thing that I'd like to comment on is a small change to the interface between locore.S' _start routine and the first port-specific code in initarm.  I've preserved the first 4 registers that were passed in on boot to _start().  Before, there'd be no way to access the Linux ATAGs, for example, by a port since these are passed in as arg 3.  To allow for future expansion, I'm just passing in one structure now.

In the coming weeks, I'll be implementing routines to parse these arguments based on standard boot protocols, while allowing customization for special needs.

In the coming months, I plan to expand our support for having multiple boards based on a single Atmel SoC.  Once I have the one at a time SoC code working, I hope to get multiple SoCs working in one kernel.  While the extra 'bloat' isn't optimal for many users, the convenience of being able to boot one kernel for installation, or trying out the system, is a feature that's been much requested.  I've already eliminated the need to have a compiled-in master clock frequency, with improved main clock detection with fallback for people using unconventional frequencies.

I'm also interested in sweeping into the tree many of the Atmel arm changes that have been accumulating in the PR database.  Some of these will be easy to integrate, while others may be difficult due to drift from the original submission.

Once we get a good baseline, I hope to merge these changes into 9.x and 8.x.  To date, the interfaces that have change have been purely internal ones we do not support.  External users may experience some bumpy waves if they haven't been working to get their changes merged upstream.  The more that you've submitted, the more I'm likely to go the extra mile to help smooth any transitions.  With luck, 8.3 and 9.2 will both benefit from these efforts.

FreeBSD/arm –

I've just found out that FreeBSD/armv6 now runs on this:

http://www.embeddedartists.com/products/kits/lpc3250_kit.php


This is excellent news. There's also been some recent work to improve pandaboard support (TI-OMAP) focusing on pmap and SMP fixes.

I'm so very glad that the FreeBSD community is pushing this ARM project along. Yes, the armv6 branch is not very well named (it supports more recent ARM platforms, not just armv6 improvements) and I'm hoping this will all make it into FreeBSD-HEAD soon.

Oh god, so much wireless hardware..

Since I've started doing wireless development, people seem to be sending me more and more hardware. (I've also bought some stuff off of ebay too, so I'm partially to blame for this. :-)So there's this group of developers over in Europe/Russia who have been busy porting FreeBSD to a variety of wireless devices, but their work hasn't made it into the main FreeBSD tree (or been published at all in any public way.) I've been liaising with Aleksandr Rybalko to push their work into -HEAD in time for FreeBSD-9.0.So far this has included:
  • Support for the Ralink RT305x MIPS SoC, with initial peripheral support;
  • nvram2env, a way of importing the environment from various bootloaders (eg uboot) into the kernel environment;
  • geom_map, a GEOM module which describes the flash layout for fixed flash partitioning schemes (again like uboot, but it can be used for anything.)
There's a few other things coming up soon, such as support for one of the Broadcom MIPS SoCs, further peripheral support for the RT305x (including the embedded wireless MAC/radio) and other bits and pieces which will prove to be useful.It's been a pleasure working with them

Oh god, so much wireless hardware..

Since I've started doing wireless development, people seem to be sending me more and more hardware. (I've also bought some stuff off of ebay too, so I'm partially to blame for this. :-)

So there's this group of developers over in Europe/Russia who have been busy porting FreeBSD to a variety of wireless devices, but their work hasn't made it into the main FreeBSD tree (or been published at all in any public way.) I've been liaising with Aleksandr Rybalko to push their work into -HEAD in time for FreeBSD-9.0.

So far this has included:

  • Support for the Ralink RT305x MIPS SoC, with initial peripheral support;
  • nvram2env, a way of importing the environment from various bootloaders (eg uboot) into the kernel environment;
  • geom_map, a GEOM module which describes the flash layout for fixed flash partitioning schemes (again like uboot, but it can be used for anything.)
There's a few other things coming up soon, such as support for one of the Broadcom MIPS SoCs, further peripheral support for the RT305x (including the embedded wireless MAC/radio) and other bits and pieces which will prove to be useful.

It's been a pleasure working with them

New FreeNAS beta snapshot released (r5648)

We've released the next beta snapshot of FreeNAS.
You can read the release notes for all the details.
Here's a highlight of the issues that we've fixed since the last beta (r5606):
  • Upgrades from prior FreeNAS 8 beta releases are now supported.
  • zfs creation failures have been fixed. The gui would indicate it succeeded, but you couldn't share it.
  • ufs creation failures have been fixed.
  • booting off USB or SCSI cdrom is now supported.
  • Many disk initialization errors that showed up as odd failures have been corrected.
  • lagg has been introduced.
  • Errors in the network screen have been corrected.
  • The storage wizard no longer says 'of X' when creating the storage unit. This eliminates the confusing 1 of 3 -> 2 of 2 dialog heading.
  • Improved compatibility with IE and Safari.
  • The installer has been streamlined.
Also, I was pleasantly surprised today when I logged in and found 19 comments from my last blog entry. I'm not used to so many, so hadn't been checking. I'll be checking more here. I'll also write a blog entry to address many of the issues raised in them.
You can download the latest from sourceforge.

New FreeNAS beta snapshot released (r5648)

We've released the next beta snapshot of FreeNAS.

You can read the release notes for all the details.

Here's a highlight of the issues that we've fixed since the last beta (r5606):
  • Upgrades from prior FreeNAS 8 beta releases are now supported.
  • zfs creation failures have been fixed. The gui would indicate it succeeded, but you couldn't share it.
  • ufs creation failures have been fixed.
  • booting off USB or SCSI cdrom is now supported.
  • Many disk initialization errors that showed up as odd failures have been corrected.
  • lagg has been introduced.
  • Errors in the network screen have been corrected.
  • The storage wizard no longer says 'of X' when creating the storage unit. This eliminates the confusing 1 of 3 -> 2 of 2 dialog heading.
  • Improved compatibility with IE and Safari.
  • The installer has been streamlined.
Also, I was pleasantly surprised today when I logged in and found 19 comments from my last blog entry. I'm not used to so many, so hadn't been checking. I'll be checking more here. I'll also write a blog entry to address many of the issues raised in them.


You can download the latest from sourceforge.

New FreeNAS Beta (r5606)

Just after the release of the first beta, a couple of serious problems came to life. As such, we've respun the release to fix these issues.
  • gmirror error displayed bogusly
  • the extremely long write times for disks
  • The lack of feedback during the installation (although with the significantly faster imaging, this is much less of an issue).
  • Default ownership and permission for Windows shares has been fixed
  • Shares are browseable by default now
  • The extra and redundant steps in the installer have been eliminated
  • The inconsistent menus in the installer have been made regular
  • A ZFS issue on reboot has been corrected
  • Multi-line config fields have been fixed
  • Problems with snmp have been resolve
  • proftpd's config file is now generated properly the second time
  • minor nits fixed in many places
You can find the release notes or the release. Stay tuned for more updates.

New FreeNAS Beta (r5606)

Just after the release of the first beta, a couple of serious problems came to life. As such, we've respun the release to fix these issues.

  • gmirror error displayed bogusly
  • the extremely long write times for disks
  • The lack of feedback during the installation (although with the significantly faster imaging, this is much less of an issue).
  • Default ownership and permission for Windows shares has been fixed
  • Shares are browseable by default now
  • The extra and redundant steps in the installer have been eliminated
  • The inconsistent menus in the installer have been made regular
  • A ZFS issue on reboot has been corrected
  • Multi-line config fields have been fixed
  • Problems with snmp have been resolve
  • proftpd's config file is now generated properly the second time
  • minor nits fixed in many places
You can find the release notes or the release. Stay tuned for more updates.

FreeNAS 8 Beta released

iXsystems is pleased to announced FreeNAS 8.0 Beta. FreeNAS 8.0 has undergone a complete rewrite. We've redesigned the GUI to be easier to use and extend. We've upgraded many technologies in the system for improved hardware support, faster I/O, better modularity, and easier upgrades. We trust that you'll find the system easier to use and, in time, much more feature rich than the current FreeNAS offering.The base system has migrated from FreeBSD 7.x and the m0m0wall build system to FreeBSD 8.1-RELEASE and NanoBSD. The system startup has migrated from the older php scripts to the standard FreeBSD rc.d boot system. We've pushed many of the bug fixes and system improvements back into FreeBSD.We've rewritten the GUI using Python and Django. We've completely removed the old php system. In addition to Django, we're using Dojango and Dojo to implement AJAX features. The new system is much more modular than the old system. We will use this modularity in a future version for easy integration of custom features into your FreeNAS box.The installer has been rewritten using pc-sysinstall, the future FreeBSD installation technology. The scripts have a similar feel to the old PHP scripts for users of the current system. The ISO now is only an installer. You can no longer run in live mode from a CDROM.The installation types have changed; there's no longer an embedded or full install, nor can the image be installed on a data disk. You must now install FreeNAS onto a dedicated device. FreeNAS supports USB flash, CompactFlash, hard drives, ssd or any other mass storage device supported by FreeBSD.FreeNAS 8.0 features ZFS version 14.FreeNAS 8.0 beta has retained the core functionality of a storage appliance. The media center features of the box have not been reimplemented in the core FreeNAS package. A media center add-on package will provide this functionality in the future. We've focused on creating a robust, easy-to-use, and extensible system. We're creating the base to allow other types of packages to be added, such as printer support, scanner support, or home automation. To help prioritize what current features are turned into packages in future FreeNAS releases, please visit http://support.freenas.org/ to provide feedback. Please add feature requests tickets. If a feature you would like to see in FreeNAS already has a ticket please just subscribe to it add a small comment, even if it's a "++." It will help us better judge and meet community needs.You can download FreeNAS from Source Forge and read all the release notes on our wiki.

FreeNAS 8 Beta released

iXsystems is pleased to announced FreeNAS 8.0 Beta. FreeNAS 8.0 has undergone a complete rewrite. We've redesigned the GUI to be easier to use and extend. We've upgraded many technologies in the system for improved hardware support, faster I/O, better modularity, and easier upgrades. We trust that you'll find the system easier to use and, in time, much more feature rich than the current FreeNAS offering.

The base system has migrated from FreeBSD 7.x and the m0m0wall build system to FreeBSD 8.1-RELEASE and NanoBSD. The system startup has migrated from the older php scripts to the standard FreeBSD rc.d boot system. We've pushed many of the bug fixes and system improvements back into FreeBSD.

We've rewritten the GUI using Python and Django. We've completely removed the old php system. In addition to Django, we're using Dojango and Dojo to implement AJAX features. The new system is much more modular than the old system. We will use this modularity in a future version for easy integration of custom features into your FreeNAS box.

The installer has been rewritten using pc-sysinstall, the future FreeBSD installation technology. The scripts have a similar feel to the old PHP scripts for users of the current system. The ISO now is only an installer. You can no longer run in live mode from a CDROM.

The installation types have changed; there's no longer an embedded or full install, nor can the image be installed on a data disk. You must now install FreeNAS onto a dedicated device. FreeNAS supports USB flash, CompactFlash, hard drives, ssd or any other mass storage device supported by FreeBSD.

FreeNAS 8.0 features ZFS version 14.

FreeNAS 8.0 beta has retained the core functionality of a storage appliance. The media center features of the box have not been reimplemented in the core FreeNAS package. A media center add-on package will provide this functionality in the future. We've focused on creating a robust, easy-to-use, and extensible system. We're creating the base to allow other types of packages to be added, such as printer support, scanner support, or home automation.

To help prioritize what current features are turned into packages in future FreeNAS releases, please visit http://support.freenas.org/ to provide feedback. Please add feature requests tickets. If a feature you would like to see in FreeNAS already has a ticket please just subscribe to it add a small comment, even if it's a "++." It will help us better judge and meet community needs.

You can download FreeNAS from Source Forge and read all the release notes on our wiki.

FreeNAS 8 — First alpha snapshots

My blog has been somewhat quiet lately. I've been busy with other things lately.The biggest of the other things is FreeNAS. iXsystems stepped up to the plate late last year when FreeNAS was going to become a Linux based platform.The iXsystems engineering team has moderized FreeNAS in a number of ways. We wanted a platform that was more extensible than the current m0m0wall-based framework allowed. We wanted to create a platform that could be expandable by modules (possibly not even written by us). We wanted to make it easier to upgrade the base FreeBSD release, as well as leverage more base FreeBSD technology that has been integrated into the system since FreeNAS was originally developed.We've migrated the build to be NanoBSD based. This allows us to leverage the embedded work that has gone into NanoBSD. It also allows us to push some of the features that are important to FreeNAS back into the base FreeBSD distribution. NanoBSD gives us the flexibility that we need. Since we're using the FreeBSD package system to add ports and packages, users will be able to add their own packages (we'll likely expand the basics to use the PBI's that PC-BSD produces for ease of installation). We're using the normal rc.d system, so upgrading is easier as well.On the GUI side we've moved to using django. This is a python-based front-end to sqlite3 which is extensible and easy to use. While we've kept things rather plain so far, we plan on jazzing things up a bit now that we have the basics working fairly well. Since the GUI is based on django, we'll be able to allow packages to hook into the GUI to present a united interface to the user.The GUI calls into a middleware layer that manages the services on the box. This middleware is responsible for generating updated config files, as well as starting, stopping and restarting daemons on the system. The same code generates the files at boot as well. Having all the configuration data in one database makes it easier to upgrade from release to release, since you don't have to merge your changes into the config files: the system takes care of that details.If you'd like to read about the nuts and bolts about trying out the latest snapshot, you can check out my forum post on the topic over at the FreeNAS forums.