From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvAzL-00022U-RW for qemu-devel@nongnu.org; Mon, 23 Dec 2013 14:16:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvAzG-000071-8n for qemu-devel@nongnu.org; Mon, 23 Dec 2013 14:16:27 -0500 Message-ID: <52B88BFD.6090607@reactos.org> Date: Mon, 23 Dec 2013 20:16:13 +0100 From: =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= MIME-Version: 1.0 References: <1383606592-12783-1-git-send-email-hpoussin@reactos.org> <1383606592-12783-4-git-send-email-hpoussin@reactos.org> <52B78C3D.4030703@web.de> <52B7DCC9.7060004@reactos.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 03/10] raven: move BIOS loading from board code to PCI host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , "qemu-ppc@nongnu.org" , QEMU Developers Peter Maydell a =C3=A9crit : > On 23 December 2013 06:48, Herv=C3=A9 Poussineau = wrote: >> So, this patch is a small functional change, as it adds a copy of the >> firmware in a new range 0xfff00000-0xfff7ffff, but I think we can live= with >> it. >> >> We'll be able to remove it once we switch to another firmware which us= es the >> right reset instruction pointer or whose size is 1MB. >> >>>> + /* Open Hack'Ware hack: bios size is 512K and is loaded at >>>> 0xfff00000. >>>> + * However, reset address is 0xfffffffc. Mirror the bios from >>>> + * 0xfff00000 to 0xfff80000. >>>> + */ >>>> + memory_region_init_alias(bios, NULL, "bios-alias", sysmem, >>>> 0xfff00000, >>>> + 0x00080000); >>>> + memory_region_add_subregion_overlap(sysmem, 0xfff80000, bios, 1= ); >=20 > This code creates the mirrored region regardless of the size of the > firmware blob, right? I think that means that if we do supply a > 1MB blob it'll do the wrong thing. You probably want to have some > "mirror this object as many times as necessary to fill the space" > logic. >=20 > We could probably do with having a generic MemoryRegion > API for that, actually -- it's not uncommon behaviour for devices > to be accessible every N bytes because they simply don't > decode the full set of address lines. >=20 > memory_region_add_subregion_tiled(MemoryRegion *mr, > hwaddr offset, hwaddr tilelen, > MemoryRegion *subregion) >=20 > to add copies of subregion to container mr starting at offset > for tilelen bytes, maybe? (we assume subregion to be created > at the length that each 'tile' should be, so don't need to pass > that too). This hack is meant to exist only as long as OHW has not been replaced by=20 something else. That's a hack which has to be used only for *current OHW=20 firmware* (ie 512KB) and only for *a short time*. I've already patches=20 to replace OHW by OpenBIOS, but some details need some more polish. So, I don't want to invest too much time to polish this hack. Choose=20 whatever you want, but I don't want to take more time to push this patchs= et. If you really don't like it, I can provide a OHW image which is 1MB, so=20 this hack becomes moot. It will be created by concatenating 2 512KB OHW=20 images in a 1MB image. Regards, Herv=C3=A9