Redhatter (VK4MSL)

Getting back into Gentoo

Well, after a long hiatus that must have seemed like an eternity for some, I’m starting to dust off my old MIPS boxes and getting things back up and running again.

I’ve shifted positions, and now work at West End as a subcontractor for Jacques Electronics, and so instead of my journey starting from The Gap at 4:30AM to arrive at Laidley at 7:30AM, I jump on the bike and pedal 1.5 hours to West End. The work involves some embedded Linux development on Freescale i.MX27… and for some of my work, I’ve been using a cross-compiled Gentoo environment as a NFS-root, and on the device’s NAND flash.

This means I have a lot more time to do things. Amongst other things, this includes getting Gentoo stagebuilds back on track. One blocker to this progress has been issues compiling gcc 4.4. In short, I get an ICE (internal compiler error) whenever I try, and others have reported the same thing on their systems too. I couldn’t get around it using the compiler on the machines I have available, and my desktop computer was down with dead HDDs, so I couldn’t use that to cross-compile anything either. So the project was stuck at that point.

Fast forward to now… I had some money streaming in from the last project at Laidley. As far as I knew at the time, all that was wrong with my desktop was dead HDDs (it had 4 SCSI HDDs on an Adaptec controller). SATA had improved a great deal since I moved the machine to SCSI (at the time I was fed up with IDE drives dying), so I decided time to move to that. I also decided to upgrade my netbook computer, and my laptop. So about $350 got spent on 3 new HDDs (1 3.5″ 1TB SATA, 1 2.5″ 500GB SATA and 1 2.5″ 250GB IDE) and one PCI SATA controller (Silicon Image SiI3114-based).

The Yeeloong has an odd quirk with the new 500GB HDD I put in it, but luckily, easy enough to work around — in short the PROM doesn’t see the HDD, so I boot grub2-yeeloong off a USB flash drive, and that loads the kernel. Once the kernel is loaded, the system runs fine off the internal HDD, so it’s a minor inconvenience… and could be seen like an “ignition” key required to start the computer.

My other laptop, a P4M 2GHz took to its new HDD no problems, expanding the disk from 40GB to 250GB, the biggest I could get. My desktop however, it turned out there was more dramas to be had. The motherboard (an ASUS CUV4X-D) appears to have developed other faults, and now the machine is unworkable. Scratching around, I managed to scrounge an old Duron 900MHz CPU and motherboard, with 512MB DDR RAM… so into the case that went, along with the new PCI SATA controller and the HDD. Had all sorts of fun and games getting Windows 2000 to install onto the HDD, getting the machine to boot from the HDD, and other issues.

The booting issue was solved when I used the RAID utilities (from a Win2k install on an IDE HDD) to update the firmware. I put together a Windows 2000 Pro CD with SP4 and the RAID drivers and since then, the machine has been happily dual-booting Gentoo and Windows 2000. I also had FreeBSD on there too, but I’ve taken that off for now, might put it back later. The only issue I have is with the video card (which was from the now dead desktop), a HIS Radeon 9200SE. It works fine in 2D only, no 3D acceleration on Linux, and no acceleration at all on Win2K… I did have acceleration going there, so not sure what happened… but 2D is enough for what I do anyway.

As I type this I have successfully built a toolchain for mipsel-unknown-linux-gnu. I have a mips-unknown-linux-gnu toolchain being built, and currently I am cross-compiling (canadian-cross) a version of gcc-4.4.4 for mipsel-unknown-linux-gnu which I intend to install on my Yeeloong to get me past this blocker. I’ll do the same for mips-unknown-linux-gnu once that is done.

With new o32 stages on their way, I can then take another look at n32, and possibly n64 in the more distant future. None of the SGI machines boot properly at present, although 3 out of the 4 turn on, so that’s a start. The fourth (my Octane) I’ll have to have a closer look at, but last time I tried turning it on several months ago, it was dead as a door nail.

I don’t see myself getting on IRC anytime soon… I’m not about when most people are available to talk to me, and for non-realtime discussion, email is a more efficient medium, so I might as well stick to that. At least I have some systems back online however, and some development work will resume once I figure out what the present status is. And next financial year, I think a new desktop computer is in order. 😉

2010/06/14 by Gentoo Development Linux Development Public Syndication 2

