qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address
Date: Sat, 10 Jan 2009 19:35:48 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Fri, Jan 09, 2009 at 03:38:58PM -0800, Paul Brook wrote:
> > For PowerPC, the kernel needs to be started with address translation
> > enabled (that's even true for the firmware), and thus the kernel loaded
> > at the virtual address.
> 
> This sounds wrong.
> 
> Surely we should be loading it at the paddr with translation disabled, hat's 
> the whole point of having both paddr and vaddr in the ELF headers. If the ppc 
> kernel isn't setting p_paddr to the load address then what is it setting it 
> to?

It was set to the same value as the virtual address (0xc0000000), and it
is now set to 0x00000000.

> >              /* address_offset is hack for kernel images that are
> >                 linked at the wrong physical address.  */
> > -            addr = ph->p_paddr + address_offset;
> > +            addr = ph->p_vaddr + address_offset;
> 
> > As all the other kernels/bios I have looked have the same virtual and
> > physical address, I don't think it will break other targets.
> 
> This will definitely break things. In particular bare metal applications 
> built 
> for the Luminary Micro boards (and probably any other system that uses XIP 
> from flash).  I also have several non-linux OS and bootloaders that rely on 
> the current elf loader behavior.
> It's standard practice to use the paddr when loading an image. This si 
> consistent with gdb and several boot loaders.
> 

If we want to mimic bootloaders, both quik and yaboot are using
p_vaddr.

-- 
  .''`.  Aurelien Jarno             | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   address@hidden         | address@hidden
   `-    people.debian.org/~aurel32 | www.aurel32.net




reply via email to

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