Redhatter’s Web Blog

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.

On my recent experiments with Bluetooth on my father’s laptop, I decided I’d go and get a dongle to experiment with it on my own laptop. So today I popped into Jaycar and picked up a $30 Bluetooth dongle.

The unit is based on the Broadcom BCM2035 chipset. On the train heading home, I plugged it in, and noticed that after compiling the required drivers into the kernel, hci-usb popped up, and created a hci0 device. So I guessed that meant everything was working. Of course, I knew I’d still need the BlueZ stack installed, so I waited until I got home before doing further experiments.

Well… I’m home now, got BlueZ installed (v3.28, and firmware v1.1) along with KDEBluetooth (1.0 beta8). Then I dug out the headset, switched it on, and tried to associate the pair. Nothing. Tried again, and again… unplugging and replugging in the dongle, restarting the daemons… Nada… Zilch.

Hmmm… So I look around, there was mention of the hciconfig command, in particular using it to enable the device. Either my device is in a coma, or something is wrong with the software. I haven’t got Windows installed on this laptop to experiment (I managed to hose it the other day when I accidentally typed sudo mkdosfs /dev/sda whilst formatting a floppy on sdb… Ooops!). Anyway…

This is how the device identifies itself…

wander ~ # cat /proc/bus/usb/devices
[...]
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=2035 Rev= 1.00
S: Manufacturer=Broadcom Corp
S: Product=BCM2035B
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
[...]
On plugging the device in, the dmesg prints:
wander ~ # dmesg
[ 7039.423795] usb 1-1: new full speed USB device using uhci_hcd and address 7
[ 7039.635328] usb 1-1: configuration #1 chosen from 1 choice
[ 7039.952188] Bluetooth: HCI USB driver ver 2.9
[ 7039.954436] usbcore: registered new interface driver hci_usb

hciconfig shows:
wander ~ # hciconfig
hci0: Type: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING PSCAN
RX bytes:4630 acl:0 sco:0 events:107 errors:0
TX bytes:2409 acl:0 sco:0 commands:106 errors:0
If I try the trick of bringing the device down, then back up again, I get the following:
wander ~ # hciconfig hci0 down
wander ~ # hciconfig hci0 up
wander ~ # hciconfig
hci0: Type: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING PSCAN
RX bytes:5582 acl:0 sco:0 events:131 errors:0
TX bytes:3001 acl:0 sco:0 commands:130 errors:0
wander ~ # dmesg
wander ~ # tail /var/log/everything/current
Mar 20 22:24:46 [hcid] HCI dev 0 down
Mar 20 22:24:46 [hcid] Stopping security manager 0
Mar 20 22:24:46 [hcid] Device hci0 has been disabled
Mar 20 22:24:48 [hcid] HCI dev 0 up
Mar 20 22:24:48 [hcid] Device hci0 has been added
Mar 20 22:24:48 [hcid] Starting security manager 0
Mar 20 22:24:48 [hcid] Device hci0 has been activated

This doesn’t fix the issue, and I’m left exactly where I started.  I’m not sure what’s going on… at the moment I don’t have the time to debug the situation, but if anyone has any suggestions (no, I’m not buying another Bluetooth dongle) — I’d happily give them a try.

Hi all,
Just to let you all know, I’ll be camping over the Easter long-weekend (Good Friday through to Easter Monday), on a private property outside Tenterfield, NSW.

There’s no internet link or mobile phone coverage here, so I won’t be online. If you happen to be around the Tenterfield area, you might get me on the 2m standard simplex frequency, 146.500MHz. (There aren’t any repeaters in the area at all, let alone IRLP/EchoLink connected ones.)

If you strike problems, best to contact me by email, and I’ll get back to you when I return on Monday. If release engineering put out another snapshot before Thursday evening (UTC+10) then I’ll try to get the boxes here building it whilst I’m away.

Both Loongson boxes will remain online, vapier has root access to both, so after getting approval from the senior MIPS devs, see him for actual access to the boxes in my absence.

Anyway… there will of course, be the obligatory posts with pics of the trip when I return.

Happy Easter all.

Hi All,

I have made available, stages based on the Gentoo 2008.0 Beta1 snapshot, for you to test on your hardware.  New in this release, is the introduction of big-endian stages compiled for MIPS1, as well as little-endian stages for MIPS3.  This should suit generic big-endian users, and Loongson users respectively.  (Of course, if you’re using hardware other than SGI, Cobalt or Lemote hardware, you’ll have to figure out most things yourself — we can’t offer support for other hardware.)

