qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc
Date: Sun, 25 Jan 2009 01:28:36 +0100





On 25.01.2009, at 00:59, Aurelien Jarno <address@hidden> wrote:

On Sat, Jan 24, 2009 at 10:57:19PM +0100, Alexander Graf wrote:

On 24.01.2009, at 22:48, Aurelien Jarno wrote:

On Sat, Jan 24, 2009 at 09:58:35PM +0100, Alexander Graf wrote:
OpenBIOS searches for the preloaded kernel at 0x1000000, so let's
put it there instead of an invalid location.

Your patch is actually wrong, the second argument of load_elf() is an offset to the physical address (as found in the elf header), and not a
load address.

By chance the physical address of a >= 2.6.25 kernel is 0x00000000, so
your patch works. But it will break supports for < 2.6.25 kernel as
their physical address is 0xc0000000. Not that they are only the
default
values, they can be changed in the .config file.

Aah, that explains why :-).

I have already proposed a patch to use the virtual address of the elf header as done by yaboot or quik, but I have been told it is actually
wrong.

We have to find another way to load the elf file at a fixed address.

Hm - can't we just give load_elf an override value for the base address?

           /* address_offset is hack for kernel images that are
              linked at the wrong physical address.  */
           addr = ph->p_paddr + address_offset;

           cpu_physical_memory_write_rom(addr, data, mem_size);

Just pass another variable here that overrides addr and doesn't
calculate it?

Except that they can be more than one segment to load, so the last one
will overwrite the previous ones. The PowerPC kernels I have seen only
have one load segment, but I am not sure it is always the case.

But then the addr hack wouldn't work either, right? It's just a question if addr_offset is relative or absolute here. And fwiw in this case relative to the elf header's value doesn't make any sense at all when the firmware expects the blob on a specific address.

Alex



--
Aurelien Jarno                            GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]