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

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

[ravikumar.chakaravarthy]

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

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

[ravikumar.chakaravarthy]

Is there a way I can get away with this error? What changes would I have to make??



-Ravi

-----Original Message-----
From: H. Peter Anvin [mailto:hpa@zytor.com] 
Sent: Thursday, March 20, 2003 5:07 PM
To: Chakaravarthy, Ravikumar
Cc: linux-kernel@vger.kernel.org
Subject: Re: Loading and executing kernel from a non-standard address usin g SY SLINUX

ravikumar.chakaravarthy@amd.com wrote:
> I tweaked the SYSLINUX boot loader and kernel to load and execute the kernel from 0x200000 (physical address). However when I try to load the kernel using the SYSLINUX bootloader to an address 0xdf000000(physical address) it doesn't work!!
> I want to know if the following should work.
> 
> 1. Should the syslinux be able to copy to the address DI=(0xdf000000). I think bcopy  function in (SYSLINUX sources) does this.. Though the bcopy is done in the 32-bit mode, SOMETIMES it fails for this physical address). bcopy is called in runkernel.inc.

Yes.

> 2. Will I have any problem in the setup.S code in arch/i386/boot or head.S in arch/i386/boot/compressed because of this copy to 0xdf000000?? At times when it gets past step 1, it fails in malloc in arch/i386/boot/compressed/misc.c. The error it gives in "Memory Error"

Almost certainly.

	-hpa

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

[H. Peter Anvin]

ravikumar.chakaravarthy@amd.com wrote:
> I tweaked the SYSLINUX boot loader and kernel to load and execute the kernel from 0x200000 (physical address). However when I try to load the kernel using the SYSLINUX bootloader to an address 0xdf000000(physical address) it doesn't work!!
> I want to know if the following should work.
> 
> 1. Should the syslinux be able to copy to the address DI=(0xdf000000). I think bcopy  function in (SYSLINUX sources) does this.. Though the bcopy is done in the 32-bit mode, SOMETIMES it fails for this physical address). bcopy is called in runkernel.inc.

Yes.

> 2. Will I have any problem in the setup.S code in arch/i386/boot or head.S in arch/i386/boot/compressed because of this copy to 0xdf000000?? At times when it gets past step 1, it fails in malloc in arch/i386/boot/compressed/misc.c. The error it gives in "Memory Error"

Almost certainly.

	-hpa

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

[ravikumar.chakaravarthy]

I tweaked the SYSLINUX boot loader and kernel to load and execute the kernel from 0x200000 (physical address). However when I try to load the kernel using the SYSLINUX bootloader to an address 0xdf000000(physical address) it doesn't work!!
I want to know if the following should work.

1. Should the syslinux be able to copy to the address DI=(0xdf000000). I think bcopy  function in (SYSLINUX sources) does this.. Though the bcopy is done in the 32-bit mode, SOMETIMES it fails for this physical address). bcopy is called in runkernel.inc.
2. Will I have any problem in the setup.S code in arch/i386/boot or head.S in arch/i386/boot/compressed because of this copy to 0xdf000000?? At times when it gets past step 1, it fails in malloc in arch/i386/boot/compressed/misc.c. The error it gives in "Memory Error"


Following is a list of changes I made to the SYSLINUX and kernel code to get it working for 0x200000. 
---------------------------------------------------------------------
#Number preceded by ":" in the following lines represent the line number. I #am using 2.4.20 source
(Syslinux)
1. runkernel.inc: 
250: sub eax,0x200000
263: mov edi,0x200000

(linux kernel)
1. arch/i386/boot/setup.S
126: .long   0x200000      # 0x200000 = default for big kernel
813: code32: .long   0x2000                      # will be set to 0x200000

2. arch/i386/boot/compressed/head.S
102: movl $0x200000,%edi
127: ljmp $(__KERNEL_CS), $0xdf000000

3. arch/i386/boot/compressed/Makefile
19: BZIMAGE_OFFSET = 0x200000

4. arch/i386/vmlinux.lds
9: . = 0x01000000 + 0x200000;

5. arch/i386/kernel/setup.c
345: static struct resource code_resource = { "Kernel code", 0x200000, 0 };

6. arch/i386/kernel/head.S
ENTRY(swapper_pg_dir)
        .long 0x202007
        .long 0x203007
        .fill BOOT_USER_PGD_PTRS-2,4,0
        /* default: 766 entries */
        .long 0x202007
        .long 0x203007
        /* default: 254 entries */
        .fill BOOT_KERNEL_PGD_PTRS-2,4,0




Thanks in advance
  -Ravi

-----Original Message-----
From: H. Peter Anvin [mailto:hpa@zytor.com] 
Sent: Tuesday, March 04, 2003 5:00 PM
To: linux-kernel@vger.kernel.org
Subject: Re: Loading and executing kernel from a non-standard address using SY SLINUX

