Last Friday (23rd), was the night of the Brisbane Amateur Radio Club Annual General Meeting. Anyone who has been involved in a small club or community group, knows how dangerous it can be to attend these meetings — if you don’t intend to stand for a position, especially when most of the people holding executive positions are stepping down.

Well, needless to stay, the vast majority of the membership was away… leaving about 8~9 of us in the room. One of the newer members wound up with job of President, along with myself scoring the job of editor for QSP, the club newsletter. There will be more on this in the next issue of QSP. I’m still toying with ways I can produce that newsletter efficiently — the three options I’m looking at are (in order of preference): LaTeX, OpenOffice.org and Scribus. I put Scribus last as I’m not familiar with it, and at last check, didn’t easily run on Win32. LaTeX is available for Win32 as part of Cygwin amongst other sources, as is OpenOffice.org.

In any case, this is a new role for me, and I look forward to the challenge.

News items for QSP can be sent directly to the new email alias I have for this: qspnews@longQlanRdcMlan.yi.org (remove the interference). Preferred formats for text are plain ASCII text (just put it in the body of the email), OpenDocument Text (as produced by OpenOffice.org), HTML, LyX and LaTeX. Preferred formats for diagrams are PDF, SVG, EPS, PNG or JPEG (the last one is best reserved for photos) — just indicate in the text roughly where you want these diagrams put, and I’ll try to fit them in as best I can.

In other news, I now have some HF kit. BARCfest saw me acquiring a second hand transceiver, a Kenwood TS-120S. Presently I’ve just got it hooked to a simple 40m dipole, and I mainly hover around the WICEN frequency on 40m (7.075MHz LSB). The eventual plan is to set up a full-wavelength 40m loop in the ceiling space of the house (we have a tiled roof) and hook that up to an ATU. I have purchased an ATU, and hope that will arrive some time this week, so before long, I should be contactable on HF. I’m permitted 10W PEP on 80m, 40m, 15m and 10m, and am able to transmit USB, LSB and (once I learn morse), CW.

Hi All…

Just figured I’d bring you all up to date on how the new release is coming along. At this time, all little-endian MIPS builds are complete… and the big-endian builds are nearing their completion, with the MIPS3 BE build expected to be completed in a few hours. Only MIPS4 BE remains.

A number of users have had issues with the beta stages that I released earlier, in particular, there are known oddities with rsync and rm. These oddities arise when an old kernel (<2.6.19) is used. You’ll want at least kernel 2.6.20, preferably 2.6.22 or 2.6.23 running on the machine to use these stages.

Using the existing netboot images, you should still be able to at least set the disk up, extract the contents, then boot a precompiled kernel that’s sufficiently recent. How do you get the kernel? Well, for an up-to-date kernel, your easiest bet is to cross-compile. On a fast box (x86, AMD64… whatever), install genkernel, then use the command genkernel -t mips64-unknown-linux-gnu -S1 (or mips64el, or use mips/mipsel for a 32-bit compiler) to generate the cross compiler. Then use ebuild /path/to/mips-sources-VERSION.ebuild unpack to unpack a copy of the sources to your PORTAGE_TMPDIR (/var/tmp/portage by default). Then follow the instructions in the handbook as per normal, specifying CROSS_COMPILE=mips64-unknown-linux-gnu- (or mips64el…) when running make.

To get the kernel modules onto the machine, run make modules_install INSTALL_MOD_PATH=/somewhere, then tar these up. Then from the SGI box, use scp inside the chroot to download them, and unpack into /. Use the same procedure to fetch the vmlinux (or vmlinux.32) binary from your build host.

I’ve put up a new netboot image for Cobalt, although I’ve noticed 2.6.23 mips-sources has some stability issues with Cobalt, so I may yet put up another netboot image. Lemote users should find the existing images are sufficiently recent to run these stages, so I haven’t worried about putting newer images up for that platform. I’m not sure how the big-endian netboot images are constructed, so at this time, I’m not able to provide images for these platforms. (Plus, I can only test R4k IP22, IP28 or RM5k2 IP32… my Octane is dead for now.)

