May 072017
 

So, in amongst my pile of crusty old hardware is the old netbook I used to use in the latter part of my univerity days. It is a Lemote Yeeloong, and sports a ~700MHz Loongson 2F CPU (MIPS III little endian ISA) and 1GB RAM.

Back in the day it was a brilliant little machine. It came out of the box running a localised (for China) version of Debian, and had pretty much everything you’d need. I natually repartitioned the machine, setting up Gentoo and I had a separate partition for Debian, so I could actually dual-boot between them.

Fast forward 10 years, the machine runs, but the battery is dead, and Debian no longer supports MIPS-III machines. Debian Jessie does, but Stretch, likely due for release some time this year, will not, if you haven’t got a CPU that supports mips32r2 or mips64r2, you’re stuffed.

I don’t want to throw this machine away.  Being as esoteric as it is, it is an unlikely target for theft, as to the casual observer, it’ll just be “some crappy netbook”.  If someone were to try and steal it, there’s a very high probability I’ll recover it with my data because the day its PMON2000 boot firmware successfully boots a x86-64 OS like Ubuntu or Windows without the assistance of a VM of some kind would be the day Satan puts a requisition order in for anti-freeze and winter mittens.

My use case is for a machine I can take with me on the bicycle.  My needs aren’t huge: I won’t be playing video on this thing, it’ll be largely for web browsing and email.  The web browser needs to support JavaScript, so that rules out options like ELinks or Dillo, my preferred browser is Firefox but I’ll settle for something Webkit-based if that’s all that’s out there.

So what operating systems do I have for a machine that sports a MIPS-III CPU and 1GB RAM?  Fedora has a MIPS port, but that, like Debian, is for the newer MIPS systems.  Arch Linux too is for newer architectures.

I could bootstrap Alpine Linux… and maybe that’s worth looking into, they seem to be doing some nice work in producing a small and capable Linux distribution.  They don’t yet support MIPS though.

Linux From Scratch is an option, if a little labour intensive.  (Been there, done that.)

OpenBSD directly supports this machine, and so I gave OpenBSD 6.0 a try.  It’s a very capable OS, and while it isn’t Linux, there isn’t much that an experienced Linux user like myself needs to adapt to in order to effectively use the OS.  pkgsrc is a great asset to OpenBSD, with a large selection of pre-built packages already available.  Using that, it is possible to get a workable environment up and running very quickly.  OpenBSD/loongson uses the n64 ABI.

Due to licensing worries, they use a particularly old version of binutils as their linker and assembler.  The plan seems to be they wish to wean themselves off the GNU toolchain in favour of LLVM.  At this time though, much of the system is built using the GNU toolchain with some custom patches.  I found that, on the Yeeloong, 1GB RAM was not sufficient for compiling LLVM, even after adding additional swap files, and some packages I needed weren’t available in pkgsrc, nor would they build with the version of GNU tools available.

Maybe as they iron out the kinks in their build environment with LLVM, this will be worth re-visiting.  They’ve done a nice job so far, but it’s not quite up to where I need it to be.

Gentoo actually gives me the choice of two possible ABIs: o32 and n32o32 is the old 32-bit ABI, and suffers a number of performance problems, but generally works.  It’s what Debian Jessie and earlier supplies, and what their mips32 port will produce from Stretch onwards.

n32 is the MIPS equivalent of what some of you may know as x32 on AMD64 platforms, it is a 32-bit environment with 64-bit long pointers… the idea being that very few applications actually benefit from the use of 64-bit data types, and so the usual quantities like int and long remain the same as what they’d be on o32, saving memory.  The long long data type gets a boost because, although “32-bit”, the 64-bit operations are still available for use.

The trouble is, some applications have problems with this mode.  Either the code sees “mips64” in the CHOST and assumes a full 64-bit system (aka n64), or it assumes the pointers are the same width as a long, or the build system makes silly assumptions as to where things get put.  (virtualenv comes to mind, which is what started me on this journey.  The same problem affects x32 on AMD64.)

So I thought, I’d give n64 a try.  I’d see if I can build a cross-compiler on my AMD64 host, and bootstrap Gentoo from that.

Step 1: Cross-compiler

For the cross-compiler, Gentoo has a killer feature that I have not seen in too many other distributions: crossdev.  This is a toolchain build tool that can generate cross-compiler toolchains for most processor architectures and environments.

This is installed by running emerge sys-devel/crossdev.

A gotcha with hardened

