[Qemu-discuss] CPU write value passed from application to qemu is strange

[Chan Kim]

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 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 of the device (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?  Maybe I'm not aware of something important..
Any hint will be deeply appreciated.