On 8 February 2014 16:38, Mark Cave-Ayland <mark.cave-ayl...@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. thanks -- PMM