I hope to be uploading some material in a fortnight’s time for you to all try out.

Hi all…

Lately I’ve been busy with university stuff. In particular, my final year project, which is investigating Controller Area Networks, in the context of the Atmel AT91SAM7X256 MCU.  These microcontrollers are a low-cost system-on-chip based around the ARM7TMDI core.  This particular one includes 64KB RAM, 256KB flash, RS-232, device-side USB 2.0, 10/100Mbps ethernet, and of course, a CAN interface.

When I first started looking into this project, I was thinking about using Linux and SocketCAN… well, needless to say the moment I saw the specs on the exact board I was using (the AT91SAM7X-EK), I soon realised Linux was simply out of the question.  That doesn’t mean however, that one is stuck to using proprietary kernels and toolchains.  The following, are some notes on how to code for these things… and where I’m at.

Kernel

You don’t have to use a kernel of course, you can code bare-iron, but I decided to go with a multitasking kernel to make my life easier — I can code each thread to do something basic, and let the kernel manage the IPC and task switching for me, hooking them together.  There are a few options out there, but so far the option I’m liking the most, is the FreeRTOS kernel.  This kernel is free software under the GNU GPL, and supports many platforms, including ARM7.

Toolchain

There are a few compiler toolchains you can use for this board.  The DVD that comes with the board, includes a version of IAR Embedded Workbench, which isn’t too bad, but unless you pay for a license, your code size is limited to 32KB.  The GNU toolchain however, is very mature for the ARM7 platform… and getting a toolchain up and running isn’t too difficult.

FreeRTOS can be built using IAR, and indeed to get me started, that’s what I did.  Once I was comfortable with the system though, I turned my attention to getting a GNU toolchain running on my laptop.  The toolchain needs to be built, targetting the arm-elf platform, using the newlib C library.  Thumb mode, multilib, and interworking support need to be included in this toolchain to build FreeRTOS.  There are numerous prebuilt toolchains, and guides on how to do them from source… but I wound up going my own way…

In my devspace, you’ll find a compressed Makefile.  Download this into an empty directory, decompress it, then rename it to Makefile.  Gentoo users, may find it helpful to symlink their distfiles directory (/usr/portage/distfiles for most people) to ’src’ — the Makefile uses the same toolchain sources as Gentoo.  Edit Makefile to point to your local Gentoo mirror (I use these mirrors because they’ve got all the sources in one place), then run make.  With luck, it’ll build everything and install it for you.  It runs as a user, then uses sudo to copy the files to /usr/local where they are to be installed.

At the end, you’ll be left with a full arm-elf toolchain, based on GCC 4.2.3, binutils 2.18 and newlib 1.15.0.

Building the FreeRTOS kernel

FreeRTOS comes with numerous demos which can be used as starting points for your own projects.  The best one for the AT91SAM7X using GCC, is the lwIP_Rowley_ARM7 demo.  This demo does three things:

1. Runs a webserver displaying some task statistics
2. Flashes the onboard LEDs to indicate it’s working
3. Emulates a CDC-ACM device, writing characters to it at 115200 baud 8N1.

To start, go into the Demos/lwIP_Rowley_ARM7 directory, and rename ‘makefile’ to ‘Makefile’.  To set the IP configuration, edit EMAC/SAM7_EMAC.h and change the IP address settings as appropriate (line 69 onwards).  Save this, then type make.  It should go ahead and build an rtosdemo.bin file, which is your executable to be flashed.

Flashing the project

This is where my usage of free software came unstuck.  There are a few projects that theoretically allow you to flash these devices.  The kit comes with a SAM-ICE J-Tag, which is equivalent to the J-Link device developed by Segger.  These, to my knowledge, do not work using J-Tag tools available under Linux.  You could use one of the Wiggler-style J-Tag cables, but I don’t have one of those at my disposal.

