64bit loader

[Peter Wemm]

On Tuesday 31 May 2005 01:56 pm, John Baldwin wrote:
> On Tuesday 31 May 2005 11:06 am, Michael Reifenberger wrote:
> > On Tue, 31 May 2005, David O'Brien wrote:
> > > Ha!!  We can only have 1 sector worth of code in boot0.  At this
> > > point we only have a few bytes of free code space.  No where near
> > > enough to do the long mode switch.
> >
> > Sorry. I didnt meant boot0 but btx. I do know that boot0 is too
> > small. But btx is already switching to protected mode so it should
> > be possible to switch to 64bit mode too.
>
> Note that the loader uses the BIOS (via virtual 8086 mode) to do all
> the disk I/O, etc.  Since long mode doesn't support vm86 mode, you'd
> end up with a loader that couldn't do any I/O to load the kernel,
> etc. unless you started including device drivers for all the
> different storage and networking hardware, etc.  A 64-bit loader
> really isn't feasible unless your 64-bit machine includes firmware
> that you can use from 64-bit mode like EFI on ia64 or OFW on sparc. 
> You probably want to stick with a 32-bit loader on amd64 for now.

Yes, there are a lot of good reasons to do it the way it is done, but 
this is the killer reason.  We simply cannot do vm86 or bios calls from 
a 64 bit loader, period.

Other "good" reasons, besides the above:
* We don't need to maintain a seperate loader code base
* We can load test kernels with an existing loader on a FreeBSD/i386 
system (and run from a ramdisk or miniroot)
* We would need to maintain 32 bit code to do bios calls anyway, even if 
we did switch between 32 bit and 64 bit mode on the fly.  If we have a 
complete 32 bit BTX environment, we get massive complexity for little 
benefit.

Disadvantages:
* The build is a bit hokey.  As was pointed out, the ficl test tools 
don't build in isolation.
* We can't load kernels that are larger than 4GB or into memory above 
the 4GB memory mark.  This actually doesn't matter that much because 
the kernel runs in virtual address space.

Now if somebody wanted to move the kernel to the 16MB mark instead of 
the 2/4MB mark, that could have some benefits because we'd lose less of 
the 16MB ISA bounce buffer memory by holding the kernel there.  The 
floppy drive controller is the only thing these days that has issues 
with that on 64 bit systems.  On the other hand, maybe we should 
implement the code that uses the chipset specific DMA registers to 
allow the ISA DMA controllers to address to the entire 4GB address 
space.  That would make life easier for the floppy controller.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5