From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDHv6-0001sJ-Fa for qemu-devel@nongnu.org; Sat, 24 Aug 2013 13:46:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDHuz-0000zZ-5c for qemu-devel@nongnu.org; Sat, 24 Aug 2013 13:46:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:54249 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDHuy-0000yA-TD for qemu-devel@nongnu.org; Sat, 24 Aug 2013 13:46:33 -0400 Message-ID: <5218F16C.9000409@suse.de> Date: Sat, 24 Aug 2013 19:46:20 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1377037501-18498-1-git-send-email-mark.cave-ayland@ilande.co.uk> <5214FEDD.3030402@suse.de> <52150C61.9070106@ilande.co.uk> In-Reply-To: <52150C61.9070106@ilande.co.uk> 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: Mark Cave-Ayland Cc: Blue Swirl , Peter Maydell , Bob Breuer , QEMU Developers , Artyom Tarasenko Am 21.08.2013 20:52, schrieb Mark Cave-Ayland: > On 21/08/13 18:54, Andreas F=C3=A4rber wrote: >=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 pat= ch >> is missing Makefile support to actually copy the new binary from >> OpenBIOS build to the location it is being added to as binary here. >=20 > Okay that's something else to add to the v2 :) On second thoughts, more important than Makefile changes (which would depend on the OpenBIOS gitmodule update) would be to document textually in the README wherever the openbios-sparc origin is tracked that this file comes from OpenBIOS rXXXX, too. >>>> --- a/hw/sparc/sun4m.c >>>> +++ b/hw/sparc/sun4m.c >>> >>>> + fcode_filename =3D qemu_find_file(QEMU_FILE_TYPE_BIOS, >>>> TCX_ROM_FILE); >>>> + if (fcode_filename) { >>>> + ret =3D load_image_targphys(fcode_filename, addr, >>>> FCODE_MAX_ROM_SIZE); >>>> + } >>> >>> 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? >>> >>> (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 s= o >> getting this designed right probably only takes a week or so... >=20 > Currently there is no concept of an SBus in QEMU, since the bus address > lines are effectively mapped to the processor bus (and so the standard > sysbus calls work just fine). I know this isn't the complete truth with > respect to real hardware, though I suspect Blue/Bob could expand furthe= r > on this if required. Seems I mixed that up with CBus then. ;) So, TCX is a SysBusDevice. How do I recognize which devices are SBus devices? Do you have a list of files/types or some recipe to find out? With QOM it would be easily possible to derive a TYPE_SBUS_DEVICE from TYPE_SYS_BUS_DEVICE and have TYPE_TCX be derived from it. Then SBusDeviceClass could supply a rom_file field, which generic SBus code loads in its realizefn while still being able to use sysbus_*() API. 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