From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy7bd-0005gK-Aw for qemu-devel@nongnu.org; Mon, 08 Dec 2014 18:20:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xy7bX-0000m2-20 for qemu-devel@nongnu.org; Mon, 08 Dec 2014 18:20:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy7bW-0000lw-Js for qemu-devel@nongnu.org; Mon, 08 Dec 2014 18:20:34 -0500 Message-ID: <5486323C.2060402@redhat.com> Date: Tue, 09 Dec 2014 00:20:28 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1417366783-14242-1-git-send-email-lersek@redhat.com> <5485AF57.6050902@redhat.com> <5485FE8A.7040309@redhat.com> <548615CE.10100@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] arm: add fw_cfg to "virt" board List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Drew Jones , Ard Biesheuvel , QEMU Developers , Christoffer Dall "Richard W.M. Jones" On 12/08/14 22:34, Peter Maydell wrote: > On 8 December 2014 at 21:19, Laszlo Ersek wrote: >> So the following in addition makes it work on TCG (x86_64) too: >> >> ----------------- >> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c >> index 7147fea..c2bc44c 100644 >> --- a/hw/nvram/fw_cfg.c >> +++ b/hw/nvram/fw_cfg.c >> @@ -31,7 +31,7 @@ >> #include "qemu/config-file.h" >> >> #define FW_CFG_SIZE 2 >> -#define FW_CFG_DATA_SIZE 1 >> +#define FW_CFG_DATA_SIZE 8 >> #define TYPE_FW_CFG "fw_cfg" >> #define FW_CFG_NAME "fw_cfg" >> #define FW_CFG_PATH "/machine/" FW_CFG_NAME >> ----------------- >> >> It affects the memory_region_init_io() call in fw_cfg_initfn(). >> >> I hope to submit a small v3 series soon. > > If you do that don't you now try to define an ioport on > x86 that's 8 bytes wide? You probably also need to check > whether the ppc and sparc boards that use mmio fw_cfg > can handle the wider data register. The above was just a quick PoC. The series I'm about to post takes care not to change anything (not even gdb experience) for clients that don't request the wider register. Thanks Laszlo