On 3 March 2017 at 02:15, BALATON Zoltan <bala...@eik.bme.hu> wrote: > Maybe it's not correct but works for everything I could test better than the > original code (which was broken even for the SH images one can find) so I > think we could just go with this until someone complains and provides a test > case. I've given up on trying to understand it because I don't really know > this device and SH so I could only go by the images I could find and they > seem to like it this way.
So what cases have you tested? The Linux kernel seems to support: * sh embedded device, little endian * PCI card, little endian host * PCI card, big endian host and there are also * 16 bit pixel format * 32 bit pixel format which makes 6 different combinations. (It's a shame there's no sh4 BE code to run on this.) >> Looking at how the SWAP_FB_ENDIAN flag gets set: >> * for the r2d board it is set always >> * for PCI devices, it is set only if big-endian >> >> I suspect that what we actually have here is something >> like: >> * for the PCI device it's always little endian (and the >> code ought not to need to depend on TARGET_WORDS_BIGENDIAN) >> * sysbus device may be more complicated >> >> Also I note there's an SM501_ENDIAN_CONTROL register on the >> device, which presumably if written changes the behaviour. > I've seen this but it's not emulated so it can be ignored for now. The spec > also says that default is little endian so for regs at least > DEVICE_LITTLE_ENDIAN should be OK. Yes, that makes sense. So we should be modelling this as an "always little endian device". The changes you have to the memory region ops achieve this for the registers implemented in this device itself. It looks like SYSBUS_OHCI is already always little endian. You also need to change the argument to the serial_mm_init() call to pass DEVICE_LITTLE_ENDIAN. thanks -- PMM
