Date: Mon, 07 Sep 2015 22:13:36 +0100 From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> To: Marius Strobl <marius@alchemy.franken.de>, Alexey Dokuchaev <danfe@FreeBSD.org> Cc: "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <55EDFE00.9090109@ilande.co.uk> In-Reply-To: <20150907203152.GA70457@alchemy.franken.de> References: <557B6116.70900@ilande.co.uk> <557C1162.3000106@FreeBSD.org> <557D82F8.50908@ilande.co.uk> <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <A88F6A52-FA8A-4669-A2D6-23374F8E26BB@FreeBSD.org> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <EEPROM/clock> addr 0x1400002000-0x1400003fff on ebus0 >> eeprom0: cannot allocate resources >> device_attach: eeprom0 attach returned 6 >> ebus0: <fdthree> addr 0 (no driver attached) >> ebus0: <su> 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: <PCI-EBus2 bridge> 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, 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 <empty> 66mhz-capable <empty> 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 <empty> 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 <empty> 66mhz-capable <empty> 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 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? ATB, Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55EDFE00.9090109>