[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Help with i386 OBSD booting/kernel-init setup please

Hello.  Due to the request of some customers, I am working to build a
version of SmartFirmware (IEEE-1275 boot firmware, also known as
OpenFirmware and formerly OpenBoot) for certain x86 hardware to
*completely* replace the standard PC BIOS.  They'd like to first boot
OpenBSD, then Linux, then perhaps FreeBSD, and entirely avoid the usual
PC BIOS oddities.  (They're a bit ticked off at PC BIOSes in general and
BIOS vendors in particular.  :)

I have a devlopment version of SF that net-boots and runs sufficiently
to load an OpenBSD i386 kernel using bootp/tftp and then try to launch
it.  Right now I'm simply trying to get it to get past device probing
and either panic due to no boot disk, or try to boot off of the net.

(SF doesn't need any boot-loaders, at least for development.  It has
some common filesystem drivers that let it load and run images directly.
I know some folks hate this sort of thing, but it does make things
easier for development.)

Naturally, since this is PC hardware, things are not anywhere near being
simple.  The OBSD kernel boots, displays its first copyright messages on
the console, then immediately faults or hard-resets the machine.

I'd like to email/talk with someone who knows enough about how i386 OBSD
boots and inits things, and what it expects from the BIOS (stacks,
segments, reserved addr ranges, PCI addr ranges, etc - all that
undocumented stuff).  I'd like to make SF do similar enough things that
I don't have to create a custom x86/OBSD port just for SF.  I've been
faking up dummy arguments for it, just to get it to get a bit further,
but still no luck as of yet.

I've been taking a whack at it by looking at the OBSD code, but nothing
that I've tried has worked.  At best I get the copyright before it
hard-resets, and more typically, it just hard-resets.  I've already
figured out not to trust the addrs in the OBSD a.out headers, or at
least mask all the addrs therein with 0x00FFFFFF.

SF itself runs in 32-bit mode, which should make booting Unices easier.
It can load and run binaries built to test its client-interface.  I've
tried to load and run Linux and FBSD binaries, but they appear to be
even more complicated OBSD/x86.  I've bagged them both for now.

(Parenthetically, I've gotten SmartFirmware running on a wide variety of
hardware, and this has been absolutely the most miserable and hardest
port of any of them by a wide wide margin.  Is there *any* part of
x86/PC hardware design that was done anything close to resembling
sanity?  It's enough to drive me to drink.  Which, actually, it has.)

Thanks in advance for any assistance, tips, Or condolences.

	-- Parag Patel