[LispM-Hackers] Outageness

[John Morrison]

Hi;

Nyef wrote:
> Stick the band in a partition on the hard drive. Add swap space. Demand
> page the band in as needed. Make things so you don't absolutely have to
> have etherboot in order to run it (etherboot doesn't seem to like PCMCIA
> ethernet cards, and guess what my OS dev machine uses?).

Here's the thing.  I kind of wanted to have the drivers (including the
IDE or other disk one) be written in Lisp, and also the filesystem
implementation.  So, there's a kind of bootstrapping issue.

I was kind of hoping that whatever boot mechanism we used could blit
(enough of) the load band into memory, and then take it from there.

Etherboot's NBI format contains a sequence of records in which you
basically tell the bootloader: "put the following number of bytes at
this location in memory."  The header of the whole NBI image tells it
where to jump to after it has loaded everything (and it also will stick
the DHCP results in memory for you to find).  I am pretty sure it will
blit the entire band into memory when I ask it to, and the reason/goal
is this:

It would eliminate the need for drivers for any sort of device at all
being included in our ersatz microcode.  They could all be in lisp. 
Paging, everything.  (My goal is to minimize the amount of nativecode to
as few lines as is possible.

Is there some other bootloader with equivalent functionality that would
not choke on PCMCIA devices?  Can GRUB netboot, too?  I don't know a
whole helluva lot about it.

> > The way I was contemplating doing this at the beginning on bare iron was
> > to (do this the same way I did the work on the Java OS and) use
> > Etherboot to put the "microcode" down below the 1MB real-mode address
> > limit (and below the 640KB frame buffers) so I don't have to do any
> > funky relocation or kernel-payload encapsulation (like the Linux kernel
> > does), and then have etherboot put the load band in higher memory, (very
> > importantly) aligned on an x86 page boundary (which I hope I recall
> > correctly is also 4KB just like in the LispM -- if not, or not some
> > multiple, This Will Never Work).
> 
> The x86 page size is indeed 4k. I'd actually prefer to keep the low spaces
> available for DMA buffers, given a choice, but that can be fixed later.

Actually, I remembered the x86 page size, but I forgot the e2/e3 page
size!

> > I've also got to think deeply about address space issues and speed.
> > I've got to build the "microcode" in such a way as that its entry point
> > and pre-protected-mode preamble works correctly in real-mode, and that
> > its protected mode addresses all work correctly later.  I would really
> > like to use the MMU and pass e3 word addresses directly to it without
> > having to execute any x86 instructions to figure out the x86 virtual
> > address of the e3 virtual word address.
> 
> There are a couple problems with this idea. First is that you will need to
> mask off at least some of tags at the top of an E3 data word. Second is

Sorry to have failed to mention that.

> that E3 addresses are word indexed, and the MMU isn't responsible for
> scaling them (you do have scaled addressing modes, though, so all is not
> lost).

Is this the Code Segment Descriptor Default Bit (or whatever it's
called)?  LDT

> You _could_ just mmap() some memory to those addresses. Or use the user
> LDT hacks to create a selector that you can use to reference the E3 memory
> space that way...

In other words, if I understand correctly (even money at best), be one
of the few programs to actually USE segmented memory?  Geez, I'm going
to have to have a good long think about that one.  Aside from real-mode,
I've avoided the whole segment thing.  Gives me a headache.  Even so,
I'll take a look.

> And at addresses 0 and 5 are the symbols NIL and T. I somehow doubt that
> those will be infrequent reads.

Geez, I thought that NIL and T were somewhere else -- I don't remember
them at those addresses.  Must be getting old.

Thanks for the tips!

-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