From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCCcK-0006fm-UI for qemu-devel@nongnu.org; Wed, 21 Aug 2013 13:54:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCCcE-0008AA-Am for qemu-devel@nongnu.org; Wed, 21 Aug 2013 13:54:48 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53196 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCCcE-0008A0-1I for qemu-devel@nongnu.org; Wed, 21 Aug 2013 13:54:42 -0400 Message-ID: <5214FEDD.3030402@suse.de> Date: Wed, 21 Aug 2013 19:54:37 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1377037501-18498-1-git-send-email-mark.cave-ayland@ilande.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Mark Cave-Ayland Cc: Blue Swirl , Bob Breuer , QEMU Developers , Artyom Tarasenko Am 21.08.2013 00:41, schrieb Peter Maydell: > On 20 August 2013 23:25, Mark Cave-Ayland wrote: >> Upstream OpenBIOS now implements SBus probing in order to determine th= e >> contents of a physical bus slot, which is required to allow OpenBIOS t= o >> identify the framebuffer without help from the fw_cfg interface. >> >> SBus probing works by detecting the presence of an FCode program >> (effectively tokenised Forth) at the base address of each slot, and if >> present executes it so that it creates its own device node in the >> OpenBIOS device tree. >> >> The FCode ROM is generated as part of the OpenBIOS build and should >> generally be updated at the same time. >=20 >> hw/display/tcx.c | 7 +++++++ >> hw/sparc/sun4m.c | 32 +++++++++++++++++++++++++------- >> pc-bios/QEMU,tcx.bin | Bin 0 -> 1242 bytes >=20 > Shouldn't this blob come in the same patch as an update to some > git module, so that we keep track of the sources used to build > the blob? I concur. Independent of how to order the .gitmodules update, this patch is missing Makefile support to actually copy the new binary from OpenBIOS build to the location it is being added to as binary here. >> --- a/hw/sparc/sun4m.c >> +++ b/hw/sparc/sun4m.c >=20 >> + fcode_filename =3D qemu_find_file(QEMU_FILE_TYPE_BIOS, TCX_ROM_FI= LE); >> + if (fcode_filename) { >> + ret =3D load_image_targphys(fcode_filename, addr, FCODE_MAX_R= OM_SIZE); >> + } >=20 > This looks like the wrong place for this -- surely the tcx device > should load its own fcode blob, not defer to the board code > to do it? >=20 > (For that matter, presumably if this is an SBus device then > the offsets of the ROM, DAC, etc etc are all fixed relative to > the base address of the SBus slot, and the tcx device itself > should be creating a container with all its component parts > at the right offset. But that's not an issue for this patch.) I vaguely recall Mark telling me that SBus is not really qdev'ified/QOM'ified, right? PCI devices have support for ROM files, too, and I think they just set the file name and generic PCI code takes care of the actual loading. Maybe we would want to do the same for SBus? We're not in a rush yet so getting this designed right probably only takes a week or so... Cheers, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg