From owner-freebsd-bugs@freebsd.org Fri Mar 3 20:21:19 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89D30CF7FAA for ; Fri, 3 Mar 2017 20:21:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0241B1C for ; Fri, 3 Mar 2017 20:21:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 6D727D49CF0; Sat, 4 Mar 2017 07:21:09 +1100 (AEDT) Date: Sat, 4 Mar 2017 07:21:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: mark@uncommon.com cc: freebsd-bugs@freebsd.org Subject: Re: [Bug 217512] boot2 is unable to load kernel directly In-Reply-To: Message-ID: <20170304055139.K1070@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=5ghZlvmeAAAA:8 a=j_IYjQQLqD4G-pUSGaMA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=RpekAKD2uzO6yzk7mOvr:22 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:21:19 -0000 On Fri, 3 Mar 2017 "a bug that doesn't want replies"@freebsd.org wrote: > --- Comment #2 from Mark Willson --- > As I understand the theory of boot0/boot1/boot2/loader operations, boot2 > should have all the registers, bios calls, and setup correct for direct > execution of the kernel. Assuming, of course, that the kernel has everything > that it needs compiled into the kernel [with the exception of kernel modules] > and does not need any of the modifications or the boot time services, e.g. > device.hints, loader.conf, etc., that the loader would supply. > > Assuming there is no support for AMD64s in boot2 then-- boot2 has the correct amount of special support (none), but the amd64 kernel always depended on the special support provided by loader. > 1) there is no support for any 64 bit based CPUs (intel or amd), effectively > limiting its use for booting directly into the kernel to ancient 32-bit i386 > machines And modern 32-bit i386 machines. FreeBSD in i386 mode on modern 64-bit CPUs runs many small applications about 10% faster than FreeBSD in amd64 mode on the same CPU. > 2) boot.config, for the same purposes, will not work It works to configure boot2, but for booting amd64 kernels that only gets you as far as pre-selecting a few things including the loader. I normally use my version of biosboot for boot2. This also supports loading kernel.config into memory for use by the kernel. kernel.config is used by FreeBSD-4 and earlier i386 kernels to hold configuration info. loader does this wrong in a different way by providing unstructured configuration info in environment variables. The structured info in kernel.config at least allows error detection for typos. This feature is broken (not supported) in boot2. > 3) boot2 cannot be used to bypass loader problems on 64 bit machines It can be used to boot a better 32-bit kernel. This is not a bad method to use generally. Instead of booting through loader, boot through a 32- bit kernel to configure for a 64-bit kernel if you must use a 64-bit kernel for some reason. In the 32-bit kernel, you can use normal tools with usable UIs, and never see loader or its unusable UI (loader still doesn't even have history for its line editor). The loader step is still unfortunately necessary to get from the 32-bit kernel to the 64-bit one, and 32-bit kernel takes a bit longer to boot than loader. > 4) boot2 can only be used to look at or changing certain temporary variables, > select a different loader (very unlikely), or to fiddle with video/serial > console options It takes editing the source code to change console options. I often use boot2 to select a loader at all when booting an i386 kernel, to change my default of not using loader. Usually there is one in /boot on the default drive/partition. I often override the default for the drive/partition, but rarely to select a different loader. > 5) the documentation is in error in a number of places (e.g. handbook, man, > internals) and needs to note this major limitation so that others don't go down > rabbit hole as well. > > I did do some additional checking and it appears that you are correct at least > as far back as FreeBSD 8.x. A similar error/outcome came up on a different > server/bios/config. Back to FreeBSD-5 for the first version of amd64. > I also noted that boot2 does say 'FreeBSD/i386 BOOT' at its prompt (although, > since i386/amd64 are the core lines for freebsd I've always thought of i386 as > a subset of AMD64--anything i386 could do amd64 could do better--guess I was > >wrong). Could do better, but usually does worse. > Is it possible that AMD64s *could* work if the appropriate device.hints were > statically linked in the kernel itself as well as any other "external" required > setup done by the loader at boot time is compiled in or is there something > fundamental about the architecture/BIOS support that makes this unlikely? Nothing fundamental, but it needs to set up page tables as on i386 and do something to replace configuration via vm86. amd64 already has an x86 emulator which is used instead of vm86 for at least syscons video BIOS calls. It seems to work perfectly. i386 also uses non-vm86 BIOS calls which are more fragile. Perhaps these could use the emulator and work on amd64 too, and the early vm86 calls on i386 could be changed to use the emulator, then used on amd64 too. Support for booting with boot2 often gets broken on i386. I fixed it in -current last year, and it still works in FreeBSD-[7-9] (probably also in [5-6], but it is still broken in [9-10] by making early vm86 calls before vm86 is initialized. vm86 BIOS calls, non-vm86 BIOS calls and the emulator take large complicated code but are still better than than using loader to make the calls. amd64 needed the emulator because BIOS calls are needed for acpi suspend/resume, and using the loader at suspend/resume time is just impossible. So amd64 no longer has the excuse that vm86 doesn't work for requiring loader. Suspend/resume doesn't actually work on most of my systems because the video BIOS calls which are the main ones done are also the ones that don't work with modern Intel graphics. Specifically, the one to restore a saved SVGA state doesn't work to turn video back on for resume. Bruce