CPU write value passed from application to qemu is strange

Issue

I was trying to run RTEMS(a real-time OS) application on a sparc virtual machine using QEMU. I'm almost there and I've seen it working hours ago. But after removing some prints it is not working and later I found it's not because of the removed prints. The data is not being passed correctly between the RTEMS image and the QEMU emulation model.(I'm working with QEMU version 1.5.50 and lan9118.c model borrowed from QEMU version 2.0.0. I modifed lan9118 a little.)
In the QEMU model, the memory region ops are defined as

struct MemoryRegionOps {
    /* Read from the memory region. @addr is relative to @mr; @size is
     * in bytes. */
    uint64_t (*read)(void *opaque,
                     hwaddr addr,
                     unsigned size);
    /* Write to the memory region. @addr is relative to @mr; @size is
     * in bytes. */
    void (*write)(void *opaque,
                  hwaddr addr,
                  uint64_t data,
                  unsigned size);
...
}

and in the RTEMS application, I write to the device like

        *TX_FIFO_PORT = cmdA;
        *TX_FIFO_PORT = cmdB;

where TX_FIFO_PORT is defined as below.

#define TX_FIFO_PORT                    (volatile ulong *)(SMSC9118_BASE + 0x20)

But when I write, for example,

cmdA : 0x2a300200 and cmdB : 0x2a002a00,  

The values I expected are

cmdA : 0x0002302a and cmdB : 0x002a002a.  (Just endian converted values)

But the values I see at the write function (entrance of QEMU) are

cmdA : 0x02000200 and cmdB : 0x2a002a00 respectively.  

The observed values have not been endian converted and even the first value is different(lower 16 bit repeated). What could be problem?
Any hint will be deeply appreciated.

Solution

Strangely I fixed this by commenting out the endian conversion for cmdA and cmdB in the RTEMS before writing to the device.(It was ok with the endian conversion..I don't know) So it's working 'almost'. Anyway, here is a tip about exchaning CPU write/read data in QEMU processor and deivce.
In QEMU, Each device model provides write and read function, also it specifies how the word should be transferd to/from the device regarding endianness. It is specified like below.

static const MemoryRegionOps lan9118_mem_ops = {
    .read = lan9118_readl,
    .write = lan9118_writel,
    .endianness = DEVICE_NATIVE_ENDIAN,
};

Here is the copy from email I received from Peter Maydell from [email protected] mailing list.

------------------------

This depends on what the MemoryRegionOps struct for the memory region sets its .endianness field to. DEVICE_NATIVE_ENDIAN means the device sees values the same way round as the guest CPU's native endianness[*], so if the guest does a 32 bit write of 0x12345678 then it appears in the write function's argument as 0x12345678. DEVICE_BIG_ENDIAN means that if the CPU is little endian then the word will be byteswapped. DEVICE_LITTLE_ENDIAN means that if the CPU is big endian then the word will be byteswapped. The latter are useful for devices or buses which have a specific endianness which is not the same as that of the CPU (eg PCI is always little endian).

Answered By - Chan Kim