From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDElf-0002eU-1z for qemu-devel@nongnu.org; Mon, 19 Jan 2015 11:01:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDEle-0005ty-4q for qemu-devel@nongnu.org; Mon, 19 Jan 2015 11:01:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDEld-0005tt-TA for qemu-devel@nongnu.org; Mon, 19 Jan 2015 11:01:30 -0500 Message-ID: <54BD2A44.9020901@redhat.com> Date: Mon, 19 Jan 2015 17:01:08 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1421667328-11800-1-git-send-email-mark.cave-ayland@ilande.co.uk> <1421667328-11800-3-git-send-email-mark.cave-ayland@ilande.co.uk> <54BCFC57.3010709@redhat.com> <54BD1C2D.9070603@suse.de> <54BD236E.1040200@redhat.com> <54BD24F5.70309@suse.de> In-Reply-To: <54BD24F5.70309@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] m48t59: add mem_base value to m48t59_init_isa() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Artyom Tarasenko Cc: qemu-ppc@nongnu.org, =?UTF-8?B?SGVydsOpIA==?= =?UTF-8?B?UG91c3NpbmVhdQ==?= , Mark Cave-Ayland , qemu-devel , Alexander Graf On 19/01/2015 16:38, Andreas F=C3=A4rber wrote: >> > Is there an "EBus bridge" PCI device similar to the PCI-to-ISA bridg= e? > In the previous dump, the "ebus" entry looked like one to me? >=20 > bus: pci > dev: ebus, id "" > addr =3D 03.0 > class Bridge, addr 00:03.0, pci id 108e:1000 (sub 1af4:1100) > bar 0: mem at 0x3000000 [0x3ffffff] > bar 1: i/o at 0x4000 [0x7fff] > bus: isa.0 > type ISA >=20 > Confusingly named, as "ebus" would be a better type name for the actual > bus, but "EBus" might work as bus name if we actually need one (does th= e > user add devices to this bus or are these all chipset features > recursively set up by the machine?). Otherwise they could just be > child<> properties on the ebus device. So is this m48t59 device mapped inside a BAR of its parent ebus device? What value will the sun4u patch pass for mem_base? Paolo