From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvA0Z-0002Ql-5E for qemu-devel@nongnu.org; Mon, 23 Dec 2013 13:13:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvA0T-0006Pe-I2 for qemu-devel@nongnu.org; Mon, 23 Dec 2013 13:13:39 -0500 Message-ID: <52B87D3D.8060806@reactos.org> Date: Mon, 23 Dec 2013 19:13:17 +0100 From: =?ISO-8859-1?Q?Herv=E9_Poussineau?= 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> <17FC51C8-FDB4-46D0-8512-A1C626D14054@suse.de> In-Reply-To: <17FC51C8-FDB4-46D0-8512-A1C626D14054@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [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: Alexander Graf Cc: =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-ppc , QEMU Developers Alexander Graf a =E9crit : > On 23.12.2013, at 07:48, Herv=E9 Poussineau wrot= e: >=20 >> Hi, >> >> Andreas F=E4rber a =E9crit : >>> Hi, >>> Am 05.11.2013 00:09, schrieb Herv=E9 Poussineau: >>>> Raven datasheet explains where firmware lives in system memory, so d= o >>>> it there instead of in board code. Other boards using the same PCI >>>> host will not have to copy the firmware loading code. >>> This part we had discussed and no one objected to the approach, so OK= . >>>> 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). >>> 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= it >>> 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_ad= dr, >> 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 = 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 = code to: >> +#define BIOS_SIZE (1024 * 1024) >> + bios_addr =3D (uint32_t)(-BIOS_SIZE); >> + bios_size =3D load_image_targphys(filename, bios_ad= dr, >> + 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 pointi= ng to empty memory, and symptoms are an empty screen on OHW. >> >> So, I'm adding this hack for OHW, to mirror the 0xfff00000-0xfff7ffff = range to 0xfff80000-0xffffffff. >> >> 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 wi= th 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. >=20 > Couldn't we just make the ROM fill the upper part of the 1MB region whe= n we see it's smaller than 1MB? So that we pad at the bottom, not the top= ? >=20 > bios_size =3D get_image_size(filename); > if (bios_size < 0) { > // error handling > } > assert(bios_size <=3D (1*MB)); > bios_addr =3D (uint32_t)(-bios_size); >=20 I don't think that's a good idea, because the PReP cpus (601/604) have a=20 reset vector at 0xfff00100. So you have to put some firmware at this=20 address, even if firmware is smaller than 1MB. OHW is the problem here, because it is less than 1MB and expects a reset=20 vector at 0xfffffffc. That's why I want to put the hack outside raven=20 chipset, in prep machine code. Regards, Herv=E9