[LispM-Hackers] It's great to see help + status update & questions on bare iron

[John Morrison]

Hi;

First, while it is personally embarrassing to have people publicly
finding bugs in your code (the "whoops" factor), it is bloody *great*
to have the help.  That is a deal I'd take any day of the week.

Second, here is the buzz with trying to get stuff running on bare
iron, and I have a couple questions to ask:

(0) I can now Etherboot my "spare" 128MB, 200MHz x86 box.

(1) Question: who here has an x86 (or cross-development capable) gcc
box, and has a spare x86 box and is interested in helping out?

(2) Please be advised that I have not yet successfully built a new
NetBootable Image (NBI) format file (I was using old JavaOS ones to
test).  The issue used to be how the uninitialized data area was
created.  When working on the old JAVAOS clone, until I used "objcopy"
to create an absolutely flat binary file, including zeroed-out
uninitialized data, I couldn't get anything to work.  Now, however, it
looks like mknbi understands vanilla ELF files.  I am resurrecting
(and radically simplifying by ripping out the Java support) the old
bare-iron support (going to protected mode, interrupt handling, printf
to console, etc) of the old JavaOS clone stuff.  I expect to shortly
(within a week) have figured out whether I can use a vanilla ELF file
instead of a flat binary, which should help immensely.  If that fails,
I have a small C program that makes QNX binaries into NBI format.
This might be easier to hack than the stock mknbi (which is now no
longer a C program us is a PERL - ugh - program!).

(3) I still intend to make an NBI file that consists of both the
microcode (native code) and the load band.  Please be advised that,
for the nonce, if your machine has less memory than the sum of the
microcode (should be small) and the load band (not so small), then you
are completely, totally, and utterly screwed (with respect to trying
out the bare iron stuff).  I guess you can either stick with the
host-build or hack away at a compression scheme.

(4) The code that I am cannibalizing used to handle machine
dependencies via inheritance.  All the "base" functionality everybody
needed (e.g., the macroinstruction machinery) was in C++ virtual base
classes.  This constituted the vast bulk of the code.  The x86 version
and the self-hosted version each subclassed the base stuff and thus
lived in their own directories like so:

jos
  common
  arch
    host
    x86 (included ASM support, etc.)

The x86 stuff was relatively small, but it made up for its dimutive
size by being particularly nasty to debug (I have no ICE system, and I
have not tried to run this under Bochs or Plex86).

Question: unless anybody shrieks bloody murder, and steps up to the
plate, I would just as soon use the inheritance scheme.  It seemed to
work pretty well in practise.

(5) Although I only used Etherboot, several other people added support
for GRUB (which I find, much to my chagrin, is the new RedHat default
bootloader!).  I.e., those with only one box, but still desirous of
booting upon bare iron, would reboot to Linux, build a new JavaOS
kernel, and then boot it using GRUB.  Repeat, ad infinitum, ad
nauseum.  I personally have no interest in that right now (it takes
too long to do each cycle, whereas Etherboot is fast as Hell), so
please be advised that while I am not going to rip it out, I am NOT
going to test building for GRUB (which requires a different binary
"Multiboot compliant" format for the final product of the build
cycle).

Please let me know who's interested in helping, and any other feedback
on the tentative plans...

Again, thanks for the help!

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@mak.com