From owner-freebsd-arm@FreeBSD.ORG Sun Aug 3 19:41:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64BD6844 for ; Sun, 3 Aug 2014 19:41:26 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2620426EB for ; Sun, 3 Aug 2014 19:41:26 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id z60so8213812qgd.27 for ; Sun, 03 Aug 2014 12:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DMNXluKYkhRNii0N+EaqaGucwXcBm/2U6m40XzJ4zi0=; b=VEOAc/gkQB5Ay/fnE/tQW1HPTL5miFKvulV6cJZdrtbJLmGOF2EN9hOffhzRYW60CF c1BU0s/DaVwmfPqeF+UJft+bLaFYSlNc9ghqzius4nShcQfGs3Y03gc7TtH5oDwtFW35 QfTGeeL5F9dJF05ot6fz3etxJBP0iL5mcw+CvUkiWP0rExb6LjEBi2mIcW36Do8nC5Ul 6vJWsyTwaGR0eLyyC3KrwVSQ3IJt7VvtVz6ZkXjk0xazMlWvoDdlsO/V7DA6A619DYJ3 tFQ8WtRFx23Pweu69IFgc4WnnxvzgqarP4vO7CvZ27TQKa2bjfXf57TviUvnR88RcvAG 17Og== MIME-Version: 1.0 X-Received: by 10.140.83.209 with SMTP id j75mr28014597qgd.42.1407094884630; Sun, 03 Aug 2014 12:41:24 -0700 (PDT) Received: by 10.140.87.241 with HTTP; Sun, 3 Aug 2014 12:41:24 -0700 (PDT) Date: Sun, 3 Aug 2014 16:41:24 -0300 Message-ID: Subject: Two questions on Flattened Device Tree, newbus and device driver attaching From: =?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?= To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 19:41:26 -0000 Hello everyone! I'm working with FreeBSD on the Zedboard (ported by Thomas Skibo ). Currently I'm trying to fully understand how the Flattened Device Tree (FDT) mechanism works and how it integrates with FreeBSD. What I've already understand (I think) is: (1) how to represent devices, memory mapping/ranges, interrupts, etc... in a Device Tree Source (DTS) file, (2) how the newbus framework works, and (3) how the kernel manages resources, devices and drivers. Although I've read all the documents I could find (and some source code) there are still two things I don't understand: *1) The DTS source file and CPUs definition:* The DTS file for the zedboard, /release/10.0.0/sys/boot/fdt/dts/zedboard.d= ts (here ), has the CPU definition all commented out: ... // cpus { // #address-cells =3D <1>; // #size-cells =3D <0>; // cpu@0 { // device-type =3D "cpu"; // model =3D "ARM Cortex-A9"; // }; // }; ... This sounds really strange to me! How can the system tell the CPU it's running on? I'v found some other DTS files for other boards that *do define* it's CPUs. For example: imx53x.dtsi: (here ) ... cpus { #address-cells =3D <1>; #size-cells =3D <0>; cpu@0 { device_type =3D "cpu"; compatible =3D "ARM,MCIMX535"; reg =3D <0x0>; d-cache-line-size =3D <32>; i-cache-line-size =3D <32>; d-cache-size =3D <0x8000>; i-cache-size =3D <0x8000>; l2-cache-line-size =3D <32>; l2-cache-line =3D <0x40000>; timebase-frequency =3D <0>; bus-frequency =3D <0>; clock-frequency =3D <0>; }; ... or: p1020rdb.dts (here ) ... cpus { #address-cells =3D <1>; #size-cells =3D <0>; PowerPC,P1020@0 { device_type =3D "cpu"; reg =3D <0x0>; next-level-cache =3D <&L2>; }; PowerPC,P1020@1 { device_type =3D "cpu"; reg =3D <0x1>; next-level-cache =3D <&L2>; }; }; ... *So my first question is: How can the system tell on wich CPU it running on? can I add the CPUs definition in my DTS file?* 2) The 'compatible' property of a node, finding the driver and attaching it to the corresponding newbus node: During autoconfiguration the the .dtb (device tree blob) file is parsed and for each node of the device three the autoconfiguration systen will create a new newbus node (with device_add_child()) and then it will find a suitable driver for it and will attach it: */ * This function is the core of the device autoconfiguration * system. Its purpose is to select a suitable driver for a device and * then call that driver to initialise the hardware appropriately. The * driver is selected by calling the DEVICE_PROBE() method of a set of * candidate drivers and then choosing the driver which returned the * best value. This driver is then attached to the device using * device_attach(). * * The set of suitable drivers is taken from the list of drivers in * the parent device's devclass. If the device was originally created * with a specific class name (see device_add_child()), only drivers * with that name are probed, otherwise all drivers in the devclass * are probed. If no drivers return successful probe values in the * parent devclass, the search continues in the parent of that * devclass (see devclass_get_parent()) if any. * * @param dev the device to initialise */ int device_probe(device_t dev) (I extracted this from here ) I believe that the autoconfiguration system uses the fdt_node_check_compatible() function (from fdtlib ) to get the "compatible" property out of each node of the .dtb blob and then it calls device_probe() to find the best driver and attach it to the corresponding newbus node. (is this correct?). >From the ePAPR standard we have this: 2.3.1 compatible Property: compatible Value type: Description: The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is =E2=80=9Cmanufacturer,model=E2=80=9D, where manuf= acturer is a string describing the name of the manufacturer (such as a stock ticker symbol), and model specifies the model number. Example: *compatible=3D=E2=80=9Cfsl,mpc8641-uart=E2=80=9D, =E2=80= =9Cns16550";* In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. *What I don't understand is how the system locates a device driver based on the compatible property. For example the cpu node's compatible property ("ARM,MCIMX535") of the imx53x.dtsi example. More precisely: How can the system relate the string "ARM,MCIMX535" with the actual device driver in the file system.* I hope my questions are clear enough. Many thanks in advance. Best regards, Mat=C3=ADas.-