Redhatter (VK4MSL)

Gentoo/MIPS o32: Little-endian stagebuilds complete, Big-endian underway

Hi all,

The O32 stage builds for little-endian MIPS systems are now complete, and you will find the stages on my devspace for now at http://dev.gentoo.org/~redhatter/mips/cobalt/stages/.  There you will find stages for:

  • MIPS-I: Suitable for all little-endian MIPS hardware
  • MIPS-III: Best for Loongson-based hardware
  • MIPS-IV: Best for Cobalt Qube2 and RaQ2… Possibly the earlier Qube/RaQ as well.

Note that for the latter two, there are also N32 stages in the pipeline.  N32 overcomes a lot of shortcomings of the O32 ABI and offers better performance overall.  For many years, Gentoo/MIPS has primarily used O32 as the default ABI, with N32 being considered “experimental”.  Zhang Le and others have done a lot of work in the field, and now many applications run fine on N32.  Gentoo will therefore be transitioning over to this newer ABI, leaving O32 available for legacy system support and for experimental targets.

And yes, I’ll have to get to and update the documentation.

Some erratum notes however… These stages all feature a binutils patched for Loongson 2F support.  In the case of the MIPS-I and MIPS-III stages, these were also built with the -Wa,-mfix-loongson2f-nop set in CFLAGS so that these stages will work on Lemote hardware.  (And I needed to do that, otherwise we’d be waiting until Christmas for the Qube2 to finish building.)  So Loongson users should find these stages will work without further patching.  MIPS-IV was not built with the changes to CFLAGS, however these stages will also not run due to incompatibilities with ABI.

Secondly, the issue with /dev still exists… I’m not sure where the bug is, I’m still investigating this.  The following run inside the chroot should correct this issue:

# rm /dev/null
# mknod /dev/null 1 3
# USE=build emerge --oneshot makedev

I’d be naïve to think it probably won’t happen on the big-endian stages… we shall see. Stage 1 for MIPS-I big-endian is already up, with stage 2 well underway. The O2 is just a little quicker than the Qube2 in that regard. 😉 I hope to have big-endian stages up by November.

Qtel and svxlink in Gentoo

Hi all…

It’s been a long time since I took over the maintenance of svxlink in Gentoo, and to be frank, I’ve done basically nothing with it because for the most part, it worked. Much development has gone on upstream, however no newer releases have been made, the only way to get the latest stuff is via SVN. This includes the somewhat experimental Qt4 branch.

Since Qt3’s demise, we’ve had to drop Qtel from the package… prompting bug #336993. There are also issues with initialisation scripts (bug #335307).

Consequently, I decided to try out this new Qt4 branch from SVN. For those playing along at home, the installation instructions are simple enough:

$ svn co https://svxlink.svn.sourceforge.net/svnroot/svxlink/branches/qt4/
$ cd qt4/src
$ make
$ sudo make install

At first, I found it wasn’t working… completely deaf and mute.  Vox didn’t show any sign of hearing my audio from the microphone… and I couldn’t hear anything back.  I tried some other ALSA devices… at this point Qtel only supported one audio device at a time.  Some tinkering, I found I could get it to hear me, but audio was very scratchy.

I had noticed this with aplay too… the problem being that the audio CODEC on the Yeeloong runs at 48kHz, and does not support other rates.  I managed to set up dmix to enforce a 48kHz rate (and give me software mixing as a bonus), then set up a rate converter atop this… but a snag, you can’t record from dmix, and Qtel (or rather libasyncaudio) expected a two-way device.  I suggested to Tobias that having separate microphone and speaker devices would be a good idea.  In double quick time he had updated the Qt4 branch to support this.

Some tinkering, and I managed to get it to hear me, but I was still effectively deaf.  It took some more investigation to track down some of the other issues, but eventually this morning I cracked it.  I had working audio both ways… but received audio was still very scratchy.  Further testing with aplay, after thinking I had solved the problem confirmed this.  More fooling around with .asoundrc ensued.  I finally tried an upgrade of the kernel to 2.6.36-rc7 (linux-loongson-community git HEAD).  Voila, rate converted sound out of aplay came through crystal clear.

