Linux 0.01 on Qemu!

Well sort of.

Linux 0.01!

Linux 0.01!

I looked at the source again, and for some reason 99% of it compiled without issue.  I recall having all kinds of issues, but clearly I was doing something wrong back then.  At any rate, all I really had to do was modify the commenting style in the 8086 boot block code, and modify the image creation tool to open files in O_BINARY mode for Windows, and I got an image that will boot, then panic because it has issues reading the hard disk.  I tried the seemingly small ‘fix’ from Linux 0.11 but it’s not working.

If anyone cares, I updated the sourceforge download, as MinGW-aout-linux–001_010_011.7z

Linux at 25 years!

As we quickly approach this amazing milestone, I think it’s always interesting to re-visit the roots of Linux, back to the really ancient versions.  Thanks to the hard work of oldlinux.org, the oldest intact Linux source code available is Linux 0.10 from November of 1991.  A popular writeup on 0.10 was up on kerneltrap.org which appears to have been vaporized, but thanks to archvie.org is preserved.

Since this version is complete I thought it would be fun to run it through the Linux 0.11 build process & toolchain to see if I could get a working kernel.  Well I had a few stumbling blocks, the bootblocks and the keyboard assembly driver were giving me issues, and for the sake of time, I went ahead and replaced them with the code from 0.11, and along with minor patching to the IDE disk driver.  I added in a simple line to let me know I was actually booting up my franken 0.10 kernel with Qemu.  Also I found later versions of Qemu work much better with 0.10 regarding the IDE disk.

Linux 0.10 on Qemu, cross compiled on Windows

Linux 0.10 on Qemu, cross compiled on Windows

I know it’s not much to look at but it really is building and running.  I’m using the disk for the 0.11 series, as the userland seems to somewhat work.  It’s very touchy, and prone to crashing as it ‘has a bug in the buffer cache’ that I didn’t feel like trying to track down.  Nobody should be using this for anything serious anyways.

Install the 0.11 a.out GCC 1.40 on Win32 cross environment (I guess you can build them on Linux too if you so desire), and if you have a working MSYS environment you can run ‘make’ and it should give you a kernel.  The command file ‘linux.cmd’ will boot it up, and attach the disk image that I used to test.  There are permission errors, and well.. errors.  0.10 was not able to selfhost, but it should be enough to boot, mount the root, and run stuff like the sample ‘hello world’ program.

For those who like to browse the source, I have a browsable tree here.

And for the 2-3 people who care, here is my updated linux-0.10 source tree hosted on sourceforge.

EMX GCC 2.5.8 for Windows

Continuing in my quest of useless stuff, here is GCC 2.5.8 for EMX as a native Win32 executable set.

With some weirdness of inline not being recognized, I just commented that out.  The GCC driver program does have some issues though, and Im just not in the mood to fully figure out why either the EMX or MS-DOS versions can’t correctly  capture return codes, or if it was better to just use -pipe and _pipe with _O_TEXT mode set, but again how to figure out if the pipe closed cleanly or with errors?  So for now it’ll always assume everything worked, but it will still print errors.  Sigh.

With that said, the CC1, CC1OBJ, CC1PLUS drivers all built, so you can use C, ObjectiveC, and C++. yay.

The functional version of this is EMX 0.8H, with the gcc 2.5.8 update.  Maybe I’ll put this all on sourceforge so people don’t have to deal with my crappy download system, but for now it’s on my site.

Here is my build, along with binaries:

emx_gcc_258_phase1_xgcc_cccp_cc1_cc1obj_cc1plus.7z

And the un touched source code, as provided in the 0.8H update

emx_gcc_258_virgin.7z

I’ve only tested it with MS-DOS, and PDOS.  I’m also using the ancient binutils from my GCC 1.40 on Windows experiment.

GCC 1.40 on Windows

I know with all the talk of GCC 6.1.0 for MS-DOS, and other platforms, you must be thinking that all this talk of progress, and high versions numbers just isn’t right!  I’ve just started to migrate code to GCC 5.1, and now you are telling me there is a GCC 6!

Where can I turn away from all this so called progress!  I don’t like my C compilers to be C++ programs that require massive HOURS to compile.  Can’t we just go back to the good old days?

