Still possible to directly boot without loader?

[John Baldwin]

On Thursday 26 October 2006 08:52, Bruce Evans wrote:
> On Thu, 26 Oct 2006, Ruslan Ermilov wrote:
> 
> > On Mon, Sep 11, 2006 at 01:09:15PM -0500, Brooks Davis wrote:
> >> On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote:
> >>> I just tried to load my standard kernel from the boot blocks (instead
> >>> of using loader(8)), but I either get a hang before the kernel prints
> >>> anything, or a BTX halted.  Is this still supposed to work in 6-
> >>> stable, or has it finally disappeared?
> >>
> >> You may be able to get this to work, but it is unsupported.
> 
> I normally use it (with a different 1-stage boot loader) for kernels
> between ~4.10 and -current.  I only boot RELENG_4 kernels for running
> benchmarks and don't bother applying my old fix for missing static
> symbols there.  See another PR for the problem and patch.  In newer
> kernels and userlands, starting some time in 5.0-CURRENT, sysutil
> programs use sysctls for live kernels so they aren't affected by missing
> static symbols.
> 
> > I've been investigating this today.  Here's what I've found:
> >
> > 1)  You need hints statically compiled into your kernel.
> >    (This has been a long time requirement.)
> 
> Even though I normally use it, I once got very confused by this.
> Everything except GENERIC booted right (with boot loaders missing
> the bug in (3)).  This is because GENERIC has had hints commented
> out since rev.1.272, and GENERIC also has no acpi (it's not very
> GENERIC).  When there are no hints, except on very old systems, most
> things except isa devices work, but at least without acpi, console
> drivers on i386's are on isa so it is hard to see if things work.
> Hints are probably also needed for ata.  I think a diskless machine
> with no consoles and pci NICs would just work.
> 
> > 2)  You can only do it on i386, because boot2 only knows
> >    about ELF32, so attempts to load ELF64 amd64 kernels
> >    will fail.  (loader(8) knows about both ELF32/64.)
> 
> I haven't got around to fixing this.
> 
> > 3)  It's currently broken even on i386; backing out
> >    rev. 1.71 of boot2.c by jhb@ fixes this for me.
> >
> > : revision 1.71
> > : date: 2004/09/18 02:07:00;  author: jhb;  state: Exp;  lines: +3 -3
> > : A long, long time ago in a CVS branch far away (specifically, HEAD prior
> > : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat
> > : mode and clients were limited to a virtual address space of 16 megabytes.
> > : Because of this limitation, boot2 silently masked all physical addresses
> > : in any binaries it loaded so that they were always loaded into the first
> > : 16 Meg.  Since BTX no longer has this limitation (and hasn't for a long
> > : time), remove the masking from boot2.  This allows boot2 to load kernels
> > : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE).
> > :
> > : Submitted by:   Sergey Lyubka devnull at uptsoft dot com
> > : MFC after:      1 month
> 
> The kernel is linked at 0xc0000000 but loade din low memory, so the high
> bits must be masked off like they used to be for the kernel to boot at all.
> This has nothing to do with paging AFAIK.  Rev.1.71 makes no sense, since
> BTX isn't large, and large kernels are more unbootable than before with
> 1.71.

The submitter was able to boot larger kernels with this but wasn't before,
but this does break things and it's still on my todo list to fix.  It can
just be backed out for now.  What it really should do for the load address is
addr - KERNBASE + KERNLOAD.  But KERNBASE and KERNLOAD aren't fixed values.
I should look at how loader does it.

-- 
John Baldwin