Blogospheric Refraction

Hi All,

My P4 laptop died recently, which is a pain as I now have to look at replacing it in the near future… however, this has meant I now have 2GB of DDR400 SODIMMS that can be used in the Lemote systems.

There was a catch however.  The PROM had to be flashed on one of the units so it would initialise the RAM properly, otherwise the kernel would b0rk.  With this done, both units now recognise the 1GB sticks of RAM installed.

At present, both systems are available for developer use.

How to upgrade the PROM on the Fulong.

For the reference of others who may wish to perform this upgrade on their Lemote equipment.  This is the procedure.

1. Download pmon_v1.1.zip from this page and unpack it.
2. Copy the pmon.bin file located inside, to your /boot partition (or somewhere else accessible to the PROM)
3. Reboot, and hit ESC/DEL repeatedly to break into the PMON prompt.
4. Type set, and write down any critical settings such as al and karg
5. At the PMON prompt, enter the following command (adjust:path as appropriate)
   load -r -f bfc00000 /dev/fs/ext2@wd0/pmon.bin
6. Restore the settings you wrote down using set arg value.
7. Type reboot to reset the system.

If at step 5, the load fails, DO NOT REBOOT OR POWER OFF! Hit the up-arrow on your keyboard, double check the command, then press ENTER to execute it again.

I’d like to thank the members of the Lemote Forum community who provided the necessary infromation.

Hi all…

Firefox 3.0.1 showing the Acid2 test on MIPS (click to enlarge)

I’ve been rather busy and thus haven’t had much time for Gentoo work, but today I managed to get some patches together that allow Firefox 3.0.1 to build and run on MIPS.

The ebuild is as yet, unkeyworded, as I wish to do some further testing.  I have successfully compiled it on little-endian MIPS, and it mostly seems to work okay.  It mostly passes the Acid2 test with some slight errors, but unfortunately, crashes part way through the Acid3 test — this I’ll investigate when I have the time.  It also crashes on my blog so your mileage may vary.

No testing has been done on big-endian MIPS at this stage, as my O2 is down for the short term (need to build a new kernel and get X running) so I’d appreciate feedback from users on this matter.

I’m pleased to annouce the final 2008.0 stages have been published.  I haven’t yet gotten around to giving them a run, I’ll set up a couple of chroots and do some test builds shortly, but in the meantime, I have put them up on my devspace for public review.

As previously announced, this release sees the addition of generic MIPS-1 stages for both big and little endian, as well as new stages for little-endian MIPS-3.  We still only support the hardware listed in the handbook however — the generic stages are provided merely as a convenience to those who may wish to experiment with other hardware, and know what they’re doing.

Approximately 1.2GB got uploaded over the 30 or so hours… this is apparent from my NTP server’s performance this weekend:

… Yeah… I think I’ll wait until I’m back at uni before I upload any more big files.

Anyway… as I say, the new stages are up, and I’d be greatful if some brave users could take them for a spin and report back.  In the meantime, I’ve got some chroots to set up and testing to do.

Hi all…

This is more a note to myself… but may also be useful with others who may be wondering WTF is wrong with their mod_auth_mysql setup.

To configure it, do it as per the instructions mentioned in the CONFIGURE file, or even following the /etc/apache2/modules.d/12_mod_auth_mysql.conf that the ebuild installs… HOWEVER… you will need to change the length of the password field in the MySQL code snippets to suit your encryption method.

I decided to use SHA1 hashes, which are 40 characters long (encoded as hex).  Thus, you use a column type of CHAR(40), and set your authentication configuration to use AuthMySQLPwEncryption sha1. To use the “scrambled” encryption scheme (uses MySQL’s PASSWORD() function), this column needs to be 41 characters long, not the 20 advertised in the examples.

Once you do this, everything should be fine… and things will work as expected.

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.

Hi all…

I’ve now uploaded the stages for Gentoo/MIPS 2008.0.  I’m hoping to get these pushed out to mirrors shortly, but in the meantime, you can find them on my devspace.  These stages need a fairly modern kernel, 2.6.19 or later, ideally  2.6.2x-series, otherwise you’ll strike issues with rm doing strange things (as people have reported already).  I have some kernel images for IP30, IP32, Loongson and Cobalt that should work with these stages.

These are only freshly compiled, and haven’t undergone much testing, so I’d appreciate it if some brave souls could give them a try and report back.  Stages are available for:

• Big Endian Systems (MIPS1, MIPS3 and MIPS4)
• Little Endian Systems (MIPSel1, MIPSel3 and MIPSel4)

Enjoy.

Hi All…

Just figured I’d bring you all up to date on how the new release is coming along. At this time, all little-endian MIPS builds are complete… and the big-endian builds are nearing their completion, with the MIPS3 BE build expected to be completed in a few hours. Only MIPS4 BE remains.

A number of users have had issues with the beta stages that I released earlier, in particular, there are known oddities with rsync and rm. These oddities arise when an old kernel (<2.6.19) is used. You’ll want at least kernel 2.6.20, preferably 2.6.22 or 2.6.23 running on the machine to use these stages.

