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

[Chan Kim]

I was mistaken. The code lan9118.c was originally from version 1.5.50.

and it seems to be endian problem. This afternoon it was ok when the smsc9220.c 
driver sent cmdA and cmdB after chaning endian.
But this time, it is ok when it is sent as is. So whatever 32bit value I write, 
it should be seen as such at the device's qemu write function. Isn't this the 
normal behavior? (If I write 0x12345678, it is seen 0x12345678 not 0x78563412). 

Chan


보낸 사람 : "Chan Kim" <address@hidden>
보낸 날짜 : 2014-09-29 17:30:12 ( +09:00 )
받는 사람 : address@hidden <address@hidden>
참조 : 
제목 : [Qemu-discuss] CPU write value passed from application to qemu is strange


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.