Re: [9fans] non-BIOS boot

Re: [9fans] non-BIOS boot

[David Gordon Hogan]

> Actually we've done complete chipset turn-on (dram control etc.) plus read
> in a kernel in 512 bytes. On the twisted, horrible, 8086 real-mode yet.

That's nice.  Now, to _really_ impress me, it has to run on any
machine where the INT13 solution would do, which includes
machines with various kinds of SCSI adaptors providing access
to the boot disk :-)

Re: [9fans] non-BIOS boot

[David Gordon Hogan]

> If you dont use the BIOS wouldn't you have to access
> the disk via i/o ports? If so, you would have to adhere to
> the SCSI/ATA standard rather than a more conformed interface
> via int13? If you did have to adhere to the different standards
> wouldnt that mean implementing the drivers in the MBR/PBS?
> I think _I'm_ the one missing something :) Can you fill me

Good luck fitting that code into the 512 bytes you have to play
with in the MBR.

The BIOS int13 call gives you enough to get the OS into memory,
then you can run a _real_ driver, tailored to the OS, and not to
the pre-Cambrian qualities of the BIOS.

Re: [9fans] non-BIOS boot

[Don]

> Good luck fitting that code into the 512 bytes you have to play
> with in the MBR.
>
> The BIOS int13 call gives you enough to get the OS into memory,
> then you can run a _real_ driver, tailored to the OS, and not to
> the pre-Cambrian qualities of the BIOS.
Werd, thats my point.
Don

Re: [9fans] non-BIOS boot

[Charles Perkins]

Regarding the limitations of the PC boot process...

"David Gordon Hogan" <dhog@plan9.bell-labs.com> wrote in message
news:8af692a6aa5a1270aab459dd5945364d@plan9.bell-labs.com...
> > If you dont use the BIOS wouldn't you have to access
> > the disk via i/o ports? If so, you would have to adhere to
> > the SCSI/ATA standard rather than a more conformed interface
> > via int13? If you did have to adhere to the different standards
> > wouldnt that mean implementing the drivers in the MBR/PBS?
> > I think _I'm_ the one missing something :) Can you fill me
>
> Good luck fitting that code into the 512 bytes you have to play
> with in the MBR.
>
> The BIOS int13 call gives you enough to get the OS into memory,
> then you can run a _real_ driver, tailored to the OS, and not to
> the pre-Cambrian qualities of the BIOS.
>

You'd be suprised what a sufficently motivated person can do with 512 bytes.
I know for a fact that you can go all the way to protected mode and
(limited) paging using just the master boot record of an IDE hard drive,
because I've done it. Now that boot sector doesn't do anything other than
remap interrupts, enable A20, set up page tables, switch to protected mode
and set up a polling LBA page-in routine for the rest of memory... but hey,
after you've got that you can just let the rest of your kernel page itself
in in a lesiurely manner with no second stage boot loader or file system
grokker required.

I wrote the boot pager in an attempt to make an OS that has no file
system--just persistent virtual memory. All the boot loaders out there
pretty much expect to have a file system of one sort or another to load a
kernel image from, and using one of those  would have made moot the whole
point of the exercise. I've since changed my mind about the evils of
structure in secondary storage but the boot pager remains and it's (imo) a
pretty neat way to get your kernel running.

Anybody who cares to look at it can click on oiuboot.asm at www.memetech.com
and/or download a bochs/VMWare booting disk image of it (oiuboot.zip.)

Now I am not claiming that stuffing all this into 512 bytes is a good idea,
mind you. Merely that it is possible.

Chuck Perkins

Re: [9fans] non-BIOS boot

[Ronald G Minnich]

Actually we've done complete chipset turn-on (dram control etc.) plus read
in a kernel in 512 bytes. On the twisted, horrible, 8086 real-mode yet.

ron

Re: [9fans] non-BIOS boot

[Don]

> Now I am not claiming that stuffing all this into 512 bytes is a good idea,
> mind you. Merely that it is possible.
>
I don't really think thats something any of us are disputing. It is
rather possible to fit _lots_ of great code into 512 bytes, as we
all know. The question here is how different the SCSI/ATA/etc
negotiation would be per device and how those differences would
create problems within a scope too great for a MBR/PBS.
:)
Don

