Date: Fri, 25 Apr 2003 16:17:05 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: i386/loader compiled with NOFORTH Message-ID: <XFMail.20030425161705.jhb@FreeBSD.org> In-Reply-To: <20030425195918.GB28920@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. :) -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030425161705.jhb>