I started Qtel and tested it initially on *ECHOTEST*, then on a local repeater (VK4RBR-L node 284321 / 147.950MHz FM) listening via RF as well. No problems there, it seems to be able to make contacts no problems at all. I will have to try svxlink itself at some point to see if I can successfully construct a node using the software, but for now my own node is back on the air after a long hiatus… and I hope to have new ebuilds in the tree.

In particular, svxlink will be split into a few packages.

  • dev-libs/libasync: Asynchronous I/O Library
  • net-libs/echolib: Echolink Communications Library
  • media-radio/svxlink: svxlink and remotetrx
  • media-radio/qtel: Qt Echolink client

I should probably try it on the O2 as well, but Qtel, libasync and echolib will probably get keyworded ~mips too, since they work fine on the Yeeloong   The others… well, I’ve got the parts to make an interface cable for the FT-897D here, in fact, enough for two.  The plan is to make up this interface cable, and try setting up a node on FM simplex.

There’s a second ‘897D as well… however it has a burnt out microphone preamp after a storm blew it up (and a blown up DDS chip, so no SSB or AM TX on this rig).  Miraculously, its finals seem intact as it’ll happily blast out 50W RF on 2m (with no modulation).  If the data interface works okay though, it may work well enough for a temporary 70cm node on one of the local repeaters, VK4RBC Mt. Coot-tha.

In the meantime, my personal node is now up and running again after a long hiatus… Look for VK4MSL in your client or dial  37 37 40 via RF.

Obligatary screenshot of Qtel in action

Obligatary screenshot of Qtel in action on the Yeeloong

Gentoo/MIPS O32: MIPSel-I stages up, others underway

Hi all…

After a long wait, Gentoo/MIPS is on the comeback trail. Okay, I’ll stick my hand up and admit I did a bit of carnage by pulling keywords on vim-7.0 (which might’ve worked with older releases but did not work on this latest release) however we’ll soon have that cleaned up. We’re still in discussions whether to drop the stable keywords on the packages that depended on vim (probably a wise move considering the vim keywords I pulled were stable ones), or whether to promote vim to stable early (probably also fairly safe given the circumstances).

In the meantime, my builds have plodded on. Gentoo/MIPS O32 for MIPS-I little-endian is now complete, with the stage 3 due to finish uploading in 5 hours time… after which, the stage 2 for the MIPS-III little-endian port will begin its upload. Progress can be watched here if people so desire… the upload is throttled at 8KB/sec so that I have some bandwidth left-over for other tasks (it’s a 128Kbps uplink).