Followup to:  <99F2150714F93F448942F9A9F112634CA54B07@txexmtae.amd.com>
By author:    ravikumar.chakaravarthy@amd.com
In newsgroup: linux.dev.kernel
>
> I am trying to load and boot the kernel from a non-standard address
> (0x200000). I am using the SYSLINUX boot loader, which loads the
> kernel at that address. I have also made changes to the kernel to
> setup code and startup_32() function to effect the same. When I boot
> the system It says
> 

Modified, perhaps.  Stock SYSLINUX loads at the standard address
(0x100000).

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[ravikumar.chakaravarthy]

Yes,
  You are right. I had to change the linker file vmlinux.lds, to change the link address to 0xc0200000 and not change PAGE_OFFSET. However as you said there seems to be other problems. My virtual to physical map seems to work fine. However when the kernel is executed, in the start_kernel in init/main.c, the prink statement doesn't seem to print the characters on the screen. Is there any reason why it should not print characters, due to the fact that I loaded the kernel at 0x200000?? Will there be any other changes to the kernel source I have to make to avoid further problems??

  -Ravi

-----Original Message-----
From: Phillip Lougher [mailto:phillip@lougher.demon.co.uk] 
Sent: Thursday, March 06, 2003 6:13 PM
To: linux-kernel@vger.kernel.org
Subject: E: Loading and executing kernel from a non-standard address usin g SY SLINUX

On Wed, 5 Mar 2003 ravikumar.chakaravarthy@amd.com wrote:
> 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.
> 

You cannot get the kernel to run from a different physical address by changing
PAGE_OFFSET.  This is not what PAGE_OFFSET is for.  PAGE_OFFSET specifies the
offset of virtual memory from the start of physical memory, which is assumed to
be 0x0.

You should never want to change PAGE_OFFSET.

> Thats why I tried to change
> the PAGE_OFFSET value to 0xc0100000, which should be the right value
> corresponding to (0x200000).

Wrong.

If you really do want the kernel to run at 0x200000 physical, you should
try changing the link address to 0xc0200000.  I'm no expert on the
i386 kernel (I know the PPC kernel), but there's no guarantee that this
will work, if there's any code which assumes the kernel is at 0x100000
physical.

Phillip

> -Ravi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Kai Germaschewski]

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

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

[ravikumar.chakaravarthy]

I want to uncompress it to a different address (actually to a MM5451 card), so that I can test the low memory. Yes my boot loader loads the compressed kernel to 0x200000, and I have modified the kernel to uncompress it and execute it from 0x200000. However I am having problems trying to execute it!!

-Ravi


-----Original Message-----
From: Martin J. Bligh [mailto:mbligh@aracnet.com] 
Sent: Tuesday, March 04, 2003 12:13 PM
To: Chakaravarthy, Ravikumar; linux-kernel@vger.kernel.org
Subject: RE: Loading and executing kernel from a non-standard address usin g SY SLINUX

> 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. 

Why would you need to uncompress it to a different address? You mention
that your bootloader does something odd, but that should only affect the
address of the compressed bzImage, not the decompressed kernel ...

M.

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

[Martin J. Bligh]

> 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. 

Why would you need to uncompress it to a different address? You mention
that your bootloader does something odd, but that should only affect the
address of the compressed bzImage, not the decompressed kernel ...

M.

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

[ravikumar.chakaravarthy]

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.

-Ravi


-----Original Message-----
From: Martin J. Bligh [mailto:mbligh@aracnet.com] 
Sent: Tuesday, March 04, 2003 11:35 AM
To: Chakaravarthy, Ravikumar; linux-kernel@vger.kernel.org
Subject: Re: Loading and executing kernel from a non-standard address using SY SLINUX

> I am trying to load and boot the kernel from a non-standard address
> (0x200000). I am using the SYSLINUX boot loader, which loads the
> kernel at that address. I have also made changes to the kernel to
> setup code and startup_32() function to effect the same. When I boot
> the system It says
> 
> Loading.......... Ready
> Uncompressing Linux... OK Booting the kernel
> 
> and then hangs.
> 
> I guess the reason being the System.map entries are still using the
> PAGE_OFFSET = 0xc0000000, as opposed to 0xc0100000.
> I have the following questions??
> 
> 1. How do i change the System.map to get the right PAGE_OFFSET.
> 2. Will it work if I load and boot the kernel from a different address
> like (0xdf000000)??
> 
> 3. Am I in the right track or missing something.

The kernel should decompress itself to the right space anyway ... check
arch/i386/boot/compressed/head.S ... should be minimal changes needed,
if any.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/