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