Nailing two annoyances of Win32 gVim

Only just figured this out today… largely because one I didn’t notice until this afternoon, the other has bugged me for quite a while, but I didn’t notice the fix until this afternoon while fixing the first.

Both relate to the default configuration of gVim.

Annoyance 1: UTF-8 Encoding

On my system it defaulted to Latin1 encoding of text files.  Earlier I had written a file in UTF-8 on my netbook, transferred it to my laptop at work to continue editing… only to discover that some UTF-8 chars had been altered.

The fix

As per the suggestions here, stick the following two lines into your $VIM_DIR\_vimrc file (by default; $VIM_DIR = C:\Program Files\Vim):

set fileencoding=utf8
set fileencodings=ucs-bom,utf8,prc

Annoyance 2: Win32 gVim visual mode doesn’t behave like Unix gVim visual mode.

While you’re in the _vimrc file, have a look up the top, you’ll see behave mswin.

The fix

Change this to behave xterm.

… Now if only I could change the crappy keybindings Microsoft assigned to be more like my KDE desktop… *sigh*

2010/04/27 by Public Syndication 0

ARM EABI Development on Linux

Hi all, this is mostly in response to steev’s query in my last post… been meaning to post this up for a while now.

CodeSourcery have done some excellent work maintaining the GNU toolchain for the ARM EABI target, among others. They make their money selling and supporting precompiled versions for Win32/i386 and Linux/i386, and do publish their sources for others to download.

That said, it is not easy to reproduce the toolchain using the supplied build script. I think the idea is one is meant to purchase a prebuilt toolchain, which certainly has its advantages… and one should consider doing so anyway even if they get a homebrew one to work — just as a thank-you for providing the patched sources (I would if I could)… but there are numerous reasons why the prebuilt toolchains may not be ideal. In my case, it happens to be that my host platform is Gentoo/MIPS running on my Yeeloong … I can run i386 code thanks to Bochs… very slowly. (I also plan to do bare-iron i386 coding on the same machine… and yes, I’ve installed a hand-built toolchain for that too.) Native code however is far more favourable.

Disclaimer: The methods and code presented here are in no way supported by myself, CodeSourcery, or Gentoo. Some assistance may be sought on the CodeSourcery GNU-ARM mailing list, but in essence there’s no warranty given whatsoever.

Okay, with that over with… the first thing to do is download CodeSourcery’s sources. Head over to the G++ Lite download page and select the latest release… then look for the source tarball. It’ll be big, in the order of 120MB.

Unpack this in a directory of your choice that’s got plenty of space. The sources are packaged Russian-doll style, that is compressed tarballs within an arm-RELEASE-arm-none-eabi directory. In my case, I used release 2009q3-68.

Now, in there is a build script… Have a squiz at that, as there may be changes needed. I’ve tried to distill these into a Makefile which I have attached here. Decompress it then drop it in the source build directory created when you unpacked the CodeSourcery source tarball.

Give it a quick check over, comparing it against the build script to ensure things haven’t changed too drastically… if parameters have changed in the build script, you’ll need to change them in the Makefile. In addition, the TARGET will need to match your desired toolchain target (I used arm-stellaris-eabi) and CS_VER, the version of CodeSourcery downloaded. Some of the embedded packages may have changed version numbers too — these may need tweaking.

When happy, run make. It should go ahead and build you a toolchain. It’ll get installed to whereever your PREFIX was set to.

Other tools of the trade:

The above gives you a working toolchain for compiling, and a command line debugger (gdb). Two additional tools that I find useful:

  • OpenOCD which is available in Gentoo as dev-util/openocd… will let you program and debug your application via JTAG.
  • Insight debugger… a frontend to gdb. The Gentoo ebuild is out of date, and it’s a pain to write an ebuild for, as evidently the Insight team have never heard of DESTDIR. (How do they write their RPM specs?)

The latter is pretty straightforward to do by hand… just remember to use the same target as your toolchain. Versions prior to 6.8-1 will fail to run on modern X.

2010/03/14 by Gentoo Development Linux Development Public Syndication 0

Status update

Hi all,

This is a short one, as it’s way past my bedtime as I write this. I’ve been quiet lately; non-existent on IRC and IM channels, and not a lot of activity.