And the answer is YES, you can!

While looking for some libraries on another project, I came across this old defunct project called RSXNT. And it’s a port of EMX to Win32 platforms!  Well isn’t that fantastic!

So, considering I was able to build GCC 1.40 and cross compile to Linux 0.11 from Windows, can we do something with this?

Well ancient versions of EMX are very difficult to track down.  Somehow I did mange to find this hybrid of 0.8B & 0.8C.  The EMX runtime & binaries are from 0.8C, but the source code is from 0.8B.  And the best thing is that the 0.8B is based around GCC 1.40!  So with a little bit of tweaking the files, and messing around I got the assembler, linker, and C compiler to build with MinGW!  Sadly the source code to EMXBIND, wasn’t included in the zips that I have, but the aformentioned RSXNT packages included a version of EMXBIND that will run on Windows!  So I managed to mash them together, and for the fun of it, I’m using the old InfoTaskForce interpreter from 1987 to complete the vintage feel.

Compiling & Binding

Compiling & Binding

Now with my executable, I can run it on MS-DOS & OS/2!

MS-DOS via DOSBox

MS-DOS via DOSBox

and OS/2 2.0!

OS/2 (on Qemu)

OS/2 (on Qemu)

Well isn’t that fantastic!

However when running RSXNT’s bind, NTBIND I got this error:

D:\emx_w32\infocom>..\bin\ntbind info2
No relocations in file:
you have not linked the NT library

Great.  Some more digging around, and if you want to make Windows programs, you need to use the RSXNT includes & libraries.  So I shifted the libraries around, and patched gcc to call the linker the same way RSXNT’s gcc driver calls it, and first go this error:

io.o: Undefined symbol __streams referenced from text segment

And looking at the stdio.h there is this:

extern struct _stdio _streams[];

No doubt, the headers & libraries are tied together.  So now making both of the RSXNT versions, I can link the executable. (YES I did try declaring the structure anyways, and I get stdout, but stdin doesn’t work).

Running on Windows 10

Running on Windows 10

Just like EMX before it, RSXNT, requires you to have the RSXNT.DLL file in your path, or in the same directory.  I suppose it’s a fair trade off.  Not that I expect there to be a surge of people cross compiling from Windows to OS/2, or even MS-DOS these days.  GCC 1.40 is ancient, 1991 vintage, but even Linus Torvalds loved it!

For comparison, GCC 5.10 produces a 55,906 byte interpreter, while GCC 1.40 produces a 88,576 byte interpreter.

For an attempt at porting some code, I choose Nethack 1.3d, and used the MS-DOS based makefiles.  It didn’t work so well, but I was able to patch in enough of the unix based termios logic, and thanks to EMX/RSXNT’s built in termios capabilities I was able to get a working version!

Nethack 1.3d on Windows 10 x64

Nethack 1.3d on Windows 10 x64

I don’t know if there really was any advantage to compiling with GCC 1.40, but it was great to see that this 1991 compiler could handily compile the 1987 based code.

How about some speed comparisons?  I dug out the ancient dhrystone.c, and gave it a shot.  I had to define 500,000,000 passes, as my computer is fast.  GCC 1.40 only offers -O for optimization, while GCC 5.1 offers many more levels, but for this quick experiment they really aren’t needed.

D:\emx\demo\dhry>gcc140.exe
Dhrystone(1.1) time for 500000000 passes = 57
This machine benchmarks at 8771929 dhrystones/second

D:\emx\demo\dhry>gcc140_O.exe
Dhrystone(1.1) time for 500000000 passes = 40
This machine benchmarks at 12500000 dhrystones/second

D:\emx\demo\dhry>gcc510.exe
Dhrystone(1.1) time for 500000000 passes = 43
This machine benchmarks at 11627906 dhrystones/second

D:\emx\demo\dhry>gcc510_O.exe
Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

D:\emx\demo\dhry>gcc510_O2.exe
Dhrystone(1.1) time for 500000000 passes = 14
This machine benchmarks at 35714285 dhrystones/second

D:\emx\demo\dhry>gcc510_Ofast.exe
Dhrystone(1.1) time for 500000000 passes = 11
This machine benchmarks at 45454545 dhrystones/second

