linux

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. 😉

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.

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.

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.

Well… after much building by one of the older Lemote systems, I finally have a Gentoo desktop with KDE 4.3.0 on the Lemote Yeeloong.

I’m still working on the rest of the KDE suite… and will have to track down the necessary bits and pieces for battery monitoring and other goodies… but it seems everything is working. It also is slightly more responsive on Gentoo than Debian (which I still have in a chroot).

This post is being written in Konqueror 4.3.0 on the said installation… it passes the Acid 2 test, but has a few stability glitches here and there… so far both the Acid 3 test, and Google Groups crashes it. I’ll sort this out later.

In short, this does mean I’ll be coaxing my O2 into making the same journey and making the necessary tree modifications in order to allow KDE 4.3 on Gentoo/MIPS.

Well… I’ve been quiet, but slowly, I’m preparing what will become a port of Gentoo/MIPS to the Lemote Yeeloong.

I have it booting off a USB HDD for now, sans X11, but I’m working on that.  The kernel at present needs some patches not yet present in the Linux/MIPS kernel tree.  To build a kernel, you also need GCC 4.4.0 (which supports -march=loongson2f) and binutils (2.19.51.0.2 or later) with this patch.  I’m looking into what is necessary in order to get these patches into our tree.  Patched ebuilds for both are in my overlay.

Once that is done… next attention will be to Mozilla Firefox 3.5 and Mozilla Thunderbird, both of which have been lagging on MIPS since I took my hiatus.  I’m still running to/from Laidley, but with the travel time… this would seem an excellent moment for package testing once I get Gentoo installed on this machine.

Here’s hoping I can return with some goodies for everyone shortly.