From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuzJh-0003oL-JA for qemu-devel@nongnu.org; Mon, 23 Dec 2013 01:48:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuzJc-0006zp-0K for qemu-devel@nongnu.org; Mon, 23 Dec 2013 01:48:41 -0500 Message-ID: <52B7DCB3.40202@reactos.org> Date: Mon, 23 Dec 2013 07:48:19 +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> In-Reply-To: <52B78C3D.4030703@web.de> 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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org Hi, Andreas F=C3=A4rber a =C3=A9crit : > Hi, >=20 > Am 05.11.2013 00:09, schrieb Herv=C3=A9 Poussineau: >> Raven datasheet explains where firmware lives in system memory, so do >> it there instead of in board code. Other boards using the same PCI >> host will not have to copy the firmware loading code. >=20 > This part we had discussed and no one objected to the approach, so OK. >=20 >> However, add a specific hack for Open Hack'Ware, which provides only >> a 512KB blob to be loaded at 0xfff00000, but expects valid code at >> 0xfffffffc (specific Open Hack'Ware reset instruction pointer). >=20 > Was this part explained before? I don't spot the equivalent in the > deleted code. If this is a new workaround, I would rather like to put i= t > in a separate patch for bisecting (can offer to do that myself then). > What are the symptoms? I am testing all these patches with OHW. Old code does (error checking removed): >> - bios_size =3D get_image_size(filename); >> - bios_addr =3D (uint32_t)(-bios_size); >> - bios_size =3D load_image_targphys(filename, bios_add= r, Ie, bios_addr =3D -512KB (size of OHW blob) =3D 0xfff80000 and firmware is loaded in the range 0xfff80000-0xffffffff OHW expects reset instruction pointer to be 0xfffffffc (not valid for=20 604, but that's not the point now), which contains a valid instruction. Note that range 0xfff00000-0xfff7ffff is empty. Datasheet for raven says that firmware is at 0xfff00000, so I changed=20 code to: +#define BIOS_SIZE (1024 * 1024) + bios_addr =3D (uint32_t)(-BIOS_SIZE); + bios_size =3D load_image_targphys(filename, bios_addr, + bios_size); Ie, bios_addr =3D -1MB =3D 0xfff00000 and firmware is loaded in the range 0xfff00000-0xfff7ffff. This doesn't work due to reset instruction pointer which now is pointing=20 to empty memory, and symptoms are an empty screen on OHW. So, I'm adding this hack for OHW, to mirror the 0xfff00000-0xfff7ffff=20 range to 0xfff80000-0xffffffff. So, this patch is a small functional change, as it adds a copy of the=20 firmware in a new range 0xfff00000-0xfff7ffff, but I think we can live=20 with it. We'll be able to remove it once we switch to another firmware which uses=20 the right reset instruction pointer. Regards, Herv=C3=A9 >> Signed-off-by: Herv=C3=A9 Poussineau >> --- >> hw/pci-host/prep.c | 51 +++++++++++++++++++++++++++++++++++++++++++= ++++++++ >> hw/ppc/prep.c | 50 +++++++++++++------------------------------= ------- >> 2 files changed, 64 insertions(+), 37 deletions(-) > [...] >> diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c >> index 9f8538c..8a09e2b 100644 >> --- a/hw/ppc/prep.c >> +++ b/hw/ppc/prep.c > [...] >> @@ -510,41 +509,13 @@ static void ppc_prep_init(QEMUMachineInitArgs *a= rgs) >> memory_region_add_subregion(sysmem, 0, ram); >> =20 >> /* allocate and load BIOS */ >> - memory_region_init_ram(bios, NULL, "ppc_prep.bios", BIOS_SIZE); >> - memory_region_set_readonly(bios, true); >> - memory_region_add_subregion(sysmem, (uint32_t)(-BIOS_SIZE), bios)= ; >> - vmstate_register_ram_global(bios); >> - if (bios_name =3D=3D NULL) >> - bios_name =3D BIOS_FILENAME; >> - filename =3D qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); >> - if (filename) { >> - bios_size =3D load_elf(filename, NULL, NULL, NULL, >> - NULL, NULL, 1, ELF_MACHINE, 0); >> - if (bios_size < 0) { >> - bios_size =3D get_image_size(filename); >> - if (bios_size > 0 && bios_size <=3D BIOS_SIZE) { >> - hwaddr bios_addr; >> - bios_size =3D (bios_size + 0xfff) & ~0xfff; >> - bios_addr =3D (uint32_t)(-bios_size); >> - bios_size =3D load_image_targphys(filename, bios_addr= , bios_size); >> - } >> - if (bios_size > BIOS_SIZE) { >> - fprintf(stderr, "qemu: PReP bios '%s' is too large (0= x%x)\n", >> - bios_name, bios_size); >> - exit(1); >> - } >> - } >> - } else { >> - bios_size =3D -1; >> - } >> - if (bios_size < 0 && !qtest_enabled()) { >> - fprintf(stderr, "qemu: could not load PPC PReP bios '%s'\n", >> - bios_name); >> - exit(1); >> - } >> - if (filename) { >> - g_free(filename); >> - } >> + /* Open Hack'Ware hack: bios size is 512K and is loaded at 0xfff0= 0000. >> + * However, reset address is 0xfffffffc. Mirror the bios from >> + * 0xfff00000 to 0xfff80000. >> + */ >> + memory_region_init_alias(bios, NULL, "bios-alias", sysmem, 0xfff0= 0000, >> + 0x00080000); >> + memory_region_add_subregion_overlap(sysmem, 0xfff80000, bios, 1); >> =20 >> if (linux_boot) { >> kernel_base =3D KERNEL_LOAD_ADDR; > [snip] >=20 >=20