For now, you’ll find them on my devspace.  If you strike problems, please let me know and I’ll try to get the problems fixed for the final 2008.0 snapshot.

• Little-Endian (mipsel): http://dev.gentoo.org/~redhatter/mips/cobalt/stages/experimental/
• Big-Endian (mips): http://dev.gentoo.org/~redhatter/mips/sgi/stages/experimental/

I’ll be taking them for a spin to make sure everything is fine, but I’d appreciate any feedback from users.  These stages are experimental, as they’re based on a beta snapshot — if you’re setting something up for a production environment (if you are, you’re braver than I am), I’d recommend using the older 2007.1 stages instead.

Some of you may recall a recent post in which I described my idea for building my own high-fidelity wireless headset. The recommendation from most people was just to buy a bluetooth headset. Today I was in the hardware store here in The Gap, looking around actually for something totally unrelated — mounting brackets for an antenna (which I didn’t find) — I happened to see they were selling some earmuffs with builtin bluetooth headset and AM/FM radios for about AU$100. This is cheaper than I had seen similar sets elsewhere… so I figured I’d bite the bullet and give them a shot. At worst, I’d have a pair of earmuffs (may come in useful if I start working in a noisy environment), with a radio built in.

They’re manufactured by Bullant, and can come in three forms: bluetooth headset only, radio only, and radio+bluetooth headset (model ABA700). They apparently provide about 85dB attenuation, meeting AS/NZS SLC80:11:Class1. Protocol wise, they support the SCO profile, and the documentation (single double-sided A4 page) seems to suggest support for A2DP (quote: “You can also listen to music stored on your Bluetooth Mobile Telephone if your Mobile Telephone has that feature” — I can’t imagine people wanting to listen to music at 8kHz, mono, 16-bit).

It took me a while to figure out how to get them going at first. What I didn’t realise, is to hear anything out of the Bluetooth component, one must first turn on the radio and tune it to some station — slightly annoying, but I can live with that. Audio quality with a local FM station is quite good — on-par with most consumer wideband FM receivers. (And noticeably better than the amateur set I’ve been using lately… but that’s hardly surprising given its purpose.)

However, I was right to be concerned about compatibility. Windows XP won’t talk to them at all — okay, no great loss, I hardly use that “OS” these days. They do work in Linux, both using the old snd-bt-sco+btsco driver, and using the newer bluez ALSA plugins. Audio quality is limited to what SCO is capable of, again, annoying as I prefer to record voice at 16kHz as clarity is slightly better, but I can live with 8kHz — I’ll have to read up on how to get A2DP working. However, I’m so far, only able to reliably use them, with apps that natively support ALSA.

Using the snd-bt-sco driver… I find parts of my speech get cut off. This was tested using Qtel (EchoLink client) and joining the *ECHOTEST* conference (an EchoLink conference that exists purely for testing a station).

Using the newer ALSA plugin, things seem to work okay, but nothing OSS-based will talk to it. Audacity is very hit-and-miss in detecting the headset. Qtel won’t talk to it properly even via the aoss wrapper. I suspect my portaudio v19-based lecture recording app will have similar problems, as it generally only seems to work properly with OSS.

It’s a great start… but I’m not sure this is quite the holy grail I’m after. I’ve been testing this on my father’s laptop, which has onboard Bluetooth. So naturally this means I’ll have to also invest in a cheap USB Bluetooth dongle for my laptop. I may wind up continuing down the path of homebrewing my own set, since it looks like the more flexible solution, and least likely to suffer compatibility issues with the applications I use. Still, it’s been a worthwhile exercise, and certainly I’ll have to keep an eye out for developments in Bluetooth support in future.

Postscript: Now that I have a Bluetooth headset, I’m in the market for a simple Bluetooth transceiver (using H2DP or SCO) that provides input/output jacks that can be hooked to standard analogue devices such as my amateur transceiver (Kenwood TH-F7E) and my non-Bluetooth enabled mobile phone (Nokia 3310).  I’m aware of RPF Communication’s TalkSafe devices — that’s the sort of thing I’m after.  If anyone knows of something similar to that, available here in Australia, I’d be most interested.