On 04/01/2019 05:47, P J P wrote:
> Hello Mark,
>
> +-- On Thu, 3 Jan 2019, Mark Cave-Ayland wrote --+
> | > /* Power */
> | > +static uint64_t power_mem_read(void *opaque, hwaddr addr, unsigned size)
> | > +{
> | > + return 0xffffffff;
> | > +}
> | > +
> | >
> | > static const MemoryRegionOps power_mem_ops = {
> | > + .read = power_mem_read,
> | > .write = power_mem_write,
> | > .endianness = DEVICE_NATIVE_ENDIAN,
> | > .valid = {
> |
> | Certainly the addition of the missing read function is valid, although I
> see that
> | you've defaulted reads to returning 0xffffffff - can you point me towards
> the source
> | that indicates that this behaviour matches that of real Ultra-5 hardware?
>
> -> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02787.html
>
> I haven't checked Ultra-5 h/w spec, return value was chosen similar to above
> one, thinking unimplemented .read need not return success.
>
> Thank you.
I asked someone with real Ultra-5 hardware to check this for me, and they've
sent me
back the following output:
ok .properties
address fffb8000
button
interrupts 00000001
reg 00000014 00724000 00000004
name power
ok fffb8000 l@ u.
0
Looks like the read value should be all 0s rather than all 1s. Can you resubmit
the
patch with this change?
ATB,
Mark.
