Date: Wed, 18 Dec 1996 14:37:46 -0500 From: Tony Overfield <tony@dell.com> To: Bruce Evans <bde@zeta.org.au>, julian@whistle.com Cc: hackers@freebsd.org Subject: Re: Boot loader hacks was: Re: MAXMEM Message-ID: <3.0.1.32.19961218143733.0068f0ac@bugs.us.dell.com>
next in thread | raw e-mail | index | archive | help
Tony Overfield wrote:
>>I think that boot2 can only be 7 KB. Even so, there seems to be plenty
>>of space to do this.
With all the options enabled, I'll now say that "plenty" was a
wee bit optimistic.
At 04:33 AM 12/17/96 +1100, Bruce Evans wrote:
>It can be of almost any size, but is currently limited to 7.5K (or
>4.5K on 9-sector floppies :-).
>[snip]
>There is also a 7.5K limit because the boot blocks are too stupid to
>load themselves if they cross a track boundary.
Are you talking about the size limit of boot1 + boot2 combined,
or is this check wrong? This check seems to limit boot2 to 7 KB.
@dd if=boot2 skip=14 of=sizetest 2> /dev/null
@if [ -s sizetest ] ; then \
echo "boot2 is too big" >&2 ; \
rm boot2 ; \
exit 2 ; \
fi
>Don't forget to compile it with all the options :-). I think it's
>already over 7.5K if they are all enabled.
It looks like it fits in 7 (7.5) KB with all the options enabled.
>> Does anyone know why the comment,
>>"Prefer the RTC value for extended memory." appears near this code?
>>
>>Well I didn't, so I added these lines right afterwards:
>>
>> if (bootinfo.bi_extmem > biosextmem)
>> biosextmem = bootinfo.bi_extmem;
>
>Because of the rule "never change a ``working'' system". It's just as
>well that it wasn't changed - memsize() doesn't clear the top 16 bits
>properly, even for the base memory size.
Believe it or not, I did notice that, but it's ok since real_to_prot()
clobbers the upper half for us (unless the level-one cache is turned
off using cr0 :-o). Well, it's not really ok, but it does work.
At 10:55 AM 12/16/96 -0800, Julian Elischer wrote:
>now try compile it with a mix of other options....
>(specifically NAMEBLOCK and PROBE_KEYBOARD etc.)
>and see if it STILL fits....
It still fits (barely). Here's a sample of the make output showing the
options I enabled.
cc -O2 -malign-functions=0 -malign-jumps=0 -malign-loops=0 -DDO_BAD144
-DBOOTWAIT=5000 -DTIMEOUT= -DBOOTSEG=0x1000 -DBOOTSTACK=0xFFF0
-I/usr/src/sys/i386/newboot/biosboot/../../.. -W -Wreturn-type -Wcomment
-Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wpointer-arith -DPROBE_KEYBOARD
-DPROBE_KEYBOARD_LOCK -DFORCE_COMCONSOLE -DCOMCONSOLE=0x3F8
-DCONSPEED=9600 -DNAMEBLOCK -DNAMEBLOCK_WRITEBACK -DBOOT_HD_BIAS=1
-c boot.c
Will all the options listed above (including my hacks), the boot2 file
is 7152 bytes. That means there are still over 15 bytes left for
additional features, error checking and bug fixes. ;-)
I'll withdraw my suggestion, since the space is so tight. I'll be
plenty happy using it by myself, however.
After I decided that a three stage boot process would be an
easy to implement band-aid for the space problem, I decided to
check the archives to see why nobody has done it yet. Though it
was difficult to follow the threads, I got the impression that
the three stage boot proposals seemed more complicated than they
needed to be. Was there some kind of trouble keeping the feature
list small when imagining so much more code space for the boot
loader. Don't bother responding to this point if it's an already
beaten (and dead) horse.
Tony
-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.19961218143733.0068f0ac>