* [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic
@ 2011-10-15 13:50 Blue Swirl
2012-01-05 17:45 ` Andreas Färber
0 siblings, 1 reply; 6+ messages in thread
From: Blue Swirl @ 2011-10-15 13:50 UTC (permalink / raw)
To: qemu-devel, Avi Kivity
Remove now incorrect address base arithmetic, missed by
9936d6e42392f1440505dfa9df065eabd251cadf. Fixes Sparc64 boot.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
---
hw/m48t59.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hw/m48t59.c b/hw/m48t59.c
index f318e67..dba5796 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -480,7 +480,6 @@ static void NVRAM_writeb (void *opaque, uint32_t
addr, uint32_t val)
{
M48t59State *NVRAM = opaque;
- addr -= NVRAM->io_base;
NVRAM_PRINTF("%s: 0x%08x => 0x%08x\n", __func__, addr, val);
switch (addr) {
case 0:
@@ -505,7 +504,6 @@ static uint32_t NVRAM_readb (void *opaque, uint32_t addr)
M48t59State *NVRAM = opaque;
uint32_t retval;
- addr -= NVRAM->io_base;
switch (addr) {
case 3:
retval = m48t59_read(NVRAM, NVRAM->addr);
--
1.6.2.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic
2011-10-15 13:50 [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic Blue Swirl
@ 2012-01-05 17:45 ` Andreas Färber
2012-01-07 17:29 ` Blue Swirl
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Färber @ 2012-01-05 17:45 UTC (permalink / raw)
To: Blue Swirl; +Cc: Alexander Graf, qemu-devel, Avi Kivity
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?
If I revert this commit on HEAD instead, then the above error
disappears, too, but there's another regression with the kernel not
being able to read the hda or something.
The write access fix seems unrelated.
Andreas
> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
> ---
> hw/m48t59.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/hw/m48t59.c b/hw/m48t59.c
> index f318e67..dba5796 100644
> --- a/hw/m48t59.c
> +++ b/hw/m48t59.c
> @@ -480,7 +480,6 @@ static void NVRAM_writeb (void *opaque, uint32_t
> addr, uint32_t val)
> {
> M48t59State *NVRAM = opaque;
>
> - addr -= NVRAM->io_base;
> NVRAM_PRINTF("%s: 0x%08x => 0x%08x\n", __func__, addr, val);
> switch (addr) {
> case 0:
> @@ -505,7 +504,6 @@ static uint32_t NVRAM_readb (void *opaque, uint32_t addr)
> M48t59State *NVRAM = opaque;
> uint32_t retval;
>
> - addr -= NVRAM->io_base;
> switch (addr) {
> case 3:
> retval = m48t59_read(NVRAM, NVRAM->addr);
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic
2012-01-05 17:45 ` Andreas Färber
@ 2012-01-07 17:29 ` Blue Swirl
2012-01-08 2:48 ` Andreas Färber
0 siblings, 1 reply; 6+ messages in thread
From: Blue Swirl @ 2012-01-07 17:29 UTC (permalink / raw)
To: Andreas Färber; +Cc: Alexander Graf, qemu-devel, Avi Kivity
On Thu, Jan 5, 2012 at 17:45, Andreas Färber <afaerber@suse.de> 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?
> If I revert this commit on HEAD instead, then the above error
> disappears, too, but there's another regression with the kernel not
> being able to read the hda or something.
>
> The write access fix seems unrelated.
>
> Andreas
>
>> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
>> ---
>> hw/m48t59.c | 2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/m48t59.c b/hw/m48t59.c
>> index f318e67..dba5796 100644
>> --- a/hw/m48t59.c
>> +++ b/hw/m48t59.c
>> @@ -480,7 +480,6 @@ static void NVRAM_writeb (void *opaque, uint32_t
>> addr, uint32_t val)
>> {
>> M48t59State *NVRAM = opaque;
>>
>> - addr -= NVRAM->io_base;
>> NVRAM_PRINTF("%s: 0x%08x => 0x%08x\n", __func__, addr, val);
>> switch (addr) {
>> case 0:
>> @@ -505,7 +504,6 @@ static uint32_t NVRAM_readb (void *opaque, uint32_t addr)
>> M48t59State *NVRAM = opaque;
>> uint32_t retval;
>>
>> - addr -= NVRAM->io_base;
>> switch (addr) {
>> case 3:
>> retval = m48t59_read(NVRAM, NVRAM->addr);
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic
2012-01-07 17:29 ` Blue Swirl
@ 2012-01-08 2:48 ` Andreas Färber
2012-01-08 11:43 ` Blue Swirl
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Färber @ 2012-01-08 2:48 UTC (permalink / raw)
To: Blue Swirl; +Cc: Alexander Graf, qemu-devel, Avi Kivity
Am 07.01.2012 18:29, schrieb Blue Swirl:
> On Thu, Jan 5, 2012 at 17:45, Andreas Färber <afaerber@suse.de> 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
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic
2012-01-08 2:48 ` Andreas Färber
@ 2012-01-08 11:43 ` Blue Swirl
2012-01-08 12:16 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Blue Swirl @ 2012-01-08 11:43 UTC (permalink / raw)
To: Andreas Färber, Avi Kivity; +Cc: qemu-devel, Alexander Graf
On Sun, Jan 8, 2012 at 02:48, Andreas Färber <afaerber@suse.de> wrote:
> Am 07.01.2012 18:29, schrieb Blue Swirl:
>> On Thu, Jan 5, 2012 at 17:45, Andreas Färber <afaerber@suse.de> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic
2012-01-08 11:43 ` Blue Swirl
@ 2012-01-08 12:16 ` Avi Kivity
0 siblings, 0 replies; 6+ messages in thread
From: Avi Kivity @ 2012-01-08 12:16 UTC (permalink / raw)
To: Blue Swirl; +Cc: Alexander Graf, Andreas Färber, qemu-devel
On 01/08/2012 01:43 PM, Blue Swirl wrote:
> On Sun, Jan 8, 2012 at 02:48, Andreas Färber <afaerber@suse.de> wrote:
> > Am 07.01.2012 18:29, schrieb Blue Swirl:
> >> On Thu, Jan 5, 2012 at 17:45, Andreas Färber <afaerber@suse.de> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-08 12:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-15 13:50 [Qemu-devel] [PATCH 1/2] m48t59: drop obsolete address base arithmetic Blue Swirl
2012-01-05 17:45 ` Andreas Färber
2012-01-07 17:29 ` Blue Swirl
2012-01-08 2:48 ` Andreas Färber
2012-01-08 11:43 ` Blue Swirl
2012-01-08 12:16 ` Avi Kivity
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.