From owner-freebsd-sparc64@freebsd.org Sun Sep 13 02:21:53 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE63AA03C4C for ; Sun, 13 Sep 2015 02:21:53 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FC06104A; Sun, 13 Sep 2015 02:21:52 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8D2LiEF008487 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Sep 2015 04:21:44 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8D2Lh7W008486; Sun, 13 Sep 2015 04:21:43 +0200 (CEST) (envelope-from marius) Date: Sun, 13 Sep 2015 04:21:43 +0200 From: Marius Strobl To: Mark Cave-Ayland Cc: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150913022143.GA7862@alchemy.franken.de> References: <557D82F8.50908@ilande.co.uk> <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <55EDFE00.9090109@ilande.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 13 Sep 2015 04:21:44 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 02:21:53 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 07, 2015 at 10:13:36PM +0100, Mark Cave-Ayland wrote: > On 07/09/15 21:31, Marius Strobl wrote: > > > On Sun, Sep 06, 2015 at 12:48:59PM +0000, Alexey Dokuchaev wrote: > >> On Sun, Sep 06, 2015 at 01:16:13PM +0100, Mark Cave-Ayland wrote: > >>> On 06/09/15 12:03, Alexey Dokuchaev wrote: > >>>> Mark did you have any success with getting the boot process further? > >>> > >>> Not really - due to changes with my job and involvment in GSoC this year > >>> then my QEMU SPARC64 work hasn't really progressed much :( > >>> > >>> I don't have my FreeBSD environment setup right now (due to OS upgrade) > >>> but can you post the console output for the boot as far as it gets with > >>> the current version of the patch applied? > >> > >> Last few lines: > >> > >> [...] > >> eeprom0: addr 0x1400002000-0x1400003fff on ebus0 > >> eeprom0: cannot allocate resources > >> device_attach: eeprom0 attach returned 6 > >> ebus0: addr 0 (no driver attached) > >> ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) > > > > This suggests that there's something wrong with the emulation of > > the PCI-EBus-bridge (child space maps to a region not covered by > > the BARs, child space not covered by the mapping, wrong resource > > type in the ranges table or something like that), causing the > > allocation of child resources to fail as in the eeprom(4) case > > above. Such a problem would also explain why uart(4) doesn't try > > to attach to 'su' albeit it should: uart_bus_probe() already > > allocates the resource, failing silently if that doesn't work > > and, thus, causing uart_bus_attach() never to be called. > > > >> Full log available here: > >> > >> http://193.124.210.26/head-r287497-sparc64-qemu.log > >> > >> ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at device 3.0 on pci0 > > > > That's already unusual; real PCI-EBus-bridges have two memory > > BARs (although children may use I/O ports which are translated > > to memory resources upstream) rather than an I/O port and a > > memory one. However, the above actually should also work code- > > wise, iff the resource types are encoded correctly in the ranges > > table. > > While the QEMU PCI-ebus properties don't necessarily reflect a real > ultra2 You probably mean Ultra5/10 here; Ultra2 are SBus- rather than PCI- based. Still, the machine QEMU emualtes only looks similar to a real Ultra5/10 from a 10 km distance ... >, they should be consistent in terms of ranges as several patches > along those lines were required to enable NetBSD and OpenBSD to boot > under qemu-system-sparc64. For reference I've included the properties > from OpenBIOS below: > > > 0 > cd /pci/ ok > 0 > .properties > name "pci" > reg 000001fe 00000000 00000000 02000000 > vendor-id 108e > device-id a000 > revision-id 0 > class-code 60000 > min-grant 0 > max-latency 0 > devsel-speed 0 > fast-back-to-back > 66mhz-capable > subsystem-vendor-id 1af4 > subsystem-id 1100 > cache-line-size 0 > device_type "pci" > model "SUNW,sabre" > compatible {"pci108e,a000", "pciclass,0"} > #address-cells 3 > #size-cells 2 > #interrupt-cells 1 > ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 00 > 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 00 00 00 > 00 00 00 00 10 00 00 00 00 01 ff 00 10 00 00 00 00 00 00 10 00 00 00 > virtual-dma -- 8 : c0 00 00 00 20 00 00 00 > #virtual-dma-size-cells 1 > #virtual-dma-addr-cells 1 > no-streaming-cache > interrupts -- 10 : 00 00 07 f0 00 00 07 ee 00 00 07 ef 00 > 00 07 e5 > upa-portid 1f > bus-range -- 8 : 00 00 00 00 00 00 00 02 > available -- 28 : 02 00 00 00 00 00 00 00 04 04 00 00 00 > 00 00 00 0b fc 00 00 01 00 00 00 00 00 00 00 00 00 83 80 00 00 00 00 00 > 00 7c 80 > interrupt-map -- 30 : 00 00 20 00 00 00 00 00 00 00 00 00 00 > 00 00 01 ff e2 b7 40 00 00 00 10 00 00 28 00 00 00 00 00 00 00 00 00 00 > 00 00 01 ff e2 b7 40 00 00 00 14 > interrupt-map-mask -- 10 : 00 00 f8 00 00 00 00 00 00 00 00 00 00 > 00 00 07 > ok > 0 > cd ebus ok > 0 > .properties > name "ebus" > vendor-id 108e > device-id 1000 > revision-id 1 > class-code 68000 > min-grant 0 > max-latency 0 > devsel-speed 0 > fast-back-to-back > 66mhz-capable > subsystem-vendor-id 1af4 > subsystem-id 1100 > cache-line-size a00 > model "ebus" > compatible {"pci108e,1000", "pciclass,068000"} > #address-cells 2 > #size-cells 1 > #interrupt-cells 1 > assigned-addresses -- 28 : 02 00 18 10 00 00 00 00 03 00 00 00 00 > 00 00 00 01 00 00 00 01 00 18 14 00 00 00 00 00 00 40 00 00 00 00 00 00 > 00 40 00 > reg 00001800 00000000 00000000 00000000 00000000 > 02001810 00000000 00000000 00000000 01000000 > 01001814 00000000 00000000 00000000 00004000 > interrupt-map -- 14 : 00 00 00 14 00 00 03 f8 00 00 00 01 ff > e1 b9 48 00 00 00 2b > interrupt-map-mask -- c : 00 00 01 ff ff ff ff ff 00 00 00 03 > ranges -- 30 : 00 00 00 10 00 00 00 00 02 00 18 10 00 > 00 00 00 00 00 00 00 01 00 00 00 00 00 00 14 00 00 00 00 01 00 18 14 00 > 00 00 00 00 00 00 00 00 00 40 00 > ok > 0 > cd su ok > 0 > .properties > name "su" > device_type "serial" > reg 00000014 000003f8 00000008 > interrupts 1 > ok > Okay, so the address of "su" actually is mapped to the I/O port space at the EBus bridge. Again that doesn't match any real machine but at least is consistent with the BAR setup QEMU employs on the PCI side. > > I wonder if the problem is the same as that in > https://reviews.freebsd.org/D2791 which is that some assumptions about > the device tree are hard-coded rather than being read and/or calculated > from the PROM properties? > The first generations of PCI-based sun4u machines don't adhere to the IEEE 1754-1994 bus binding specifications (on the other hand, I only ever got draft versions of these so I've no idea whether they went final). E450 are worst in that regard, closely followed by Ultra30. To that matter, even the interpretation of the ranges property for the PCI-ISA-bridges found in PCI-Express-based sun4u machines still doesn't follow the relevant bus binding document. Thus, assuming the behavior of real hardware built by Fujitsu and Sun - which includes distrusting knowingly incorrect OFW properties in quite a few occasions - in sparc64 bus code rather than basing it on the OFW standards generally is sane. That said, later device-tree-related code in FreeBSD/sparc64 is rather generic and has quite a few heuristics, which made things work out-of-the box on several models we didn't have access to ourselves. Actually, in some cases FreeBSD performed even better than Linux, Net- and OpenBSD did in that regard, i. e. while these latter needed changes, FreeBSD required none. This also is why - apparently - the FreeBSD kernel manages to attach the 16550 of QEMU as low-level console device, although the BAR layout of the PCI-EBus-bridge doesn't match any real hardware. However, looking at ebus(4), I've spotted a bug in the conversion to NEW_PCIB. Interested parties might want to give the attached patch a try. That bug definitely can lead to the problem seen with QEMU, I'm not sure it's the only one in that regard, though; I'm fairly certain in this case there's no problem with interpreting the device-tree involved, given that the same code is used for ISA busses which - at least in reality - unlike EBus ones use I/O port instead of memory space for the resources of devices such as UARTs etc. There could be other spots not prepared for EBus devices suddenly requesting SYS_RES_IOPORT, too, though. Marius --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sparc64_NEW_PCIB.diff_fix" Index: ebus.c =================================================================== --- ebus.c (revision 287726) +++ ebus.c (working copy) @@ -69,7 +69,6 @@ __FBSDID("$FreeBSD$"); #include #include #include - #include #include @@ -507,7 +506,7 @@ ebus_activate_resource(device_t bus, device_t chil int i, rv; sc = device_get_softc(bus); - if ((sc->sc_flags & EBUS_PCI) != 0 && type == SYS_RES_MEMORY) { + if ((sc->sc_flags & EBUS_PCI) != 0 && type != SYS_RES_IRQ) { for (i = 0; i < sc->sc_nrange; i++) { eri = &sc->sc_rinfo[i]; if (rman_is_region_manager(res, &eri->eri_rman) != 0) { @@ -550,7 +549,7 @@ ebus_release_resource(device_t bus, device_t child passthrough = (device_get_parent(child) != bus); rl = BUS_GET_RESOURCE_LIST(bus, child); sc = device_get_softc(bus); - if ((sc->sc_flags & EBUS_PCI) != 0 && type == SYS_RES_MEMORY) { + if ((sc->sc_flags & EBUS_PCI) != 0 && type != SYS_RES_IRQ) { if ((rman_get_flags(res) & RF_ACTIVE) != 0 ){ rv = bus_deactivate_resource(child, type, rid, res); if (rv != 0) --3MwIy2ne0vdjdPXF-- From owner-freebsd-sparc64@freebsd.org Sun Sep 13 02:39:20 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E32F69CA33D for ; Sun, 13 Sep 2015 02:39:19 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8590513C8; Sun, 13 Sep 2015 02:39:19 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8D2dH75008534 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Sep 2015 04:39:17 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8D2dG56008533; Sun, 13 Sep 2015 04:39:16 +0200 (CEST) (envelope-from marius) Date: Sun, 13 Sep 2015 04:39:16 +0200 From: Marius Strobl To: Mark Cave-Ayland Cc: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150913023916.GB7862@alchemy.franken.de> References: <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <55EC3949.1020508@ilande.co.uk> <20150906134245.GA21410@FreeBSD.org> <55EC4C43.9050700@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55EC4C43.9050700@ilande.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 13 Sep 2015 04:39:17 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 02:39:20 -0000 On Sun, Sep 06, 2015 at 03:22:59PM +0100, Mark Cave-Ayland wrote: > On 06/09/15 14:42, Alexey Dokuchaev wrote: > > > On Sun, Sep 06, 2015 at 02:02:01PM +0100, Mark Cave-Ayland wrote: > >> I wonder if the problem is just that suitable console drivers can't > >> be found? > >> > >>> ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) > >>> ebus0: addr 0x1400000060-0x1400000067 (no driver attached) > >> > >> The QEMU hardware model is still a WIP and the serial port currently > >> uses a 16550A UART (su) device rather than ESCC found in real hardware, > >> while the keyboard is a simple PS2 keyboard. > >> > >> If you alter your kernel configuration to include building of the su and > >> ps2 driver modules, does this help with detection of the serial and > >> keyboard devices and if so, does boot progress any further at all? > > > > Hmm, I'm running GENERIC, so it looks like everything should be already > > there, no? At least by looking at ./conf/files.sparc64 I don't see what > > else ("device ???") should I add to it to get su/kb_ps2 support... > > I'm afraid I'm not really a BSD person, but a quick browse at the source > on github suggests you need these drivers: > > https://github.com/freebsd/freebsd/blob/master/sys/dev/uart/uart_bus_ebus.c > > https://github.com/freebsd/freebsd/blob/master/sys/dev/atkbdc/atkbdc_ebus.c > > It also looks like you'd need to hack atkbdc_ebus.c to allow "kb_ps2" as > a device name rather than just trying to match on "8042", although this > could potentially be fixed by renaming the device in OpenBIOS moving > forwards as long as it doesn't cause any regressions. > Simple renaming in OpenBIOS wouldn't be the right fix either and neither change would make things work. On real machines for PS/2 there's a "8042" node on the EBus and _beneath_ that "8042" node there's a "kb_ps2" as well as a "kdmouse" one. "8042" has _two_ _identical_ addresses assigned, which its children index via their "reg" properties. The interrupt also goes onto the "8042" node. See the example of a Sun AXe board below. *Please* emulate real machines with QEMU. This specifically also applies to ARM hardware. Marius Node 0xf008cf88: ebus interrupt-map: 00 00 00 14 00 38 03 f8 00 00 00 01 f0 08 a7 38 00 00 00 1c 00 00 00 14 00 30 00 60 00 00 00 01 f0 08 a7 38 00 00 00 29 00 00 00 14 00 30 00 60 00 00 00 02 f0 08 a7 38 00 00 00 2a 00 00 00 14 00 36 02 f8 00 00 00 01 f0 08 a7 38 00 00 00 1d 00 00 00 14 00 40 00 00 00 00 00 01 f0 08 a7 38 00 00 00 2b 00 00 00 14 00 34 02 78 00 00 00 01 f0 08 a7 38 00 00 00 22 00 00 00 14 00 72 40 00 00 00 00 01 f0 08 a7 38 00 00 00 25 00 00 00 14 00 30 00 2e 00 00 00 01 f0 08 a7 38 00 00 00 04 00 00 00 14 00 32 03 f0 00 00 00 01 f0 08 a7 38 00 00 00 27 00 00 00 14 00 20 00 00 00 00 00 01 f0 08 a7 38 00 00 00 23 00 00 00 14 00 20 00 00 00 00 00 02 f0 08 a7 38 00 00 00 24 00 00 00 14 00 60 00 00 00 00 00 01 f0 08 a7 38 00 00 00 28 00 00 00 14 00 60 00 00 00 00 00 02 f0 08 a7 38 00 00 00 1e 00 00 00 14 00 60 00 00 00 00 00 03 f0 08 a7 38 00 00 00 1f interrupt-map-mask: 00 00 00 1f 00 ff ff ff 00 00 00 03 #interrupt-cells: 00 00 00 01 ranges: 00 00 00 10 00 00 00 00 82 01 08 10 00 00 00 00 f0 00 00 00 01 00 00 00 00 00 00 14 00 00 00 00 82 01 08 14 00 00 00 00 f1 00 00 00 00 80 00 00 reg: 00 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 01 08 10 00 00 00 00 f0 00 00 00 00 00 00 00 01 00 00 00 82 01 08 14 00 00 00 00 f1 00 00 00 00 00 00 00 00 80 00 00 #size-cells: 00 00 00 01 #address-cells: 00 00 00 02 name: 65 62 75 73 00 'ebus' max-latency: 00 00 00 19 min-grant: 00 00 00 0a class-code: 00 06 80 00 revision-id: 00 00 00 01 devsel-speed: 00 00 00 01 fast-back-to-back: device-id: 00 00 10 00 vendor-id: 00 00 10 8e <...> Node 0xf008fb5c: 8042 interrupts: 00 00 00 01 00 00 00 02 #size-cells: 00 00 00 00 #address-cells: 00 00 00 01 reg: 00 00 00 14 00 30 00 60 00 00 00 08 00 00 00 14 00 30 00 60 00 00 00 08 device_type: 38 30 34 32 00 '8042' name: 38 30 34 32 00 '8042' model: 49 4e 54 43 2c 38 30 63 34 32 00 'INTC,80c42' Node 0xf00909a4: kb_ps2 reg: 00 00 00 00 language: 65 6e 00 'en' compatible: 70 6e 70 50 4e 50 2c 33 30 33 00 'pnpPNP,303' port-b-ignore-cd: port-a-ignore-cd: keyboard: device_type: 73 65 72 69 61 6c 00 'serial' name: 6b 62 5f 70 73 32 00 'kb_ps2' Node 0xf009314c: kdmouse reg: 00 00 00 01 compatible: 70 6e 70 50 4e 50 2c 66 30 33 00 'pnpPNP,f03' port-b-ignore-cd: port-a-ignore-cd: mouse: device_type: 73 65 72 69 61 6c 00 'serial' name: 6b 64 6d 6f 75 73 65 00 'kdmouse' From owner-freebsd-sparc64@freebsd.org Sun Sep 13 10:39:41 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BE409CD4C8 for ; Sun, 13 Sep 2015 10:39:41 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0C11E1E82; Sun, 13 Sep 2015 10:39:41 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 0AD301BE4; Sun, 13 Sep 2015 10:39:41 +0000 (UTC) Date: Sun, 13 Sep 2015 10:39:41 +0000 From: Alexey Dokuchaev To: Marius Strobl Cc: Mark Cave-Ayland , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150913103940.GA60101@FreeBSD.org> References: <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150913022143.GA7862@alchemy.franken.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 10:39:41 -0000 On Sun, Sep 13, 2015 at 04:21:43AM +0200, Marius Strobl wrote: > However, looking at ebus(4), I've spotted a bug in the conversion > to NEW_PCIB. Interested parties might want to give the attached > patch a try. That bug definitely can lead to the problem seen with > QEMU, I'm not sure it's the only one in that regard, though; I'm > fairly certain in this case there's no problem with interpreting > the device-tree involved, given that the same code is used for > ISA busses which - at least in reality - unlike EBus ones use > I/O port instead of memory space for the resources of devices > such as UARTs etc. There could be other spots not prepared for > EBus devices suddenly requesting SYS_RES_IOPORT, too, though. I've applied that patch, but it alone is not enough to allow the boot to proceed further in QEMU. :( As Mark had mentioned, I will try to get some debug info and share it if I find anything interesting. ./danfe From owner-freebsd-sparc64@freebsd.org Sun Sep 13 17:36:54 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36456A037E4 for ; Sun, 13 Sep 2015 17:36:54 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C10DC1A3A; Sun, 13 Sep 2015 17:36:52 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZbBCi-0001Lw-0J; Sun, 13 Sep 2015 18:36:43 +0100 Message-ID: <55F5B41F.7060903@ilande.co.uk> Date: Sun, 13 Sep 2015 18:36:31 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <557D82F8.50908@ilande.co.uk> <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> In-Reply-To: <20150913022143.GA7862@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 17:36:54 -0000 On 13/09/15 03:21, Marius Strobl wrote: >>> That's already unusual; real PCI-EBus-bridges have two memory >>> BARs (although children may use I/O ports which are translated >>> to memory resources upstream) rather than an I/O port and a >>> memory one. However, the above actually should also work code- >>> wise, iff the resource types are encoded correctly in the ranges >>> table. >> >> While the QEMU PCI-ebus properties don't necessarily reflect a real >> ultra2 > > You probably mean Ultra5/10 here; Ultra2 are SBus- rather than PCI- > based. Still, the machine QEMU emualtes only looks similar to a > real Ultra5/10 from a 10 km distance ... Ooops, yes. >> , they should be consistent in terms of ranges as several patches >> along those lines were required to enable NetBSD and OpenBSD to boot >> under qemu-system-sparc64. For reference I've included the properties >> from OpenBIOS below: >> >> >> 0 > cd /pci/ ok >> 0 > .properties >> name "pci" >> reg 000001fe 00000000 00000000 02000000 >> vendor-id 108e >> device-id a000 >> revision-id 0 >> class-code 60000 >> min-grant 0 >> max-latency 0 >> devsel-speed 0 >> fast-back-to-back >> 66mhz-capable >> subsystem-vendor-id 1af4 >> subsystem-id 1100 >> cache-line-size 0 >> device_type "pci" >> model "SUNW,sabre" >> compatible {"pci108e,a000", "pciclass,0"} >> #address-cells 3 >> #size-cells 2 >> #interrupt-cells 1 >> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 00 00 00 >> 00 00 00 00 10 00 00 00 00 01 ff 00 10 00 00 00 00 00 00 10 00 00 00 >> virtual-dma -- 8 : c0 00 00 00 20 00 00 00 >> #virtual-dma-size-cells 1 >> #virtual-dma-addr-cells 1 >> no-streaming-cache >> interrupts -- 10 : 00 00 07 f0 00 00 07 ee 00 00 07 ef 00 >> 00 07 e5 >> upa-portid 1f >> bus-range -- 8 : 00 00 00 00 00 00 00 02 >> available -- 28 : 02 00 00 00 00 00 00 00 04 04 00 00 00 >> 00 00 00 0b fc 00 00 01 00 00 00 00 00 00 00 00 00 83 80 00 00 00 00 00 >> 00 7c 80 >> interrupt-map -- 30 : 00 00 20 00 00 00 00 00 00 00 00 00 00 >> 00 00 01 ff e2 b7 40 00 00 00 10 00 00 28 00 00 00 00 00 00 00 00 00 00 >> 00 00 01 ff e2 b7 40 00 00 00 14 >> interrupt-map-mask -- 10 : 00 00 f8 00 00 00 00 00 00 00 00 00 00 >> 00 00 07 >> ok >> 0 > cd ebus ok >> 0 > .properties >> name "ebus" >> vendor-id 108e >> device-id 1000 >> revision-id 1 >> class-code 68000 >> min-grant 0 >> max-latency 0 >> devsel-speed 0 >> fast-back-to-back >> 66mhz-capable >> subsystem-vendor-id 1af4 >> subsystem-id 1100 >> cache-line-size a00 >> model "ebus" >> compatible {"pci108e,1000", "pciclass,068000"} >> #address-cells 2 >> #size-cells 1 >> #interrupt-cells 1 >> assigned-addresses -- 28 : 02 00 18 10 00 00 00 00 03 00 00 00 00 >> 00 00 00 01 00 00 00 01 00 18 14 00 00 00 00 00 00 40 00 00 00 00 00 00 >> 00 40 00 >> reg 00001800 00000000 00000000 00000000 00000000 >> 02001810 00000000 00000000 00000000 01000000 >> 01001814 00000000 00000000 00000000 00004000 >> interrupt-map -- 14 : 00 00 00 14 00 00 03 f8 00 00 00 01 ff >> e1 b9 48 00 00 00 2b >> interrupt-map-mask -- c : 00 00 01 ff ff ff ff ff 00 00 00 03 >> ranges -- 30 : 00 00 00 10 00 00 00 00 02 00 18 10 00 >> 00 00 00 00 00 00 00 01 00 00 00 00 00 00 14 00 00 00 00 01 00 18 14 00 >> 00 00 00 00 00 00 00 00 00 40 00 >> ok >> 0 > cd su ok >> 0 > .properties >> name "su" >> device_type "serial" >> reg 00000014 000003f8 00000008 >> interrupts 1 >> ok >> > > Okay, so the address of "su" actually is mapped to the I/O port space > at the EBus bridge. Again that doesn't match any real machine but at > least is consistent with the BAR setup QEMU employs on the PCI side. Yes. It's to do with the way that OpenBIOS expects to access ioport X at base + X which doesn't sit too well with the PCI-EBus bridge; at least it would require some terrific special case hacks to get this working correctly. >> I wonder if the problem is the same as that in >> https://reviews.freebsd.org/D2791 which is that some assumptions about >> the device tree are hard-coded rather than being read and/or calculated >> from the PROM properties? >> > > The first generations of PCI-based sun4u machines don't adhere to > the IEEE 1754-1994 bus binding specifications (on the other hand, > I only ever got draft versions of these so I've no idea whether > they went final). E450 are worst in that regard, closely followed > by Ultra30. To that matter, even the interpretation of the ranges > property for the PCI-ISA-bridges found in PCI-Express-based sun4u > machines still doesn't follow the relevant bus binding document. > Thus, assuming the behavior of real hardware built by Fujitsu and > Sun - which includes distrusting knowingly incorrect OFW properties > in quite a few occasions - in sparc64 bus code rather than basing > it on the OFW standards generally is sane. > That said, later device-tree-related code in FreeBSD/sparc64 is > rather generic and has quite a few heuristics, which made things > work out-of-the box on several models we didn't have access to > ourselves. Actually, in some cases FreeBSD performed even better > than Linux, Net- and OpenBSD did in that regard, i. e. while these > latter needed changes, FreeBSD required none. This also is why - > apparently - the FreeBSD kernel manages to attach the 16550 of > QEMU as low-level console device, although the BAR layout of the > PCI-EBus-bridge doesn't match any real hardware. Whilst working with other OSs, what tends to happen is that the basic kernel output gets sent via prom_printf() or similar which means that you see the output fine until you switch to userspace and your console driver kicks in. Now that may not be the case for FreeBSD but that's why I'm keen to get the ebus device attach working first to eliminate this as a possibility. > However, looking at ebus(4), I've spotted a bug in the conversion > to NEW_PCIB. Interested parties might want to give the attached > patch a try. That bug definitely can lead to the problem seen with > QEMU, I'm not sure it's the only one in that regard, though; I'm > fairly certain in this case there's no problem with interpreting > the device-tree involved, given that the same code is used for > ISA busses which - at least in reality - unlike EBus ones use > I/O port instead of memory space for the resources of devices > such as UARTs etc. There could be other spots not prepared for > EBus devices suddenly requesting SYS_RES_IOPORT, too, though. Thank you! I'm the process of clearing out space to set everything up so I would hope to be in place to start looking at this again in a couple of weeks. ATB, Mark. From owner-freebsd-sparc64@freebsd.org Sun Sep 13 17:46:23 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16CD0A03C03 for ; Sun, 13 Sep 2015 17:46:23 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFD4F1D22; Sun, 13 Sep 2015 17:46:22 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZbBM1-0001Ni-Af; Sun, 13 Sep 2015 18:46:20 +0100 Message-ID: <55F5B660.5050904@ilande.co.uk> Date: Sun, 13 Sep 2015 18:46:08 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <55EC3949.1020508@ilande.co.uk> <20150906134245.GA21410@FreeBSD.org> <55EC4C43.9050700@ilande.co.uk> <20150913023916.GB7862@alchemy.franken.de> In-Reply-To: <20150913023916.GB7862@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 17:46:23 -0000 On 13/09/15 03:39, Marius Strobl wrote: > On Sun, Sep 06, 2015 at 03:22:59PM +0100, Mark Cave-Ayland wrote: >> On 06/09/15 14:42, Alexey Dokuchaev wrote: >> >>> On Sun, Sep 06, 2015 at 02:02:01PM +0100, Mark Cave-Ayland wrote: >>>> I wonder if the problem is just that suitable console drivers can't >>>> be found? >>>> >>>>> ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) >>>>> ebus0: addr 0x1400000060-0x1400000067 (no driver attached) >>>> >>>> The QEMU hardware model is still a WIP and the serial port currently >>>> uses a 16550A UART (su) device rather than ESCC found in real hardware, >>>> while the keyboard is a simple PS2 keyboard. >>>> >>>> If you alter your kernel configuration to include building of the su and >>>> ps2 driver modules, does this help with detection of the serial and >>>> keyboard devices and if so, does boot progress any further at all? >>> >>> Hmm, I'm running GENERIC, so it looks like everything should be already >>> there, no? At least by looking at ./conf/files.sparc64 I don't see what >>> else ("device ???") should I add to it to get su/kb_ps2 support... >> >> I'm afraid I'm not really a BSD person, but a quick browse at the source >> on github suggests you need these drivers: >> >> https://github.com/freebsd/freebsd/blob/master/sys/dev/uart/uart_bus_ebus.c >> >> https://github.com/freebsd/freebsd/blob/master/sys/dev/atkbdc/atkbdc_ebus.c >> >> It also looks like you'd need to hack atkbdc_ebus.c to allow "kb_ps2" as >> a device name rather than just trying to match on "8042", although this >> could potentially be fixed by renaming the device in OpenBIOS moving >> forwards as long as it doesn't cause any regressions. >> > > Simple renaming in OpenBIOS wouldn't be the right fix either and neither > change would make things work. > On real machines for PS/2 there's a "8042" node on the EBus and _beneath_ > that "8042" node there's a "kb_ps2" as well as a "kdmouse" one. "8042" > has _two_ _identical_ addresses assigned, which its children index via > their "reg" properties. The interrupt also goes onto the "8042" node. > See the example of a Sun AXe board below. > > *Please* emulate real machines with QEMU. This specifically also applies > to ARM hardware. Well if there was enough time and people working on this... :) Interest in SPARC appears to have dropped significantly since the switch to Oracle so the work I do is limited to the available spare time. Currently the PS/2 keyboard/mouse code is I believe based on old PReP code, but I agree looking at this that the existing model is wrong - I'll go away and get this fixed ASAP. Longer term it may be that switching to an ESCC serial port would be a better option here. The sad part is that complete emulation is unlikely to be obtainable, for example the code required for just a complete implementation of an ATI Rage card with its hardware acceleration would be fairly substantial. ATB, Mark. From owner-freebsd-sparc64@freebsd.org Sun Sep 13 17:47:37 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20852A03C5A for ; Sun, 13 Sep 2015 17:47:37 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB94D1D50; Sun, 13 Sep 2015 17:47:36 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZbBNC-0001O6-T8; Sun, 13 Sep 2015 18:47:34 +0100 Message-ID: <55F5B6AA.8050302@ilande.co.uk> Date: Sun, 13 Sep 2015 18:47:22 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Alexey Dokuchaev , Marius Strobl CC: "freebsd-sparc64@freebsd.org" References: <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> In-Reply-To: <20150913103940.GA60101@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 17:47:37 -0000 On 13/09/15 11:39, Alexey Dokuchaev wrote: > On Sun, Sep 13, 2015 at 04:21:43AM +0200, Marius Strobl wrote: >> However, looking at ebus(4), I've spotted a bug in the conversion >> to NEW_PCIB. Interested parties might want to give the attached >> patch a try. That bug definitely can lead to the problem seen with >> QEMU, I'm not sure it's the only one in that regard, though; I'm >> fairly certain in this case there's no problem with interpreting >> the device-tree involved, given that the same code is used for >> ISA busses which - at least in reality - unlike EBus ones use >> I/O port instead of memory space for the resources of devices >> such as UARTs etc. There could be other spots not prepared for >> EBus devices suddenly requesting SYS_RES_IOPORT, too, though. > > I've applied that patch, but it alone is not enough to allow the boot > to proceed further in QEMU. :( How sad :( > As Mark had mentioned, I will try to get some debug info and share > it if I find anything interesting. Yes please. Once the ebus attach is sorted then hopefully things will start to become a bit clearer... ATB, Mark. From owner-freebsd-sparc64@freebsd.org Sun Sep 13 18:01:31 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A54B9A03523 for ; Sun, 13 Sep 2015 18:01:31 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5FC1778; Sun, 13 Sep 2015 18:01:30 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8DI1QhR011243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Sep 2015 20:01:26 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8DI1QEU011242; Sun, 13 Sep 2015 20:01:26 +0200 (CEST) (envelope-from marius) Date: Sun, 13 Sep 2015 20:01:26 +0200 From: Marius Strobl To: Alexey Dokuchaev Cc: "freebsd-sparc64@freebsd.org" , Mark Cave-Ayland Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150913180126.GC7862@alchemy.franken.de> References: <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150913103940.GA60101@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 13 Sep 2015 20:01:26 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 18:01:31 -0000 On Sun, Sep 13, 2015 at 10:39:41AM +0000, Alexey Dokuchaev wrote: > On Sun, Sep 13, 2015 at 04:21:43AM +0200, Marius Strobl wrote: > > However, looking at ebus(4), I've spotted a bug in the conversion > > to NEW_PCIB. Interested parties might want to give the attached > > patch a try. That bug definitely can lead to the problem seen with > > QEMU, I'm not sure it's the only one in that regard, though; I'm > > fairly certain in this case there's no problem with interpreting > > the device-tree involved, given that the same code is used for > > ISA busses which - at least in reality - unlike EBus ones use > > I/O port instead of memory space for the resources of devices > > such as UARTs etc. There could be other spots not prepared for > > EBus devices suddenly requesting SYS_RES_IOPORT, too, though. > > I've applied that patch, but it alone is not enough to allow the boot > to proceed further in QEMU. :( > Err, right, on a second look the bug I thought existed in ebus(4) actually isn't there; its code I added as part of the conversion to NEW_PCIB is just a bit unclean/unobvious but in fact does the right thing, even if a child resource would map to SYS_RES_IOPORT. However, I noticed that the cause of failure likely is a bug in the "ranges" property of the QEMU EBus bridge. The following is an example from a T1-AC200 demonstrating how a correct setup looks like: ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at device 12.0 on pci1 child_hi child_lo phys_hi phys_mid phys_lo size 00000010 00000000 82016010 00000000 f0000000 01000000 00000014 00000000 82016014 00000000 f1000000 00800000 When mapping EBus child resources, their adresses are translated to the address base specified by (phys_mid << 32) | phys_lo on the parent side, based on the range the child resource falls into (determined via child_hi, child_lo and size). For PCI-EBus- bridges, the parent address range further must [1, p. 113 f.] match the resources on the PCI side, i. e. the BARs. In the above case that's 0xf0000000 determined by (phys_mid << 32) | phys_lo and size 0x1000000 from the ranges property and mem 0xf0000000- 0xf0ffffff from the first BAR (see dmesg snippet) for example. With QEMU we get (based on the dump from Mark and your dmesg): ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at device 3.0 on pci0 child_hi child_lo phys_hi phys_mid phys_lo size 00000010 00000000 02001810 00000000 00000000 01000000 00000014 00000000 01001814 00000000 00000000 00004000 So here, the parent addresses don't match as for example 0x00000000 determined by (phys_mid << 32) | phys_lo doesn't match BAR 0, which is mem 0x3000000-0x3ffffff. Likewise for the second BAR and range combo. Sizes are correct, though. Note that according to the dump from Mark, the BARs of the PCI-EBus-bridge at least match its "assigned-addresses" property. So it might be as simple as fixing phys_mid and phys_lo in the device tree file shipping with OpenBIOS, iff such a thing exists and the device tree isn't assembled dynamically somehow. Marius 1: Peripheral Component Interconnect Input Output Controller, Part No.: 802-7837-01, Sun Microelectronics, March 1997 From owner-freebsd-sparc64@freebsd.org Tue Sep 15 22:15:30 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86AEC9C2C4D for ; Tue, 15 Sep 2015 22:15:30 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42F29107F; Tue, 15 Sep 2015 22:15:29 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZbyVD-0003hL-PJ; Tue, 15 Sep 2015 23:15:20 +0100 Message-ID: <55F89861.1030107@ilande.co.uk> Date: Tue, 15 Sep 2015 23:14:57 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl , Alexey Dokuchaev CC: "freebsd-sparc64@freebsd.org" References: <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> In-Reply-To: <20150913180126.GC7862@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:15:30 -0000 On 13/09/15 19:01, Marius Strobl wrote: > On Sun, Sep 13, 2015 at 10:39:41AM +0000, Alexey Dokuchaev wrote: >> On Sun, Sep 13, 2015 at 04:21:43AM +0200, Marius Strobl wrote: >>> However, looking at ebus(4), I've spotted a bug in the conversion >>> to NEW_PCIB. Interested parties might want to give the attached >>> patch a try. That bug definitely can lead to the problem seen with >>> QEMU, I'm not sure it's the only one in that regard, though; I'm >>> fairly certain in this case there's no problem with interpreting >>> the device-tree involved, given that the same code is used for >>> ISA busses which - at least in reality - unlike EBus ones use >>> I/O port instead of memory space for the resources of devices >>> such as UARTs etc. There could be other spots not prepared for >>> EBus devices suddenly requesting SYS_RES_IOPORT, too, though. >> >> I've applied that patch, but it alone is not enough to allow the boot >> to proceed further in QEMU. :( >> > > Err, right, on a second look the bug I thought existed in ebus(4) > actually isn't there; its code I added as part of the conversion > to NEW_PCIB is just a bit unclean/unobvious but in fact does the > right thing, even if a child resource would map to SYS_RES_IOPORT. > > However, I noticed that the cause of failure likely is a bug in > the "ranges" property of the QEMU EBus bridge. The following is > an example from a T1-AC200 demonstrating how a correct setup > looks like: > ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at device 12.0 on pci1 > child_hi child_lo phys_hi phys_mid phys_lo size > 00000010 00000000 82016010 00000000 f0000000 01000000 > 00000014 00000000 82016014 00000000 f1000000 00800000 > > When mapping EBus child resources, their adresses are translated > to the address base specified by (phys_mid << 32) | phys_lo on > the parent side, based on the range the child resource falls > into (determined via child_hi, child_lo and size). For PCI-EBus- > bridges, the parent address range further must [1, p. 113 f.] > match the resources on the PCI side, i. e. the BARs. In the above > case that's 0xf0000000 determined by (phys_mid << 32) | phys_lo > and size 0x1000000 from the ranges property and mem 0xf0000000- > 0xf0ffffff from the first BAR (see dmesg snippet) for example. > > With QEMU we get (based on the dump from Mark and your dmesg): > ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at device 3.0 on pci0 > child_hi child_lo phys_hi phys_mid phys_lo size > 00000010 00000000 02001810 00000000 00000000 01000000 > 00000014 00000000 01001814 00000000 00000000 00004000 > > So here, the parent addresses don't match as for example > 0x00000000 determined by (phys_mid << 32) | phys_lo doesn't > match BAR 0, which is mem 0x3000000-0x3ffffff. Likewise for > the second BAR and range combo. Sizes are correct, though. > > Note that according to the dump from Mark, the BARs of the > PCI-EBus-bridge at least match its "assigned-addresses" > property. So it might be as simple as fixing phys_mid and > phys_lo in the device tree file shipping with OpenBIOS, iff > such a thing exists and the device tree isn't assembled > dynamically somehow. Aha - I bet that's it. I've tweaked OpenBIOS to update phys_mid the same as "assigned-addresses" and that now gives me the following for /pci/ebus: 0 > cd /pci/ebus ok 0 > .properties name "ebus" vendor-id 108e device-id 1000 revision-id 1 class-code 68000 min-grant 0 max-latency 0 devsel-speed 0 fast-back-to-back 66mhz-capable subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size a00 model "ebus" compatible {"pci108e,1000", "pciclass,068000"} #address-cells 2 #size-cells 1 #interrupt-cells 1 assigned-addresses -- 28 : 02 00 18 10 00 00 00 00 03 00 00 00 00 00 00 00 01 00 00 00 01 00 18 14 00 00 00 00 00 00 40 00 00 00 00 00 00 00 40 00 reg 00001800 00000000 00000000 00000000 00000000 02001810 00000000 00000000 00000000 01000000 01001814 00000000 00000000 00000000 00004000 interrupt-map -- 14 : 00 00 00 14 00 00 03 f8 00 00 00 01 ff e1 b9 48 00 00 00 2b interrupt-map-mask -- c : 00 00 01 ff ff ff ff ff 00 00 00 03 ranges -- 30 : 00 00 00 10 00 00 00 00 02 00 18 10 00 00 00 00 03 00 00 00 01 00 00 00 00 00 00 14 00 00 00 00 01 00 18 14 00 00 00 00 00 00 40 00 00 00 40 00 ok Properly formatted, ranges now looks like this: 00000010 00000000 02001810 00000000 03000000 01000000 00000014 00000000 01001814 00000000 00004000 00004000 ...and in my tests here it doesn't appear to regress any of my test images. As I still don't have a FreeBSD environment setup yet, I've uploaded the binary to http://www.ilande.co.uk/tmp/openbios-sparc64 - if someone with QEMU 2.4 could replace openbios-sparc64 with the downloaded version and post a boot log in -nographic mode then that would be great. BTW does the comment on D2791 mean that it has been superseded by a new patch that has been committed to trunk? ATB, Mark. From owner-freebsd-sparc64@freebsd.org Wed Sep 16 03:10:30 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EC019CEDB9 for ; Wed, 16 Sep 2015 03:10:30 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6E41384; Wed, 16 Sep 2015 03:10:30 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 5E6871F1D; Wed, 16 Sep 2015 03:10:30 +0000 (UTC) Date: Wed, 16 Sep 2015 03:10:30 +0000 From: Alexey Dokuchaev To: Mark Cave-Ayland Cc: Marius Strobl , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150916031030.GA6711@FreeBSD.org> References: <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F89861.1030107@ilande.co.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 03:10:30 -0000 On Tue, Sep 15, 2015 at 11:14:57PM +0100, Mark Cave-Ayland wrote: > Aha - I bet that's it. I've tweaked OpenBIOS to update phys_mid the same > as "assigned-addresses" and that now gives me the following for /pci/ebus: > > [...] > Properly formatted, ranges now looks like this: > > 00000010 00000000 02001810 00000000 03000000 01000000 > 00000014 00000000 01001814 00000000 00004000 00004000 > > ...and in my tests here it doesn't appear to regress any of my test > images. As I still don't have a FreeBSD environment setup yet, I've > uploaded the binary to http://www.ilande.co.uk/tmp/openbios-sparc64 - if > someone with QEMU 2.4 could replace openbios-sparc64 with the downloaded > version and post a boot log in -nographic mode then that would be great. Log is identical to the one I posted earlier (modulo the build timestamps), except this part: eeprom0: addr 0x1400002000-0x1400003fff on ebus0 -eeprom0: cannot allocate resources -device_attach: eeprom0 attach returned 6 +eeprom0: model mk48t59 ebus0: addr 0 (no driver attached) -ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) +uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 +uart0: console (9600,n,8,1) ebus0: addr 0x1400000060-0x1400000067 (no driver attached) Kernel still hangs at the same place. > BTW does the comment on D2791 mean that it has been superseded by a new > patch that has been committed to trunk? Yes, it was committed as part of r287726. Because commit log did not have reference to D2791, it had to be closed/abandoned by hand. ./danfe From owner-freebsd-sparc64@freebsd.org Wed Sep 16 19:28:12 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BAFA9CE126 for ; Wed, 16 Sep 2015 19:28:12 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B73E51EFF; Wed, 16 Sep 2015 19:28:10 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZcIN9-0007vN-Qi; Wed, 16 Sep 2015 20:28:07 +0100 Message-ID: <55F9C2B8.7030605@ilande.co.uk> Date: Wed, 16 Sep 2015 20:27:52 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Alexey Dokuchaev CC: Marius Strobl , "freebsd-sparc64@freebsd.org" References: <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> In-Reply-To: <20150916031030.GA6711@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:28:12 -0000 On 16/09/15 04:10, Alexey Dokuchaev wrote: > On Tue, Sep 15, 2015 at 11:14:57PM +0100, Mark Cave-Ayland wrote: >> Aha - I bet that's it. I've tweaked OpenBIOS to update phys_mid the same >> as "assigned-addresses" and that now gives me the following for /pci/ebus: >> >> [...] >> Properly formatted, ranges now looks like this: >> >> 00000010 00000000 02001810 00000000 03000000 01000000 >> 00000014 00000000 01001814 00000000 00004000 00004000 >> >> ...and in my tests here it doesn't appear to regress any of my test >> images. As I still don't have a FreeBSD environment setup yet, I've >> uploaded the binary to http://www.ilande.co.uk/tmp/openbios-sparc64 - if >> someone with QEMU 2.4 could replace openbios-sparc64 with the downloaded >> version and post a boot log in -nographic mode then that would be great. > > Log is identical to the one I posted earlier (modulo the build timestamps), > except this part: > > eeprom0: addr 0x1400002000-0x1400003fff on ebus0 > -eeprom0: cannot allocate resources > -device_attach: eeprom0 attach returned 6 > +eeprom0: model mk48t59 > ebus0: addr 0 (no driver attached) > -ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) > +uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 > +uart0: console (9600,n,8,1) > ebus0: addr 0x1400000060-0x1400000067 (no driver attached) Well this is definitely progress - at least the ebus attach is now sorted :) I've sent the patch upstream (see http://www.openfirmware.info/pipermail/openbios/2015-September/008802.html) and will commit it soon if there are no objections. Next I'll see if I can get the 8042 part of the device tree correct in order to attach the PS/2 keyboard driver. > Kernel still hangs at the same place. Hmmm. Thinking back to when I was getting NetBSD/OpenBSD to work under QEMU then first things I would look at are: - Missing UPA/APB diagnostic register implementation from QEMU - Use of an ASI unimplemented/buggy in QEMU - Incorrect interrupt mapping/bug in APB emulation Is it possible to force entry into the kernel debugger on boot and get a backtrace during the hang to see what is happening? Also how does the boot log compare with a complete boot log - often looking at what the next line is on a complete boot log gives a hint as where things are going wrong. If you boot in normal (graphic) mode is there any output that appears there but not in -nographic mode? I also see that the output stops after "IPsec: Initialized Security Association Processing." appears on the console. Maybe the crypto uses paths that aren't well tested in QEMU or we are waiting for entrophy? Does disabling the IPsec module in the kernel help? >> BTW does the comment on D2791 mean that it has been superseded by a new >> patch that has been committed to trunk? > > Yes, it was committed as part of r287726. Because commit log did not have > reference to D2791, it had to be closed/abandoned by hand. Great! Thank you both for your help so far :) ATB, Mark. From owner-freebsd-sparc64@freebsd.org Wed Sep 16 21:19:25 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94E319C2673 for ; Wed, 16 Sep 2015 21:19:25 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CC891173; Wed, 16 Sep 2015 21:19:24 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8GLJFjO075899 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Sep 2015 23:19:15 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8GLJFTX075898; Wed, 16 Sep 2015 23:19:15 +0200 (CEST) (envelope-from marius) Date: Wed, 16 Sep 2015 23:19:15 +0200 From: Marius Strobl To: Mark Cave-Ayland Cc: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150916211914.GD18789@alchemy.franken.de> References: <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F9C2B8.7030605@ilande.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Wed, 16 Sep 2015 23:19:15 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 21:19:25 -0000 On Wed, Sep 16, 2015 at 08:27:52PM +0100, Mark Cave-Ayland wrote: > On 16/09/15 04:10, Alexey Dokuchaev wrote: > > > On Tue, Sep 15, 2015 at 11:14:57PM +0100, Mark Cave-Ayland wrote: > >> Aha - I bet that's it. I've tweaked OpenBIOS to update phys_mid the same > >> as "assigned-addresses" and that now gives me the following for /pci/ebus: > >> > >> [...] > >> Properly formatted, ranges now looks like this: > >> > >> 00000010 00000000 02001810 00000000 03000000 01000000 > >> 00000014 00000000 01001814 00000000 00004000 00004000 > >> > >> ...and in my tests here it doesn't appear to regress any of my test > >> images. As I still don't have a FreeBSD environment setup yet, I've > >> uploaded the binary to http://www.ilande.co.uk/tmp/openbios-sparc64 - if > >> someone with QEMU 2.4 could replace openbios-sparc64 with the downloaded > >> version and post a boot log in -nographic mode then that would be great. > > > > Log is identical to the one I posted earlier (modulo the build timestamps), > > except this part: > > > > eeprom0: addr 0x1400002000-0x1400003fff on ebus0 > > -eeprom0: cannot allocate resources > > -device_attach: eeprom0 attach returned 6 > > +eeprom0: model mk48t59 > > ebus0: addr 0 (no driver attached) > > -ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) > > +uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 > > +uart0: console (9600,n,8,1) > > ebus0: addr 0x1400000060-0x1400000067 (no driver attached) > > Well this is definitely progress - at least the ebus attach is now > sorted :) I've sent the patch upstream (see > http://www.openfirmware.info/pipermail/openbios/2015-September/008802.html) > and will commit it soon if there are no objections. > > Next I'll see if I can get the 8042 part of the device tree correct in > order to attach the PS/2 keyboard driver. > > > Kernel still hangs at the same place. > > Hmmm. Thinking back to when I was getting NetBSD/OpenBSD to work under > QEMU then first things I would look at are: > > - Missing UPA/APB diagnostic register implementation from QEMU > - Use of an ASI unimplemented/buggy in QEMU > - Incorrect interrupt mapping/bug in APB emulation Speaking of APB emulation, QEMU apparently cares about adding two APBs to the Sabre but there's nothing beneath them, i. e. all PCI devices hang off directly from the host-PCI-bridge. This cannot be in reality, hardware-wise. The QEMU topology shouldn't pose a problem for FreeBSD but I think some x11 part at least one point in time had the assumption the if there are APBs (aka Simbas), all PCI devices sit underneath them. Anyway, I'm mainly puzzled as to why that topology was chosen in QEMU. If there's a problem with emulating an entire PCI hierarchy, i. e. devices behind PCI-PCI- bridges, why not emulate a Hummingbird and get rid of the APBs altogether in the frist place? > Also how does the > boot log compare with a complete boot log - often looking at what the > next line is on a complete boot log gives a hint as where things are > going wrong. The next lines should be probe messages of the devices on the ATA controller, i. e. something like: cd0 at ata3 bus 0 scbus1 target 1 lun 0 cd0: Removable CD-ROM SCSI device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ada0 at ata3 bus 0 scbus1 target 0 lun 0 ada0: ATA-5 device ada0: Serial Number 3HS2QXLQ ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytes) ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 And then finally some "Trying to mount root from <...>" line. Which suggest that the next thing to investigate is the CMD646 emulation. Is there a particular reason why QEMU emulates a CMD646U rather than a plain CMD646 as found in the real sun4u machines of the USIIe/i era? Alexey, does building the port with CDROM_DMA disabled make a difference? I've also a gut feeling that interrupts are not working, otherwise there should be some timeout message if detection of ATA devices fails and finally a panic due to there being no source for mounting root (assuming the kernel doesn't hang before the enumeration of storage devices). Alexey, could you please try to drop into the debugger (apparently, ctrl-a b should bring you there with QEMU if you have compiled DDB into the kernel) and issue a `show intrcnt` (besides a backtrace)? Btw., is there a way to netboot with qemu-system-sparc64? It would help enormously not to build ISO images for testing but apparently at least `boot net:dhcp` isn't implemented in QEMU/OpenBIOS. > I also see that the output stops after "IPsec: Initialized Security > Association Processing." appears on the console. Maybe the crypto uses > paths that aren't well tested in QEMU or we are waiting for entrophy? Unlikely; "Initialized" means just that, the SA stuff has been set up. Also, given that IP isn't used at that point IPsec simply isn't either. Unblocking the random device in turn comes later, i. e. at least after storage devices have been probed. Marius From owner-freebsd-sparc64@freebsd.org Thu Sep 17 08:28:17 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C17A59C2F26 for ; Thu, 17 Sep 2015 08:28:17 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B207A19BC; Thu, 17 Sep 2015 08:28:17 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id B07C011DE; Thu, 17 Sep 2015 08:28:17 +0000 (UTC) Date: Thu, 17 Sep 2015 08:28:17 +0000 From: Alexey Dokuchaev To: Marius Strobl Cc: Mark Cave-Ayland , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150917082817.GA71811@FreeBSD.org> References: <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150916211914.GD18789@alchemy.franken.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 08:28:17 -0000 On Wed, Sep 16, 2015 at 11:19:15PM +0200, Marius Strobl wrote: > [...] > Which suggest that the next thing to investigate is the CMD646 > emulation. Is there a particular reason why QEMU emulates a > CMD646U rather than a plain CMD646 as found in the real sun4u > machines of the USIIe/i era? > > Alexey, does building the port with CDROM_DMA disabled make > a difference? Ironically I had it already disabled prior to your question; but I've rebuilt the port enabling it for completeness' sake. It did not make a difference. Then I've disabled all CAM/ATA stuff (scbus, ata, umass, etc.) in the kernel config and that's what I see now (this is with CDROM_DMA=on): cryptosoft0: on nexus0 nexus0: type unknown (no driver attached) Timecounter "tick" frequency 100000000 Hz quality 1000 Event timer "tick" frequency 100000000 Hz quality 1000 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. Trying to mount root from cd9660:/dev/iso9660/TEST [ro]... mountroot: waiting for device /dev/iso9660/TEST ... > Alexey, could you please try to drop into the debugger > (apparently, ctrl-a b should bring you there with QEMU if > you have compiled DDB into the kernel) and issue a `show > intrcnt` (besides a backtrace)? Not particularly interesting it seems: KDB: enter: Break to debugger [ thread pid 11 tid 100004 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db> bt Tracing pid 11 tid 100004 td 0xfffff80001287810 kdb_break() at kdb_break+0x54 uart_intr() at uart_intr+0x1e4 intr_event_handle() at intr_event_handle+0x68 intr_execute_handlers() at intr_execute_handlers+0x8 intr_fast() at intr_fast+0x50 -- interrupt level=0xb pil=0 %o7=0xc045be04 -- sched_idletd() at sched_idletd+0x3b4 fork_exit() at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 db> show intrcnt db> > On Wed, Sep 16, 2015 at 08:27:52PM +0100, Mark Cave-Ayland wrote: > > I also see that the output stops after "IPsec: Initialized Security > > Association Processing." appears on the console. Maybe the crypto uses > > paths that aren't well tested in QEMU or we are waiting for entrophy? > > Unlikely; "Initialized" means just that, the SA stuff has > been set up. Also, given that IP isn't used at that point > IPsec simply isn't either. Unblocking the random device > in turn comes later, i. e. at least after storage devices > have been probed. Marius' thinking is correct; in fact, I've tried to disable various "auxiliary" stuff earlier (including CRYPTO) and it did not make any difference. ./danfe From owner-freebsd-sparc64@freebsd.org Thu Sep 17 08:48:42 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 422EB9CE8C8 for ; Thu, 17 Sep 2015 08:48:42 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 32E101141; Thu, 17 Sep 2015 08:48:42 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 3115C1405; Thu, 17 Sep 2015 08:48:42 +0000 (UTC) Date: Thu, 17 Sep 2015 08:48:42 +0000 From: Alexey Dokuchaev To: Mark Cave-Ayland Cc: Marius Strobl , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150917084842.GA78467@FreeBSD.org> References: <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F9C2B8.7030605@ilande.co.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 08:48:42 -0000 On Wed, Sep 16, 2015 at 08:27:52PM +0100, Mark Cave-Ayland wrote: > [...] > Also how does the boot log compare with a complete boot log -- often > looking at what the next line is on a complete boot log gives a hint as > where things are going wrong. I've boot with boot_verbose=1; most of the new output looks unrelated. One extra line is printed after IPsec init message befor the hang: IPsec: Initialized Security Association Processing. lo0: bpf attached KDB: enter: Break to debugger [ thread pid 11 tid 100004 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db> show intrcnt pil11: filter 3 vec2027: uart0 3 db> Backtrace looks the same as in my previous email to Marius, yet there are some interrupts shown this time. ./danfe From owner-freebsd-sparc64@freebsd.org Fri Sep 18 06:53:22 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C0F19CDE91 for ; Fri, 18 Sep 2015 06:53:22 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18B1B12AA; Fri, 18 Sep 2015 06:53:20 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZcpXg-0006EM-8q; Fri, 18 Sep 2015 07:53:11 +0100 Message-ID: <55FBB4CB.5050108@ilande.co.uk> Date: Fri, 18 Sep 2015 07:52:59 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> In-Reply-To: <20150916211914.GD18789@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 06:53:22 -0000 On 16/09/15 22:19, Marius Strobl wrote: >> Hmmm. Thinking back to when I was getting NetBSD/OpenBSD to work under >> QEMU then first things I would look at are: >> >> - Missing UPA/APB diagnostic register implementation from QEMU >> - Use of an ASI unimplemented/buggy in QEMU >> - Incorrect interrupt mapping/bug in APB emulation > > Speaking of APB emulation, QEMU apparently cares about adding two > APBs to the Sabre but there's nothing beneath them, i. e. all PCI > devices hang off directly from the host-PCI-bridge. This cannot > be in reality, hardware-wise. The QEMU topology shouldn't pose a > problem for FreeBSD but I think some x11 part at least one point > in time had the assumption the if there are APBs (aka Simbas), all > PCI devices sit underneath them. Anyway, I'm mainly puzzled as to > why that topology was chosen in QEMU. If there's a problem with > emulating an entire PCI hierarchy, i. e. devices behind PCI-PCI- > bridges, why not emulate a Hummingbird and get rid of the APBs > altogether in the frist place? This goes back to before my time with OpenBIOS/QEMU but my understanding is that there was a bug in either the QEMU or OpenBIOS PCI bridge code that made it impossible to enumerate devices behind the bridge at the time when the original code was added. There is probably a good chance that things have changed here, however I'd like to get the basic emulation working first before making changes to the model (e.g. creating a virtual hme device). My eventual aim is to be able to run Solaris in -nographic mode for 64-bit SPARC. >> Also how does the >> boot log compare with a complete boot log - often looking at what the >> next line is on a complete boot log gives a hint as where things are >> going wrong. > > The next lines should be probe messages of the devices on the > ATA controller, i. e. something like: > cd0 at ata3 bus 0 scbus1 target 1 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > ada0 at ata3 bus 0 scbus1 target 0 lun 0 > ada0: ATA-5 device > ada0: Serial Number 3HS2QXLQ > ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytes) > ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > > And then finally some "Trying to mount root from <...>" line. > > Which suggest that the next thing to investigate is the CMD646 > emulation. Is there a particular reason why QEMU emulates a > CMD646U rather than a plain CMD646 as found in the real sun4u > machines of the USIIe/i era? Mainly because that device is already available in QEMU. From what I've seen in various driver sources the plain CMD646 is extremely buggy for DMA and everyone just gives up and disables it ;) > Alexey, does building the port with CDROM_DMA disabled make > a difference? > > I've also a gut feeling that interrupts are not working, > otherwise there should be some timeout message if detection > of ATA devices fails and finally a panic due to there being > no source for mounting root (assuming the kernel doesn't > hang before the enumeration of storage devices). > Alexey, could you please try to drop into the debugger > (apparently, ctrl-a b should bring you there with QEMU if > you have compiled DDB into the kernel) and issue a `show > intrcnt` (besides a backtrace)? That's interesting. I've already upstreamed some fixes for CMD646 interrupts in order to get NetBSD/OpenBSD to work. The short version is that the interrupt acknowledge bits are mirrored between the CMD646 BMDMA and standard registers, and previously QEMU handled them separately. What was happening was that the interrupt would be cleared by writing to one register but without the mirror the BMDMA would hang as its interrupt bit was still asserted. I have had reports that disk I/O hangs under high load on fast machines but it's not something I can reproduce here. With some investigation, I found that the logic in the emulated APB interrupt code isn't quite right but haven't had a chance to come up with a better solution. I do have a better (but still wrong) patch for QEMU if anyone is interested to see if that gets things moving along further. > Btw., is there a way to netboot with qemu-system-sparc64? > It would help enormously not to build ISO images for > testing but apparently at least `boot net:dhcp` isn't > implemented in QEMU/OpenBIOS. Unfortunately OpenBIOS doesn't have an IP stack included (yet?). For testing Linux kernels there are -kernel and -initrd parameters that simply copy the ELF image into the virtual machine RAM and set the PC to the entry address on startup. I'm not sure there is an equivalent for the *BSD ABI though. >> I also see that the output stops after "IPsec: Initialized Security >> Association Processing." appears on the console. Maybe the crypto uses >> paths that aren't well tested in QEMU or we are waiting for entrophy? > > Unlikely; "Initialized" means just that, the SA stuff has > been set up. Also, given that IP isn't used at that point > IPsec simply isn't either. Unblocking the random device > in turn comes later, i. e. at least after storage devices > have been probed. ATB, Mark. From owner-freebsd-sparc64@freebsd.org Fri Sep 18 06:57:09 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B79D79CE0CE for ; Fri, 18 Sep 2015 06:57:09 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 710FC15C2; Fri, 18 Sep 2015 06:57:09 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZcpbU-0006F6-56; Fri, 18 Sep 2015 07:57:07 +0100 Message-ID: <55FBB5B9.7020401@ilande.co.uk> Date: Fri, 18 Sep 2015 07:56:57 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> In-Reply-To: <20150916211914.GD18789@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 06:57:09 -0000 On 16/09/15 22:19, Marius Strobl wrote: >>> Log is identical to the one I posted earlier (modulo the build timestamps), >>> except this part: >>> >>> eeprom0: addr 0x1400002000-0x1400003fff on ebus0 >>> -eeprom0: cannot allocate resources >>> -device_attach: eeprom0 attach returned 6 >>> +eeprom0: model mk48t59 >>> ebus0: addr 0 (no driver attached) >>> -ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) >>> +uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 >>> +uart0: console (9600,n,8,1) >>> ebus0: addr 0x1400000060-0x1400000067 (no driver attached) >> >> Well this is definitely progress - at least the ebus attach is now >> sorted :) I've sent the patch upstream (see >> http://www.openfirmware.info/pipermail/openbios/2015-September/008802.html) >> and will commit it soon if there are no objections. >> >> Next I'll see if I can get the 8042 part of the device tree correct in >> order to attach the PS/2 keyboard driver. Last night I spent a few hours trying to fix up the device model for the keyboard device (whilst also inserting an 8042 node). The binary I have works for a NetBSD 7 ISO, although they have included a workaround for a missing interrupt-map property which I've also added in. I've updated the image at https://www.ilande.co.uk/tmp/openbios-sparc64 with these fixes if someone could test and confirm that FreeBSD now reports an attach of the kb_ps2 device. ATB, Mark. From owner-freebsd-sparc64@freebsd.org Fri Sep 18 06:59:57 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC71E9CE1BF for ; Fri, 18 Sep 2015 06:59:57 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA2A7161A; Fri, 18 Sep 2015 06:59:57 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZcpeC-0006Fk-JP; Fri, 18 Sep 2015 07:59:55 +0100 Message-ID: <55FBB662.4080708@ilande.co.uk> Date: Fri, 18 Sep 2015 07:59:46 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Alexey Dokuchaev , Marius Strobl CC: "freebsd-sparc64@freebsd.org" References: <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> In-Reply-To: <20150917082817.GA71811@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 06:59:58 -0000 On 17/09/15 09:28, Alexey Dokuchaev wrote: > On Wed, Sep 16, 2015 at 11:19:15PM +0200, Marius Strobl wrote: >> [...] >> Which suggest that the next thing to investigate is the CMD646 >> emulation. Is there a particular reason why QEMU emulates a >> CMD646U rather than a plain CMD646 as found in the real sun4u >> machines of the USIIe/i era? >> >> Alexey, does building the port with CDROM_DMA disabled make >> a difference? > > Ironically I had it already disabled prior to your question; but I've > rebuilt the port enabling it for completeness' sake. It did not make > a difference. > > Then I've disabled all CAM/ATA stuff (scbus, ata, umass, etc.) in the > kernel config and that's what I see now (this is with CDROM_DMA=on): What does the CAM/ATA stuff do here? Does this mean it may not necessarily be an interrupt issue if you can get to mounting the root fs with CDROM_DMA=on? ATB, Mark. From owner-freebsd-sparc64@freebsd.org Sat Sep 19 16:20:01 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 561509CFF34 for ; Sat, 19 Sep 2015 16:20:01 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4645B1C18; Sat, 19 Sep 2015 16:20:01 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 456551C54; Sat, 19 Sep 2015 16:20:01 +0000 (UTC) Date: Sat, 19 Sep 2015 16:20:01 +0000 From: Alexey Dokuchaev To: Mark Cave-Ayland Cc: Marius Strobl , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150919162001.GA8802@FreeBSD.org> References: <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FBB662.4080708@ilande.co.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 16:20:01 -0000 On Fri, Sep 18, 2015 at 07:59:46AM +0100, Mark Cave-Ayland wrote: > On 17/09/15 09:28, Alexey Dokuchaev wrote: > > Then I've disabled all CAM/ATA stuff (scbus, ata, umass, etc.) in the > > kernel config and that's what I see now (this is with CDROM_DMA=on): > > What does the CAM/ATA stuff do here? Does this mean it may not > necessarily be an interrupt issue if you can get to mounting the root fs > with CDROM_DMA=on? Well, I don't know. I've played a bit more with this: turns out that "ATA controllers" block has nothing to do with it, but when I disable scbus and depending stuff, it gets past the "IPsec: Initialized Security Association Processing." message and trying to mount root off CD (which fails for obvious reasons). Disabling "device cd" alone is not enough, FWIW. Since Marius mentioned earlier that is might be CMD646 vs. CMD646U emulation, I thought that commenting out "device cd" could give us a data point, but unfortunately not: looks like something is wrong with entire SCSI bus. ./danfe From owner-freebsd-sparc64@freebsd.org Sat Sep 19 19:49:18 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 838789CFF7B for ; Sat, 19 Sep 2015 19:49:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ED0831888; Sat, 19 Sep 2015 19:49:17 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8JJnFtg098544 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 19 Sep 2015 21:49:15 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8JJnFTZ098543; Sat, 19 Sep 2015 21:49:15 +0200 (CEST) (envelope-from marius) Date: Sat, 19 Sep 2015 21:49:15 +0200 From: Marius Strobl To: Mark Cave-Ayland Cc: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150919194915.GJ18789@alchemy.franken.de> References: <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <55FBB5B9.7020401@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FBB5B9.7020401@ilande.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sat, 19 Sep 2015 21:49:15 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 19:49:18 -0000 On Fri, Sep 18, 2015 at 07:56:57AM +0100, Mark Cave-Ayland wrote: > On 16/09/15 22:19, Marius Strobl wrote: > > >>> Log is identical to the one I posted earlier (modulo the build timestamps), > >>> except this part: > >>> > >>> eeprom0: addr 0x1400002000-0x1400003fff on ebus0 > >>> -eeprom0: cannot allocate resources > >>> -device_attach: eeprom0 attach returned 6 > >>> +eeprom0: model mk48t59 > >>> ebus0: addr 0 (no driver attached) > >>> -ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) > >>> +uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 > >>> +uart0: console (9600,n,8,1) > >>> ebus0: addr 0x1400000060-0x1400000067 (no driver attached) > >> > >> Well this is definitely progress - at least the ebus attach is now > >> sorted :) I've sent the patch upstream (see > >> http://www.openfirmware.info/pipermail/openbios/2015-September/008802.html) > >> and will commit it soon if there are no objections. > >> > >> Next I'll see if I can get the 8042 part of the device tree correct in > >> order to attach the PS/2 keyboard driver. > > Last night I spent a few hours trying to fix up the device model for the > keyboard device (whilst also inserting an 8042 node). The binary I have > works for a NetBSD 7 ISO, although they have included a workaround for a > missing interrupt-map property which I've also added in. > > I've updated the image at https://www.ilande.co.uk/tmp/openbios-sparc64 > with these fixes if someone could test and confirm that FreeBSD now > reports an attach of the kb_ps2 device. With that version OpenBIOS is getting better regarding the 8042 part but isn't quite there, yet. For atkbdc(4) to attach, besides "kb_ps2" there also needs to be the "kdmouse" node beneath the "8042" one and the latter must have a second address identical to the first one in its "reg" property. Marius From owner-freebsd-sparc64@freebsd.org Sat Sep 19 21:14:23 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82356A0550E for ; Sat, 19 Sep 2015 21:14:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 29D8F1D29; Sat, 19 Sep 2015 21:14:22 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8JLEKVP098758 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 19 Sep 2015 23:14:20 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8JLEKAx098757; Sat, 19 Sep 2015 23:14:20 +0200 (CEST) (envelope-from marius) Date: Sat, 19 Sep 2015 23:14:20 +0200 From: Marius Strobl To: Mark Cave-Ayland Cc: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150919211420.GK18789@alchemy.franken.de> References: <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FBB662.4080708@ilande.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sat, 19 Sep 2015 23:14:20 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 21:14:23 -0000 On Fri, Sep 18, 2015 at 07:59:46AM +0100, Mark Cave-Ayland wrote: > On 17/09/15 09:28, Alexey Dokuchaev wrote: > > > On Wed, Sep 16, 2015 at 11:19:15PM +0200, Marius Strobl wrote: > >> [...] > >> Which suggest that the next thing to investigate is the CMD646 > >> emulation. Is there a particular reason why QEMU emulates a > >> CMD646U rather than a plain CMD646 as found in the real sun4u > >> machines of the USIIe/i era? > >> > >> Alexey, does building the port with CDROM_DMA disabled make > >> a difference? > > > > Ironically I had it already disabled prior to your question; but I've > > rebuilt the port enabling it for completeness' sake. It did not make > > a difference. > > > > Then I've disabled all CAM/ATA stuff (scbus, ata, umass, etc.) in the > > kernel config and that's what I see now (this is with CDROM_DMA=on): > > What does the CAM/ATA stuff do here? Does this mean it may not > necessarily be an interrupt issue if you can get to mounting the root fs > with CDROM_DMA=on? I think we are looking at multiple issues here. First off, based on the interrupt-map provided by OpenBIOS, we route the intpin of the ATA controller to INO 20 (which uses the interrupt mapping register at offset 0xc28). If I additionally enable the code for debugging interrupt routing problems, which just clears all interrupts handle by the Sabre and then in all its interrupt mapping registers enables all INOs by writing the valid bit, Sabre IGN and CPU module ID there, I see 5 interrupts for INO 20 at the time the kernel hangs under QEMU. I don't get any stray interrupts for INOs that we're not actively routing. Based on what Alexey wrote, he doesn't see interrupts for INO 20, i. e. the ATA controller, with a kernel not including the debug code. That doesn't make sense to me. Without the debug code, we still enable the INOs for which drivers request them when they attach to devices the same way as described above, just not unconditionally for all interrupts handle by the Sabre. So there should be no difference for correctly routed interrupts. Second, even when I see interrupts for the ATA controller, enumeration of storage devices hangs somehow. On a real machine when booting verbose, this looks like (mainly output from ata_generic_reset(): <...> IPsec: Initialized Security Association Processing. lo0: bpf attached ata2: reset tp1 mask=00 ostat0=ff ostat1=ff ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: reset tp2 stat0=50 stat1=00 devices=0x20001 GEOM: new disk cd0 cd0 at ata3 bus 0 scbus1 target 1 lun 0 cd0: Removable CD-ROM SCSI device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present <...> With QEMU: <...> IPsec: Initialized Security Association Processing. lo0: bpf attached ata2: reset tp1 mask=03 ostat0=00 ostat1=00 ata2: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=00 stat1=00 devices=0x0 ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x00 err=0x00 lsb=0xff msb=0xff ata3: reset tp2 stat0=00 stat1=00 devices=0x10000 <...> db> show intrcnt pil3: ithrd 5 vec2004: atapci0 5 QEMU: Terminated <...> So after a reset, real iron additionally sets the READY and SERVICE bits in the ATA status register but that doesn't explain the hang. Code that is waiting for READY to get set also uses a timeout. I patched QEMU to identify the ATA controller as a plain CMD646 one so the UDMA isn't tried in the first place. I also limited the ATA mode used by the kernel to PIO4 at maximum. Neither made a difference, i. e. the hang still occurs. Another striking thing is that the interrupt statistics show to CPU tick interrupts. I'm unsure at which point the kernel actually enables them but they really should have been engaged at the time the hang occurs, otherwise scheduling won't work properly, which also might be an explanation for the hang, i. e. the kernel might never switch to the CAM thread(s). All in all, interrupts in QEMU seem buggy in one way or another. Marius From owner-freebsd-sparc64@freebsd.org Sat Sep 19 22:38:30 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86A08A059DC for ; Sat, 19 Sep 2015 22:38:30 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4412C1B2C; Sat, 19 Sep 2015 22:38:29 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from cpc2-slam8-2-0-cust642.2-4.cable.virginm.net ([82.24.206.131] helo=[192.168.0.5]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZdQlt-0004bs-OO; Sat, 19 Sep 2015 23:38:20 +0100 Message-ID: <55FDE3CA.2030707@ilande.co.uk> Date: Sat, 19 Sep 2015 23:38:02 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <55FBB5B9.7020401@ilande.co.uk> <20150919194915.GJ18789@alchemy.franken.de> In-Reply-To: <20150919194915.GJ18789@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 82.24.206.131 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 22:38:30 -0000 On 19/09/15 20:49, Marius Strobl wrote: > On Fri, Sep 18, 2015 at 07:56:57AM +0100, Mark Cave-Ayland wrote: >> On 16/09/15 22:19, Marius Strobl wrote: >> >>>>> Log is identical to the one I posted earlier (modulo the build timestamps), >>>>> except this part: >>>>> >>>>> eeprom0: addr 0x1400002000-0x1400003fff on ebus0 >>>>> -eeprom0: cannot allocate resources >>>>> -device_attach: eeprom0 attach returned 6 >>>>> +eeprom0: model mk48t59 >>>>> ebus0: addr 0 (no driver attached) >>>>> -ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) >>>>> +uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 >>>>> +uart0: console (9600,n,8,1) >>>>> ebus0: addr 0x1400000060-0x1400000067 (no driver attached) >>>> >>>> Well this is definitely progress - at least the ebus attach is now >>>> sorted :) I've sent the patch upstream (see >>>> http://www.openfirmware.info/pipermail/openbios/2015-September/008802.html) >>>> and will commit it soon if there are no objections. >>>> >>>> Next I'll see if I can get the 8042 part of the device tree correct in >>>> order to attach the PS/2 keyboard driver. >> >> Last night I spent a few hours trying to fix up the device model for the >> keyboard device (whilst also inserting an 8042 node). The binary I have >> works for a NetBSD 7 ISO, although they have included a workaround for a >> missing interrupt-map property which I've also added in. >> >> I've updated the image at https://www.ilande.co.uk/tmp/openbios-sparc64 >> with these fixes if someone could test and confirm that FreeBSD now >> reports an attach of the kb_ps2 device. > > With that version OpenBIOS is getting better regarding the 8042 part > but isn't quite there, yet. For atkbdc(4) to attach, besides "kb_ps2" > there also needs to be the "kdmouse" node beneath the "8042" one and > the latter must have a second address identical to the first one in > its "reg" property. Interesting. On both NetBSD and OpenBSD I get a successful attach with just the kb_ps2 device node. I guess that advertising a non-existent mouse port shouldn't do any harm, as attempted accesses will just be ignored. I'll add the kdmouse device and report back. ATB, Mark. From owner-freebsd-sparc64@freebsd.org Sat Sep 19 23:05:45 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6EFF9CF7F1 for ; Sat, 19 Sep 2015 23:05:45 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C0A21964; Sat, 19 Sep 2015 23:05:44 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from cpc2-slam8-2-0-cust642.2-4.cable.virginm.net ([82.24.206.131] helo=[192.168.0.5]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZdRCM-0004gM-Jp; Sun, 20 Sep 2015 00:05:41 +0100 Message-ID: <55FDEA3C.1010804@ilande.co.uk> Date: Sun, 20 Sep 2015 00:05:32 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> In-Reply-To: <20150919211420.GK18789@alchemy.franken.de> Content-Type: multipart/mixed; boundary="------------060504080405090800060005" X-SA-Exim-Connect-IP: 82.24.206.131 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 23:05:45 -0000 This is a multi-part message in MIME format. --------------060504080405090800060005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 19/09/15 22:14, Marius Strobl wrote: > On Fri, Sep 18, 2015 at 07:59:46AM +0100, Mark Cave-Ayland wrote: >> On 17/09/15 09:28, Alexey Dokuchaev wrote: >> >>> On Wed, Sep 16, 2015 at 11:19:15PM +0200, Marius Strobl wrote: >>>> [...] >>>> Which suggest that the next thing to investigate is the CMD646 >>>> emulation. Is there a particular reason why QEMU emulates a >>>> CMD646U rather than a plain CMD646 as found in the real sun4u >>>> machines of the USIIe/i era? >>>> >>>> Alexey, does building the port with CDROM_DMA disabled make >>>> a difference? >>> >>> Ironically I had it already disabled prior to your question; but I've >>> rebuilt the port enabling it for completeness' sake. It did not make >>> a difference. >>> >>> Then I've disabled all CAM/ATA stuff (scbus, ata, umass, etc.) in the >>> kernel config and that's what I see now (this is with CDROM_DMA=on): >> >> What does the CAM/ATA stuff do here? Does this mean it may not >> necessarily be an interrupt issue if you can get to mounting the root fs >> with CDROM_DMA=on? > > I think we are looking at multiple issues here. First off, based > on the interrupt-map provided by OpenBIOS, we route the intpin of > the ATA controller to INO 20 (which uses the interrupt mapping > register at offset 0xc28). If I additionally enable the code for > debugging interrupt routing problems, which just clears all > interrupts handle by the Sabre and then in all its interrupt > mapping registers enables all INOs by writing the valid bit, > Sabre IGN and CPU module ID there, I see 5 interrupts for INO > 20 at the time the kernel hangs under QEMU. I don't get any > stray interrupts for INOs that we're not actively routing. > Based on what Alexey wrote, he doesn't see interrupts for INO 20, > i. e. the ATA controller, with a kernel not including the debug > code. That doesn't make sense to me. Without the debug code, we > still enable the INOs for which drivers request them when they > attach to devices the same way as described above, just not > unconditionally for all interrupts handle by the Sabre. So > there should be no difference for correctly routed interrupts. > > Second, even when I see interrupts for the ATA controller, > enumeration of storage devices hangs somehow. On a real > machine when booting verbose, this looks like (mainly output > from ata_generic_reset(): > <...> > IPsec: Initialized Security Association Processing. > lo0: bpf attached > ata2: reset tp1 mask=00 ostat0=ff ostat1=ff > ata3: reset tp1 mask=03 ostat0=50 ostat1=00 > ata3: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 > ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata3: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata3: reset tp2 stat0=50 stat1=00 devices=0x20001 > GEOM: new disk cd0 > cd0 at ata3 bus 0 scbus1 target 1 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > <...> > > With QEMU: > <...> > IPsec: Initialized Security Association Processing. > lo0: bpf attached > ata2: reset tp1 mask=03 ostat0=00 ostat1=00 > ata2: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 > ata2: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > ata2: reset tp2 stat0=00 stat1=00 devices=0x0 > ata3: reset tp1 mask=03 ostat0=50 ostat1=00 > ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata3: stat1=0x00 err=0x00 lsb=0xff msb=0xff > ata3: reset tp2 stat0=00 stat1=00 devices=0x10000 > > <...> > db> show intrcnt > pil3: ithrd 5 > vec2004: atapci0 5 > QEMU: Terminated > <...> > > So after a reset, real iron additionally sets the READY and > SERVICE bits in the ATA status register but that doesn't > explain the hang. Code that is waiting for READY to get set > also uses a timeout. > > I patched QEMU to identify the ATA controller as a plain > CMD646 one so the UDMA isn't tried in the first place. I > also limited the ATA mode used by the kernel to PIO4 at > maximum. Neither made a difference, i. e. the hang still > occurs. > > Another striking thing is that the interrupt statistics > show to CPU tick interrupts. I'm unsure at which point > the kernel actually enables them but they really should > have been engaged at the time the hang occurs, otherwise > scheduling won't work properly, which also might be an > explanation for the hang, i. e. the kernel might never > switch to the CAM thread(s). > > All in all, interrupts in QEMU seem buggy in one way > or another. Thanks for looking into this in detail Marius - plenty of information to start debugging this further. While I don't have any insight on the CPU tick interrupt yet, my initial feeling is that the ATA hang could be related to the PCI interrupt clearing issue that I started looking into a while back. Although it isn't a complete fix, does the attached patch against QEMU help at all? Otherwise it will require a deeper dive into the QEMU interrupt emulation. ATB, Mark. --------------060504080405090800060005 Content-Type: text/x-diff; name="apb-no-clear.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="apb-no-clear.patch" diff --git a/hw/pci-host/apb.c b/hw/pci-host/apb.c index 599768e..714e654 100644 --- a/hw/pci-host/apb.c +++ b/hw/pci-host/apb.c @@ -454,9 +454,10 @@ static void apb_config_writel (void *opaque, hwaddr addr, break; case 0x1400 ... 0x14ff: /* PCI interrupt clear */ if (addr & 4) { - unsigned int ino = (addr & 0xff) >> 5; - if ((s->irq_request / 4) == ino) { - pbm_clear_request(s, s->irq_request); + unsigned int ino = (addr & 0xff) >> 3; + if (s->irq_request == ino) { + s->pci_irq_in &= ~(1ULL << ino); + s->irq_request = NO_IRQ_REQUEST; pbm_check_irqs(s); } } @@ -465,7 +466,8 @@ static void apb_config_writel (void *opaque, hwaddr addr, if (addr & 4) { unsigned int ino = ((addr & 0xff) >> 3) | 0x20; if (s->irq_request == ino) { - pbm_clear_request(s, ino); + s->pci_irq_in &= ~(1ULL << ino); + s->irq_request = NO_IRQ_REQUEST; pbm_check_irqs(s); } } --------------060504080405090800060005--