Re: Help with i386 OBSD booting/kernel-init setup please

[Tobias Weingartner <weingart@natasha.tepid.org>]

On Wednesday, January 19, Parag Patel wrote:
> 
> 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.  :)

PC BIOSes are not much to speak of.  They've gotten somewhat better in the
past 5 years, but we still find tons of incompatibilities, and downright
bugs in even the newest versions of them.  If there are any BIOS coders out
there, *PLEASE* follow some accepted "standards", and do some bug testing
before you release them to the masses!  About 1.5 years ago I talked about
the possibility of having a OF type of thing booting using a minimal section
of the BIOS, and then using that to load/manage the boot of 32-bit OS's in
general.  At the time I "explained" this idea to someone (you know who you
are!), they basically told me that I was nuts.  I'm somewhat glad that I am
not the only one...


> 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.

This is quite far.  If you take a look at the current /boot sources for
the x86 arch, you should be able to find all you need to know about loading
and invoking a kernel.  For the most part, it's pretty straight forward.

There are basically 4 things you need to do, to have obsd boot successfully;
1) Load kernel at physical 1MB in RAM.
2) Setup registers + Stack as in /boot.
3) Pass all needed BIOSargs that current /boot passes to the kernel.
4) Pray.  Jump to kernel init.  :-)

I'm guessing that you are missing out on the #3 department.  In particular,
chances are that you are not passing the kernel anything about the amount of
RAM that is has available, etc.


> (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.)

The boot loaders should be rather "simple" to write.  I figure something like
our current /boot sources, suitably munged would likely give a very good start
to the whole thing.


> 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'm guessing that there is a "problem" with the kernel not knowing how much
memory (not having a memory map passed to it) it has to deal with.


> 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.

Try looking at /sys/arch/i386/stand/libsa/exec_i386.c, for an idea of what
needs to be passed to the kernel.  Also, there is other things in that dir,
which should help out.


> 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.

Very true.  Basically, the kernel goes at physical address 1MB.  Right after
the 640K-1MB "hole".  There could be some incentive to rewrite the init code
in the x86 kernel to be able to work off an arbitrary point (lets say 4K
boundary).  In that way the kernel could be loaded towards the top end of
physical RAM, saving precious RAM below the 16MB boundary (for ISA DMA stuff).
Of course, that could be quite a chore...


> 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.

Basically, the kernel expects to be invoked in 32-bit mode, VM disabled.  Other
than that, the above 4 points should help somewhat.


> (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.)

Wow.  I'd love to have a looksee.  Sanity in the PC market? Nah, never heard
of that stuff.  Just wait until you get into memory detection, disk drive
detection, geometry translation, and and Mickey would let you know, APM stuff.
Hell, even following accepted "standards" will still make certain PCs decide
they don't like what you just did, and lock up on you for no apparent reason,
such that you end up coding exceptions, etc.

To help with the bad parts, think and drink Guiness...  :-)


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

Any help I can provide, you're welcome to.

--Toby.
Tobias Weingartner |        Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. |        http://www.tepid.org/~weingart/
Edmonton, AB       |-------------------------------------------------
Canada, T6G 1G3    | %SYSTEM-F-ANARCHISM, The OS has been overthrown