The AT91SAM7X has a trick up its sleeve though.  If you power the board up for a few seconds with the ERASE jumper enabled, power it down, then power it back up with the ERASE jumper removed, it’ll revert back to using SAM-BA firmware.  SAM-BA allows for the board to be flashed either via the DBGU serial port, or, via a CDC-ACM USB device.  Tools such as Sam_I_Am, then connect to the /dev/ttyACM0 device created.  For this to work, a small patch needs to be applied to the cdc-acm driver in the Linux kernel (This same patch also adds support for the FreeRTOS CDC device created by the above demo).

For me, this has been the most promising, but hasn’t quite gotten things going… I’m able to flash the device, but for some reason, it sees it as an AT91SAM7S256… and the thing won’t boot.  If anyone has some pointers as to what could be going wrong, I’m all ears.

At the moment, I’m using the SAM-BA flashing utility available from Atmel’s website free of charge.  This is a Windows NT utility requiring administrator privileges, which is suboptimal, but so be it, it works, I just boot my desktop PC into Windows 2000, and access the output binary via SMB.  This works, and isn’t too painful.  It may also work in a VM, I haven’t tried yet.

I’ll keep tinkering with the Linux utilities, because I feel it’s almost there… I’ve thrown this post up so that others who may be looking for this information, have somewhere to work from.  Apart from the little issues I’ve had, I’ve found this board quite enjoyable to work with.  I can use mostly my own tools to work with the files, and the C compiler is both stable (unlike the GNU toolchain for Altera Nios II) and fully ANSI C compliant (unlike the Z-World compiler used on Rabbit Semiconductor devices) — a nice change indeed.

http://en.wikipedia.org/wiki/ANZAC

Hi all…

There seems to be a little confusion as to whether the PS2 is supported by Gentoo. To clarify, it isn’t. There was never any effort to officially support the PS2. Some unofficial work did begin some years ago, however that work ceased fairly early on, and there has been no interest in continuing it.

There are a number of technical reasons why the PS2 is not supported.

First and foremost, the CPU is a real bastardised piece of work. It implements a custom instruction set, which is a hodge podge of MIPS I, MIPS II, MIPS III and MIPS IV, with some special instructions thrown in. It doesn’t fully implement any of the aforementioned instruction sets. So binaries such as my mipsel1 stages, will not work — you’ll hit illegal instruction errors fairly early on.

Secondly, the patches necessary for the kernel, and toolchain, are based on a really ancient set of packages. The kernel released with the PlayStation II Linux kit (2.2.1), was a year old when the first PS2 hit the shelves. Not so bad then, but the kernel was never properly maintained. Even today, unofficial efforts have only gotten as far as 2.4.3x-series. The toolchain is still quite ancient, at best, gcc-3.3 from what I recall, is the best they’ve got. Maybe they’ve got as far as 3.4… who knows…

Thirdly, the memory on the PS2 is restricted to 32MB. This is soldered on-board, can’t be upgraded. Gentoo/MIPS will not build most packages with 32MB RAM. Once upon a time, I could just build stages with 64MB on my Qube2, if I shut down things like MySQL — not anymore, I need 128MB to do this today. uClibc could be feasible, but you’d still have problems with the “special” CPU. Virtual memory doesn’t help — even if you had 2YB of swap, it wouldn’t stop builds dying.

Other MIPS-based consoles, such as the original PlayStation (MIPS R3000-based) and the PlayStation Pocket (MMU-less MIPS32r2) are also not supported for similar reasons.  And we (MIPS team) don’t support the PlayStation 3 either — for that, you should talk to the PowerPC team.

Now… I have no complaints about answering questions about what we support/don’t support… but a few points… (this is where my rant starts by the way)

