From owner-freebsd-arm@FreeBSD.ORG Sun Aug 3 11:23:10 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 94B7888F; Sun, 3 Aug 2014 11:23:10 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDB520C8; Sun, 3 Aug 2014 11:23:09 +0000 (UTC) Received: from smtp6.mail.yandex.net (smtp6.mail.yandex.net [77.88.61.56]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 81329BC100D; Sun, 3 Aug 2014 15:23:06 +0400 (MSK) Received: from smtp6.mail.yandex.net (localhost [127.0.0.1]) by smtp6.mail.yandex.net (Yandex) with ESMTP id 124501640093; Sun, 3 Aug 2014 15:23:05 +0400 (MSK) Received: from 188-122-240-86.clients.tlt.100megabit.ru (188-122-240-86.clients.tlt.100megabit.ru [188.122.240.86]) by smtp6.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id sBoNvqHXLQ-N5TuOmS4; Sun, 3 Aug 2014 15:23:05 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 9d11a5ae-db30-4802-977d-ea85421f21d2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1407064985; bh=7Cq2tOYshSRvbnnKIE2FbIVR5EV1t+CfLsI/8FVcdNA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HVB+dBmvF0v41EZbnrnYRs4rDOw0cCXvBCV2icM5QHlHzV4gcLXT7Mo/yAd/vDdXY Q1EJJkVHGKIknDyUjLvyPz1CXKEiES7Xdr3qzYgNyZdv9ONfZQczmxKsSo6iTbT9SM aBmefHpt5pXWUqa88SSk95EvGs0zAlfMyfYeUbR4= Authentication-Results: smtp6.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <53DE1B99.70805@narod.ru> Date: Sun, 03 Aug 2014 17:23:05 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: mexas@bristol.ac.uk, ian@FreeBSD.org Subject: Re: Compilation for ARM, patches References: <201408031011.s73ABrDH079670@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201408031011.s73ABrDH079670@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org 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 11:23:10 -0000 Hi Anton, For clang. -Stepan Anton Shterenlikht wrote: >> From: Ian Lepore >> Date: Fri, 01 Aug 2014 14:38:45 -0600 >> >> Sorry it took so long, but I've finally gotten these patches committed, >> as of r269395, thanks for submitting them. You were right about the >> nested .fnstart being an error. I learned more about the unwind info >> while working on the c++ exception bugs -- multiple .fnstart without >> a .fnend in between can't be expressed correctly at all, the tools are >> right to complain about that. >> >> I made some changes to the EENTRY() stuff, if I didn't get it right and >> it needs more changes to compile with your newer binutils, just let me >> know and I'll adjust as needed. >> >> I also committed the .arch_extension for ti_smc.S, which actually >> required changing our base binutils to recognize .arch_extension (but it >> was worth it, because if we start correcting our code now it will be >> ready when we update our tools in base). >> >> -- Ian > > Just to clarify, is this for clang or for GCC, or both? > > Thanks > > Anton > From owner-freebsd-arm@FreeBSD.ORG Sun Aug 3 12:44:36 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 408C9494 for ; Sun, 3 Aug 2014 12:44:36 +0000 (UTC) Received: from eu1sys200aog134.obsmtp.com (eu1sys200aog134.obsmtp.com [207.126.144.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 953BB2918 for ; Sun, 3 Aug 2014 12:44:34 +0000 (UTC) Received: from mail-we0-f172.google.com ([74.125.82.172]) (using TLSv1) by eu1sys200aob134.postini.com ([207.126.147.11]) with SMTP ID DSNKU94umGg2aLX90QmI6tCjH46LiX96ffFp@postini.com; Sun, 03 Aug 2014 12:44:35 UTC Received: by mail-we0-f172.google.com with SMTP id x48so6408780wes.3 for ; Sun, 03 Aug 2014 05:44:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=mu+bqHKz/T6T7JY6ggi9hgT7Y3tUwsVRJdVyQYzMrBI=; b=XXVMwXRga/E1OmQ0ovyS2qtUoIQBlTMxp+4eOCgs+OznJwAOPpheZ10bM64qcw3nhi Jw3CZfYDUwLSVqp0HCTWxn3e3Ao+631AbxXYZ1wHJnbNI5XwgcJfyIMvs5r4hAL13YYC yVtfQ9iPg0SiqX8l7paKfpWpvIhN8+QWcY4W/sqG7GgZuKn/+w8TmiuTjHpmpq0NIi4E LVFoyMpODOIXU9tCKYc6npq6xC6nhsg04juLWpFxb26I5dtQpfPg9p+Hhy8b4c4a4lH8 eiu/55ItUn7mCGW03TyN+cmG6XlMwk4qYRY8MsPOX0gr2KMl2v34Nlh3hp6Z4h2m2ju0 IYeA== X-Received: by 10.180.10.165 with SMTP id j5mr20591560wib.10.1407060715946; Sun, 03 Aug 2014 03:11:55 -0700 (PDT) X-Gm-Message-State: ALoCoQnD1/HaUOwmvj4kK6RVSl3bjynJGTOe7wHtXKCiTWcLSxYI6sUn+5qb5Ww0gXethdBWpUZBF4zdW/ilNP0K/M7QR7Sz2hdrtuhVVAS24bdXU9qNDQeE1ohEK/k4ldA2DMxdtawx X-Received: by 10.180.10.165 with SMTP id j5mr20591552wib.10.1407060715824; Sun, 03 Aug 2014 03:11:55 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id lq15sm28436420wic.1.2014.08.03.03.11.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Aug 2014 03:11:55 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s73ABr54079671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 Aug 2014 11:11:53 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s73ABrDH079670; Sun, 3 Aug 2014 11:11:53 +0100 (BST) (envelope-from mexas) Date: Sun, 3 Aug 2014 11:11:53 +0100 (BST) From: Anton Shterenlikht Message-Id: <201408031011.s73ABrDH079670@mech-cluster241.men.bris.ac.uk> To: ian@FreeBSD.org, stpworld@narod.ru Subject: Re: Compilation for ARM, patches Reply-To: mexas@bristol.ac.uk In-Reply-To: <1406925525.56408.264.camel@revolution.hippie.lan> Cc: freebsd-arm@freebsd.org 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 12:44:36 -0000 >From: Ian Lepore >Date: Fri, 01 Aug 2014 14:38:45 -0600 > >Sorry it took so long, but I've finally gotten these patches committed, >as of r269395, thanks for submitting them. You were right about the >nested .fnstart being an error. I learned more about the unwind info >while working on the c++ exception bugs -- multiple .fnstart without >a .fnend in between can't be expressed correctly at all, the tools are >right to complain about that. > >I made some changes to the EENTRY() stuff, if I didn't get it right and >it needs more changes to compile with your newer binutils, just let me >know and I'll adjust as needed. > >I also committed the .arch_extension for ti_smc.S, which actually >required changing our base binutils to recognize .arch_extension (but it >was worth it, because if we start correcting our code now it will be >ready when we update our tools in base). > >-- Ian Just to clarify, is this for clang or for GCC, or both? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Sun Aug 3 17:57:08 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 71B2AA8A for ; Sun, 3 Aug 2014 17:57:08 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45F492A73 for ; Sun, 3 Aug 2014 17:57:07 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XDyRU-0007QT-47; Sun, 03 Aug 2014 16:15:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s73GFQUe010659; Sun, 3 Aug 2014 10:15:26 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18OyYNEpJ8g2mc9+4zsaSPh X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Compilation for ARM, patches From: Ian Lepore To: mexas@bristol.ac.uk In-Reply-To: <201408031011.s73ABrDH079670@mech-cluster241.men.bris.ac.uk> References: <201408031011.s73ABrDH079670@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Aug 2014 10:15:25 -0600 Message-ID: <1407082525.56408.267.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org 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 17:57:08 -0000 On Sun, 2014-08-03 at 11:11 +0100, Anton Shterenlikht wrote: > >From: Ian Lepore > >Date: Fri, 01 Aug 2014 14:38:45 -0600 > > > >Sorry it took so long, but I've finally gotten these patches committed, > >as of r269395, thanks for submitting them. You were right about the > >nested .fnstart being an error. I learned more about the unwind info > >while working on the c++ exception bugs -- multiple .fnstart without > >a .fnend in between can't be expressed correctly at all, the tools are > >right to complain about that. > > > >I made some changes to the EENTRY() stuff, if I didn't get it right and > >it needs more changes to compile with your newer binutils, just let me > >know and I'll adjust as needed. > > > >I also committed the .arch_extension for ti_smc.S, which actually > >required changing our base binutils to recognize .arch_extension (but it > >was worth it, because if we start correcting our code now it will be > >ready when we update our tools in base). > > > >-- Ian > > Just to clarify, is this for clang or for GCC, or both? > > Thanks > > Anton It's actually, more than anything, "for the future." The code was compiling as-is (obviously) using our current base toolchains, but Stepan was trying to use newer tools (to get some features he needed) and he ran into these problems in our code. Fixing them now means we'll have less to fix all at once when we move to newer tools in base. -- Ian 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.- From owner-freebsd-arm@FreeBSD.ORG Mon Aug 4 16:16:22 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 BDBB69D9 for ; Mon, 4 Aug 2014 16:16:22 +0000 (UTC) Received: from nm8-vm1.access.bullet.mail.bf1.yahoo.com (nm8-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 559FF2552 for ; Mon, 4 Aug 2014 16:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1407168803; bh=R/E7yGiqC4iShcunDqflv/je15QRf6LKeVxFTKxGW6A=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WhBR7yGPhwEfSFHbnGo7N63lkbV639inO0PzMhd5wC0ctY++IzA0pFAb3Kw0bGjerJPIdG0VjiGsuo53bGnwnm2CNoJwJ04/Dy33UKJUY0qTQZnIZ2T3JspcbsFcNWxAAY2XiY5F3H5er4yMRJjFgforLQoXfo/q6MNEulfQYP2ONWaj9yD9GAEgu/TN1u6J3V3ckaWja9XL9I8EH4LjhokQXvFJ9Sm0NVWj9ZVX3PWTYalQNHoY6vFyce8q+KXBXFAZ4Lgy1/pDVLe9Wg9ccsCTMMIcwUMaBeOG9GjayexS6O8fWVcQU+Z3Km8uG/FovvbZwNgUwbHyqpf3u3rSpw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=sbcglobal.net; b=V1Fap0Hr0Bl1Hs3nKRv4/Ook1zSLaNsZ3z47eUsz+w0E78Ku6E1Cex97Mf4rSgA2/bmRLj1+8NjuislTvkfFDS3JNBqGpir/NCG9ybB0hrcnNVdPtIsAIWX3TeyCY2QXrh5LrkNv3FIoblpfTW5PhZVPJ6708X3zZgvELNbxOw3Kkf4joyLE4N52ZpcmENk+R+n8lTsiJAUbUSIe+7PALNvJgsVLHZTjAnju76TmT5aKiIuBNshoJ3Lgunnn2e9X+c+QD69J/RKPgSi+LlsrbyEVKWXJ5t+RJ4UmjUIuDlKY/C9ur99ZarvV3qEUoot1il76Zk4McVNSjfoVmMXm/A==; Received: from [66.196.81.162] by nm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Aug 2014 16:13:23 -0000 Received: from [98.138.226.242] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Aug 2014 16:13:23 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.ne1.yahoo.com with NNFMP; 04 Aug 2014 16:13:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1407168803; bh=R/E7yGiqC4iShcunDqflv/je15QRf6LKeVxFTKxGW6A=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Vx/5aDyVSotUox1k6XzT3gxPy2KdLxiBMlviATh5G7WCLrkX/dB+wv3XReSTK6m09KiJo6eQIkuv0XVWMRzQoQ59b0fcqKSmXJG9lMlR4/42K21KK3qx1UrTNyYn7HR9QjmXdwa/CU57QMJyZerx5Jp/r4vBxXEzt7psXU5m4vo= X-Yahoo-Newman-Id: 443076.99841.bm@smtp113.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: swzEZ6UVM1mmHEljplmDQlzcErCulWj0r52imfXsgsjtM6t Ko7rFBR5fUOMlpI__J2x2QoKb86inQzTbUasT4yHgQ25vZBtIZifBFXGsA0U K2QLqZLKKnGm8sTM8X3HLa7ptqJsTdQO43aqSX25Z92uNFjg7j1DoJSTQjz. OCS9pFHRW.kHmvKrZ6WH7qX3KCK.PgstbTMTu6yvxsmHsQEe6neJ67KtDNXl YEUMR.vMYPl.I_38LlRPYlowOw_7HxESsycv1EautudCmTVwRpw5I0jo2I.O 1aBRUGil8ctzMCeYBjZIEBeVzH4n6be0__8U_ygJ4UTqWj6G4Im1w6.fca1j ptjm0ZoGeLKF1MsE_Rj6NViKmLieCK2cSS1RPTeMF3LAXA3X22nK__gE8gFx tP47xeozgbRwDZBvmJgcdbPwhpeO6B6stB5Nfz1jlr7b4Pex_Rh0Iypl9usm P4ZtVPIMTaNqyMDkgas0wIddZSIXrf80pV59jp3MFqWbD4LVBVGOKlEEM1LU wXS7859benexUOrCE_mBM8y9Zz92Y_198txm_ztbkk3FlvK9baPeISlcmj7U ypskdPeRmvlTRkpjZoL1SEoJazNRkMKEtA3H4DSn_OVYMiW5twnSBsAmNA78 JYBvgdrR8fpqzZk3MU7XWy9tUNGqW2I0wNedxVolJvHoIeGUzcZ4OteBr81X xuc2l.peQhkjVE471b1w5kYP_UlwYfMevKVob7vI.bw0F3WCw.XGXMZzxG.r sCvY5gCeN7v.Jk_dDf.gnhxHe0BqyeWz40prQzORP8KUiGcK5IE8O X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Message-ID: <53DFB121.40909@sbcglobal.net> Date: Mon, 04 Aug 2014 09:13:21 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org, =?UTF-8?B?TWF0w61hcyBQZXJyZXQgQ2FudG9uaQ==?= Subject: Re: Two questions on Flattened Device Tree, newbus and device driver attaching References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 04 Aug 2014 16:16:22 -0000 On 8/3/14, 12:41 PM, Matías Perret Cantoni wrote: > 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.dts > (here > ), > has the CPU definition all commented out: > > ... > // cpus { > // #address-cells = <1>; > // #size-cells = <0>; > // cpu@0 { > // device-type = "cpu"; > // model = "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: > [snip] > > *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?* To be honest, I don't remember why I commented that out. I'm pretty sure it's ignored but it might be useful to have that info in the .dtb file anyway. The system identifies the CPU by the CPU ID register. See sys/arm/arm/identcpu.c and sys/arm/include/armreg.h. --Thomas -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Mon Aug 4 20:00:13 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 4450FD9B for ; Mon, 4 Aug 2014 20:00:13 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0478F2210 for ; Mon, 4 Aug 2014 20:00:12 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XEOQP-000JJl-MJ; Mon, 04 Aug 2014 20:00:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s74K04K5013317; Mon, 4 Aug 2014 14:00:04 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ye191hY8C7B1M5cjCut7E X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Two questions on Flattened Device Tree, newbus and device driver attaching From: Ian Lepore To: =?ISO-8859-1?Q?Mat=EDas?= Perret Cantoni In-Reply-To: References: Content-Type: text/plain; charset="iso-2022-jp" Date: Mon, 04 Aug 2014 14:00:03 -0600 Message-ID: <1407182403.56408.297.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org 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: Mon, 04 Aug 2014 20:00:13 -0000 On Sun, 2014-08-03 at 16:41 -0300, Matas Perret Cantoni wrote: > 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.dts > (here > ), > has the CPU definition all commented out: > > ... > // cpus { > // #address-cells = <1>; > // #size-cells = <0>; > // cpu@0 { > // device-type = "cpu"; > // model = "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 = <1>; > #size-cells = <0>; > > cpu@0 { > device_type = "cpu"; > compatible = "ARM,MCIMX535"; > reg = <0x0>; > d-cache-line-size = <32>; > i-cache-line-size = <32>; > d-cache-size = <0x8000>; > i-cache-size = <0x8000>; > l2-cache-line-size = <32>; > l2-cache-line = <0x40000>; > timebase-frequency = <0>; > bus-frequency = <0>; > clock-frequency = <0>; > }; > ... > > or: > > p1020rdb.dts (here > > ) > > ... > cpus { > #address-cells = <1>; > #size-cells = <0>; > > PowerPC,P1020@0 { > device_type = "cpu"; > reg = <0x0>; > next-level-cache = <&L2>; > }; > > PowerPC,P1020@1 { > device_type = "cpu"; > reg = <0x1>; > next-level-cache = <&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 $B!H(Bmanufacturer,model$B!I(B, where manufacturer is a > string describing the name of the manufacturer (such as a stock ticker > symbol), and model > specifies the model number. > > Example: *compatible=$B!H(Bfsl,mpc8641-uart$B!I(B, $B!H(Bns16550";* > > 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. > For #1, virtually none of our arm code uses the cpu information from the fdt data, because we generally compile a custom kernel specific to each cpu. We've been slowly (very slowly) moving towards a unified kernel that can boot on multiple arm chips (or at least closely related chips within a family), and that will make the cpu info more important some day. For #2, if you're looking for some big master table that maps compatible strings to drivers, no such thing exists. Each driver source has one or more DRIVER_MODULE() macros that provides some information about the driver. One of the things it provides is the parent. The newbus system builds a metadata hierarchy that tracks which drivers have described themselves as potential children on each bus. Usually a device's parent is some sort of bus such as PCI. In an fdt-based system "simplebus" is an abstraction that can represent many different types of buses (such as internal on-chip connections between the cpu and internal devices). A hardware bus such as PCI has ways to query the hardware to see what's connected. In the fdt world, simplebus uses the fdt data to do this query... it looks at all the fdt device entries that are described as its children in the fdt data. For each child in the fdt data, simplebus asks newbus to probe all the drivers whose DRIVER_MODULE() said they could be children of simplebus. The probe() routine of each driver has access to the fdt data for the device simplebus is trying to probe. The driver compares the compatible strings in that data to the compatible strings that it knows how to handle, and returns a success/fail code from probe() to indicate whether or not it is the driver for the device. Sometimes multiple drivers can handle the same hardware, so newbus probes every child driver against every device on the bus. For example a usb keyboard is a pretty generic thing, but a FooStar1000 keyboard might have a special driver that understands extra keys. The generic usb keyboard driver would return BUS_PROBE_GENERIC, and the FooStar1000 driver would return BUS_PROBE_SPECIFIC. After probing all potential devices, newbus chooses the one with the highest return value from probe() as being the one most-specific to that hardware. (In reality this doesn't happen much; usually only one driver returns success and all others return an error.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 05:39:22 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 1A77F200 for ; Tue, 5 Aug 2014 05:39:22 +0000 (UTC) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 9DC2C2073 for ; Tue, 5 Aug 2014 05:39:21 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id 10so311037lbg.20 for ; Mon, 04 Aug 2014 22:39:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=3jw3khnGVA/1Ok3ppfRyI5jGspv7D30cOiYAnrQceDM=; b=azmCvMH75AOYkJvNP9/AoWDQ5mMUQMcvAV9AO9qHczqJwKPJlbQTpFE3oUpXWlUnt6 heITje745IgkefzeYKHlyHyFKfCUh8heMEhJyRWybFhtyPwnEjjpTg/5aedu9gqT9vaW ImEjaDSL94IRm3B2oMPoErBMy8Nh0Aw+7m2Ye4CZHZ654tBwYJ5a1l7OXY5Q1Q/fYevT Cbko9UYcMh66VRMzI1F0+K1RxUPIUuAx5bOQwttDbLcnJ898uB7eksPT90awL6V8Aq89 ZNSXgPlzORD5chlsUBjOLyiSLK1ZiZXkSEE21qFW9mdyW5JU+TxaMZHfagB0zK3GFq60 DFUg== X-Gm-Message-State: ALoCoQlbbR1llLf0nzi3rP2x3ugSRVLt3wmghvRwaRPUhM1XV2plrKECrtPVwIdYe1KwCizbfJn3 MIME-Version: 1.0 X-Received: by 10.112.157.68 with SMTP id wk4mr1262628lbb.85.1407217152627; Mon, 04 Aug 2014 22:39:12 -0700 (PDT) Received: by 10.152.21.41 with HTTP; Mon, 4 Aug 2014 22:39:12 -0700 (PDT) Date: Tue, 5 Aug 2014 12:39:12 +0700 Message-ID: Subject: Unable to compile squid for RPI From: Alie Tan To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Tue, 05 Aug 2014 05:39:22 -0000 Hi, Is there anyway to solve compilation error below: ../../include/util.h:58:34: note: expanded from macro '_SQUID_EXTERNNEW_' #define _SQUID_EXTERNNEW_ extern inline __attribute__((gnu_inline)) ^ 5 warnings generated. /tmp/StoreMap-5d1169.s: Assembler messages: /tmp/StoreMap-5d1169.s:713: Error: selected processor does not support `ldrexb r1,[r2]' /tmp/StoreMap-5d1169.s:715: Error: selected processor does not support `strexb r4,r3,[r2]' /tmp/StoreMap-5d1169.s:2456: Error: selected processor does not support `ldrexb r1,[r2]' /tmp/StoreMap-5d1169.s:2458: Error: selected processor does not support `strexb r7,r3,[r2]' c++: error: assembler command failed with exit code 1 (use -v to see invocation) *** [StoreMap.lo] Error code 1 make[5]: stopped in /usr/ports/www/squid33/work/squid-3.3.11/src/ipc 1 error Thanks in advance From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 06:39:46 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 64A0CEFF for ; Tue, 5 Aug 2014 06:39:46 +0000 (UTC) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (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 34707267A for ; Tue, 5 Aug 2014 06:39:45 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id eu11so805354pac.18 for ; Mon, 04 Aug 2014 23:39:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=X/F1GPs4q2S+L+JSTVpIxNuFsllvtLEKAOu0ACCgvzw=; b=QAhMVUGnEmP8pPGNUrka9XJCQAlbz1avlh+zGSKoiXWl1tadXcCCuI17cEqZC2CTXT 1b/167tPR5f+UDeOLzRVw1Sj1y0gVxyz9cv7doq9+tF8Cxsil0eUOjBZzPyehGpOeDSg l2V68Q83Jkf+PjcWFUNOSNk9NEYiJZnukUrqajANeZAZeJZee4hfe7d6rQkwBS2NbVc4 8JlhO4KySBLmitqZxxtyyKwJ7BVCgCH80Je1eGuwXsFZMR5qdsO1ctYO8VcYpOJowyrX VgpWcNZc8GWjzU2z08J2B3MofHAMgDSTi7YKxyoXov2WN9Y1F07StHmQVaKDffLO3LYn jkjg== X-Gm-Message-State: ALoCoQm1bWxhYCQuUbUHhd9N+r5XSTLlCQlS7hxv/SsqFQr5dvipYOh7FUXea1vfiw9IS5AprrpY X-Received: by 10.66.161.41 with SMTP id xp9mr1882417pab.120.1407220418206; Mon, 04 Aug 2014 23:33:38 -0700 (PDT) Received: from [10.64.25.9] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id op10sm829914pbb.88.2014.08.04.23.33.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 23:33:37 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7FF482B4-3047-4631-AED5-DAF067CC7F72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Unable to compile squid for RPI From: Warner Losh In-Reply-To: Date: Tue, 5 Aug 2014 00:33:34 -0600 Message-Id: References: To: Alie Tan X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" 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: Tue, 05 Aug 2014 06:39:46 -0000 --Apple-Mail=_7FF482B4-3047-4631-AED5-DAF067CC7F72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 4, 2014, at 11:39 PM, Alie Tan wrote: > Hi, >=20 > Is there anyway to solve compilation error below: > ../../include/util.h:58:34: note: expanded from macro = '_SQUID_EXTERNNEW_' > #define _SQUID_EXTERNNEW_ extern inline __attribute__((gnu_inline)) > ^ > 5 warnings generated. > /tmp/StoreMap-5d1169.s: Assembler messages: > /tmp/StoreMap-5d1169.s:713: Error: selected processor does not support > `ldrexb r1,[r2]' > /tmp/StoreMap-5d1169.s:715: Error: selected processor does not support > `strexb r4,r3,[r2]' > /tmp/StoreMap-5d1169.s:2456: Error: selected processor does not = support > `ldrexb r1,[r2]' > /tmp/StoreMap-5d1169.s:2458: Error: selected processor does not = support > `strexb r7,r3,[r2]' > c++: error: assembler command failed with exit code 1 (use -v to see > invocation) > *** [StoreMap.lo] Error code 1 >=20 > make[5]: stopped in /usr/ports/www/squid33/work/squid-3.3.11/src/ipc > 1 error There was a period of time when the clang default was busted. perhaps = you hit an unlucky window? Warner --Apple-Mail=_7FF482B4-3047-4631-AED5-DAF067CC7F72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4Hq/AAoJEGwc0Sh9sBEAECIQAN26K58GbQd7QyBIOOk/EB0v UKUgZLVj2NK7X3tmWXzSCV/S7opcpfn43PE1qMQyH3JP7uQDLr2tE8JQsN4OQCwU URYZMPYajAMZmFfeHDzKvVEPr7C9DZbyZpyKmRFre6sHYgQaSDbr+lIATnfCK7WA SPY3+v3ARJfRGgJ1rde0TrGv9AP1iUQ50SIpOwXoWAf0ctnUCdXwnYFCz89xEAQK T/+mqpYIG6L33d3OdEuH33n5eu2zvjEGwATpCleOWMW9OfB/17XzNMCWr8AAkPmf TiG+4tGoav4PGVTz2QIB7Var8kpGy5FEojfKDJwEixZnmL+/hZYdEO2fbVxMUhQ7 ZaAlT7vruDSVrPysgMUf2E7ezYRFDbX7Ns8YLH8FrxiWZi1TA92m+mbA8/KYot6V AtbcbDafoi6Z2iD9VoX/Xzg7BFMkRYJRMLcHp57CEOHrnLzqtXMehM4vek4MhhJD oH/0pLZSWs2OkQIldxfA/ANxOWsz9SrwMceIAVhHJE/nivUPGHwOJZI0VBL10lla Y2HyEI/iM60p2z9u+uEdIO4wXb7qRSwZXOLT6yR5OMv8gdciWH9LxDbReWz53Mxd 15oyKJuK9rvSWFhrIWFBFvrs23AuPID5JoJJBKuxdVM8HRsg7TTMdint6t7zKMKu /NYz6LDmj1et8zN/Uj+b =diiQ -----END PGP SIGNATURE----- --Apple-Mail=_7FF482B4-3047-4631-AED5-DAF067CC7F72-- From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 07:51:54 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 143E2300 for ; Tue, 5 Aug 2014 07:51:54 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id ECD98207A for ; Tue, 5 Aug 2014 07:51:53 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id EB2A55DEBC; Tue, 5 Aug 2014 07:51:46 +0000 (UTC) Date: Tue, 5 Aug 2014 08:51:34 +0100 From: Andrew Turner To: Alie Tan Subject: Re: Unable to compile squid for RPI Message-ID: <20140805085134.7dd6a295@bender.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" 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: Tue, 05 Aug 2014 07:51:54 -0000 On Tue, 5 Aug 2014 12:39:12 +0700 Alie Tan wrote: > Hi, > > Is there anyway to solve compilation error below: > ../../include/util.h:58:34: note: expanded from macro > '_SQUID_EXTERNNEW_' #define _SQUID_EXTERNNEW_ extern inline > __attribute__((gnu_inline)) ^ > 5 warnings generated. > /tmp/StoreMap-5d1169.s: Assembler messages: > /tmp/StoreMap-5d1169.s:713: Error: selected processor does not support > `ldrexb r1,[r2]' > /tmp/StoreMap-5d1169.s:715: Error: selected processor does not support > `strexb r4,r3,[r2]' > /tmp/StoreMap-5d1169.s:2456: Error: selected processor does not > support `ldrexb r1,[r2]' > /tmp/StoreMap-5d1169.s:2458: Error: selected processor does not > support `strexb r7,r3,[r2]' > c++: error: assembler command failed with exit code 1 (use -v to see > invocation) > *** [StoreMap.lo] Error code 1 > > make[5]: stopped in /usr/ports/www/squid33/work/squid-3.3.11/src/ipc > 1 error You need to make sure you have r269387. These are armv6k instructions and our version of clang prior to this change only worked with armv6 instructions, i.e. no ldrexb or strexb instruction. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 16:26:44 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 BDF9E397 for ; Tue, 5 Aug 2014 16:26:44 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (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 90D3824CA for ; Tue, 5 Aug 2014 16:26:44 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id ft15so1615740pdb.38 for ; Tue, 05 Aug 2014 09:26:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type:subject:message-id:date :to:mime-version; bh=YeK/+Lwp2AKUZ7pHsYs0dDGqh/xRkMptW3DQNOLO/Q0=; b=BBzRCl6iyK7DHd4XMVsGvcE1Vm6ISJ32BSHCSH9Xxf/avnACSNNNOXH7cSkwAhgPat Zw7BEkOxcDnNdJuFI8XJKFBClJ6oibwemIDjrBRdnIeo+tPdJqat3jmz69ziYYTxE/1v GTEzF/OdERPKQ1OOjaMOqOm/Kck2TueoJfq+n0arUTXOP8QRmefDMxwOjDonFtVeFwoy d30VxQmEHEdlh3Hhzs9LUfQnj0rCa3uPsVtxPkGZRSBMTlUgVp1FTV2TjF+ethvTzMAm S5FqbK0EJNtN2peM65y9O9szIrbJVv0Isj8L5i/oAuA8mKh+DmjO+KHYYk7E41ThANub iXLw== X-Gm-Message-State: ALoCoQkbDR4nbW2lYuyz6sMVAs0aEYv+ez37m4pi2vgi68okuJw7Z6DaOl1ynzhuyTOY8nJq739o X-Received: by 10.69.20.97 with SMTP id hb1mr5616653pbd.150.1407255997970; Tue, 05 Aug 2014 09:26:37 -0700 (PDT) Received: from [10.64.25.9] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id op10sm2506166pbb.88.2014.08.05.09.26.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 09:26:37 -0700 (PDT) Sender: Warner Losh From: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5F91CE42-E6E1-4494-8C16-A1B59B4D38B4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: What platform do you use? Message-Id: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Date: Tue, 5 Aug 2014 10:26:35 -0600 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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: Tue, 05 Aug 2014 16:26:44 -0000 --Apple-Mail=_5F91CE42-E6E1-4494-8C16-A1B59B4D38B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Greetings, I=92d like to know what platforms people use FreeBSD/arm with, and if = you=92d have time to test some potentially =93break the kernel=94 sort = of changes in the next month? I have the following boards: boatloads of atmel, BBB, and RPI. This = covers the at91, imx6 and broadcom directories. I also have a allwinnner = board, but I=92ve never got it booting FreeBSD. Likewise with a = rockchip. I have some marvell gear too, but it is buried deep. This = leaves a lot of other boards/SoCs to cover... Warner --Apple-Mail=_5F91CE42-E6E1-4494-8C16-A1B59B4D38B4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4QW7AAoJEGwc0Sh9sBEAO/gQALEHFKL/4e1k6Yg9mDbifbF/ fJ7Fc2ZGBXc3EuOO6IX+Cmj88Yd+ohAilb9InxISd9o5YAsDJQs6V67k9B23mIcN 4ydM3LPtnKyGyZEqMTQSol+O34Vr8kfFToZWTNap436nt58qWP9XTxTdd9E2Fksz e/KjvQRMJr8rbpig3+kRPw9fijsiOz0zmSSoLPU9lnVWZrvw2uZS+NaZpgDqcxsn gtpWT3dRG/zyRV2eV9gbeulI2ZkkXP+NpSG/sjFLMiZC+LSV9qqtmSqZBrrPelVq 1KdjJW/pRskikXBE8q8odsNkqfLURQF+9EJqUFuB6PxTvUpYcxxVfS/xgLRzfQqu MZFW2AR1QuuTy6/rJ14hjnwxzSvk7GHgpzQNO8XbRg8cgynSQWE0rgP007YDzRoF 82lku/oVrJTE7TI2eq8tk35xBrGlpvjycbGG38fmNDkN8YcJ/iDs0kvY37DfJKUo irX1LdxNj5uZX7uMSw/3GeOwVsgsiaKyJ7l78diA+i8MEhzi52X4Copq57dmW40X or7gehZbFe/WhCI/WhBQPF3NYCeRPhrpRMTa/kGgeYNXraRHQWaEBwQPK7xb6BQd D+UdkQWa8RO0UwpppeSRD85NIr97jXFG7b/JZp5BoY0WXtgIDHU6lmtUKegEXg7G gftMOhlmWNV3pmge79Gq =tav9 -----END PGP SIGNATURE----- --Apple-Mail=_5F91CE42-E6E1-4494-8C16-A1B59B4D38B4-- From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 16:36:11 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 6FFA475F for ; Tue, 5 Aug 2014 16:36:11 +0000 (UTC) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (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 38BB625AD for ; Tue, 5 Aug 2014 16:36:11 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id j17so897205oag.12 for ; Tue, 05 Aug 2014 09:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LP3kNbVXyJmYd+rywcYDNiq3DJ4UTwnS5HEtCHeVYdY=; b=zSn5Ul9SspjBhPMFoCdP+ziHC3YJ6BNXYgjp7P+1O4NW2a+YUkihyuKz7/VHsrAqso 8Se7JOjVTMvG+/g1tP5X1/WTwBOupMRMKdz/iAbTZan1Vzq1wenc3omupzPuZTrVY/wN kY+ZOp1ZrIJz+5x8D5471FbBa/ENBPi2hTlzbSom5wqXh+/V9VRBp3WSNpGKVcCVRjSi VHPmTz2/QBz2SE2dhUpyDeP0R/fZkmQpbad1XD6iGjtYA3N5vjlFy9NZjo4MBzAYEDwM 80Emo6Srn7RjvbIF6PBuUAof6QnUfG5DSXuTJxdAYpSRKqHKDggWwLUlW1kXARQCcEKz PZlg== MIME-Version: 1.0 X-Received: by 10.60.65.97 with SMTP id w1mr7516658oes.2.1407256570281; Tue, 05 Aug 2014 09:36:10 -0700 (PDT) Sender: r.c.ladan@gmail.com Received: by 10.182.146.5 with HTTP; Tue, 5 Aug 2014 09:36:10 -0700 (PDT) In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Date: Tue, 5 Aug 2014 18:36:10 +0200 X-Google-Sender-Auth: cyNEK_9UTI6_Qwtz_NfW8_qvg0A Message-ID: Subject: Re: What platform do you use? From: =?UTF-8?Q?Ren=C3=A9_Ladan?= To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm 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: Tue, 05 Aug 2014 16:36:11 -0000 2014-08-05 18:26 GMT+02:00 Warner Losh : > Greetings, > > I=E2=80=99d like to know what platforms people use FreeBSD/arm with, and = if you=E2=80=99d > have time to test some potentially =E2=80=9Cbreak the kernel=E2=80=9D sor= t of changes in > the next month? > > I have the following boards: boatloads of atmel, BBB, and RPI. This cover= s > the at91, imx6 and broadcom directories. I also have a allwinnner board, > but I=E2=80=99ve never got it booting FreeBSD. Likewise with a rockchip. = I have > some marvell gear too, but it is buried deep. This leaves a lot of other > boards/SoCs to cover... > > For what it's worth, I have an RPI-B running 10.0-RELEASE at home. Rene From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 16:43:58 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 24403840 for ; Tue, 5 Aug 2014 16:43:58 +0000 (UTC) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (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 DF93C267F for ; Tue, 5 Aug 2014 16:43:57 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id a141so808655oig.9 for ; Tue, 05 Aug 2014 09:43:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OgESEKXTs/A96z3kfz92HxxFDC/bekl+nXECJYnILdM=; b=eXAxa1820SpnkuYpxplPnDJPzn0NMjaPHrnyuZgxcICdvZx7emtUbTPQO48BlQ+ZCL yD9fZNjRFZHz0/Iz9ncoZoCCvoyKe4NhBhlBnl4MEW17oaIiEaGVpN38yoJNzQUlgF4C AAcs3mesC2cYCLtySX8/OO7SE33h7y8sHQBPrgSaeVsdNOOvm2j8ky2qlE2iLEAvWMbU jtOxD1T/r4fBo3Ai2rd1Yn+zMB9nRG9kCLgkjBizVVj5vZitpInrwUAxVIZoB/fR4tlM me99qkNCrFd4eTUEKLwWWQvmHAFEfFOSgQL4KTeoB/8aMZlZ1AkmQ8GBOhjFeNtMDljc 6nAg== X-Gm-Message-State: ALoCoQlbcDq0EOMFWZrt5PF0awB8LH/otuOzYROMMeq/qKbqVUJ2zsx4i72HKtgzYtciG97DVPcb X-Received: by 10.60.34.98 with SMTP id y2mr7448810oei.9.1407257030891; Tue, 05 Aug 2014 09:43:50 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:6cfb:7a33:fc1a:e4fd? ([2610:160:11:33:6cfb:7a33:fc1a:e4fd]) by mx.google.com with ESMTPSA id ej4sm4679412obb.28.2014.08.05.09.43.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 09:43:47 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1972.3\)) Subject: Re: What platform do you use? From: Jim Thompson In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Date: Tue, 5 Aug 2014 11:43:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5E91AFF0-B73B-40FB-B021-CF9E34A3A044@netgate.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1972.3) Cc: freebsd-arm 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: Tue, 05 Aug 2014 16:43:58 -0000 > On Aug 5, 2014, at 11:26 AM, Warner Losh wrote: >=20 > Greetings, >=20 > I=92d like to know what platforms people use FreeBSD/arm with, and if = you=92d have time to test some potentially =93break the kernel=94 sort = of changes in the next month? >=20 > I have the following boards: boatloads of atmel, BBB, and RPI. This = covers the at91, imx6 and broadcom directories. I also have a allwinnner = board, but I=92ve never got it booting FreeBSD. Likewise with a = rockchip. I have some marvell gear too, but it is buried deep. This = leaves a lot of other boards/SoCs to cover... If you want a Gateworks, I think I have one or two more here. In other news, likely by the end of the month, we will be shipping BBB = with FreeBSD pre-loaded. In a couple months, we will have an anodized = aluminum case for same=85=20 Jim From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 16:51:39 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 DA1E4C6D for ; Tue, 5 Aug 2014 16:51:39 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (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 A9D822789 for ; Tue, 5 Aug 2014 16:51:39 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id y13so1627873pdi.11 for ; Tue, 05 Aug 2014 09:51:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=3cdZb6jENS5Z5/vLiNI1Wcm6BINUL8IY1BjWlettU/g=; b=bRcV8erMLuTvOHdfr0cXn6AyGzjYylWuZwSHHweKYsyoEplsQoGWjHEhpk9OUnQq2x 3dbrOHno8ERQqeD6uiIfXgzCc+dNIXWg1toxrfcyIxf8Q1Ix0FPeQzoMR+zHL8rGdoeu YfbwKy/V5bvB/mKMEc0FUnS/CffJruqcs2o15Wv1zfReLP3PE5yPVuNLQRI4aIphy4z9 6KDGrTXLXaeiGLdI48ZBl/yYm6uYg/Nm+bl4qa/mvMOpKSvDLYBLW96JB+t/e6salzt3 PeN6bNfuzrjLqKATslvotFdPXHtUNzRQqtyjLc6vlO/p0nXazHYe0pSU+BlXjCHLgorl 26MA== X-Gm-Message-State: ALoCoQl0svqnhgtrDAapctnvJUm3tR8hw+QtbyEBoX/qAuzZ+E9dxLlIfOhfo6NteH5MYpWpy68I X-Received: by 10.66.236.35 with SMTP id ur3mr5079151pac.35.1407257173924; Tue, 05 Aug 2014 09:46:13 -0700 (PDT) Received: from [10.64.25.9] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id x10sm1727334pdp.24.2014.08.05.09.46.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 09:46:13 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_46FD8C20-8A14-4C14-A340-4A8552C419CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What platform do you use? From: Warner Losh In-Reply-To: <5E91AFF0-B73B-40FB-B021-CF9E34A3A044@netgate.com> Date: Tue, 5 Aug 2014 10:46:11 -0600 Message-Id: <40901E3A-C5C6-4B3C-A347-612C6CE361B9@bsdimp.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <5E91AFF0-B73B-40FB-B021-CF9E34A3A044@netgate.com> To: Jim Thompson X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm 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: Tue, 05 Aug 2014 16:51:40 -0000 --Apple-Mail=_46FD8C20-8A14-4C14-A340-4A8552C419CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 5, 2014, at 10:43 AM, Jim Thompson wrote: >=20 >> On Aug 5, 2014, at 11:26 AM, Warner Losh wrote: >>=20 >> Greetings, >>=20 >> I=92d like to know what platforms people use FreeBSD/arm with, and if = you=92d have time to test some potentially =93break the kernel=94 sort = of changes in the next month? >>=20 >> I have the following boards: boatloads of atmel, BBB, and RPI. This = covers the at91, imx6 and broadcom directories. I also have a allwinnner = board, but I=92ve never got it booting FreeBSD. Likewise with a = rockchip. I have some marvell gear too, but it is buried deep. This = leaves a lot of other boards/SoCs to cover... >=20 > If you want a Gateworks, I think I have one or two more here. >=20 > In other news, likely by the end of the month, we will be shipping BBB = with FreeBSD pre-loaded. =20 Cool! > In a couple months, we will have an anodized aluminum case for same=85=20= So I take it the Altoids can just wasn=92t cool enough :) Warner --Apple-Mail=_46FD8C20-8A14-4C14-A340-4A8552C419CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4QpTAAoJEGwc0Sh9sBEAb58P/ivYZJHMEQIsLotaAjMkUm83 T2gRON/ScqHOdpK0T/x7DrtCQrg//AohWjdnt0QtSr2pA1iE8c4rBX1bZUCFyCSs V9BPRp3xlem+PstoHYO69gK/zAXi/9j+f5eKVFNRh86yQkHGaYeg00LM6u0Sx68n KXTTvVXQKgalq5xYFApHTrseAEQFOnZeUK3iKHf8+r23hGTDNMV2srD/hTBHpfZW VRdwfQeQ7IfhzFiN2OOgvtMxVGn/A5Mso4yRFKGKx+ujV/JJeIR5f/RMDTNoBK9O CG7uXIJ8EB8wUYA8NS0HcLk8FGzuXZ6qKYSULPWdBRN7jtZb+atT69bOf4aqsfCm LcDZTB+KQrDXEx2s1Fjj4ulsBAj3bR7uBIx5VZYSYroXID5rqsbQbqbHCr59FBsN NOxnYq4kiSLfnQVV154ygKpwWv5Ler+ayZhZeltfv539kjf/sQyVytk7lsqG6K3/ T9wiI1oDyy97Kyr3kELPfbrX1VunKOv2Jf2AXWu2Iq9Q5Ow4c5DR23LZ6Eo5EeIb sCqXeihxvcmeordOpLSivoY/uIY152vkmrPjGvKMIudYC9wzLpDDO9UKWVVgOTBj OPGCxonSrSJStKlX5EjhUQcypWRtJ4kan/VHqHeIQDiGFuY7Dz1tKkqyn63xYsb7 lc+5lpDrs+IGOMsN2WT+ =OeIy -----END PGP SIGNATURE----- --Apple-Mail=_46FD8C20-8A14-4C14-A340-4A8552C419CE-- From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 17:17:51 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 117975FD for ; Tue, 5 Aug 2014 17:17:51 +0000 (UTC) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (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 CB54E2A20 for ; Tue, 5 Aug 2014 17:17:50 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j17so934627oag.28 for ; Tue, 05 Aug 2014 10:17:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=htvuLaF804aFrre7jpHeZHQG3th+8UHKMvGdVlk7HU4=; b=L5yjn96slKlWVghWBXXJxNazUiHvDgb6OQA3ebfonKNFcoyB12SLSYFVIRfFsUu45i He+5dr6bN0WHCRNEh614zt5xg3HsInG05XpMEnJzHRU1ZbMgeezz0lV+oZj/PKj2XLGU HRrJj4IXxvssZX/ow2LazGAp7kjM7CFN6FWvtpUf8fqkGPuR2EfeuoQUN2yF8uduwn3E dPIE2l0XdJ08XrrflSscNrVGjgGfqdMDIelApVd3Rrgn3T/KP4d1qwAoPwwu5YkROggj hzqC/Xh8Smz2jMVxwJi3jAsLtd2yhdn9BL0J6z2bEYpiuM6fqrwDRoZSzt6/FNqUuEtd LugQ== X-Gm-Message-State: ALoCoQlHqaL6bayvh3WLhkMDpeRjsogPNUqf5sT9g6g/Rd8YJTsjXfG5aEMY2BiSbHQf4F0NDplg X-Received: by 10.60.63.233 with SMTP id j9mr7253157oes.23.1407257267320; Tue, 05 Aug 2014 09:47:47 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:6cfb:7a33:fc1a:e4fd? ([2610:160:11:33:6cfb:7a33:fc1a:e4fd]) by mx.google.com with ESMTPSA id y6sm9060971oej.8.2014.08.05.09.47.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 09:47:43 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1972.3\)) Subject: Re: What platform do you use? From: Jim Thompson In-Reply-To: <40901E3A-C5C6-4B3C-A347-612C6CE361B9@bsdimp.com> Date: Tue, 5 Aug 2014 11:47:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2112ABBD-9663-40C0-B87B-B29C0B554D06@netgate.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <5E91AFF0-B73B-40FB-B021-CF9E34A3A044@netgate.com> <40901E3A-C5C6-4B3C-A347-612C6CE361B9@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1972.3) Cc: freebsd-arm 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: Tue, 05 Aug 2014 17:17:51 -0000 > On Aug 5, 2014, at 11:46 AM, Warner Losh wrote: >=20 >=20 > On Aug 5, 2014, at 10:43 AM, Jim Thompson wrote: >=20 >>=20 >>> On Aug 5, 2014, at 11:26 AM, Warner Losh wrote: >>>=20 >>> Greetings, >>>=20 >>> I=92d like to know what platforms people use FreeBSD/arm with, and = if you=92d have time to test some potentially =93break the kernel=94 = sort of changes in the next month? >>>=20 >>> I have the following boards: boatloads of atmel, BBB, and RPI. This = covers the at91, imx6 and broadcom directories. I also have a allwinnner = board, but I=92ve never got it booting FreeBSD. Likewise with a = rockchip. I have some marvell gear too, but it is buried deep. This = leaves a lot of other boards/SoCs to cover... >>=20 >> If you want a Gateworks, I think I have one or two more here. >>=20 >> In other news, likely by the end of the month, we will be shipping = BBB with FreeBSD pre-loaded. =20 >=20 > Cool! I was hoping you=92d like it. >> In a couple months, we will have an anodized aluminum case for same=85=20= >=20 > So I take it the Altoids can just wasn=92t cool enough :) the laser etching doesn=92t look good on top of paint. From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 17:19:23 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 7475265B for ; Tue, 5 Aug 2014 17:19:23 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (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 4ACF22A31 for ; Tue, 5 Aug 2014 17:19:23 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id w10so1706210pde.9 for ; Tue, 05 Aug 2014 10:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fEHlxU3G/6jC6KfXxASy05MX1/qbUWJDHVQoD/it+7k=; b=mojpzj/7ZnfyM0KqSsY2k9poTHOgy43RmyumXVPgMNXqqp5sLOY2lzg1mN7LDRp5cw 4p4SGAgDK4+dZzRn3fOGM05wo9pV4U38lhkU85b4eXj3fEXwG8slBkLrZBsqAMxFCWRD uDZuOiBxfk8TTOeBXIvin72CTFHArdOidiq9a9b06bTDrWBQDGl7B1ygiQvPy0pSSfmj TPN9wjL7WJ6KGrcYDTh5lDkK2pnnn2cTaDKgQLx7WX4gxP5HHAakFS7XOqYzplU25NYW um/Wag1pWDXa79iWxvv5IhlcRChOZz44HKEJh4UhUScFkyyYqyO3tqKmBD8Ktf3Xw/d3 KCXg== X-Received: by 10.68.245.162 with SMTP id xp2mr5887077pbc.60.1407259162383; Tue, 05 Aug 2014 10:19:22 -0700 (PDT) Received: from [192.168.40.122] ([209.12.167.3]) by mx.google.com with ESMTPSA id aa4sm2632652pbc.22.2014.08.05.10.19.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Aug 2014 10:19:21 -0700 (PDT) Message-ID: <53E11217.4030003@gmail.com> Date: Tue, 05 Aug 2014 10:19:19 -0700 From: Jungle Boogie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: What platform do you use? References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <5E91AFF0-B73B-40FB-B021-CF9E34A3A044@netgate.com> In-Reply-To: <5E91AFF0-B73B-40FB-B021-CF9E34A3A044@netgate.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Tue, 05 Aug 2014 17:19:23 -0000 Dear Jim, Freebsd-arm -------------------------------------------- From: Jim Thompson Sent: Tue, 5 Aug 2014 11:43:46 -0500 To: Warner Losh Cc: freebsd-arm Subject: Re: What platform do you use? > > > In other news, likely by the end of the month, we will be shipping BBB > with FreeBSD pre-loaded. In a couple months, we will have an anodized aluminum case > for same… Will it be freeBSD-STABLE? Will you likely release new images every so often or is that not expected? > Jim > -- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 17:48:38 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 20B3ED8B for ; Tue, 5 Aug 2014 17:48:38 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id D06082ED0 for ; Tue, 5 Aug 2014 17:48:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N9U0072GHGT3T80@mta.uoks.uj.edu.pl> for freebsd-arm@freebsd.org; Tue, 05 Aug 2014 19:48:29 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Tue, 05 Aug 2014 19:48:29 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Tue, 05 Aug 2014 19:48:29 +0200 (CEST) Date: Tue, 05 Aug 2014 19:48:29 +0200 From: Jakub Klama In-reply-to: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Message-id: <7784a8d74bb5ea89c4903759eadd7f9a@uj.edu.pl> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Subject: Re: What platform do you =?UTF-8?Q?use=3F?= To: freebsd-arm@freebsd.org User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl 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: Tue, 05 Aug 2014 17:48:38 -0000 On Tue, 05 Aug 2014 10:26:35 -0600, Warner Losh wrote: > Greetings, > > I’d like to know what platforms people use FreeBSD/arm with, and if > you’d have time to test some potentially “break the kernel†sort of > changes in the next month? > > I have the following boards: boatloads of atmel, BBB, and RPI. This > covers the at91, imx6 and broadcom directories. I also have a > allwinnner board, but I’ve never got it booting FreeBSD. Likewise > with > a rockchip. I have some marvell gear too, but it is buried deep. This > leaves a lot of other boards/SoCs to cover... Hi Warner, Currently I own: * RPI-B * Cubieboard2 * Pandaboard * EA3250 Ping me if you want me to test your changes on one of these. Jakub From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 18:04:08 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 BF61A15E for ; Tue, 5 Aug 2014 18:04:08 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (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 865802082 for ; Tue, 5 Aug 2014 18:04:08 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wm4so981660obc.2 for ; Tue, 05 Aug 2014 11:04:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/QsokkPwA0Sl9lWPFNn09H/+QoXiEIJ+MFmT5+baHu4=; b=GOJAgro0KMiageBW+1c0JPe+qoRtZbHm0qx/xdTiLmJK/VOMhVcQXjK0dOz1VTmdlo lXgrl7V59IbkwoyUDBINJpzKdqf/gZ2CDF2copiO7Q5dhkSrTHOJbxQrR5PsJUC1rt3r D/aYRwxkcm2o0Ebwe8tNMSn721phP3FLVdV62ZPBoJ3m4+1DKyHWyIPf2ytDM13YIiwH MZEnEPpHIKqp0DEUlDJPT1Y8mvU3pp0ssIhHF0rmdD27VGycJJo8AW0drkrJucTOegtJ ev8M62maGGFybWrocJPAE27c1yDsSQ2Wg3ZAVcWOTbEEMPQ9i0BGf7IKo57HQt9VA+sa fmfA== X-Gm-Message-State: ALoCoQmDWh6rrL8XW5+rzXExxRANzXIO+0z1+XPoXf/nuxWx0fZK6VTFAfqwtOvQ6dssStWs5Wyx X-Received: by 10.182.94.204 with SMTP id de12mr8060249obb.66.1407261477574; Tue, 05 Aug 2014 10:57:57 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:21ea:ac27:44df:3558? ([2610:160:11:33:21ea:ac27:44df:3558]) by mx.google.com with ESMTPSA id c4sm9720817oez.10.2014.08.05.10.57.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 10:57:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1972.3\)) Subject: Re: What platform do you use? From: Jim Thompson In-Reply-To: <53E11217.4030003@gmail.com> Date: Tue, 5 Aug 2014 12:57:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9EB69D1F-BEA8-4542-9D00-2D148B1F443E@netgate.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <5E91AFF0-B73B-40FB-B021-CF9E34A3A044@netgate.com> <53E11217.4030003@gmail.com> To: Jungle Boogie X-Mailer: Apple Mail (2.1972.3) Cc: freebsd-arm@freebsd.org 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: Tue, 05 Aug 2014 18:04:08 -0000 > On Aug 5, 2014, at 12:19 PM, Jungle Boogie = wrote: >=20 > Dear Jim, Freebsd-arm > -------------------------------------------- > From: Jim Thompson > Sent: Tue, 5 Aug 2014 11:43:46 -0500 > To: Warner Losh Cc: freebsd-arm = > Subject: Re: What platform do you use? >>=20 >>=20 >> In other news, likely by the end of the month, we will be shipping = BBB >> with FreeBSD pre-loaded. In a couple months, we will have an anodized = aluminum case >> for same=E2=80=A6 >=20 > Will it be freeBSD-STABLE? Will you likely release new images every so = often > or is that not expected? 10-STABLE. My rough plan was to keep semi-current with the public = images. From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 18:24:41 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 AC91CB1F for ; Tue, 5 Aug 2014 18:24:41 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86A0622BB for ; Tue, 5 Aug 2014 18:24:40 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s75IOc5S024901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2014 11:24:39 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s75IOcK7024900; Tue, 5 Aug 2014 11:24:38 -0700 (PDT) (envelope-from jmg) Date: Tue, 5 Aug 2014 11:24:38 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: What platform do you use? Message-ID: <20140805182438.GP88623@funkthat.com> Mail-Followup-To: Warner Losh , freebsd-arm References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 05 Aug 2014 11:24:39 -0700 (PDT) Cc: freebsd-arm 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: Tue, 05 Aug 2014 18:24:41 -0000 Warner Losh wrote this message on Tue, Aug 05, 2014 at 10:26 -0600: > I?d like to know what platforms people use FreeBSD/arm with, and if you?d have time to test some potentially ?break the kernel? sort of changes in the next month? > > I have the following boards: boatloads of atmel, BBB, and RPI. This covers the at91, imx6 and broadcom directories. I also have a allwinnner board, but I?ve never got it booting FreeBSD. Likewise with a rockchip. I have some marvell gear too, but it is buried deep. This leaves a lot of other boards/SoCs to cover... I have an AVILA board that I'm keeping current and can test things (I netboot, so testing kernel changes are quick)... I also have a BBW that I occasionally test w/ but since I haven't got it netbooting, the cost of building an entire image and writing it to SLOW microsd prevents me from testing as much... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 19:47:11 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 63130517 for ; Tue, 5 Aug 2014 19:47:11 +0000 (UTC) Received: from nm14-vm2.access.bullet.mail.gq1.yahoo.com (nm14-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0574C2D5B for ; Tue, 5 Aug 2014 19:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1407268029; bh=HpJda8o3frFzsK9Md43yc2S17/+cNNDn9XDPMpOvo2A=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=i64OC5WYUl9160veAgkyoVH9RDVKlYZqwCCXN7QpLad7FqTCI99Fpyzvgkhi7EHi/qn8jVUpV098Ph4Q+GsPa1Ihg2qBjjAzHR4fOCe7+VlAL1Q9SvAQpSCmM9saS6T5ZJceZHVvuStTT6ej6pEuIhUKt3RDml+cmb5+mMH+dmOd1OAltiSnnbmApiRUIxalqtRrdk6iAnzeZ5hlmNA9UTZaL6P5CHF66vKwbOMPEvr0bnfCqAkYmHqwrkbYcgllPks2B/6NFStk/C4yQ4/nhBTmAcuu+El0R7p2OvTf1hEW1zu+c20reGkvOFSNY/hZrymwteilz9ZwrcVbPrxN8g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=sbcglobal.net; b=W8a5YRVavb1+1zJjcLpJ61ghO6UHtRUkQ7lcyXuf8JQbJeaddrdK3s13+oPo7lW2SeFPH8r5lAJ2p6hkByszNYLvauMo+Y1YRg1UnU8LFIWJp505/vaemxKh75O4HAUiDUie3OS4TFyoON7Yslifa9g0g40ZwI9Pcg8O69DVlrrvL6qfN5p1TMS0WHTC9YGkZIjSEaa4+EcA/B/FSkQ6NE8XsipwqcJDCuBi/71xPuKlkz3Z1lutXxIkeQtSngQX1YGipl2ig0ZulUsSaYtX+iygIL82q53yP/1kh6EIP6P2tiZbk3AaeM7dJnewbYMwXO6Nd+ajszOgMUqtiH6K7Q==; Received: from [216.39.60.175] by nm14.access.bullet.mail.gq1.yahoo.com with NNFMP; 05 Aug 2014 19:47:09 -0000 Received: from [67.195.22.117] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 05 Aug 2014 19:47:09 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.gq1.yahoo.com with NNFMP; 05 Aug 2014 19:47:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1407268029; bh=HpJda8o3frFzsK9Md43yc2S17/+cNNDn9XDPMpOvo2A=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XNipAsaNaxAGhk0PT9yH8ZW4R3X7S7fy0WiJICruYn2buIZf/QbHa9YLXyxg2jQ2qnApddnrJfcbj14AipWVJRCPnS+oiFTJwsxAWlKNf5+oUiF0hGfGzKNvIC985Kl3cmOowskRy+umGz4eCwHtJbFfp8Vs7JQN7VUONPOlQtY= X-Yahoo-Newman-Id: 921960.96002.bm@smtp112.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Jont3UUVM1karFfOHsb5Dw_EI6Iw8.yzuOo3H3cRLRNU4Sl lGl1P4tJQVXyjkznQp4rarmXeAX63EvBAMKnMrF5xan7GvyyRvA_VTCJwohR LmJuOjLugMraKgijvFiHboNpBYn21q95.104W190vqwkgSz6Ohr2tnYMwgUa dWpmjbSsE1gMf3HGsz0s9S7ZTSPpxmBlalYzNAwiR5wurDQ_8kGcNi.lY27O BGHrmhF2De.7xTRUXPtgblPYXCHCvHZpsQP35a5eUUKXVSNeA55iE4IbyqNs huFl9tep8pfKuzQtpwO_XT8R4GzXMbDZMeQ9cstpH4cAJitVt0DlQC1Lh1j2 y.rW3lROADKMriXyuOCP9V1FrmbbgaY.FiHI3AdDxjB9P1_k1GF_AoxqVAgv SfHO.p96rVDD8_cEqcJkZgmeGZh4yWidAT0T0BqvpLqwd8Zh57onlTx6ntip sSTOBPGLZmOTbP62j2GsVC6T6IMhMPezDSTBLml8nctxlx9RQrDa0dTJYAad mqcP94hkqrK76DMCQGhBfalTOLdr1Kl5IfZVcSShQcXlpU6447lc1ye9bKQ- - X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Message-ID: <53E134BD.50902@sbcglobal.net> Date: Tue, 05 Aug 2014 12:47:09 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , freebsd-arm Subject: Re: What platform do you use? References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Tue, 05 Aug 2014 19:47:11 -0000 On 8/5/14, 9:26 AM, Warner Losh wrote: > Greetings, > > I’d like to know what platforms people use FreeBSD/arm with, and if you’d have time to test some potentially “break the kernel” sort of changes in the next month? > > I have the following boards: boatloads of atmel, BBB, and RPI. This covers the at91, imx6 and broadcom directories. I also have a allwinnner board, but I’ve never got it booting FreeBSD. Likewise with a rockchip. I have some marvell gear too, but it is buried deep. This leaves a lot of other boards/SoCs to cover... > > Warner > Hi. I can do some testing on the Zedboard or MicroZed, Zynq-based boards with Cortex-A9 cores. --Thomas -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Tue Aug 5 22:02:20 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 2D28A541 for ; Tue, 5 Aug 2014 22:02:20 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (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 B680E2CEF for ; Tue, 5 Aug 2014 22:02:19 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x48so1741597wes.19 for ; Tue, 05 Aug 2014 15:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:hackerspace:user-agent; bh=0fSY8sQsFwy2tZofwlIkMbv3vtXc/SL8PuysZh5eIVY=; b=IaWvtgyhagdtSGZtyU7SywnwS+r8UdONUkpXYiHgnJASQC+KK9KTlLnedxEGye17W2 nCLXOKKwspcQ2inSWnwg6AxrdCm7H9NqGttWv3JS/MflbsAb4SDC8QfKh1mr5qB18DCg Kc/T709PXEbKJccSR7aB9XGRFea8u5fROl5LXcn8uXmWTphusiKSq8qFy1sE/gqxCdZB s77iBnFpdGF726RDZKlO6Ka+camWzNs2gY0UdSU8mR30Rfc4e/bVfofZ4ISSYyxlrFdc LCod6MOt1H1DZSTGA7r14tQRBpOVPoU3xl6zfhcdDWBjT+yjejmfkRIaVmGdBSihjqvT SsTQ== X-Received: by 10.180.87.199 with SMTP id ba7mr10292910wib.49.1407276138105; Tue, 05 Aug 2014 15:02:18 -0700 (PDT) Received: from gmail.com (host31-49-197-44.range31-49.btcentralplus.com. [31.49.197.44]) by mx.google.com with ESMTPSA id kw1sm7001785wjb.19.2014.08.05.15.02.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Aug 2014 15:02:17 -0700 (PDT) Sender: Tom Jones Date: Tue, 5 Aug 2014 23:02:13 +0100 From: Tom Jones To: freebsd-arm@freebsd.org Subject: Re: What platform do you use? Message-ID: <20140805220212.GA7904@gmail.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Hackerspace: 57North Hacklab User-Agent: Mutt/1.5.23 (2014-03-12) 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: Tue, 05 Aug 2014 22:02:20 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 05, 2014 at 10:26:35AM -0600, Warner Losh wrote: > Greetings, >=20 > I=E2=80=99d like to know what platforms people use FreeBSD/arm with, and = if you=E2=80=99d > have time to test some potentially =E2=80=9Cbreak the kernel=E2=80=9D sor= t of changes in the > next month? Currently I have * Raspberry PI * BBB * Chromebook Snow I can probably get access to otherboards if they are in question. --=20 Tom @adventureloop adventurist.me #pragma summon cthulhu :wq --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - https://gpgtools.org iQIcBAABCgAGBQJT4VRkAAoJEDetXgJOHpB8nTsP/jq8Z4vvDVX8f8RtLBplMnKS 6NebHvhZRnyz485IN1A50tJ6wQsfevObrg2fcGS39TUtlAgWXyrPhaTTyQFSrg8E IawijmvfhQ3Msr32Ua57siZg7pyLY40XYLhra76oC1v7qhZTIBC9WN19+149DTlr K3eR0HtEPl+l63Icuz3dF7iXfpUA6P7iDq6HjQ2bVOBwyL7+YrOk+lfETWD7A6Mc k2hRMzkhJigGmTqO/TReFYrREIHo8XG8oB52qinK9LeEC50NYw3rF5FpocFrrlsT XpRudySvO9N1W+FQeNhlxkX2GS9qapVz3a5XjUtGP6Rknjm7E2jn1XYKycQf0QN0 wBDADyCqalJgS0hvETJZjgk5yBCXZLjYX+HUxWphHyOnNLEWGIT8NhsrvNdpxHvb WlpXvL+djepX7OVuQnRg0Lehn6vGLF029noP3QeYnrIuGOIzsv4GlKlJLdT7vh3O m3YM+nXsHiumRWF8pOesNdpYyx0TUadxBvH+tR1Xjz8FMWKq3NzPwFcApTr9ud/R 1vxdTFfcWJxYmpn3xxMnFxPZRMdT/LTKugVEtFwoSDRzPJRYqV8/IZOOze3hcBFW eoXfhDovxAM0HHL8rNzTMXPJHf+4dEILa7qQQ5y5Ei/vSX4klmA8S0UOETMhjvtI SvvNKaz7cRhFgQVQMxkB =FmaM -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 01:31:16 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 5F642A61; Wed, 6 Aug 2014 01:31:16 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (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 07E57260B; Wed, 6 Aug 2014 01:31:15 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id w8so1816866qac.2 for ; Tue, 05 Aug 2014 18:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V66ZdRmlNA7/ifheqqhCIyAWbrpabiFTZ9uGlxAhl30=; b=iopDyShWS437jqGMVj60ZXViaKRb8792jxTI0oRju+kpRo2ZELYphSENbH8a5WcoZM FhxTCsEaMRSBkxWN+cL3YZSSPbS1uqzU6//E2YHe4MBc0pf6diIpqEAfGJF0WleBGdte 9Ga9M35ss68Xoui9Mt2vXllYfOdvyhWH0l6GU1nrVX0xD+EUkpfwtFywbX3BNCsn9Yz7 4aHSYJILPDJ47qamNhZUOeq9ZBLiatQ7lViKFWc768yMHdabKQWP+41/XZYueUH7FrBi t1aukBHM5+NlMWGmCoDYyLL9OW4S3BxgPS9Lb8v8BUIiACZoYy8S26ZRN6FwHYtU89zU 031A== MIME-Version: 1.0 X-Received: by 10.224.88.71 with SMTP id z7mr12026459qal.94.1407288675067; Tue, 05 Aug 2014 18:31:15 -0700 (PDT) Received: by 10.140.87.241 with HTTP; Tue, 5 Aug 2014 18:31:14 -0700 (PDT) In-Reply-To: <1407182403.56408.297.camel@revolution.hippie.lan> References: <1407182403.56408.297.camel@revolution.hippie.lan> Date: Tue, 5 Aug 2014 22:31:14 -0300 Message-ID: Subject: Re: Two questions on Flattened Device Tree, newbus and device driver attaching From: =?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?= To: Ian Lepore , Thomas Skibo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org 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: Wed, 06 Aug 2014 01:31:16 -0000 2014-08-04 17:00 GMT-03:00 Ian Lepore : > On Sun, 2014-08-03 at 16:41 -0300, Matas Perret Cantoni wrote: > > 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.dts > > (here > > < > https://svnweb.freebsd.org/base/release/10.0.0/sys/boot/fdt/dts/zedboard.= dts?revision=3D260789&view=3Dmarkup > >), > > 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 > > < > https://svnweb.freebsd.org/base/release/10.0.0/sys/boot/fdt/dts/imx53x.dt= si?view=3Dmarkup > > > > ) > > > > ... > > 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 > > < > https://svnweb.freebsd.org/base/release/10.0.0/sys/boot/fdt/dts/p1020rdb.= dts?view=3Dmarkup > > > > ) > > > > ... > > 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 runnin= g > > on? can I add the CPUs definition in my DTS file?* > > > > 2) The 'compatible' property of a node, finding the driver and attachin= g > 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 > > < > https://svnweb.freebsd.org/base/release/10.0.0/sys/kern/subr_bus.c?revisi= on=3D260789&view=3Dmarkup > > > > ) > > > > I believe that the autoconfiguration system uses the > > fdt_node_check_compatible() function (from fdtlib > > < > https://svnweb.freebsd.org/base/release/10.0.0/sys/contrib/libfdt/libfdt.= h?revision=3D260789&view=3Dmarkup > >) > > 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 > > < > https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.= 1.pdf > > > > 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 b= y > 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 m= anufacturer 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 devic= e > > driver that supported > > fsl,mpc8641-uart. If a driver was not found, it would then try to locat= e > a > > driver that supported > > the more general ns16550 device type. > > > > > > *What I don't understand is how the system locates a device driver base= d > on > > the compatible property. For example the cpu node's compatible property > > ("ARM,MCIMX535") of the imx53x.dtsi example. More precisely: How can th= e > > system relate the string "ARM,MCIMX535" with the actual device driver i= n > > the file system.* > > > > I hope my questions are clear enough. Many thanks in advance. > > > > For #1, virtually none of our arm code uses the cpu information from the > fdt data, because we generally compile a custom kernel specific to each > cpu. We've been slowly (very slowly) moving towards a unified kernel > that can boot on multiple arm chips (or at least closely related chips > within a family), and that will make the cpu info more important some > day. > > Oh, I see. Now It is clearer if I take a look in /10.0.0/sys/arm/std.zynq7: ... # # std.zynq7 - Generic configuration for Xilinx Zynq-7000 PS. # # $FreeBSD$ cpu CPU_CORTEXA machine arm armv6 ... So #1 is solved. Thank you both! For #2, if you're looking for some big master table that maps compatible > strings to drivers, no such thing exists. > > Each driver source has one or more DRIVER_MODULE() macros that provides > some information about the driver. One of the things it provides is the > parent. The newbus system builds a metadata hierarchy that tracks which > drivers have described themselves as potential children on each bus. > > Usually a device's parent is some sort of bus such as PCI. In an > fdt-based system "simplebus" is an abstraction that can represent many > different types of buses (such as internal on-chip connections between > the cpu and internal devices). A hardware bus such as PCI has ways to > query the hardware to see what's connected. In the fdt world, simplebus > uses the fdt data to do this query... it looks at all the fdt device > entries that are described as its children in the fdt data. > > For each child in the fdt data, simplebus asks newbus to probe all the > drivers whose DRIVER_MODULE() said they could be children of simplebus. > The probe() routine of each driver has access to the fdt data for the > device simplebus is trying to probe. The driver compares the compatible > strings in that data to the compatible strings that it knows how to > handle, and returns a success/fail code from probe() to indicate whether > or not it is the driver for the device. > > Sometimes multiple drivers can handle the same hardware, so newbus > probes every child driver against every device on the bus. For example > a usb keyboard is a pretty generic thing, but a FooStar1000 keyboard > might have a special driver that understands extra keys. The generic > usb keyboard driver would return BUS_PROBE_GENERIC, and the FooStar1000 > driver would return BUS_PROBE_SPECIFIC. After probing all potential > devices, newbus chooses the one with the highest return value from > probe() as being the one most-specific to that hardware. (In reality > this doesn't happen much; usually only one driver returns success and > all others return an error.) > > -- Ian > #2 is way more clearer now, but I still can't see a few things: I can see the function simplebus_attach() calling newbus to create a child, probe it and attach it for each of the ftd nodes claiming to be simplebus compatible. Here is a snippet from simplebus.c: /* * Walk simple-bus and add direct subordinates as our children. */ dt_node =3D ofw_bus_get_node(dev); for (dt_child =3D OF_child(dt_node); dt_child !=3D 0; dt_child =3D OF_peer(dt_child)) { ... /* Add newbus device for this FDT node */ dev_child =3D device_add_child(dev, NULL, -1); } ... return (bus_generic_attach(dev)); } So there are two functions from bus.h being called: device_add_child() which makes a new newbus child, and bus_generic_attach(dev) which causes newbus to probe and attach each of the new childs of the simplebus node. I can see fdtbus doing the same thing for each node of the fdt's root node. Here is a snippet from fdtbus.c: /* * Walk the FDT root node and add top-level devices as our children. */ for (child =3D OF_child(root); child !=3D 0; child =3D OF_peer(child)) { ... newbus_device_from_fdt_node(dev, child); ... return (bus_generic_attach(dev)); _________ So until here I think I understand how the newbus nodes (devices) are being created and how the drivers are being attached to them. But when I print the information about system device configuration with devinfo I can see that there is a "nexus0" node and a "ofwbus0" node in the newbus hierarchy: root@zedboard:~ # devinfo nexus0 ofwbus0 simplebus0 zy7_slcr0 gic0 l2cache0 .... I think that the nexus0 node is created by this function: /* * Determine i/o configuration for a machine. */ static void configure_first(void *dummy) { device_add_child(root_bus, "nexus", 0); } (which is in the file /10.0.0/sys/arm/arm/autoconf.c and by the way I can't find any calling function to configure_first). And I guess the root node is declared in /10.0.0/sys/kern/subr_bus.c file: device_t root_bus; devclass_t root_devclass; But I can't find out how the "ofwbus0" node is created neither who is doing so! Thanks in advance. Best regards, Matias.- From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 08:02:23 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 1094D9F0 for ; Wed, 6 Aug 2014 08:02:23 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C69522136 for ; Wed, 6 Aug 2014 08:02:22 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6942D1FE027 for ; Wed, 6 Aug 2014 10:02:14 +0200 (CEST) Message-ID: <53E1E122.9040304@selasky.org> Date: Wed, 06 Aug 2014 10:02:42 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-arm Subject: Loading modules with KB920X panics Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 06 Aug 2014 08:02:23 -0000 Hi, I'm building a custom module for KB920X and it panics when loading because structures like Elf32_Rel and Elf32_Rela are not aligned. I added __packed keyword and the errors seems to be going away. Any clues what is wrong? .ko file can be supplied. FreeBSD-current --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 09:27:15 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 E6D1BDA0 for ; Wed, 6 Aug 2014 09:27:15 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (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 7DC5C2A9D for ; Wed, 6 Aug 2014 09:27:15 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id u56so2344480wes.28 for ; Wed, 06 Aug 2014 02:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Sml9XYSYNpnf+kzCBQKeBjuhv4jeb9Jr3kijcL2hWT8=; b=YkgHw++7El2dOVI5r8vf2KJyQvHVvccK5I8/1VgaQXodUcFCiS+5qcf/i9HLvKJpZR Fbr2LEcSHEA9EvdykxPmrD5uxDWocYcxYWwADw70AjtUdQqX+YHG+l89WKOF+u0Bol3F K181L+Tm/HUmhOxYgoKNbrXt7HLl7hmFWLts5a4Ik8+qt3p4UNoqcu1MrhY5oA9trXZ8 Os3+wVW5tKqESK9GhbQTP/t612VBia9xujok3DVryEmd5Gu3hOlD9ZDkNTdw8uaFud1k VT5ZAnudLOc7GXrs5SxA6O0uj6mWlvGmUIwJ1nVcadVXD9kVU051w5SrGwyqHRk+cr6N AtQw== X-Received: by 10.194.203.8 with SMTP id km8mr14098059wjc.51.1407317233326; Wed, 06 Aug 2014 02:27:13 -0700 (PDT) Received: from [10.52.39.192] (36-239.197-178.cust.bluewin.ch. [178.197.239.36]) by mx.google.com with ESMTPSA id i8sm4275937wib.6.2014.08.06.02.27.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 02:27:12 -0700 (PDT) Message-ID: <53E1F4EF.8040706@gmail.com> Date: Wed, 06 Aug 2014 11:27:11 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , freebsd-arm Subject: Re: What platform do you use? References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Wed, 06 Aug 2014 09:27:16 -0000 Am 05.08.2014 18:26, schrieb Warner Losh: > Greetings, > > I’d like to know what platforms people use FreeBSD/arm with, and if you’d have time to test some potentially “break the kernel” sort of changes in the next month? > > I have the following boards: boatloads of atmel, BBB, and RPI. This covers the at91, imx6 and broadcom directories. I also have a allwinnner board, but I’ve never got it booting FreeBSD. Likewise with a rockchip. I have some marvell gear too, but it is buried deep. This leaves a lot of other boards/SoCs to cover... > > Warner > I can help out with my Dreamplug... (Marvell Kirkwood), running CURRENT already, but it breaks every 2nd day for USB or filesystem reasons, so I don't know if it's stable enough to do the tests you'd like to do. Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 09:56:51 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 9B70941B for ; Wed, 6 Aug 2014 09:56:51 +0000 (UTC) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 659F62F68 for ; Wed, 6 Aug 2014 09:56:51 +0000 (UTC) Received: from linutop.bsdsx.fr (unknown [82.238.159.102]) by smtp5-g21.free.fr (Postfix) with SMTP id E70DBD48042; Wed, 6 Aug 2014 11:56:40 +0200 (CEST) Date: Wed, 6 Aug 2014 11:56:40 +0200 From: Freddy DISSAUX To: Warner Losh , freebsd-arm Subject: Re: What platform do you use? Message-ID: <20140806095639.GO27787@linutop.bsdsx.fr> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 06 Aug 2014 09:56:51 -0000 > Greetings, Hello, [ snip FreeBSD/arm platforms ] I have a OpenRD Client (Marvell Kirkwood) and follow -current. Regards From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 10:18:47 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 66BFEA93 for ; Wed, 6 Aug 2014 10:18:47 +0000 (UTC) Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) (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 279F721BF for ; Wed, 6 Aug 2014 10:18:46 +0000 (UTC) Received: by mail-yk0-f176.google.com with SMTP id 19so1484628ykq.21 for ; Wed, 06 Aug 2014 03:18:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=aSHtfQPQH+P32RybpJOES9wlq2gZF7npco9eMh4Q7iE=; b=M/qKSGY1elpMUA33echftxComt3mGmFk9QXrvWYOKlQLfCzXXt8YLxkV3gl+g5uEzF 9A1zG4El5H534upKIpZd912BatWEpY2hYHa66dfZ0fZpePSGrIKD6O2d7V0PbGqfUpLi /ghGIwaxwuqfNHXleF3kyhVvD0n7ZYlsUSP2gSHIRtvK5NytfrVBy7W/ukhFXjVOvtme nG/cpHmgAIYlU/OzigeQ5DqNJ/sZVfHBoKicBoo1b6GLaClFmbwndX4j9clmGcKkyg93 MfCcvWEv9hu8SqGi9nOwKqDdA4mit7PH35K1/cDvjwGAfYCz6rXFnM16a4kLh7nLKP75 R2sg== X-Gm-Message-State: ALoCoQlDz6PlxX5NhhZKz6ZA+llOSWZ6d40WiMyzyZ0TTZ0WWueKbMZ13sfyutpoetr85Ox+tx5Z X-Received: by 10.236.141.142 with SMTP id g14mr4095514yhj.186.1407320320493; Wed, 06 Aug 2014 03:18:40 -0700 (PDT) Received: from [51.129.101.156] (66-87-121-156.pools.spcsdns.net. [66.87.121.156]) by mx.google.com with ESMTPSA id k38sm934738yhg.13.2014.08.06.03.18.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 03:18:39 -0700 (PDT) References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <53E1F4EF.8040706@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53E1F4EF.8040706@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Jim Thompson Subject: Re: What platform do you use? Date: Wed, 6 Aug 2014 05:18:37 -0500 To: Mattia Rossi Cc: freebsd-arm 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: Wed, 06 Aug 2014 10:18:47 -0000 > On Aug 6, 2014, at 4:27, Mattia Rossi wrote: >=20 > Am 05.08.2014 18:26, schrieb Warner Losh: >> Greetings, >>=20 >> I=E2=80=99d like to know what platforms people use FreeBSD/arm with, and i= f you=E2=80=99d have time to test some potentially =E2=80=9Cbreak the kernel= =E2=80=9D sort of changes in the next month? >>=20 >> I have the following boards: boatloads of atmel, BBB, and RPI. This cover= s the at91, imx6 and broadcom directories. I also have a allwinnner board, b= ut I=E2=80=99ve never got it booting FreeBSD. Likewise with a rockchip. I ha= ve some marvell gear too, but it is buried deep. This leaves a lot of other b= oards/SoCs to cover... >>=20 >> Warner >=20 > I can help out with my Dreamplug... (Marvell Kirkwood), running CURRENT al= ready, but it breaks every 2nd day for USB or filesystem reasons, so I don't= know if it's stable enough to do the tests you'd like to do. >=20 > Cheers, >=20 > Mat FYI. I have BBW(1), BBB(n) Gateworks Avila (not running FreeBSD on it, but I was running RELENG-6 back i= n 2007, https://lists.freebsd.org/pipermail/freebsd-arm/2007-May/000558.html= ),=20 and 2 designs based on Marvel Kirkwood that aren't running FreeBSD currently= , either, but should.=20 I applied to AMD to get one of their 64-bit ARM dev boards as well.=20 -- Jim From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 11:58:15 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 F18F0173 for ; Wed, 6 Aug 2014 11:58:15 +0000 (UTC) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A56B2E85 for ; Wed, 6 Aug 2014 11:58:14 +0000 (UTC) Received: from mail-we0-f182.google.com ([74.125.82.182]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKU+IYN/2gD4YFreNhBTx1y8YeFslADh0p@postini.com; Wed, 06 Aug 2014 11:58:15 UTC Received: by mail-we0-f182.google.com with SMTP id k48so2565266wev.27 for ; Wed, 06 Aug 2014 04:57:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to :in-reply-to; bh=RZqOxYd3R13kL+njbrkgcCRNVVefYSJhnVzkOzBjxyE=; b=j+0l8gc3bWz6/BLt/n1t/hiCVFHEUemfwFo0DO1pxs4END5ZxP1Y46wtYp+frECSVb CiMcFqMrdp/AHKbUf0/57Hl2vN0zFxfwh6ZNuW+VpOh+sqoF9NHp9G09YEh/gC7tYGcn P9idg50OgDBbP8++53DD29sVvw97qQ65abhnYE7zQjbWwjdnNrn4G/4ip1jcWbMcmwo2 tqBNIL2EY4cWqS650CTGTpKi4k8W4DL9yWO4bFk9b1Hjbd+qJ4Xm92aAg3WeOeFGXpZD 5VDDiq4JDZENoDxhN4XqzMHXPpzQR4oOu/FBBuUt7LsqnG4fMCgZDYTrJLUg6JZoDEQm n+pA== X-Received: by 10.194.77.233 with SMTP id v9mr9038942wjw.129.1407267926638; Tue, 05 Aug 2014 12:45:26 -0700 (PDT) X-Gm-Message-State: ALoCoQlbWTVBiLcZyduH4rhZssQVE5yTXKXGR7g9n/8Kl5x74DghwzdGtO3pLdVYAAE5lxHOTrV6yPhsVEZ2wo6WLLt2XklBoWCXs+UOu1P3IMavVu1harmRGZEspJDJ/9oNqLK+6jGd X-Received: by 10.194.77.233 with SMTP id v9mr9038913wjw.129.1407267926406; Tue, 05 Aug 2014 12:45:26 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id d4sm10614886wiy.13.2014.08.05.12.45.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Aug 2014 12:45:25 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s75JjL1O096960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Aug 2014 20:45:21 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s75JjLaK096959; Tue, 5 Aug 2014 20:45:21 +0100 (BST) (envelope-from mexas) Date: Tue, 5 Aug 2014 20:45:21 +0100 (BST) From: Anton Shterenlikht Message-Id: <201408051945.s75JjLaK096959@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org, imp@bsdimp.com Subject: Re: What platform do you use? Reply-To: mexas@bris.ac.uk In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> 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: Wed, 06 Aug 2014 11:58:16 -0000 I have RPI-B. I don't say use, because... well... it's not really that useful. Happy to test patches. At present my kernel seems broken anyway. Anton From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 12:10:08 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 87136789 for ; Wed, 6 Aug 2014 12:10:08 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4301B2FF6 for ; Wed, 6 Aug 2014 12:10:07 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 0BAA86A6008; Wed, 6 Aug 2014 14:10:05 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s76CA4Ya082365; Wed, 6 Aug 2014 14:10:04 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s76CA3RD082025; Wed, 6 Aug 2014 14:10:03 +0200 (CEST) (envelope-from lars) Date: Wed, 6 Aug 2014 14:10:03 +0200 From: Lars Engels To: Anton Shterenlikht Subject: Re: What platform do you use? Message-ID: <20140806121003.GC51170@e-new.0x20.net> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <201408051945.s75JjLaK096959@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="da4uJneut+ArUgXk" Content-Disposition: inline In-Reply-To: <201408051945.s75JjLaK096959@mech-cluster241.men.bris.ac.uk> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org 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: Wed, 06 Aug 2014 12:10:08 -0000 --da4uJneut+ArUgXk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Tue, Aug 05, 2014 at 08:45:21PM +0100, Anton Shterenlikht wrote: > I have RPI-B. I don't say use, because... > well... it's not really that useful. BTW: is there any development going on for the RPI? gonzo@ hasn't blogged about it for a long time. --da4uJneut+ArUgXk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJT4hsbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tdQYH/AzyRc0BZ1rd7NJMM1C8MJn3 Jt8V9BVAVXOGATGz2eFWBvAS+Pl30Ch/TOows9G+HJh/JNoG77Opehjq/4PTDY6W TosdwgLyZFvpHX7vKInOK7aT02/73d0s41ERUguytNbdVHk6P0dY53C9fH95l/ha 8XopHVLIWCiFbqMHoenF4TnROWa1dGb8XMBk4DOcnAsHElCbni7YFbhJWmAdJhGI vD66Z6Kr1rcXFNfLNa3jKB6mo4MLFxkaIJPGt3E+Z4NQprY1Wneq+MNNTI9O1E2G lJIw3umjFBdCgPHkRBbCCyWgH7D6ZTW9GC8foUFW7s6d5KhiIXnDh2QQ0fnhkYA= =/b9C -----END PGP SIGNATURE----- --da4uJneut+ArUgXk-- From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 14:36:14 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 B33DAC01 for ; Wed, 6 Aug 2014 14:36:14 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 743F1248E for ; Wed, 6 Aug 2014 14:36:14 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XF2Jz-000Lhg-0L; Wed, 06 Aug 2014 14:36:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s76Ea5hG017125; Wed, 6 Aug 2014 08:36:06 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+yOLsmtTi7qkNkSMeuOFx7 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Two questions on Flattened Device Tree, newbus and device driver attaching From: Ian Lepore To: =?ISO-8859-1?Q?Mat=EDas?= Perret Cantoni In-Reply-To: References: <1407182403.56408.297.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-2022-jp" Date: Wed, 06 Aug 2014 08:36:05 -0600 Message-ID: <1407335765.56408.320.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org 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: Wed, 06 Aug 2014 14:36:14 -0000 On Tue, 2014-08-05 at 22:31 -0300, Matas Perret Cantoni wrote: > 2014-08-04 17:00 GMT-03:00 Ian Lepore : > > > On Sun, 2014-08-03 at 16:41 -0300, Matas Perret Cantoni wrote: > > > 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.dts > > > (here > > > < > > https://svnweb.freebsd.org/base/release/10.0.0/sys/boot/fdt/dts/zedboard.dts?revision=260789&view=markup > > >), > > > has the CPU definition all commented out: > > > > > > ... > > > // cpus { > > > // #address-cells = <1>; > > > // #size-cells = <0>; > > > // cpu@0 { > > > // device-type = "cpu"; > > > // model = "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 > > > < > > https://svnweb.freebsd.org/base/release/10.0.0/sys/boot/fdt/dts/imx53x.dtsi?view=markup > > > > > > ) > > > > > > ... > > > cpus { > > > #address-cells = <1>; > > > #size-cells = <0>; > > > > > > cpu@0 { > > > device_type = "cpu"; > > > compatible = "ARM,MCIMX535"; > > > reg = <0x0>; > > > d-cache-line-size = <32>; > > > i-cache-line-size = <32>; > > > d-cache-size = <0x8000>; > > > i-cache-size = <0x8000>; > > > l2-cache-line-size = <32>; > > > l2-cache-line = <0x40000>; > > > timebase-frequency = <0>; > > > bus-frequency = <0>; > > > clock-frequency = <0>; > > > }; > > > ... > > > > > > or: > > > > > > p1020rdb.dts (here > > > < > > https://svnweb.freebsd.org/base/release/10.0.0/sys/boot/fdt/dts/p1020rdb.dts?view=markup > > > > > > ) > > > > > > ... > > > cpus { > > > #address-cells = <1>; > > > #size-cells = <0>; > > > > > > PowerPC,P1020@0 { > > > device_type = "cpu"; > > > reg = <0x0>; > > > next-level-cache = <&L2>; > > > }; > > > > > > PowerPC,P1020@1 { > > > device_type = "cpu"; > > > reg = <0x1>; > > > next-level-cache = <&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 > > > < > > https://svnweb.freebsd.org/base/release/10.0.0/sys/kern/subr_bus.c?revision=260789&view=markup > > > > > > ) > > > > > > I believe that the autoconfiguration system uses the > > > fdt_node_check_compatible() function (from fdtlib > > > < > > https://svnweb.freebsd.org/base/release/10.0.0/sys/contrib/libfdt/libfdt.h?revision=260789&view=markup > > >) > > > 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 > > > < > > https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf > > > > > > 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 $B!H(Bmanufacturer,model$B!I(B, where manufacturer is a > > > string describing the name of the manufacturer (such as a stock ticker > > > symbol), and model > > > specifies the model number. > > > > > > Example: *compatible=$B!H(Bfsl,mpc8641-uart$B!I(B, $B!H(Bns16550";* > > > > > > 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. > > > > > > > For #1, virtually none of our arm code uses the cpu information from the > > fdt data, because we generally compile a custom kernel specific to each > > cpu. We've been slowly (very slowly) moving towards a unified kernel > > that can boot on multiple arm chips (or at least closely related chips > > within a family), and that will make the cpu info more important some > > day. > > > > > Oh, I see. Now It is clearer if I take a look in /10.0.0/sys/arm/std.zynq7: > > ... > # > # std.zynq7 - Generic configuration for Xilinx Zynq-7000 PS. > # > # $FreeBSD$ > > cpu CPU_CORTEXA > machine arm armv6 > ... > > > So #1 is solved. Thank you both! > > For #2, if you're looking for some big master table that maps compatible > > strings to drivers, no such thing exists. > > > > Each driver source has one or more DRIVER_MODULE() macros that provides > > some information about the driver. One of the things it provides is the > > parent. The newbus system builds a metadata hierarchy that tracks which > > drivers have described themselves as potential children on each bus. > > > > Usually a device's parent is some sort of bus such as PCI. In an > > fdt-based system "simplebus" is an abstraction that can represent many > > different types of buses (such as internal on-chip connections between > > the cpu and internal devices). A hardware bus such as PCI has ways to > > query the hardware to see what's connected. In the fdt world, simplebus > > uses the fdt data to do this query... it looks at all the fdt device > > entries that are described as its children in the fdt data. > > > > For each child in the fdt data, simplebus asks newbus to probe all the > > drivers whose DRIVER_MODULE() said they could be children of simplebus. > > The probe() routine of each driver has access to the fdt data for the > > device simplebus is trying to probe. The driver compares the compatible > > strings in that data to the compatible strings that it knows how to > > handle, and returns a success/fail code from probe() to indicate whether > > or not it is the driver for the device. > > > > Sometimes multiple drivers can handle the same hardware, so newbus > > probes every child driver against every device on the bus. For example > > a usb keyboard is a pretty generic thing, but a FooStar1000 keyboard > > might have a special driver that understands extra keys. The generic > > usb keyboard driver would return BUS_PROBE_GENERIC, and the FooStar1000 > > driver would return BUS_PROBE_SPECIFIC. After probing all potential > > devices, newbus chooses the one with the highest return value from > > probe() as being the one most-specific to that hardware. (In reality > > this doesn't happen much; usually only one driver returns success and > > all others return an error.) > > > > -- Ian > > > > #2 is way more clearer now, but I still can't see a few things: > > I can see the function simplebus_attach() calling newbus to create a child, > probe it and attach it for each of the ftd nodes claiming to be simplebus > compatible. Here is a snippet from simplebus.c: > > /* > * Walk simple-bus and add direct subordinates as our children. > */ > dt_node = ofw_bus_get_node(dev); > for (dt_child = OF_child(dt_node); dt_child != 0; > dt_child = OF_peer(dt_child)) { > > ... > /* Add newbus device for this FDT node */ > dev_child = device_add_child(dev, NULL, -1); > } > ... > return (bus_generic_attach(dev)); > } > > > So there are two functions from bus.h being called: device_add_child() > which makes a new newbus child, and bus_generic_attach(dev) which causes > newbus to probe and attach each of the new childs of the simplebus node. > > I can see fdtbus doing the same thing for each node of the fdt's root node. > Here is a snippet from fdtbus.c: > > /* > * Walk the FDT root node and add top-level devices as our children. > */ > for (child = OF_child(root); child != 0; child = OF_peer(child)) { > > ... > newbus_device_from_fdt_node(dev, child); > ... > > return (bus_generic_attach(dev)); > > > _________ > > So until here I think I understand how the newbus nodes (devices) are being > created and how the drivers are being attached to them. > But when I print the information about system device configuration with > devinfo I can see that there is a "nexus0" node and a "ofwbus0" node in the > newbus hierarchy: > > root@zedboard:~ # devinfo > nexus0 > ofwbus0 > simplebus0 > zy7_slcr0 > gic0 > l2cache0 > .... > > > I think that the nexus0 node is created by this function: > > /* > * Determine i/o configuration for a machine. > */ > static void > configure_first(void *dummy) > { > > device_add_child(root_bus, "nexus", 0); > } > > > (which is in the file /10.0.0/sys/arm/arm/autoconf.c and by the way I can't > find any calling function to configure_first). > > And I guess the root node is declared in /10.0.0/sys/kern/subr_bus.c file: > > device_t root_bus; > devclass_t root_devclass; > > > But I can't find out how the "ofwbus0" node is created neither who is doing > so! > > Thanks in advance. > Best regards, Matias.- configure_first() and the other functions in autoconf.c are started by the system init code in mi_startup() in kern/init_main.c. Any part of the kernel or modules that may be loaded by loader(8) can use a SYSINIT() macro to declare that they have init code to run at kernel startup. Linker magic combines all the SYSINIT info into a special section in the kernel binary, and the mi_startup() code walks through that info and calls all the functions. You've already discovered that nexus gets added by configure_first() (I think I knew that years ago, but had completely forgotten). That causes nexus to be probed and attached. The probe always succeeds with nexus, and nexus attach() calls bus_generic_probe(). That causes newbus to call the identify() routine for every driver that said it might be a child of nexus. Most drivers don't have an identify() routine, it's rarely used. I think of it as a sort of pre-probe routine (man 9 DEVICE_IDENTIFY has more info on it.) The ofwbus driver (dev/ofw/ofwbus.c) has a DRIVER_MODULE() macro that declares it to be a potential child of nexus, and it has an identify() routine that calls device_add_child() to add itself as a child of nexus. I think of this as "forced adoption"... normally it is the parent bus that does device_add_child(), but in this case the child attaches itself to the parent. Once ofwbus is added to nexus in this way, its attach() routine gets called when nexus does bus_generic_attach(), and the ofwbus attach() then uses the FDT data to attach simplebus and other children described in the data. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 14:42:31 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 B4E16C8 for ; Wed, 6 Aug 2014 14:42:31 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 777852594 for ; Wed, 6 Aug 2014 14:42:31 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XF2Q2-0007y1-TO for freebsd-arm@freebsd.org; Wed, 06 Aug 2014 16:42:23 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: What platform do you use? References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Date: Wed, 06 Aug 2014 16:42:21 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40 autolearn=disabled version=3.3.2 X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 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: Wed, 06 Aug 2014 14:42:31 -0000 On Tue, 05 Aug 2014 18:26:35 +0200, Warner Losh wrote: > Greetings, > > I=E2=80=99d like to know what platforms people use FreeBSD/arm with, a= nd if = > you=E2=80=99d have time to test some potentially =E2=80=9Cbreak the ke= rnel=E2=80=9D sort of = > changes in the next month? > > I have the following boards: boatloads of atmel, BBB, and RPI. This = > covers the at91, imx6 and broadcom directories. I also have a allwinnn= er = > board, but I=E2=80=99ve never got it booting FreeBSD. Likewise with a = rockchip. = > I have some marvell gear too, but it is buried deep. This leaves a lot= = > of other boards/SoCs to cover... > > Warner > I have some (currently broken) Sheevaplug machines which ran FreeBSD 10 = in = the past and I am planning to install 11 on them in the nearby future. One of these can be used for testing purposes. Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 16:04:35 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 69A57C72 for ; Wed, 6 Aug 2014 16:04:35 +0000 (UTC) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (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 3A48F2049 for ; Wed, 6 Aug 2014 16:04:34 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id eu11so3681210pac.4 for ; Wed, 06 Aug 2014 09:04:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=JqHccV/+mr9cgqcmSJvl95JOABk+N5TgW2R4HfZwveg=; b=BH1ZTNMbxjHfLM0QwRkDGmji4g+wt6so+B6i+LU0tOdfxi6LFsHJFh6G78mpfS+m93 qNzoDPLk5UTrgS2fEjT/e5j+B1c+tUi72JQwkzHKixpq+xSsjyAzkqvU5W+Zhbet8QgT a9/AvMxcR5V4zl++e8d8bF4Yr2e+mgxHru4HGF0wF36SPYhtDROuG8Y6xURpxzju87Tx gtE+8LOyQt1JlCarrdmdZzDBDQ3VDH8dCFdMDdWZ432rEz30N5j1K8PbpjEiTd5WxgZ1 ceu/W6NUMONNZprmTiIbNA9QyVM2V8gVsyXer9PrHFqp/WuA2Mbh+kNep5rYzzICEktf Ci9Q== X-Gm-Message-State: ALoCoQkDWYJ1V6EM6gWSCvEyw0KgbnkS+F9xHYW7+icWIg2g6AHD95MDyWUAYLZ26szAU4AH+6I1 X-Received: by 10.70.51.8 with SMTP id g8mr11796684pdo.98.1407341068276; Wed, 06 Aug 2014 09:04:28 -0700 (PDT) Received: from [10.64.25.9] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id fq4sm2329972pdb.71.2014.08.06.09.04.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 09:04:27 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_608468C5-1EEA-4881-8388-C38FB4387C68"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Loading modules with KB920X panics From: Warner Losh In-Reply-To: <53E1E122.9040304@selasky.org> Date: Wed, 6 Aug 2014 10:04:25 -0600 Message-Id: <86AAC393-76E8-4F5B-B07A-1A648572E552@bsdimp.com> References: <53E1E122.9040304@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm 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: Wed, 06 Aug 2014 16:04:35 -0000 --Apple-Mail=_608468C5-1EEA-4881-8388-C38FB4387C68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 6, 2014, at 2:02 AM, Hans Petter Selasky wrote: > Hi, >=20 > I'm building a custom module for KB920X and it panics when loading = because structures like Elf32_Rel and Elf32_Rela are not aligned. >=20 > I added __packed keyword and the errors seems to be going away. >=20 > Any clues what is wrong? I=92m sure this used to work. Any notion of when it might have broken? Warner --Apple-Mail=_608468C5-1EEA-4881-8388-C38FB4387C68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4lIJAAoJEGwc0Sh9sBEAR40QAObAyQjTqslrGvBCWrUUrEPn QlhtG8sovR4m+JqkHcrGTls087hnAtOB27+RD/fWF19wq/zPBjaW6QLzWv/h0ljd Hsq2uklne1rKoyRoctMV5ptarifcPS3hjdDhlEr/IXDHifPVYorGdWURgyYWxS2w eBrM9C/Q1Xn2iNmpvIRHYGLlK9RKijFOU48Xz7Dg+8M/LL6z3Qa9zlIZxC4BNkGF U9ULyI8oq6tvPQGxYI/BARdlNNzW0HakKPPEKWJAP5nm6S3ySAY+JaU55s1MzSh9 5MnEPAJjkxzATyiDGuqUn9SLUdEy5ZpAr3FfhkkJIC/3YSIYvxAcN2IJhTr5Mic5 b+Z9YNxhXEQ5LCK6HPat0TKjhjjaAu19r9OAv5qizxXTf4ktVofB49K79uqjyWA4 ChV1hZWTd/VkFm8yxK4Pril14mYh9lOBSXMY3kILELGTZ528SYXhRRzkdrB1JiaB dVf6Y3qSKlfFMHp6DaclxT/6+mQj4LPiwo/ZDC7uVno1SAKCKADzt0kb4BauCxtB nNFZ/MlOART28gOwT1X0lQ/RNHBaODmnOkI/nxBKuPXNmJtvLUhZaZOmLRZxRX/t W9BGG3yTe2xF/FLCoFXapFzfUwJnRfOpPOt1w4gKEmv5IsqFgk62V8DhcaAMN2E/ bRzGPEJF5bHuew1cr6sn =9qCa -----END PGP SIGNATURE----- --Apple-Mail=_608468C5-1EEA-4881-8388-C38FB4387C68-- From owner-freebsd-arm@FreeBSD.ORG Wed Aug 6 16: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 4E12038E for ; Wed, 6 Aug 2014 16:08:20 +0000 (UTC) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (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 1D42A20AC for ; Wed, 6 Aug 2014 16:08:19 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id g10so3560357pdj.12 for ; Wed, 06 Aug 2014 09:08:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8ly3J3EYj+oKaasQR136OQZTy17nh90rztjBjwwBGc0=; b=RK9wjDAb9bQQND/8GHuVjfajNah6fKxFDSiHQUTMUyQpXKLUFCE/fKnQLArZwDJepE G0nQOTXL3E34OY9xgHoBgZYwvCapQjBL6NKO2Cq4S+Z7EdExWqwUBZ9p1G5vUSW5/am9 d/vN2cVQTi49ZYBYub+lfdlDeyeeLlft/0+k6LlbMqSLnQdzgqduYYnH8/eV50A/uKWF I05vqdcQdp8z4p+nRC0+2VEcW60HgCz1KAYiIsmq3aOzxJrVp7qnXnWas1pOKojSh8xA iQ6C8DHreYrrcoUUvA0zkeZUSV0SNWwdEqSiq8xBKR0wx5OATs713y7HTn6L/axX5lxL 3izA== X-Gm-Message-State: ALoCoQnTBzUj7A+3tFPlZ1tqOAgjGaatdGbNuqR86qumb/xU/MWlzQgAPspl8R6GkuoudwemXXPo X-Received: by 10.70.16.196 with SMTP id i4mr12214989pdd.93.1407341299244; Wed, 06 Aug 2014 09:08:19 -0700 (PDT) Received: from [10.64.25.9] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id r9sm2357868pdp.53.2014.08.06.09.08.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 09:08:18 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_E866DAE6-3166-41F2-A8E9-BCE214D6F992"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What platform do you use? From: Warner Losh In-Reply-To: Date: Wed, 6 Aug 2014 10:08:16 -0600 Message-Id: <8B434576-F1FE-4036-B0CA-1604597B14A8@bsdimp.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> To: Tom Everett X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm 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: Wed, 06 Aug 2014 16:08:20 -0000 --Apple-Mail=_E866DAE6-3166-41F2-A8E9-BCE214D6F992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On a related note, I=92m expanding nanobsd so it can build images, ala = crochet, for embedded platforms, plus also support building packages / = ports in a cross fashion (today using qemu user + some optimization = hacks, maybe tomorrow natively if Baptist ever gets that all going). = Mostly doodles right now, however, and it does force a two-phase build = (one to build everything, and then one to create an image from the = packages the first phase built). Warner On Aug 6, 2014, at 8:13 AM, Tom Everett wrote: > FWIW I'm hacking away at building Chromebook support into Crochet. = It's not working yet... but some day.... >=20 >=20 >=20 > On Tue, Aug 5, 2014 at 10:26 AM, Warner Losh wrote: > Greetings, >=20 > I=92d like to know what platforms people use FreeBSD/arm with, and if = you=92d have time to test some potentially =93break the kernel=94 sort = of changes in the next month? >=20 > I have the following boards: boatloads of atmel, BBB, and RPI. This = covers the at91, imx6 and broadcom directories. I also have a allwinnner = board, but I=92ve never got it booting FreeBSD. Likewise with a = rockchip. I have some marvell gear too, but it is buried deep. This = leaves a lot of other boards/SoCs to cover... >=20 > Warner >=20 >=20 >=20 >=20 > --=20 > A better world shall emerge based on faith and understanding - = Douglas MacArthur --Apple-Mail=_E866DAE6-3166-41F2-A8E9-BCE214D6F992 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4lLwAAoJEGwc0Sh9sBEA7ncP/jPgYSTqoCFSgOa9g0U4cVUg JhaiRSXo39oVL2J7rLCcmzWJDmag7tFYutZtcUizg+0nC/t6InAeLL4+wj89Jk1l G0/xsVVPUBh6LVKCWNeYzKC/L8+cwp0oJU+yIIGTburkymbD9jXljfLRWIwTfKGc SwVvlWtVsSsYvJFDIcTlcEumvaW9wHWz3J5J4tAJNF9+vzJiPWf97B86IqMPtpec S+5hpi9l5wO8N95TP0oIbpit9JNEXTzC0HQSB47K7xpJYyvoE40RUiExADzDUDBg uxPsrb5/KYKDlczQ/aOWVW+5AHT3ff80QefBsjCb/tRDxmppBR/5XIRrjNpArD4P 9hR6lw+9E3f3hVIrAk8D7Jbf4Zsf9YGNFProTdXKsSy70iAyBpH+7a6tRhAbH76t 2bJ0LYZ4sgFQEXR+ceZRjtD4civEqSumWgy75IeGSxmTKyUFeuniGXurWzHnRj4n dypxNS6n0lZ8cr2jQxu6Ty5MdwtLTFtJdesEZ5g1mbjui8rEt0X4bLrZTYcCLPD8 DffXIXSMcVpnCPLIw48bAWq1n00jAHSakML0zIgQIjrv999jKtUEBFQDzz6bQs3R nyHWpq5HLRrjxtW1IA991OQufJvPDqqJm3LtODA9h4a5dgWcPiRm5NEHO81UqCgT AZgA7TZtoHX2zWDGfw7O =Eehi -----END PGP SIGNATURE----- --Apple-Mail=_E866DAE6-3166-41F2-A8E9-BCE214D6F992-- From owner-freebsd-arm@FreeBSD.ORG Thu Aug 7 12:19:19 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 B0A19816 for ; Thu, 7 Aug 2014 12:19:19 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (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 38FFA206D for ; Thu, 7 Aug 2014 12:19:19 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id el20so2411698lab.17 for ; Thu, 07 Aug 2014 05:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Fm6pCCskX5cVPxrsgGFblvW+I5i/2fcaOB2095INzVk=; b=YvUIyxWgiqJX3NUzxk+PnMOjw8OF095x0/Obaqa300jHg+v1VWx8dhdyeOQsZmIqNi vAz1nDBhFqIQRas+B4PAQqLKEOt8063O0ivGRqNvEE/GluJMht6byRAxoMLNNYIBJuS2 v+Rb6rI4F6CL7DnZvZCFxKLFyTjq5HxZzBxGFcdTrALP+tXZNOe2WdGO7HpOqKC3TUTy 0iRrTgtjPGluL+yyjBlzlghuUfJUmqDQFLLwKLMPvMUBjTGYG0HAHxtEx4xp6jW5XyL0 hnYPnq8cqMAaxJivwrDXONmFZi33PD1IWURNdYO3QuabkqJzK+0j0ZEUt8J9sYBXgF90 cxdw== MIME-Version: 1.0 X-Received: by 10.112.16.230 with SMTP id j6mr1849179lbd.90.1407413957150; Thu, 07 Aug 2014 05:19:17 -0700 (PDT) Received: by 10.152.30.37 with HTTP; Thu, 7 Aug 2014 05:19:17 -0700 (PDT) In-Reply-To: References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <8B434576-F1FE-4036-B0CA-1604597B14A8@bsdimp.com> Date: Thu, 7 Aug 2014 14:19:17 +0200 Message-ID: Subject: Fwd: What platform do you use? From: Aleksander Dutkowski 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: Thu, 07 Aug 2014 12:19:19 -0000 Hello! I have: - BeagleBoard-xM rev. C. (I hope I will update FBSD on this board) - WandBoard Quad On Wed, Aug 6, 2014 at 6:08 PM, Warner Losh wrote: > On a related note, I=E2=80=99m expanding nanobsd so it can build images, = ala > crochet, for embedded platforms, plus also support building packages / > ports in a cross fashion (today using qemu user + some optimization hacks= , > maybe tomorrow natively if Baptist ever gets that all going). Mostly > doodles right now, however, and it does force a two-phase build (one to > build everything, and then one to create an image from the packages the > first phase built). > > Warner > > > On Aug 6, 2014, at 8:13 AM, Tom Everett wrote: > > > FWIW I'm hacking away at building Chromebook support into Crochet. It'= s > not working yet... but some day.... > > > > > > > > On Tue, Aug 5, 2014 at 10:26 AM, Warner Losh wrote: > > Greetings, > > > > I=E2=80=99d like to know what platforms people use FreeBSD/arm with, an= d if > you=E2=80=99d have time to test some potentially =E2=80=9Cbreak the kerne= l=E2=80=9D sort of changes > in the next month? > > > > I have the following boards: boatloads of atmel, BBB, and RPI. This > covers the at91, imx6 and broadcom directories. I also have a allwinnner > board, but I=E2=80=99ve never got it booting FreeBSD. Likewise with a roc= kchip. I > have some marvell gear too, but it is buried deep. This leaves a lot of > other boards/SoCs to cover... > > > > Warner > > > > > > > > > > -- > > A better world shall emerge based on faith and understanding - Douglas > MacArthur > > From owner-freebsd-arm@FreeBSD.ORG Thu Aug 7 14:36:47 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 4EFB185C for ; Thu, 7 Aug 2014 14:36:47 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 B637421D2 for ; Thu, 7 Aug 2014 14:36:46 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id s7so2731836lbd.8 for ; Thu, 07 Aug 2014 07:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M/UxLJQIMsn3gok2e8jMBjeUug9oI7jrKC6QEOUCOeA=; b=fuIHX7Q4xkKyP7ErGhX9NdYH35LdUszVZgphaWO455dP4o9rPgTtgCQLQBDIz05n6x tnopbKEAvj3L8V2Qej3zvmpxoMV+rmAd+YpEOzoLcGu0UZexY8dJYgjfc5QHpNZdO2Sd +m6OQKSpTmXqgV0DeajC83un8+RGfmkUlty2sspKjG7TiFK548SHu/fmM92FIKDFnTQW +7srR31EloEQ9I2Kj6eUDGQRKcffcPO/1jDiMGcsCVfOyCc9gSNsVpidCHUIwKz4K56U vrCOe3RSWhEFLZIEank28Kouc7P0nOZL+e9uu+bbV2gS+z8bPgZC38Wlbnxt/sup+v+1 RUYQ== MIME-Version: 1.0 X-Received: by 10.112.16.230 with SMTP id j6mr2389005lbd.90.1407422204617; Thu, 07 Aug 2014 07:36:44 -0700 (PDT) Received: by 10.152.30.37 with HTTP; Thu, 7 Aug 2014 07:36:44 -0700 (PDT) In-Reply-To: <20140621171914.26950010@bender.Home> References: <20140616095914.21757989@bender.Home> <20140621171914.26950010@bender.Home> Date: Thu, 7 Aug 2014 16:36:44 +0200 Message-ID: Subject: Re: Removing partially supported SoCs From: Aleksander Dutkowski To: Andrew Turner Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org 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: Thu, 07 Aug 2014 14:36:47 -0000 The code for BB-xM is at [1]. Unfortunately this is almost 2 years old and I dont have time to merge it with current:/ But I was booting to multiuser and most of the peripherals were working. [1] http://svnweb.freebsd.org/socsvn/soc2012/aleek/beaglexm-head/ On Sat, Jun 21, 2014 at 6:19 PM, Andrew Turner wrote: > On Mon, 16 Jun 2014 09:59:14 +0100 > Andrew Turner wrote: > > > I'm looking at removing support for SoCs where we have code but nobody > > appears to be supporting it. Having this extra code means we have to > > update it, but are unable to test the changes as it may not boot. > > > > To begin with I'm planning on removing Tegra 2 and OMAP3 code. > > > > The Tegra 2 is quite old and, as far as I know, never got to single > > user mode. There is only one kernel config that builds the code. > > Along with this the SoC dependent code is very minimal as it only > > includes what appears to be the minimum code to build and start > > booting the kernel. > > > > For OMAP3 we don't have the std.omap3 or files.omap3 files, and > > therefore no kernel config. The omap3 directory only contains a file > > with the SoC specific register addresses. It also makes other Ti > > drivers more comples as they need to check which SoC they are running > > on. > > > > Removing OMAP3 will not affect the other Ti SoCs, i.e. OMAP4 and > > AM35xx. > > > > If anyone feels they wish to keep support for either of these SoCs > > they will need to work to improve the support of both getting the SoC > > booting to a useful state, and to help keep the code up to date with > > other kernel changes, i.e. to not leave when the SoC is booting to > > multi-user mode. > > > > If I get no complaints I'm planning on removing them this weekend. > > After this other SoCs will be evaluated to determine if we should > > still support them. > > I've had a little intrest in the OMAP3 support for the BeagleBoard-xM > and Gumstix Overo boards. I will leave it in for now and remove only > the Tegra 2 code. > > For people interested in either of these boards, or another OMAP3 board > I would suggest you start working on bringing the support up to a level > where we can boot on these boards otherwise the code will come up for > removal again. > > Andrew > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- pozdrawiam Aleksander Dutkowski -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 12.3.4 (Build 666) Charset: wtf-8 wsBVAwUBT+sou1VtgMGTo1scAQJtMwf/cQbE0UHH4NLwqZqCZtM+xSRUQWx886Zq wghKIFHGU93hf8384JDHdsjadlfu220r8f8384JDVUnwUBThVUnzM+xSRUQsBVVUnz2d J+449ghVUnz2aL3kS4nDERddu+k0wsk1FHGU93hfqZqCZtM7zzhjklQwErtY68vDzwf== -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Thu Aug 7 20:34:22 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 29DD7AD9 for ; Thu, 7 Aug 2014 20:34:22 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (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 B335323D8 for ; Thu, 7 Aug 2014 20:34:21 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q58so4750584wes.32 for ; Thu, 07 Aug 2014 13:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vSA/YDRNAL+xaWk3nikApq6AsFGPkzh2vniayE+igc0=; b=lpcwDc/wxZjyduGQDhF+EqMtiyr8OvRGIbXUV29bztOioKdZfsd5fI2/eHFKiSwHPg P90G/yqLSQ87ZyYpcZkNhKM3eKXeVRtQ9n9pzRFs3itX9MCsq/c0aNWPNJRIjw/KCCDy nSf8tyk2Ygte+7mn7Ab3dhXxRgMpHttcicIRR9IiX4ryJQRcOxU/WZX+gPNgARESYNNj KxfMOmLNJmrjLcDMEfPN/GWLloXsLkSw1LXdvFUwk6ReMO6/iLYsS1A9jb3WTSQgNM5c QU6DN5e5j9+TVcspVfcxutKATGDXzs2Tv8XgrQ7pjsZNE3CpCCKoyhLPSuwvjrW7PHTk OxUA== X-Received: by 10.180.88.167 with SMTP id bh7mr37974wib.12.1407443659909; Thu, 07 Aug 2014 13:34:19 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id a4sm2910443wie.21.2014.08.07.13.34.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 13:34:18 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53E3E2C7.9000802@hot.ee> Date: Thu, 07 Aug 2014 23:34:15 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Warner Losh , freebsd-arm , John-Mark Gurney Subject: Re: What platform do you use? References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <20140805182438.GP88623@funkthat.com> In-Reply-To: <20140805182438.GP88623@funkthat.com> X-TagToolbar-Keys: D20140807233415637 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Thu, 07 Aug 2014 20:34:22 -0000 On 2014-08-05 21:24, John-Mark Gurney wrote: > I also have a BBW that I occasionally test w/ but since I haven't got > it netbooting, the cost of building an entire image and writing it to > SLOW microsd prevents me from testing as much... I wonder why people like to update their embedded systems by taking card out, completely overwriting it with new data and putting card back in. No wonder that it's slow, complex & heedlessly wears out your flash. If I do this in my BBB I would get myself pissed very soon because of the effort required. I never bothered to netboot too, because I wanted to test it in insecure network conditions. I mean, I don't remember a case where I needed to take HDD to another machine for upgrade. The issue where it's not practical to compile something locally is completely unrelated with this, too. From owner-freebsd-arm@FreeBSD.ORG Thu Aug 7 21:34:15 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 19F8AEF6 for ; Thu, 7 Aug 2014 21:34:15 +0000 (UTC) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (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 DD7C329E6 for ; Thu, 7 Aug 2014 21:34:14 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id bj1so6009777pad.25 for ; Thu, 07 Aug 2014 14:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZM+ktHUKQQijcVil29fHZ5oV3nIkW3EI3lCwoN1jtvM=; b=SjwIHeaN87QZ/P0yZh8qFV3qyxIwsQo/N6J1wlTe3atf74QtpBuqmrf7qVUoA95Sno keulE16znF8znnrIczgUhUGRhRHCVd3X4uiC8mDEOb4q5ZIEAM3bYECmHJDz7E5SW5ab hYtf87CJWY4vIETjilVrs33Z3NULHY+CU1sfiVlZd61LFGpUdqB4CTNtbUNT5R215prk 3c+CPwNoHcStVGhdVjMfiw6rg0mS07/l+wO0OTetWmeQ0ULgHQJFShote2JaSYofc/BS NzNQkJ+/2T6QMpdaJfAZ3gfH949zcPLcgLCAXlrJkg2XYO36omQeURuV+x5wikHkkvxA k9Iw== X-Gm-Message-State: ALoCoQneStPoxkIvrYbWiOrrgq2azIWQoEaVo3uMKvmsLiJSGUQd03hGc8cz7er4/cmS6WIvu+7x X-Received: by 10.66.235.70 with SMTP id uk6mr20180482pac.49.1407447247983; Thu, 07 Aug 2014 14:34:07 -0700 (PDT) Received: from [10.64.25.25] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id qj1sm831629pbb.24.2014.08.07.14.34.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 14:34:07 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7361B5C6-B171-4FBD-9F82-67E4A4E41141"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What platform do you use? From: Warner Losh In-Reply-To: <53E3E2C7.9000802@hot.ee> Date: Thu, 7 Aug 2014 15:34:05 -0600 Message-Id: <24403276-D738-4CB1-A3BE-BBB72D4370C6@bsdimp.com> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <20140805182438.GP88623@funkthat.com> <53E3E2C7.9000802@hot.ee> To: "Sulev-Madis Silber (ketas)" X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm 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: Thu, 07 Aug 2014 21:34:15 -0000 --Apple-Mail=_7361B5C6-B171-4FBD-9F82-67E4A4E41141 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 7, 2014, at 2:34 PM, Sulev-Madis Silber (ketas) = wrote: > On 2014-08-05 21:24, John-Mark Gurney wrote: >> I also have a BBW that I occasionally test w/ but since I haven't got >> it netbooting, the cost of building an entire image and writing it to >> SLOW microsd prevents me from testing as much... >=20 > I wonder why people like to update their embedded systems by taking = card > out, completely overwriting it with new data and putting card back in. > No wonder that it's slow, complex & heedlessly wears out your flash. >=20 > If I do this in my BBB I would get myself pissed very soon because of > the effort required. I never bothered to netboot too, because I wanted > to test it in insecure network conditions. > I mean, I don't remember a case where I needed to take HDD to another > machine for upgrade. The issue where it's not practical to compile > something locally is completely unrelated with this, too. make installworld works too, as does extracting the binary sets. The new = installer should work, but I=92ve not tried it. Warner --Apple-Mail=_7361B5C6-B171-4FBD-9F82-67E4A4E41141 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4/DNAAoJEGwc0Sh9sBEA/6EQANOnuhLCQxolvp7MdtgsOKeO kbMRFvDvOCHIIrRDcR8DJJVTYlcvNxN7p4ZaEoEFkiwqV8o02T462umirFpneYE6 VunxbnR45OEXpkIBHVpTNjGs2/u6/uSox3xzO3V+MdzizguCs4qCPCQPWRc6YYmz PWeEHtidxBLzrdMGpjbtT5KITuuF29fiE4GZIPKmqTlr4aRT/gi15nLOhz+4LnVy KA2edb9UV8kkSnynnuBQ9FDOLsAE2YO6Vtz1hvUxVClQ9NNfLt7FaGpKl893Nk/H FwFiBl6xmSl6M+sq60nltGVrY1w7nC6SgSxwyVnabTgFoySjMZKUpYrgeC9hz042 ctZu7E1B1p9Ch8dYsl/4dNlhmjmrXxfQ2y4fxQoR4u9kTS0kjDguGItJC/BQQHsm +G0mYn5tjR8CO12cU3OLRi5rstcszpoomB267/MM459vrRInb8yHYgRKm6ExfhsJ C+iPChLzNKHYfvoU+dsLfppe5usuVexHuJdJwlE2Qsmpo0eCQbTe6GhWHhr3T4wD GOUC0eqJ63mWgRXSCQbsZo62Cif+8t/X7KPSGbPzHyL4TX41ykaxa++boNq7iy5p HfuKUSBC7PdbQpfwvvxp+Jeuv7lEu5iz7yL6/og7whb+X61WxWyswVsneJEuUDwq Fg8MzAO/Wi9rl8D3BYFS =pYnT -----END PGP SIGNATURE----- --Apple-Mail=_7361B5C6-B171-4FBD-9F82-67E4A4E41141-- From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 01:50:19 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 DD719F9E for ; Fri, 8 Aug 2014 01:50:19 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B293D2521 for ; Fri, 8 Aug 2014 01:50:19 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XFZJs-000Bi4-0b; Fri, 08 Aug 2014 01:50:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s781o9Kj020168; Thu, 7 Aug 2014 19:50:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19t73wJjkzAF0RYGKkm4eLu X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Loading modules with KB920X panics From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <53E1E122.9040304@selasky.org> References: <53E1E122.9040304@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Aug 2014 19:50:08 -0600 Message-ID: <1407462608.56408.350.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm 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: Fri, 08 Aug 2014 01:50:19 -0000 On Wed, 2014-08-06 at 10:02 +0200, Hans Petter Selasky wrote: > Hi, > > I'm building a custom module for KB920X and it panics when loading > because structures like Elf32_Rel and Elf32_Rela are not aligned. > > I added __packed keyword and the errors seems to be going away. > > Any clues what is wrong? > > .ko file can be supplied. > > FreeBSD-current > We load .ko modules on our at91rm92 stuff at work (although I haven't tested anything newer than 10.0 mid-last year). It seems odd that the reloc info would be unaligned. The ldscript should align the start of the section, and it should stay aligned after that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 05:42:34 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 9FBD3DD; Fri, 8 Aug 2014 05:42:34 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F8A12D45; Fri, 8 Aug 2014 05:42:34 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2E9571FE027; Fri, 8 Aug 2014 07:42:32 +0200 (CEST) Message-ID: <53E46361.4020605@selasky.org> Date: Fri, 08 Aug 2014 07:42:57 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Loading modules with KB920X panics References: <53E1E122.9040304@selasky.org> <1407462608.56408.350.camel@revolution.hippie.lan> In-Reply-To: <1407462608.56408.350.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm 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: Fri, 08 Aug 2014 05:42:34 -0000 On 08/08/14 03:50, Ian Lepore wrote: > On Wed, 2014-08-06 at 10:02 +0200, Hans Petter Selasky wrote: >> Hi, >> >> I'm building a custom module for KB920X and it panics when loading >> because structures like Elf32_Rel and Elf32_Rela are not aligned. >> >> I added __packed keyword and the errors seems to be going away. >> >> Any clues what is wrong? >> >> .ko file can be supplied. >> >> FreeBSD-current >> > > We load .ko modules on our at91rm92 stuff at work (although I haven't > tested anything newer than 10.0 mid-last year). > > It seems odd that the reloc info would be unaligned. The ldscript > should align the start of the section, and it should stay aligned after > that. > Hi, This was an out-of-the kernel module, built under the build environment for ARM. Can you point me to the linker script responsible for this? I specified: --warn-section-align And it output some warnings. Any clues how I can nail this down? If someone is interested I can give you the source code and build instructions. --HPS From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 07:54:37 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 144E168C for ; Fri, 8 Aug 2014 07:54:37 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (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 C79EA2B35 for ; Fri, 8 Aug 2014 07:54:36 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id hq11so7824926vcb.30 for ; Fri, 08 Aug 2014 00:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=o09lhpsWyU9FVEGn2J08lBpEuB9rT2fXdogC3Y9Il/Q=; b=gcX/kqO6xycFzj9wQIl7wWX9AF8U5nQv/fYyFsbBotp+cIus87zPGCSaGQQZd99LK0 ivCB2NYrsNgh6Pi3ooSkS3CjDbRr3wXHVN0n2EyLr+PLcTbZU+SpVkx0ly7hMZLUOR1k BF8e9stD1Ijxie4se5Ah0fASOx1cRn7OgE5vk1PKlKuA/7YCvfchEMsoIBa4zAyWcCfk vzY3UAIRIKqE+cchwALt2EbDRGpRH0B1cbNnmLOP8BHD04F76rr17G7F93vmZ6+x5TEE ag6YbYb0jcEKtLAVldqIzyiAvMcSrnwRd718T79oQUQgnFeBLMxoFxfVPPJJb9X253CP y1VQ== MIME-Version: 1.0 X-Received: by 10.220.200.71 with SMTP id ev7mr20642798vcb.24.1407484475756; Fri, 08 Aug 2014 00:54:35 -0700 (PDT) Received: by 10.52.177.231 with HTTP; Fri, 8 Aug 2014 00:54:35 -0700 (PDT) In-Reply-To: References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> Date: Fri, 8 Aug 2014 09:54:35 +0200 Message-ID: Subject: Re: What platform do you use? From: Jan Sieka Cc: 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: Fri, 08 Aug 2014 07:54:37 -0000 2014-08-06 16:42 GMT+02:00 Ronald Klop : > On Tue, 05 Aug 2014 18:26:35 +0200, Warner Losh wrote: > > Greetings, >> >> I=E2=80=99d like to know what platforms people use FreeBSD/arm with, and= if you=E2=80=99d >> have time to test some potentially =E2=80=9Cbreak the kernel=E2=80=9D so= rt of changes in >> the next month? >> >> I have the following boards: boatloads of atmel, BBB, and RPI. This >> covers the at91, imx6 and broadcom directories. I also have a allwinnner >> board, but I=E2=80=99ve never got it booting FreeBSD. Likewise with a ro= ckchip. I >> have some marvell gear too, but it is buried deep. This leaves a lot of >> other boards/SoCs to cover... >> >> Warner >> >> > I have some (currently broken) Sheevaplug machines which ran FreeBSD 10 i= n > the past and I am planning to install 11 on them in the nearby future. > One of these can be used for testing purposes. > > Ronald. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > Hi! I also have SheevaPlug that currently is not used so can be used for testing. Best regards, Jan Sieka From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 13:36:04 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 3F5A05EE for ; Fri, 8 Aug 2014 13:36:04 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11E212467 for ; Fri, 8 Aug 2014 13:36:03 +0000 (UTC) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 0AEB3347; Fri, 8 Aug 2014 09:35:55 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What platform do you use? From: Paul Mather In-Reply-To: <24403276-D738-4CB1-A3BE-BBB72D4370C6@bsdimp.com> Date: Fri, 8 Aug 2014 09:35:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <724D10EE-F6DF-4366-91CF-AE4419847389@gromit.dlib.vt.edu> References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <20140805182438.GP88623@funkthat.com> <53E3E2C7.9000802@hot.ee> <24403276-D738-4CB1-A3BE-BBB72D4370C6@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm 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: Fri, 08 Aug 2014 13:36:04 -0000 On Aug 7, 2014, at 5:34 PM, Warner Losh wrote: >=20 > On Aug 7, 2014, at 2:34 PM, Sulev-Madis Silber (ketas) = wrote: >=20 >> On 2014-08-05 21:24, John-Mark Gurney wrote: >>> I also have a BBW that I occasionally test w/ but since I haven't = got >>> it netbooting, the cost of building an entire image and writing it = to >>> SLOW microsd prevents me from testing as much... >>=20 >> I wonder why people like to update their embedded systems by taking = card >> out, completely overwriting it with new data and putting card back = in. >> No wonder that it's slow, complex & heedlessly wears out your flash. >>=20 >> If I do this in my BBB I would get myself pissed very soon because of >> the effort required. I never bothered to netboot too, because I = wanted >> to test it in insecure network conditions. >> I mean, I don't remember a case where I needed to take HDD to another >> machine for upgrade. The issue where it's not practical to compile >> something locally is completely unrelated with this, too. >=20 > make installworld works too, as does extracting the binary sets. The = new installer > should work, but I=92ve not tried it. It would be handy for those of us wanting to cross-build FreeBSD/arm=20 for someone who is familiar with the build process to give a quick=20 example of how to update a FreeBSD/arm installation that is cross-built=20= on another system. In the past, I've had the impression that the build=20= infrastructure on the target system sometimes needs to be in alignment=20= with the new kernel/world you're trying to install, and so NFS-mounting=20= /usr/src and /usr/obj or copying it to the target system fails to yield=20= a successful "make installworld" on the target system. Maybe this is=20 no longer the case, as I believe great strides have been made in the=20 realm of cross-building. Up to now, I have largely used Crochet to build images for my R-PI and=20= BBB. That's okay for initial install, but I'm much more familiar with=20= updating from source and would like to do that from then on. In the=20 past, FreeBSD/arm has been too flaky for me to do a native build (I've=20= posted here about that in the past), but, besides that, it would be=20 nice to cut down the long native build times by cross-building on a=20 much faster system. I have an R-PI and BBB and would like to cross-build (for update=20 purposes) on my FreeBSD/amd64 10-STABLE system. Could you post a known=20= way to do this? I can NFS-mount from the FreeBSD/amd64 or else have it=20= put /usr/src and /usr/obj on an USB external hard drive that I can then=20= connect to my R-PI or BBB for updating. Either is okay with me. Thanks in advance. Cheers, Paul. PS: What is the make target to build the binary sets? Does this work=20 when cross-building? From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 14:52:16 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 0BBE0375 for ; Fri, 8 Aug 2014 14:52:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D452F2D2B for ; Fri, 8 Aug 2014 14:52:15 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XFlWf-0005fQ-UN; Fri, 08 Aug 2014 14:52:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s78EqCDQ021571; Fri, 8 Aug 2014 08:52:12 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+y9CnmC2GVBkYrcKKhvAuc X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Loading modules with KB920X panics From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <53E46361.4020605@selasky.org> References: <53E1E122.9040304@selasky.org> <1407462608.56408.350.camel@revolution.hippie.lan> <53E46361.4020605@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Aug 2014 08:52:11 -0600 Message-ID: <1407509531.56408.358.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm 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: Fri, 08 Aug 2014 14:52:16 -0000 On Fri, 2014-08-08 at 07:42 +0200, Hans Petter Selasky wrote: > On 08/08/14 03:50, Ian Lepore wrote: > > On Wed, 2014-08-06 at 10:02 +0200, Hans Petter Selasky wrote: > >> Hi, > >> > >> I'm building a custom module for KB920X and it panics when loading > >> because structures like Elf32_Rel and Elf32_Rela are not aligned. > >> > >> I added __packed keyword and the errors seems to be going away. > >> > >> Any clues what is wrong? > >> > >> .ko file can be supplied. > >> > >> FreeBSD-current > >> > > > > We load .ko modules on our at91rm92 stuff at work (although I haven't > > tested anything newer than 10.0 mid-last year). > > > > It seems odd that the reloc info would be unaligned. The ldscript > > should align the start of the section, and it should stay aligned after > > that. > > > > Hi, > > This was an out-of-the kernel module, built under the build environment > for ARM. Can you point me to the linker script responsible for this? > > I specified: --warn-section-align > > And it output some warnings. Any clues how I can nail this down? > > If someone is interested I can give you the source code and build > instructions. > > --HPS Sure, send the stuff to me and I'll see if I can figure anything out. I've just discovered there isn't a separate ldscript for building modules, it just uses the generic arm script compiled into ld. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 14:57:07 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 756CE7B6 for ; Fri, 8 Aug 2014 14:57:07 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 0A2D82D7B for ; Fri, 8 Aug 2014 14:57:06 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id f8so2664937wiw.3 for ; Fri, 08 Aug 2014 07:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DQlS1MrHAEMgApoKMyDHcAhwZl8OBG/NoOnEYAfeoYQ=; b=pdNyAJwtv/kkNwKSnYxXXvX4Ka0TUCUDgvZkSTgz/gKNJF8ljLZjirH1UD8JSc+DQh BVL2RlshS/jf2WCOV46RCBFq4dnXjbSFu7ipFFfrxhPZsd0MFsV0joWmgG3lrjrT0B4u 46qaJfqB0/+x/5QAhwlj/21eNOc/FDhgSiE4CsKUwQPo4yNSFA49iRFP7Ri0byffj7Us QiWwpDkVXOm2cj3ZClhjt6Om2+tAo5MAR8k0EvPcAHzSOX+K0icy/PYrPVdpkgY9xA21 QEQ4EN9xuRuZiHVPnkF3tKiNwxf1JSyNmENghRVHKAiJzQ1QjEa0tAHzl2lkFX0d11Az +Aog== X-Received: by 10.180.99.65 with SMTP id eo1mr4981487wib.12.1407509825247; Fri, 08 Aug 2014 07:57:05 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:434:a679:7428:2e35? ([2001:1620:ff0:c51:434:a679:7428:2e35]) by mx.google.com with ESMTPSA id eb4sm7881926wic.16.2014.08.08.07.57.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 07:57:04 -0700 (PDT) Message-ID: <53E4E53F.30905@gmail.com> Date: Fri, 08 Aug 2014 16:57:03 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: freebsd-arm Subject: Re: What platform do you use? References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <20140805182438.GP88623@funkthat.com> <53E3E2C7.9000802@hot.ee> <24403276-D738-4CB1-A3BE-BBB72D4370C6@bsdimp.com> <724D10EE-F6DF-4366-91CF-AE4419847389@gromit.dlib.vt.edu> In-Reply-To: <724D10EE-F6DF-4366-91CF-AE4419847389@gromit.dlib.vt.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 08 Aug 2014 14:57:07 -0000 Am 08.08.2014 15:35, schrieb Paul Mather: > On Aug 7, 2014, at 5:34 PM, Warner Losh wrote: > >> On Aug 7, 2014, at 2:34 PM, Sulev-Madis Silber (ketas) wrote: >> >>> On 2014-08-05 21:24, John-Mark Gurney wrote: >>>> I also have a BBW that I occasionally test w/ but since I haven't got >>>> it netbooting, the cost of building an entire image and writing it to >>>> SLOW microsd prevents me from testing as much... >>> I wonder why people like to update their embedded systems by taking card >>> out, completely overwriting it with new data and putting card back in. >>> No wonder that it's slow, complex & heedlessly wears out your flash. >>> >>> If I do this in my BBB I would get myself pissed very soon because of >>> the effort required. I never bothered to netboot too, because I wanted >>> to test it in insecure network conditions. >>> I mean, I don't remember a case where I needed to take HDD to another >>> machine for upgrade. The issue where it's not practical to compile >>> something locally is completely unrelated with this, too. >> make installworld works too, as does extracting the binary sets. The new installer >> should work, but I’ve not tried it. > It would be handy for those of us wanting to cross-build FreeBSD/arm > for someone who is familiar with the build process to give a quick > example of how to update a FreeBSD/arm installation that is cross-built > on another system. In the past, I've had the impression that the build > infrastructure on the target system sometimes needs to be in alignment > with the new kernel/world you're trying to install, and so NFS-mounting > /usr/src and /usr/obj or copying it to the target system fails to yield > a successful "make installworld" on the target system. Maybe this is > no longer the case, as I believe great strides have been made in the > realm of cross-building. > > Up to now, I have largely used Crochet to build images for my R-PI and > BBB. That's okay for initial install, but I'm much more familiar with > updating from source and would like to do that from then on. In the > past, FreeBSD/arm has been too flaky for me to do a native build (I've > posted here about that in the past), but, besides that, it would be > nice to cut down the long native build times by cross-building on a > much faster system. > > I have an R-PI and BBB and would like to cross-build (for update > purposes) on my FreeBSD/amd64 10-STABLE system. Could you post a known > way to do this? I can NFS-mount from the FreeBSD/amd64 or else have it > put /usr/src and /usr/obj on an USB external hard drive that I can then > connect to my R-PI or BBB for updating. Either is okay with me. > > Thanks in advance. > > The way I do it is cross-compiling everything needed on an ssh enabled remote machine, and installing it into a folder on that machine with DESTDIR= On my arm machine then as root I do "cd /" and "chflags -R noschg *" and "ssh user@host tar -cpf - /destdirfolder/* | tar -xpf - " And voilà, world is installed. I then copy the kernel from the obj dir to my boot partition via scp and reboot. Usually this works. Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 16:19:32 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 0B21CBEE for ; Fri, 8 Aug 2014 16:19:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7C9127E3 for ; Fri, 8 Aug 2014 16:19:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s78GJVSv017820 for ; Fri, 8 Aug 2014 16:19:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 192516] New: DTrace not yet supported on ARM Date: Fri, 08 Aug 2014 16:19:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gnn@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 08 Aug 2014 16:19:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192516 Bug ID: 192516 Summary: DTrace not yet supported on ARM Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: gnn@FreeBSD.org Created attachment 145527 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145527&action=edit Patch from gonzo@ to get DTrace running on ARM DTrace is not currently supported on ARM. There is a patch, attached, from gonzo@ which gets us started down this road. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 16:19:54 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 E4595C27 for ; Fri, 8 Aug 2014 16:19:54 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD20B27E8 for ; Fri, 8 Aug 2014 16:19:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s78GJsqA017953 for ; Fri, 8 Aug 2014 16:19:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 192516] DTrace not yet supported on ARM Date: Fri, 08 Aug 2014 16:19:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gnn@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 08 Aug 2014 16:19:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192516 George V. Neville-Neil changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-arm@FreeBSD.org |gnn@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 16:35:48 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 0F321255; Fri, 8 Aug 2014 16:35:48 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7BCF29FA; Fri, 8 Aug 2014 16:35:47 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XFn8n-0008ck-BQ; Fri, 08 Aug 2014 16:35:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s78GZeV6021745; Fri, 8 Aug 2014 10:35:40 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5WdfyPuARYM7I5Vxd0qIJ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [Bug 192516] New: DTrace not yet supported on ARM From: Ian Lepore To: bugzilla-noreply@freebsd.org In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Aug 2014 10:35:40 -0600 Message-ID: <1407515740.56408.378.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org 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: Fri, 08 Aug 2014 16:35:48 -0000 On Fri, 2014-08-08 at 16:19 +0000, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192516 > > Bug ID: 192516 > Summary: DTrace not yet supported on ARM > Product: Base System > Version: 11.0-CURRENT > Hardware: Any > OS: Any > Status: Needs Triage > Severity: Affects Many People > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: gnn@FreeBSD.org > > Created attachment 145527 > --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145527&action=edit > Patch from gonzo@ to get DTrace running on ARM > > DTrace is not currently supported on ARM. There is a patch, attached, from > gonzo@ which gets us started down this road. > FYI, someone was working on this last year (Howard Su ) but I haven't heard from him in ages, either on arm@ or on irc. I'm afraid he got frustrated and wandered away because we really didn't have the resources available to give him any support in his efforts. There are some old messages about it in the arm@ archives. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 17:36:54 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 2B7C5EF9 for ; Fri, 8 Aug 2014 17:36:54 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1D942171 for ; Fri, 8 Aug 2014 17:36:53 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XFo5s-0007IB-Ce for freebsd-arm@freebsd.org; Fri, 08 Aug 2014 19:36:44 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: testing new pmap code References: <53CFE285.9040101@rice.edu> Date: Fri, 08 Aug 2014 19:36:43 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <53CFE285.9040101@rice.edu> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: ba572e8a3bde05b4b19613c12a9e49fc 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: Fri, 08 Aug 2014 17:36:54 -0000 On Wed, 23 Jul 2014 18:27:49 +0200, Alan Cox wrote: > Folks, > > About a week ago I committed some new pmap code on all architectures, > including arm. However, that code isn't "active" until the attached > patch is committed. Before I commit this patch, I'd like to ask people > to test it on arm "classic" and especially v6. (The v6 pmap changes > were more complicated.) > > Here is how to test it. Before you apply the kernel patch, compile and > run the attached program, mlockall2A.c, in a loop. Something like this: > > # while ( 1 ) > while? ./mlockall2A > while? sysctl vm.stats.vm.v_wire_count > while? sleep 7 > while? end > > You should see the wire count steadily increase, because there is a > wired page leak. > > Now, apply the kernel patch, and repeat the same test. This time, the > wire count should stabilize. > > If you're testing on arm v6, substitute > > sysctl vm.stats.vm.v_wire_count vm.pmap.section > > for > > sysctl vm.stats.vm.v_wire_count > > so that I can verify that we're handling superpages correctly. > > Thanks, > Alan > I setup my Sheevaplug (armv5?) with 11-CURRENT. Does this need testing still? I saw that the patch is already committed. And running the test does not crash my machine. The v_wire_count goes up, seems to stabilize and after I stop the loop it goes down again. Ronald. From owner-freebsd-arm@FreeBSD.ORG Fri Aug 8 22:16:01 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 3B7448FA; Fri, 8 Aug 2014 22:16:01 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CA7325C0; Fri, 8 Aug 2014 22:16:00 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XFsS7-0004uf-CM; Fri, 08 Aug 2014 22:15:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s78MFvlO022292; Fri, 8 Aug 2014 16:15:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+G8Q3HNsPlIMSbzucOsbZO X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] mge driver / elf reloc From: Ian Lepore To: Fabien Thomas In-Reply-To: References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Aug 2014 16:15:56 -0600 Message-ID: <1407536156.56408.412.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@freebsd.org 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: Fri, 08 Aug 2014 22:16:01 -0000 On Mon, 2014-07-21 at 10:40 +0200, Fabien Thomas wrote: > On 21 Jul 2014, at 01:10, John-Mark Gurney wrote: > > > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > >> > >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote: > >> > >>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > >>>> Sorry to take so long to reply to this, I'm trying to get caught up. I > >>>> see you've already committed the mge fixes. I think the ELF alignment > >>>> fix looks good and should also be committed. > >>> > >>> So, re the elf alignment... > >>> > >>> I think we should get a set of macros that handle load/stores to/from > >>> unaligned addresses that are transparent to the caller.... I need > >>> these for some other code I'm writing... > >>> > >>> I thought Open/Net had these available, but I can't seem to find them > >>> right now... > >> > >> $ man 9 byteorder > >> > >> is most of what you want, lacking only some aliases to pick > >> the correct macro for native byte order. > > > > Um, those doesn't help if you want native endian order... > > > > Also, only the enc/dec functions are documented to work on non-aligned > > address, so that doesn't help in most cases... > > Yes, having an API to read unaligned pointer is better than than using local fix like in the patch. > Tell me if you add one and I can adapt the patch. > > Fabien > So can we just get this patch committed as-is, and then maybe convert it later to the much-desired "something better" that this discussion deteriorated into? http://people.freebsd.org/~fabient/ARM/patch-arm_elf_alignfix If you've ever wondered whether there are real costs to bikeshedding, this is an example of such. This relocation patch is the fix to the kernel module loading problem HPS has been having, and who knows how much time he had to waste debugging it. I know I spent 4 hours on it today before discovering that the problem was known and fixed, only the fix isn't committed yet. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 00:16:57 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 47D93D97 for ; Sat, 9 Aug 2014 00:16:57 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (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 D0A0E2151 for ; Sat, 9 Aug 2014 00:16:56 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id k14so6340102wgh.32 for ; Fri, 08 Aug 2014 17:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=z6OVJBJ/UWaAzmvubX8YFosRK3IfTpnp7pS6fmx43J8=; b=A4qj7PoMTXanh03gZ8uEoyyS9ZA61+M4SDlCSe37u86QBiSDb9FYLVtUZS7ZX2QG7g ZYza9u8GI0J3t5ikLo+LE/AUmALlbKvUg5bUP72Paj/EN034Wf2F1Csa6DP1R1jrddUQ Id8+/Ky7y0Uo1IdTbh/nP3mvuTj0QPbFALfi0T34x2NXrh4UgoHDgSF7g4vESjX6Pki2 qJ8CJKLBG3Z7F0XWDicLHbAZXFc7p/SRuxkydrxzUkjFNZPkyEnKtGkHYJ64IRicyjGg p++6q4QcR+sV1jb+RVZUPO94XcDiiSbELsxXrxmyKIJgs1KqCvuIBLNOb9dr3Qk2Riw6 j4Iw== X-Received: by 10.194.8.35 with SMTP id o3mr35043299wja.3.1407543415052; Fri, 08 Aug 2014 17:16:55 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id r20sm12613696wik.0.2014.08.08.17.16.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 17:16:54 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53E5686F.60007@hot.ee> Date: Sat, 09 Aug 2014 03:16:47 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mattia Rossi Subject: Re: What platform do you use? References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <20140805182438.GP88623@funkthat.com> <53E3E2C7.9000802@hot.ee> <24403276-D738-4CB1-A3BE-BBB72D4370C6@bsdimp.com> <724D10EE-F6DF-4366-91CF-AE4419847389@gromit.dlib.vt.edu> <53E4E53F.30905@gmail.com> In-Reply-To: <53E4E53F.30905@gmail.com> X-TagToolbar-Keys: D20140809031646666 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm 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: Sat, 09 Aug 2014 00:16:57 -0000 On 2014-08-08 17:57, Mattia Rossi wrote: > > Am 08.08.2014 15:35, schrieb Paul Mather: >> On Aug 7, 2014, at 5:34 PM, Warner Losh wrote: >> >>> On Aug 7, 2014, at 2:34 PM, Sulev-Madis Silber (ketas) >>> wrote: >>> >>>> On 2014-08-05 21:24, John-Mark Gurney wrote: >>>>> I also have a BBW that I occasionally test w/ but since I haven't got >>>>> it netbooting, the cost of building an entire image and writing it to >>>>> SLOW microsd prevents me from testing as much... >>>> I wonder why people like to update their embedded systems by taking >>>> card >>>> out, completely overwriting it with new data and putting card back in. >>>> No wonder that it's slow, complex & heedlessly wears out your flash. >>>> >>>> If I do this in my BBB I would get myself pissed very soon because of >>>> the effort required. I never bothered to netboot too, because I wanted >>>> to test it in insecure network conditions. >>>> I mean, I don't remember a case where I needed to take HDD to another >>>> machine for upgrade. The issue where it's not practical to compile >>>> something locally is completely unrelated with this, too. >>> make installworld works too, as does extracting the binary sets. The >>> new installer >>> should work, but I’ve not tried it. >> It would be handy for those of us wanting to cross-build FreeBSD/arm >> for someone who is familiar with the build process to give a quick >> example of how to update a FreeBSD/arm installation that is cross-built >> on another system. In the past, I've had the impression that the build >> infrastructure on the target system sometimes needs to be in alignment >> with the new kernel/world you're trying to install, and so NFS-mounting >> /usr/src and /usr/obj or copying it to the target system fails to yield >> a successful "make installworld" on the target system. Maybe this is >> no longer the case, as I believe great strides have been made in the >> realm of cross-building. >> >> Up to now, I have largely used Crochet to build images for my R-PI and >> BBB. That's okay for initial install, but I'm much more familiar with >> updating from source and would like to do that from then on. In the >> past, FreeBSD/arm has been too flaky for me to do a native build (I've >> posted here about that in the past), but, besides that, it would be >> nice to cut down the long native build times by cross-building on a >> much faster system. >> >> I have an R-PI and BBB and would like to cross-build (for update >> purposes) on my FreeBSD/amd64 10-STABLE system. Could you post a known >> way to do this? I can NFS-mount from the FreeBSD/amd64 or else have it >> put /usr/src and /usr/obj on an USB external hard drive that I can then >> connect to my R-PI or BBB for updating. Either is okay with me. >> >> Thanks in advance. >> >> > The way I do it is cross-compiling everything needed on an ssh enabled > remote machine, and installing it into a folder on that machine with > DESTDIR= > On my arm machine then as root I do > "cd /" > and > "chflags -R noschg *" > and > "ssh user@host tar -cpf - /destdirfolder/* | tar -xpf - " > And voilà, world is installed. > I then copy the kernel from the obj dir to my boot partition via scp and > reboot. > Usually this works. > > Cheers, > > Mat I use rsync for this. Avoids unneeded writes and is much faster in any way. You want rsync with file flags patch for proper permissions sync (and it's still bit buggy, so I created workaround). Since I don't make any changes inside embedded system, I can just create full system locally and have exact copy of it in another system where it actually runs. I found that best way to create that locally is to unionfs-mount all the dirs together, however it blows up when you have overlay 30 levels deep. Especially if you try to run rsync on this impressive onion (workaround was to use tar to make copy of it first). You can bring your directory trees together with just tar too, however I didn't like how directory mtimes changed there. Those multiple dirs would contain things like result of installworld, your config, your ports, etc... What runs inside my BBB now and how I upgrade it, is largely described here: http://ketas.si.pri.ee/bbb/ From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 02:26:53 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 E1EBDBB3; Sat, 9 Aug 2014 02:26:53 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id C4B552BA8; Sat, 9 Aug 2014 02:26:53 +0000 (UTC) Received: from [IPv6:2601:9:8280:5fd:d52d:c118:dd20:86fd] (unknown [IPv6:2601:9:8280:5fd:d52d:c118:dd20:86fd]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 755AF34A9D5; Fri, 8 Aug 2014 19:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1407551213; bh=wqFCR00p+LIBh6/yLpoPiGcqNO50pwOtuqRLS9bpwss=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=mPE3MjDpQYKnA3zIaG4E7gcYmUrY/SUbe/hrJQ+Pyr/RVDgFO8rusDXtWL7IV3qUt /DPZ+mdVckFB8wozGXYLIC5xsqy/kcJM7o1BkUTzPejBIUT2H0M4l1C8RKGEiz8p4m J2Lr4hML9Ywa+1FB0qb+J9rkyXc6hzERhXVkUXHk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Bug 192516] New: DTrace not yet supported on ARM From: Rui Paulo In-Reply-To: <1407515740.56408.378.camel@revolution.hippie.lan> Date: Fri, 8 Aug 2014 19:26:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1407515740.56408.378.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@FreeBSD.org, bugzilla-noreply@freebsd.org 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: Sat, 09 Aug 2014 02:26:54 -0000 On Aug 8, 2014, at 9:35, Ian Lepore wrote: > On Fri, 2014-08-08 at 16:19 +0000, bugzilla-noreply@freebsd.org wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192516 >>=20 >> Bug ID: 192516 >> Summary: DTrace not yet supported on ARM >> Product: Base System >> Version: 11.0-CURRENT >> Hardware: Any >> OS: Any >> Status: Needs Triage >> Severity: Affects Many People >> Priority: --- >> Component: arm >> Assignee: freebsd-arm@FreeBSD.org >> Reporter: gnn@FreeBSD.org >>=20 >> Created attachment 145527 >> --> = https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D145527&action=3Dedit= >> Patch from gonzo@ to get DTrace running on ARM >>=20 >> DTrace is not currently supported on ARM. There is a patch, = attached, from >> gonzo@ which gets us started down this road. >>=20 >=20 > FYI, someone was working on this last year (Howard Su > ) but I haven't heard from him in ages, either on > arm@ or on irc. I'm afraid he got frustrated and wandered away = because > we really didn't have the resources available to give him any support = in > his efforts. There are some old messages about it in the arm@ = archives. What resources are you talking about? There at least two active DTrace = developers who could try to help him. It's the first time I'm hearing = about a DTrace patch and the first time I know about Howard Su working = on it. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 02:56:14 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 43019E77 for ; Sat, 9 Aug 2014 02:56:14 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 161D92EB2 for ; Sat, 9 Aug 2014 02:56:13 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XFwpI-000Itj-7b; Sat, 09 Aug 2014 02:56:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s792uB4U022645; Fri, 8 Aug 2014 20:56:11 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19sq5UoHclSOlbpCy2OuXj7 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [Bug 192516] New: DTrace not yet supported on ARM From: Ian Lepore To: Rui Paulo In-Reply-To: References: <1407515740.56408.378.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Aug 2014 20:56:10 -0600 Message-ID: <1407552970.56408.440.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org 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: Sat, 09 Aug 2014 02:56:14 -0000 On Fri, 2014-08-08 at 19:26 -0700, Rui Paulo wrote: > On Aug 8, 2014, at 9:35, Ian Lepore wrote: > > > On Fri, 2014-08-08 at 16:19 +0000, bugzilla-noreply@freebsd.org wrote: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192516 > >> > >> Bug ID: 192516 > >> Summary: DTrace not yet supported on ARM > >> Product: Base System > >> Version: 11.0-CURRENT > >> Hardware: Any > >> OS: Any > >> Status: Needs Triage > >> Severity: Affects Many People > >> Priority: --- > >> Component: arm > >> Assignee: freebsd-arm@FreeBSD.org > >> Reporter: gnn@FreeBSD.org > >> > >> Created attachment 145527 > >> --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145527&action=edit > >> Patch from gonzo@ to get DTrace running on ARM > >> > >> DTrace is not currently supported on ARM. There is a patch, attached, from > >> gonzo@ which gets us started down this road. > >> > > > > FYI, someone was working on this last year (Howard Su > > ) but I haven't heard from him in ages, either on > > arm@ or on irc. I'm afraid he got frustrated and wandered away because > > we really didn't have the resources available to give him any support in > > his efforts. There are some old messages about it in the arm@ archives. > > What resources are you talking about? There at least two active DTrace developers who could try to help him. It's the first time I'm hearing about a DTrace patch and the first time I know about Howard Su working on it. I'm talking about resources like asking for reviews of his patches (and nobody ever did, myself included). Answering questions, providing advice, basic stuff that we're hard pressed to do, quite frankly. I could spend my entire waking existance doing just that kind of stuff, and still not keep up, and also never get a line of code written. If you didn't know, maybe you weren't reading arm@ back then... http://lists.freebsd.org/pipermail/freebsd-arm/2013-November/006957.html http://lists.freebsd.org/pipermail/freebsd-arm/2013-December/007024.html He also used to hang out in #bsdmips and try to get arm-specific help with his dtrace work, but the few of us who probably could have helped were all too busy with our own ENOTIME situations to offer much. (To others reading along... oddly enough #bsdmips on efnet is the right place to get arm-freebsd developer info, although ENOTIME is still a big problem.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 03:22:46 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 5C20F31A; Sat, 9 Aug 2014 03:22:46 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD0C228A; Sat, 9 Aug 2014 03:22:46 +0000 (UTC) Received: from [IPv6:2601:9:8280:5fd:d52d:c118:dd20:86fd] (unknown [IPv6:2601:9:8280:5fd:d52d:c118:dd20:86fd]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 9149C34A9F4; Fri, 8 Aug 2014 20:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1407554565; bh=fgA9LxXDXTb/AGXZflPlPtA14M/xP2PDuSAV8GBxPQA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OYQcq8ijcE1yMluoQaUE3b29xjMN7lCAY1teI6GgHZ8BcWv4/YfDgTQ3XWP8bTaKQ jdlebSSXSyuNmb7rdupmpr63gbTUeirV2cR74UALxqTwza1aBvdMMak0D40qZqL3bH ibjFhaoU/vAV2XOcblhNDQ6FNEnT8vqxOVkCzzCs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Bug 192516] New: DTrace not yet supported on ARM From: Rui Paulo In-Reply-To: <1407552970.56408.440.camel@revolution.hippie.lan> Date: Fri, 8 Aug 2014 20:22:45 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <1407515740.56408.378.camel@revolution.hippie.lan> <1407552970.56408.440.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@FreeBSD.org 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: Sat, 09 Aug 2014 03:22:46 -0000 On Aug 8, 2014, at 19:56, Ian Lepore wrote: > I'm talking about resources like asking for reviews of his patches (and > nobody ever did, myself included). Answering questions, providing > advice, basic stuff that we're hard pressed to do, quite frankly. I > could spend my entire waking existance doing just that kind of stuff, > and still not keep up, and also never get a line of code written. Yup, that's why we have a bug tracker. :-) > If you didn't know, maybe you weren't reading arm@ back then... > > http://lists.freebsd.org/pipermail/freebsd-arm/2013-November/006957.html There's no patch here. Do you have it? -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 03:30:37 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 ACDEB516 for ; Sat, 9 Aug 2014 03:30:37 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9186922D2 for ; Sat, 9 Aug 2014 03:30:36 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XFxMT-000PJV-4N; Sat, 09 Aug 2014 03:30:29 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s793USqD022710; Fri, 8 Aug 2014 21:30:28 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/xKXfk9U3FmNRleMyD+OED X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [Bug 192516] New: DTrace not yet supported on ARM From: Ian Lepore To: Rui Paulo In-Reply-To: References: <1407515740.56408.378.camel@revolution.hippie.lan> <1407552970.56408.440.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="=-1VnxsOIhDnJzpH5E7tuZ" Date: Fri, 08 Aug 2014 21:30:27 -0600 Message-ID: <1407555027.56408.442.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org 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: Sat, 09 Aug 2014 03:30:37 -0000 --=-1VnxsOIhDnJzpH5E7tuZ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2014-08-08 at 20:22 -0700, Rui Paulo wrote: > On Aug 8, 2014, at 19:56, Ian Lepore wrote: > > I'm talking about resources like asking for reviews of his patches (and > > nobody ever did, myself included). Answering questions, providing > > advice, basic stuff that we're hard pressed to do, quite frankly. I > > could spend my entire waking existance doing just that kind of stuff, > > and still not keep up, and also never get a line of code written. > > Yup, that's why we have a bug tracker. :-) > That response strikes me as being a bit of a non sequitor. > > If you didn't know, maybe you weren't reading arm@ back then... > > > > http://lists.freebsd.org/pipermail/freebsd-arm/2013-November/006957.html > > There's no patch here. Do you have it? Attached. -- Ian --=-1VnxsOIhDnJzpH5E7tuZ Content-Disposition: attachment; filename="dtrace.1121.diff" Content-Type: text/x-patch; name="dtrace.1121.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff --git a/cddl/contrib/opensolaris/lib/libdtrace/arm/dt_isadep.c b/cddl/contrib/opensolaris/lib/libdtrace/arm/dt_isadep.c new file mode 100644 index 0000000..7e73794 --- /dev/null +++ b/cddl/contrib/opensolaris/lib/libdtrace/arm/dt_isadep.c @@ -0,0 +1,181 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License, Version 1.0 only + * (the "License"). You may not use this file except in compliance + * with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + */ +/* + * Copyright 2005 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ + +#pragma ident "%Z%%M% %I% %E% SMI" + +#include +#include +#include +#include +#include + +#include +#include + +#define OP(x) ((x) >> 30) +#define OP2(x) (((x) >> 22) & 0x07) +#define COND(x) (((x) >> 25) & 0x0f) +#define A(x) (((x) >> 29) & 0x01) + +#define OP_BRANCH 0 + +#define OP2_BPcc 0x1 +#define OP2_Bicc 0x2 +#define OP2_BPr 0x3 +#define OP2_FBPfcc 0x5 +#define OP2_FBfcc 0x6 + +/*ARGSUSED*/ +int +dt_pid_create_entry_probe(struct ps_prochandle *P, dtrace_hdl_t *dtp, + fasttrap_probe_spec_t *ftp, const GElf_Sym *symp) +{ + ftp->ftps_type = DTFTP_ENTRY; + ftp->ftps_pc = (uintptr_t)symp->st_value; + ftp->ftps_size = (size_t)symp->st_size; + ftp->ftps_noffs = 1; + ftp->ftps_offs[0] = 0; + + if (ioctl(dtp->dt_ftfd, FASTTRAPIOC_MAKEPROBE, ftp) != 0) { + dt_dprintf("fasttrap probe creation ioctl failed: %s\n", + strerror(errno)); + return (dt_set_errno(dtp, errno)); + } + + return (1); +} + +int +dt_pid_create_return_probe(struct ps_prochandle *P, dtrace_hdl_t *dtp, + fasttrap_probe_spec_t *ftp, const GElf_Sym *symp, uint64_t *stret) +{ + + uint32_t *text; + int i; + int srdepth = 0; + + dt_dprintf("%s: unimplemented\n", __func__); + return (DT_PROC_ERR); + + if ((text = malloc(symp->st_size + 4)) == NULL) { + dt_dprintf("mr sparkle: malloc() failed\n"); + return (DT_PROC_ERR); + } + + if (Pread(P, text, symp->st_size, symp->st_value) != symp->st_size) { + dt_dprintf("mr sparkle: Pread() failed\n"); + free(text); + return (DT_PROC_ERR); + } + + /* + * Leave a dummy instruction in the last slot to simplify edge + * conditions. + */ + text[symp->st_size / 4] = 0; + + ftp->ftps_type = DTFTP_RETURN; + ftp->ftps_pc = symp->st_value; + ftp->ftps_size = symp->st_size; + ftp->ftps_noffs = 0; + + + free(text); + if (ftp->ftps_noffs > 0) { + if (ioctl(dtp->dt_ftfd, FASTTRAPIOC_MAKEPROBE, ftp) != 0) { + dt_dprintf("fasttrap probe creation ioctl failed: %s\n", + strerror(errno)); + return (dt_set_errno(dtp, errno)); + } + } + + + return (ftp->ftps_noffs); +} + +/*ARGSUSED*/ +int +dt_pid_create_offset_probe(struct ps_prochandle *P, dtrace_hdl_t *dtp, + fasttrap_probe_spec_t *ftp, const GElf_Sym *symp, ulong_t off) +{ + if (off & 0x3) + return (DT_PROC_ALIGN); + + ftp->ftps_type = DTFTP_OFFSETS; + ftp->ftps_pc = (uintptr_t)symp->st_value; + ftp->ftps_size = (size_t)symp->st_size; + ftp->ftps_noffs = 1; + ftp->ftps_offs[0] = off; + + if (ioctl(dtp->dt_ftfd, FASTTRAPIOC_MAKEPROBE, ftp) != 0) { + dt_dprintf("fasttrap probe creation ioctl failed: %s\n", + strerror(errno)); + return (dt_set_errno(dtp, errno)); + } + + return (1); +} + +/*ARGSUSED*/ +int +dt_pid_create_glob_offset_probes(struct ps_prochandle *P, dtrace_hdl_t *dtp, + fasttrap_probe_spec_t *ftp, const GElf_Sym *symp, const char *pattern) +{ + ulong_t i; + + ftp->ftps_type = DTFTP_OFFSETS; + ftp->ftps_pc = (uintptr_t)symp->st_value; + ftp->ftps_size = (size_t)symp->st_size; + ftp->ftps_noffs = 0; + + /* + * If we're matching against everything, just iterate through each + * instruction in the function, otherwise look for matching offset + * names by constructing the string and comparing it against the + * pattern. + */ + if (strcmp("*", pattern) == 0) { + for (i = 0; i < symp->st_size; i += 4) { + ftp->ftps_offs[ftp->ftps_noffs++] = i; + } + } else { + char name[sizeof (i) * 2 + 1]; + + for (i = 0; i < symp->st_size; i += 4) { + (void) sprintf(name, "%lx", i); + if (gmatch(name, pattern)) + ftp->ftps_offs[ftp->ftps_noffs++] = i; + } + } + + if (ioctl(dtp->dt_ftfd, FASTTRAPIOC_MAKEPROBE, ftp) != 0) { + dt_dprintf("fasttrap probe creation ioctl failed: %s\n", + strerror(errno)); + return (dt_set_errno(dtp, errno)); + } + + return (ftp->ftps_noffs); +} diff --git a/cddl/contrib/opensolaris/tools/ctf/cvt/ctf.c b/cddl/contrib/opensolaris/tools/ctf/cvt/ctf.c index 82ec5fa..c6f47af 100644 --- a/cddl/contrib/opensolaris/tools/ctf/cvt/ctf.c +++ b/cddl/contrib/opensolaris/tools/ctf/cvt/ctf.c @@ -169,12 +169,12 @@ write_objects(iidesc_t *idp, ctf_buf_t *b) { ushort_t id = (idp ? idp->ii_dtype->t_id : 0); - ctf_buf_write(b, &id, sizeof (id)); - if (target_requires_swap) { SWAP_16(id); } + ctf_buf_write(b, &id, sizeof (id)); + debug(3, "Wrote object %s (%d)\n", (idp ? idp->ii_name : "(null)"), id); } diff --git a/cddl/lib/Makefile b/cddl/lib/Makefile index 53d402a..ff34d68 100644 --- a/cddl/lib/Makefile +++ b/cddl/lib/Makefile @@ -22,7 +22,8 @@ _libzpool= libzpool .endif .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" || \ - ${MACHINE_CPUARCH} == "mips" || ${MACHINE_CPUARCH} == "powerpc" + ${MACHINE_CPUARCH} == "mips" || ${MACHINE_CPUARCH} == "powerpc" || \ + ${MACHINE_CPUARCH} == "arm" _drti= drti _libdtrace= libdtrace .endif diff --git a/cddl/lib/libdtrace/Makefile b/cddl/lib/libdtrace/Makefile index 46f7046..f9b0214 100644 --- a/cddl/lib/libdtrace/Makefile +++ b/cddl/lib/libdtrace/Makefile @@ -79,6 +79,10 @@ CFLAGS+= -I${OPENSOLARIS_SYS_DISTDIR}/uts/sparc CFLAGS+= -I${OPENSOLARIS_SYS_DISTDIR}/uts/mips .PATH: ${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libdtrace/mips .PATH: ${.CURDIR}/../../../sys/cddl/dev/dtrace/mips +.elif ${MACHINE_CPUARCH} == "arm" +CFLAGS+= -I${OPENSOLARIS_SYS_DISTDIR}/uts/arm +.PATH: ${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libdtrace/arm +.PATH: ${.CURDIR}/../../../sys/cddl/dev/dtrace/arm .elif ${MACHINE_CPUARCH} == "powerpc" CFLAGS+= -I${OPENSOLARIS_SYS_DISTDIR}/uts/powerpc .PATH: ${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libdtrace/powerpc diff --git a/cddl/usr.sbin/Makefile b/cddl/usr.sbin/Makefile index fb2c437..ad8a998 100644 --- a/cddl/usr.sbin/Makefile +++ b/cddl/usr.sbin/Makefile @@ -21,6 +21,12 @@ _dtruss= dtruss _lockstat= lockstat .endif +.if ${MACHINE_CPUARCH} == "arm" +_dtrace= dtrace +_lockstat= lockstat +_dtruss= dtruss +.endif + .if ${MACHINE_CPUARCH} == "mips" _dtrace= dtrace .endif diff --git a/lib/Makefile b/lib/Makefile index bb8a7e1..db0f16d 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -233,6 +233,12 @@ _libsmb= libsmb _libsmb= libsmb .endif +.if ${MACHINE_CPUARCH} == "arm" +_libsmb= libsmb +_libproc= libproc +_librtld_db= librtld_db +.endif + .if ${MK_OPENSSL} != "no" _libmp= libmp .endif diff --git a/lib/libproc/proc_bkpt.c b/lib/libproc/proc_bkpt.c index 2c2761a..02a7ed6 100644 --- a/lib/libproc/proc_bkpt.c +++ b/lib/libproc/proc_bkpt.c @@ -51,6 +51,9 @@ __FBSDID("$FreeBSD$"); #elif defined(__powerpc__) #define BREAKPOINT_INSTR 0x7fe00008 /* trap */ #define BREAKPOINT_INSTR_SZ 4 +#elif defined(__arm__) +#define BREAKPOINT_INSTR 0xe7ffffff /* bkpt */ +#define BREAKPOINT_INSTR_SZ 4 #else #error "Add support for your architecture" #endif diff --git a/lib/libproc/proc_regs.c b/lib/libproc/proc_regs.c index 145c8fe..35d8d38 100644 --- a/lib/libproc/proc_regs.c +++ b/lib/libproc/proc_regs.c @@ -56,6 +56,8 @@ proc_regget(struct proc_handle *phdl, proc_reg_t reg, unsigned long *regvalue) case REG_PC: #if defined(__amd64__) *regvalue = regs.r_rip; +#elif defined(__arm__) + *regvalue = regs.r_pc; #elif defined(__i386__) *regvalue = regs.r_eip; #elif defined(__mips__) @@ -67,6 +69,8 @@ proc_regget(struct proc_handle *phdl, proc_reg_t reg, unsigned long *regvalue) case REG_SP: #if defined(__amd64__) *regvalue = regs.r_rsp; +#elif defined(__arm__) + *regvalue = regs.r_sp; #elif defined(__i386__) *regvalue = regs.r_esp; #elif defined(__mips__) @@ -99,6 +103,8 @@ proc_regset(struct proc_handle *phdl, proc_reg_t reg, unsigned long regvalue) case REG_PC: #if defined(__amd64__) regs.r_rip = regvalue; +#elif defined(__arm__) + regs.r_pc = regvalue; #elif defined(__i386__) regs.r_eip = regvalue; #elif defined(__mips__) @@ -110,6 +116,8 @@ proc_regset(struct proc_handle *phdl, proc_reg_t reg, unsigned long regvalue) case REG_SP: #if defined(__amd64__) regs.r_rsp = regvalue; +#elif defined(__arm__) + regs.r_sp = regvalue; #elif defined(__i386__) regs.r_esp = regvalue; #elif defined(__mips__) diff --git a/sys/arm/arm/exception.S b/sys/arm/arm/exception.S index 55a4f64..80b1734 100644 --- a/sys/arm/arm/exception.S +++ b/sys/arm/arm/exception.S @@ -47,12 +47,26 @@ */ #include "assym.s" - +#include "opt_kdtrace.h" #include #include #include __FBSDID("$FreeBSD$"); +#ifdef KDTRACE_HOOKS + .bss + .align 4 + .global _C_LABEL(dtrace_invop_jump_addr) +_C_LABEL(dtrace_invop_jump_addr): + .word 0 + .word 0 + + .global _C_LABEL(dtrace_invop_calltrap_addr) +_C_LABEL(dtrace_invop_calltrap_addr): + .word 0 + .word 0 +#endif + .text .align 0 @@ -239,7 +253,20 @@ END(undefined_entry) ENTRY_NP(undefinedinstruction_bounce) PUSHFRAMEINSVC +#ifdef notyet + adr r1, dtrace_invop_jump_addr + ldr r0, r1 + cmp r0, #0 + beq normal + + mrs r2, spsr_all + tst r2, #PSR_MODE + bne normal + bl r0 + +normal: +#endif mov r0, sp adr lr, exception_exit b _C_LABEL(undefinedinstruction) diff --git a/sys/arm/arm/identcpu.c b/sys/arm/arm/identcpu.c index 219d49c..1febfcf 100644 --- a/sys/arm/arm/identcpu.c +++ b/sys/arm/arm/identcpu.c @@ -461,7 +461,7 @@ identify_arm_cpu(void) u_int8_t type, linesize; int i; - cpuid = cpu_id(); + cpuid = cpu_ident(); if (cpuid == 0) { printf("Processor failed probe - no CPU ID\n"); diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c index c935a82..d9656db 100644 --- a/sys/arm/arm/machdep.c +++ b/sys/arm/arm/machdep.c @@ -835,8 +835,8 @@ fake_preload_metadata(struct arm_boot_params *abp __unused) strcpy((char*)&fake_preload[i++], "kernel"); i += 1; fake_preload[i++] = MODINFO_TYPE; - fake_preload[i++] = strlen("elf kernel") + 1; - strcpy((char*)&fake_preload[i++], "elf kernel"); + fake_preload[i++] = strlen("/boot/kernel/kernel") + 1; + strcpy((char*)&fake_preload[i++], "/boot/kernel/kernel"); i += 2; fake_preload[i++] = MODINFO_ADDR; fake_preload[i++] = sizeof(vm_offset_t); diff --git a/sys/arm/arm/trap.c b/sys/arm/arm/trap.c index 5021eec..d34846c 100644 --- a/sys/arm/arm/trap.c +++ b/sys/arm/arm/trap.c @@ -80,6 +80,7 @@ #include "opt_ktrace.h" +#include "opt_kdtrace.h" #include __FBSDID("$FreeBSD$"); @@ -122,6 +123,31 @@ __FBSDID("$FreeBSD$"); #include #endif +#ifdef KDTRACE_HOOKS +#include + +/* + * This is a hook which is initialised by the dtrace module + * to handle traps which might occur during DTrace probe + * execution. + */ +dtrace_trap_func_t dtrace_trap_func; + +dtrace_doubletrap_func_t dtrace_doubletrap_func; + +/* + * This is a hook which is initialised by the systrace module + * when it is loaded. This keeps the DTrace syscall provider + * implementation opaque. + */ +systrace_probe_func_t systrace_probe_func; + +/* + * These hooks are necessary for the pid and usdt providers. + */ +dtrace_pid_probe_ptr_t dtrace_pid_probe_ptr; +dtrace_return_probe_ptr_t dtrace_return_probe_ptr; +#endif void swi_handler(struct trapframe *); void undefinedinstruction(struct trapframe *); @@ -452,6 +478,7 @@ data_abort_handler(struct trapframe *tf) printf("\nvm_fault(%p, %x, %x, 0) -> %x\n", map, va, ftype, error); dab_fatal(tf, fsr, far, td, &ksig); + return; } @@ -492,6 +519,14 @@ dab_fatal(struct trapframe *tf, u_int fsr, u_int far, struct thread *td, { const char *mode; +#ifdef KDTRACE_HOOKS + if (!TRAP_USERMODE(tf)) + { + if (dtrace_trap_func != NULL && (*dtrace_trap_func)(tf, far & FAULT_TYPE_MASK)) + return (0); + } +#endif + mode = TRAP_USERMODE(tf) ? "user" : "kernel"; disable_interrupts(I32_bit|F32_bit); diff --git a/sys/arm/conf/BEAGLEBONE b/sys/arm/conf/BEAGLEBONE index 272d3e8..16c9a46 100644 --- a/sys/arm/conf/BEAGLEBONE +++ b/sys/arm/conf/BEAGLEBONE @@ -59,8 +59,8 @@ options KDB options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS -options WITNESS #Enable checks to detect deadlocks and cycles -options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed +#options WITNESS #Enable checks to detect deadlocks and cycles +#options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed #options DIAGNOSTIC # NFS support @@ -69,12 +69,12 @@ options NFSCL options NFSLOCKD # Uncomment this for NFS root -#options NFS_ROOT #NFS usable as /, requires NFSCL -#options BOOTP_NFSROOT -#options BOOTP_COMPAT -#options BOOTP -#options BOOTP_NFSV3 -#options BOOTP_WIRED_TO=cpsw0 +options NFS_ROOT #NFS usable as /, requires NFSCL +options BOOTP_NFSROOT +options BOOTP_COMPAT +options BOOTP +options BOOTP_NFSV3 +options BOOTP_WIRED_TO=cpsw0 # MMC/SD/SDIO card slot support @@ -83,7 +83,8 @@ device mmcsd # mmc/sd flash cards device sdhci # mmc/sd host controller # Boot device is 2nd slice on MMC/SD card -options ROOTDEVNAME=\"ufs:mmcsd0s2\" +#options ROOTDEVNAME=\"ufs:mmcsd0s2\" +options ROOTDEVNAME=\"nfs:192.168.0.123:/bbb\" # Console and misc device uart @@ -131,4 +132,10 @@ device usfs # Flattened Device Tree options FDT options FDT_DTB_STATIC -makeoptions FDT_DTS_FILE=beaglebone.dts +makeoptions FDT_DTS_FILE=beaglebone-black.dts + +#dtrace support +options KDTRACE_HOOKS # Kernel DTrace hooks +options DDB_CTF # all architectures - kernel ELF linker loads CTF data +makeoptions WITH_CTF=1 +makeoptions MODULES_OVERRIDE="opensolaris dtrace cyclic dtrace/dtnfsclient dtrace/dtnfscl dtrace/lockstat dtrace/profile dtrace/fbt" diff --git a/sys/arm/include/cpufunc.h b/sys/arm/include/cpufunc.h index d3e9ebe..4c96373 100644 --- a/sys/arm/include/cpufunc.h +++ b/sys/arm/include/cpufunc.h @@ -167,7 +167,7 @@ struct cpu_functions { extern struct cpu_functions cpufuncs; extern u_int cputype; -#define cpu_id() cpufuncs.cf_id() +#define cpu_ident() cpufuncs.cf_id() #define cpu_cpwait() cpufuncs.cf_cpwait() #define cpu_control(c, e) cpufuncs.cf_control(c, e) diff --git a/sys/cddl/contrib/opensolaris/uts/arm/sys/fasttrap_isa.c b/sys/cddl/contrib/opensolaris/uts/arm/sys/fasttrap_isa.c new file mode 100644 index 0000000..18e3837 --- /dev/null +++ b/sys/cddl/contrib/opensolaris/uts/arm/sys/fasttrap_isa.c @@ -0,0 +1,30 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License (the "License"). + * You may not use this file except in compliance with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + */ + +/* + * Copyright 2007 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ + + +/* + * XXX: Placeholder for ARM fasttrap code + */ diff --git a/sys/cddl/contrib/opensolaris/uts/arm/sys/fasttrap_isa.h b/sys/cddl/contrib/opensolaris/uts/arm/sys/fasttrap_isa.h new file mode 100644 index 0000000..10361cbe --- /dev/null +++ b/sys/cddl/contrib/opensolaris/uts/arm/sys/fasttrap_isa.h @@ -0,0 +1,94 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License, Version 1.0 only + * (the "License"). You may not use this file except in compliance + * with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + */ +/* + * Copyright 2005 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ + +#ifndef _FASTTRAP_ISA_H +#define _FASTTRAP_ISA_H + +#pragma ident "%Z%%M% %I% %E% SMI" + +#include + +#ifdef __cplusplus +extern "C" { +#endif + +/* + * This is our reserved trap instruction: ta 0x38 + */ +#define FASTTRAP_INSTR 0x91d02038 + +#define FASTTRAP_SUNWDTRACE_SIZE 128 + +typedef uint32_t fasttrap_instr_t; + +typedef struct fasttrap_machtp { + fasttrap_instr_t ftmt_instr; /* original instruction */ + uintptr_t ftmt_dest; /* destination of DCTI */ + uint8_t ftmt_type; /* emulation type */ + uint8_t ftmt_flags; /* emulation flags */ + uint8_t ftmt_cc; /* which cc to look at */ + uint8_t ftmt_code; /* branch condition */ +} fasttrap_machtp_t; + +#define ftt_instr ftt_mtp.ftmt_instr +#define ftt_dest ftt_mtp.ftmt_dest +#define ftt_type ftt_mtp.ftmt_type +#define ftt_flags ftt_mtp.ftmt_flags +#define ftt_cc ftt_mtp.ftmt_cc +#define ftt_code ftt_mtp.ftmt_code + +#define FASTTRAP_T_COMMON 0x00 /* common case -- no emulation */ +#define FASTTRAP_T_CCR 0x01 /* integer condition code branch */ +#define FASTTRAP_T_FCC 0x02 /* floating-point branch */ +#define FASTTRAP_T_REG 0x03 /* register predicated branch */ +#define FASTTRAP_T_ALWAYS 0x04 /* branch always */ +#define FASTTRAP_T_CALL 0x05 /* call instruction */ +#define FASTTRAP_T_JMPL 0x06 /* jmpl instruction */ +#define FASTTRAP_T_RDPC 0x07 /* rdpc instruction */ +#define FASTTRAP_T_RETURN 0x08 /* return instruction */ + +/* + * For performance rather than correctness. + */ +#define FASTTRAP_T_SAVE 0x10 /* save instruction (func entry only) */ +#define FASTTRAP_T_RESTORE 0x11 /* restore instruction */ +#define FASTTRAP_T_OR 0x12 /* mov instruction */ +#define FASTTRAP_T_SETHI 0x13 /* sethi instruction (includes nop) */ + +#define FASTTRAP_F_ANNUL 0x01 /* branch is annulled */ +#define FASTTRAP_F_RETMAYBE 0x02 /* not definitely a return site */ + +#define FASTTRAP_AFRAMES 3 +#define FASTTRAP_RETURN_AFRAMES 4 +#define FASTTRAP_ENTRY_AFRAMES 3 +#define FASTTRAP_OFFSET_AFRAMES 3 + + +#ifdef __cplusplus +} +#endif + +#endif /* _FASTTRAP_ISA_H */ diff --git a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c index f35cf73..9e4b23d 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c +++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c @@ -10933,7 +10933,7 @@ err: #else int i; -#if defined(__amd64__) || defined(__mips__) || defined(__powerpc__) +#if defined(__amd64__) || defined(__mips__) || defined(__powerpc__) || defined(__arm__) /* * FreeBSD isn't good at limiting the amount of memory we * ask to malloc, so let's place a limit here before trying diff --git a/sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h b/sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h index 295457c..671faa9 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h +++ b/sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h @@ -2390,6 +2390,13 @@ extern void dtrace_helpers_destroy(proc_t *); #define DTRACE_INVOP_MFLR_R0 5 #define DTRACE_INVOP_NOP 6 +#elif defined(__arm__) + +#define DTRACE_INVOP_PUSHM 1 +#define DTRACE_INVOP_POPM 2 +#define DTRACE_INVOP_B 3 + + #endif #ifdef __cplusplus diff --git a/sys/cddl/dev/dtrace/arm/dtrace_asm.S b/sys/cddl/dev/dtrace/arm/dtrace_asm.S new file mode 100644 index 0000000..7898bc4 --- /dev/null +++ b/sys/cddl/dev/dtrace/arm/dtrace_asm.S @@ -0,0 +1,185 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License, Version 1.0 only + * (the "License"). You may not use this file except in compliance + * with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + * + * $FreeBSD$ + */ +/* + * Copyright 2004 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ + +#define _ASM +#define _LOCORE +#define LOCORE + +#include +#include + +#include + +#include "assym.s" + +/* +void dtrace_membar_producer(void) +*/ +ENTRY(dtrace_membar_producer) + RET + +/* +void dtrace_membar_consumer(void) +*/ +ENTRY(dtrace_membar_consumer) + RET + +/* +dtrace_icookie_t dtrace_interrupt_disable(void) +*/ +ENTRY(dtrace_interrupt_disable) + mrs r0, cpsr + mov r1, r0 + orr r1, r1, #(I32_bit|F32_bit) + msr cpsr_c, r1 + RET +/* +void dtrace_interrupt_enable(dtrace_icookie_t cookie) +*/ +ENTRY(dtrace_interrupt_enable) + and r0, r0, #(I32_bit|F32_bit) + mrs r1, cpsr + bic r1, r1, #(I32_bit|F32_bit) + orr r1, r1, r0 + msr cpsr_c, r1 + RET + +/* +uint8_t +dtrace_fuword8_nocheck(void *addr) +*/ +ENTRY(dtrace_fuword8_nocheck) + ldrb r3, [r0] + mov r0, r3 + RET + +/* +uint16_t +dtrace_fuword16_nocheck(void *addr) +*/ +ENTRY(dtrace_fuword16_nocheck) + ldrh r3, [r0] + mov r0, r3 + RET + +/* +uint32_t +dtrace_fuword32_nocheck(void *addr) +*/ +ENTRY(dtrace_fuword32_nocheck) + ldr r3, [r0] + mov r0, r3 + RET + +/* +uint64_t +dtrace_fuword64_nocheck(void *addr) +*/ +ENTRY(dtrace_fuword64_nocheck) + ldm r0, {r2, r3} + + mov r0, r2 + mov r1, r3 +#if defined(__BIG_ENDIAN__) +/* big endian */ + mov r0, r3 + mov r1, r2 +#else +/* little endian */ + mov r0, r2 + mov r1, r3 + +#endif + RET + +/* +void +dtrace_copy(uintptr_t uaddr, uintptr_t kaddr, size_t size) +*/ +ENTRY(dtrace_copy) + stmfd sp!, {r4-r5} /* stack is 8 byte aligned */ + teq r2, #0x00000000 + mov r5, #0x00000000 + beq 2f + +1: ldrb r4, [r0], #0x0001 + add r5, r5, #0x00000001 + strb r4, [r1], #0x0001 + teqne r5, r2 + bne 1b + +2: ldmfd sp!, {r4-r5} /* stack is 8 byte aligned */ + RET + + +/* +void +dtrace_copystr(uintptr_t uaddr, uintptr_t kaddr, size_t size, + volatile uint16_t *flags) +XXX: Check for flags? +*/ +ENTRY(dtrace_copystr) + stmfd sp!, {r4-r5} /* stack is 8 byte aligned */ + teq r2, #0x00000000 + mov r5, #0x00000000 + beq 2f + +1: ldrb r4, [r0], #0x0001 + add r5, r5, #0x00000001 + teq r4, #0x00000000 + strb r4, [r1], #0x0001 + teqne r5, r2 + bne 1b + +2: ldmfd sp!, {r4-r5} /* stack is 8 byte aligned */ + RET + +#if 0 +/* +void +vpanic(const char *format, va_list alist) +*/ +ENTRY(vpanic) /* Initial stack layout: */ +vpanic_common: + RET +#endif +/* +void +dtrace_vpanic(const char *format, va_list alist) +*/ +ENTRY(dtrace_vpanic) /* Initial stack layout: */ + b vpanic + RET + +/* +uintptr_t +dtrace_caller(int aframes) +*/ +ENTRY(dtrace_caller) + mov r0, #-1 + RET diff --git a/sys/cddl/dev/dtrace/arm/dtrace_isa.c b/sys/cddl/dev/dtrace/arm/dtrace_isa.c new file mode 100644 index 0000000..e885a60 --- /dev/null +++ b/sys/cddl/dev/dtrace/arm/dtrace_isa.c @@ -0,0 +1,373 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License, Version 1.0 only + * (the "License"). You may not use this file except in compliance + * with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + * + * $FreeBSD$ + */ +/* + * Copyright 2005 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ +#include + +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "regset.h" + +/* + * Wee need some reasonable default to prevent backtrace code + * from wandering too far + */ +#define MAX_FUNCTION_SIZE 0x10000 +#define MAX_PROLOGUE_SIZE 0x100 + + +uint8_t dtrace_fuword8_nocheck(void *); +uint16_t dtrace_fuword16_nocheck(void *); +uint32_t dtrace_fuword32_nocheck(void *); +uint64_t dtrace_fuword64_nocheck(void *); + +void +dtrace_getpcstack(pc_t *pcstack, int pcstack_limit, int aframes, + uint32_t *intrpc) +{ + u_int32_t *frame, *lastframe; + int scp_offset; + int depth = 0; + pc_t caller = (pc_t) solaris_cpu[curcpu].cpu_dtrace_caller; + + if (intrpc != 0) + pcstack[depth++] = (pc_t) intrpc; + + aframes++; + + frame = (u_int32_t *)__builtin_frame_address(0);; + lastframe = NULL; + scp_offset = -(get_pc_str_offset() >> 2); + + while ((frame != NULL) && (depth < pcstack_limit)) { + db_addr_t scp; +#if 0 + u_int32_t savecode; + int r; + u_int32_t *rp; +#endif + + /* + * In theory, the SCP isn't guaranteed to be in the function + * that generated the stack frame. We hope for the best. + */ + scp = frame[FR_SCP]; + printf("--> %08x\n", (uint32_t)scp); + + if (aframes > 0) { + aframes--; + if ((aframes == 0) && (caller != 0)) { + pcstack[depth++] = caller; + } + } + else { + printf("++ --> %08x\n", (uint32_t)scp); + pcstack[depth++] = scp; + } + +#if 0 + savecode = ((u_int32_t *)scp)[scp_offset]; + if ((savecode & 0x0e100000) == 0x08000000) { + /* Looks like an STM */ + rp = frame - 4; + for (r = 10; r >= 0; r--) { + if (savecode & (1 << r)) { + /* register r == *rp-- */ + } + } + } +#endif + + /* + * Switch to next frame up + */ + if (frame[FR_RFP] == 0) + break; /* Top of stack */ + + lastframe = frame; + frame = (u_int32_t *)(frame[FR_RFP]); + + if (INKERNEL((int)frame)) { + /* staying in kernel */ + if (frame <= lastframe) { + /* bad frame pointer */ + break; + } + } + else + break; + } + + for (; depth < pcstack_limit; depth++) { + pcstack[depth] = 0; + } +} + +void +dtrace_getupcstack(uint64_t *pcstack, int pcstack_limit) +{ + printf("IMPLEMENT ME: %s\n", __func__); +} + +int +dtrace_getustackdepth(void) +{ + printf("IMPLEMENT ME: %s\n", __func__); + return (0); +} + +void +dtrace_getufpstack(uint64_t *pcstack, uint64_t *fpstack, int pcstack_limit) +{ + printf("IMPLEMENT ME: %s\n", __func__); +} + +/*ARGSUSED*/ +uint64_t +dtrace_getarg(int arg, int aframes) +{ + struct arm_frame *fp = (struct arm_frame *)dtrace_getfp(); + + return (0); +} + +int +dtrace_getstackdepth(int aframes) +{ + u_int32_t *frame, *lastframe; + int scp_offset; + int depth = 1; + + frame = (u_int32_t *)__builtin_frame_address(0);; + lastframe = NULL; + scp_offset = -(get_pc_str_offset() >> 2); + + while (frame != NULL) { + db_addr_t scp; +#if 0 + u_int32_t savecode; + int r; + u_int32_t *rp; +#endif + + /* + * In theory, the SCP isn't guaranteed to be in the function + * that generated the stack frame. We hope for the best. + */ + scp = frame[FR_SCP]; + + depth++; + + /* + * Switch to next frame up + */ + if (frame[FR_RFP] == 0) + break; /* Top of stack */ + + lastframe = frame; + frame = (u_int32_t *)(frame[FR_RFP]); + + if (INKERNEL((int)frame)) { + /* staying in kernel */ + if (frame <= lastframe) { + /* bad frame pointer */ + break; + } + } + else + break; + } + + if (depth < aframes) + return 0; + else + return depth - aframes; + +} + +ulong_t +dtrace_getreg(struct trapframe *rp, uint_t reg) +{ + printf("IMPLEMENT ME: %s\n", __func__); + + return (0); +} + +static int +dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) +{ + + if (uaddr + size > VM_MAXUSER_ADDRESS || uaddr + size < uaddr) { + DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); + cpu_core[curcpu].cpuc_dtrace_illval = uaddr; + return (0); + } + + return (1); +} + +void +dtrace_copyin(uintptr_t uaddr, uintptr_t kaddr, size_t size, + volatile uint16_t *flags) +{ + if (dtrace_copycheck(uaddr, kaddr, size)) + dtrace_copy(uaddr, kaddr, size); +} + +void +dtrace_copyout(uintptr_t kaddr, uintptr_t uaddr, size_t size, + volatile uint16_t *flags) +{ + if (dtrace_copycheck(uaddr, kaddr, size)) + dtrace_copy(kaddr, uaddr, size); +} + +void +dtrace_copyinstr(uintptr_t uaddr, uintptr_t kaddr, size_t size, + volatile uint16_t *flags) +{ + if (dtrace_copycheck(uaddr, kaddr, size)) + dtrace_copystr(uaddr, kaddr, size, flags); +} + +void +dtrace_copyoutstr(uintptr_t kaddr, uintptr_t uaddr, size_t size, + volatile uint16_t *flags) +{ + if (dtrace_copycheck(uaddr, kaddr, size)) + dtrace_copystr(kaddr, uaddr, size, flags); +} + +uint8_t +dtrace_fuword8(void *uaddr) +{ + if ((uintptr_t)uaddr > VM_MAXUSER_ADDRESS) { + DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); + cpu_core[curcpu].cpuc_dtrace_illval = (uintptr_t)uaddr; + return (0); + } + return (dtrace_fuword8_nocheck(uaddr)); +} + +uint16_t +dtrace_fuword16(void *uaddr) +{ + if ((uintptr_t)uaddr > VM_MAXUSER_ADDRESS) { + DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); + cpu_core[curcpu].cpuc_dtrace_illval = (uintptr_t)uaddr; + return (0); + } + return (dtrace_fuword16_nocheck(uaddr)); +} + +uint32_t +dtrace_fuword32(void *uaddr) +{ + if ((uintptr_t)uaddr > VM_MAXUSER_ADDRESS) { + DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); + cpu_core[curcpu].cpuc_dtrace_illval = (uintptr_t)uaddr; + return (0); + } + return (dtrace_fuword32_nocheck(uaddr)); +} + +uint64_t +dtrace_fuword64(void *uaddr) +{ + if ((uintptr_t)uaddr > VM_MAXUSER_ADDRESS) { + DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); + cpu_core[curcpu].cpuc_dtrace_illval = (uintptr_t)uaddr; + return (0); + } + return (dtrace_fuword64_nocheck(uaddr)); +} + +#ifndef I32_bit +#define I32_bit (1 << 7) /* IRQ disable */ +#endif +#ifndef F32_bit +#define F32_bit (1 << 6) /* FIQ disable */ +#endif + +#define __with_interrupts_disabled(expr) \ + do { \ + u_int cpsr_save, tmp; \ + \ + __asm __volatile( \ + "mrs %0, cpsr;" \ + "orr %1, %0, %2;" \ + "msr cpsr_all, %1;" \ + : "=r" (cpsr_save), "=r" (tmp) \ + : "I" (I32_bit | F32_bit) \ + : "cc" ); \ + (expr); \ + __asm __volatile( \ + "msr cpsr_all, %0" \ + : /* no output */ \ + : "r" (cpsr_save) \ + : "cc" ); \ + } while(0) + +uint32_t dtrace_cas32(uint32_t *target, uint32_t cmp, uint32_t new) +{ + uint32_t ret; + __with_interrupts_disabled( + { + ret = *target; + if (*target == cmp) { + *target = new; + } + }); + + return ret; +} + +void * dtrace_casptr(volatile void *target, volatile void *cmp, volatile void *new) +{ + return (void*)dtrace_cas32((uint32_t*)target, (uint32_t)cmp, (uint32_t)new); +} + diff --git a/sys/cddl/dev/dtrace/arm/dtrace_subr.c b/sys/cddl/dev/dtrace/arm/dtrace_subr.c new file mode 100644 index 0000000..c24dd9b --- /dev/null +++ b/sys/cddl/dev/dtrace/arm/dtrace_subr.c @@ -0,0 +1,264 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License, Version 1.0 only + * (the "License"). You may not use this file except in compliance + * with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + * + * $FreeBSD$ + * + */ +/* + * Copyright 2005 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DELAYBRANCH(x) ((int)(x) < 0) + +extern uintptr_t dtrace_in_probe_addr; +extern int dtrace_in_probe; +extern dtrace_id_t dtrace_probeid_error; +extern int (*dtrace_invop_jump_addr)(struct trapframe *); + +int dtrace_invop(uintptr_t, uintptr_t *, uintptr_t); +void dtrace_invop_init(void); +void dtrace_invop_uninit(void); + +typedef struct dtrace_invop_hdlr { + int (*dtih_func)(uintptr_t, uintptr_t *, uintptr_t); + struct dtrace_invop_hdlr *dtih_next; +} dtrace_invop_hdlr_t; + +dtrace_invop_hdlr_t *dtrace_invop_hdlr; + +int +dtrace_invop(uintptr_t addr, uintptr_t *stack, uintptr_t eax) +{ + dtrace_invop_hdlr_t *hdlr; + int rval; + + for (hdlr = dtrace_invop_hdlr; hdlr != NULL; hdlr = hdlr->dtih_next) + if ((rval = hdlr->dtih_func(addr, stack, eax)) != 0) + return (rval); + + return (0); +} + + +void +dtrace_invop_add(int (*func)(uintptr_t, uintptr_t *, uintptr_t)) +{ + dtrace_invop_hdlr_t *hdlr; + + hdlr = kmem_alloc(sizeof (dtrace_invop_hdlr_t), KM_SLEEP); + hdlr->dtih_func = func; + hdlr->dtih_next = dtrace_invop_hdlr; + dtrace_invop_hdlr = hdlr; +} + +void +dtrace_invop_remove(int (*func)(uintptr_t, uintptr_t *, uintptr_t)) +{ + dtrace_invop_hdlr_t *hdlr = dtrace_invop_hdlr, *prev = NULL; + + for (;;) { + if (hdlr == NULL) + panic("attempt to remove non-existent invop handler"); + + if (hdlr->dtih_func == func) + break; + + prev = hdlr; + hdlr = hdlr->dtih_next; + } + + if (prev == NULL) { + ASSERT(dtrace_invop_hdlr == hdlr); + dtrace_invop_hdlr = hdlr->dtih_next; + } else { + ASSERT(dtrace_invop_hdlr != hdlr); + prev->dtih_next = hdlr->dtih_next; + } + + kmem_free(hdlr, 0); +} + + +/*ARGSUSED*/ +void +dtrace_toxic_ranges(void (*func)(uintptr_t base, uintptr_t limit)) +{ + printf("IMPLEMENT ME: dtrace_toxic_ranges\n"); +} + +void +dtrace_xcall(processorid_t cpu, dtrace_xcall_t func, void *arg) +{ + cpuset_t cpus; + + if (cpu == DTRACE_CPUALL) + cpus = all_cpus; + else + CPU_SETOF(cpu, &cpus); + + smp_rendezvous_cpus(cpus, smp_no_rendevous_barrier, func, + smp_no_rendevous_barrier, arg); +} + +static void +dtrace_sync_func(void) +{ +} + +void +dtrace_sync(void) +{ + dtrace_xcall(DTRACE_CPUALL, (dtrace_xcall_t)dtrace_sync_func, NULL); +} + +/* + * DTrace needs a high resolution time function which can + * be called from a probe context and guaranteed not to have + * instrumented with probes itself. + * + * Returns nanoseconds since boot. + */ +uint64_t +dtrace_gethrtime() +{ + struct timespec curtime; + + nanouptime(&curtime); + + return (curtime.tv_sec * 1000000000UL + curtime.tv_nsec); + +} + +uint64_t +dtrace_gethrestime(void) +{ + struct timespec curtime; + + getnanotime(&curtime); + + return (curtime.tv_sec * 1000000000UL + curtime.tv_nsec); +} + +/* Function to handle DTrace traps during probes. See amd64/amd64/trap.c */ +int +dtrace_trap(struct trapframe *frame, u_int type) +{ + /* + * A trap can occur while DTrace executes a probe. Before + * executing the probe, DTrace blocks re-scheduling and sets + * a flag in it's per-cpu flags to indicate that it doesn't + * want to fault. On returning from the probe, the no-fault + * flag is cleared and finally re-scheduling is enabled. + * + * Check if DTrace has enabled 'no-fault' mode: + * + */ + if ((cpu_core[curcpu].cpuc_dtrace_flags & CPU_DTRACE_NOFAULT) != 0) { + /* + * There are only a couple of trap types that are expected. + * All the rest will be handled in the usual way. + */ + switch (type) { + /* Page fault. */ + case FAULT_WRTBUF_0: + case FAULT_WRTBUF_1: + case FAULT_ALIGN_0: + case FAULT_ALIGN_1: + /* Flag a bad address. */ + cpu_core[curcpu].cpuc_dtrace_flags |= CPU_DTRACE_BADADDR; + cpu_core[curcpu].cpuc_dtrace_illval = 0; + + /* + * Offset the instruction pointer to the instruction + * following the one causing the fault. + */ + frame->tf_pc += sizeof(int); + return (1); + default: + /* Handle all other traps in the usual way. */ + break; + } + } + + /* Handle the trap in the usual way. */ + return (0); +} + +void +dtrace_probe_error(dtrace_state_t *state, dtrace_epid_t epid, int which, + int fault, int fltoffs, uintptr_t illval) +{ + + dtrace_probe(dtrace_probeid_error, (uint64_t)(uintptr_t)state, + (uintptr_t)epid, + (uintptr_t)which, (uintptr_t)fault, (uintptr_t)fltoffs); +} + +static int +dtrace_invop_start(struct trapframe *frame) +{ + printf("IMPLEMENT ME: %s\n", __func__); + switch (dtrace_invop(frame->tf_pc, (uintptr_t *)frame, frame->tf_pc)) { + case DTRACE_INVOP_PUSHM: + // TODO: + break; + case DTRACE_INVOP_POPM: + // TODO: + break; + case DTRACE_INVOP_B: + // TODO + break; + default: + return (-1); + break; + } + + return (0); +} + +void dtrace_invop_init(void) +{ + dtrace_invop_jump_addr = dtrace_invop_start; +} + +void dtrace_invop_uninit(void) +{ + dtrace_invop_jump_addr = 0; +} diff --git a/sys/cddl/dev/dtrace/arm/regset.h b/sys/cddl/dev/dtrace/arm/regset.h new file mode 100644 index 0000000..1ff6463 --- /dev/null +++ b/sys/cddl/dev/dtrace/arm/regset.h @@ -0,0 +1,56 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License, Version 1.0 only + * (the "License"). You may not use this file except in compliance + * with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + * + * $FreeBSD$ + */ +/* + * Copyright 2004 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ + +/* Copyright (c) 1990, 1991 UNIX System Laboratories, Inc. */ + +/* Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T */ +/* All Rights Reserved */ + +#ifndef _REGSET_H +#define _REGSET_H + +/* + * #pragma ident "@(#)regset.h 1.11 05/06/08 SMI" + */ + +#ifdef __cplusplus +extern "C" { +#endif + +#define REG_PC R14 +#define REG_FP R13 +#define REG_SP R12 +#define REG_PS R0 +#define REG_R0 R0 +#define REG_R1 R1 + +#ifdef __cplusplus +} +#endif + +#endif /* _REGSET_H */ diff --git a/sys/cddl/dev/fbt/fbt_arm.c b/sys/cddl/dev/fbt/fbt_arm.c new file mode 100644 index 0000000..2daefa8 --- /dev/null +++ b/sys/cddl/dev/fbt/fbt_arm.c @@ -0,0 +1,1303 @@ +/* + * CDDL HEADER START + * + * The contents of this file are subject to the terms of the + * Common Development and Distribution License (the "License"). + * You may not use this file except in compliance with the License. + * + * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE + * or http://www.opensolaris.org/os/licensing. + * See the License for the specific language governing permissions + * and limitations under the License. + * + * When distributing Covered Code, include this CDDL HEADER in each + * file and include the License file at usr/src/OPENSOLARIS.LICENSE. + * If applicable, add the following below this CDDL HEADER, with the + * fields enclosed by brackets "[]" replaced with your own identifying + * information: Portions Copyright [yyyy] [name of copyright owner] + * + * CDDL HEADER END + * + * Portions Copyright 2006-2008 John Birrell jb@freebsd.org + * Portions Copyright 2013 Justin Hibbits jhibbits@freebsd.org + * Portions Copyright 2013 Howard Su howardsu@freebsd.org + * + * $FreeBSD$ + * + */ + +/* + * Copyright 2006 Sun Microsystems, Inc. All rights reserved. + * Use is subject to license terms. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +static MALLOC_DEFINE(M_FBT, "fbt", "Function Boundary Tracing"); + +#define FBT_PATCHVAL 0xe06a0cfe // illegal instruction + +#define FBT_PUSHM 0xe92d0000 +#define FBT_POPM 0xe8bd0000 +#define FBT_JUMP 0xea000000 + +static d_open_t fbt_open; +static int fbt_unload(void); +static void fbt_getargdesc(void *, dtrace_id_t, void *, dtrace_argdesc_t *); +static void fbt_provide_module(void *, modctl_t *); +static void fbt_destroy(void *, dtrace_id_t, void *); +static void fbt_enable(void *, dtrace_id_t, void *); +static void fbt_disable(void *, dtrace_id_t, void *); +static void fbt_load(void *); +static void fbt_suspend(void *, dtrace_id_t, void *); +static void fbt_resume(void *, dtrace_id_t, void *); + +#define FBT_ENTRY "entry" +#define FBT_RETURN "return" +#define FBT_ADDR2NDX(addr) ((((uintptr_t)(addr)) >> 4) & fbt_probetab_mask) +#define FBT_PROBETAB_SIZE 0x8000 /* 32k entries -- 128K total */ + +static struct cdevsw fbt_cdevsw = { + .d_version = D_VERSION, + .d_open = fbt_open, + .d_name = "fbt", +}; + +static dtrace_pattr_t fbt_attr = { +{ DTRACE_STABILITY_EVOLVING, DTRACE_STABILITY_EVOLVING, DTRACE_CLASS_COMMON }, +{ DTRACE_STABILITY_PRIVATE, DTRACE_STABILITY_PRIVATE, DTRACE_CLASS_UNKNOWN }, +{ DTRACE_STABILITY_PRIVATE, DTRACE_STABILITY_PRIVATE, DTRACE_CLASS_ISA }, +{ DTRACE_STABILITY_EVOLVING, DTRACE_STABILITY_EVOLVING, DTRACE_CLASS_COMMON }, +{ DTRACE_STABILITY_PRIVATE, DTRACE_STABILITY_PRIVATE, DTRACE_CLASS_ISA }, +}; + +static dtrace_pops_t fbt_pops = { + NULL, + fbt_provide_module, + fbt_enable, + fbt_disable, + fbt_suspend, + fbt_resume, + fbt_getargdesc, + NULL, + NULL, + fbt_destroy +}; + +typedef struct fbt_probe { + struct fbt_probe *fbtp_hashnext; + uint32_t *fbtp_patchpoint; + int8_t fbtp_rval; + uint32_t fbtp_patchval; + uint32_t fbtp_savedval; + uintptr_t fbtp_roffset; + dtrace_id_t fbtp_id; + const char *fbtp_name; + modctl_t *fbtp_ctl; + int fbtp_loadcnt; + int fbtp_primary; + int fbtp_invop_cnt; + int fbtp_symindx; + struct fbt_probe *fbtp_next; +} fbt_probe_t; + +static struct cdev *fbt_cdev; +static dtrace_provider_id_t fbt_id; +static fbt_probe_t **fbt_probetab; +static int fbt_probetab_size; +static int fbt_probetab_mask; +static int fbt_verbose = 0; + +static int +fbt_invop(uintptr_t addr, uintptr_t *stack, uintptr_t rval) +{ + struct trapframe *frame = (struct trapframe *)stack; + solaris_cpu_t *cpu = &solaris_cpu[curcpu]; + fbt_probe_t *fbt = fbt_probetab[FBT_ADDR2NDX(addr)]; + + for (; fbt != NULL; fbt = fbt->fbtp_hashnext) { + if ((uintptr_t)fbt->fbtp_patchpoint == addr) { + fbt->fbtp_invop_cnt++; + cpu->cpu_dtrace_caller = addr; + + dtrace_probe(fbt->fbtp_id, frame->tf_r0, + frame->tf_r1, frame->tf_r2, + frame->tf_r3, 0); // TODO: Need 5th parameter from stack + + cpu->cpu_dtrace_caller = 0; + + return (fbt->fbtp_rval); + } + } + + return (0); +} + +static int +fbt_provide_module_function(linker_file_t lf, int symindx, + linker_symval_t *symval, void *opaque) +{ + char *modname = opaque; + const char *name = symval->name; + fbt_probe_t *fbt, *retfbt; + int popm; + u_int32_t *instr, *limit; + + if (strncmp(name, "dtrace_", 7) == 0 && + strncmp(name, "dtrace_safe_", 12) != 0) { + /* + * Anything beginning with "dtrace_" may be called + * from probe context unless it explicitly indicates + * that it won't be called from probe context by + * using the prefix "dtrace_safe_". + */ + return (0); + } + + if (name[0] == '_' && name[1] == '_') + return (0); + + instr = (u_int32_t *) symval->value; + limit = (u_int32_t *)(symval->value + symval->size); + + for (; instr < limit; instr++) + if ((*instr & 0xffff0000) == FBT_PUSHM && (*instr & 0x4000) != 0) + break; + + if (instr >= limit) + return (0); + + fbt = malloc(sizeof (fbt_probe_t), M_FBT, M_WAITOK | M_ZERO); + fbt->fbtp_name = name; + fbt->fbtp_id = dtrace_probe_create(fbt_id, modname, + name, FBT_ENTRY, 3, fbt); + fbt->fbtp_patchpoint = instr; + fbt->fbtp_ctl = lf; + fbt->fbtp_loadcnt = lf->loadcnt; + fbt->fbtp_savedval = *instr; + fbt->fbtp_patchval = FBT_PATCHVAL; + fbt->fbtp_rval = DTRACE_INVOP_PUSHM; + fbt->fbtp_symindx = symindx; + + fbt->fbtp_hashnext = fbt_probetab[FBT_ADDR2NDX(instr)]; + fbt_probetab[FBT_ADDR2NDX(instr)] = fbt; + + lf->fbt_nentries++; + + popm = FBT_POPM | ((*instr) & 0x3FFF) | 0x8000; + + + retfbt = NULL; +again: + for(; instr < limit; instr++) + { + if (*instr == popm) + break; + else if ((*instr & 0xff000000) == FBT_JUMP) + { + int offset; + u_int32_t *target, *start; + offset = (*instr & 0xffffff); + offset <<= 8; + offset /= 64; + target = instr + (2 + offset); + start = (u_int32_t *) symval->value; + if (target >= limit || target < start) + break; + instr++; //skip delay slot + } + } + + if (instr >= limit) + return (0); + + /* + * We have a winner! + */ + fbt = malloc(sizeof (fbt_probe_t), M_FBT, M_WAITOK | M_ZERO); + fbt->fbtp_name = name; + if (retfbt == NULL) { + fbt->fbtp_id = dtrace_probe_create(fbt_id, modname, + name, FBT_RETURN, 5, fbt); + } else { + retfbt->fbtp_next = fbt; + fbt->fbtp_id = retfbt->fbtp_id; + } + retfbt = fbt; + + fbt->fbtp_patchpoint = instr; + fbt->fbtp_ctl = lf; + fbt->fbtp_loadcnt = lf->loadcnt; + fbt->fbtp_symindx = symindx; + if ((*instr & 0xff000000) == FBT_JUMP) + fbt->fbtp_rval = DTRACE_INVOP_B; + else + fbt->fbtp_rval = DTRACE_INVOP_POPM; + fbt->fbtp_savedval = *instr; + fbt->fbtp_patchval = FBT_PATCHVAL; + fbt->fbtp_hashnext = fbt_probetab[FBT_ADDR2NDX(instr)]; + fbt_probetab[FBT_ADDR2NDX(instr)] = fbt; + + lf->fbt_nentries++; + + instr++; + goto again; +} + +static void +fbt_provide_module(void *arg, modctl_t *lf) +{ + char modname[MAXPATHLEN]; + int i; + size_t len; + + strlcpy(modname, lf->filename, sizeof(modname)); + len = strlen(modname); + if (len > 3 && strcmp(modname + len - 3, ".ko") == 0) + modname[len - 3] = '\0'; + + /* + * Employees of dtrace and their families are ineligible. Void + * where prohibited. + */ + if (strcmp(modname, "dtrace") == 0) + return; + + /* + * The cyclic timer subsystem can be built as a module and DTrace + * depends on that, so it is ineligible too. + */ + if (strcmp(modname, "cyclic") == 0) + return; + + /* + * To register with DTrace, a module must list 'dtrace' as a + * dependency in order for the kernel linker to resolve + * symbols like dtrace_register(). All modules with such a + * dependency are ineligible for FBT tracing. + */ + for (i = 0; i < lf->ndeps; i++) + if (strncmp(lf->deps[i]->filename, "dtrace", 6) == 0) + return; + + if (lf->fbt_nentries) { + /* + * This module has some FBT entries allocated; we're afraid + * to screw with it. + */ + return; + } + + /* + * List the functions in the module and the symbol values. + */ + (void) linker_file_function_listall(lf, fbt_provide_module_function, modname); +} + +static void +fbt_destroy(void *arg, dtrace_id_t id, void *parg) +{ + fbt_probe_t *fbt = parg, *next, *hash, *last; + modctl_t *ctl; + int ndx; + + do { + ctl = fbt->fbtp_ctl; + + ctl->fbt_nentries--; + + /* + * Now we need to remove this probe from the fbt_probetab. + */ + ndx = FBT_ADDR2NDX(fbt->fbtp_patchpoint); + last = NULL; + hash = fbt_probetab[ndx]; + + while (hash != fbt) { + ASSERT(hash != NULL); + last = hash; + hash = hash->fbtp_hashnext; + } + + if (last != NULL) { + last->fbtp_hashnext = fbt->fbtp_hashnext; + } else { + fbt_probetab[ndx] = fbt->fbtp_hashnext; + } + + next = fbt->fbtp_next; + free(fbt, M_FBT); + + fbt = next; + } while (fbt != NULL); +} + +static void +fbt_enable(void *arg, dtrace_id_t id, void *parg) +{ + fbt_probe_t *fbt = parg; + modctl_t *ctl = fbt->fbtp_ctl; + + ctl->nenabled++; + + /* + * Now check that our modctl has the expected load count. If it + * doesn't, this module must have been unloaded and reloaded -- and + * we're not going to touch it. + */ + if (ctl->loadcnt != fbt->fbtp_loadcnt) { + if (fbt_verbose) { + printf("fbt is failing for probe %s " + "(module %s reloaded)", + fbt->fbtp_name, ctl->filename); + } + + return; + } + + for (; fbt != NULL; fbt = fbt->fbtp_next) { + *fbt->fbtp_patchpoint = fbt->fbtp_patchval; + cpu_icache_sync_range((vm_offset_t)fbt->fbtp_patchpoint, 4); + } +} + +static void +fbt_disable(void *arg, dtrace_id_t id, void *parg) +{ + fbt_probe_t *fbt = parg; + modctl_t *ctl = fbt->fbtp_ctl; + + ASSERT(ctl->nenabled > 0); + ctl->nenabled--; + + if ((ctl->loadcnt != fbt->fbtp_loadcnt)) + return; + + for (; fbt != NULL; fbt = fbt->fbtp_next) { + *fbt->fbtp_patchpoint = fbt->fbtp_savedval; + cpu_icache_sync_range((vm_offset_t)fbt->fbtp_patchpoint, 4); + } +} + +static void +fbt_suspend(void *arg, dtrace_id_t id, void *parg) +{ + fbt_probe_t *fbt = parg; + modctl_t *ctl = fbt->fbtp_ctl; + + ASSERT(ctl->nenabled > 0); + + if ((ctl->loadcnt != fbt->fbtp_loadcnt)) + return; + + for (; fbt != NULL; fbt = fbt->fbtp_next) { + *fbt->fbtp_patchpoint = fbt->fbtp_savedval; + cpu_icache_sync_range((vm_offset_t)fbt->fbtp_patchpoint, 4); + } +} + +static void +fbt_resume(void *arg, dtrace_id_t id, void *parg) +{ + fbt_probe_t *fbt = parg; + modctl_t *ctl = fbt->fbtp_ctl; + + ASSERT(ctl->nenabled > 0); + + if ((ctl->loadcnt != fbt->fbtp_loadcnt)) + return; + + for (; fbt != NULL; fbt = fbt->fbtp_next) { + *fbt->fbtp_patchpoint = fbt->fbtp_patchval; + cpu_icache_sync_range((vm_offset_t)fbt->fbtp_patchpoint, 4); + } +} + +static int +fbt_ctfoff_init(modctl_t *lf, linker_ctf_t *lc) +{ + const Elf_Sym *symp = lc->symtab;; + const ctf_header_t *hp = (const ctf_header_t *) lc->ctftab; + const uint8_t *ctfdata = lc->ctftab + sizeof(ctf_header_t); + int i; + uint32_t *ctfoff; + uint32_t objtoff = hp->cth_objtoff; + uint32_t funcoff = hp->cth_funcoff; + ushort_t info; + ushort_t vlen; + + /* Sanity check. */ + if (hp->cth_magic != CTF_MAGIC) { + printf("Bad magic value in CTF data of '%s'\n",lf->pathname); + return (EINVAL); + } + + if (lc->symtab == NULL) { + printf("No symbol table in '%s'\n",lf->pathname); + return (EINVAL); + } + + if ((ctfoff = malloc(sizeof(uint32_t) * lc->nsym, M_LINKER, M_WAITOK)) == NULL) + return (ENOMEM); + + *lc->ctfoffp = ctfoff; + + for (i = 0; i < lc->nsym; i++, ctfoff++, symp++) { + if (symp->st_name == 0 || symp->st_shndx == SHN_UNDEF) { + *ctfoff = 0xffffffff; + continue; + } + + switch (ELF_ST_TYPE(symp->st_info)) { + case STT_OBJECT: + if (objtoff >= hp->cth_funcoff || + (symp->st_shndx == SHN_ABS && symp->st_value == 0)) { + *ctfoff = 0xffffffff; + break; + } + + *ctfoff = objtoff; + objtoff += sizeof (ushort_t); + break; + + case STT_FUNC: + if (funcoff >= hp->cth_typeoff) { + *ctfoff = 0xffffffff; + break; + } + + *ctfoff = funcoff; + + info = *((const ushort_t *)(ctfdata + funcoff)); + vlen = CTF_INFO_VLEN(info); + + /* + * If we encounter a zero pad at the end, just skip it. + * Otherwise skip over the function and its return type + * (+2) and the argument list (vlen). + */ + if (CTF_INFO_KIND(info) == CTF_K_UNKNOWN && vlen == 0) + funcoff += sizeof (ushort_t); /* skip pad */ + else + funcoff += sizeof (ushort_t) * (vlen + 2); + break; + + default: + *ctfoff = 0xffffffff; + break; + } + } + + return (0); +} + +static ssize_t +fbt_get_ctt_size(uint8_t version, const ctf_type_t *tp, ssize_t *sizep, + ssize_t *incrementp) +{ + ssize_t size, increment; + + if (version > CTF_VERSION_1 && + tp->ctt_size == CTF_LSIZE_SENT) { + size = CTF_TYPE_LSIZE(tp); + increment = sizeof (ctf_type_t); + } else { + size = tp->ctt_size; + increment = sizeof (ctf_stype_t); + } + + if (sizep) + *sizep = size; + if (incrementp) + *incrementp = increment; + + return (size); +} + +static int +fbt_typoff_init(linker_ctf_t *lc) +{ + const ctf_header_t *hp = (const ctf_header_t *) lc->ctftab; + const ctf_type_t *tbuf; + const ctf_type_t *tend; + const ctf_type_t *tp; + const uint8_t *ctfdata = lc->ctftab + sizeof(ctf_header_t); + int ctf_typemax = 0; + uint32_t *xp; + ulong_t pop[CTF_K_MAX + 1] = { 0 }; + + + /* Sanity check. */ + if (hp->cth_magic != CTF_MAGIC) + return (EINVAL); + + tbuf = (const ctf_type_t *) (ctfdata + hp->cth_typeoff); + tend = (const ctf_type_t *) (ctfdata + hp->cth_stroff); + + int child = hp->cth_parname != 0; + + /* + * We make two passes through the entire type section. In this first + * pass, we count the number of each type and the total number of types. + */ + for (tp = tbuf; tp < tend; ctf_typemax++) { + ushort_t kind = CTF_INFO_KIND(tp->ctt_info); + ulong_t vlen = CTF_INFO_VLEN(tp->ctt_info); + ssize_t size, increment; + + size_t vbytes; + uint_t n; + + (void) fbt_get_ctt_size(hp->cth_version, tp, &size, &increment); + + switch (kind) { + case CTF_K_INTEGER: + case CTF_K_FLOAT: + vbytes = sizeof (uint_t); + break; + case CTF_K_ARRAY: + vbytes = sizeof (ctf_array_t); + break; + case CTF_K_FUNCTION: + vbytes = sizeof (ushort_t) * (vlen + (vlen & 1)); + break; + case CTF_K_STRUCT: + case CTF_K_UNION: + if (size < CTF_LSTRUCT_THRESH) { + ctf_member_t *mp = (ctf_member_t *) + ((uintptr_t)tp + increment); + + vbytes = sizeof (ctf_member_t) * vlen; + for (n = vlen; n != 0; n--, mp++) + child |= CTF_TYPE_ISCHILD(mp->ctm_type); + } else { + ctf_lmember_t *lmp = (ctf_lmember_t *) + ((uintptr_t)tp + increment); + + vbytes = sizeof (ctf_lmember_t) * vlen; + for (n = vlen; n != 0; n--, lmp++) + child |= + CTF_TYPE_ISCHILD(lmp->ctlm_type); + } + break; + case CTF_K_ENUM: + vbytes = sizeof (ctf_enum_t) * vlen; + break; + case CTF_K_FORWARD: + /* + * For forward declarations, ctt_type is the CTF_K_* + * kind for the tag, so bump that population count too. + * If ctt_type is unknown, treat the tag as a struct. + */ + if (tp->ctt_type == CTF_K_UNKNOWN || + tp->ctt_type >= CTF_K_MAX) + pop[CTF_K_STRUCT]++; + else + pop[tp->ctt_type]++; + /*FALLTHRU*/ + case CTF_K_UNKNOWN: + vbytes = 0; + break; + case CTF_K_POINTER: + case CTF_K_TYPEDEF: + case CTF_K_VOLATILE: + case CTF_K_CONST: + case CTF_K_RESTRICT: + child |= CTF_TYPE_ISCHILD(tp->ctt_type); + vbytes = 0; + break; + default: + printf("%s(%d): detected invalid CTF kind -- %u\n", __func__, __LINE__, kind); + return (EIO); + } + tp = (ctf_type_t *)((uintptr_t)tp + increment + vbytes); + pop[kind]++; + } + + /* account for a sentinel value below */ + ctf_typemax++; + *lc->typlenp = ctf_typemax; + + if ((xp = malloc(sizeof(uint32_t) * ctf_typemax, M_LINKER, M_ZERO | M_WAITOK)) == NULL) + return (ENOMEM); + + *lc->typoffp = xp; + + /* type id 0 is used as a sentinel value */ + *xp++ = 0; + + /* + * In the second pass, fill in the type offset. + */ + for (tp = tbuf; tp < tend; xp++) { + ushort_t kind = CTF_INFO_KIND(tp->ctt_info); + ulong_t vlen = CTF_INFO_VLEN(tp->ctt_info); + ssize_t size, increment; + + size_t vbytes; + uint_t n; + + (void) fbt_get_ctt_size(hp->cth_version, tp, &size, &increment); + + switch (kind) { + case CTF_K_INTEGER: + case CTF_K_FLOAT: + vbytes = sizeof (uint_t); + break; + case CTF_K_ARRAY: + vbytes = sizeof (ctf_array_t); + break; + case CTF_K_FUNCTION: + vbytes = sizeof (ushort_t) * (vlen + (vlen & 1)); + break; + case CTF_K_STRUCT: + case CTF_K_UNION: + if (size < CTF_LSTRUCT_THRESH) { + ctf_member_t *mp = (ctf_member_t *) + ((uintptr_t)tp + increment); + + vbytes = sizeof (ctf_member_t) * vlen; + for (n = vlen; n != 0; n--, mp++) + child |= CTF_TYPE_ISCHILD(mp->ctm_type); + } else { + ctf_lmember_t *lmp = (ctf_lmember_t *) + ((uintptr_t)tp + increment); + + vbytes = sizeof (ctf_lmember_t) * vlen; + for (n = vlen; n != 0; n--, lmp++) + child |= + CTF_TYPE_ISCHILD(lmp->ctlm_type); + } + break; + case CTF_K_ENUM: + vbytes = sizeof (ctf_enum_t) * vlen; + break; + case CTF_K_FORWARD: + case CTF_K_UNKNOWN: + vbytes = 0; + break; + case CTF_K_POINTER: + case CTF_K_TYPEDEF: + case CTF_K_VOLATILE: + case CTF_K_CONST: + case CTF_K_RESTRICT: + vbytes = 0; + break; + default: + printf("%s(%d): detected invalid CTF kind -- %u\n", __func__, __LINE__, kind); + return (EIO); + } + *xp = (uint32_t)((uintptr_t) tp - (uintptr_t) ctfdata); + tp = (ctf_type_t *)((uintptr_t)tp + increment + vbytes); + } + + return (0); +} + +/* + * CTF Declaration Stack + * + * In order to implement ctf_type_name(), we must convert a type graph back + * into a C type declaration. Unfortunately, a type graph represents a storage + * class ordering of the type whereas a type declaration must obey the C rules + * for operator precedence, and the two orderings are frequently in conflict. + * For example, consider these CTF type graphs and their C declarations: + * + * CTF_K_POINTER -> CTF_K_FUNCTION -> CTF_K_INTEGER : int (*)() + * CTF_K_POINTER -> CTF_K_ARRAY -> CTF_K_INTEGER : int (*)[] + * + * In each case, parentheses are used to raise operator * to higher lexical + * precedence, so the string form of the C declaration cannot be constructed by + * walking the type graph links and forming the string from left to right. + * + * The functions in this file build a set of stacks from the type graph nodes + * corresponding to the C operator precedence levels in the appropriate order. + * The code in ctf_type_name() can then iterate over the levels and nodes in + * lexical precedence order and construct the final C declaration string. + */ +typedef struct ctf_list { + struct ctf_list *l_prev; /* previous pointer or tail pointer */ + struct ctf_list *l_next; /* next pointer or head pointer */ +} ctf_list_t; + +#define ctf_list_prev(elem) ((void *)(((ctf_list_t *)(elem))->l_prev)) +#define ctf_list_next(elem) ((void *)(((ctf_list_t *)(elem))->l_next)) + +typedef enum { + CTF_PREC_BASE, + CTF_PREC_POINTER, + CTF_PREC_ARRAY, + CTF_PREC_FUNCTION, + CTF_PREC_MAX +} ctf_decl_prec_t; + +typedef struct ctf_decl_node { + ctf_list_t cd_list; /* linked list pointers */ + ctf_id_t cd_type; /* type identifier */ + uint_t cd_kind; /* type kind */ + uint_t cd_n; /* type dimension if array */ +} ctf_decl_node_t; + +typedef struct ctf_decl { + ctf_list_t cd_nodes[CTF_PREC_MAX]; /* declaration node stacks */ + int cd_order[CTF_PREC_MAX]; /* storage order of decls */ + ctf_decl_prec_t cd_qualp; /* qualifier precision */ + ctf_decl_prec_t cd_ordp; /* ordered precision */ + char *cd_buf; /* buffer for output */ + char *cd_ptr; /* buffer location */ + char *cd_end; /* buffer limit */ + size_t cd_len; /* buffer space required */ + int cd_err; /* saved error value */ +} ctf_decl_t; + +/* + * Simple doubly-linked list append routine. This implementation assumes that + * each list element contains an embedded ctf_list_t as the first member. + * An additional ctf_list_t is used to store the head (l_next) and tail + * (l_prev) pointers. The current head and tail list elements have their + * previous and next pointers set to NULL, respectively. + */ +static void +ctf_list_append(ctf_list_t *lp, void *new) +{ + ctf_list_t *p = lp->l_prev; /* p = tail list element */ + ctf_list_t *q = new; /* q = new list element */ + + lp->l_prev = q; + q->l_prev = p; + q->l_next = NULL; + + if (p != NULL) + p->l_next = q; + else + lp->l_next = q; +} + +/* + * Prepend the specified existing element to the given ctf_list_t. The + * existing pointer should be pointing at a struct with embedded ctf_list_t. + */ +static void +ctf_list_prepend(ctf_list_t *lp, void *new) +{ + ctf_list_t *p = new; /* p = new list element */ + ctf_list_t *q = lp->l_next; /* q = head list element */ + + lp->l_next = p; + p->l_prev = NULL; + p->l_next = q; + + if (q != NULL) + q->l_prev = p; + else + lp->l_prev = p; +} + +static void +ctf_decl_init(ctf_decl_t *cd, char *buf, size_t len) +{ + int i; + + bzero(cd, sizeof (ctf_decl_t)); + + for (i = CTF_PREC_BASE; i < CTF_PREC_MAX; i++) + cd->cd_order[i] = CTF_PREC_BASE - 1; + + cd->cd_qualp = CTF_PREC_BASE; + cd->cd_ordp = CTF_PREC_BASE; + + cd->cd_buf = buf; + cd->cd_ptr = buf; + cd->cd_end = buf + len; +} + +static void +ctf_decl_fini(ctf_decl_t *cd) +{ + ctf_decl_node_t *cdp, *ndp; + int i; + + for (i = CTF_PREC_BASE; i < CTF_PREC_MAX; i++) { + for (cdp = ctf_list_next(&cd->cd_nodes[i]); + cdp != NULL; cdp = ndp) { + ndp = ctf_list_next(cdp); + free(cdp, M_FBT); + } + } +} + +static const ctf_type_t * +ctf_lookup_by_id(linker_ctf_t *lc, ctf_id_t type) +{ + const ctf_type_t *tp; + uint32_t offset; + uint32_t *typoff = *lc->typoffp; + + if (type >= *lc->typlenp) { + printf("%s(%d): type %d exceeds max %ld\n",__func__,__LINE__,(int) type,*lc->typlenp); + return(NULL); + } + + /* Check if the type isn't cross-referenced. */ + if ((offset = typoff[type]) == 0) { + printf("%s(%d): type %d isn't cross referenced\n",__func__,__LINE__, (int) type); + return(NULL); + } + + tp = (const ctf_type_t *)(lc->ctftab + offset + sizeof(ctf_header_t)); + + return (tp); +} + +static void +fbt_array_info(linker_ctf_t *lc, ctf_id_t type, ctf_arinfo_t *arp) +{ + const ctf_header_t *hp = (const ctf_header_t *) lc->ctftab; + const ctf_type_t *tp; + const ctf_array_t *ap; + ssize_t increment; + + bzero(arp, sizeof(*arp)); + + if ((tp = ctf_lookup_by_id(lc, type)) == NULL) + return; + + if (CTF_INFO_KIND(tp->ctt_info) != CTF_K_ARRAY) + return; + + (void) fbt_get_ctt_size(hp->cth_version, tp, NULL, &increment); + + ap = (const ctf_array_t *)((uintptr_t)tp + increment); + arp->ctr_contents = ap->cta_contents; + arp->ctr_index = ap->cta_index; + arp->ctr_nelems = ap->cta_nelems; +} + +static const char * +ctf_strptr(linker_ctf_t *lc, int name) +{ + const ctf_header_t *hp = (const ctf_header_t *) lc->ctftab;; + const char *strp = ""; + + if (name < 0 || name >= hp->cth_strlen) + return(strp); + + strp = (const char *)(lc->ctftab + hp->cth_stroff + name + sizeof(ctf_header_t)); + + return (strp); +} + +static void +ctf_decl_push(ctf_decl_t *cd, linker_ctf_t *lc, ctf_id_t type) +{ + ctf_decl_node_t *cdp; + ctf_decl_prec_t prec; + uint_t kind, n = 1; + int is_qual = 0; + + const ctf_type_t *tp; + ctf_arinfo_t ar; + + if ((tp = ctf_lookup_by_id(lc, type)) == NULL) { + cd->cd_err = ENOENT; + return; + } + + switch (kind = CTF_INFO_KIND(tp->ctt_info)) { + case CTF_K_ARRAY: + fbt_array_info(lc, type, &ar); + ctf_decl_push(cd, lc, ar.ctr_contents); + n = ar.ctr_nelems; + prec = CTF_PREC_ARRAY; + break; + + case CTF_K_TYPEDEF: + if (ctf_strptr(lc, tp->ctt_name)[0] == '\0') { + ctf_decl_push(cd, lc, tp->ctt_type); + return; + } + prec = CTF_PREC_BASE; + break; + + case CTF_K_FUNCTION: + ctf_decl_push(cd, lc, tp->ctt_type); + prec = CTF_PREC_FUNCTION; + break; + + case CTF_K_POINTER: + ctf_decl_push(cd, lc, tp->ctt_type); + prec = CTF_PREC_POINTER; + break; + + case CTF_K_VOLATILE: + case CTF_K_CONST: + case CTF_K_RESTRICT: + ctf_decl_push(cd, lc, tp->ctt_type); + prec = cd->cd_qualp; + is_qual++; + break; + + default: + prec = CTF_PREC_BASE; + } + + if ((cdp = malloc(sizeof (ctf_decl_node_t), M_FBT, M_WAITOK)) == NULL) { + cd->cd_err = EAGAIN; + return; + } + + cdp->cd_type = type; + cdp->cd_kind = kind; + cdp->cd_n = n; + + if (ctf_list_next(&cd->cd_nodes[prec]) == NULL) + cd->cd_order[prec] = cd->cd_ordp++; + + /* + * Reset cd_qualp to the highest precedence level that we've seen so + * far that can be qualified (CTF_PREC_BASE or CTF_PREC_POINTER). + */ + if (prec > cd->cd_qualp && prec < CTF_PREC_ARRAY) + cd->cd_qualp = prec; + + /* + * C array declarators are ordered inside out so prepend them. Also by + * convention qualifiers of base types precede the type specifier (e.g. + * const int vs. int const) even though the two forms are equivalent. + */ + if (kind == CTF_K_ARRAY || (is_qual && prec == CTF_PREC_BASE)) + ctf_list_prepend(&cd->cd_nodes[prec], cdp); + else + ctf_list_append(&cd->cd_nodes[prec], cdp); +} + +static void +ctf_decl_sprintf(ctf_decl_t *cd, const char *format, ...) +{ + size_t len = (size_t)(cd->cd_end - cd->cd_ptr); + va_list ap; + size_t n; + + va_start(ap, format); + n = vsnprintf(cd->cd_ptr, len, format, ap); + va_end(ap); + + cd->cd_ptr += MIN(n, len); + cd->cd_len += n; +} + +static ssize_t +fbt_type_name(linker_ctf_t *lc, ctf_id_t type, char *buf, size_t len) +{ + ctf_decl_t cd; + ctf_decl_node_t *cdp; + ctf_decl_prec_t prec, lp, rp; + int ptr, arr; + uint_t k; + + if (lc == NULL && type == CTF_ERR) + return (-1); /* simplify caller code by permitting CTF_ERR */ + + ctf_decl_init(&cd, buf, len); + ctf_decl_push(&cd, lc, type); + + if (cd.cd_err != 0) { + ctf_decl_fini(&cd); + return (-1); + } + + /* + * If the type graph's order conflicts with lexical precedence order + * for pointers or arrays, then we need to surround the declarations at + * the corresponding lexical precedence with parentheses. This can + * result in either a parenthesized pointer (*) as in int (*)() or + * int (*)[], or in a parenthesized pointer and array as in int (*[])(). + */ + ptr = cd.cd_order[CTF_PREC_POINTER] > CTF_PREC_POINTER; + arr = cd.cd_order[CTF_PREC_ARRAY] > CTF_PREC_ARRAY; + + rp = arr ? CTF_PREC_ARRAY : ptr ? CTF_PREC_POINTER : -1; + lp = ptr ? CTF_PREC_POINTER : arr ? CTF_PREC_ARRAY : -1; + + k = CTF_K_POINTER; /* avoid leading whitespace (see below) */ + + for (prec = CTF_PREC_BASE; prec < CTF_PREC_MAX; prec++) { + for (cdp = ctf_list_next(&cd.cd_nodes[prec]); + cdp != NULL; cdp = ctf_list_next(cdp)) { + + const ctf_type_t *tp = + ctf_lookup_by_id(lc, cdp->cd_type); + const char *name = ctf_strptr(lc, tp->ctt_name); + + if (k != CTF_K_POINTER && k != CTF_K_ARRAY) + ctf_decl_sprintf(&cd, " "); + + if (lp == prec) { + ctf_decl_sprintf(&cd, "("); + lp = -1; + } + + switch (cdp->cd_kind) { + case CTF_K_INTEGER: + case CTF_K_FLOAT: + case CTF_K_TYPEDEF: + ctf_decl_sprintf(&cd, "%s", name); + break; + case CTF_K_POINTER: + ctf_decl_sprintf(&cd, "*"); + break; + case CTF_K_ARRAY: + ctf_decl_sprintf(&cd, "[%u]", cdp->cd_n); + break; + case CTF_K_FUNCTION: + ctf_decl_sprintf(&cd, "()"); + break; + case CTF_K_STRUCT: + case CTF_K_FORWARD: + ctf_decl_sprintf(&cd, "struct %s", name); + break; + case CTF_K_UNION: + ctf_decl_sprintf(&cd, "union %s", name); + break; + case CTF_K_ENUM: + ctf_decl_sprintf(&cd, "enum %s", name); + break; + case CTF_K_VOLATILE: + ctf_decl_sprintf(&cd, "volatile"); + break; + case CTF_K_CONST: + ctf_decl_sprintf(&cd, "const"); + break; + case CTF_K_RESTRICT: + ctf_decl_sprintf(&cd, "restrict"); + break; + } + + k = cdp->cd_kind; + } + + if (rp == prec) + ctf_decl_sprintf(&cd, ")"); + } + + ctf_decl_fini(&cd); + return (cd.cd_len); +} + +static void +fbt_getargdesc(void *arg __unused, dtrace_id_t id __unused, void *parg, dtrace_argdesc_t *desc) +{ + const ushort_t *dp; + fbt_probe_t *fbt = parg; + linker_ctf_t lc; + modctl_t *ctl = fbt->fbtp_ctl; + int ndx = desc->dtargd_ndx; + int symindx = fbt->fbtp_symindx; + uint32_t *ctfoff; + uint32_t offset; + ushort_t info, kind, n; + + if (fbt->fbtp_roffset != 0 && desc->dtargd_ndx == 0) { + (void) strcpy(desc->dtargd_native, "int"); + return; + } + + desc->dtargd_ndx = DTRACE_ARGNONE; + + /* Get a pointer to the CTF data and it's length. */ + if (linker_ctf_get(ctl, &lc) != 0) + /* No CTF data? Something wrong? *shrug* */ + return; + + /* Check if this module hasn't been initialised yet. */ + if (*lc.ctfoffp == NULL) { + /* + * Initialise the CTF object and function symindx to + * byte offset array. + */ + if (fbt_ctfoff_init(ctl, &lc) != 0) + return; + + /* Initialise the CTF type to byte offset array. */ + if (fbt_typoff_init(&lc) != 0) + return; + } + + ctfoff = *lc.ctfoffp; + + if (ctfoff == NULL || *lc.typoffp == NULL) + return; + + /* Check if the symbol index is out of range. */ + if (symindx >= lc.nsym) + return; + + /* Check if the symbol isn't cross-referenced. */ + if ((offset = ctfoff[symindx]) == 0xffffffff) + return; + + dp = (const ushort_t *)(lc.ctftab + offset + sizeof(ctf_header_t)); + + info = *dp++; + kind = CTF_INFO_KIND(info); + n = CTF_INFO_VLEN(info); + + if (kind == CTF_K_UNKNOWN && n == 0) { + printf("%s(%d): Unknown function!\n",__func__,__LINE__); + return; + } + + if (kind != CTF_K_FUNCTION) { + printf("%s(%d): Expected a function!\n",__func__,__LINE__); + return; + } + + if (fbt->fbtp_roffset != 0) { + /* Only return type is available for args[1] in return probe. */ + if (ndx > 1) + return; + ASSERT(ndx == 1); + } else { + /* Check if the requested argument doesn't exist. */ + if (ndx >= n) + return; + + /* Skip the return type and arguments up to the one requested. */ + dp += ndx + 1; + } + + if (fbt_type_name(&lc, *dp, desc->dtargd_native, sizeof(desc->dtargd_native)) > 0) + desc->dtargd_ndx = ndx; + + return; +} + +static int +fbt_linker_file_cb(linker_file_t lf, void *arg) +{ + + fbt_provide_module(arg, lf); + + return (0); +} + +static void +fbt_load(void *dummy) +{ + /* Create the /dev/dtrace/fbt entry. */ + fbt_cdev = make_dev(&fbt_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, + "dtrace/fbt"); + + /* Default the probe table size if not specified. */ + if (fbt_probetab_size == 0) + fbt_probetab_size = FBT_PROBETAB_SIZE; + + /* Choose the hash mask for the probe table. */ + fbt_probetab_mask = fbt_probetab_size - 1; + + /* Allocate memory for the probe table. */ + fbt_probetab = + malloc(fbt_probetab_size * sizeof (fbt_probe_t *), M_FBT, M_WAITOK | M_ZERO); + + dtrace_invop_add(fbt_invop); + + if (dtrace_register("fbt", &fbt_attr, DTRACE_PRIV_USER, + NULL, &fbt_pops, NULL, &fbt_id) != 0) + return; + + /* Create probes for the kernel and already-loaded modules. */ + linker_file_foreach(fbt_linker_file_cb, NULL); +} + + +static int +fbt_unload() +{ + int error = 0; + + /* De-register the invalid opcode handler. */ + dtrace_invop_remove(fbt_invop); + + /* De-register this DTrace provider. */ + if ((error = dtrace_unregister(fbt_id)) != 0) + return (error); + + /* Free the probe table. */ + free(fbt_probetab, M_FBT); + fbt_probetab = NULL; + fbt_probetab_mask = 0; + + destroy_dev(fbt_cdev); + + return (error); +} + +static int +fbt_modevent(module_t mod __unused, int type, void *data __unused) +{ + int error = 0; + + switch (type) { + case MOD_LOAD: + break; + + case MOD_UNLOAD: + break; + + case MOD_SHUTDOWN: + break; + + default: + error = EOPNOTSUPP; + break; + + } + + return (error); +} + +static int +fbt_open(struct cdev *dev __unused, int oflags __unused, int devtype __unused, struct thread *td __unused) +{ + return (0); +} + +SYSINIT(fbt_load, SI_SUB_DTRACE_PROVIDER, SI_ORDER_ANY, fbt_load, NULL); +SYSUNINIT(fbt_unload, SI_SUB_DTRACE_PROVIDER, SI_ORDER_ANY, fbt_unload, NULL); + +DEV_MODULE(fbt, fbt_modevent, NULL); +MODULE_VERSION(fbt, 1); +MODULE_DEPEND(fbt, dtrace, 1, 1, 1); +MODULE_DEPEND(fbt, opensolaris, 1, 1, 1); diff --git a/sys/cddl/dev/lockstat/lockstat.c b/sys/cddl/dev/lockstat/lockstat.c index 9b3f7d7..a7e5896 100644 --- a/sys/cddl/dev/lockstat/lockstat.c +++ b/sys/cddl/dev/lockstat/lockstat.c @@ -46,7 +46,8 @@ #include #if defined(__i386__) || defined(__amd64__) || \ - defined(__mips__) || defined(__powerpc__) + defined(__mips__) || defined(__powerpc__) || \ + defined(__arm__) #define LOCKSTAT_AFRAMES 1 #else #error "architecture not supported" diff --git a/sys/cddl/dev/profile/profile.c b/sys/cddl/dev/profile/profile.c index 051ffa1..870c533 100644 --- a/sys/cddl/dev/profile/profile.c +++ b/sys/cddl/dev/profile/profile.c @@ -126,6 +126,16 @@ #define PROF_ARTIFICIAL_FRAMES 3 #endif +#ifdef __mips +/* bogus */ +#define PROF_ARTIFICIAL_FRAMES 3 +#endif + +#ifdef __arm__ +/* bogus */ +#define PROF_ARTIFICIAL_FRAMES 3 +#endif + typedef struct profile_probe { char prof_name[PROF_NAMELEN]; dtrace_id_t prof_id; diff --git a/sys/modules/dtrace/Makefile b/sys/modules/dtrace/Makefile index 1b12371..b819316 100644 --- a/sys/modules/dtrace/Makefile +++ b/sys/modules/dtrace/Makefile @@ -24,5 +24,7 @@ SUBDIR+= fbt fasttrap .if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_ARCH} == "powerpc64" SUBDIR+= systrace_freebsd32 .endif - +.if ${MACHINE_CPUARCH} == "arm" +SUBDIR+= fbt +.endif .include diff --git a/sys/modules/dtrace/dtrace/Makefile b/sys/modules/dtrace/dtrace/Makefile index 3299a1e..aa6b83b 100644 --- a/sys/modules/dtrace/dtrace/Makefile +++ b/sys/modules/dtrace/dtrace/Makefile @@ -22,7 +22,7 @@ CFLAGS+= -I${.CURDIR}/../../../cddl/contrib/opensolaris/uts/intel SRCS+= bus_if.h device_if.h vnode_if.h # Needed for dtrace_asm.S -SRCS+= assym.s +#SRCS+= assym.s # These are needed for assym.s SRCS+= opt_compat.h opt_kstack_pages.h opt_nfs.h opt_hwpmc_hooks.h diff --git a/sys/modules/dtrace/fbt/Makefile b/sys/modules/dtrace/fbt/Makefile index 7c03d31..4bb8195 100644 --- a/sys/modules/dtrace/fbt/Makefile +++ b/sys/modules/dtrace/fbt/Makefile @@ -3,8 +3,8 @@ .PATH: ${.CURDIR}/../../../cddl/dev/fbt KMOD= fbt -.if ${MACHINE_CPUARCH} == "powerpc" -SRCS= fbt_powerpc.c +.if ${MACHINE_CPUARCH} == "powerpc" || ${MACHINE_CPUARCH} == "arm" +SRCS= fbt_${MACHINE_CPUARCH}.c .else SRCS= fbt.c .endif --=-1VnxsOIhDnJzpH5E7tuZ-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 03:42:47 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 B97FE5EC; Sat, 9 Aug 2014 03:42:47 +0000 (UTC) Received: from felyko.com (felyko.com [65.49.80.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9F82824FD; Sat, 9 Aug 2014 03:42:47 +0000 (UTC) Received: from [IPv6:2601:9:8280:5fd:d52d:c118:dd20:86fd] (unknown [IPv6:2601:9:8280:5fd:d52d:c118:dd20:86fd]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 392B634A9D5; Fri, 8 Aug 2014 20:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1407555765; bh=mrbnGJ4mY2kjUorwDXQFOZXikKv9eb0KHGVqTFysCTc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NvXdjrF02Bzs0dstvFLJO0HaUH//5F15DvU88zVZovwXt6jK6nYSEx301PRbQzi+L NeOWxsLnduFgFGkZ20Vc6kM3awr4WGAEF75INdKxQRtD7JM83ICzVMaKhC0Lu+GM2L Xc1GSy6I9n0kZhHGRM/P18pgKDbtPhGBuVLwcSH0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Bug 192516] New: DTrace not yet supported on ARM From: Rui Paulo In-Reply-To: <1407555027.56408.442.camel@revolution.hippie.lan> Date: Fri, 8 Aug 2014 20:42:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1407515740.56408.378.camel@revolution.hippie.lan> <1407552970.56408.440.camel@revolution.hippie.lan> <1407555027.56408.442.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@FreeBSD.org 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: Sat, 09 Aug 2014 03:42:47 -0000 On Aug 8, 2014, at 20:30, Ian Lepore wrote: > On Fri, 2014-08-08 at 20:22 -0700, Rui Paulo wrote: >> On Aug 8, 2014, at 19:56, Ian Lepore wrote: >>> I'm talking about resources like asking for reviews of his patches = (and >>> nobody ever did, myself included). Answering questions, providing >>> advice, basic stuff that we're hard pressed to do, quite frankly. I >>> could spend my entire waking existance doing just that kind of = stuff, >>> and still not keep up, and also never get a line of code written. >>=20 >> Yup, that's why we have a bug tracker. :-) >>=20 >=20 > That response strikes me as being a bit of a non sequitor. It's not really. I'm of the opinion that it would be much easier to = follow up with Howard Su through bugzilla than through email.=20 The only non-logical aspect is the lack of a semi-decent bug tracker = back then. >>> If you didn't know, maybe you weren't reading arm@ back then... >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-arm/2013-November/006957.html >>=20 >> There's no patch here. Do you have it? >=20 > Attached. I've attached it to bug report. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 04:14:10 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 2861CBBC for ; Sat, 9 Aug 2014 04:14:10 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02DE52730 for ; Sat, 9 Aug 2014 04:14:08 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s794B8kG050569; Sat, 9 Aug 2014 04:11:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id 5pwyt653g9h7b3d5zwdmfytwki; Sat, 09 Aug 2014 04:11:08 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What platform do you use? From: Tim Kientzle In-Reply-To: <724D10EE-F6DF-4366-91CF-AE4419847389@gromit.dlib.vt.edu> Date: Fri, 8 Aug 2014 21:11:08 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <7EC2AB25-5949-40BF-A5AA-BF4C98F3F640@bsdimp.com> <20140805182438.GP88623@funkthat.com> <53E3E2C7.9000802@hot.ee> <24403276-D738-4CB1-A3BE-BBB72D4370C6@bsdimp.com> <724D10EE-F6DF-4366-91CF-AE4419847389@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm 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: Sat, 09 Aug 2014 04:14:10 -0000 On Aug 8, 2014, at 6:35 AM, Paul Mather wrote: > > It would be handy for those of us wanting to cross-build FreeBSD/arm > for someone who is familiar with the build process to give a quick > example of how to update a FreeBSD/arm installation that is cross-built > on another system. Personally, I use native "make buildworld buildkernel" and let it run over the weekend. ;-) I know a lot of people are happy with NFS mounts, but here are two other options that may prove attractive to some people: * For systems that boot from SD card: Cross-build a new system, mount the SD card onto the build host, and then update the SD card image with make ARCH=armv6 DESTDIR=/mnt/ installworld * For BBB that's booting from eMMC: I've considered adding an option to Crochet's BBB images so you can build a new SD image, boot from that, then update the installed system on eMMC with bits from the SD card. Such a script would complement the existing "copy-to-emmc.sh" script which erases the eMMC and copies over the SD image. Re: several complaints about SD cards and speed. A good USB reader/writer can bulk write to an SD card at better than 10MB/s. (That's a full 1GB image in about 2 minutes.) I've used the built-in SD adapters in various laptops, but those always seem to be really slow. It makes a big difference. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 04:14:28 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 2BFEABF3; Sat, 9 Aug 2014 04:14:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 044182732; Sat, 9 Aug 2014 04:14:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s794EP7u088248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 21:14:26 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s794EPqo088247; Fri, 8 Aug 2014 21:14:25 -0700 (PDT) (envelope-from jmg) Date: Fri, 8 Aug 2014 21:14:25 -0700 From: John-Mark Gurney To: Ian Lepore Subject: Re: [CFR] mge driver / elf reloc Message-ID: <20140809041425.GE83475@funkthat.com> Mail-Followup-To: Ian Lepore , Fabien Thomas , Tim Kientzle , freebsd-arm@FreeBSD.org References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <1407536156.56408.412.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1407536156.56408.412.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 08 Aug 2014 21:14:26 -0700 (PDT) Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Fabien Thomas 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: Sat, 09 Aug 2014 04:14:28 -0000 Ian Lepore wrote this message on Fri, Aug 08, 2014 at 16:15 -0600: > On Mon, 2014-07-21 at 10:40 +0200, Fabien Thomas wrote: > > On 21 Jul 2014, at 01:10, John-Mark Gurney wrote: > > > > > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > > >> > > >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote: > > >> > > >>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > > >>>> Sorry to take so long to reply to this, I'm trying to get caught up. I > > >>>> see you've already committed the mge fixes. I think the ELF alignment > > >>>> fix looks good and should also be committed. > > >>> > > >>> So, re the elf alignment... > > >>> > > >>> I think we should get a set of macros that handle load/stores to/from > > >>> unaligned addresses that are transparent to the caller.... I need > > >>> these for some other code I'm writing... > > >>> > > >>> I thought Open/Net had these available, but I can't seem to find them > > >>> right now... > > >> > > >> $ man 9 byteorder > > >> > > >> is most of what you want, lacking only some aliases to pick > > >> the correct macro for native byte order. > > > > > > Um, those doesn't help if you want native endian order... > > > > > > Also, only the enc/dec functions are documented to work on non-aligned > > > address, so that doesn't help in most cases... > > > > Yes, having an API to read unaligned pointer is better than than using local fix like in the patch. > > Tell me if you add one and I can adapt the patch. > > > > Fabien > > > > So can we just get this patch committed as-is, and then maybe convert it > later to the much-desired "something better" that this discussion > deteriorated into? > > http://people.freebsd.org/~fabient/ARM/patch-arm_elf_alignfix > > If you've ever wondered whether there are real costs to bikeshedding, > this is an example of such. This relocation patch is the fix to the Yes and no... Yes, this delayed it, but replys on improvement were given (Warner's) and then no action was taken... I want us to continue to take the better way than the quickest way... > kernel module loading problem HPS has been having, and who knows how > much time he had to waste debugging it. I know I spent 4 hours on it > today before discovering that the problem was known and fixed, only the > fix isn't committed yet. I agree w/ Warner that the conditional should be removed and we always call load_ptr/store_ptr... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Aug 9 22:35:39 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 28070DF3 for ; Sat, 9 Aug 2014 22:35:39 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (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 DEA82216A for ; Sat, 9 Aug 2014 22:35:38 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so8119066iec.10 for ; Sat, 09 Aug 2014 15:35:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Yo9ZW124MOcmtsdJsvYpUoFPrPl2NAoiOFhW1I5N6ms=; b=JpzboVfQrMf2plgzypdKsM2ynE99nabNJWsvQYektIqyS13z1POkY0MpYNJMdy0mOW HDVaW4OuSO2s1FtjYx1NrRoK9mk+JXxV64buvvkjBTRGjB8qlpgszlgkz6pJDO2G0/j1 2PYv/plufp07c9W2zpWyTM+8fHQrojMfu0f/4oAV7RnuzveGXa8eEyaTddUPFIImNprc +xIWl9tW/USjlWt7w/MEJKr6eo9Mx+Fd4vJ2ORQnbzOykJqZBMZlLp9J9dQQX8b5mDs4 L3/0ueQNei8S+BymPd+D/lotBCUWlHbLaOepRhQZ3AnDaJzDRO6o0zYjPCYdgBh7bL/E A73A== X-Gm-Message-State: ALoCoQkwIWwSleNJv31tej8hsGaslIrYmZlb/va096GUXsvNqNsRMmD7iwjiwxId2IU1wRsdiPr2 X-Received: by 10.50.39.8 with SMTP id l8mr17012875igk.13.1407623730895; Sat, 09 Aug 2014 15:35:30 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id n1sm27228285igp.1.2014.08.09.15.35.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Aug 2014 15:35:30 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_36106E6A-3B06-4118-9704-835FAF3D485A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Warner Losh In-Reply-To: <20140809041425.GE83475@funkthat.com> Date: Sat, 9 Aug 2014 16:35:28 -0600 Message-Id: <2F9FF1C2-7C87-4C5E-A829-9ACBCB0FF7A1@bsdimp.com> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <1407536156.56408.412.camel@revolution.hippie.lan> <20140809041425.GE83475@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Fabien Thomas , Ian Lepore 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: Sat, 09 Aug 2014 22:35:39 -0000 --Apple-Mail=_36106E6A-3B06-4118-9704-835FAF3D485A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 8, 2014, at 10:14 PM, John-Mark Gurney wrote: > Ian Lepore wrote this message on Fri, Aug 08, 2014 at 16:15 -0600: >> On Mon, 2014-07-21 at 10:40 +0200, Fabien Thomas wrote: >>> On 21 Jul 2014, at 01:10, John-Mark Gurney wrote: >>>=20 >>>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 = -0700: >>>>>=20 >>>>> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney = wrote: >>>>>=20 >>>>>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 = -0600: >>>>>>> Sorry to take so long to reply to this, I'm trying to get caught = up. I >>>>>>> see you've already committed the mge fixes. I think the ELF = alignment >>>>>>> fix looks good and should also be committed. >>>>>>=20 >>>>>> So, re the elf alignment... >>>>>>=20 >>>>>> I think we should get a set of macros that handle load/stores = to/from >>>>>> unaligned addresses that are transparent to the caller.... I = need >>>>>> these for some other code I'm writing...=20 >>>>>>=20 >>>>>> I thought Open/Net had these available, but I can't seem to find = them >>>>>> right now... >>>>>=20 >>>>> $ man 9 byteorder >>>>>=20 >>>>> is most of what you want, lacking only some aliases to pick >>>>> the correct macro for native byte order. >>>>=20 >>>> Um, those doesn't help if you want native endian order... >>>>=20 >>>> Also, only the enc/dec functions are documented to work on = non-aligned >>>> address, so that doesn't help in most cases... >>>=20 >>> Yes, having an API to read unaligned pointer is better than than = using local fix like in the patch. >>> Tell me if you add one and I can adapt the patch. >>>=20 >>> Fabien >>>=20 >>=20 >> So can we just get this patch committed as-is, and then maybe convert = it >> later to the much-desired "something better" that this discussion >> deteriorated into? >>=20 >> http://people.freebsd.org/~fabient/ARM/patch-arm_elf_alignfix >>=20 >> If you've ever wondered whether there are real costs to bikeshedding, >> this is an example of such. This relocation patch is the fix to the >=20 > Yes and no... Yes, this delayed it, but replys on improvement were > given (Warner's) and then no action was taken... >=20 > I want us to continue to take the better way than the quickest way... >=20 >> kernel module loading problem HPS has been having, and who knows how >> much time he had to waste debugging it. I know I spent 4 hours on it >> today before discovering that the problem was known and fixed, only = the >> fix isn't committed yet. >=20 > I agree w/ Warner that the conditional should be removed and we always > call load_ptr/store_ptr... The feedback was given quickly, but no reply was forthcoming. = Criticizing the feedback seems rather out of line. I=92ll commit something this weekend, but honestly the feedback wasn=92t = a bikeshed by any stretch of the imagination. Warner --Apple-Mail=_36106E6A-3B06-4118-9704-835FAF3D485A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT5qIwAAoJEGwc0Sh9sBEArLAQANY8tL8cvD7SzcfbLdzsczvc +l6q+2QlGnVNdzuA94NlvtmhxFe/DZ04GaLXv1IL4MFq9hP4SyWRa03R/whNPPWG l5NkGy28Ov5FgeO3FitzRRaFp+sRd0XuhRgiGshD/p54PiC9er03Z0pancA6lDFp 1mZz0EdAhj7zkbefKREaygQKlelCgo673wgCIJoGlpfqSbQqwKBYl3eLEMdKtjb7 c/QlMCCtjWwA1KbSpGzyc/q5HsV49av6IGlDInNWHTbkP8mXR/pxfDAR7zAj+Swi K87F0ccBwiwTzDtMxiCgd68Mp8g8H1eYiYqWBlhR3kNFqaSp7glg8GcemMVqTPQ1 JV/XHlcwy7k/qVOF4vNnW9b3irXLbwzH7hLGkWDdO9NYp8BaSpFPJZ6CqGWz9c1l VyrclznuEhszqgsiMqXFoNm9IBNoyINKUMTGduF4haw9Rkay9QhfEkH/UJ0qZ0EO K/ulJz0cxwo696Y67422nKxC3h4Ehk3Hxy11llhiHbhizESe708t6zssasdsITtG InkI/rDyEjbx/NcbzhDfo+gWxUE+fjHr08S1eBW+SMTnw43NzuWDebGLHB+gNlov hV9R1OBtdmDhTElIovVWKu7N1x7+zWOkTJQsbswZy4m3pRBXfFofyaGRM5rr4EX7 tDEVLWB78IgmQEpejc9R =p0dj -----END PGP SIGNATURE----- --Apple-Mail=_36106E6A-3B06-4118-9704-835FAF3D485A--