I run “hardened” AMD64 stages on my machines, and there’s a little gotcha to be aware of: the hardened USE flag gets set by crossdev, and that can cause fun and games if, like on MIPS, the hardening features haven’t been ported.  My first attempt at this produced a n64 userland where pretty much everything generated a segmentation fault, the one exception being Python 2.7.  If I booted with init=/bin/bash (or init=/bin/bb), my virtual environment died, if I booted with init=/usr/bin/python2.7, I’d be dropped straight into a Python shell, where I could import the subprocess module and try to run things.

Cleaning up, and forcing crossdev to leave off hardened support, got things working.

Building the toolchain

With the above gotcha in mind:

# crossdev --abis n64 \
           --env 'USE="-hardened"' \
           -s4 -t mips64el-unknown-linux-gnu

The --abis n64 tells crossdev you want a n64 ABI toolchain, and the --env will hopefully keep the hardened flag unset. Failing that, try this:

# cat > /etc/portage/package.use/mips64 <<EOF
cross-mips64el-unknown-linux-gnu/binutils -hardened
cross-mips64el-unknown-linux-gnu/gcc -hardened
cross-mips64el-unknown-linux-gnu/glibc -hardened
EOF

If you want a combination of specific toolchain components to try, I’m using:

  • Binutils: 2.28
  • GCC: 5.4.0-r3
  • glibc: 2.25
  • headers: 4.10

Step 2: Checking our toolchain

This is where I went wrong the first time, I tried building the entire OS, only to discover I had wasted hours of CPU time building non-functional binaries. Save yourself some frustration. Start with a small binary to test.

A good target for this is busybox. Run mips64el-unknown-linux-gnu-emerge busybox, and wait for a bit.

When it completes, you should hopefully have a busybox binary:

RC=0 stuartl@beast ~ $ file /usr/mips64el-unknown-linux-gnu/bin/busybox 
/usr/mips64el-unknown-linux-gnu/bin/busybox: ELF 64-bit LSB executable, MIPS, MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, stripped

Testing busybox

There is qemu-user-mips64el, but last time I tried it, I found it broken. So an easier option is to use real hardware or QEMU emulating a full system. In either case, you’ll want to ensure you have your system-of-choice running with a working 64-bit kernel already, if your real hardware isn’t already running a 64-bit Linux kernel, use QEMU.

For QEMU, the path-of-least-resistance I found was to use Debian. Aurélien Jarno has graciously provided QEMU images and corresponding kernels for a good number of ports, including little-endian MIPS.

Grab the Wheezy disk image and the corresponding kernel, then run the following command:

# qemu-system-mips64el -M malta \
    -kernel vmlinux-3.2.0-4-5kc-malta \
    -hda debian_wheezy_mipsel_standard.qcow2 \
    -append "root=/dev/sda1 console=ttyS0,115200" \
    -serial stdio -nographic -net nic -net user

Let it boot up, then log in with username root, password root.

Install openssh-client and rsync (this does not ship with the image):

# apt-get update
# apt-get install openssh-client rsync

Now, you can create a directory, and pull the relevant files from your host, then try the binary out:

# mkdir gentoo
# rsync -aP 10.0.2.2:/usr/mips64el-unknown-linux-gnu/ gentoo/
# chroot gentoo bin/busybox ash

With luck, you should be in the chroot now, using Busybox.

Step 3: Building the system

Having done a “hello world” test, we’re now ready to build everything else. Start by tweaking your /usr/mips64el-unknown-linux-gnu/etc/portage/make.conf to your liking then adjust /usr/mips64el-unknown-linux-gnu/etc/portage/make.profile to point to one of the MIPS profiles. For reference, on my system:

RC=0 stuartl@beast ~ $ ls -l /usr/mips64el-unknown-linux-gnu/etc/portage/make.profile
lrwxrwxrwx 1 root root 49 May  1 09:26 /usr/mips64el-unknown-linux-gnu/etc/portage/make.profile -> /usr/portage/profiles/default/linux/mips/13.0/n64
RC=0 stuartl@beast ~ $ cat /usr/mips64el-unknown-linux-gnu/etc/portage/make.conf 
CHOST=mips64el-unknown-linux-gnu
CBUILD=x86_64-pc-linux-gnu
ARCH=mips

HOSTCC=x86_64-pc-linux-gnu-gcc

ROOT=/usr/${CHOST}/

ACCEPT_KEYWORDS="mips ~mips"