As you can see, GCC 1.40 produces the slowest code.  While it’s optimized code did beat out GCC 5.10 with no optimizations, turning on optimizations did blow it away.  And again GCC 5.1 beat out the older 1.40 for executable sizes.

29,960 gcc510_O.exe
29,996 gcc510_O2.exe
30,472 gcc510.exe
70,656 gcc140_O.exe
74,752 gcc140.exe

And this time by over a 2x lead!  It is fair to say that the new versions of GCC, despite being significantly larger do indeed produce smaller and faster code.

For anyone who’s read this far, I guess you want to take it out for a test drive?  Remember it is still EMX based, which means is wants to live on the ROOT of your hard disk.  I’m using the ‘D’ drive for myself, so if you are using C or whatever you’ll need to alter the environment vars.

You can download the exe’s and combined source here: gcc-1.40_EMX-OS2_RSXNT.7z

NeoGeo dev update with Neo Thunder

neo thunder

Compiled and Linked under Windows 10

In a round about way I was looking at old NeoGeo hardware having seen the ‘NeoGeo X’ android device for sale.  In a round about way I stumbled onto this page detailing various homebrew projects.  I saw the Neo Thunder, which looked interesting, and more importantly included source code!

What was even better is that there was a download of the full toolchain + emulators to get it up and running!  I downloaded it, and hit the wall quickly as this was built with cygwin circa 2001, which means it will forkbomb any post Windows XP SP2 system.

Well, I couldn’t just let it die on the vine, so I turned back to my Canadian cross compiler build machine, and quickly built a m68k-elf tool chain.  As always, first build a native cross compiler for later building libgcc.a and friends.  I use a 32bit version of Linux with a downgraded MinGW environment so I can use Binutils 2.25.1 and GCC 4.1.2

For anyone who cares, this is my configure strings:


binutils
../configure --target=m68k-elf --prefix=/usr/local/m68k-elf
../configure --target=m68k-elf --prefix=/m68k-elf --host=i686-mingw32


gcc
../configure --target=m68k-elf --prefix=/usr/local/m68k-elf
../configure --target=m68k-elf --prefix=/m68k-elf --disable-libssp --build=m68k-elf --host=i686-mingw32

With a cross compiler built, the next problem was with the built in tools like bin2elf, fixcnv, gfxcc, and symify.  These were also built with cygwin, and failed to run.  With a LOT of googling however I did find the following link to “Fabrice Martinez’s NeoDev Neo Geo C development library for GCC’. 290 kb Année 7/26/2004 (LINUX)“, out on yaronet.com.

I patched up makefiles to my liking, and I could build all the libs, and all of the sample code (well except for the c++ one, because I couldn’t be bothered to build a c++ compiler).  Some of it runs, some doesn’t I’m not sure what is going on.  But for what it’s worth, Neo Thunder actually builds and runs (on mame!).

As always you can MinGW-M68K-ELF(neogeo).7z on my site.  Be sure to read the 404 page for the username password, as it auto-generates from time to time.  I don’t know if anyone will care, but it was kinda cool to track down the needed bits, and build out a working version of Neo Thunder.

Updated build of Linux 0.11 on Windows 10

Building & Running Linux

Building & Running Linux

I’ve updated my project for compiling Linux 0.11 on Windows 10.  In this version it builds a lot better with TDM MinGW 5.1.0 + MSYS.

The big improvements is that you can compile Linux without the full MinGW/MSYS install by running the ‘blind’ script which will compile the kernel without make and friends.

The build process for the kernel works as well so now with the included Qemu 0.12.5, no need to link under Linux anymore.  I fixed up some of the build processes as I thought I’d re-build and some stuff bombed so it’s all fixed up.

For those interested, I just updated the original download here:

MinGW-aout-linux-011.7z

Building Linux 0.11 on Windows 10

No really, it compiles! on Windows!

No really, it compiles! on Windows!

So continuing with the fun from yesterday, where I had managed to get gcc 1.40 running on Windows with MinGW, it was time to try to take the final leap and build Linux.