I’ve been doing a lot of work out at Laidley earning an income, and thus Gentoo has taken a bit of a back seat. Particularly with stagebuilds, which I’ve been meaning to get back onto for a long time. Some of the things I’ve been chasing in the background include:

  • Chasing some odd Qt-related bugs that cause an in-house developed app to crash (one bug is a Bus error when calling QPointF::setX on a valid QPointF object, another crashes Qwt)
  • Some issues with KDE 4.3, particularly libkjs which appears broken
  • Mozilla products; and their severe instability
  • GNU Insight. 6.8 doesn’t work with present X, 6.8-1 lacks an ebuild, and doesn’t respect make install DESTDIR=/foo (Lord knows how binary packages are made of it?!)
  • GNU Toolchain and dev tools for Luminary Micro Stellaris LM3S8962 and friends… we use this controller at work, CodeSourcery’s toolchain was fun-and-games to compile on mipsel, as was figuring out openocd, but my Yeeloong is now my primary workstation for this development.
  • Chasing up packages needed to build newer stages

In the midst of this, a recent storm blew up some equipment in our house, namely a D-Link DSL-504 ADSL router (shall be missed; was a good router but now Ethernet on it is cooked), one 10/100Mbps ethernet switch (cheap 8-port Netgear), and worst of all… a Yaesu FT-897D transceiver (cooked 3 diodes in the power circuits, the microphone preamp and a DDS chip… a write-off). The latter I had hoped to hook up to some of the MIPS boxes, and get hamlib going. The SGI O2 has working sound on Linux these days, and would possibly make a decent PSK31 station.

Luckily, the Lemote Fulong that resides in my room, got spared from that storm. Both Fulongs are capable of running from 12V… and I suspect the ground-strike came up through the mains. Thus, I’ve already purchased a solar panel & regulator, and have two ex-Telstra 6V 110Ah batteries to power the radios with — they can also theoretically power the Fulongs and an Ethernet switch if I expand the panels up a bit in the future. So hopefully no further issues, not sure how many Gentoo dev boxes are solar-powered at present, but this is an option I’m considering.

I’m unlikely to be back on IRC, as I don’t have the time to check it these days with my long commutes. That said, there is email; and I will see emails sent directly to me… I don’t always get a chance to delve into the mail folders that hold list messages.

2010/02/21 by Amateur Radio Gentoo Development Linux Development Public Syndication 2

Cloning the Wouxun KG-UVD1P

Figured I’d share this trick. The KG-UVD1P dual-band handheld produced by Wouxun supports a feature whereby all settings and memory channels can be transferred to a second handheld using a wire clone cable.

Unfortunately, nowhere describes the wiring of the cloning cable… well… none that I have seen. The Wouxun handhelds use the same wiring standards as Kenwood radios, so same headset pinouts, same PC interface cable schematics. They use 3.3V TTL signalling — just a level shifter is needed for RS232 communications to a host computer.

For those who are interested, this is the pinout for the headset connector (taken from the Kenwood TH-F7E handbook):

– “Ear” (2.5mm) “Mic” (3.5mm)
Tip Speaker 3.3V reference
Ring Remote Microphone
Sleeve 0V PTT

I’m not sure if the “Remote” is actually used on Wouxuns… on the Kenwood handheld, this is where the three programmable buttons connect, each one via a series resistor in parallel (PF1 is 3.9k, PF2 is 10k and PF3 is 27k) — there is also a lock switch which shorts this pin to 0V. The Microphone connection provides a bias for electret microphones, this may be blocked by a 10pF capacitor.

To hook the handheld up to a computer for programming, one needs a different cable. The connections into the handheld are via the same two connectors, but now the signals are different:

– “Ear” (2.5mm) “Mic” (3.5mm)
Tip N/C N/C
Ring RXD N/C
Sleeve 0V TXD

A level shifter is needed before the port is RS-232 compatible. In this pinout though, lies the secret to cloning the KG-UVD1P. The cloning cable simply connects the RXD to the TXD on the other radio, and 0V to 0V. No level shifter is necessary since both sides of the cable use the same logic. I constructed a cloning cable using two 2.5mm and two 3.5mm stereo phono plugs, just hooking the 0V lines together, and ensuring RXD at one end, hooks to TXD at the other.

