Date: Wed, 1 Jun 2005 10:09:47 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-amd64@freebsd.org Cc: Michael Reifenberger <mike@Reifenberger.com> Subject: Re: 64bit loader Message-ID: <200506011009.48460.peter@wemm.org> In-Reply-To: <200505311656.50288.jhb@FreeBSD.org> References: <20050531133608.J87922@fw.reifenberger.com> <20050531165558.L88820@fw.reifenberger.com> <200505311656.50288.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506011009.48460.peter>