1. Write properly when in the IRC channel. If it’s one thing that’ll quickly get my back up, it’s SMS-like chat on IRC. I’m tolerant of spelling errors and grammatical mistakes, but I won’t tolerate laziness. If a word has vowels in it, include them! It’s not like it’s significantly more effort to press an additional button on a keyboard. If you’re using morse to drive the computer, or have a physical disability that makes typing difficult, fine, declare this up front, and all will be okay, but otherwise, there’s no excuse.
2. Read the documentation! It tells you what we support, and what we don’t. It’s likely your question is answered there already.
3. If we can’t help you with some non-supported platform, we mean it… don’t pester us about it, we’re not going to start supporting a new platform in 5 minutes flat.

The following arrived via email via the Department of Defence… figured you might appreciate it — clearly the Chinese are really keen — this road isn’t my cup of tea!

Try a mountain trail stroll in China …

First, let’s take the cable car up to the start of the trail

Now follow the path

Be sure to hold on to the railing

Keep an eye on the person in front of you

Be very careful when passing someone going in the opposite direction

Now just up a few steps (they are on the left in the picture)

It gets a little steeper here - so put your toes in the holes

A few more steps to go

Finally in sight, the Teahouse!

I’d go almost anywhere for a Beer but a cup of tea?

Hi All…

Whilst building a new netboot image for Cobalt systems, I discovered there’s a bug relating to the PCI handling in the latest kernel ebuild. In short, the pata_via driver is broken out-of-the-box, it’ll complain about being unable to register I/O resources, and the disks will be inaccessible.

To fix — download this patch, and apply it to your source tree using patch -p1 < patchfile, then rebuild your kernel (it’ll take a few seconds). You’ll notice the new kernel should boot successfully.

When Kumba returns, I’ll get him to add it to the mips-sources patchset so this is done automatically.

Hi All…

Those who have been trying out the 2008.0 beta stages I put out recently, probably will have ran into problems with tools like rm and touch not working properly.  It turns out, a series of kernel updates between 2.6.16 (what most of the netboot images are based on, except Cobalt which uses 2.6.13), and 2.6.19-rc5 (what my O2 runs), there have been changes to some of the system calls.  So the newer coreutils breaks on the older kernels.

I’m now in the process of updating the kernels used.  As I type this, I’m recompiling the Cobalt netboot image (same userland tools, just a newer kernel … at some point I’ll recompile the userland too), downloading the 2.6.20 kernel for IP28 users, and I’ll look into IP22 (r4k), IP30 and IP32 as well.

Sadly, R5k IP22 and IP27 will get ignored here — because I don’t have any suitable hardware to test them on.  Otherwise I’d update those too.

I’ll let you all know when the newer netboot images are available.

Well, I’ve tinkered today with the headset and this Bluetooth dongle, and got a little further. Still can’t actually connect to anything, but I am seeing devices pop up in Konqueror under the bluetooth:/ kioslave and hcitool scan actually reports some devices.wander ~ # hcitool scan –flush
Scanning …
20:07:35:xx:xx:xx KF-700
00:1E:E1:xx:xx:xx SGH-A412

I have no idea what the SGH device is … someone’s mobile phone apparently (this dongle has a 100m range). The other device, is my headset. However, hitting the MFB (Mobile Find) button on the headset, does not yield a pin entry request in KDEBluetooth. I’m no closer to actually being able to use this as a means of wireless VoIP.

To reiterate what I have tried:

• Upgraded to latest vanilla kernel: 2.6.25-rc6
• Running latest BlueZ tools in portage: bluez-firmware-1.2 bluez-bluefw-1.0 bluez-libs-3.28 bluez-utils-3.28 bluez-hciemu-1.2
• Using hciconfig to bring the device down, back up, and reset it, enabling various modes (e.g. page scan, inquiry scan, page+inquiry scan)

