From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvLYB-000242-O3 for qemu-devel@nongnu.org; Tue, 24 Dec 2013 01:33:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvLY7-0001k1-MA for qemu-devel@nongnu.org; Tue, 24 Dec 2013 01:33:07 -0500 Message-ID: <52B92A96.3000701@reactos.org> Date: Tue, 24 Dec 2013 07:32:54 +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> <52B87D3D.8060806@reactos.org> <52B896E8.60903@web.de> <52B8B12F.5000104@reactos.org> <35A30917-FC76-49F5-AF40-50CF2EAB1C87@suse.de> <52B8EB4D.4090304@web.de> In-Reply-To: <52B8EB4D.4090304@web.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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Peter Maydell , Mark Cave-Ayland , qemu-ppc , Alexander Graf , QEMU Developers Andreas F=E4rber a =E9crit : > Am 24.12.2013 01:32, schrieb Alexander Graf: >> On 23.12.2013, at 22:54, Herv=E9 Poussineau wro= te: >> >>> Andreas F=E4rber a =E9crit : >>>> Am 23.12.2013 19:13, schrieb Herv=E9 Poussineau: >>>>> Alexander Graf a =E9crit : >>>>>> On 23.12.2013, at 07:48, Herv=E9 Poussineau = wrote: >>>>>> >>>>>>> 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 do >>>>>>>>> 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 t= he >>>>>>>> deleted code. If this is a new workaround, I would rather like t= o >>>>>>>> put it >>>>>>>> in a separate patch for bisecting (can offer to do that myself t= hen). >>>>>>>> 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, bi= os_addr, >>>>>>> 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 instru= ction. >>>>>>> Note that range 0xfff00000-0xfff7ffff is empty. >>>>>>> >>>>>>> Datasheet for raven says that firmware is at 0xfff00000, so I cha= nged >>>>>>> code to: >>>>>>> +#define BIOS_SIZE (1024 * 1024) >>>>>>> + bios_addr =3D (uint32_t)(-BIOS_SIZE); >>>>>>> + bios_size =3D load_image_targphys(filename, bi= os_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 to empty memory, and symptoms are an empty screen on OHW= . >>>>>>> >>>>>>> So, I'm adding this hack for OHW, to mirror the 0xfff00000-0xfff7= ffff >>>>>>> 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 with it. >>>>>>> >>>>>>> We'll be able to remove it once we switch to another firmware whi= ch >>>>>>> uses the right reset instruction pointer or whose size is 1MB. >>>>>> Couldn't we just make the ROM fill the upper part of the 1MB regio= n >>>>>> when we see it's smaller than 1MB? So that we pad at the bottom, n= ot >>>>>> the top? >>>>>> >>>>>> 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); >>>>>> >>>>> I don't think that's a good idea, because the PReP cpus (601/604) h= ave a >>>>> reset vector at 0xfff00100. So you have to put some firmware at thi= s >>>>> address, even if firmware is smaller than 1MB. >>>>> >>>>> OHW is the problem here, because it is less than 1MB and expects a = reset >>>>> vector at 0xfffffffc. That's why I want to put the hack outside rav= en >>>>> chipset, in prep machine code. >>>> Let me clarify then that it was me who disabled some checks that use= d to >>>> assure that the loaded binary is in fact 1MB: >>>> http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3D74145374bfc0b7b0241= 5184606236f0390479deb >>>> So the issue is actually that the OHW binary is really messed up. >>>> And me, Herv=E9 and Mark have been working on getting OpenBIOS worki= ng for >>>> PReP in its place. >>>> So I'm currently considering the following options: >>>> 1) >>>> Revert OHW alias and size/position change >>>> Strip ELF loading and elf-machine >>>> Add back Raven ELF support separately >>>> 2) >>>> Apply my prep.c ELF support patch first >>>> Apply this patch as pure loading-logic movement >>>> 3) >>>> Leave broken OHW loading in prep.c >>>> Only implement 1MB / ELF loading support in Raven >>>> 4) >>>> Accept a 1MB OHW image and drop support for 512KB OHW >> I like this option the best. >=20 > Alex, are you volunteering to build one? You wanted to look into that > with me since a looong time ago... :) I can provide one 1MB OHW binary soon. One is already available (without Ren=E9 Rebe patch) at http://repo.or.cz/w/qemu/hpoussin.git/blob/openhackware:/ppc_rom.bin >=20 > http://repo.or.cz/w/openhackware.git >=20 > As you will remember, Jocelyn fixed an IDE issue binary-only, without > updating pc-bios/ohw.diff: > http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3D55aa45ddde3283cdd78132= 6d001f7456bf02f684 >=20 > I dug out the patch Ren=E9 Rebe proposed later for fixing that IDE issu= e: > http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00223.html >=20 > I've just managed to fix up that patch to finally apply (apart from lin= e > wraps in a patch to a patch - gosh! - there was also an "address@hidden= " > from the archive hidden in the patch context), attached, but haven't ye= t > re-tried to build with it. It includes a linker script fix that might > explain my previous build issues. >=20 Herv=E9