Installing Debian Linux 5.0 on the Qemu Dec Alpha

Years ago I’d written this terribly vague, and generic quickie post that Debian 5 will in fact boot inside of Qemu. I didn’t really want to get into it as it’s a little complicated and a lot painful. People have cried out over the years, but I figured I’d help people.

Linux for the Dec Alpha

For operating system tourists, I’ll save you the story, just go here, and download qemu-2.2.50-DecAlphaDebian.7z. You’ll quickly find out it’s borderline useless, and go onto your next thing. You’re welcome.

First thing this was running in 2014, and newer Qemu’s seem to behave… strange. So I stuck with a late 2014 build of Qemu. If you deviate from here , you are on your own. I did dig up quite a few other Dec Alpha AXP emulators and put them on archive.org. -But that’s totally up to you, again I’m sticking with 2014’s Qemu.

The BIOS/Pal on Qemu’s Alpha is far from complete and cannot read disks, so no boot sectors, boot loaders, no on disk kernels. All is not lost, you can inject a kernel and initrd, however this is where the fun is. Obviously to install you need to extract both from the ISO file. Also make sure the kernel is decompressed, add a .gz extension and de-compress it, as it should be around 6MB.

qemu-system-alpha.exe -net nic -net user -drive file=alpha.vmdk,if=ide,media=disk -drive file=debian-5010-alpha-netinst.iso,if=ide,media=cdrom -initrd initrd.gz -kernel vmlinux

This is vaguely how to boot up the installer. Partition, make sure hda1 hda2 hda3 etc are created and all is fine.

Now the next amount of fun is that you need to extract the created initrd as the installer initrd always launches the installer. The busybox cannot create tar files, there is no ftp or scp, also I couldn’t get it to even try to mount NFS images.

However on Windows 10 with WSLv2 or a Linux machine you can mount the disk image (keep it raw? or convert it?)

losetup /dev/loop0 myimage.disk 
partprobe /dev/loop0
mount /dev/loop0p1 /mnt/myimage

These three steps will let you mount the disk in this case /dev/loop0p2 which is the root filesystem. Debian didn’t have partprobe installed so I had to apt-get install parted

Now that you can mount it, you can copy the boot/initrd.img-2.6.26-2-alpha-generic file.

We do need to tell Linux where the root filesystem is so to finally run Qemu it’s like this:

qemu-system-alpha.exe -net nic -net user -drive file=alpha.vmdk,if=ide,media=disk -initrd initrd.img-2.6.26-2-alpha-generic -kernel vmlinuz-2.6.26-2-alpha-generic -append "root=/dev/hda2"

Obviously this was a lot more time consuming than it should be, but now I can do useful things.

Also sometimes Qemu just sits there with a black screen. the UI is waiting for something ,not sure what. It’ll either come to life on it’s own or you got to bang it.

A mildly annoying 32bit adventure, also happy 30th PGP!

It’s been 30 years since the initial launch of PGP! Hard to believe what a firestorm it ignited i the 1990’s and the real pity of how the crypto field is just as baffling and confusing to people today as it was back then.

It’s crazy how crypto went from being an obtuse tool, to suddenly being in the hands of normal people with a public web of trust, and widely available source. And of course it was that widely available source that led to the first real people of trying to geofence on the internet, and it was naturally impossible to contain, even in the era before VPN’s people were able to circumvent any and all “protections” and download away. Strong cryptography went from being something considered ‘weapons grade’ and thusly requiring a munitions license to produce and distribute to suddenly being available to the world at large.

Investigations were launched, agencies contacted, and in spite of it all people had signing parities to exchange public keys, and sign the trust building the web. Try as some people may have demanded ‘back door access’ or black box crypto chips, the cat was out of the bag, and all you needed was a C compiler and a zip file small enough to easily fit on a low density 5 1/4″ diskette. It is 1991 after all, and there is still a sizable amount of XT/AT class machines out there, along with the 68000 Amiga/Atari/Macintosh (upgraded QL’s? 128kb really isn’t enough).

PGP 1.0 is from another era, originally written in the late 80’s cleaned up and released in 1991 where mass produced 64bit machines were still a bit off, and thusly PGP 1.0 really supports 16bit & 32bit OS’s. For the purpose of this ‘revival’ I went with the Unix port, the aptly named unix_pgp10.tar.gz. And from the MS-DOS version I extracted the test data to make sure it works in the file pgp10-test-data.tar.gz

$ file pgp
 pgp: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=cd9ecbf51fab24abbb7153a2cc04bb01bbf2ae91, not stripped
$ ./pgp testfile.ctx
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 File is encrypted.  Secret key is required to read it.
 Key for user ID: Bond, James (007)
 288-bit key, Key ID A27A1F, created Sat Oct 19 23:56:24 3006391
 You need a pass phrase to unlock your RSA secret key.
 Enter pass phrase:

While it was simple enough to build, sadly on x64 WSL instance it doesn’t work. There is no pass phrase for the test data.

Normally I have one of usual two choices a) try to fix PGP to be 64bit friendly or b) run it under a 32bit environment. Normally I would do b, but I went digging into some porting strategies for the a choice and ran into this totally underused tech x32.

Long story short you keep your 32bit integers, you run like it’s a 32bit process but you are mapped into a 64bit address space. Even better -static works!

On Debian 10 the environment can be installed with the following:

