Jun 052008
 

Hi all…

In the absence of recent netboot images, you might find these notes useful.  These describe how to install Gentoo without the use of a netboot image, but rather, making your own, and using root-over-NFS.  This same guide can also be used to port Gentoo to other presently unsupported MIPS hardware.

What you need…

You’ll need about 200MB or so (the more the better) on the netboot server to house a root filesystem.  In addition to the tools mentioned in the handbook, you’ll also want nfs-utils installed to export the client’s root FS.

You’ll also want a cross-compiler.  You only need to be able to build a kernel — libc is not necessary.  To generate such a compiler, install the sys-devel/crossdev package, and run crossdev -t mips64-unknown-linux-gnu -S1 (or  mips64el for Cobalt/little endian targets).  If the build fails, try various versions of binutils and gcc, it may be a little tinkering to get a combo that works.

IP28 users will want to enable the ip28 USE-flag on in /etc/portage/package.keywords for the cross-mips64-unknown-linux-gnu/gcc package.

Unpacking and setting up the root fs…

Download the stage 3 tarball, and unpack that into a directory on your server.  Then, export it by editing /etc/exports, and adding a line like the following:

/unpacked/stage3/path    *(ro,sync)

Remember to reload your NFS server config by typing /etc/init.d/nfs reload.

Building the kernel…

Start by unpacking the kernel with appropriate USE flags set (USE=ip28 for IP28 users, USE=ip30 for Octane users, USE=cobalt for Cobalt users).  This is done with the following command (adjust if your PORTDIR is in a different place):

# USE=ip28 \
  ebuild /usr/portage/sys-kernel/mips-sources/mips-sources-VERSION.ebuild \
    unpack

If all goes well, you’ll have a copy of the patched kernel tree in /var/tmp/sys-kernel/mips-sources-VERSION/work/linux-VERSION.  Change to that directory, and configure the kernel as per the guide in the Gentoo/MIPS handbook, passing ARCH=mips CROSS_COMPILE=mips64-unknown-linux-gnu- (or mips64el…) to all make calls.  If you want to use the .config that comes with one of the old netboot images, you can use scripts/extract-ikconfig to extract it.

Remember to say Y to your network card driver, and these options:

  • Root-over-NFS support
  • NFS Client support
  • IP Level Autoconfiguration (DHCP)

Once you’ve compiled your kernel and have your vmlinux (or vmlinux.32) file, copy this file to your server’s /nfsroot (Cobalt hardware) or /tftproot (almost anything else) directory in place of the usual Gentoo netboot image.  For kernel modules, install them by typing make CROSS_COMPILE=”…” INSTALL_MOD_PATH=/unpacked/stage3/path modules_install.

You may also find it helpful to place a copy of the stage 3 tarball and kernel inside the NFS root area for convenient access on the final host.

Booting the system…

SGI Boxes:

Break into the command monitor prompt as per the handbook, and at the prompt, type the following (all on one line):

>> bootp(): root=/dev/nfs ip=dhcp 
            init=/bin/bash
            nfsroot=ip.of.root.server:/unpacked/stage3/path

Cobalt boxes:

This assumes you have one of my netboot images already unpacked in /nfsroot and that you’ve placed your freshly compiled kernel in /nfsroot as well.

Compress the kernel image using gzip -9, and rename it to kernel.gz (overwriting the existing file).  Then edit the default.colo file … the execute line should read (place this on one line):

execute root=/dev/nfs ip=dhcp init=/bin/bash
        nfsroot=ip.of.root.server:/unpacked/stage3/path

Netboot the Cobalt system in the usual way.

Lemote hardware:

Hit ESC a few times to break into the PMON2000 prompt… then type the following (each on one line):

PMON> ifaddr rtl0 lemote_box_ip_addr # (e.g. 10.0.0.8)
PMON> load tftp://tftp_server_ip_addr/kernel_name
PMON> g console=tty0 root=/dev/nfs ip=dhcp
      nfsroot=ip.of.root.server:/unpacked/stage3/path

In all cases, you should be at a prompt.  Proceed with the Gentoo/MIPS handbook instructions as per normal at this point. 🙂

Jun 052008
 