USE="${ARCH} -pam"

CFLAGS="-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=${ROOT}tmp/

ELIBC="glibc"

PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/portage/local/"

Now, you should be ready to start building:

# mips64el-unknown-linux-gnu-emerge -e \
    --keep-going -j6 --load-average 12.0 @system

Now, go away, and do something else for several hours.  It’ll take that long, depending on the speed of your machine.  In my case, the machine is an AMD Phenom II x6 with 8GB RAM, which was brand new in 2010.  It took a good day or so.

Step 4: Testing our system

We should have enough that we can boot our QEMU VM with this image instead.  One way of trying it would be to copy across the userland tree the same way we did for pulling in busybox and chrooting back in again.

In my case, I took the opportunity to build a kernel specifically for the VM that I’m using, and made up a disk image using the new files.

Building a kernel

Your toolchain should be able to cross-build a kernel for the virtual machine.  To get you started, here’s a kernel config file.  Download it, decompress it, then drop it into your kernel source tree as .config.

Having done that, run make olddefconfig ARCH=mips to set the defaults, then make menuconfig ARCH=mips and customise to your hearts content. When finished, run make -j6 vmlinux modules CROSS_COMPILE=mips64el-unknown-linux-gnu- to build the kernel and modules.

Finally, run make modules_install firmware_install INSTALL_MOD_PATH=$PWD/modules CROSS_COMPILE=mips64el-unknown-linux-gnu- to install the kernel modules and firmware into a convenient place.

Making a root disk

Create a blank, raw disk image using qemu-img, then partition it as you like and mount it as a loopback device:

# qemu-img create -f raw gentoo.raw 8G
# fdisk gentoo.raw
(do your partitioning here)
# losetup -P /dev/loop0 $PWD/gentoo.raw

Now you can format the partitions /dev/loop0pX as you see fit, then mount them in some convenient place. I’ll assume that’s /mnt/vm for now. You’re ready to start copying everything in:

# rsync -aP /usr/mips64el-unknown-linux-gnu/ /mnt/vm/
# rsync -aP /path/to/kernel/tree/modules/ /mnt/vm/

You can use this opportunity to make some tweaks to configuration files, like updating etc/fstab, tweaking etc/portage/make.conf (changing ROOT, removing CBUILD), and setting up a getty on ttyS0. I also like to symlink lib to lib64 in non-multilib environments such as this: Don’t symlink lib and lib64! See below.

# cd /mnt/vm
# mv lib/* lib64
# rmdir lib
# ln -s lib64 lib
# cd usr
# mv lib/* lib64
# rmdir lib
# ln -s lib64 lib

When you’re done, unmount.

First boot

Run QEMU with the following arguments:

# qemu-system-mips64el -M malta \
    -kernel /path/to/your/kernel/vmlinux \
    -hda /path/to/your/gentoo.raw \
    -append "root=/dev/sda1 console=ttyS0,115200 init=/bin/bash" \
    -serial stdio -nographic -net nic -net user

It should boot straight to a bash prompt. Mount the root read/write, and then you can make any edits you need to do before boot, such as changing the root password. When done, re-mount the root as read-only, then exec /sbin/init.

# mount / -o rw,remount
# passwd
… etc
# mount / -o ro,remount
# exec /sbin/init

With luck, it should boot to completion.

Step 5: Making the VM a system service

Now, it’d be real nice if libvirt actually supported MIPS VMs, but it doesn’t appear that it does, or at least I couldn’t get it to work.  virt-manager certainly doesn’t support it.

No matter, we can make do with a telnet console (on loopback), and supervisord to daemonise QEMU.  I use the following supervisord configuration file to start my VMs:

[unix_http_server]
file=/tmp/supervisor.sock   ; (the path to the socket file)

[supervisord]
logfile=/tmp/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB        ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10           ; (num of main logfile rotation backups;default 10)
loglevel=info                ; (log level;default info; others: debug,warn,trace)
pidfile=/tmp/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false               ; (start in foreground if true;default false)
minfds=1024                  ; (min. avail startup file descriptors;default 1024)
minprocs=200                 ; (min. avail process descriptors;default 200)

; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; use a unix:// URL  for a unix socket