apt-get install gcc-7 lib32gcc-7-dev libgcc-7-dev libx32gcc-7-dev gcc-7-multilib

Then to invoke it, use gcc-7 -mx32 . It’s that easy.

WSLv1 vs WSLv2

$ ./pgp
 -bash: ./pgp: cannot execute binary file: Exec format error
$ file pgp
 pgp: ELF 32-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=2aa5f030603018ca1dc6c5c10aa979751b006aca, for GNU/Linux 3.4.0, not stripped

Notice it is now a 32-bit LSB executable, but also in the x86-64 address space! However under the WSLv1 environment it won’t work. Time to update to v2

   wsl --set-version Ubuntu-20.04 2
   Conversion in progress, this may take a few minutes…
   For information on key differences with WSL 2 please visit https://aka.ms/wsl2
   WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel 

And now with the instance converted:

$ ./pgp
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 For details on free licensing and distribution, see the PGP User's Guide.
 For other cryptography products and custom development services, contact:
 Philip Zimmermann, 3021 11th St, Boulder CO 80304 USA, phone (303)444-4541
 Usage summary:
 To encrypt a plaintext file with recipent's public key, type:
    pgp -e textfile her_userid      (produces textfile.ctx)
 To sign a plaintext file with your secret key, type:
    pgp -s textfile your_userid     (produces textfile.ctx)
 To sign a plaintext file with your secret key, and then encrypt it
    with recipent's public key, producing a .ctx file:
    pgp -es textfile her_userid your_userid
 To encrypt with conventional encryption only:  pgp -c textfile
 To decrypt or check a signature for a ciphertext (.ctx) file:
    pgp ciphertextfile [plaintextfile]
 To generate your own unique public/secret key pair, type:  pgp -k
 To add a public or secret key file's contents to your public
    or secret key ring:   pgp -a keyfile [keyring]
 To remove a key from your public key ring:     pgp -r userid [keyring]
 To view the contents of your public key ring:  pgp -v [userid] [keyring]
$

And we are in business! Now we can run the example crypto test:

$ ./pgp testfile.ctx
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 File is encrypted.  Secret key is required to read it.
 Key for user ID: Bond, James (007)
 286-bit key, Key ID A27A1F, created (null)
 Advisory warning: This RSA secret key is not protected by a passphrase.
 Just a moment-- .
 File has signature.  Public key is required to check signature. .
 Good signature from user "Smart, Maxwell (86)".
 Signature made Thu Jun  6 05:28:52 1991
 Plaintext filename: testfile

And there we are!

