qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv2 1/2] sun4m: Add Sun CG3 framebuffer and corres


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCHv2 1/2] sun4m: Add Sun CG3 framebuffer and corresponding OpenBIOS FCode ROM
Date: Sun, 9 Feb 2014 15:33:55 +0000

On 9 February 2014 15:19, Mark Cave-Ayland
<address@hidden> wrote:
> On 09/02/14 14:41, Peter Maydell wrote:
>
>> On 8 February 2014 16:38, Mark Cave-Ayland
>> <address@hidden>  wrote:
>>> +    case 4:
>>> +        /* This register can be written to as either a long word or a
>>> byte.
>>> +         * According to the SBus specification, byte transfers are
>>> placed
>>> +         * in bits 31-28 */
>>> +        if (size == 1) {
>>> +            val<<= 24;
>>> +        }
>>
>>
>> I'm a little reluctant to start talking about endianness again :-)
>> but that "if (size == 1)" comment looks a little odd to me. The SBus
>> spec says that SBus is a big-endian bus (which probably means
>> that the .endianness in the memops struct should be
>> DEVICE_BIG_ENDIAN though for SPARC targets it won't make
>> any actual difference)". So while it's true that for SBus you get
>> byte transfers in data lines 31..28 (and also possibly on some of
>> the other data lines if the address is not 4-aligned or if the master
>> just feels like sending the byte on all four lanes at once), I don't
>> think that's why you're doing this shift. The shift is presumably
>> because the behaviour of this specific device is "I treat a byte
>> write like a write to the most significant byte of this register",
>> not because of the specifics of how SBus defines a byte transfer
>> to occur.
>
>
> It's been a little while since I looked, however this was my interpretation
> of the table 3-12 on p.66 of the SBus specification. While that particular
> table refers to the acknowledgment cycle from the slave back to the master,
> it seems to work here in the same way when transferring between the master
> and the slave.

It's not that I think your comment is wrong about how SBus does
byte transfers, or that the code is wrong, I just don't think that the
reason for the code is the SBus behaviour; it's the device behaviour.
QEMU abstracts a bus's mechanisms for transferring data into the
MemoryRegion ops, which means that for a byte access you'll
always get called with the byte value in the low 8 bits of the input
argument. This would be true whether SBus passed byte values in
lines 31..28, 7..0 or by sending them one bit at a time on D13. The
relation between a byte write and a word write here is a property
of the device, not the bus.

(You'll notice that 3-12 allows the slave to send the byte data
in various different lanes depending on which size acknowlegement
it chooses to send. The documentation of what the master does
is on page 53 and actually says you have to send it in two lanes
for a non-aligned address, and certainly QEMU won't do anything
corresponding to that. In any case I don't think it's relevant here.)

thanks
-- PMM



reply via email to

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