Re: i386/loader compiled with NOFORTH

On Fri, Apr 25, 2003 at 04:17:05PM -0400, John Baldwin wrote:
> 
> On 25-Apr-2003 Ruslan Ermilov wrote:
> > On Fri, Apr 25, 2003 at 03:22:58PM -0400, John Baldwin wrote:
> >> 
> >> On 25-Apr-2003 Ruslan Ermilov wrote:
> >> > On Fri, Apr 25, 2003 at 12:07:35PM -0400, John Baldwin wrote:
> >> >> 
> >> >> On 25-Apr-2003 Ruslan Ermilov wrote:
> >> >> > On Thu, Apr 24, 2003 at 05:45:15PM -0400, John Baldwin wrote:
> >> >> >> 
> >> >> >> On 24-Apr-2003 Ruslan Ermilov wrote:
> >> >> >> > On Thu, Apr 24, 2003 at 02:21:17PM -0400, John Baldwin wrote:
> >> >> >> >> 
> >> >> >> >> On 24-Apr-2003 Ruslan Ermilov wrote:
> >> >> >> >> > On 5.x, loader(8) compiled with -DNOFORTH, results in
> >> >> >> >> > a system without a console.  This does not affect the
> >> >> >> >> > RELENG_4.
> >> >> >> >> > 
> >> >> >> >> > Can someone who knows this code please look into it?
> >> >> >> >> 
> >> >> >> >> No kernel console or no loader console?  The usual problem with
> >> >> >> >> no kernel console on 5.x is lack of device.hints.
> >> >> >> >> 
> >> >> >> > No kernel console.  The device.hints, it's there under /boot;
> >> >> >> > I only reinstalled loader(8) with -DNOFORTH, and this gave me
> >> >> >> > "no console" behavior.  Can you try it locally?
> >> >> >> 
> >> >> >> Since device.hints is read in by Forth code, I wouldn't be
> >> >> >> surprised if it didn't work.  When you break into the 10
> >> >> >> second countdown, do you have any hints set in the loader
> >> >> >> environment?
> >> >> >> 
> >> >> > Yes, figured this out by myself already.  I've ended up
> >> >> > uncommenting the "hints" line in GENERIC config, everything
> >> >> > is OK now, and bzip2(1) also works, modulo the memory
> >> >> > restrictions -- only level 1 bzipping works that requires
> >> >> > ~250K of memory.
> >> >> > 
> >> >> > John, is there a way to fix btx/loader/whatever so that
> >> >> > heap memory is not limited to 640K?
> >> >> 
> >> >> Not really.  At least, not easily.  We load the kernel up above 1mb,
> >> >> but we don't know how much memory lives up above 1mb and we assume
> >> >> that there is enough for the kernel and that's it.
> >> >> 
> >> > I was referring to this message from loader(8):
> >> > 
> >> > BIOS 639kB/129856kB available memory
> >> > 
> >> > So I thought that the memory allocation in i386/loader is
> >> > limited to real mode's 640KB, no?
> >> > 
> >> > Also, IIRC, the installation requirement was 8MB or so,
> >> > and the runtime requirement was 4MB (these are 4.x numbers
> >> > from my memory), so we can safely assume that we have at
> >> > least 4MB of memory?  Now that I look at it, I see that
> >> > GENERIC kernel in 5.0 is 4.82MB, and so we can probably
> >> > always assume that we have 8MB of memory.
> >> 
> >> We assume that we have enough memory to stick the kernel
> >> up there, but that's the only assumption we make. :)
> >> 
> > You still does not answer my question: is the memory
> > allocation in loader(8) limited to real mode 640KB?
> 
> Yes.  Basically, the loader is loaded at address 0xa000 and
> it's stack grows down from 0x9ffff (0xa0000 is where video
> memory is mapped), so that gives you
> 0xa0000 - 0xa000 = 0x96000 = 614400 = 600k for all of the
> loader text, data, bss, stack, and heap.
> 
> I don't think the loader catches it if the stack and heap
> grow into each other.  You just start corrupting things. :)
> 
But if we manage to load kernel high, above 1M, there
should be something that allows us to relocate heap
there, no?  Also, can't we just trust what BIOS thinks
about the amount of memory?


Cheers,
-- 
Ruslan Ermilov		Sysadmin and DBA,
ru_at_sunbay.com		Sunbay Software AG,
ru_at_FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age