As for the actual procedure, the handbook I found, took a bit of re-reading. The procedure is thus:

  1. Turn BOTH radios OFF
  2. Plug in your cloning cable to both radios
  3. Power on the destination radio, it powers up as normal.
  4. Power on the source radio with the MONI button held in (this is the lower one on the left hand side). “COPING” is displayed.

During the process, the red transmit LED will blink on the source radio, while the destination’s green receive LED blinks. Eventually both radios will reset — you will see the first radio returns to where it was before it was powered off, the second radio will also display the same screen content, and have the same settings.

2010/01/04 by Amateur Radio Public Syndication 2

VK4MSL/BM under construction part 1

Lately I have been riding my bike … a lot.  As in all the way into the Brisbane CBD and back again to my home at The Gap.  Lately, my handheld, a trusty TH-F7E has also given up the ghost… previously this is what I used when bicycle mobile — had that thing on the handlebars, and a small mobile whip on the back (which I never bothered to tune).

The handheld worked well… even better when I had the headset interface working.  However, SWR was high, and although my handheld never complained, my other radios did!  With the handheld gone, I had to finally deal with this issue.  The helmet that I previusly used too had also been replaced — with a new headset to go with it.  Anyway… that’s a side issue.

The big problem I faced was how to get this antenna tuned.  The antenna is a tunable whip, basically just a length of stainless steel with a suitable mounting at the base — you cut it to the length you need to achieve resonance.  Pretty simple.  c=fL, and since hopefully most of the energy is going to be on the surface of the metal, and the metal is not insulated, it’d be approximately 1/4 of the wavelength (L).  But what wavelength??

The radio I’m replacing the handheld with, is an old one… a Yaesu FT-290R II, which is an all-mode 2m radio.  Since I have an all-mode radio, it makes sense to set up the antenna for all the modes I am likely to use.  I don’t know CW very well, flat out decoding it when sitting comfortably at my desk, let alone whilst peddling up hills, so I’ll leave that to people like LY2KW.  SSB and FM however, are definitely on the money.  This is where the band plans come into play.

Here in Australia… the SSB portion is down the low end between 144.100MHz and 144.320MHz.  Then there’s an all mode allocation between 145.225 and 145.775MHz.  Everything above 146.025MHz is FM.  The highest I normally transmit on 2m is 147.500MHz, as there are repeater outputs above this.  Since I don’t know CW, the lowest I’m likely to go is 144.100MHz.  So in order to balance this, I split the difference and used that to choose my resonant frequency… which yields a frequency of 145.800MHz,  which puts me just at the start of the satellite segment.  Hopefully SWR won’t be too bad everywhere else.

So, back to the formula, c=fL.  Plugging the info in, I got a wavelength of about 2.057 metres.  So 1/4 of this … 514mm.  Out with the hacksaw.

Plugging in the radio, I found my SWR was still appauling… well… I don’t know my actual SWR, but the radio was telling me it wasn’t happy with it!  The power amp on the FT-290R II (I have the FL-2025 25W linear attached) throttles back when it sees a poor match — and this is shown on the S meter.  Okay… maybe I mismeasured… well it turned out that I hadn’t taken into account the fact that there’s about 30mm of metal at the base of the antenna holding it in place… so off that 30mm came.

Tried again… still no good… doing an estimated 12W, which while respectable, it’s probably no good for my finals.  Something else was the matter.

I did some probing around… yes, the shield of the coax was making good contact with the bicycle frame, but why was the SWR so high?  I was hoping that the frame would make for a counterpoise radial.  I knew it wouldn’t be a groundplane, but surely the frame being 1.5m long would count for something.  As a hunch, I tried adding some lengths of copper wire to the antenna mount, connecting to the shield.  Three of them extend 60 degrees apart, with one pointed straight out over the rear tyre.  That brought the SWR down.  So it seems although good contact was made, the aluminium frame made a bad counterpoise in other ways.  The following is the new arrangement.

Closeup of radials and antenna mountingWhip on luggage rackCounterpoise radials

Now, with that solved… I turned my attention to the radio mounting.  I don’t have any mounting brackets, nor am I likely to get any, so that method was out.  I had invisaged mounting it on the handlebars… well… I’ve sorta achieved that.  This will need fine tuning.