Re: [9fans] non-BIOS boot

[Ronald G Minnich]

> > Now I am not claiming that stuffing all this into 512 bytes is a good idea,
> > mind you. Merely that it is possible.
> >

no argument with this. It's just that the 512-byte limit doesn't apply
here (any more).

ron

Re: [9fans] non-BIOS boot

[Douglas A. Gwyn]

Charles Perkins wrote:
> You'd be suprised what a sufficently motivated person can do with 512 bytes.
> [impressive hack deleted]

I am reminded of the (perhaps partly apocryphal) story of the IBM 1403
card reader's LOAD button which would get just one 80-column card image
into the 1410's core memory then start executing it.  Unfortunately it
took 79 characters to simply get the next card read..  The boot loader
thus consisted of an initial section that accumulated one character of
the second stage per card, followed by a branch to the second-stage
image where a more useful boot loader now resided.

Re: [9fans] non-BIOS boot

[rsc]

> Anyone out there have any pointers towards documentation
> on accessing devices via physical memory? Like, apparently
> video memory to write text is mapped at 0xb8000.. do other
> devices become mapped like this? Is this documented
> information? If so, where? I've read through most of the
> intel CPU documentation, but, I havent seen anything related
> to this topic. I'd prefer not to use the BIOS in my MBR

google for ralf brown's interrupt list.
there's a file called memory.lst that you
might find useful.

[9fans] non-BIOS boot

[Don]

Anyone out there have any pointers towards documentation
on accessing devices via physical memory? Like, apparently
video memory to write text is mapped at 0xb8000.. do other
devices become mapped like this? Is this documented
information? If so, where? I've read through most of the
intel CPU documentation, but, I havent seen anything related
to this topic. I'd prefer not to use the BIOS in my MBR
code..
Don

Re: [9fans] non-BIOS boot

[Ronald G Minnich]

Those crazy video addresses only work if you've gone through the pain and
agony of running the vga bios, OR you know how to do the equivalent in
your code.

We've dealt with this for 2 years now, it is a mess.

ron

Re: [9fans] non-BIOS boot

[Don]

Thanks for the tips, guys.
There really _is_ no good way to do disk
processing without using int13&|LBA is
there?
Don

Re: [9fans] non-BIOS boot

[Ronald G Minnich]

On Wed, 29 May 2002, Don wrote:

> There really _is_ no good way to do disk processing without using
> int13&|LBA is there?

not sure what you mean here. We do is all the time without int13.

What did I miss?

ron

Re: [9fans] non-BIOS boot

[Don]

> not sure what you mean here. We do is all the time without int13.
>
> What did I miss?
>
> ron
If you dont use the BIOS wouldn't you have to access
the disk via i/o ports? If so, you would have to adhere to
the SCSI/ATA standard rather than a more conformed interface
via int13? If you did have to adhere to the different standards
wouldnt that mean implementing the drivers in the MBR/PBS?
I think _I'm_ the one missing something :) Can you fill me
in?
Don

Re: [9fans] non-BIOS boot

[Ronald G Minnich]

On Thu, 30 May 2002, Don wrote:

> If you dont use the BIOS wouldn't you have to access
> the disk via i/o ports? If so, you would have to adhere to
> the SCSI/ATA standard rather than a more conformed interface
> via int13?

Great question. I used to think this too.

Turns out PC hardware is designed for two things: full-capability OSes and
really STUPID STUPID BIOSes. So, for example, IDE hardware runs with all
kinds of fancy DMA, and also runs in trivial polled-IO modes so that
software written ca. 1982 will work correctly. It's really amazing to see
the contortions PC hardware goes through to conform to an Intel reference
design from 1978 or so (not kidding, I have some of those old books
somewhere).

It turns out that the INT13 is no more conforming than the silly hardware.

What we do in LinuxBIOS for IDE support is run dead-stupid simple
polled-IO drivers to load the kernel. These were contributed by someone
from another project.

 > If you did have to adhere to the different standards
> wouldnt that mean implementing the drivers in the MBR/PBS?

Yes, you are right here, but this has turned out to be not a big deal (so
far).

ron