PGP 1.0 suffers from 2 real defects of the era the first being the home brew bassomatic that is apparently full of all kinds of flaws, and the second lurking in rsalib.c

 The RSA public key cryptosystem is patented by the Massachusetts Institute of Technology (U.S. patent #4,405,829).  Public Key  Partners (PKP) holds the exclusive commercial license to sell and  sub-license the RSA public key cryptosystem.  The author of this  software implementation of the RSA algorithm is providing this  implementation for educational use only.  Licensing this algorithm  from PKP is the responsibility of you, the user, not Philip Zimmermann, the author of this implementation.  The author assumes no liability for any breach of patent law resulting from the unlicensed use of this software by the user. These routines implement all of the multiprecision arithmetic necessary for Rivest-Shamir-Adleman (RSA) public key cryptography.

And it ignited so much of a war about licensing the RSA cryptography base. It wasn’t until 1992/1993 that the RSA released their own aptly named rsaref that at least clarified and addressed their licensing restrictions. As we found out later it wasn’t the DOJ shutting down encryption, nor wild acts of congress instead it was US Patent 4,405,829 which finally expired in Sept 21, 2000, along with US patent 4,200,770 Hellman Diffie Merkle, public-key cryptography which expired in September of 1997. So in the end it was the lawyers who were to be feared, not the the US Government.

Another source of annoyance was the public/private key files are stored in a binary format (hence the 16/32/64 issues I’m sure!).

C:\temp>pgp -v jason.pub
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 Key ring: 'jason.pub'
 Type bits/keyID   Date     User ID
 pub  990/F7CAD5 12-Jun-21  Jason Stevens
 1 key(s) examined.
 C:\temp>type jason.pub
 °ü½╟╓iº½t↕Hï╜Æ(↑ªα&E☼lKL$*⌠=└¥╒[׊s,â•”kÃ¥r~▐MFBv≥≡╫Eâ”´â•ŸTÿ║µó â•¨6,♣â—„Ermo▼æ▄;± ùî
 C:\temp>

So naturally you have to use uuencode which led to MIME collisions and other fun stuff down the road. yay!

begin 666 jason.pub
MF9,`$!C$8`U*87-O;B!3=&5V96YSW@/5RO>TFV)_9@%49RW3NYGD<8*H`3X1
MZ>D'/F/D7$)OKD9&K+>A<@4<,$RV.+M?9VR;17)M;Q^1W#OQ()>,#?B!J\?6
M::>K=!)(B[V2*!BFX"9%#VQ+3"0J]#W`!YW56]>*<RS):X9R?MY-1D)V\O#7
/1<''5)BZYJ+_T#8L!0`1
`
end

Even though today we have widespread SSL, and all kinds of apps that encrypt by default, but Operation Trojan Shield shows that that an app is simply not enough, and you cannot trust anything.

Though Enigma had some cryptographic weaknesses, in practice it was German procedural flaws, operator mistakes, failure to systematically introduce changes in encipherment procedures, and Allied capture of key tables and hardware that, during the war, enabled Allied cryptologists to succeed and “turned the tide” in the Allies’ favour.[15][16]

-Wikipedia

And just like the spy movies good crypto is tedious, bulky and rarely used properly*.

Yes please don’t seriously rely on pgp 1.0!

Pinebook Pro first impressions

Pinebook Pro

So yes, it’s most certainly built from a MacBook Air looking frame. But it’s not the same build materials, which of course is to be expected as these are far cheaper. Unlike the other ARM book I have, this one doesn’t have a GPRS modem, and as of this moment doesn’t natively run Windows. Which with it’s paltry 4GB of RAM and 64GB of disk space is just as well.

adding a 32bit runtime

Just as the MIPS64 had it’s weirdisims, the ARM64 is in the same seat. I didn’t see anything all that clear on Manjaro, and 32bit, at the same time debootstrap is available in the repo, allowing you to quickly install a 32bit Debian userland to chroot into. It’s pretty much the same steps as before, with the only real change being to use the armhf processor family giving a 32bit tree.

Maybe it’s my overall familiarity with Debian, but I find the environment far easier to deal with. Well that and of course many things just build so much nicer in 32bit mode, than 64bit mode sadly. It’s a shame that many distros don’t seem to include a matching 32bit/64bit libset but here we are.

Another plus is that Debian has far more robust mirrors world wide, and downloading components and updates is FAR faster than Manajro.

Loose clips?!

In the first week however disaster struck as I had it ‘sleeping’ one night and plugged in to charge, and when I opened the lid, I got nothing. The charging led showed RED for some reason like it was still charging, and no matter what I tried on the keyboard it just would not turn on.

Searching online didn’t give me much other than people saying that they were replacing the built in flash and didn’t seat it correctly. Did my kids or cat knock it over when I wasn’t looking? Was it on the edge of not being seated from shipping? I have no idea.

Lid off!

Well as much as I love opening new stuff, it was acting dead so I guess nothing to lose. That said the screws come off pretty easily but there is 2 sizes as the ones up front are super short. With the lid off you can see that the battery is 2x the size of the motherboard. And yeah of course it being ARM, its very raspberry pi – ish. And I guess it’s really no surprise.

The mainboard

On the mainboard there is 2 push buttons, and 2 sliding jumpers. One is hidden beneath the black tape. I hit the reset button, and slid both sliders up and down and then pressed down on the 64GB chip. I flipped it over to see if that did anything, and surprisingly it’d turn itself on!

I quickly shut it down, and screwed it back together. And I’ve been using it daily over the last week without any further issues with it powering on. Again I have no idea what was wrong but at least it seemed easy enough to open up and hit some buttons. Which brings me to the overall feel:

Build quality

It’s really hard to slam the PineBook Pro. It has incredibly lofty goals, and for the pricepoint it’s absolutely insanely good value. The body has been molded from what at best could be called an ‘inspired by the Mac Book Air’ but it’s the keyboard and trackpoint where it falls short. The keys have too much travel for their own good, and seem to twist a little giving a klunk as they don’t depress quite right. I have had issues with the arrow keys trying to play DooM via DOSBox. And I’ve become so spoilt with backlit keys, that although I know how to touchtype I still look from time to time.

The trackpoint is miserable, it’s constantly jumping the mouse (no palm detection)? and it just doesn’t glide or click ‘right’. But I know I’m being 100% unfair as I’m comparing this to a laptop that is 5x the price. I’ve written this and other stuff on the laptop and it’s just been so jumpy at times for seemingly no reason when I type it’ll jump and click at the worst possible moments.

The flip side is that FPS stuff is impossible as the keyboard and trackpoint won’t deliberately work at the same time. And I have no idea how to go about dealing with that. I guess use an external mouse.

Another stupid low point is the speakers. They are so tinny which I guess is to be expected, but they are so quite. I guess I should play test tones, and get some app to measure dB, but comparing it to anything else again just seems so unfair.

That said the screen is AMAZING. I had worried that the screen was going to be terrible, but no the screen is an absolute high point of the machine.

Battery life has been pretty good, and from opening it up, it’s no surprise as it does have a massive battery. They do include clips to bypass the battery all together if you want to run it from DC mains 100%. The only issue I have had with battery life is that Manjaro doesn’t seem to have hibernation support. And many times I put it to sleep when I go to sleep it’ll wake up with zero percent remaining. I don’t see that as a fault of the physical build, rather the OS.

Software and FSF flailings?

I don’t know much about Manjaro but it’s default setup sure feels a lot like the way Debian felt when they were under pressure to keep all non-free stuff segregated and partitioned away from users. The problem as it’s always been is that popular software has almost always been commercial, especially for normal uses. Turning on Community and Contributions should really be the default setting with people who want to be FSF pure having to click the button giving normal people the best possible experience. As an old person who’s been hearing about the ‘year of the Linux desktop’ is at hand back in 1997 (Va Linux et al), and been an on and off user since SLS, it’s always about the users. All the plugins and bookmarks and shared data stuff I have is on Chromium and having to hunt down how to turn it on sucked, as I was moments away from just doing the usual ‘user’ thing of wiping the install because I can’t find an app.

Distro shopping has been the worst thing to plague Linux since it was apparent that Linus wasn’t going to bless us a userland, unlike BSD. I know some see it as a strength but it’s always been such a critical weakness for the user. Oddly enough the circle has come around to bite enough people that Docker is a thing to deal with dependency and distro hell.

Games!

Well without a doubt visit astr0baby’s blog and enjoy some good hand holding to get a bunch of open stuff built. It’s toally worth it. And incredible to play 64bit Duke Nukem 3D!

Is it worth it?

Well if you want non x86 on the go, the price simply cannot be beat. However the default Linux install is alien to me, but I’m trying to learn to deal with it. And of course the weird power on issue really precludes this from normal people. I’d recommend it to anyone comfortable with Linux and a screwdriver. If you are 100% hardware focused it’s a laptop, no GPIO so it’s going to be a little bit of a bummer. If you are scared of opening it up, you may find like I did that you very well might have to. However for anyone in the middle absolutely.

“Normies” this isn’t the laptop you want. .. I’d say “yet” as I’m sure that build quality will only improve, just as software will hopefully get a bit more friendly for adding stuff like Chrome (what a mission to get it installed!).

Final ramblings

Years ago in college we joked that 30 years in the future you could get a quad processor Dec Alpha as a bundle in with a box of cereal. That a computer would be an impulse purchase at the supermarket. It seemed so laughable but a given as manufacturing and acceptance of that internet thing was a given. But that was the future from 30 years ago.

The future is now!

GCC 2.5.8 failure on 32bit ARM

This is really nothing more than a placeholder for me… Unless someone else knows the answer, then it’s really ‘how not to cross compile GCC’.

First I’m using the EMX’ified version of GCC from my MinGW to EMX cross. It didn’t require that much massaging to get it to build, the usual unzip as ascii to convert text, and in no time I can build cc1.


root@pinepro:/src/emx/src/gcc-2.5.8# file cc1
cc1: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42c0c8de7175edade7614dc92d5d13e4421e0e6f, with debug_info, not stripped

and it crashes in what has to be a 2020 most unfortunte name

Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1 

Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>, 
    outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667     {
(gdb) 

Yes, it really crashes in rtx_cost. Good thing there isn’t a super popular card from Nvidia that is currently being short squeezed by crypto miners right now called the RTX where everyone is looking for a good price. 😐

I had then been thinking perhaps it’s because I’m using GCC 8.3.0, maybe it’s introducing some new and exciting bug? So I cross compiled GCC 4.1.2 as follows:

./configure --target=armeb-linux --host=armeb-linux --build=armeb-linux

Keeping in mind that my knowledge of ARM is pretty much nill, especially on Linux. The compile went mostly okay, just have to remember the gnu inline macro’s as needed from back in the day (-fgnu89-inline) and while it builds, it is insisting on using collect2 which of course is screwing things up. And of course I don’t want it as my system compiler. As a hack I found system gcc 8 can link things fine as I didn’t want to spend all day messing with GCC/collect2

I copied xgcc, cc1 and cpp from 4.1.2 into a /412 directory, and rebuilt 2.5.8 with the following shell:

make CC="/412/xgcc -B/412 -g -O0  -I. \
-I./config \
-I/usr/lib/gcc/arm-linux-gnueabihf/8/include \
-I/usr/local/include \
-I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed \
-I/usr/include/arm-linux-gnueabihf \
-I/usr/include" cc1

As you can see the cross wasn’t picking up the right include paths, so I just cheated, and dumped them from 8, and just copied them into this script. I re-ran the build and had 2 issues,

/412/xgcc -B/412 -g -O0  -I. -I./config -I/usr/lib/gcc/arm-linux-gnueabihf/8/include -I/usr/local/include -I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed -I/usr/include/arm-linux-gnueabihf -I/usr/include -c  -DIN_GCC   -g -std=gnu89     -I. -I. -I./config local-al.c

....

/tmp/ccMguyhs.s: Assembler messages:
/tmp/ccMguyhs.s:5001: Error: selected processor does not support `fltd f1,r3' in ARM mode
/tmp/ccMguyhs.s:5025: Error: selected processor does not support `fltd f0,r3' in ARM mode
/tmp/ccMguyhs.s:5026: Error: selected processor does not support `dvfd f1,f1,f0' in ARM mode
/tmp/ccMguyhs.s:5027: Error: selected processor does not support `ldfd f0,.L489' in ARM mode
/tmp/ccMguyhs.s:5028: Error: selected processor does not support `mufd f0,f1,f0' in ARM mode