There wasn’t too much to massage on Linux, mostly Makefiles for the various tool name differences, and how to handle keyboard.S as the default setup for NTFS is case insensitivity.  While I did get some old version of as16 and ld16 to build, I’m not sure if they are working correctly.  Or it could be the ‘build’ tool.  The downside is that the final ‘Image’ file produced doesn’t work (I should add that all issues have since been fixed, and it is now possible to cross compile a running kernel from Windows, and boot it with Qemu).

But copying the ‘system’ file that is compiled on Windows, to a Linux VM, and having it do the boot setup does work!

And it boots!

And it boots!

Very cool to say the least!

I almost wonder if MSVC 1.0 could build any of this.  Then it could be possible to bootstrap Linux from Windows NT 3.1 … Although Windows 10 is good enough for me, right now.

And I got the DJGPP 1.0 gcc driver to work (soft of)!

C:\aoutgcc\test>gcc -v hello.c -o hello -I ../include-0.12 -L../lib
gcc version 1.40
cpp -v -I ../include-0.12 -undef -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ hello.c C:/Users/neozeed/AppData/Local/Temp/cca0_388.cpp
GNU CPP version 1.40
cc1 C:/Users/neozeed/AppData/Local/Temp/cca0_388.cpp -quiet -dumpbase hello.c -version -o C:/Users/neozeed/AppData/Local/Temp/cca0_388.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387
a386 -o hello.o C:/Users/neozeed/AppData/Local/Temp/cca0_388.s
ld -o hello c:/aoutgcc/lib/crt0.o -L../lib hello.o c:/aoutgcc/lib/gnulib -lc c:/aoutgcc/lib/gnulib

Sorry that doesn’t format so well on a blog.  But now I only have to force the include path, and the lib directory. At this point I’d call it ‘good enough’

I uploaded the archive MinGW-aout-linux-011.7z.  If you want to compile Linux, you’ll need a MSYS from MinGW.  Otherwise, this is only interesting to people who run Windows and want to play with Linux 0.11.  I also included the Linux VM, and binaries for the tools.  It’s not even 7MB.  How is that for crazy small?

 

** EDIT

I got it all working now that I found all the portions to set to output as O_BINARY/wb that are needed on a Win32 host, so using MinGW I can build the as86/ld86/binutils/gcc and Linux 0.11!

My updated post is here.

Also I put all the source onto git, along with binaries up on sourceforge.  It’s worth mentioning that since I wrote this article, I have gotten quite a number of older versions of Linux to build, along with simple kernel debugging with GDB.  Kernels include:

Download Ancient Linux on Windows

Download Ancient Linux on Windows

 

Craziest cross compile yet!

Windows 10 to target Linux 0.11!

It works!

It works!

Sadly that ancient line program only runs ELF binaries, so that won’t work to test.

As I mentioned gcc doesn’t work. I need to tear more into DJGPP
to see how they did it or just use it’s gcc driver to run this.

In the test directory I’ve mimic’d what a Linux 0.11 install does when compiling
a single file into an exe.

simply run:

c_ hello

and it’ll compile hello.c into hello.

C:\aoutgcc>..\bin\cpp -v -I../include-0.12 -undef -D__GNUC__ -Dunix -Di386 -Dlinux -D__unix__ -D__i386__ -D__linux__ hello.c C:\Users\neozeed\AppData\Local\Temp\001.cpp
GNU CPP version 1.40

C:\aoutgcc>..\bin\cc1 C:\Users\neozeed\AppData\Local\Temp\001.cpp -quiet -dumpbase hello.c -version -o C:\Users\neozeed\AppData\Local\Temp\001.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387

C:\aoutgcc>..\bin\a386 -o hello.o C:\Users\neozeed\AppData\Local\Temp\001.s

C:\aoutgcc>..\bin\ld -o hello ../lib/crt0.o hello.o ../lib/libc.a

Wasn’t that fun?

The ‘best’ way I can think of to test is to tar the exe like this:

C:\aoutgcc>..\bin\tar.exe hello.tar hello

And then run it with the Linux 0.11 on Qemu which can be found here:

qemu-12.5.i386.zip

qemu -L pc-bios -hda linux-0.11-devel-060625.qcow2 -no-reboot -m 16 -k en-us -fda hello.tar

Then once Linux boots, do this:

