Still possible to directly boot without loader?

Ruslan Ermilov ru at FreeBSD.org
Thu Oct 26 14:18:57 UTC 2006


On Thu, Oct 26, 2006 at 10:52:30PM +1000, Bruce Evans wrote:
> On Thu, 26 Oct 2006, Ruslan Ermilov wrote:
> >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 real purpose of this commit was to allow to directly "load kernels
larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE)".  (Old
version masked high 8 bits, leaving only 2^24=16MB for the kernel.)

I have compiled GENERIC and PAE kernels; objdump(1) reports that GENERIC
kernel has virtual "start address 0xc0449cb0", and PAE has virtual "start
address 0xc02458f0".

What happens here is that BTX now uses flat memory model, and by not
masking higher bits at all, BTX attempts to load kernels at above 3G,
which silently fails, and then jumps to the entry point located in
"no memory" unless the machine has enough memory.

If the machine has enough physical memory, e.g. 4G, then it works (I
think that was the case on the machine John tested this change), but
on my test machine I only have 3G of memory, so it fails.

My interim solution to the problem that would still allow booting
larger than 16MB kernels is to mask some of the higher bits.
Currently, I mask 28 bits that gives possible 256MB which is probably
practical.

%%%
Index: boot2.c
===================================================================
RCS file: /home/ncvs/src/sys/boot/i386/boot2/boot2.c,v
retrieving revision 1.72.2.4
diff -u -p -r1.72.2.4 boot2.c
--- boot2.c	15 Feb 2006 15:08:51 -0000	1.72.2.4
+++ boot2.c	26 Oct 2006 13:48:44 -0000
@@ -332,7 +332,7 @@ load(void)
 	return;
     }
     if (fmt == 0) {
-	addr = hdr.ex.a_entry;
+	addr = hdr.ex.a_entry & 0x0fffffff;
 	p = PTOV(addr);
 	fs_off = PAGE_SIZE;
 	if (xfsread(ino, p, hdr.ex.a_text))
@@ -366,7 +366,7 @@ load(void)
 		j++;
 	}
 	for (i = 0; i < 2; i++) {
-	    p = PTOV(ep[i].p_paddr);
+	    p = PTOV(ep[i].p_paddr & 0x0fffffff);
 	    fs_off = ep[i].p_offset;
 	    if (xfsread(ino, p, ep[i].p_filesz))
 		return;
@@ -387,7 +387,7 @@ load(void)
 		p += es[i].sh_size;
 	    }
 	}
-	addr = hdr.eh.e_entry;
+	addr = hdr.eh.e_entry & 0x0fffffff;
     }
     bootinfo.bi_esymtab = VTOP(p);
     bootinfo.bi_kernelname = VTOP(kname);
%%%

A more intelligent approach would be to use the size of available
memory.  I haven't yet looking at implementing this and I don't
know if this kind of information is available in boot2.

> There is an another PR about this.
> 
I've already closed PR 104709 as a duplicate for PR 96430.
Are there any other PRs with the same subject?

> 4) Another rev. broke support for booting with -c and -d to save 4 bytes.
> -c is useful for RELENG_6 and -d is essential for debugging.  If you
> always use loader(8) then you would only notice this if you try to set
> these flags in boot2.
> 
I'll fix that.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061026/7265f77c/attachment.pgp


More information about the freebsd-stable mailing list