The computer is a 600au Miata that has a PCI bus, SCSI disk and CDROM, a floppy, and an on-board Tulip ethernet.
Aug 1, 2003:
I have a 'hello world' bootblock working. Now comes the fun
part of getting all the rest of it put together.
Bootblock Source Code It is in VMS-MACRO64. I will probably switch to GNU gas as I will be able to port that to my OS under Alpha, whereas I would not be able to port the VMS assembler, compiler, linker, etc.
Aug 8, 2003:
I _have_ switched to GNU assembler. Here is the new Bootblock Source Code,
so far. I am trying to get the console 'fixup' routine to move the stuff to the high end of the virtual
mapping, so I can use the low end for usermode programs. It's the more traditional OS approach instead of
what I did in the x86 version. The reason is that the amount of space taken by the pagetables varies with
hardware (theoretically), but I don't want user programs to have to be relinked. So with the kernel stuff
at the top of virtual memory, the low end is always the same.
The SRM console starts the bootfile with paging enabled. It puts its stuff (BIOS equiv) mapped at 0x10000000 and loads the bootfile mapped at 0x20000000. It maps the pagetable at 0x40000000, but I get rid of it as it is redundant. There is a full pagetable mapping at 0x200000000 (the first 8GB boundary). I move it to 0xFFFFFFFC00000000, and relocate the other (BIOS and bootfile) stuff to 0xFFFFFFFE00000000.
Right now I'm struggling with getting the relocation stuff to work. The remapping of the pages is ok, but the console routines barf out (kernel stack not valid) when I try to print on the console again.
Sept 1, 2003:
I have it booting with the loader loaded at 0xFFFFFFFA00000000. The pagetables are at 0xFFFFFFF800000000.
Virtual addresses 0xFFFFFFFC00000000..0xFFFFFFFFFFFFFFFF are reserved for the sparse I/O mapping. On my Miata,
the Pyxis chipset uses 12GB of the 16GB I am reserving. If some other Alpha requires more VA space, there is
a single parameter to change, then relink at the new address. Hey, I'll be happy to get it to work on this
one machine.
I have the keyboard working via interrupts. The stupid thing uses a different keyboard mapping than the PC and it seems the callback (BIOS) routine that does the scancode-to-ascii conversion doesn't work. Now I am going to try to get PCI interrupts working with my ethernet driver. It comes with a built-in tulip 21143 chip, but I may use a tried-and-true 21041 or 21140 card that I know works.
Sept 16, 2003:
I have a 21041 board working through the 21152 bridge. My idiot driver doesn't work with
the 21143 chip, so it was easier to use a 21041 board rather than fix it. Someday...
Sept 21, 2003:
IDE driver works now. Converted x86-only driver to generic, just like I did with the ethernet
driver. Biggest problem was figuring out that the console routines (bios) leaves interrupts
disabled in the 8259's by default.
The things I need to change in an x86-only driver to make it generic are the bus scan routines, IRQ connection and converting physical addresses to PCI addresses. I did a similar thing for ISA bus devices, but haven't figured out what to do with ISA DMA. I may never for all that matters, unless I really want to use the floppy.
Found a place where I had a fixed-length struct in the cache routines that had to be replaced with sizeof (void *)'s. Fortunately, the runtime init code checked to make sure there enough room before going ahead with it.
Sept 29, 2003:
It works to the point up to loading the shell (oz_cli). It gets to user mode and map the image
sections. It's barfing somewhere when it dynamically links the image to the kernel symbol table.
The biggest porting 'issue' has been where I didn't allow sufficiently for multi-level pagetables. I had assumed in some spots that the system pagetable pages were always faulted in which is not the case for the Alpha, as it would take a lot of memory. Also, when I mapped a section, I wrote the 'requested' or 'desired' protection in software reserved bits of the pte's. This caused problems when I mapped a process' pagetable section, as it wanted to fault in all the level 2 pages (8MB) so it could mark them kernel read/write. So I had to add a 'default protection' field to the mapping struct that would supply the protection bits for the contents of a pagetable page when the pagetable page gets faulted in for the first time. On the x86, all this did was write the bits to the page directory, which is always faulted in.
Sept 30, 2003:
It loads and starts the shell now. So it's basically working!
The Alpha SWPCTX (like x86 load CR3) doesn't invalidate the TLB's; there must be an explicit
MTPR TBIAP. D'oh!
... and... make sure you do an IMB and an MB,
too! Gaaahaaaaaahaaaaaaaad! (Oct 4, 2003)
Oct 3, 2003:
A lot of the utilities "just work," but they show up stuff. Like the shell showed me that ast's
weren't being enabled and the "dir" command showed me that the dates weren't being converted right.
I don't know anything about the Alpha's FPU, so I have to study it so I can save/restore it on thread switches. There's an 'FPU enable' bit, so I can do it like the Intel stuff, save it when a thread switches out, then restore it if and when a new thread tries to access it.
Oct 19, 2003:
Loader stays at 20000000. I/O routines use upper virt address range to map I/O space. Then loader
dynamically loads kernel just below the I/O stuff, and pagetables go just below the loader. So in
my case, the Pyxis driver maps I/O space to 0xFFFFFFFC00000000 thru 0xFFFFFFFFFFFFFFFF, the kernel
ends up at 0xFFFFFFFA00000000 thru 0xFFFFFFFBFFFFFFFF, and the pagetables use 0xFFFFFFF800000000
thru 0xFFFFFFF9FFFFFFFF.
Also made a driver that uses SRM routines for keyboard as well as screen so I can use serial line (plugged into my PC) for console. Downside is I don't have CONTROL-SHIFT-keys anymore, but I emulate them with CONTROL-] follwed by the key.
Nov 18, 2003:
The new downloads contain the Alpha code. Right now, they compile on a
Linux (RedHat 7.2) system that has cross-compiler (gcc 2.95.3) and cross-linker. I suppose they would
compile on a native Alpha Linux system, but I haven't tried. Anyway, the compilation script is
ozmake_axp in the sources directory. I have been testing it by using a bootp server
I wrote that runs on the Linux computer, which then sets up the tftp daemon to boot the oz_loader_axp.eb
file. Then the loader uses the ip_fs_linux server to read in the kernel and act as a system disk.