从应用程序传递给 qemu 的 CPU 写入值很奇怪

Question

我尝试使用 QEMU 在 sparc 虚拟机上运行 RTEMS(实时操作系统)应用程序。我快到了，我已经看到它在几个小时前工作了。但是在删除一些打印件后它不起作用，后来我发现这不是因为删除了打印件。数据未在 RTEMS 图像和 QEMU 仿真模型之间正确传递。(我正在使用 QEMU 1.5.50 版和从 QEMU 2.0.0 版借用的 lan9118.c 模型。我对 lan9118 做了一些修改。)
在QEMU模型中，内存区域ops定义为

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);
...
}

在 RTEMS 应用程序中，我像这样写入设备

        *TX_FIFO_PORT = cmdA;
        *TX_FIFO_PORT = cmdB;

其中 TX_FIFO_PORT 定义如下。

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

但是当我写的时候，例如，

cmdA : 0x2a300200 and cmdB : 0x2a002a00,  

我期望的值是

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

但是我在write函数(QEMU的入口)看到的值是

cmdA : 0x02000200 and cmdB : 0x2a002a00 respectively.  

观察到的值没有进行字节序转换，甚至第一个值也不同(低 16 位重复)。可能是什么问题？
任何提示将不胜感激。

Answer 1

奇怪的是，我在写入设备之前通过在 RTEMS 中注释掉 cmdA 和 cmdB 的字节序转换来解决此问题。(字节序转换没问题……我不知道)所以它“几乎”工作了。不管怎样，这里有一个关于在 QEMU 处理器和设备中交换 CPU 写入/读取数据的提示。
在 QEMU 中，每个设备模型都提供了写入和读取功能，它还指定了如何根据字节顺序将字传输到设备/从设备传输。如下所示。

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

这是我从 qemu-discuss@nongnu.org 邮件列表收到的来自彼得梅德尔的电子邮件的副本。

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

这取决于内存区域的 MemoryRegionOps 结构将其 .endianness 字段设置为什么。DEVICE_NATIVE_ENDIAN 表示设备以与 guest CPU 的 native 字节顺序 [*] 相同的方式查看值，因此如果 guest 执行 0x12345678 的 32 位写入，则它在写入函数的参数中显示为 0x12345678。 DEVICE_BIG_ENDIAN 表示如果 CPU 是小端字节序，那么该字将被字节交换。DEVICE_LITTLE_ENDIAN 意味着如果 CPU 是 big endian 那么这个字将被字节交换。后者对于具有与 CPU 不同的特定字节序的设备或总线很有用(例如 PCI 始终是小字节序)。