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

[Blue Swirl]

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?

Alternatively there could be different handlers for MMIO and PIO, or
in this case masking the address with 0x3 could be used but I'd rather
unify the I/O handlers.