I’ve been doing some thinking today.  I haven’t been in the amateur radio gig very long… I got my license in mid January, and I’ve been active mostly on the 2m and 70cm bands for the past few months.

The last month saw me acquire the parts needed for a HF station, and so lately I’ve also been poking around on 40m and 80m too.  I’ll admit I’m still very new to the scene, getting to know what bands are best in what conditions, and making a small number of contacts.

I’ve been very active lately on 70cm on the Mt. Coot-tha repeater, VK4RBC (438.525MHz), and have been on the odd occasion, tried making contact on various frequencies on HF.

At BARCfest this year, a number of commercial traders were present, showing off the latest and greatest from two of the big communications companies out there… ICom and Yaesu.  It was at BARCfest, that I picked up my current HF rig, a Kenwood TS-120S, and a few sellers had a number of older rigs on sale.

Now this particular rig is quite old… according to the eHam site, they are 1980s vintage, although the exact date my rig was manufactured is unclear.  As far as features, it’s basic… SSB and CW modes, coverage of 80m, 40m, 20m, 15m and 10m, and around 100W output.  For my needs, okay, the power output is overkill, but it’s sufficient.  In fact, the power output is good, as if there is an emergency, I have the extra power to make contact.

At BARCfest however, there were some of the very latest rigs on display.  There was one Yaesu base station monster being shown off by Kyle Communications, I can’t recall what model, but its (discounted!) price tag was around AU$8000.  This thing did just about everything except errect its own antenna and make you coffee.  SSTV, RTTY, Packet, DSP filtering, you name it, it had it.  Very impressive, but are all these gratuituous bells and whistles really needed?

One thing I like about the rig I have, is that the handbook includes full schematics of the transceiver circuitry, with explainations on how it works.  It’s all implemented using solid state components that are easily sourced.  In fact, the handbook has some hand-written notes suggesting that the thing has been serviced a couple of times before hand already.  Being basic in features, has enabled it to be serviced, and I suspect that I should have this rig for a very long time, as long as I can get replacement parts — I see no reason why it shouldn’t continue operating for years to come.

However, rigs like the one I described above, the average operator, I suspect, would be helpless to try and fix a complex beast like that.  There’s just so much that could go wrong, and loads of specialised components that are purpose built for it.  Sure, it might be off-the-shelf DSPs and microcontrollers in use… you might be able to buy replacements… but where do you go to get them reprogrammed so they perform the function for which they are intended?

Even my handheld, a Kenwood TH-F7E, is a rather complicated beast.  It has a small microcontroller in it, and a lot of integrated circuitry, that I couldn’t possibly fix if something went wrong.  I bought it because it had FM transmit capability on 2m and 70cm (the only two VHF/UHF bands I’m permitted on presently) and it could receive AM, {,W,N}FM, SSB and CW over a wide range from 100kHz through to about 1.3GHz.  Now okay, in order to minaturise the device, it was necessary for specialised components to be used here… that’s fair enough, but I can forget doing much in the ways of repairs.

I believe that base station rigs are getting overly complicated these days — we really need to get back to basics.  For someone like myself, I really only need a few basic features:

  • Coverage of all the analogue modes: CW, AM, FM and SSB
  • Reasonable output power
  • Good sensitivity/selectivity
  • Digital readout

All of this (except digital readout) can be implemented with analogue electronics.

Digital modes in my book are better implemented on a desktop PC.  Computers these days are quite capable of doing software DSP… I don’t see any reason why it is necessary for the transceiver to do all that.  A small microcontroller inside the rig to provide PC control, and memory banks, no worries… but that’s about as complicated as it needs to be in my opinion.

Heck, there’s no reason why some of this couldn’t be modular — that is, the rig works without the microcontroller.  The microcontroller would just be responsible for loading/storing VFO frequencies, and switching modes — if it’s absent, this just gets done manually by the user.  The controls on the front would just manipulate digital flip flops, that could also be driven by the microcontroller.

The upshot is, a rig like the above, could be made quite robust… and reasonably inexpensive.  Some of us don’t need the frills — or if they do, are sufficiently knowledgable enough to make them ourselves.  There are people who will demand very fancy rigs, and that’s fine… there’s plenty in the market now to cater for that group of operators, but for the rest of us, I think a lot could be gained from reducing the complexity in current transceivers.