Using the existing netboot images, you should still be able to at least set the disk up, extract the contents, then boot a precompiled kernel that’s sufficiently recent. How do you get the kernel? Well, for an up-to-date kernel, your easiest bet is to cross-compile. On a fast box (x86, AMD64… whatever), install genkernel, then use the command genkernel -t mips64-unknown-linux-gnu -S1 (or mips64el, or use mips/mipsel for a 32-bit compiler) to generate the cross compiler. Then use ebuild /path/to/mips-sources-VERSION.ebuild unpack to unpack a copy of the sources to your PORTAGE_TMPDIR (/var/tmp/portage by default). Then follow the instructions in the handbook as per normal, specifying CROSS_COMPILE=mips64-unknown-linux-gnu- (or mips64el…) when running make.

To get the kernel modules onto the machine, run make modules_install INSTALL_MOD_PATH=/somewhere, then tar these up. Then from the SGI box, use scp inside the chroot to download them, and unpack into /. Use the same procedure to fetch the vmlinux (or vmlinux.32) binary from your build host.

I’ve put up a new netboot image for Cobalt, although I’ve noticed 2.6.23 mips-sources has some stability issues with Cobalt, so I may yet put up another netboot image. Lemote users should find the existing images are sufficiently recent to run these stages, so I haven’t worried about putting newer images up for that platform. I’m not sure how the big-endian netboot images are constructed, so at this time, I’m not able to provide images for these platforms. (Plus, I can only test R4k IP22, IP28 or RM5k2 IP32… my Octane is dead for now.)

I hope to be uploading some material in a fortnight’s time for you to all try out.

Hi all…

There seems to be a little confusion as to whether the PS2 is supported by Gentoo. To clarify, it isn’t. There was never any effort to officially support the PS2. Some unofficial work did begin some years ago, however that work ceased fairly early on, and there has been no interest in continuing it.

There are a number of technical reasons why the PS2 is not supported.

First and foremost, the CPU is a real bastardised piece of work. It implements a custom instruction set, which is a hodge podge of MIPS I, MIPS II, MIPS III and MIPS IV, with some special instructions thrown in. It doesn’t fully implement any of the aforementioned instruction sets. So binaries such as my mipsel1 stages, will not work — you’ll hit illegal instruction errors fairly early on.

Secondly, the patches necessary for the kernel, and toolchain, are based on a really ancient set of packages. The kernel released with the PlayStation II Linux kit (2.2.1), was a year old when the first PS2 hit the shelves. Not so bad then, but the kernel was never properly maintained. Even today, unofficial efforts have only gotten as far as 2.4.3x-series. The toolchain is still quite ancient, at best, gcc-3.3 from what I recall, is the best they’ve got. Maybe they’ve got as far as 3.4… who knows…

Thirdly, the memory on the PS2 is restricted to 32MB. This is soldered on-board, can’t be upgraded. Gentoo/MIPS will not build most packages with 32MB RAM. Once upon a time, I could just build stages with 64MB on my Qube2, if I shut down things like MySQL — not anymore, I need 128MB to do this today. uClibc could be feasible, but you’d still have problems with the “special” CPU. Virtual memory doesn’t help — even if you had 2YB of swap, it wouldn’t stop builds dying.

Other MIPS-based consoles, such as the original PlayStation (MIPS R3000-based) and the PlayStation Pocket (MMU-less MIPS32r2) are also not supported for similar reasons.  And we (MIPS team) don’t support the PlayStation 3 either — for that, you should talk to the PowerPC team.

Now… I have no complaints about answering questions about what we support/don’t support… but a few points… (this is where my rant starts by the way)

1. Write properly when in the IRC channel. If it’s one thing that’ll quickly get my back up, it’s SMS-like chat on IRC. I’m tolerant of spelling errors and grammatical mistakes, but I won’t tolerate laziness. If a word has vowels in it, include them! It’s not like it’s significantly more effort to press an additional button on a keyboard. If you’re using morse to drive the computer, or have a physical disability that makes typing difficult, fine, declare this up front, and all will be okay, but otherwise, there’s no excuse.
2. Read the documentation! It tells you what we support, and what we don’t. It’s likely your question is answered there already.
3. If we can’t help you with some non-supported platform, we mean it… don’t pester us about it, we’re not going to start supporting a new platform in 5 minutes flat.

Hi All…

Whilst building a new netboot image for Cobalt systems, I discovered there’s a bug relating to the PCI handling in the latest kernel ebuild. In short, the pata_via driver is broken out-of-the-box, it’ll complain about being unable to register I/O resources, and the disks will be inaccessible.

To fix — download this patch, and apply it to your source tree using patch -p1 < patchfile, then rebuild your kernel (it’ll take a few seconds). You’ll notice the new kernel should boot successfully.

When Kumba returns, I’ll get him to add it to the mips-sources patchset so this is done automatically.

Hi All…

Those who have been trying out the 2008.0 beta stages I put out recently, probably will have ran into problems with tools like rm and touch not working properly.  It turns out, a series of kernel updates between 2.6.16 (what most of the netboot images are based on, except Cobalt which uses 2.6.13), and 2.6.19-rc5 (what my O2 runs), there have been changes to some of the system calls.  So the newer coreutils breaks on the older kernels.

I’m now in the process of updating the kernels used.  As I type this, I’m recompiling the Cobalt netboot image (same userland tools, just a newer kernel … at some point I’ll recompile the userland too), downloading the 2.6.20 kernel for IP28 users, and I’ll look into IP22 (r4k), IP30 and IP32 as well.

Sadly, R5k IP22 and IP27 will get ignored here — because I don’t have any suitable hardware to test them on.  Otherwise I’d update those too.

I’ll let you all know when the newer netboot images are available.