and so on. Also failing was global.c Again the same weird instruction/asm mix being triggered. Other than those two, cc1 will build, but unsurprisingly:

Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1 

Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>, 
    outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667     {
(gdb) 

Well, at least it’s consistent?

Or a fun way to kill a couple hours.

**EDIT I went ahead and looked in the 4.1 source for ARM stuff..

root@pinepro:/src/gcc-4.1.2# grep arm config*|grep linux
grep: config: Is a directory
configure:  arm*-*-linux-gnueabi)
configure.in:  arm*-*-linux-gnueabi)

it didn’t like the gnueabihf stuff one bit.

I tried to rebuild as linux-gnueabi

./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=arm-linux-gnueabi

make LANGUAGES=c HOST_CFLAGS='-fgnu89-inline' CFLAGS='-fgnu89-inline'

And then re-built GCC 2.5.8 with the same error, but slightly further into the program:

Starting program: /src/emx/src/gcc-2.5.8/cc1

Program received signal SIGSEGV, Segmentation fault.
0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
679       code = GET_CODE (x);
(gdb) bt
#0  0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
#1  0x004f2e20 in rtx_cost (x=0x60c3f8, outer_code=SET) at cse.c:736
#2  0x004ac2dc in init_expmed () at expmed.c:87
#3  0x0045ae28 in compile_file (name=0x5c96ec "stdin") at toplev.c:1648
#4  0x0045f6fc in main (argc=1, argv=0xfffefd04, envp=0xfffefd0c) at toplev.c:3569
(gdb)