[program:qemu-mips64el]
command=/usr/bin/qemu-system-mips64el -cpu MIPS64R2-generic -m 2G -spice disable-ticketing,port=5900 -M malta -kernel /home/stuartl/kernels/qemu-mips/vmlinux -hda /var/lib/libvirt/images/gentoo-mips64el.raw -append "mem=256m@0x0 mem=1792m@0x90000000 root=/dev/sda1 console=ttyS0,115200" -chardev socket,id=char0,port=65223,host=::1,server,telnet,nowait -chardev socket,id=char1,port=65224,host=::1,server,telnet,nowait -serial chardev:char0 -mon chardev=char1,mode=readline -net nic -net bridge,helper=/usr/libexec/qemu-bridge-helper,br=br0

The following creates two telnet sockets, port 65223 is the VM’s console, 65224 is the QEMU control console. The VM has the maximum 2GB RAM possible and uses bridged networking to the network bridge br0. There is a graphical console available via SPICE.

All telnet and SPICE interfaces are bound to loopback, so one must use SSH tunnelling to reach those ports from another host. You can change the above command line to use VNC if that’s what you prefer.

At this point, the VM should be able to boot on its own. I’d start with installing some basic packages, and move on from there. You’ll find the environment is very sparse (my build had no Perl binary for example) but the basics for building everything should be there.

You may also find that what is there, isn’t quite installed right… I found that sshd wasn’t functional due to missing users… a problem soon fixed by doing an emerge -K openssh (the earlier step will have produced binary packages).

In my case, that’s installing a decent text editor (vim) and GNU screen so I can start a build, then detach.  Lastly, I’ll need catalyst, which is Gentoo’s release engineering tool.

At the moment, this is where I’m at.  GNU screen has indirectly pulled in Perl as a dependency, and that is building as I type this.  It is building faster than the little netbook does, and I have the bonus that I can throw more RAM at the problem than I can on the real hardware. The plan from here:

  1. emerge -ek @system, to build everything that got missed before.
  2. ROOT=/tmp/seed emerge -eK @system, to bundle everything up into a staging area
  3. populating /tmp/seed/dev with device files
  4. tar-ing up /tmp/seed to make my initial “seed” stage for catalyst.
  5. building the first n64 stages for Gentoo using catalyst
  6. building the packages I want for the netbook in a chroot
  7. transferring the chroot to the netbook

Symlinking lib and lib64… don’t do it!

So, I was doing this years ago when n32 was experimental.  I recall it being necessary then as this was before Portage having proper multilib support.  The earlier mipsel n32 stages I built, which started out from kanaka‘s even more experimental multilib stages, required this kludge to work-around the lack of support in Portage.

Portage has changed, it now properly handles multilib, and so the symlink kludge is not only not necessary, it breaks things rather badly, as I discovered.  When packages merge files to /lib, rather than following the symlink, they’ll replace it with a directory.  At that point, all hell breaks loose, because stuff that “appeared” in /lib before is no longer there.

I was able to recover by rsync-ing /lib64 to /lib, which isn’t a pretty solution, but it’ll be enough to get an initial “seed” stage.  Running that seed stage through Catalyst will clean up the remnants of that bungle.

Feb 172013
 

Well, I was half expecting that it’d happen one day. Gentoo Bug 89744, the bug that saw me promoted to developer on the Gentoo/MIPS team, is now a retirement bug in full swing.

To those in the Gentoo community, I say, thank-you for putting up with me for so long. It is probably time that I moved on though. Real life has meant I’ve got practically no time during my working week to do anything meaningful, and after a week of arguing with computers (largely Ubuntu-based) I come home on a Friday evening not feeling like even looking at a computer. Some weekends, the computer has stayed in my backpack, and not been removed until the following Monday when I return to work.

Thus the time has come, I must be going.

That said, I mostly did enjoy the time I had as a developer. I still remain a Gentoo user, as that seems to be the OS that best fits my usage patterns, and I might pop up from time to time, but I’ll probably maintain a fairly low profile from now on.

I actually didn’t notice the account being shut down, only discovered today in fact, that the redhatter@gentoo.org email address was not working from an Amateur radio colleague. It’s then I thought to have a quick gander and found out what had happened.

This does leave me with two Lemote boxes, that technically no longer belong here.

Remember these? They’re looking for a home now!

I shall enquire, and find out where to send the boxes themselves, or a donation to cover their cost. It is not right that they remain here without some sort of compensation.

This leaves some people without a means of contacting me.  I don’t bother with the instant messengers these days, and definitely not Skype.

Plain old email still works though, you can contact me at stuartl at longlandclan dot yi dot org from now on.  As for the old links on dev.gentoo.org, terribly sorry but that’s outside my control now.


