From owner-freebsd-arm@FreeBSD.ORG Sun Jan 19 03:08:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF5FD68E for ; Sun, 19 Jan 2014 03:08:20 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9332517E1 for ; Sun, 19 Jan 2014 03:08:20 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id uy17so5059158igb.4 for ; Sat, 18 Jan 2014 19:08:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=mbUcM4/PJrGkwpKLpmtu9BaBYUSjMxuRVmYbi+PFN2U=; b=VCvbkRUzc4PYfN1IgIxoNHtggAstteYw5begx14fqaopVmGQmtZEpX0e2E9qCOi0lN EiuypgVo9Hj290ZcNb2pQK8ib+LezDFb/AeMq6KVsz1cDQBzepohT5Xym0twmMZXA2KM w1mWasX79EZVtKMavL/VFnDmGKsQZJBSAi+j7WXkVUCEwbTUtOM2uZXw8M3A3xvJI7V+ VxeNFnOaNbPAcS8PGJko2ZhrvJKyKSiMhotfw9qW5xDWYRTd9zZOInmdugOR4pLaqi17 QXG0X3r3H82we5kAtxNFh6cdwT7Q2/nvCR37A6TxN6FHpRIcGj4AHD0E4uiWrDIsfxC1 oWkA== X-Gm-Message-State: ALoCoQnw8idIGZGN54hKtTsz5wmyBKftjowyYLu6HiqumxaxU4pXrYAlRYAeNYv4hP7pmSKJ2Iav X-Received: by 10.50.79.228 with SMTP id m4mr5710692igx.47.1390100894534; Sat, 18 Jan 2014 19:08:14 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id g6sm12630791igg.9.2014.01.18.19.08.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Jan 2014 19:08:14 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <52DB3FFD.2070503@freebsd.org> Date: Sat, 18 Jan 2014 20:08:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C16C019-B9AF-417B-9B02-C016A202AAC7@bsdimp.com> References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> <52D89DC9.7050303@freebsd.org> <52DB1138.6010804@linaro.org> <3AE8EDE6-D931-4F93-9BF7-ABFB297B5B96@bsdimp.com> <52DB3FFD.2070503@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1085) Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 03:08:20 -0000 On Jan 18, 2014, at 8:01 PM, Nathan Whitehorn wrote: > On 01/18/14 20:44, Warner Losh wrote: >> On Jan 18, 2014, at 4:41 PM, Julien Grall wrote: >>=20 >>> Hello Nathan, >>>=20 >>> On 01/17/2014 03:04 AM, Nathan Whitehorn wrote: >>>> On 01/16/14 18:36, Julien Grall wrote: >>>>>=20 >>>>> On 01/16/2014 01:56 AM, Nathan Whitehorn wrote: >>>>> As I understand, only the simple bus code (see simplebus_attach) = is >>>>> translating the interrupts in the device on a resource. >>>>> So if you have a node directly attached to the root node with >>>>> interrupts and MMIO, the driver won't be able to retrieve and >>>>> translate the interrupts via bus_alloc_resources. >>>> Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this. >>> I have digged into the code to find the reason of my issue. FreeBSD = is receiving a VM fault when the driver (xen-dt) is trying to setup the = IRQ. >>>=20 >>> This is because the GIC is not yet initialized but FreeBSD asks to = unmask the IRQ (sys/arm/arm/gic.c:306). >>>=20 >>> With this problem, all device nodes that are before the GIC in the = device tree can't have interrupts. For instance this simple device will = segfault on FreeBSD: >>>=20 >>> / { >>>=20 >>> mybus { >>> compatible =3D "simple-bus"; >>>=20 >>> mynode { >>> interrupt-parent =3D &gic; >>> interrupts =3D <...>; >>> }; >>>=20 >>> gic: gic@xxxx { >>> interrupt-controller; >>> } >>> }; >>> }; >>>=20 >>> The node "mynode" will have to move after the GIC to be able to work = correctly. >> This stems from a difference in enumeration between FreeBSD and = Linux. FreeBSD enumerates the devices in DTB order, while Linux does a = partial ordering based on dependencies. >>=20 >> Warner >=20 > Enumerating in some other order doesn't necessarily help: since the > interrupt and bus trees are independent, circular dependencies can > happen. This is not a hypothetical: on most powermacs, the main > interrupt controller is a functional unit on a PCI device -- a PCI > device whose other units have interrupt lines that eventually connect > back to itself. There is no way to fix that with ordering. So I think = we > still need to defer interrupt setup. It's not that bad -- PPC already > does this to handle the powermac case. I guess I've looked at simpler cases where interrupts and GPIO pins need = to be up before anything can work on Atmel... We kinda fake it now, but = there's some ordering issues that are solved in this way. But I've not = finished the work on bringing Atmel into the FDT world yet. Deferred = setup isn't always an option, but I'll keep that in mind in case I hit = that case... The other way to cope is to use the multi-pass enumeration stuff that = John Baldwin put into the tree a while ago. In that case, you could = enumerate bridges, interrupt controllers, gpio providers, etc first, and = then do a second pass that catches the rest of the devices and the = interrupt processing for the first pass devices. This is a variation on = the deferred enumeration stuff you are talking about, so that might be a = better, more general solution to these sorts of problems. Warner