From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 14:40:35 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 731A873 for ; Thu, 14 Feb 2013 14:40:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 41C5B8AE for ; Thu, 14 Feb 2013 14:40:35 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id k20so2362062iak.29 for ; Thu, 14 Feb 2013 06:40:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=6sryvn5U5P/Z53+7+9T7fp3Bp1v+it0/1GyT0gVPvqM=; b=ibyAxxb3ah4WdCQgMSUOSG/QzPRDNlsZPvmAgdgS1d552n3Bc/KZm3BtgiDSeN6nZC yvrXhnMnw7BIb/PbaoHqzhSShwgNzdLpAKY4T2GmDtv59+1yV073gQ2s/G4dkkJAkjIR miaVmM1tttL1fIQmzFeSBt4sAWr1cktUg3RmGmrQd/4sCvCNDqq4nHngfYMd6pPKS35y oKddKyo/ynGejZWGJeiJhFVD32keMv0BQD2WywimH3IXT68CHspEwBn5xsmV76zQecLX Dg0imgIlo9IhLgrdyUSMaf5/fck6AxU6k1i6dWSTMXPZw9npjrZg/3jvf4Q8HG1Uxu0l 9+yg== X-Received: by 10.42.92.72 with SMTP id s8mr35130908icm.0.1360852834886; Thu, 14 Feb 2013 06:40:34 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id qn10sm17532290igc.6.2013.02.14.06.40.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 06:40:33 -0800 (PST) Sender: Warner Losh Subject: Re: FDT on x86 and for non-fdtbus devices. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 14 Feb 2013 07:40:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> To: Robert Watson X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnjPW3fZPjn+0CBV1RZNfpqz4UpINfJTksaWPMOGkS1KPmsofzbEPRnOqyEexofyvHZ19j0 Cc: "freebsd-arch@FreeBSD.org Arch" , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:40:35 -0000 On Feb 14, 2013, at 3:33 AM, Robert Watson wrote: >=20 > On Wed, 13 Feb 2013, Marcel Moolenaar wrote: >=20 >> I think one way to state the problem in a generic way is: How can we = obtain the FDT pnode_t given an arbitrary device_t and use the pnode_t = to query for properties, etc. >>=20 >> Are people already doing things like this? Is there an interest in = being able to do things like this? Are changes to drivers to have them = query FDT contributable at all or do people think such would be = "pollution"? >=20 > Only loosely related, but another thing we'd like to be able to do at = SRI/Cambridge is merge ROM-discovered FDT configuration data with = kernel-linked configuration data. For example, we'd like to rely on the = device's ROM for a list of physical device layouts and so on, but embed = our description of flash layout, additional device driver configuration = information (e.g., /dev node information for avgen, which exports = devices unsupported by specific device drivers using a generic = memory-mapped interface), etc, in the compiled kernel for the device. = I'm not sure if that's something that's of interest in this context as = well? IF you want to just add nodes to the FDT, I think that having a merge = function in ubldr and such wouldn't be too horribly hard. If you wanted = to change leaf nodes already in the tree, that would be quite a bit = harder, but might be doable in the kernel context.... But I'm curious why your specific example wouldn't already live in the = FDT for your board.... Warner