RE: Loading and executing kernel from a non-standard address usin g SY SLINUX

[ravikumar.chakaravarthy@amd.com]

Yup,
  Thanks I got that. The physical address is computed using (virtual address) - PAGE_OFFSET. So if my decompressed kernel is loaded at the physical address 0x200000 (I defined this address), I would need the linker to know it. Actually I went past that stage and now I got into start_kernel.. however it seems to be hanging somewhere after that. 
Is there any other kernel changes I need to make to avoid this hanging for a normal boot.

-Ravi

-----Original Message-----
From: Kai Germaschewski [mailto:kai@tp1.ruhr-uni-bochum.de] 
Sent: Wednesday, March 05, 2003 3:40 PM
To: Chakaravarthy, Ravikumar
Cc: mbligh@aracnet.com; linux-kernel@vger.kernel.org
Subject: RE: Loading and executing kernel from a non-standard address usin g SY SLINUX

On Tue, 4 Mar 2003 ravikumar.chakaravarthy@amd.com wrote:

> Yes the kernel is uncompressed to the right location (0x200000), in my
> case. When I try to uncompress it to a non standard address (other than
> 0x100000), the address mapping is affected. Thats why I tried to change
> the PAGE_OFFSET value to 0xc0100000, which should be the right value
> corresponding to (0x200000).

> So the problem now is that, when a function is invoked it is unable to
> fetch the right physical address, since my address mapping (System.map)
> does not change when I change the value of PAGE_OFFSET and recompile the
> kernel.

Well, this sounds very much like your vmlinux is relocated to the wrong 
adresses, and then it's not surprising it doesn't work. You definitely 
want to change arch/i386/vmlinux.lds.S. I'm not sure if you actually want 
to change PAGE_OFFSET, but I don't see a fundamental reason why it should 
be needed, so I think you should try as-is.

--Kai