Re: [Qemu-devel] [PATCHv2 1/2] sun4m: Add Sun CG3 framebuffer and corresponding OpenBIOS FCode ROM

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 09/02/14 14:41, Peter Maydell wrote:

> On 8 February 2014 16:38, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk>  wrote:
>> The CG3 framebuffer is a simple 8-bit framebuffer for use with operating
>> systems such as early Solaris that do not have drivers for TCX.
>>
>> +static void cg3_reg_write(void *opaque, hwaddr addr, uint64_t val,
>> +                          unsigned size)
>> +{
>> +    CG3State *s = opaque;
>> +    uint8_t regval;
>> +    int i;
>> +
>> +    DPRINTF("write %02lx to reg %x size %d\n", val, (int)addr, size);
>> +
>> +    switch (addr) {
>> +    case 0:
>> +        s->dac_index = val;
>> +        s->dac_state = 0;
>> +        break;
>> +    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.

One of things we do know about that card is that the DAC is a BT408, 
where the 256 * 3 shift register for the RGB values is seemingly 
controller by register 4. And I'm fairly sure that I've seen a mixture 
of byte and 4-byte accesses to the card coming from the Solaris driver 
which is why it's necessary to support both accesses in this way :/

There is also a related comment on page 80 explaining how bus sizing can 
be used to allow 8-bit framebuffer to be driven in exactly the same way 
as a 32-bit framebuffer.

FWIW I copied the .endianness part over from the TCX driver, so if you 
feel for correctness that .endianness needs to be DEVICE_BIG_ENDIAN for 
TCX too then I'm happy to submit a patch for that too.


ATB,

Mark.