gentoo

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.

Hi all…

I’ll put this in the handbook when I get around to updating that… but in short, those who need to be able to netboot SGI systems from a Windows host, might wish to give tftpd32 a try.  I’ve been tinkering with this TFTP server in order to load some ARM-based devices (Ka-Ro TX27s using RedBoot).  I find this server daemon is inconsistent with its loading speed when transferring files to a TX27 (sometimes speed is good; around 1MB/sec, other times it crawls at 3KB/sec), however experimenting with it in a VirtualBox VM running Windows 2000, it works flawlessly for netbooting the SGI O2 I have here.

Below is a screenshot of the settings used.  A Linux or Unix-based TFTP server would be better if that can be organised, but for those who have no option, this may be a viable alternative.

TFTPD32 Configuration, tested with an SGI O2

qube ~ # catalyst -f /home/catalyst/configs/stage1.spec 
Catalyst, version 2.0.6.906
Copyright 2003-2008 Gentoo Foundation
Copyright 2008-2009 various authors
Distributed under the GNU General Public License version 2.1

Using default Catalyst configuration file, /etc/catalyst/catalyst.conf
Setting sharedir to config file value "/usr/lib/catalyst"
Setting snapshot_cache to config file value "/home/catalyst/snapshot_cache"
Setting hash_function to config file value "crc32"
Setting storedir to config file value "/home/catalyst"
Setting portdir to config file value "/usr/portage"
Setting distdir to config file value "/hd/0/gentoo/distfiles"
Setting options to config file value "autoresume kerncache metadata_overlay pkgcache seedcache snapcache"
Autoresuming support enabled.
Kernel cache support enabled.
Package cache support enabled.
Seed cache support enabled.
Snapshot cache support enabled.
Use of metadata_overlay module for portage enabled.
Envscript support enabled.

        WARNING: No value set for key cxxflags...deleting

        WARNING: No value set for key distcc_hosts...deleting

        WARNING: No value set for key pkgcache_path...deleting

        WARNING: No value set for key portage_overlay...deleting

        WARNING: No value set for key ldflags...deleting

        WARNING: No value set for key portage_confdir...deleting
Using target: stage1
Building natively for mips
stage1 root path is /tmp/stage1root
Source path set to /home/catalyst/builds/seeds/seed-20100806.tar.bz2
Caching snapshot to /home/catalyst/snapshot_cache/20100806/
The autoresume path is /home/catalyst/tmp/default/.autoresume-stage1-mipsel1-20100806/
stage1 stage path is /home/catalyst/tmp/default/stage1-mipsel1-20100806/tmp/stage1root
Resume point detected, skipping target path setup operation...
Location of the package cache is /home/catalyst/packages/default/stage1-mipsel1-20100806/
Location of the kerncache is /home/catalyst/kerncache/default/stage1-mipsel1-20100806/
Checking for processes running in chroot and killing them.
--- Running action sequence: unpack
Referenced SEEDCACHE does not appear to be a directory, trying to untar...
No Valid Resume point detected, cleaning up...
Removing AutoResume Points: ...
Emptying directory /home/catalyst/tmp/default/.autoresume-stage1-mipsel1-20100806/
Emptying directory /home/catalyst/tmp/default/stage1-mipsel1-20100806/

Starting tar extract from /home/catalyst/builds/seeds/seed-20100806.tar.bz2
to /home/catalyst/tmp/default/stage1-mipsel1-20100806/ (This may take some time) ...

And with that… a new round of stagebuilds begins… I’ll do the initial stage builds on the Qube2 for now, so things will take some time, but I want to iron out all the issues I’ve been having and get something together that builds smoothly. I may even run it through Catalyst a second time just to make sure everything is clean. These should also include the newer tools, such as baselayout-2 and eselect.

This seed stage was mostly cross-compiled on my now dead Duron. I now have a 6-core AMD Phenom II which I also plan to set up QEMU on, for stage-building purposes… and soon will get distcc going on a few of the hosts here… so hopefully I’ll have stagebuilds going much more regularly.

It has been a long time between drinks for Gentoo/MIPS… but at last, I’ve managed to get something rolling, and hopefully I should have some stages out by the end of the year.

What took me so long? A number of packages didn’t want to compile… particularly python-2.6 and gcc-4.4. The former exhibited various compiler errors… I think I’ve got that sussed now. The latter would compile xgcc, then that binary would promptly die with an Internal Compiler Error.

I couldn’t resolve the latter due to not having anything other than MIPS hardware at home for development. So when I managed to cobble together a Duron 900MHz, I was able to use that to cross-compile a minimal environment with a C-only gcc (it wouldn’t build without USE=nocxx) and supply a version of Python from my Yeeloong.

I now have the Qube2 busy running the bootstrap script, it has self-compiled its own python-2.6 now and is working through the other base-system packages. I found the Lemote boxes seemed to exhibit an odd lock-up at specific points of the build, but the Qube2 just keeps plodding along. Ahh well, they do say “slow and steady wins the race”.

Speaking of slow and steady, the Duron 900MHz decided to keel over this morning… so I’m not sure if I’ll be able to put together a similar environment to bootstrap the big-endian port, but we’ll see. There’s money in the budget for a new 6-core AMD Phenom II system in the near future though, so by the time I get Gentoo/MIPS little-endian up and running, I should have new hardware to tackle the big-endian port with.

On other news… it seems the next Linux.conf.au is going to be here in Brisbane… shock horror I might be able to attend this one. 😉

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.