qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmet


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic
Date: Sun, 08 Jan 2012 14:16:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/08/2012 01:43 PM, Blue Swirl wrote:
> On Sun, Jan 8, 2012 at 02:48, Andreas Färber <address@hidden> wrote:
> > Am 07.01.2012 18:29, schrieb Blue Swirl:
> >> On Thu, Jan 5, 2012 at 17:45, Andreas Färber <address@hidden> wrote:
> >>> Am 15.10.2011 15:50, schrieb Blue Swirl:
> >>>> Remove now incorrect address base arithmetic, missed by
> >>>> 9936d6e42392f1440505dfa9df065eabd251cadf. Fixes Sparc64 boot.
> >>>
> >>> ...but breaks PReP boot:
> >>>
> >>> ERROR: BUG caught...
> >>> BIOS execution exception
> >>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
> >>> Stopping execution
> >>>
> >>> I verified by checking out the preceding commit, applying a variation of
> >>> http://patchwork.ozlabs.org/patch/134519/ on top; that restored PReP
> >>> boot to what it used to look like.
> >>>
> >>> Any insights?
> >>
> >> Sparc64 problem was that the io_base did not match what was passed to
> >> the functions and then the calculation made the offset totally
> >> incorrect. Could you add printfs to see what is the offset?
> >
> > info qtree:
> >
> >  dev: m48t59, id ""
> >    dev-prop: size = 8192
> >    dev-prop: type = 59
> >    dev-prop: io_base = 0x74
> >    irq 1
> >    mmio ffffffffffffffff/0000000000002000
> >
> > #define DEBUG_NVRAM:
> >
> > NVRAM_writeb: 0x00000074 => 0x00000000
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000001
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000002
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000003
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000004
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000005
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000006
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000007
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000008
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x00000009
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x0000000a
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x0000000b
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x0000000c
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x0000000d
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x0000000e
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
> > NVRAM_writeb: 0x00000074 => 0x0000000f
> > NVRAM_writeb: 0x00000075 => 0x00000000
> > NVRAM_readb: 0x00000077 <= 0xffffffff
>
> This is what happens on Sparc64:
> NVRAM_writeb: 0x00000000 => 0x00000000
> NVRAM_writeb: 0x00000001 => 0x00000000
> NVRAM_readb: 0x00000003 <= 0x00000070
> NVRAM_writeb: 0x00000000 => 0x00000001
> NVRAM_writeb: 0x00000001 => 0x00000000
> NVRAM_readb: 0x00000003 <= 0x0000001a
> NVRAM_writeb: 0x00000000 => 0x00000002
> NVRAM_writeb: 0x00000001 => 0x00000000
> NVRAM_readb: 0x00000003 <= 0x00000000
> NVRAM_writeb: 0x00000000 => 0x00000003
> NVRAM_writeb: 0x00000001 => 0x00000000
> NVRAM_readb: 0x00000003 <= 0x00000002
> NVRAM_writeb: 0x00000000 => 0x00000004
> NVRAM_writeb: 0x00000001 => 0x00000000
> NVRAM_readb: 0x00000003 <= 0x00000073
> NVRAM_writeb: 0x00000000 => 0x00000005
> NVRAM_writeb: 0x00000001 => 0x00000000
> NVRAM_readb: 0x00000003 <= 0x00000079
> NVRAM_writeb: 0x00000000 => 0x00000006
> NVRAM_writeb: 0x00000001 => 0x00000000
> NVRAM_readb: 0x00000003 <= 0x00000073
> NVRAM_writeb: 0x00000000 => 0x00000007
> NVRAM_writeb: 0x00000001 => 0x00000000
>
> I/O base offset is kept with PIO but removed from MMIO, which is not
> consistent. Avi, could we fix this?

Yes, I'll work on it.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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