Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!newsserver.jvnc.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: ptdi 4f324a6a
Message-ID: <1993Apr27.123419.15536@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD, Sankt Augustin, Germany
References: <C6299E.1Gw@veda.is> <C653DM.9q@veda.is>
Date: Tue, 27 Apr 1993 12:34:19 GMT
Lines: 49
In article <C653DM.9q@veda.is>, adam@veda.is (Adam David) writes:
|>
[...]
|> Why should the kernel run into problems when it is almost 640k in size?
|> It still fits in 640k after all (text, data, bss). Is there a stack that
|> gets clobbered just below the 640k boundary? Please someone tell me how
Not the stack, but simply the secondary bootstrap loader that is
located at 0x90000. While loading a large kernel, the loader itself
gets overwritten, before the load is finished.
|> to get a kernel to work that is loaded at 0x00100000.
I tried this this weekend (without success). It is not that easy.
Julian's boot loader puts the kernel at the correct address, i.e.
linking a kernel to 0xFE100000 puts it at 0x100000 (i.e. address masked with
0x00FFFFFF). The locore.s part in the beginning must be modified that
correct locations are put into the MMU. This involves the variables
SYSTEM AND SYSPDROFF (which is SYSTEM>>22 which gas doesn't do right).
The tricky part is that the kernel must still believe that itself is
at 0xFE000000 (which should translate into the physical address 100000).
There are several macros and locations in the code that rely on
0xFE000000 (just grep -i 0xfe00 in the kernel source tree) and have this
explicitly there. Stupid changing all of them does not work. Paging should
exactly work this way that the physical location of data is anywhere, but
is seen at a fixed location, so I believe that 0xFE000000 is correct in
these places. The solution should need the following parts:
1. Build the kernel paging tables correctly (I am unsure whether I did it
right).
2. Exclude the kernel space from the pool of pageable memory (This
was simple with the kernel at 0x00000000, pageable==over_00100000).
3. Include the free space below 0xA0000 (and probably between the adapters)
to the pageable pool.
The latter two jobs, I suspect, have to be done in the VM system, which
is said to be thrown away in the next version. Bill also said, he had
fixed the loading above 1M, so I don't know whether it makes much sense
to start a joint effort to hack the necessary fixes in.
Holger
|> Adam D. (adam@veda.is)
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions