fw_cfg_mem: expose the "data_width" property with fw_cfg_init_mem_wide()
commit6c87e3d5967a1d731b5f591a8f0ee6c319c14ca8
authorLaszlo Ersek <lersek@redhat.com>
Mon, 22 Dec 2014 12:11:41 +0000 (22 13:11 +0100)
committerPeter Maydell <peter.maydell@linaro.org>
Mon, 22 Dec 2014 23:39:18 +0000 (22 23:39 +0000)
tree2a9f71c50b7651686af66f5f6777a50d778e28a5
parentcfaadf0e89e7c2a47462d5f96390c9a9b4de037c
fw_cfg_mem: expose the "data_width" property with fw_cfg_init_mem_wide()

We rebase fw_cfg_init_mem() to the new function for compatibility with
current callers.

The behavior of the (big endian) multi-byte data reads is best shown
with a qtest session.  Here, we are reading the first six bytes of
the UUID

    $ arm-softmmu/qemu-system-arm -M virt -machine accel=qtest \
         -qtest stdio -uuid 4600cb32-38ec-4b2f-8acb-81c6ea54f2d8
>>> writew 0x9020008 0x0200
<<< OK
>>> readl 0x9020000
<<< OK 0x000000004600cb32

Remember this is big endian.  On big endian machines, it is stored
directly as 0x46 0x00 0xcb 0x32.

On a little endian machine, we have to first swap it, so that it becomes
0x32cb0046.  When written to memory, it becomes 0x46 0x00 0xcb 0x32
again.

Reading byte-by-byte works too, of course:

>>> readb 0x9020000
<<< OK 0x0000000000000038
>>> readb 0x9020000
<<< OK 0x00000000000000ec

Here only a single byte is read at a time, so they are read in order
similar to the 1-byte data port that is already in PPC and SPARC
machines.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1419250305-31062-8-git-send-email-pbonzini@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/nvram/fw_cfg.c
include/hw/nvram/fw_cfg.h