The positive thing is that there was no weird register errors while compiling, and it built 100% normally…? “arm-linux-gnueabihf” almost seems right, specs needs fixing to point to “/lib/ld-linux-armhf.so.3” instead of “/lib/ld-linux.so.3” along with the linker target.

Fun with Caldera WABI

(This is a guest post by Antoni Sawicki / Tenox)

In the previous post about SCO Merge I briefly mentioned WABI, which is a Windows ABI emulator for Unix. Initially released by Sun Microsystems, it’s believed that it came with acquisition of Interactive Systems Corp (ISC) and Interactive UNIX. It was available for SPARC, x86 and PowerPC Solaris as well as IBM AIX. Around 1997 it was released for x86 Linux by Caldera. This article will focus on Caldera’s version specifically.

Although entirely possible to install WABI on another RPM based distribution such as Red Hat, I’m a purist and wanted to try it on Caldera Open Linux. The install is pretty straightforward you mount the iso file and run install script. In a next step you need to install an update to version 2.2D. This is done by replacing /opt/wabi/bin/wabiprog with extracted version of this file. Thanks to readers of this blog post for sharing these.

When launched for the first time, you will be prompted to provide copy of Windows 3.1. This the main difference with WINE which specifically does not require copy of windows to run apps. I have noticed that WABI is rather picky about lower vs uppercase when installing software. There is an utility called wabimakelower to help there. You can also add an icon to one of Caldera Linux / Looking Glass program groups.

Once you run it, it’s Windows 3.1 as usual:

WABI was designed for running productivity apps such as Office:

You can even run Visual Studio:

Curiously WABI is not a MS-DOS emulator. In order to run DOS apps you need to install such and configure it in WABI Control Panel:

For the lazy, a readily preinstalled version is available as OVA and 86box. Root password is “caldera”.

There also is a User Guide in PDF.

Have Fun with Virtualization!

Minecraft on the loongson-3A4000 / Lemote A1901

It runs!

This was a bit more work than I had anticipated. However flygoat had done much of the legwork for me. The first thing to get is flygoat’s mc-loongson.zip. I made a local download as I suspect many will not have QQ or WeChat (Or don’t want to admit to the government that you are downloading this…).

I’m not sure if it’s a MIPS thing or a UOS thing, but it had Java 11.0.4 in by default, which is CRAZY slow

$ /usr/lib/jvm/java-1.11.0-openjdk-mips64el/bin/java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-post-Debian-1deb10u1)
OpenJDK 64-Bit Zero VM (build 11.0.4+11-post-Debian-1deb10u1, interpreted mode)

I installed version 8, but they are ‘in parallel’ in different directories… I guess it’s the .net hell drift all over again. Although to be fair I’ve only dealt with vendor installed java on Linux where it’s all fixed to single versions.

/usr/lib/jvm/java-1.11.0-openjdk-mips64el/bin/java --module-path /usr/share/openjfx/lib --add-modules=javafx.controls,javafx.fxml,javafx.base,javafx.media,javafx.web,javafx.swing -jar HMCL-3.2.139.jar

One annoying thing is that it cannot find JavaFX over and over despite it being installed, so I had to manually add the ‘module-path’. This is the syntax for version 11, I’m not all that sure on the version 8 syntax.