Update:

The Lemote boxes now have a home. Thanks Anthony!

Sep 132011
 

Hi all…

I got fed up of restoring my firmware for the Broadcom wireless chip in my late-2008 model MacBook.  Anyone who has one of these might find the current in-tree versions of net-wireless/b43-firmware is missing files needed by the modern b43 driver (namely ucode16_mimo.fw), and net-wireless/b43-fwcutter doesn’t well, cut it, for extracting the newer files.

If you’ve got a newer 802.11n-based Broadcom chip, you might find the following ebuilds handy:

  • net-wireless/b43-firmware-5.10.56.27.3
  • net-wireless/b43-fwcutter-015 and net-wireless/b43-fwcutter-9999

The first is the firmware mentioned in this post.  It needs a newer fwcutter binary than is provided in Portage.  You’ve got the choice of the latest version, or the bleeding edge via git.  Both work at time of writing, although neither are guaranteed.

The ebuilds are not in-tree, I’ll leave that for the actual maintainer for these ebuilds to pick them up if desired, I’ve put them in an overlay accessed via the following command:

git clone git://git.longlandclan.yi.org/overlays/b43.git

Or you can take a squiz via gitweb.

Jun 202011
 

To whoever were responsible for developing this new feature in the latest Portage releases…

zhouman portage # FEATURES=-test USE=-handbook\ -doc emerge -eukDN --keep-going system kde-meta vim poppler =xulrunner-2.0.1-r1 =vim-core-7.3.189 =gvim-7.3.189 gst-plugins-base vim =gst-plugins-theora-0.10.32 =firefox-4.0.1-r1
Calculating dependencies... done!

!!! One or more updates have been skipped due to a dependency conflict:

app-editors/vim-core:0