The following is seen in dmesg when the dongle is plugged in (proceeding text snipped):
[ 2560.963622] usb 5-1: new full speed USB device using ohci_hcd and address 3
[ 2561.133938] usb 5-1: configuration #1 chosen from 1 choice
[ 2561.151391] usb 5-1: New USB device found, idVendor=0a5c, idProduct=2035
[ 2561.151403] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2561.151409] usb 5-1: Product: BCM2035B
[ 2561.151414] usb 5-1: Manufacturer: Broadcom Corp

And hciconfig shows:
wander ~ # hciconfig
hci0: Type: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 377:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:982 acl:0 sco:0 events:28 errors:0
TX bytes:610 acl:0 sco:0 commands:28 errors:0

I’m guessing the address is the problem. And this issue seems to rest with the kernel driver itself, hci-usb. I’ve tried forcing bcm203x to take custody of the device, this doesn’t work at all — the device doesn’t even initialise. So clearly hci-usb is responsible for setting things up — but it isn’t. In sysfs:

wander ~ # cat /sys/bus/bluetooth/devices/hci0/address
00:00:00:00:00:00

Allegedly, the BCM2033 works rather well with Linux, and I see no reason why the BCM2035 shouldn’t, when the code is clearly present. I’d say there’s some edge case that isn’t handled. I’ll ask a little later on the BlueZ mailing lists and see what I can come up with … but I’m posting this here for others’ reference. Later down the track I plan to repeat this exercise on the Lemote boxes (and maybe my O2 as well, if I get a USB card for it) — presently though, I’m doing this on my laptop (which is x86-based).

Again, if anyone has an idea what’s going wrong… I’m all ears.

Hi All,

Yes, I’m back from my trip away. It’s always good to get away from technology for a while. In this case, it was camping on a private property, “Lonesome”, just off the Mt. Lindsay road part way between Basket Swamp and Bald Rock National Parks. We last visited this place two years ago for Easter, photos of that visit are viewable here.

This time around, there were two major activities that took place. Saturday the whole group did a walk up to Little Bald Rock, with some walking cross-country back to the road, and the rest of us (me included) taking a more leisurely walk up the granite slabs back to the Bald Rock picnic area carpark.

During the walk, a number of beetles (one pictured left) with brightly coloured abdomens were sighted — we’re not sure what species they are. We saw at least 4 or 5, mostly on the walk back to the cars. The colours seem to be some kind of warning display when the beetle feels threatened (which I certainly would if 8 or so giants just stepped over me). Not pictured in this photo is the orange band around the beetle’s neck — it’s otherwise a plain brown colour all over.

Sunday saw the group splitting up. Some went to Tenterfield to look around town. Others travelled back to Bald Rock National Park to do Bald Rock itself. We decided to go have a look for some mines that we had located the previous trip. Most of the mines had collapsed in, but one, was in quite good condition, and a few adventurous ones (me included) grabbed our torches and (perhaps unwisely) headed inside.

The area had once been a gold mine, but had long since been abandoned. These days, it’s home to a colony of small bats. These flighty mammals did not appreciate our invasion, and quickly started flying about the tunnel, sometimes clobbering us in the process. They’re mighty difficult to capture on camera — they do not like my 1W LED headlamp shone on them, nor do they appreciate the flash of a camera. I did manage to get one photo (right) of a bat, as well as a couple of them in flight.

There were no incidents thankfully and we spent the morning looking for other mine shafts and tunnels. We found numerous shafts, some quite deep, and a couple of collapsed tunnels. The early part of the afternoon was spent bush bashing our way back to the creek, which we followed back to the campsite.  During this time, many of us accumulated many leeches, some of us scoring over a dozen leech bites.  That afternoon was spent ridding ourselves of the blood-thirsty pests.

All in all, it was an enjoyable weekend. I’m yet to put the panoramas together, at the moment I’m getting clothes washed and camping gear put away. The full series of photos taken mostly by myself, can be found on our gallery site, along with other photo sets from past trips.