From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86 Boot enhancements, boot protocol 2.04 7/9
Date: 04 Apr 2002 12:04:16 -0700 [thread overview]
Message-ID: <m1hemrqo9b.fsf@frodo.biederman.org> (raw)
In-Reply-To: <m1ofh0spik.fsf@frodo.biederman.org> <a8flgc$ms2$1@cesium.transmeta.com> <m1lmc3qtaz.fsf@frodo.biederman.org> <3CAC9BD4.5050500@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
> No, that's not how that works in reality. In practice, the boot loader picks
> the lowest address it can practically use, in order to minimize the conventional
> memory ceiling.
A very sane thing to do. Which makes the requirements/assumptions
in misc.c broken.
> For example, PXELINUX always loads at 0x50000, simply because
> odds that you have a PXE stack and can use 0x90000 is about zero to
> none.
O.k. Than PXELINUX does what I would expect, instead of what seems to
be requested by the boot.txt
> In
> fact, these days there are enough BIOSes that load stuff in the high part of
> memory that using 0x90000 is actively dangerous and **needs to be avoided**.
> Theoretically, you're right; it adds a very small amount of memory to the
> decompression. If that matters, there is actually a very easy way to deal with
> it: for any boot loader there is a Lowest Usable Address (conventional memory
> ceiling). You can use INT 12h and adjust the load address all the way up to
> 0x90000 if the conventional memory ceiling permits; this usually is something
> like five lines of assembly.
Unless the fact is only recorded in the e820 memory map...
> > I'd like to change the way we do this, so I'm going to stare at this
> > problem a little bit more. Changing the default load address and
> > still being able to compute how much memory the kernel is going
> > to use is a challenge.
>
> There can't be a "default load address". 0x90000 is actively dangerous and
> trying to encourage it for anything than legacy kernels is WRONG. If you can't
> handle this, then you need to go back to the drawing board.
I agree. But I do think being able to hard code the load address is a
very good thing.
After digesting the requirements I plan on having setup.S call int 12h
(so the information is available), and then having misc.c relocate the
real mode code, and the command line, out of the way, of it's
decompression buffer. This removes the need for bootloaders to
make a tradeoff between memory use efficiency and reliability.
This should give me about 630KB on machines designed to run DOS, where
this matters. Better than the current best of 572KB, with the real
mode code @ 0x90000.
And when your total size is 1-4MB. +-640KB is a significant change.
Eric
next prev parent reply other threads:[~2002-04-04 19:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-03 16:41 [PATCH] x86 Boot enhancements, boot protocol 2.04 7/9 Eric W. Biederman
2002-04-03 19:15 ` Tom Rini
2002-04-04 3:23 ` Eric W. Biederman
2002-04-04 14:10 ` Tom Rini
2002-04-04 15:38 ` Eric W. Biederman
2002-04-03 19:34 ` H. Peter Anvin
2002-04-04 17:15 ` Eric W. Biederman
2002-04-04 18:30 ` H. Peter Anvin
2002-04-04 19:04 ` Eric W. Biederman [this message]
2002-04-04 19:19 ` H. Peter Anvin
2002-04-04 19:32 ` Eric W. Biederman
2002-04-05 21:30 ` Eric W. Biederman
2002-04-05 22:04 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1hemrqo9b.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox