From owner-freebsd-sparc64@freebsd.org Mon Sep 7 21:13:56 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 0074F9CC45C for ; Mon, 7 Sep 2015 21:13:56 +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 B244D1CF6; Mon, 7 Sep 2015 21:13:54 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [90.198.121.172] (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 1ZZ3jT-0000zP-2k; Mon, 07 Sep 2015 22:13:46 +0100 Message-ID: <55EDFE00.9090109@ilande.co.uk> Date: Mon, 07 Sep 2015 22:13:36 +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: <557B6116.70900@ilande.co.uk> <557C1162.3000106@FreeBSD.org> <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> In-Reply-To: <20150907203152.GA70457@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 90.198.121.172 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: Mon, 07 Sep 2015 21:13:56 -0000 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, 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 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.