qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Mips target '-kernel' option bug


From: Blue Swirl
Subject: Re: [Qemu-devel] Mips target '-kernel' option bug
Date: Wed, 17 Oct 2007 22:06:33 +0300

On 10/17/07, Jocelyn Mayer <address@hidden> wrote:
> On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote:
> > J. Mayer wrote:
> > > I failed to run Mips target test image on my amd64 machine and I now
> > > found the reason of the bug:
> > > the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c
> > > implicitelly assumes that the ram_addr_t is 32 bits long.
> > > Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel
> > > load address then is over 4 GB. Then, when computing the initrd_offset,
> > > the code always concludes that there's not enough RAM available to load
> > > it at the top of the kernel.
> > > I found 2 ways of fixing the bug, but I don't know which one is correct
> > > in Mips execution environment.
> > > The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus
> > > translating the kernel virtual address from 0x8000nnnn to the physical
> > > one 0x0000nnnn (instead of 0x10000nnnn, when running on 64 bits hosts).
> > > The second solution would be to explicitelly always cast the kernel_high
> > > value to 32 bits.
> > > As I do not really know if some Mips target specific constraints would
> > > make one of the other solution prefered, I'd better let the specialist
> > > choose !
> > >
> > > The good news is that, once this issue is fixed, the Mips test images
> > > run with the reverse-endian softmmu patch applied.
> >
> > I think this patch is the correct fix. Please test and comment.
>
> Thanks, I'll test it at home tonight.
> To satisfy my curiosity, is there a specific reason to have a positive
> VIRT_TO_PHYS_ADDEND ?

On Sparc, OpenBIOS image is loaded to a physical address that is
higher in the address space than the virtual address:
#define PROM_PADDR           0xff0000000ULL
#define PROM_VADDR           0xffd00000
and
#define PROM_ADDR            0x1fff0000000ULL
#define PROM_VADDR           0x000ffd00000ULL




reply via email to

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