$ /usr/lib/jvm/java-8-openjdk-mips64el/bin/java -version
openjdk version "1.8.0"
OpenJDK Runtime Environment (Loongson 8.1.3-mips64r2-uos) (build 1.8.0-1.8.0.212-2deepin-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

I changed the /etc/alternatives/java to point to version 8, which although causes the launcher to crash launching the actual exe, it’s trivial enough to change it to version 8. Although the command is… unwieldy but save it to a shell script.

I’m sure it won’t paste well, but here we go.. and it’s in my homedir sooo here we go!

/usr/lib/jvm/java-8-openjdk-mips64el/bin/java “-Dminecraft.client.jar=.minecraft/versions/1.15.2/1.15.2.jar” “-Duser.home=null” -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC “-XX:G1NewSizePercent=20” “-XX:G1ReservePercent=20” “-XX:MaxGCPauseMillis=50” “-XX:G1HeapRegionSize=16M” -XX:-UseAdaptiveSizePolicy -XX:-OmitStackTraceInFastThrow -Xmn128m -Xmx7936m “-Dfml.ignoreInvalidMinecraftCertificates=true” “-Dfml.ignorePatchDiscrepancies=true” “-Djava.library.path=/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2-natives” “-Dminecraft.launcher.brand=HMCL” “-Dminecraft.launcher.version=3.2.139” -cp /home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/patchy/1.1/patchy-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/oshi-project/oshi-core/1.1/oshi-core-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/jna/4.4.0/jna-4.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/platform/3.4.0/platform-3.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j/66.1/icu4j-66.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/javabridge/1.0.22/javabridge-1.0.22.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/sf/jopt-simple/jopt-simple/5.0.3/jopt-simple-5.0.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/io/netty/netty-all/4.1.25.Final/netty-all-4.1.25.Final.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/guava/guava/21.0/guava-21.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-io/commons-io/2.5/commons-io-2.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-codec/commons-codec/1.10/commons-codec-1.10.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jinput/jinput/2.0.5/jinput-2.0.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jutils/jutils/1.0.0/jutils-1.0.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/brigadier/1.0.17/brigadier-1.0.17.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/datafixerupper/4.0.26/datafixerupper-4.0.26.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/code/gson/gson/2.8.0/gson-2.8.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/authlib/1.6.25/authlib-1.6.25.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-compress/1.8.1/commons-compress-1.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpclient/4.3.3/httpclient-4.3.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-logging/commons-logging/1.1.3/commons-logging-1.1.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpcore/4.3.2/httpcore-4.3.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/it/unimi/dsi/fastutil/8.2.1/fastutil-8.2.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-api/2.8.1/log4j-api-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-core/2.8.1/log4j-core-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/text2speech/1.11.3/text2speech-1.11.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j-core-mojang/51.2/icu4j-core-mojang-51.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2.jar “-Djava.library.path=/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2-natives” “-Dminecraft.launcher.brand=HMCL” “-Dminecraft.launcher.version=3.2.139” -cp /home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/patchy/1.1/patchy-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/oshi-project/oshi-core/1.1/oshi-core-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/jna/4.4.0/jna-4.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/platform/3.4.0/platform-3.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j/66.1/icu4j-66.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/javabridge/1.0.22/javabridge-1.0.22.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/sf/jopt-simple/jopt-simple/5.0.3/jopt-simple-5.0.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/io/netty/netty-all/4.1.25.Final/netty-all-4.1.25.Final.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/guava/guava/21.0/guava-21.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-io/commons-io/2.5/commons-io-2.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-codec/commons-codec/1.10/commons-codec-1.10.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jinput/jinput/2.0.5/jinput-2.0.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jutils/jutils/1.0.0/jutils-1.0.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/brigadier/1.0.17/brigadier-1.0.17.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/datafixerupper/4.0.26/datafixerupper-4.0.26.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/code/gson/gson/2.8.0/gson-2.8.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/authlib/1.6.25/authlib-1.6.25.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-compress/1.8.1/commons-compress-1.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpclient/4.3.3/httpclient-4.3.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-logging/commons-logging/1.1.3/commons-logging-1.1.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpcore/4.3.2/httpcore-4.3.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/it/unimi/dsi/fastutil/8.2.1/fastutil-8.2.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-api/2.8.1/log4j-api-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-core/2.8.1/log4j-core-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/text2speech/1.11.3/text2speech-1.11.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j-core-mojang/51.2/icu4j-core-mojang-51.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2.jar net.minecraft.client.main.Main –username USERNAME –version “HMCL 3.2.139” –gameDir /home/neozeed/mc-loongson/.minecraft –assetsDir /home/neozeed/mc-loongson/.minecraft/assets –assetIndex 1.16 –uuid UUID –accessToken TOOOOKENNNNNN –userType mojang –versionType “HMCL 3.2.139” –width 854 –height 480

Naturally you’ll need your own username, token, uuid..

One thing is for sure, setting the graphics to higher details gives better performance. I suspect that it’s a matter of pushing more of the rendering to hardware, out of software mode.

I have it set to Fabulous! graphics, render distance of 25 chunks, no vysnc, clouds fast, mipmap level 2.

While it does take a while to load up, join the server, and do the initial world loading, you can watch all 4 cores run at 100%, but once it’s loaded in, it’s down to a single core at 100%, and the other 3 are hovering around 10-25%. So once jit’d and loaded in it seems to run okay.

They are jackhammering downstairs and I could make this 1 minute clip in a brief moment of peace. This is before I figured out that the more acceleration you give Minecraft, the faster it runs with the GPU doing the heavy lifting (I think).

Is this the machine for the Minecraft enthusiast? Hardly, but Minecraft is the Java success story, where a platform like this, a fringe non mainstream platform will run a commercial app. This is where the real portability of binutils/gcc/libc and Linux prove to be the winning platform.

Adding a Radeon RX 570

I saw this card while I was out, and I’ve seen mention of some Radeon’s working on the Lemote A1901 board, although it didn’t like my Asus Radeon R9 380 Strix, I’m guessing it’s too old? I can’t find it now, but there was some mention somewhere of someone using a 500 series card (I don’t understand the AMD number schema), so I figured I’d get the 570 as it was just over $100 USD, and it has 8GB of VRAM, so it ought to be somewhat usable if I guessed wrong on the compatibility.

But I did get lucky! The card not only was able to initialize, but UOS came up to the desktop!

glxinfo -B gave the following output:

name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: Radeon RX 570 Series (POLARIS10, DRM 3.27.0, 4.19.0-loongson-3-desktop, LLVM 7.0.1) (0x67df)
Version: 18.3.6
Accelerated: yes
Video memory: 8192MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2

So there we go, 8GB of memory, and ‘Accelerated: yes’. It’s also FPS locked to the screen refresh so it’s running a steady 60fps for the display I’m using. I need to build some later games that use GL to really push the machine.

The one big ‘negative’ is that the video card sits over the SATA ports, so I need to get an L connector SATA cable, as now I can’t use my 2TB spinning rust disk with the fancy GPU in place. And it makes my 800 watt PSU all the more justified.

I’m just glad that the portable drivers, well are portable!

Adding a 32bit runtime to UOS

AKA what happens when your OS is from one Debian like distribution and lags behind the rest of the world, but you want to run a parallel infastructure. Obviously for people who have sane setups their stuff is in sync and this doesn’t apply.

HOWEVER for people who use USO they will find out quickly that it’s a Debian derived MIPS64EL based distribution, but they don’t keep any MIPSEL (32bit) binaries. So I was thinking add in the dpkg arch, and some deb sources and I’d be good to go, right? Except the stuff is out of step so what happens is that UOS decides it wants to replace the OS with what is on the mipsel repos. Even when specfiying the arch’s directly.

deb [by-hash=force arch=mips64el] https://professional-packages.chinauos.com/desktop-professional eagle main contrib non-free
deb [arch=mipsel] http://deb.debian.org/debian buster main contrib non-free

I tried.

So the good news is that I asked around and found a solution that I’d never heard of, “debootstrap”. The general page is here:

What it boils down to is that it’s a script set that will download enough DEB’s and extract them onto a directory and prep it out as a chroot/jail. And you can specify whatever architecture you want, you can even use qemu to run totally alien stuff! I’d never heard of this before, such a shame.

From my rough notes I did something like this:

/usr/sbin/debootstrap --arch mipsel buster /usr/local/mipsel http://deb.debian.org/debian

This will install the mipsel platform of Buster into /usr/local/mipsel

running the following gets me into the chroot/jail/container..

LANG=C.UTF-8 sudo chroot /usr/local/mipsel /bin/bash

YES it’s that simple! Although there is some house cleaning to be done:

apt install makedev
mount none /proc -t proc
cd /dev
MAKEDEV generic

Making the devices sure took long enough, but now I could do the regular update, add in some compilers and stuff, X11, and whatnot and get things going. Remember to mess around with xauth to get X11 forwarding from chroot working

Now for the ‘fun’ part of linking the libs…

ln -fs /usr/local/mipsel/usr/lib/mipsel-linux-gnu /usr/lib32
ln -fs /usr/lib32/ld.so.1 /lib/ld.so.1

Then you need to ‘config’ ld.config with

cat > /etc/ld.so.conf.d/mipsel-buildroot.conf
/usr/local/mipsel/usr/lib/mipsel-linux-gnu
^D

Phew we are almost there!

$ file /usr/local/mipsel/bin/dash
/usr/local/mipsel/bin/dash: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=22877e3a9a83675b22a121c9d2f8943d7339e7db, stripped
$ sudo ldconfig;/usr/local/mipsel/bin/dash
$

And just like that we now can run dynamically linked 32bit MIPSEL binaries on UOS.

As a bonus (from stackexcahnge) here is how to run Xauth to get forwarding from the chroot. From the ‘base’ physical machine run:

$ xauth list
latitude/unix:0  MIT-MAGIC-COOKIE-1  d4474d13c

Now with that cookie run this in the chroot:

# xauth add latitude/unix:0 MIT-MAGIC-COOKIE-1 d4474d13c
# xclock

and the 32bit Xclock should pop up on your 64bit desktop.

Wasn’t that fun?!

Annoyance with the MIPS linker: relocation overflows

gcc disasm.o audio.o configuration.o dialog.o file.o hostcall.o keymap.o main.o memAlloc.o misc.o screen.o screenConvert.o sdlgui.o shortcut.o scalebit.o input.o fe2.o ../fe2.part1.o ../fe2.part2.o -L/usr/lib/mips64el-linux-gnuabi64 -lSDL -o ../frontier

/usr/bin/ld: ../fe2.part1.o: in function <code>load_binfile': fe2.s.c:(.text+0x180): relocation truncated to fit: R_MIPS_CALL16 against</code>fopen@@GLIBC_2.2'
/usr/bin/ld: fe2.s.c:(.text+0x19c): relocation truncated to fit: R_MIPS_CALL16 against <code>fseek@@GLIBC_2.0' /usr/bin/ld: fe2.s.c:(.text+0x1a8): relocation truncated to fit: R_MIPS_CALL16 against</code>ftell@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x1c0): relocation truncated to fit: R_MIPS_CALL16 against <code>fseek@@GLIBC_2.0' /usr/bin/ld: fe2.s.c:(.text+0x1e4): relocation truncated to fit: R_MIPS_CALL16 against</code>fread@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x1f0): relocation truncated to fit: R_MIPS_CALL16 against <code>fclose@@GLIBC_2.2' /usr/bin/ld: fe2.s.c:(.text+0x280): relocation truncated to fit: R_MIPS_GOT_DISP against</code>stderr@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x284): relocation truncated to fit: R_MIPS_CALL16 against <code>fprintf@@GLIBC_2.0' /usr/bin/ld: fe2.s.c:(.text+0x290): relocation truncated to fit: R_MIPS_CALL16 against</code>exit@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x2b4): relocation truncated to fit: R_MIPS_CALL16 against `__assert_fail@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x2c4): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:18: ../frontier] Error 1

I’d never heard or seen this before, and yeah it’s some MIPS’isim.

Apparently it’s something called a “global offset table” which of course has a 64k entery limit which can cause an overflow if you are doing something crazy like running a disassembler and having tens of thousands of instructions.

Looking at the GCC MIPS options page, there is hope, one can opt for a more iniffecient and larger table with the simple option of -mxgot

FrontVM-2 20061120

And now I can link frontvm.

A modern RISC workstation for a modern (government) era.

While discussing various non x86 boards the topic came up about the Chinese government MIPS based processors, namely the Loongson-3A4000. I’ve tried several times on the past to buy one with no success however 2020 would make up with it as 2 separate leads yielded boards.

To me, there is a great deal of confusion around this setup as it goes by different names, and is sometimes spelt in English, other times Chinese (Simplified & Traditional) with different part numbers and vendors making it kind of confusing.

Various names include, but not limited to:

  • Lemote loongson
  • loongson-3-desktop
  • LEMOTE-LS3A4000-7A1000-1w-V01-pc
  • ICT Loongson-3A R4(loongson-3A4000)
  • Lemote LX-6901
  • Lemote A1901
  • 龙芯3A4000+7A台式机主板

I don’t want to sound like I’m going to just shit all over this thing, but it’s not free, it’s not subsided, and it’s not cheap. Weighing in at 元3,500 RMB the LX-6901 is not a machine for the masses, however it is a non x86 machine for the classes.

Thanks to my day job I was able to get my buyer to trace down several companies, and ads placed on TaoBao and another from AliExpress. Last time I tried both routes, along with the board manufacter Lemote, I was unable to get anything. This time however both leads would work out so now I have 2.

I was told that it would take upwards of 2 weeks for the order(s) to be fulfilled and I should have them in 3 weeks. However 4 business days later this box arrived in my office:

presents from the orient

I suspect they need to temper people’s expectations on shipping, but luckily for me I’m not over seas, although shipping from China to Hong Kong does require a special permit for electronics.

Clearly the tape had been opened several times for various inspections as this shipment was destined to be exported. But props on the dragon tape!

As expected, two boards! Oddly and confusing enough both suppliers insist the boards are different.

Natrually, they are of course identical.

Here is a better glimpse at the board.

The Lemote LX-6901 is not without faults however, it has a memory controller issue and cannot operate correctly with 2 sticks of ram. Luckily my DDR4 extras are 16gb so it’s not bad for messing around. The board also can post ATI boards. However it doesn’t like my Asus Radeon R9 380 Strix board, although it posted fine. I have a few of the FirePro W2100 cards, not a remarkable card, but it does work.

In addition you do need a specific OS for the board, on vendor on AliExpress was unwilling to send me anything, while another on TaoBao was willing to send me UnionTech’s UOS.

System BIOS

the M.2 slot works fine and I was able to boot from USB, and install UOS. The BIOS is very ‘PC’ like, pressing ENTER will enter the bios, and you can change boot priorities, or drop to the UEFI shell if you so please.

BIOS initalization

Installation is pretty easy and straight forward. There is only a few options during install, the desination, if you should accept the default layout (why not)? and a language

The USB stick is slow, but it didn’t matter as I only needed to install twice. The first time I had both memory slots populated, and the board crashed at 5% of the install. I was able to do some searching around and found out about the bad memory controller, so popping out one of the DIMMs and I was able to install and use the machine.

UOS for the MIPS however is a seeming commercial product that is very difficult to buy outside of China (it may very well be allocated only for certain circles as you need a Chinese cellphone number, government ID, and some kind of project id?), although I’m still trying.

Not authorized

The phone support was useless, and I’ve had a few email exchanges on asking if it’s available for purchase, and if so how much. I’ll update if I can figure it out.

What does suck is that while UOS is not authorized you can’t get any OS updates, nor can you enable to root user. So yeah you can’t effectively own the machine with UOS. There is a ‘trial’ mode to enable a 90 day ‘grace’ period so at least I can add GCC and at least build software. Clearly if I can’t sort out UOS I’ll have to dump the kernel / initrd and restore another MIPS64EL Linux distro over the filesystem. Debian has MIPS64EL, and seems to be working to mainline the LX-6901.

UOS bills itself as a Windows replacement, and I have to say that I do enjoy using it. It has some rather ‘Windows’ qualities to it, like the sound mixer, and ease of installing apps from the ‘store’ however if it’s not in the store and it’s Not authorized you are out of luck. As much as I dislike distro of the week nonsense, I do like the idea of thousands of people being hired to flesh it out to make Linux usable, but only time will tell how much of it is translation to Chinese, and how much is developing software.

When it comes to performance the 3A4000 running at 1.8Ghz is faster than a Raspberry Pi 4, however not significantly faster CPU wise. However the big plus the MIPS does have is that it has a far more capable bus with M.2 and PCI-E slots along with SATA giving the board much better IO than any SOC solution like the Pis.

I built the BYTE Benchmark 5.1.3 and did this graph with data from running on a Zero for comparison. I had to adjust scales for some of this so its more visible, however the important data is here that CPU wise they are close together, but in the area of IO the Dragon pulls far ahead. For those who like the Linux boot score, the CPU ‘clocks’ in at 3594.02 BogoMIPS per core.

It’s been a large ‘discovery’ thing, and a long time since I’ve tried to make Linux a ‘daily driver’ and of course the scarcity of MIPS binaries on Linux is going to be an issue, but I’ll have to explore the apparent ARM/x86 compatibility as I can find more information about it.

Since this has been such a learning curve for me as I learn more things I’ll add them to this list:

I don’t know how much (if any) reach my blog has in China, but if anyone knows any more or can help, drop a line!