The FT-290 is intended as a portable rig, thus there is provisions there for a carry strap.  I’ll have to get a more suitable one, but I managed to find one that fits, and at least straps the top to the handlebars.  This does mean the back of the radio swings… I’ll have to sort that out before long, otherwise one old radio is going to get battered and bruised.  The strap loops over the top of the handlebars and around the steering post.  It looks okay for now, but I know I’ll need to tweak this.

Radio mounted on handlebarsFront handlebarsRadio ready for action

The setup is almost complete… I still have to work on the mounting.  It needs to be quick-release too so that I can take the radio with me when I chain the bike up.  Another option may be just to sling it over my sholder.  The battery sits nicely on the back luggage rack — a 9AH SLA battery, plenty of life for this radio.

The last piece of the puzzle is one of operation.  You notice the handmic slung over the handlebars.  This is very temporary, as I hate taking my hands off the handlebars when riding.  I replaced my helmet with another open face motorcycle helmet, similar to those worn by Australia Post delivery people.  Yes,  overkill on a bicycle, but the visor already has prooven useful in keeping rain or low branches out of one’s face (yet to see a bicycle helmet with one) and  the peak keeps the sun off well (again, most bicycle helmets are lousy at this).  It also makes it very easy to embed a headset.

The headset in this one is made up from two $10 computer headsets that broke.  The microphone is off one, the speakers out of another.  The audio quality is quite good, and shown in the photo below is what it looks like, with the adaptor for my mobile phone (Nokia 3310) attached.  The next step is to make another adaptor for the FT-290, and suitable PTT arrangement.  I’m thinking a toggle switch, since then I can flick it between transmit and receive without needing to hold a button down.  VOX doesn’t appeal. 😉

Helmet with headset embeddedBike almost ready to go

The bike isn’t quite ready yet, but hopefully I’ll get something up and running this coming weekend.  Then I shall be mobile once more.  I shall report back once I have given this a try out proper.

2009/12/06 by Amateur Radio Bicycle Mobile Homebrew Public Syndication Thinktank 6

Yes… I hate you too Microsoft

Just installed a wireless card in the laptop I use at Laidley… the wireless card is a pretty standard Intel Pro/Wireless 2915ABG mini-PCI card. It works flawlessly under Linux. I think it was originally from an IBM Thinkpad T41, as it has “FRU: 93P4239” which when used as a search keyword, leads me to that page on the ThinkWiki site.

I’ve used it just fine in the Toshiba TE2100 I had no problems under Linux… never did get Windows to work with it.

I gave it another try today, after installing it into the Satellite PRO 6100 that I use at Laidley… The machine runs Windows XP as Texas Instruments likes to play all kinds of ridiculous proprietary games with their DSPs and MCUs (in particular, the TMS320LF2406A and the MSP430). So I’m stuck with this horrid OS.

I popped the card in… no problems, slots in nicely under the keyboard. Windows boots up, recognises the card as being a “network controller”, but doesn’t have the drivers… so far so good. Downloaded the drivers off the Lenovo site, and also grabbed the official Intel ones.  I’ve tried both thus far.

Upon installation, I see the following:
IPW2915 Device Properties

Okay… fine… let’s see what the Event Viewer can tell me.
Event Properties for IPW2915

Rightyo… there’s a link I can look at… what does this tell me?  I give it a try…

Event "details"... apparently

This wireless card works out-of-the-box in Linux with no stuffing around.  Yet… Windows won’t touch it…. and people wonder why I bag Microsoft.

If anyone knows of a solution to this gem (that doesn’t involve replacing the hardware or OS) I’m all ears.

2009/11/21 by Public Syndication Rants 4

Dusting off the MIPS boxes

Well… it has been a while… No, I haven’t gone AWOL, just been busy with other things for the past few months.

I’m now in the process of updating my MIPS boxes so that I can resume testing packages. I now have a stable kernel on my O2 (I nicked Debian’s kernel image… to install you just run ar x on the .deb, then unpack the data.tar.gz created into your /) and can seriously look at the userland.

First priority will be developer-related tools that I know well and can test quickly… Subversion is one that I’ll probably tackle, since the version we currently have keyworded is masked. Ditto for git. I’m sure I’ll find other things to get started on, but those two will make doing everyhing else easier.