MIPS-IV little-endian builds are going slowly… with a snag hit when the Qube2 couldn’t download an amended patchset for binutils (basically patchset 1.1 + patches from bug #338405) because muggins forgot to copy across the envscript specifying my local GENTOO_MIRRORS.

The O2 is also happily compiling a seed stage, for what will be a round of stage builds for big-endian systems… no issues so far and stage builds will commence there in earnest shortly.

It is hoped that we will soon be offering N32 stages to compliment this release very soon. N32 will likely be the future direction for the Gentoo/MIPS port, with O32 being provided for legacy installations and for hardware unable to run 64-bit kernels reliably (or at all).

From here, the next step will be uClibc stages and installation media for the various platforms we support. This should include the newer Lemote systems which have previously enjoyed semi-official support in the past.

Gentoo/MIPS o32: Little-endian stagebuilds continue

Hi all…

Just to let you know, there will be new stages to replace the ones I uploaded recently. Having found a solution for the issues with building on the Lemote computers, I now have MIPS-I and MIPS-III builds going simultaneously on the two Fulong systems. MIPS-IV is being handled by my much slower Qube2. One of the hold-ups was a parallel-build with gcc-4.4.4 (and I note that distcc doesn’t seem to work under Catalyst anyway).

I hope to get big-endian ports bootstrapped soon, with my O2 up and running.

Hunting spambots with bad clocks

Looking back in my email history, I receive a lot of emails that are either back in the past by some significant margin (i.e. 01-01-1970… before I was even born) or way off in the future (in 2038). I just received one today which was a month old.

In almost all cases, these emails are spam. I suppose the idea is that being way back in the past, or way off in the future, it’ll appear ahead or behind all other emails. Not here however. I recently upgraded the server here, and decided to give qpsmtp a try. Being able to code plugins for SMTP is a nice feature, and there’s already a plugin that can look after this very problem. I’ve extended it, so that I’ll tolerate emails up to two weeks old, or no more than two days ahead. (I should probably make this two hours ahead, since the international date line is two hours east of me.. anyway.)

I also tweaked it so that the messages it sends back are more … well … entertaining:

552-Get with the times, 24 Aug 2010 01:08:04 -0000
552  was ages ago.
552-Get back in your tardis, 24 Aug 2011 01:08:04 -0000
552  hasn't happened yet.

In both cases there, the email was flat-rejected. No spam checking, no nothing… it took one look at the Date: header, and tossed it into the bin. The updated check_basicheaders script is here. It’d be nice if more SMTP servers rejected emails that are off in the future, or too far back in the past. I can understand a week in the past, but two weeks is getting just a little old… and until time-travel into the future becomes possible I refuse to believe I can get an email from the future legitimately (and even then, they can come back to the present and re-send it!).

Gentoo/MIPS O32: Fuloong2E Errata

Hi all…

A little note regarding the usage of the latest MIPS-I stages on Fuloong 2E… I found I had a hard-lock compiling some applications which can be possibly traced back to an issue regarding the NOP instruction on the Loongson CPU.  I understood it to only affect 2F-series systems, and also assumed latest binutils had the patch, it seems I was wrong on both those fronts.

A workaround is described on Lemote’s site… compile the fix-nop.c then use it to patch up ld and as… then builds should go smoothly. Now that I know about this issue, I can use the faster Loongson2E machines to build the stages, which means I’ll address the other issues I’ve found and roll out a new set of stages, rather than waiting for the slow Qube2 to chug its way through the build queue.

Gentoo/MIPS: Little Endian MIPS-I stage3 up

Hi all,

Well, after a long plod the stage 3 for MIPS-I little-endian systems is uploaded. I’m working on MIPS-III and MIPS-IV stages, as well as equivalents for big-endian systems.

Two things with this stage 3 tarball. First and foremost, /dev seems to be empty. I think this is most definitely a bug, and I’ll try to rectify it, but in the meantime, just merge sys-apps/makedev. That should clear everything up.

The second is that somehow dev-vcs/git got pulled in. I guess this is a happy accident since many will probably want it for fetching kernel sources. I’m undecided whether to leave it there or not… I probably should see why it got in there and fix it as that’s probably related to makedev‘s absence. I don’t see it in the profile, so it’s a mystery why it wound up in the system. I’ll do some further checks, but for the most part, it’s harmless.

I’m just rebuilding one of the Fulong2E’s with it to check it out… and as always, feedback is appreciated.

Gentoo/MIPS: Incremental uploads commence

Observant viewers may notice that I’ve begun uploading some of the stage tarballs. The first of the stages built is the stage 1 tarball for MIPS-I little-endian. Stage 2 is building as I type this, hopefully by this weekend it’ll be uploaded and stage 3 will be on its way.

I’ll let you know when all the MIPS-I little-endian builds are done, that way you won’t wind up downloading a partially uploaded file. That said, should you jump the gun, you should be able to resume the download to fetch the remainder. I’ve started with MIPS-I since that’s the lowest-common-denominator … MIPS-III will be next, followed by MIPS-IV.

I plan to get onto the big-endian port shortly. SGI owners have not been forgotten, just I’ve been busy. 🙂

Gentoo/MIPS Stages: Coming Soon

Well, after a long hiatus and a few battles more recently, I now have the Qube2 building O32 stages for the little-endian port of Gentoo.

N32 will probably come soon with Matt Turner throwing some Broadcom BCM91250 heavyweights at the task. I intend to keep O32 going as there’s a lot of hardware out there that cannot use N32 that people use Gentoo on, and there are also a lot of systems which still run Gentoo O32. To provide a continued operating system for these systems, I’ll continue to maintain an O32 port.

At this point… I have produced a seed stage 3 based on modern sources, and have the Qube2 busily working through the final stage 1 for MIPS1 now (at package 55 of 60). I have the occasional hiccup such as baselayout trying to install a .keep file in a mounted /proc and dying… I’ve also had the man ebuild try to call groupadd before shadow was installed.

Other than that, things are moving forward, and I hope to have new stages to you shortly.

VK4MSL/BM: First true bicycle-mobile contact: ZL3SV

Well… it seems my tinkering has paid off. This weekend was the weekend of the International Lighthouse Lightship Weekend… and also a federal election.

On Tuesday, I bought a trailer for the bicycle … this is primarily so that I can transport groceries, etc… to home since I’ve got the place to myself for a few weeks and need to be independent. Being so low to the ground, the trailer is hard to see, so I made the decision to move the CB whip over to the trailer, not only does it now radiate a signal, but it also alerts drivers to the trailer’s presence.

I was up to 3AM figuring out how to mount this antenna on the trailer… but eventually I cobbled together a mounting, moved the homebrew autotransformer over, and hey presto… I had nailed the propagation and visibility problems all at once. SWR is still horrid with the CB whip on the trailer, but the autotransformer brings it down to a manageable <15:1 SWR, which the AT-897 can deal with easily.

On the way to the event, I had the station on 14.200MHz… I heard a Chinese station… a BT call, and also later, a New Zealand station. Didn’t make any contacts until I got to the Bulwer Island lighthouse (AU0003) where I made contact with VK5SR, Cape Jaffer Lighthouse (AU0007), registering a weak 53 signal.

On the way home this evening, I first started hunting for a 40m tap on the autotransformer… found one that gave me a 10:1 SWR on 7.080MHz… Okay, not great, but better than the >25 I’d get otherwise.

Around Bardon, I was hearing some VK7 stations, tried to make contact, but I was in amongst their noise floor. As I got to Ashgrove, I tuned around and heard VK3ARK, Cape Liptrap Lighthouse (AU0037). Managed to make contact, and initially registered a 56 signal, but quickly dropped off as I rolled down the hill towards St. John’s Wood… by the time I hit Royal Parade I had dropped off completely. They got that I was mobile, not sure about the bicycle bit… but never mind. 🙂

I travel to the end of the road, trying to put out a few calls, then when I join the bike path I pause, and have a tune around… a very loud signal on 7.145MHz just about blew me away. I listened for a bit as I cycled… it was Gary ZL3SV, in the South Island of New Zealand.

He was in contact with a US station in New Jersey at the time. I could just make out the US station, however Gary just about blew me off the bike… so I waited for a break and called in. 2 others also jumped in… VK4FMVC and VK3BOT. I was barely able to hear VK3BOT, couldn’t hear VK4FMVC (40m can be like that). Gary could hear me though… he was getting me a strong 58 signal. When I checked the S meter briefly, he was registering 59+. This was around 7:00PM (UTC+10).

I was doing 100W at the time… running off a 9Ah SLA battery. I suspect I’d be lucky if even half of that was being radiated by the CB whip… Gary mentioned he was using 200W into a 1500′ centre-fed sloper… undoubtedly an excellent system. I’ll have to see about sending a QSL card over to NZ. As I continued home, there was also a VK6 station that joined us on the frequency, however I didn’t get to make a contact there… and I was nearly home.

I don’t think I’ll make HF a regular habit on the bike, but I’ll consider doing it again sometime. I’ll also see if I can document the setup a bit more… as it’s showing a good deal of promise. This was one contact I really didn’t think I’d be able to make.