(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
~app-editors/vim-core-7.3.189 required by (app-editors/gvim-7.3.189::gentoo, binary scheduled for merge)
(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
=vim-core-7.3.189

!!! The following update(s) have been skipped due to unsatisfied dependencies
!!! triggered by backtracking:

app-editors/vim:0
[binary R ] x11-proto/xf86vidmodeproto-2.3.1
[binary R ] sys-libs/zlib-1.2.5-r2
[binary R ] sys-libs/ncurses-5.9
[binary R ] x11-proto/xproto-7.0.21
[binary R ] virtual/libintl-0
[binary R *] sci-visualization/gnuplot-4.4.2-r1
[ ... ]
[ebuild N *] kde-base/kdebase-meta-4.6.4 USE="(-aqua)"
[binary R *] media-libs/mediastreamer-2.7.3-r3
[ebuild N *] kde-base/kopete-4.6.4 USE="addbookmarks autoreplace contactnotes highlight history jingle nowlistening pipes privacy sms ssl statistics texteffect translator urlpicpreview v4l2 xmpp zeroconf (-aqua) -debug -gadu -groupwise -handbook (-kdeenablefinal) -latex -meanwhile -msn -oscar -otr -qq -skype -testbed -webpresence -winpopup -yahoo"
[binary R *] media-plugins/mediastreamer-ilbc-2.0.3
[ebuild N *] kde-base/kdenetwork-meta-4.6.4 USE="(-aqua) -ppp"
[ebuild N *] kde-base/kde-meta-4.6.4 USE="accessibility nls (-aqua) -sdk -semantic-desktop"

The following keyword changes are necessary to proceed:
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kglobalaccel-4.6.4 **
#required by kde-base/kdemultimedia-meta-4.6.4[mplayer], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/mplayerthumbs-4.6.4 **
#required by kde-base/kdeedu-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/rocs-4.6.4 **
#required by kde-base/kdegames-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kigo-4.6.4 **
#required by kde-base/kajongg-4.6.4, required by kde-base/kdegames-meta-4.6.4[python], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/oxygen-icons-4.6.4 **
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kdebase-menu-4.6.4 **
#required by kde-base/kdeutils-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)

[...]

NOTE: This --autounmask behavior can be disabled by setting
EMERGE_DEFAULT_OPTS="--autounmask=n" in make.conf.

Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT).
zhouman portage #

THANK-YOU

You’ve just made my life trying to install and test big collections of software in Gentoo/MIPS much easier. 🙂

Jun 192011
 

Well, I’ve been meaning to get around to fixing up svxlink in Gentoo for a long time now. For those who don’t know, svxlink is a client and server for the EchoLink amateur radio linking system.

We had to stop releasing the Qtel client, as it relied on Qt3 which we no longer ship in Gentoo.  On top of this, the ebuild installed non-Gentoo init scripts, fails to build with gcc-4.6 and fails due to underlinking.  (My thanks go to Diego for pointing these flaws out.)

At the moment I’m working on the first problem, which is that the builds that were in-tree are crusty and old.  svxlink did release version 11.05 not long back, and ohh yes, they’ve changed their versioning scheme too to match Ubuntu.  However, their trunk branch is still dependent on Qt3 if you want Qtel.  There is an experimental Qt4 branch, which is what I’ve been working with.

One irritation I had was trying to make it possible to install the client component or the server component.  svxlink has its own, very custom, build system based on recursive makefiles.  (Yes, I know, considered harmful and all that.)  The build system first builds the core libraries, then it starts looking at Qtel and svxlink’s server components.  The first thing was to try and split these up.

The new ebuilds will introduce a svxlink-libs package.  This is relatively straightforward, and it just builds & installs the libasync, libechlib and liblocationinfo libraries.  The catch is when building qtel and svxlink, the build system looks for the built binaries inside the source tree.

I have submitted a patch upstream that remedies this.  Eventually I’ll look at how we can fix some of the other flaws in the build system.  So far I’m still battling svxlink itself, but I soon will have svxlink-libs and qtel packages available for testing in the Portage tree.  svxlink itself will also need to wait until I can set up a test node on simplex somewhere… my O2 looks like a likely possibility.

I’ll keep you all informed as this progresses.  Qtel appears to be working (although I’m battling some funnies with the sound device on the Apple MacBook)… just a matter of fixing some issues with the build system for svxlink and I should be able to have svxlink back in the tree once again.

May 162011
 

This weekend just gone I was at Imbil helping out with the International Rally of Queensland, reporting scores for the car rally there.  This was my first look at packet radio in action.  Prior to this I had enabled the amateur radio options in the kernels I built, but never tried actually hooking radio to computer.  I shall be posting some notes on how I got this working…

zhouman ~ # uname -a
Linux zhouman 2.6.35.7-lm2f-nb #2 Wed Oct 13 00:42:58 EST 2010 mips64 ICT Loongson-2 V0.3 FPU V0.1 lemote-yeeloong-2f-8.9inches GNU/Linux
zhouman ~ # ifconfig sm0
sm0 Link encap:AMPR AX.25 HWaddr VK4MSL
inet addr:172.31.32.1 Bcast:172.31.32.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:256 Metric:1
RX packets:365 errors:0 dropped:0 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:24236 (23.6 KiB) TX bytes:6850 (6.6 KiB)

zhouman ~ # mheard
Callsign Port Packets Last Heard
VK4EA-9 sm0 6 Mon May 16 17:59:12
VK4NRL-9 sm0 1 Mon May 16 17:58:40
VK4VP-1 sm0 8 Mon May 16 17:58:38
VK4RAI-3 sm0 9 Mon May 16 17:57:58
VK4TIM-9 sm0 14 Mon May 16 17:57:56
VK4TDI-1 sm0 2 Mon May 16 17:57:39
VK4DC-1 sm0 15 Mon May 16 17:57:07
VK4TEC-9 sm0 120 Mon May 16 17:56:08
VK4FY-1 sm0 18 Mon May 16 17:54:38
VK4RMO-3 sm0 1 Mon May 16 17:54:33
VK4RGC-3 sm0 3 Mon May 16 17:52:48
VK4RC-1 sm0 8 Mon May 16 17:51:29
VK4FIL-1 sm0 4 Mon May 16 17:46:44
VK4RIL-13 sm0 4 Mon May 16 17:45:43
VK4RBR-3 sm0 5 Mon May 16 17:42:59
VK2RDO-3 sm0 2 Mon May 16 17:41:19
VK4RRC-13 sm0 3 Mon May 16 17:36:39
VK2JUB-1 sm0 2 Mon May 16 17:34:44
VK4BNQ-1 sm0 1 Mon May 16 17:26:58
VK4LDA-9 sm0 2 Mon May 16 17:24:59
VK2POO-9 sm0 9 Mon May 16 17:21:24
VK2XFL-9 sm0 1 Mon May 16 17:21:09
VK4RSR-3 sm0 1 Mon May 16 17:20:04
VK4IE sm0 1 Mon May 16 17:15:04
VK4ALJ-3 sm0 1 Mon May 16 17:15:00
VK4HPW-9 sm0 5 Mon May 16 17:13:23
zhouman ~ #

Set-up consisted of:
Linux kernel on Lemote Yeeloong, latest soundmodem driver, Yaesu FT-897D, homebrew interface cable plugged into Yeeloong’s onboard sound card, USB serial driving BC547 in interface cable for PTT.

zhouman ~ # cat /etc/ax25/soundmodem.conf
<?xml version="1.0"?>
<modem>
<configuration name="FT897-D">
<chaccess txdelay="150" slottime="100" ppersist="40" fulldup="0" txtail="10"/>
<audio type="alsa" device="plughw:0,0" halfdup="0" capturechannelmode="Mono"/>
<ptt file="/dev/ttyUSB0"/>
<channel name="Channel 0">
<mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1"/>
<demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1"/>
<pkt mode="MKISS" ifname="sm0" hwaddr="VK4MSL" ip="172.31.32.1" netmask="255.255.255.0" broadcast="172.31.32.255"/>
</channel>
</configuration>
</modem>
zhouman ~ #

I’ve shut it down for now, but I’ll give it a bit more work on 145.175MHz tomorrow. Once I get something working, I might set something up using the O2 or one of the Fulongs (probably the latter) and see about getting soundmodem back into Gentoo.

Update: After hand-editing the ebuild to enable APRS support, I can successfully report that not only is soundmodem working, but so is Xastir on my Yeeloong, as can be seen on aprs.fi.

Apr 232011
 

Well, been some time now since I announced the start of some µClibc stages.  So far, not much has happened there other than the fact that I’ve successfully hard-locked the Fulong 2E system that I tried compiling on.  This is despite compiling with binutils-2.21 and using -Wa,-mfix-loongson2f-nop… which is usually enough to prevent lockups.  Clearly there’s further erratum that I’m hitting, I might try later on the Qube and see where that gets us, agonisingly slow might be better than the current pace.

Generic N32 MIPS-III little endian continues to remain unavailable due to an issue compiling Python 2.7, and unfortunately my N32 chroot on the Yeeloong broke when I upgraded glibc (the primary reason why I began doing a generic MIPS3 build on the Qube using Matt’s MIPS4 build).  I will get back onto this eventually.

On other news since the purchase of the MacBook I’ve been able to leave my Yeeloong sit at home running continuously to update the entire system.  Qt 4.7.2 gave me some grief — it seems at least on mipsel, qmake segfaults during the initial build of qt-core …

mipsel-unknown-linux-gnu-g++ -o "/tmp/portage/x11-libs/qt-core-4.7.2-r1
/work/qt-everywhere-opensource-src-4.7.2/bin/qmake" project.o property.
o main.o makefile.o unixmake2.o unixmake.o mingw_make.o option.o winmak
efile.o projectgenerator.o meta.o makefiledeps.o metamakefile.o xmloutp
ut.o pbuilder_pbx.o borland_bmake.o msvc_vcproj.o msvc_vcxproj.o msvc_n
make.o msvc_objectmodel.o msbuild_objectmodel.o symmake.o initprojectde
ploy_symbian.o symmake_abld.o symmake_sbsv2.o symbiancommon.o registry.
o epocroot.o qtextcodec.o qutfcodec.o qstring.o qtextstream.o qiodevice
.o qmalloc.o qglobal.o qbytearray.o qbytearraymatcher.o qdatastream.o q
buffer.o qlist.o qfile.o qfsfileengine_unix.o qfsfileengine_iterator_un
ix.o qfsfileengine.o qfsfileengine_iterator.o qregexp.o qvector.o qbita
rray.o qdir.o qdiriterator.o quuid.o qhash.o qfileinfo.o qdatetime.o qs
tringlist.o qabstractfileengine.o qtemporaryfile.o qmap.o qmetatype.o q
settings.o qlibraryinfo.o qvariant.o qvsnprintf.o qlocale.o qlinkedlist
.o qurl.o qnumeric.o qcryptographichash.o qxmlstream.o qxmlutils.o  -Wl
,-O1 -Wl,--as-needed                           
floatmath auto-detection... ()                                         
/tmp/portage/x11-libs/qt-core-4.7.2-r1/work/qt-everywhere-opensource-sr
c-4.7.2/config.tests/unix/compile.test: line 71: 25542 Segmentation fau
lt      "$OUTDIR/bin/qmake" -nocache -spec "$QMKSPEC" "CONFIG+=$QMAKE_C
ONFIG" "CONFIG-=debug_and_release" "LIBS*=$LFLAGS" "LIBS+=$MAC_ARCH_LFL
AGS" "INCLUDEPATH*=$INCLUDEPATH" "QMAKE_CXXFLAGS*=$CXXFLAGS" "QMAKE_CXX
FLAGS+=$MAC_ARCH_CXXFLAGS" "QT_BUILD_TREE=$OUTDIR" "$SRCDIR/$TEST/$EXE.
pro" -o "$OUTDIR/$TEST/Makefile"                                       
gmake: *** No targets.  Stop.                                          
floatmath disabled.                                                    
... etc for numerous other modules.

qt-4.6.3 builds without issues, but this is not sufficient for KDE 4.6.  I’m still investigating.  hyperestraier also fails to build, but only if you have USE=debug set, disable that USE flag and it builds without issues.

Fingers crossed, I can get Qt 4.7 and KDE 4.6 to build, and that there aren’t any issues.  Previously libkjs used to be quite unstable which is one of the main reasons I have not keyworded any release of KDE 4 for MIPS.  Yes, you could dodge around it and have a usable desktop, but I didn’t consider it working well enough for keywording.

Mozilla stuff will need some loving too.  I hope to upgrade to Firefox 4.0 on MIPS, see how that goes.  One of these days I’ll get onto tackling Thunderbird.  Sadly my life away from Gentoo intervenes and thus my plans frequently get put on the backburner as work demands my attention elsewhere.

Apr 102011
 

Well, I’ve done some tinkering with Gentoo/Prefix on MacOS X.  Not bad so far, although there’s a lot of packages not keyworded… (a bit like MIPS) and some packages I miss from regular Gentoo (e.g. crossdev).  However, we can work on sorting this out over time.

For those of you who aren’t particularly fond of going on a copy/paste fest from the documentation, I decided rather than sit there all night and manually do it, I’d code up a script to do it for me.  Behold: Gentoo MacOS X bootstrap script.

Usage:

$ export EPREFIX="${HOME}/.gentoo/amd64"
$ export CHOST="x86_64-apple-darwin10"
$ mkdir -pv "${EPREFIX}"
$ sh do-bootstrap.sh
Mar 152011
 

Well, one thing I’ll need to investigate… I’ve been battling a slightly broken bzip2 which when compressing some files, would cause the whole machine to lock up.  Environment is µClibc-0.9.31 based, using gcc-4.5.2.

Everything compiled with the CFLAGS: “-Os -pipe -mips1 -Wa,-mfix-loongson2f-nop”.  The latter flag is really for Loongson 2F but I find it helpful on 2E as well.  Things seemed to go well, except that I had no end of problems with the machine locking up when running bzip2 on some files.  I found it reproduceable while building autoconf within Catalyst stage 1.

It would appear it’s a compiler issue, as when I rebuilt bzip2 using the CFLAGS: “-O2 -march=loongson2e -Wa,-mfix-loongson2f-nop”, it worked fine.  I will have to investigate this further.  I don’t think it’s a MIPS-I vs Loongson 2E issue, my hypothesis is that -Os generates some instructions that Loongson 2E doesn’t like, as I normally don’t have any problems running MIPS I binaries… the thing that’s significantly different is -Os vs -O2.

Mar 122011
 

Well, it seems I might have µClibc stages going again, at least for little endian initially, then I might fire up one of the SGI boxes and see about a big-endian version.  For a long while, Gentoo/MIPS support for this lightweight C library was all but missing ever since an ABI change broke the µClibc port back around 2006.

I’ve tried on several occasions to build a new environment, and often I was met with technical difficulties which prevented me from producing a working environment.  Recently, I downloaded Rob Landley’s Aboriginal Linux distribution, both big and little endian variants, and took it for a spin.  Having done that, I’m pleased to report that I now have a µClibc chroot that’s merrily compiling various components of the Gentoo system, and will soon be sufficient to make a seed stage for bootstrapping the port once again.

This should mean new netboot images in the medium term for all little-endian ports (and proper ones too, not glibc-based hacks) and new images for SGI Indy (R4000) and O2.  In theory, support for Octane and Indigo2 R10000 is possible, however the systems I have are no longer functional, only my Indy and O2 still work, thus it’s impossible for me to test media for other systems.  Fingers crossed this initial build will go to plan, and we’ll have shiny new stages shortly.