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

[Peter Maydell]

On 8 February 2014 16:38, Mark Cave-Ayland
<address@hidden> 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.

thanks
-- PMM