tar -xvf /dev/fd0
chmod +x hello
./hello

Fun?!

For anyone who wants to play at home, here is the complete sources, and binaries.

Building MinGW32 Qemu on Linux (or anything else I guess)

So as always it’s the glibc2 wars.  And as part of the fun you need pkg-config.  And since it has to run, you’ll end up with the native version.

Luckily I found this site, mega-nerd.com

So you can create a i586-mingw32msvc-pkg-config file.  Just in case it get's lost here it is:

#!/bin/bash

# This file has no copyright assigned and is placed in the Public Domain.
# No warranty is given.

# When using the mingw32msvc cross compiler tools, the native Linux
# pkg-config executable works fine as long as the default PKG_CONFIG_LIBDIR
# is overridden.
export PKG_CONFIG_LIBDIR=/usr/i586-mingw32msvc/lib/pkgconfig

# Also want to override the standard user defined PKG_CONFIG_PATH with
# a mingw32msvc specific one.
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH_MINGW32MSVC

# Now just execute pkg-config with the given command line args.
pkg-config $@

Fun as always, right?

And as always Qemu can be configured with:

configure --cross-prefix=i586-mingw32msvc-

When cross compiling.

Continuing with a PowerPC ELF compiler for Windows

Continuing on from yesterdays adventure I built the PowerPC compiler to support the Cisco 1700 (and maybe the 7200 NPE-G2?).

Much to my surprise, this one works too!

Loading ELF file ‘../ciscoload.bin’…
ELF entry point: 0x8000cba0

C1700 ‘default’: starting simulation (CPU0 IA=0xfff00100), JIT enabled.
ROMMON emulation microcode.

Launching IOS image at 0x8000cba0…
CIL
Error: Unable to find any valid flash! Aborting load.

Awesome!

Building this was a lot more fun.  I thought I could sidestep building a Linux to PowerPC ELF cross compiler, but as it turns out, to bootstrap libgcc, you really need a compiler that can do this.  But with the steps basically down, it was trivial to whip up.

Although I did keep on hitting this error with the Win32 tools that “-mstrict-align” is not supported, while trying to build the startup and libgcc sources using the MinGW targeted compiler through wine.  But once I had a native Linux to PowerPC toolchain in place, not only could I build the Windows based compiler, but I can also use the flag -mstrict-align on Windows without it complaining.  So lesson learned, have a cross compiler built to the final target to make life easier when building a Canadian cross.

As always, building the binutils package was a snap, just run:

./configure --host=i686-mingw32 --target=ppc-elf -prefix=/ppc

and I had my assembler/linker/librarian in no time.

Because of the aforementioned -mstrict-align issue, I got more creative with the parameters for GCC.

./configure --target=ppc-elf --prefix=/ppc --disable-nls --disable-werror --disable-libssp --without-headers --disable-threads --build=i486-linux-gnu --host=i686-mingw32

But with the Linux to PowerPC cross compiler in place, I was able to quickly generate a working toolchain.

I copied in CILO, and added in a build batch file to manually build it, and updated the test directory to run it.

So for those who are interested here is my toolchains:

And a mirror on sourceforge of my cross toolchains, PowerPC and MIPS.

As a minor addendum, The 1700 can run stuff that is far more complicated than the MIPS.  I’m not sure why I get so many TLB violations for doing something more complicated but I (poorly) ported aclock to run on the cisco 1700!

Aclock on the cisco 1700 via Dynamips

Aclock on the cisco 1700 via Dynamips

The Dynamips ROMMON emulator doesn’t provide the keyboard input function call so it can’t read from the keyboard.  Also it can’t read the clock so I have it running 250,000 dhrystones between clock ticks.  Although I think that is far too many, maybe 125,000 would be more like it but it runs on the PowerPC.  While on the MIPS I get nothing but this:

*** TLB (Load/Fetch) Exception ***
PC = 0x80008964, Cause = 0x00008008, Status Reg = 0x00408103

Oh well.  Maybe it’s a stack problem I guess I’ll have to break down and do a memory map and write a malloc if I want to go down this road.  Although back in 1999 this would be incredible but today I don’t think anyone would run anything but IOS on their cisco hardware.