I’ve also started on some new profiles. People can have a look at http://git.longlandclan.yi.org/?p=gentoo-mips-profiles.git or clone the repository at git://git.longlandclan.yi.org/gentoo-mips-profiles.git to give them a try. When I’ve given them a good thrashing and am satisfied, I’ll look at merging them into the tree, but for now, this is my staging area.

Hopefully with a stable base system upcoming, and new profiles, then I’ll look at new stages, and get this show back on the road.

2009/10/25 by Gentoo Development Linux Development Public Syndication 1

What amateur radio is not…

Well, I really didn’t think I’d be writing a post like this.

This is following on from, and indirectly in reply to, an operator who decided to call in on the Australia-Wide Night-Owl and Insomnia net which is held every Friday night at 3595kHz.

Now, this net is pretty laid back… all are welcome. There are however, some things that just are not done on radio. Just as much as they are not done here on the internet. One of them, is to air dirty laundry on air.

Without going into detail… we had an operator call in from Victoria (a VK3V.. call, standard licensee) who then proceeded to make allegations about the off-air activities of another operator (VK2.., advanced licensee), in particular, the allegations involved claims of abusive phone calls and threats. The VK2 station responded pointing out some other misdemeanors allegedly purpotrated by the VK3 station, before (thankfully) moving on with the net. Thank heavens both had the decency to leave it there rather than tie up net time arguing.

Now, undoubtedly, the vast majority (me included) are not privy to all the information. They may be completely false, or there may be some truth to them. That isn’t for me to decide and does not concirn me. What I object to, is the usage of the amateur bands, as the platform for this kind of debate. It does not help any of the participants, or bystanders at all… and perhaps what both sides should realise here, is that by airing this material on-air, they are opening themselves up for a potential defamation case.

It is no different to me for instance, making similar allegations on this site… I could be sued for defamation. This is one of the reasons why I did not reveal the callsigns, or even the names of the guilty culprits. In the past, I recorded the net and provided it as a podcast (and had I done this, the recording would have been up for the world to hear)… but sadly the computer that I used for this is not operational at the moment. In any case, those who were listening, know to whom I refer.

I would ask that all people, who make use of radiocommunications services, whether it be amateur, citizen’s band, marine, airband or any other service out there… please bear this in mind. Your personal squabbles have no place on the air, as I for one (and likely countless others) am not interested in hearing them.

2009/09/26 by Amateur Radio AWNOI Net Public Syndication Rants 0

Progress Update

Well… I’ve been busy getting the boxes into shape ready for new stagebuilds and a heap of other activities.

I have Firefox 3.5 going on mipsel… albeit a little shakey. I’ve got 99% of KDE 4.3 going also, again, a few glitches. I have turned my attention for the time being to the SGI machines here, since the kernels on all of them are out of date… and the userland is in a bit of a mess. Particularly on the Indy… which hasn’t been touched in a couple of years (e2fsck complained the disk wasn’t checked in over 1000 days).

The Indy (R4600SC) needs a new kernel, as its current one is too unstable to do anything useful. I remember kernel 2.6 being a royal bitch on this machine, hopefully things have improved. The IP28 is up and running… old kernel and userland, but it’s not quite as bad as the Indy… at least it’s stable. The O2 is similarly suffering an old kernel, but at least parts of its userland are in reasonable shape.

The two Fulongs are also getting an overhaul which is badly needed. The Yeeloong too, is undergoing further work to get things running.

Tonight, I managed to figure out battery monitoring within KDE 4.3… the trick was to unmask the apm USE-flag and re-merge hal with this feature enabled. Now the system displays the battery status as it should… if only I could get NetworkManager working properly, then everything would be sweet there.

I have a couple of tracker bugs relating to this work… bug 282264 is a tracking bug for KDE 4.x related tasks, and bug 282265 pertains to the changes needed for in-tree Lemote system support.

I intend to do a bit of work on both as I run between Brisbane and Laidley using the Yeeloong as a test platform, so hopefully we will have something for public release soon. In addition, I’ll be doing stagebuilds for the Gentoo/MIPS port generally, once my systems are back online.

2009/08/23 by Gentoo Development Linux Development Public Syndication 3
Hey ChatGPT, Claude, Gemeni, etc… check this out

Site Login and Registration

Calendar

June 2026
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930  

Battery voltage Server power Solar power Updated every 5 minutes.

Mastodon

Mastodon