From owner-freebsd-arm@freebsd.org Sun Jul 24 15:46:15 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FAE2BA3A57 for ; Sun, 24 Jul 2016 15:46:15 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm48-vm4.bullet.mail.bf1.yahoo.com (nm48-vm4.bullet.mail.bf1.yahoo.com [216.109.115.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF0931BD6 for ; Sun, 24 Jul 2016 15:46:14 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1469375036; bh=iU7m3DGG+oqkRkNwDstW0qBekOLPnW+cCqLZmfFuLzM=; h=From:Subject:Date:Cc:To:From:Subject; b=bfF0L8MsIB7aZquaBDk8F1n6OATfK2H/b/Z9YcrIB13n60Up+18s8h8LOg2C106fM3KOqvpqoVlK6Fk/C6BGVmLyUmpGelT6nrsa8rzxt6mWsa1qXyrB4YlFENvHjNcYfBPir+HzwoJdRYjU4Q1AOnQjqRhiknTSrW7rZMsdsbkmGWciLvHdHWB3biEFjsBXDsJz5iTRNeNO4819qQ8+Kehzwv+vGUuQkWIUGIFD61SspZErBZSE6FhaUHHMnnXus5qMLqumKTbVVY0yC1N0USaV4Vvcfayzauc98rarq7GOIoitLOaR80IiCCxu9m1naE3v3PqarIlShajNzzoMLQ== Received: from [66.196.81.170] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2016 15:43:56 -0000 Received: from [98.139.211.195] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2016 15:43:56 -0000 Received: from [127.0.0.1] by smtp204.mail.bf1.yahoo.com with NNFMP; 24 Jul 2016 15:43:56 -0000 X-Yahoo-Newman-Id: 765817.25664.bm@smtp204.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6yvX7uQVM1nxjC7Jw1wfwtPt8sjtAXCE9wAIeUzxvvUXnJA 9zEddYF9gTEB2Cc4houhvu5AcfPHpZpZCGSZBuGYpebTyaLUNC2Z0GQzPtJs Qx6Y_hQa8ftJPTgE56KjTe2s.Ik8amA5RMftIFSpKe.EtSUNt17UamE71G8J RO96MJIlWbKFKqStDxuamWGTvKvRc.l13G9DvPv5JrlMloRRx3IPBf3Pc7Z_ Et0lCs9qiL73ebvfp90Im8xvGfHkQN45n2y2NbcM2y.e2e1M5e4R._sffWp3 P08dJiWCK901dyrkOCmzf3MW04kjsvd._q2KJyJenil6CjpfxtKARFCuPh2A 6DQP9hzO8B9kM2txCyCLZEJeO2QWshFqwgKGebdm.kUaw8tInbVSq1StEndt Tl2VzorlFyT1eZ9APwrxythCw0nGtnOdhyBBsq.L3dMffzRnGcg1UYaPJXk3 I.wKfr40YRwq7T4RZC1.cGV.ZQOzHmZ85oPLlAhmrjwVIYF2dS139n.RXsfz xb2MDpgTEjQ__C2Tv8halZ9fYv7Uxt3qAN1.RdO6CIGPxTibThcMP4QRKxBm roVmNTiAyixDNFOAJp3oKlTH5NYU- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Questions about writing custom boot loader, Zynq, Zybo Date: Sun, 24 Jul 2016 08:43:54 -0700 Message-Id: Cc: Thomas Skibo To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 15:46:15 -0000 > I have the following problems while the kernel is booting: >=20 > 1. RS232 port switches to double speed when the kernel starts printing > (230400 baud instead of 115200 baud). This may be due to a clock not getting initialized correctly. See = below. >=20 > 2. The ethernet driver cannot find the MAC address The ethernet address is set by u-boot. Without an ethernet address, the = driver (cgem) is supposed to pick a random one. >=20 > 3. Is there anything special about how the Zynq is configured in > ps7_init.c? Absolutely. ps7_init.c sets up all the clocks and DDR parameters and is = very board specific. This might be why you=E2=80=99re having problems = with the RS232 port. The clock settings may not match the clock values = in the dtb. >=20 > 4. Is the exact ps7_init.c that Thomas Skibo used for his Zybo = binaries > available anywhere? I build the u-boot binaries from sources at = https://github.com/Xilinx/u-boot-xlnx, specifically release v2016.1. = The ps7_init.c and ps7_init.h used are in directory = board/xilinx/zynq/zybo_hw_platform. There are ps7_init.[ch] for other = boards there too. =E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Sun Jul 24 20:45:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6940BA3E19 for ; Sun, 24 Jul 2016 20:45:16 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61B3E1F7C for ; Sun, 24 Jul 2016 20:45:15 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id b199so116487697lfe.0 for ; Sun, 24 Jul 2016 13:45:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=OZ6Xmhf8M17Wt0LRjbwrxWAn2e1y1eArguharl4/tj8=; b=YivBN3Y+IisCiBDujIwAqVYGCYClra+W/a5uQEzLQxYzAEjF681IIff4jcjU7Ufaxe PEIwCandnD9n9QGlFgMHP/8G+DTFwEqKaYugaC/bIMF4sW4c0syZ1a+kT3hSJIA0cZNN VNXHLLgel/xqoCCO1e1LHi+84I9NLxgDuAxdUltz69jv5I22HqVbi9IoMXJm3y46rEbA Abg2mnLwG5z7PUxjnci0VhCsGlshLjOpVCLfIsp17W78jNvJfIuuv5r4m5KUAkTtLi7o s4i7LJvOSLRKXpWnBYtHzD7n8aFbl4yXs7AKNm5co3o+svUZD+L0hEwUW2g6tYEVYOBm AXGg== X-Gm-Message-State: AEkoouvewmjEFpSIVAQv3RT0x9jjtqDerVNrXVDxNv92j1IG00IiXwR0VdQjOj/KmDLBvA== X-Received: by 10.46.9.142 with SMTP id 136mr6154102ljj.4.1469393113600; Sun, 24 Jul 2016 13:45:13 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id f69sm4962110lji.19.2016.07.24.13.45.12 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 24 Jul 2016 13:45:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Herminio Hernandez Jr. " Cc: "Adrian Chadd" , "Peter Jeremy" , "freebsd-arm@freebsd.org" Subject: Re: rpi2 as wireless router References: <20160720063002.GC35271@server.rulingia.com> <20160720223337.GE35271@server.rulingia.com> <60BAAAA2-D1A5-40AF-9B43-9AB4815D9DFF@gmail.com> <4E1AB9F3-B7F8-49F3-BAD2-259584B04E3B@gmail.com> Date: Sun, 24 Jul 2016 23:45:04 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <4E1AB9F3-B7F8-49F3-BAD2-259584B04E3B@gmail.com> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 20:45:16 -0000 Thu, 21 Jul 2016 06:56:22 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Herminio Hernandez Jr. = : Another idea: try to add hw.usb.urtwn.enable_11n=3D"0" into /boot/loader.conf (and reboot). (described as "download speed" fix in = https://forums.freebsd.org/threads/48737/ - but may help here too). > No same issue. I am willing to help in any way I can. I can send you t= he = > pcap files I made. > > Sent from my iPhone > >> On Jul 20, 2016, at 8:04 PM, Adrian Chadd = >> wrote: >> >> Hi, >> >> Ok. We'll have to set up a test environment here to see what's going >> on, complete with some packet sniffing. >> >> Question - if you configure up hostap to be open/no authentication, >> does it all work? >> >> >> -a From owner-freebsd-arm@freebsd.org Sun Jul 24 22:25:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3128BA3FFA for ; Sun, 24 Jul 2016 22:25:12 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7C721BF2 for ; Sun, 24 Jul 2016 22:25:12 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id l72so229855110oig.2 for ; Sun, 24 Jul 2016 15:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tZUOruRWc6NENZMCrgB3M3cAgJHpDSWtbQGfRjGhWPI=; b=OTw1C0LTAQ1gt4oEr545KQBqWhnjGnq1h3LRATmv/yugYGng7DleVKsxlK6F5ZTg9G sA+I/NYQUZ99fackkJBsy95nD4DxXOPhay14GtqhKfBntB1qv1lNLUTstvg8v4noAW3t 3Zss/VMI4un2DQaMjs5RcP4dcwUd3YKVqVXCbnERPXg+Sknula9tA32WAHCGVRITN5cl t4xSr1CdGloQQyo/Y5/66bs7eD3dxUrTY+LFHylWxPyPcqQlr04yU0p3lP18YjsqcjYZ 6QfqlVukPq1vX6fSUhsq2NdLXiDhmw1iEz+egSwl+rXFmecq/GiZnY5J8uu3J4U3uADZ 6g8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tZUOruRWc6NENZMCrgB3M3cAgJHpDSWtbQGfRjGhWPI=; b=dxonETca0XO26TNwSBM4xIjCH0J6qVvjR0xQF4aT2tXzIM2ZvArih57swdNSE1jadG B72Yp0o9xQHqE9sJaGs0LXZzckYo9V1lVAxjq8CRgNgWG7BUCCh8LolrLxhqfIWGKo7o eGAKSBGgIaSfhXFmEEDTFV2EHND/tRrXg4O93xrTXQgmMGDAoL3sahqKvt5wwB7XDbIk K/8NYQyWl5L/jRDDlxImM1WekUYSKkEUsRWbBzAv8JJAowX3i85W+WMRVav2OjNxCBww VPikqF1fLbHXmPEpHplnfGpSQrOf4Jv7KjpivEb3ei4mdbBYlrP3GVjqNP8DMBcWozk7 8+zQ== X-Gm-Message-State: AEkoouuk9XkYpBD8wzq5gTrdN7yga4RHL0SIGvPGuk3wGdBhJUcYwuxZtYR4fchLNHIWVu2lFc/HC/txYcynOg== X-Received: by 10.157.17.251 with SMTP id y56mr7305129oty.144.1469399111941; Sun, 24 Jul 2016 15:25:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.20.8 with HTTP; Sun, 24 Jul 2016 15:25:11 -0700 (PDT) In-Reply-To: References: From: Lee D Date: Sun, 24 Jul 2016 18:25:11 -0400 Message-ID: Subject: Re: Questions about writing custom boot loader, Zynq, Zybo To: Thomas Skibo Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 22:25:13 -0000 On Sun, Jul 24, 2016 at 11:43 AM, Thomas Skibo via freebsd-arm < freebsd-arm@freebsd.org> wrote: > > > > I have the following problems while the kernel is booting: > > > > 1. RS232 port switches to double speed when the kernel starts printing > > (230400 baud instead of 115200 baud). > > This may be due to a clock not getting initialized correctly. See below. > > > > > 2. The ethernet driver cannot find the MAC address > > The ethernet address is set by u-boot. Without an ethernet address, the > driver (cgem) is supposed to pick a random one. > > > > > 3. Is there anything special about how the Zynq is configured in > > ps7_init.c? > > Absolutely. ps7_init.c sets up all the clocks and DDR parameters and is > very board specific. This might be why you=E2=80=99re having problems wi= th the > RS232 port. The clock settings may not match the clock values in the dtb= . > > > > > 4. Is the exact ps7_init.c that Thomas Skibo used for his Zybo binaries > > available anywhere? > > I build the u-boot binaries from sources at > https://github.com/Xilinx/u-boot-xlnx, specifically release v2016.1. The > ps7_init.c and ps7_init.h used are in directory > board/xilinx/zynq/zybo_hw_platform. There are ps7_init.[ch] for other > boards there too. > > > =E2=80=94 > Thomas Skibo > thomasskibo@yahoo.com > > > Thanks for the tips. The RS232 issue was simple. Xilinx (or possibly Digilent) changed the default clock for the serial port from 50MHz to 100MHz. I made the correction in the DTS file and now the baud rate is correct. Do you know if passing a boot params structure in R0 is necessary for the kernel to boot? I still can't seem to get past that timer message. This is what I've done: 1. Made sure I am working with a bare default Zybo config generated in Vivado 2016.2 2. compared my ps_init.[ch] to the one you pointed me to. There were no significant differences except for the RS232 clock rate. I had some MIO pins configured, and my DRAM timings were different. my DRAM works fine with standalone apps so I assume that was a tweak made by Digilent and not an issue. 3. added printf's to inittimecounter() in src/sys/kern/kern_tc.c. It is clear that it completes normally. Also the timer appears to be running. However that function is part of the kernel init sequence (SYSINIT macro), so I don't know what is getting called next. 4. I removed the ehci device from the DTS, and commented out all USB related entries in the zybo kernel config file. Still it freezes after that timer message. So probably not USB related. 5. Checked to make sure that the USB3320 chip is not being held in reset by the GPIO line. My next steps are: 1. keep digging through the kernel and placing printfs to pinpoint where it is failing. 2. try the ps_init.[ch] files you showed me in my project, even though they shouldn't make any difference. 3. try passing a boot params structure in r0. Thanks again for pointing me to the original ps_init files, that was very helpful to be able to see those. Lee From owner-freebsd-arm@freebsd.org Sun Jul 24 22:29:42 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D863BA30AB; Sun, 24 Jul 2016 22:29:42 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8411C9D; Sun, 24 Jul 2016 22:29:42 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6OMTdKZ021282 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2016 15:29:39 -0700 To: freebsd-arch , freebsd-arm@freebsd.org, Michal Meloun , Svatopluk Kraus From: Nathan Whitehorn Subject: bus_map_intr() changes Message-ID: Date: Sun, 24 Jul 2016 15:29:38 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 X-Sonic-CAuth: UmFuZG9tSVYpR/a0cWS68gL1SqUzzrY3bq00D+HhJ3yL9Mq/FCQoWRnSA7uRKVpReCrqnhptsLMbquuh7pe5qLO8KbrZ96y06DKL7GPCMhk= X-Sonic-ID: C;JHm6G+5R5hGIN5NwxPCmMQ== M;uDX2G+5R5hGIN5NwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 22:29:42 -0000 There is a very long thread on the SVN list about this that has lasted much too long and should be over here. So, I'd like to start with a clean slate. The discussion is related to r301453, which adds a function BUS_MAP_INTR() and a function bus_extend_resource() that allow a parent bus to decode SYS_RES_IRQ-type resources during bus_alloc_resource(). This is designed to allow the parent bus to read in flags from the device tree regarding IRQ setup (polarity, trigger mode) and pass that along to the interrupt controller with the resource allocation request. By specifying an enum intr_map_data_type, you can also specify what kind of interrupt specifier is being added to the decoration (ACPI, FDT, GPIO). This is a departure from the existing code used on device tree systems (OFW_BUS_MAP_INTR()), which allocates a virtual IRQ corresponding to an interrupt-parent key and one of the device tree's opaque arbitrary-length interrupt specifiers at resource assignment time. The information that virtual IRQ maps to is cached and then applied by the PIC when the PIC's interrupts are configured, which may be after BUS_SETUP_INTR() if the call is made before interrupts are on and the PIC hasn't attached at that point. I am making a wiki page at https://wiki.freebsd.org/Complicated_Interrupts to describe the current implementation and the rationale for its implementation, which should exist by the time most read this. Some of that content is copied below for ease of replying. My concern is that the new API (r301453) parallels the existing one in a way that will require both to be maintained indefinitely, while providing less functionality, in particular in three ways: 1. Breaking the opacity of the device tree's interrupt specifiers (which only the PIC driver knows what to do with) 2. Requiring the bus parent to know exactly how to map an IRQ number (poorly determined, as above) to a device tree entry (which may not include it -- see below) and know how to interpret it (above, which only the PIC driver knows) 3. It also requires that the PIC driver already be attached, which cannot be guaranteed on some systems where the PIC is a bus child of devices with interrupt on that same PIC. What I would like to establish here, rather than just being cranky, is that this new API both (a) does something on real hardware that the existing API cannot do, either currently or with trivial modifications and (b) is capable of expressing the things the current API can express. If the answer to either of those is "no", we're going to have to support both in perpetuity, with different paths on different platforms and the whole thing is going to be a huge mess. We're in a situation right now where that will be baked into FreeBSD 11 for the duration of the branch, which is quite unfortunate. -Nathan ---- Excerpt of wiki text ---- ---- Part 1: Overview of mechanism ---- The core part of this system is a registry in machine-dependent code that maps some description of an interrupt to an IRQ number used by the rest of the kernel. This number is arbitrary; on systems in which a useful human-readable number can be extracted in a general way from the description, it is helpful for users for the IRQ number to be related to something about the system (e.g. the interrupt pin on single-controller systems) but it can be just a monotonically increasing integer. Currently one interrupt mapping strategy is implemented: Open Firmware (or FDT) interrupt-parent / interrupt specifier tuples to IRQ. Bus code maps the Open Firmware interrupt specifier using the ofw_bus_map_intr() function, which is cascaded through the bus hierarchy and is usually resolved by nexus. int ofw_bus_map_intr(device_t dev, phandle_t iparent, int icells, pcell_t *intr); This takes the requesting device, the xref phandle of the interrupt parent (e.g. from the "interrupt-parent" property, or the equivalent entry in an interrupt-map) and the byte string describing the interrupt (e.g. the contents of the "interrupts" property, or the equivalent entry in an interrupt-map) and returns a unique IRQ number that can be added to a resource list and used with bus_alloc_resource(), bus_setup_intr(), etc. In the event you needed more than OF-type mappings (e.g. for ACPI) you could add an equivalent acpi_bus_map_intr() method to nexus that tabulates mappings in parallel based on different data. ---- Part 2: Rationale ---- As a separate issue, it would be great if you could comment on a way to implement the following two scenarios with this API, which I think are currently impossible and would need to solved to avoid bifurcation. These kinds of things are what drove the current API. --- Case 1: the G5 Powermac --- I have hardware with two PICs, one cascaded from the other. PIC 1 lives in the northbridge, and PIC 2 lives on a device on the PCI bus behind a couple of bridges. Depending on the era of the hardware, these are cascaded in different directions. They have different interrupt specifier formats. A. How do I represent interrupts on the PCI bus parent of PIC 2 that are handled by PIC 2? PIC 2 obviously can't attach before its bus parent, but the bus parent can't complete initialization without the ability to setup its interrupts. B. Devices on the PCI bus have interrupts handled by a mixture of PIC 1 and PIC 2, sometimes on the same device and not always expressable through the bus hierarchy. For example, one of the two storage controllers has an interrupt on PIC 2 run through a wire that doesn't go through the PCI connection and so isn't in the interrupt-map of the PCI bus, which is wired (mostly) to PIC 1, and about which the parent bus can and should know nothing. --- Case 2: IBM OPAL firmware --- The /ibm,opal device on IBM PowerNV systems has a non-standard interrupts property ("opal-interrupts") that contains the list of IRQs that should be forwarded to the firmware. These are not interrupts belonging to a single physical device at /ibm,opal (which is a virtual device anyway) and so are not in the interrupts property; nor do they necessarily share an interrupt parent. How do I represent this? --- Case 3: IBM XICS interrupts --- On virtualized (and most non-virtualized) IBM hardware, the interrupts are one cell and that single cell encodes the interrupt parent, the line sense, and the IRQ. --- Case 4: MSIs --- MSIs are assigned purely by the PCI bus and the PCI bus parent can't know about them from the device tree. How does the bus parent sensibly decorate resources like this? The PCI MSI API assumes that these all exist purely as 32-bit integers and they are not assigned through resource lists in the conventional fashion. From owner-freebsd-arm@freebsd.org Sun Jul 24 22:38:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15713BA3302 for ; Sun, 24 Jul 2016 22:38:18 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E68B61364; Sun, 24 Jul 2016 22:38:17 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6OMcEM7028658 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2016 15:38:15 -0700 Subject: Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys To: Michal Meloun , Svatopluk Kraus , freebsd-arm@freebsd.org References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> From: Nathan Whitehorn Message-ID: Date: Sun, 24 Jul 2016 15:38:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57950005.6070403@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbxsU7wVoV5X8eeAOws7AobMQTIvl5L1AOcvKlpYcOxYvRX68nKtgM1SIKJpVwALfEFgARWTRjj7AKxny7tDHC4Q9NP01USJOE= X-Sonic-ID: C;5m4yT+9R5hGDPZNwxPCmMQ== M;9kJ2T+9R5hGDPZNwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 22:38:18 -0000 On 07/24/16 10:51, Michal Meloun wrote: [snip] >>> >>>> >>>>> For this reason we makes domain key composite, in our model, the >>>>> domain key consist of "domain key type" >>>>> and "domain key value". This composite key guarantees uniqueness >>>>> and it also allows to select proper parser for byte string. >>>> >>>> Yes, but this solves what is a nonexistant problem by making the >>>> system substantially less flexible and more invasive. Which is not >>>> a good tradeoff. >>>> >>> I think that existence of problem is confirmed in the above example . >>> Quote from previous paragraph: >>> "We could solve this in a number of ways, ... , or adding another >>> value (domain type, for example)." >>> What can I say more ... >> >> Except that the example you gave *is not an example* of the problem >> you are describing. You would only end up with a problem if: >> 1) You had interrupts in a GPIO property rather than in an interrupts >> property (or equivalent). >> 2) *And* you had interrupts on GPIOs in an interrupts property (or >> equivalent) >> 3) *and* those are encoded differently >> 4) *and* the different encodings use the same number of cells >> 5) *and* are not otherwise distinguishable >> >> Does that ever actually happen, in the real world, on any device >> tree? You could imagine any kind of messed up thing you want, but we >> shouldn't structure APIs around them, especially given that the >> current alternative you are proposing has real, concrete problems on >> real hardware that actually exists. >> > Allow me to respond to this issue only. I think that this main issue, > everything else looks resolvable for me (or, in worst case, can be > converted to MD code). > > from linux/arch/arm/boot/dts/am335x-evm.dts (it's first file that I'm > searched) > > ---------------------------------------------------------------------------------------------------------------------------- > &gpmc { > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&nandflash_pins_s0>; > ranges = <0 0 0x08000000 0x1000000>; /* CS0: 16MB for NAND */ > nand@0,0 { > compatible = "ti,omap2-nand"; > reg = <0 0 4>; /* CS0, offset 0, IO size 4 */ > interrupt-parent = <&gpmc>; > interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ > <1 IRQ_TYPE_NONE>; /* termcount */ > rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ > ---------------------------------------------------------------------------------------------------------------------------- > so we have > rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ > and > interrupt-parent = <&gpmc>; > interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ > > > --- or --- > from linux/arch/arm/boot/dts/exynos5420-peach-pit.dts > > max98090: codec@10 { > compatible = "maxim,max98090"; > reg = <0x10>; > interrupts = <2 0>; > interrupt-parent = <&gpx0>; > pinctrl-names = "default"; > and > sleep-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>; > > also, in this case, first cell in 'interrupts' property have different > meaning that second cell in 'sleep-gpio'. > (on exynos, not all gpios supports interrrupts) > > > In general, binding for 'interrupts ' and '-gpios ' are > different, but can have same size . Thanks so much for the concrete example! This is very helpful. Three questions: 1. Are the drivers for these devices actually taking interrupts on the lines defined in the *-gpios property? It seems weird to me that there would be interrupts on GPIOs and, simultaneously, implicit interrupts on other GPIOs. It looks like the things on the *-gpios properties are things you set rather than things you would request an interrupt on (sleep for the second case, a wait pin in the first). 2. What is the different meaning? I assumed the second cell in both cases is the GPIO pin number, because anything else would be crazy. 3. What on earth is IRQ_TYPE_NONE? That's an OpenPIC flag that just disables the interrupt entirely. Why would you want to configure things that way? (#1 is the only one that really matters here; the rest are personal curiosity) If the answer to (1) is "yes", there would be a good case for adding something like a ofw_bus_map_gpio_as_intr() or the like that takes the same arguments as ofw_bus_map_intr() and propagates them to the control in some way but with a flag. It's an easy extension and this is the reason the function has "ofw" in the name. My one qualm about that is that there is no guarantee that a GPIO controller can actually provide interrupts on a random GPIO (nor is it clear that that is actually what is wanted here). That qualm applies to both APIs, of course, and I still don't see a rationale for throwing away the existing code even if (1) is true. I've changed the mailing list here since the SVN list really isn't the best place. For people who want context and are seeing this for the first time, please see the other email I just sent. -Nathan From owner-freebsd-arm@freebsd.org Mon Jul 25 02:23:00 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE212BA46CD for ; Mon, 25 Jul 2016 02:23:00 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A82521B1E; Mon, 25 Jul 2016 02:23:00 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: by mail-pf0-x22f.google.com with SMTP id y134so58730058pfg.0; Sun, 24 Jul 2016 19:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6hHyHLncrFIcrLSSFMxGus+W71c+pHYJekgSqdWPbL0=; b=IxKP39wrhLjC9USFLiz303smjV3PqRQeS4P926DE5O2QKogP9OUXYM7Dk7qDhtm+ta xKJSLolnjIMrLu4V6iSex87NYuRv3ZKwFrfdH2npGQBtO7ikTWGuWoB7yKl4kspOXCRi v+70dlxf0JQ6cXSUR70na5O1AljD4KY8S2f/Aj8Xp2frn5SGsGD7UECFKb8ppQ5t3j3Y EoWInFX4ROGcUcSv3lwcCPIeUH1viCbtAg0q7Hu2lzO59T6tOsPMzzNWfat6axWspqbf /gWB3VgW09CcUXRMyCECtCtScv1VCII+dL84LK203rF77NqKhAPg24tMwId84SpZIWiE SiIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6hHyHLncrFIcrLSSFMxGus+W71c+pHYJekgSqdWPbL0=; b=SVngiYQ2yJcndKUZCENcZf1rZcaCJWcCH+EpU7/eC4VLL6SsRuKWtYGp95RD9p7cMC GflM3NEMGGIWGyg0awh7DWFgjUjHaNoreB6sWnSVSS8xT2WIbj/BnzXnuU8OuTxTPNia s2Akuqe0FdZHskiQ5r9avsq3dcHsTIAeZ5X8mui1SE3FD7ZZtKhNdkhEkYjb4skh9zkq NvliP24gBAVMUAsIe4j5WK0pC3u0qMovaHItpSBJftlEXDPoXLFDr6S3BuPhhw3h+mxd mqJ/ylREShIKB3oP1KpOGYxH+5v3YAEmKudJNTSU9ORtEJKonWCV11gk5JbxkDk0nsEs a/Eg== X-Gm-Message-State: AEkoouuxQDrFrVAPAuiQvzku5FEvtiCib8INEU2Jdz3onYMvl2ylCJ10IwrakPDAIyoRGw== X-Received: by 10.98.102.221 with SMTP id s90mr25144146pfj.69.1469413380278; Sun, 24 Jul 2016 19:23:00 -0700 (PDT) Received: from debian-macbookpro (wsip-24-249-178-180.ph.ph.cox.net. [24.249.178.180]) by smtp.gmail.com with ESMTPSA id d3sm35316714pfk.37.2016.07.24.19.22.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 24 Jul 2016 19:22:59 -0700 (PDT) Date: Sun, 24 Jul 2016 19:22:55 -0700 From: Herminio Hernandez Jr To: Andriy Voskoboinyk Cc: Adrian Chadd , Peter Jeremy , "freebsd-arm@freebsd.org" Subject: Re: rpi2 as wireless router Message-ID: <20160725022255.GA6128@debian-macbookpro> References: <20160720223337.GE35271@server.rulingia.com> <60BAAAA2-D1A5-40AF-9B43-9AB4815D9DFF@gmail.com> <4E1AB9F3-B7F8-49F3-BAD2-259584B04E3B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 02:23:01 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 07/24, Andriy Voskoboinyk wrote: > Thu, 21 Jul 2016 06:56:22 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Herminio Hernandez Jr. > : >=20 > Another idea: try to add > hw.usb.urtwn.enable_11n=3D"0" > into /boot/loader.conf (and reboot). > (described as "download speed" fix in > https://forums.freebsd.org/threads/48737/ - > but may help here too). >=20 The same issue. Debian is not seeing the DHCP Offer from freebsd.=20 > > No same issue. I am willing to help in any way I can. I can send you the > > pcap files I made. > >=20 > > Sent from my iPhone > >=20 > > > On Jul 20, 2016, at 8:04 PM, Adrian Chadd > > > wrote: > > >=20 > > > Hi, > > >=20 > > > Ok. We'll have to set up a test environment here to see what's going > > > on, complete with some packet sniffing. > > >=20 > > > Question - if you configure up hostap to be open/no authentication, > > > does it all work? > > >=20 > > >=20 > > > -a --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJXlXf/AAoJEH77aDWU7UChav0P/R2ewU0YIlEKHn24dDrTeZ7h fkTJkOuQAGnN13TbjQyJy9CeSYEnY8i3QqXwQg+v6qlf3Mw8i/nYNzOzunO2YsNr lY9KcKwK8K71aNOgijFDXajy2/WFscnXW3fa08Di+J2fxrrbMyMakBw4V3CjF9fT uLaweepfts5r8bcJWMm/7iQG29ZxWC5nZM4P5NCSdxMYLrUQod9+myjNabez+6kY tuLd8bEM9lbNUfwRRtz6yKBqHDEG/y0jAHXPGVaCVWvGhSpB7IKChnruwYu95y5w hs9YMzSQFUJssuA87EBSOjZqHUOoMF6HoKA94AjvzxsBaN1SfwTlAQd8dw4yoQ2s OPR49Ct2b1NP8/Q20e2rjtvsuFwJh2Nl0QxzbIj6+ULXEoQh5Pl7WcAP6j4JhsfP LYq6GElJQELWyYB8x5EY5xcV/JzZrjiJHva94YC5WrAacMR7tUMjLB303APwMzhr d+DEWWfp3yNVBBCsSjKdhqYnEumcAno2mCwop9C8jMev25yszGZ/b7yUcb32F4uS GEqBluRTmG05nvFUNhr+wua6JqBykHlazehLtYNZAnJz47UV31KOSRxP/ghRxcEA 2WXfIDh4xFtSTha8I2kf2kgKORREOJc6vEJF7r80JhUSZWYlEVmEXRcgnMuJq5v3 9y8CaQrYJGnGwy7CY7rZ =8Mw7 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-arm@freebsd.org Mon Jul 25 03:37:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E628BA3657 for ; Mon, 25 Jul 2016 03:37:04 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C818A117B for ; Mon, 25 Jul 2016 03:37:03 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-oi0-x243.google.com with SMTP id c199so15565107oig.1 for ; Sun, 24 Jul 2016 20:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=SzIUO9zXtGgmtpq7WsZsJMpwXhzJNVFNKmA+ta699jw=; b=wQD6I3lB1Le27oLaLtddewr5fLA0kmwCxuIDgdexK3C9xJHct1cdNmNCSUGS2Zuw6U 4Wv+kTPokOqXSBQhhVYgXjCVorxReIyxXug8XzHXBkcw0+uSedbcI2dD/VeUQ3l+KvOV n6YAYkxWt9cd0K0lGDs23JIXT7bi6hlnMSbKKgxot9SrTYU3PyGB5z/Fh3KmgZr3is26 lHsEeoN6ykohQlhTG1btvy/N0FlrsBFGj6a0xv6oS0SAe/BnRJ5SnS8seDt930ro0wFg tZ960uhPAa0pwdaKJFCz+TlbRjyVviYOsD0q278AdE/eLYX1ZHkWd7J4W4tD1dyFs+HA fD4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=SzIUO9zXtGgmtpq7WsZsJMpwXhzJNVFNKmA+ta699jw=; b=OKbwu8saPdn/Lxt8pZ7m0lgQU7mUOGMHHrtsXs1l0XbgfLK6jx7IXKx0WEObvfUIG1 m3FdJ/Rh4zFq0JhZ/LWnGMjotIWsYc61bBaVMv9a4g/2IFQ4pBNdcg91cge7gEvQk3uW 5hXybdtXUYeE6T7qVqhGaot21Kqo0kzo8k81ItFJjGaCX0GvGYHxrnnjpIe1hAbxh/WD gjIiM+d+Ftq7Vzr88qn97AyRvuqBv3y6/a8L1k13eq+bAXkClRYrzwZ/do8o0GSOYm2z ndY2IqJeuXG6mBdHZZglk51P1+sfYBS/4tvohD7lm/MFx3t6F8NnXEh9xxHnTHsSMJlu BqZg== X-Gm-Message-State: AEkoouuUUdqqeJ+xujD2QG7Psbs+g0pk9pjDwGDJ7nF49kM/jdoj+8tvOLcPb+rWR1V6jPo6QlKgeUNOY3qR5Q== X-Received: by 10.202.224.198 with SMTP id x189mr8279544oig.169.1469417822840; Sun, 24 Jul 2016 20:37:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.20.8 with HTTP; Sun, 24 Jul 2016 20:37:02 -0700 (PDT) In-Reply-To: References: From: Lee D Date: Sun, 24 Jul 2016 23:37:02 -0400 Message-ID: Subject: Re: Questions about writing custom boot loader, Zynq, Zybo To: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 03:37:04 -0000 On Sun, Jul 24, 2016 at 11:43 AM, Thomas Skibo via freebsd-arm < freebsd-arm@freebsd.org> wrote: > > > > > 3. Is there anything special about how the Zynq is configured in > > ps7_init.c? > > Absolutely. ps7_init.c sets up all the clocks and DDR parameters and is > very board specific. This might be why you=E2=80=99re having problems wi= th the > RS232 port. The clock settings may not match the clock values in the dtb= . > I was able to track down my boot hang to the mmc_wait_for_req() function in src/sys/dev/mmc/mmc.c. It gets stuck in an msleep call waiting for a mutex to be released... I think... the call looks like: while ((req->flags & MMC_REQ_DONE) =3D=3D 0) { msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); } It's not spinning in that while loop, it just never returns from msleep(). I'm not sure if this is a timer problem or an MMC driver problem. I've tried setting the Zynq SD controller to the same register values it has when booting normally with u-boot, but to no avail. Does u-boot do any important configuration to the timers or to the SD controller? Suggestions welcome... I'm not sure how to continue debugging this. Thanks, Lee From owner-freebsd-arm@freebsd.org Mon Jul 25 14:05:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96097BA46E1; Mon, 25 Jul 2016 14:05:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F74F16AE; Mon, 25 Jul 2016 14:05:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6PE52Um020787 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Jul 2016 07:05:02 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun , Svatopluk Kraus , freebsd-arch@FreeBSD.org, freebsd-arm@freebsd.org References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> From: Nathan Whitehorn Message-ID: Date: Mon, 25 Jul 2016 07:05:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57961549.4020105@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaqp7NbCWPh2Ab+BkUZZm/pbb6akU/7Rutiv9ygsDsqYQdDj8LiSnsKVToCW/Dc7TNQMww24dN4Wa08iimDR5HHv7edEWKpQko= X-Sonic-ID: C;DnHbx3BS5hGpaJtMTlz00w== M;Ms0oyHBS5hGpaJtMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 14:05:05 -0000 On 07/25/16 06:34, Michal Meloun wrote: > It seems that you accidentally moved this thread to arm@, so I moved him > again to arch@. (Thanks -- I meant it to be both arm@ and arch@, like the other email) > Dne 25.07.2016 v 0:38 Nathan Whitehorn napsal(a): >> >> On 07/24/16 10:51, Michal Meloun wrote: >> >> [snip] >> >>>>>>> For this reason we makes domain key composite, in our model, the >>>>>>> domain key consist of "domain key type" >>>>>>> and "domain key value". This composite key guarantees uniqueness >>>>>>> and it also allows to select proper parser for byte string. >>>>>> Yes, but this solves what is a nonexistant problem by making the >>>>>> system substantially less flexible and more invasive. Which is not >>>>>> a good tradeoff. >>>>>> >>>>> I think that existence of problem is confirmed in the above example . >>>>> Quote from previous paragraph: >>>>> "We could solve this in a number of ways, ... , or adding another >>>>> value (domain type, for example)." >>>>> What can I say more ... >>>> Except that the example you gave *is not an example* of the problem >>>> you are describing. You would only end up with a problem if: >>>> 1) You had interrupts in a GPIO property rather than in an >>>> interrupts property (or equivalent). >>>> 2) *And* you had interrupts on GPIOs in an interrupts property (or >>>> equivalent) >>>> 3) *and* those are encoded differently >>>> 4) *and* the different encodings use the same number of cells >>>> 5) *and* are not otherwise distinguishable >>>> >>>> Does that ever actually happen, in the real world, on any device >>>> tree? You could imagine any kind of messed up thing you want, but we >>>> shouldn't structure APIs around them, especially given that the >>>> current alternative you are proposing has real, concrete problems on >>>> real hardware that actually exists. >>>> >>> Allow me to respond to this issue only. I think that this main >>> issue, everything else looks resolvable for me (or, in worst case, >>> can be converted to MD code). >>> >>> from linux/arch/arm/boot/dts/am335x-evm.dts (it's first file that I'm >>> searched) >>> >>> ---------------------------------------------------------------------------------------------------------------------------- >>> >>> &gpmc { >>> status = "okay"; >>> pinctrl-names = "default"; >>> pinctrl-0 = <&nandflash_pins_s0>; >>> ranges = <0 0 0x08000000 0x1000000>; /* CS0: 16MB for NAND */ >>> nand@0,0 { >>> compatible = "ti,omap2-nand"; >>> reg = <0 0 4>; /* CS0, offset 0, IO size 4 */ >>> interrupt-parent = <&gpmc>; >>> interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ >>> <1 IRQ_TYPE_NONE>; /* termcount */ >>> rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ >>> ---------------------------------------------------------------------------------------------------------------------------- >>> >>> so we have >>> rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ >>> and >>> interrupt-parent = <&gpmc>; >>> interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ >>> >>> >>> --- or --- >>> from linux/arch/arm/boot/dts/exynos5420-peach-pit.dts >>> >>> max98090: codec@10 { >>> compatible = "maxim,max98090"; >>> reg = <0x10>; >>> interrupts = <2 0>; >>> interrupt-parent = <&gpx0>; >>> pinctrl-names = "default"; >>> and >>> sleep-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>; >>> >>> also, in this case, first cell in 'interrupts' property have >>> different meaning that second cell in 'sleep-gpio'. >>> (on exynos, not all gpios supports interrrupts) >>> >>> >>> In general, binding for 'interrupts ' and '-gpios ' are >>> different, but can have same size . >> Thanks so much for the concrete example! This is very helpful. Three >> questions: >> >> 1. Are the drivers for these devices actually taking interrupts on the >> lines defined in the *-gpios property? It seems weird to me that there >> would be interrupts on GPIOs and, simultaneously, implicit interrupts >> on other GPIOs. It looks like the things on the *-gpios properties are >> things you set rather than things you would request an interrupt on >> (sleep for the second case, a wait pin in the first). > Yes, interrupts on GPIO pins are relatively widely used. For example, > SDHCI driver uses this for handling of card detect pin. Moreover, the > SDHCI driver have zero knowledge about given GPIO pin > interrupt capabilities. He simply tries to allocate interruption, and > when it fails, it switches to a pooling mode. > Other usage is HDMI cable/monitor detect input, USB VBUS pin or so... That wasn't my question. Are these particular device drivers allocating interrupts both on the GPIOs in their "interrupts" property (which are entirely GPIOs in this example) *and* on the GPIOs listed as resources but not listed as interrupts? If they are, then you need a switching mechanism, but that seems pretty unlikely given the names of the non-interrupt GPIOs (they look like outputs). It would also be a somewhat deranged way to set up a device tree -- not that that rules it out or anything. >> 2. What is the different meaning? I assumed the second cell in both >> cases is the GPIO pin number, because anything else would be crazy. > No, on exynos (if memory serves me), not all GPIOs have interrupt > capability, and they are numbered independently. > But again, please note that both *-gpios and interrupts properties are > defined independently, they can be formatted differently even within a > single controller. Which is totally fine. The question is if you need to set up interrupts on the GPIOs both the "interrupts" and non-interrupts properties, which is easy enough to handle, but kind of weird. > >> 3. What on earth is IRQ_TYPE_NONE? That's an OpenPIC flag that just >> disables the interrupt entirely. Why would you want to configure >> things that way? > In Linux DT, the IRQ_TYPE_NONE is equivalent of our > pair -> don't change > actual interrupt configuration, i want to reuse default or already > preset configuration (from uboot for example). It's not a Linux thing, it's from the OpenPIC spec. Probably it just means the interrupt isn't configurable, no that it matters. > >> (#1 is the only one that really matters here; the rest are personal >> curiosity) >> >> If the answer to (1) is "yes", there would be a good case for adding >> something like a ofw_bus_map_gpio_as_intr() or the like that takes the >> same arguments as ofw_bus_map_intr() and propagates them to the >> control in some way but with a flag. It's an easy extension and this >> is the reason the function has "ofw" in the name. My one qualm about >> that is that there is no guarantee that a GPIO controller can actually >> provide interrupts on a random GPIO (nor is it clear that that is >> actually what is wanted here). That qualm applies to both APIs, of >> course, and I still don't see a rationale for throwing away the >> existing code even if (1) is true. > But current INTRNG is no longer OFW centric, it can easily handle any > other 'configuration source'. We removed it (from INTRNG core) at > r297539, at request from MIPS folks. > But again, all what I want in this area is (for me) simple change of > your ofw_bus_map_intr() method to something like: > > enum intr_map_data_type { > INTR_MAP_DATA_OFW, > INTR_MAP_DATA_GPIO, > ... > }; > > int > bus_map_intr(device_t dev, enum intr_map_data_type type, uintptr_t > pic_id, void *config_data, int config_size) > > Please, don't take current implementation of bus_map_intr() in account. > From my current point of view, the method is badly named and his name > doesn't reflect its functionality. Fair enough. My core issue is basically that this code connects interrupts to the newbus hierarchy, which simply doesn't work in a lot of cases when the newbus hierarchy doesn't match the interrupt one, which is quite common (see my other mail). Unfortunately, that's a fundamental architectural issue with r301453 and so I'm not sure how to proceed here. The current mechanism I was discussing is not OFW-centric either, although it is true that the only current mapping method (ofw_bus_map_intr()) is (though it can be abused for non-OFW data sources successfully), but you could easily add an acpi_bus_map_intr() or whatever that takes different data and connects in the MD interrupt code. I have no objections to that at all. I'm still confused about how your GPIO interrupts work (above), but that's a detail. Is that something that you think would be workable? I'd be more than happy to write some prototype code. -Nathan > > Michal >> I've changed the mailing list here since the SVN list really isn't the >> best place. For people who want context and are seeing this for the >> first time, please see the other email I just sent. >> -Nathan From owner-freebsd-arm@freebsd.org Mon Jul 25 16:18:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFEC5BA4B37 for ; Mon, 25 Jul 2016 16:18:19 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.chatusa.com (br1.CN84in.chatusa.com [69.59.192.140]) (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 AD02113A5; Mon, 25 Jul 2016 16:18:18 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.ChatUSA.com (localhost [127.0.0.1]) by pdx.rh.CN85.chatusa.com (8.13.3/8.13.3) with ESMTP id u6PGHsKl013244; Mon, 25 Jul 2016 09:17:54 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3/Submit) id u6PGHfAG013243; Mon, 25 Jul 2016 09:17:41 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201607251617.u6PGHfAG013243@pdx.rh.CN85.ChatUSA.com> Subject: Re: rpi2 as wireless router In-Reply-To: <20160725022255.GA6128@debian-macbookpro> To: Herminio Hernandez Jr Date: Mon, 25 Jul 2016 09:17:41 -0700 (PDT) CC: Andriy Voskoboinyk , Adrian Chadd , "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 16:18:20 -0000 Is there a switch running STP between the 2 boxes? More speicifically is the RPI plugged into a switch with STP on the port it is plugged into? There is about a 30+ sec time AFTER link comes up and before the switch well accept any packets on the port due to the port entering STP blocking state after any link loss. > On 07/24, Andriy Voskoboinyk wrote: > > Thu, 21 Jul 2016 06:56:22 +0300 ???? ???????? Herminio Hernandez Jr. > > : > > > > Another idea: try to add > > hw.usb.urtwn.enable_11n="0" > > into /boot/loader.conf (and reboot). > > (described as "download speed" fix in > > https://forums.freebsd.org/threads/48737/ - > > but may help here too). > > > The same issue. Debian is not seeing the DHCP Offer from freebsd. > > > No same issue. I am willing to help in any way I can. I can send you the > > > pcap files I made. > > > > > > Sent from my iPhone > > > > > > > On Jul 20, 2016, at 8:04 PM, Adrian Chadd > > > > wrote: > > > > > > > > Hi, > > > > > > > > Ok. We'll have to set up a test environment here to see what's going > > > > on, complete with some packet sniffing. > > > > > > > > Question - if you configure up hostap to be open/no authentication, > > > > does it all work? > > > > > > > > > > > > -a -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Mon Jul 25 16:32:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DDA2BA440C for ; Mon, 25 Jul 2016 16:32:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05CBA12AA for ; Mon, 25 Jul 2016 16:32:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id f6so109809245ith.0 for ; Mon, 25 Jul 2016 09:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QKCY80C8L+zXbQcVDxmPxDiW9bDkRFRvzcNBD1pN9Q4=; b=gWAo/Ot49q7I8eBMHdPZQIyK/1jCV2QHM2YnJ7Umiz1HMfuDhFCoXxnon39/4kJ6M5 +qG3cRl/vkO6jf6VC78lkh+qeGtExPLv/AR3sU/Dq7klYsF7UDNPh1mTQWbnJjl4CImA G1ZQ9SwatXhW1G1qlNXUVXqMZjOS5eqauJ4fmtjCOVLdy8gA8pHz0TXytK73WTy7QO7E gyJlwCRWXbNo8me8PVdN5mXUwCHyXskxp9RFTNUq+uFXlH9Olu2g1n2FwChZ/Z4RZyaq nol4rxcVmeAPt4rMHh+guel1nAG4tRAhxVJZDs2YjhmckWRHF3uvgvhhiV9w6aC3HR33 qAfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QKCY80C8L+zXbQcVDxmPxDiW9bDkRFRvzcNBD1pN9Q4=; b=muOyF4RxCe0fQTN7lnt02T2KwWbtwT2Iz3832VNum0PH1NWgctLRFaHRDGNmacwXiV BrO8VHByMJyuosV2D3o/02osV9y1RXNv7L3aYa08HBlSiHPBCNWfpYDrv6Kced7J0EqK RbjXyXvSvY+QtNsOqhdjxwCRCTq4vksVbzF24/kNpjk3b0ie7Wjyjmd+z0LOLO+yNzcZ 5QvVAK+Jfjr0/Pe8uU8On4IC5t052ynYauv1KO6EaDzs2o6KQZMCsh9tEVBo2JwGtH40 L3tMJ2HnKx8Fny6Nf8BfBCvLzhtK0m0yuCv02kCQGZ2KDhG1Ft84LnXiwgkfrFverLbT Bw1Q== X-Gm-Message-State: ALyK8tKzd05mYTrRZsmmluLdvT24ERnTw82ySTAqNPRG1JNu1Zgb77tDQwSbhZVsYmJbSUVQpNt4mm7X/rgs5g== X-Received: by 10.36.66.2 with SMTP id i2mr40710179itb.53.1469464345219; Mon, 25 Jul 2016 09:32:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Mon, 25 Jul 2016 09:32:24 -0700 (PDT) X-Originating-IP: [50.205.115.50] In-Reply-To: References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> From: Warner Losh Date: Mon, 25 Jul 2016 10:32:24 -0600 X-Google-Sender-Auth: puGqSw5KkQDAcsGN8wUg4sd6mPw Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 16:32:26 -0000 On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn wrote: > That wasn't my question. Are these particular device drivers allocating > interrupts both on the GPIOs in their "interrupts" property (which are > entirely GPIOs in this example) *and* on the GPIOs listed as resources but > not listed as interrupts? If they are, then you need a switching mechanism, > but that seems pretty unlikely given the names of the non-interrupt GPIOs > (they look like outputs). It would also be a somewhat deranged way to set up > a device tree -- not that that rules it out or anything. On Atmel, there's a situation that this covers, I think. The MCI device has an interrupt in the core: mmc0: mmc@fffa8000 { compatible = "atmel,hsmci"; reg = <0xfffa8000 0x600>; interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>; #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; clocks = <&mci0_clk>; clock-names = "mci_clk"; status = "disabled"; }; and in other places wires in GPIO interrupts for things like card eject / insertion. mmc0: mmc@f0008000 { pinctrl-0 = < &pinctrl_board_mmc0 &pinctrl_mmc0_slot0_clk_cmd_dat0 &pinctrl_mmc0_slot0_dat1_3>; status = "okay"; slot@0 { reg = <0>; bus-width = <4>; cd-gpios = <&pioD 15 GPIO_ACTIVE_HIGH>; }; }; an interrupt is registered on the cd-gpios pin for when the card changes. At least in linux, FreeBSD doesn't (yet) implement this, but will someday if I get back to the armv6 atmel work I started (see at91-cosino.dts for example, there's others). I think this is an example of what you are asking about, or did I get lost in the twisty maze of conversation zigs and zags... Warner From owner-freebsd-arm@freebsd.org Mon Jul 25 16:45:20 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A80A7BA464B for ; Mon, 25 Jul 2016 16:45:20 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm39-vm8.bullet.mail.bf1.yahoo.com (nm39-vm8.bullet.mail.bf1.yahoo.com [72.30.239.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60E4B17C2 for ; Mon, 25 Jul 2016 16:45:19 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1469464946; bh=RODsG6RT9e5EiViZey5fb769g+k8Ux78eR1UpgkdVTA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=LPWWQ/Lr/+vERRc7om5rlfVfasMngyNdgggCB/u1WxiDVGjH16oIkV0z13WR6LkaHiK4QZ4HdIHhWSXJCsrVwLg7wQ5K6GJfUpOSNiY9oJ58VGuFTAP021TZ7ztmzj5X0V4SpdKCZuJbe0v3uYixRjDeMy/NCAhHc2RhiDJ3d5nxkNMZEMa08zjFch6SgqozOtaIlE1aTFiq+GII3GKpdpFCUN9MEJiDgik5K6q3m8BSiYI9QxhZfrdc6QrIslAEjt87qFqn4zYO53dScp8l2HHKe1TOIf9AtVoOsXJmfIKoG78EQYFk/DMCjpL4XmcIAhfJK8CaJ9qx1MrJxPTaJw== Received: from [98.139.215.141] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2016 16:42:26 -0000 Received: from [98.139.211.203] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2016 16:42:26 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 25 Jul 2016 16:42:26 -0000 X-Yahoo-Newman-Id: 868352.13010.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fVTltIgVM1nt1KnivCVIS3wMgJ5T_8nrCMd7Hal6BF03hBv xgSRducQIlOOWLSfxtfzB6sVyVJ4EC4vUk8ppNLVjEC7__qtgor8lM2vbiIX KNcyEhXQUqp6AgEChVcN42iOFDSVyFPjsyWyCFnp2m68sYhOeIW3e7zC1MUM A7jWTjHMDAZOmnf1lS2pAafdlaCEePZ3Byhd9qiOqKgPRXVqrZEp06V2kfIN Z0siV.HZpF0se75G9ChxoFKPUBAOYPOnwEaiycTNwXrd7tXXGiNjoQCofQJG JwOadLb33ewwAiouAtP5UVFR6yziLUVXo7S7.9qS0vOV9H_9Bzrq9fhtBHEv z59PcuY5Oo.VlIZyTwHRy6RcHb4P7mgzuCJ_AIs6XbhGCZF_updCEE7rV9w_ gc04DdWexRiHX9Vs0sGaxIiAnr8Hl9x4hJ4DBAcIvdyG5T8Gb1uu7v_KGbph oreAF8TEjYCmkzQIovAhutKduuN.uh_jxEMY42q70SepXDoukEX07z1s3a8u CsKDi4oMYqw_TQLbGV7jQvLZo_OkCDqpsSvCo3Uo6rZUNEt04p5wVW6Cq42c YWLiWD33o X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Questions about writing custom boot loader, Zynq, Zybo From: Thomas Skibo In-Reply-To: Date: Mon, 25 Jul 2016 09:42:24 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lee D X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 16:45:20 -0000 > On Jul 24, 2016, at 3:25 PM, Lee D wrote: >=20 > Thanks for the tips. The RS232 issue was simple. Xilinx (or possibly = Digilent) changed the default clock for the serial port from 50MHz to = 100MHz. I made the correction in the DTS file and now the baud rate is = correct. I hadn=E2=80=99t noticed they changed it. My u-boot still uses the = 50Mhz so it matches the DTS file. What really ought to happen is the slcr driver should determine the = frequency of all the clocks derived from ps_clk so the only thing the = DTS file needs to provide is the ps_clk frequency. I=E2=80=99ll have to = do that anyway if we move over to using GNU DTS files. >=20 > Do you know if passing a boot params structure in R0 is necessary for = the kernel to boot? =20 >=20 > I still can't seem to get past that timer message. This is what I've = done: >=20 > 1. Made sure I am working with a bare default Zybo config generated in = Vivado 2016.2 >=20 > 2. compared my ps_init.[ch] to the one you pointed me to. There were = no significant differences except for the RS232 clock rate. I had some = MIO pins configured, and my DRAM timings were different. my DRAM works = fine with standalone apps so I assume that was a tweak made by Digilent = and not an issue. >=20 > 3. added printf's to inittimecounter() in src/sys/kern/kern_tc.c. It = is clear that it completes normally. Also the timer appears to be = running. =20 >=20 > However that function is part of the kernel init sequence (SYSINIT = macro), so I don't know what is getting called next.=20 >=20 > 4. I removed the ehci device from the DTS, and commented out all USB = related entries in the zybo kernel config file. Still it freezes after = that timer message. So probably not USB related. >=20 > 5. Checked to make sure that the USB3320 chip is not being held in = reset by the GPIO line. >=20 > My next steps are: >=20 > 1. keep digging through the kernel and placing printfs to pinpoint = where it is failing. >=20 > 2. try the ps_init.[ch] files you showed me in my project, even though = they shouldn't make any difference. >=20 > 3. try passing a boot params structure in r0.=20 >=20 > Thanks again for pointing me to the original ps_init files, that was = very helpful to be able to see those. >=20 > Lee >=20 =E2=80=94=E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Mon Jul 25 16:48:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C15FCBA46BF; Mon, 25 Jul 2016 16:48:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8EDD189C; Mon, 25 Jul 2016 16:48:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6PGmOF8026555 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Jul 2016 09:48:25 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Warner Losh References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> Cc: Michal Meloun , Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" From: Nathan Whitehorn Message-ID: Date: Mon, 25 Jul 2016 09:48:24 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaSaSSOA20ymKx7VTUGGfy3r3xuPzV4lk/S++AVRaPyu3KE3BCJ3ljiLPFGLXxQ8TdHwi6TjuvbDozWsZQRiTuTHu0iM9dKFmc= X-Sonic-ID: C;6riHmodS5hG61ZtMTlz00w== M;1gbQmodS5hG61ZtMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 16:48:33 -0000 On 07/25/16 09:32, Warner Losh wrote: > On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn > wrote: >> That wasn't my question. Are these particular device drivers allocating >> interrupts both on the GPIOs in their "interrupts" property (which are >> entirely GPIOs in this example) *and* on the GPIOs listed as resources but >> not listed as interrupts? If they are, then you need a switching mechanism, >> but that seems pretty unlikely given the names of the non-interrupt GPIOs >> (they look like outputs). It would also be a somewhat deranged way to set up >> a device tree -- not that that rules it out or anything. > On Atmel, there's a situation that this covers, I think. > > The MCI device has an interrupt in the core: > > mmc0: mmc@fffa8000 { > compatible = "atmel,hsmci"; > reg = <0xfffa8000 0x600>; > interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>; > #address-cells = <1>; > #size-cells = <0>; > pinctrl-names = "default"; > clocks = <&mci0_clk>; > clock-names = "mci_clk"; > status = "disabled"; > }; > > and in other places wires in GPIO interrupts for things like card > eject / insertion. > > mmc0: mmc@f0008000 { > pinctrl-0 = < > &pinctrl_board_mmc0 > &pinctrl_mmc0_slot0_clk_cmd_dat0 > &pinctrl_mmc0_slot0_dat1_3>; > status = "okay"; > slot@0 { > reg = <0>; > bus-width = <4>; > cd-gpios = <&pioD 15 GPIO_ACTIVE_HIGH>; > }; > }; > > an interrupt is registered on the cd-gpios pin for when the card changes. At > least in linux, FreeBSD doesn't (yet) implement this, but will someday if I get > back to the armv6 atmel work I started (see at91-cosino.dts for example, there's > others). > > I think this is an example of what you are asking about, or did I get > lost in the > twisty maze of conversation zigs and zags... > > Warner > Where we would run into (minor) problems is if the interrupt parent for the first mmc0 is the GPIO controller. More generally, if &pioD has interrupt children specified in some way that is not a tuple somewhere else in the tree then you would have to have methods to parse both interrupt specifiers as-obtained-from-interrupts-properties (or equivalent) and specifiers as-obtained-from-gpio-properties. If the tree picks one format and sticks with it, you can get away with just the one. Glancing through the DTS source for this board, that doesn't appear to be the case and the property formatting is uniform, but I might have missed something in one of the many #includes. As a general point, GPIO weirdness would be easy enough case to handle if it did come up (add some mapping method, as above) that I think we shouldn't worry too much about it from an architectural point of view. If a board appears that is set up this way, we can roll with the punches at that point and add whatever small amount of shim code that is required. It would be annoyance, sure, but not a real complication. -Nathan From owner-freebsd-arm@freebsd.org Mon Jul 25 18:21:24 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A58C2B9CA93 for ; Mon, 25 Jul 2016 18:21:24 +0000 (UTC) (envelope-from scoopsnsmiles@hotmail.com) Received: from BLU004-OMC3S15.hotmail.com (blu004-omc3s15.hotmail.com [65.55.116.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7241C1A38 for ; Mon, 25 Jul 2016 18:21:24 +0000 (UTC) (envelope-from scoopsnsmiles@hotmail.com) Received: from BLU436-SMTP30 ([65.55.116.73]) by BLU004-OMC3S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 25 Jul 2016 11:20:17 -0700 X-TMN: [cm7bip1XDwMPF9AIFgCkKuL0OuPHaXBV] X-Originating-Email: [scoopsnsmiles@hotmail.com] Message-ID: From: "Apple Support " Subject: Action Required: Verify your Apple ID To: freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Mon, 25 Jul 2016 19:20:14 +0100 X-Antivirus: avast! (VPS 160725-0, 07/25/2016), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 25 Jul 2016 18:20:15.0089 (UTC) FILETIME=[30A7EE10:01D1E6A1] Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 18:21:24 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Dear Apple ID User, Verify this email address belongs to you, click the link below and the= n sign in using your Apple ID and password and update your Billing det= ails. Verify now > Why you received this email. Apple requires verification whenever an email address is selected as a= n Apple ID. Your email cannot be used until you verify it. Failure to verify and update your billing details might lead to closur= e of your Apple ID. Apple Support Apple ID | Support | Privacy Policy Copyright =A9 2016 Apple Inc. 1 Infinite Loop, Cupertino, CA 95014, United States? All Rights Reserved. From owner-freebsd-arm@freebsd.org Mon Jul 25 22:02:25 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AADB1BA5787 for ; Mon, 25 Jul 2016 22:02:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E443129A for ; Mon, 25 Jul 2016 22:02:24 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u6PLrpOF017836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 23:53:57 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u6PLriOl014744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jul 2016 23:53:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u6PLrih5095068; Mon, 25 Jul 2016 23:53:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u6PLrh3v095067; Mon, 25 Jul 2016 23:53:43 +0200 (CEST) (envelope-from ticso) Date: Mon, 25 Jul 2016 23:53:43 +0200 From: Bernd Walter To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 Message-ID: <20160725215343.GA95042@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 22:02:25 -0000 On Mon, Jul 11, 2016 at 07:06:40PM -0500, Karl Denninger wrote: > On 7/11/2016 18:22, Herbert J. Skuhra wrote: > > On 11/07/16 22:58, Bernd Walter wrote: > >> Sure it is not the board, powersupply, cable or switchport? > >> Check if the red power LED on the Raspberry is on - it goes off under > >> a certain supply voltage, although the board contiues to work. > > Hmm, the LEDs (red/green) on the RPI2 should work on FreeBSD? > > > > I have two RPIs 2 (and one RPI3) and three different power supplies and > > the red LED is only on for a few seconds after connecting the power > > cable. The LEDs are working permanently when I run Arch Linux ARM. > That's the default, yes. The red LED goes out when the kernel loads. I've just tested it myself. On all tested (7) Pi1 it stayed on. On a Pi2 however it goes off and it is unlikely a power thing. That is with FreeBSD-11-ALPHA6 image. Will do some variable voltage tests to see if this is static or not. > However, I have a little daemon process that blinks the green one, so I > know it's running, and it works fine... -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Jul 25 23:13:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD9EDBA49BF for ; Mon, 25 Jul 2016 23:13:19 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (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 93ED31D3C; Mon, 25 Jul 2016 23:13:19 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id EA55E145; Mon, 25 Jul 2016 19:03:23 -0400 (EDT) From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Using packaged base with FreeBSD/arm Date: Mon, 25 Jul 2016 19:03:23 -0400 Message-Id: <2A1CEA39-A263-451C-A5FC-F8E223A22746@gromit.dlib.vt.edu> Cc: Glen Barber To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 23:13:19 -0000 A recent thread on freebsd-arm concerned how best to upgrade FreeBSD/arm = systems such as Raspberry Pi, BeagleBone Black, etc. via cross-building = on a fast host (e.g., FreeBSD/amd64 system). In particular, how do you = actually update the SD card on the FreeBSD/arm system without physically = having to move the SD card to the cross-build machine? Various methods = such as using rsync, cpdup, NFS, etc. proved problematic due to handling = of special file system flags or the fact that a rsync/cpdup isn't doing = exactly the same thing as installworld/installkernel appears to do. So, with that in mind, I decided over the weekend to give the new = packaging of base a try as a method of updating my 11-STABLE FreeBSD/arm = systems. I'm happy to report that it went very well! I now have the = build system I use to cross-build packages from ports for my FreeBSD/arm = systems also building base OS packages. I have managed to bootstrap a = Raspberry Pi B+, Raspberry Pi 2, and a BeagleBone Black with = FreeBSD-base packages. What's better is that this is without having to = move SD cards or wait for days as the system grinds through native = builds. :-) Congratulations to the PkgBase people! For those who might want to try this, I basically adapted my OS = cross-building environment (using the "mk" script from = https://wiki.freebsd.org/FreeBSD/arm/crossbuild) so that it also built a = PkgBase repo: --- mk.orig 2016-07-25 16:31:28.723973000 -0400 +++ mk 2016-07-24 20:43:45.278344000 -0400 @@ -9,7 +9,7 @@ # First set all tweakable variables to default values before loading # config/mk.conf which can override any of these defaults. -mk_arch=3D"armv6hf" +mk_arch=3D"armv6" mk_insdir=3D"$(pwd)/nfsroot" mk_jobs=3D"$(sysctl -n hw.ncpu)" mk_kernel=3D"GENERIC" @@ -19,6 +19,7 @@ mk_objdir=3D"$(pwd)/obj" mk_srcconf=3D"$(pwd)/config/src.conf" mk_srcdir=3D"$(pwd)/src" +mk_repodir=3D"$(pwd)/repo" mk_ubldraddr=3D"0x0" # If making a target that requires root privs, automatically add sudo. @@ -49,6 +50,8 @@ "__MAKE_CONF=3D${mk_makeconf}" \ "srcconf=3D${mk_srcconf}" \ "KERNCONF=3D${mk_kernel}" \ + "NO_INSTALLEXTRAKERNELS=3Dno" \ + "REPODIR=3D${mk_repodir}" \ "UBLDR_LOADADDR=3D${mk_ubldraddr}" \ ${mk_mkargs} \ "$@" I added the "NO_INSTALLEXTRAKERNELS=3Dno" because I want to build kernel = packages for each of the different ARM systems I have. For that reason, = I have this line in my "config/mk.conf" file: mk_kernel=3D"VIRT BEAGLEBONE RPI-B RPI2" I placed VIRT as the first kernel listed on purpose. I want it to be = the default one. To build my PkgBase repo, I have this script: #!/bin/sh mk buildworld mk buildkernel mk packages After that runs, I have a "FreeBSD:11:armv6" repo directory hierarchy in = my project "repo" directory (definable via mk_repodir in = config/mk.conf). I found the REPODIR variable by looking through the = build system Makefiles. I don't know whether this is the canonical way = to define where the repository lives, but it appears to work. It was then a matter of following the PkgBase project Wiki page = (https://wiki.freebsd.org/PkgBase) to serve this repository to my = FreeBSD/arm systems, and to add it as a "FreeBSD-base" repository to = each of them. I bootstrapped the systems using the PkgBase = instructions. Note that for the kernel I installed only the kernel package appropriate = for the target system's ARM board. So, on the BeagleBone Black system I = did a "pkg install FreeBSD-kernel-beaglebone" to install the BeagleBone = Black kernel package. The big wrinkle here is that it installs it to = /boot/kernel.KERNCONF, where "KERNCONF" is the kernel configuration file = name. So, in the case of my BeagleBone Black it installed the kernel = files to the /boot/kernel.BEAGLEBONE directory. So, in order to boot = successfully, I had to symlink /boot/kernel to /boot/kernel.BEAGLEBONE. As suggested by the PkgBase Wiki, I ran mergemaster after bootstrapping. = Unfortunately, I had a local /etc/src.conf that strips out a bunch of = components, and so mergemaster got rid of some things it probably should = not have (mainly in /etc/rc.d). I guess src.conf is not really supposed = to be used with PkgBase (i.e., the whole idea is not to install the = FreeBSD-tests package rather than exclude tests via "WITHOUT_TESTS=3Dyes" = in /etc/src.conf). When doing this on my other ARM systems I moved away = /etc/src.conf before running mergemaster. In my case, the initial bootstrap installed 400 packages + 1 package for = the appropriate kernel. I don't know whether this is an appropriate = number: I was expecting higher, as I recall a recent thread on = freebsd-current when a CFT went out for packaging base that stated there = were over 700 packages currently. There did appear to be a big = catch-all package, FreeBSD-runtime, that seemed to contain most of the = system binaries (/bin, /sbin, /usr/bin, /usr/sbin, etc.), and so maybe = the 700+ packages had that split apart into many more packages. I was nice that debug files could easily be removed via "pkg delete -g = 'FreeBSD-*-debug'" or that profile libraries could be expunged = similarly. Having bootstrapped the system, I'm not entirely sure how = granular updates are. I know that I will update via "pkg upgrade" but = upon what basis does pkg decide a FreeBSD-base package has been updated? = Is it the pkg version? If so, I know I can always force an upgrade = (re-installation of a package that is "new" but has the same version) = via "pkg upgrade -f", so I'm not too worried. (It's not clear to me how = -STABLE packages get numbered.) Anyway, I'm going to persist with this method of keeping my FreeBSD/arm = systems up to date. It has the big advantage of allowing me to offload = the heavy lifting onto my powerful build server and still be able to = update easily from the ARM client systems. This looks very promising. My next task is to figure out how I can get "mk packages" to sign the = repo with my own key... Cheers, Paul.= From owner-freebsd-arm@freebsd.org Tue Jul 26 04:24:55 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7052EBA56C6 for ; Tue, 26 Jul 2016 04:24:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F6A517A9 for ; Tue, 26 Jul 2016 04:24:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id q83so193999718iod.1 for ; Mon, 25 Jul 2016 21:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WMB4q8qs9epdEO2K9XxEQLmKp/HlF7veu4NSwCqgS3U=; b=IAoGPYCX8NxORdQCCFHkalOvVRzQWsyBHLPQ5yU+x3cWuGc8MSZTpvkngNgM/5csN8 jypYrW3VC1bx0ZCftA7mKQlzdLxnwrNnmPtmzK+Eoa/vRq0leTga9Wp8CzvjvBl02/iN faocJAY0Wiqu+tGl+MyCphRW90j30AuWU3I1WMoMg0DrPr/lhnHmvIr8Egp1ZxDZwpfN Buf2N/SD4CNuJpSMsy4uxzO4OVBuyKSSqo+VBisLZxPqE4pJI6tQZLOvzZfLrcGVuh2J I77V8quAkfKFhZx+8ngKofXDpWEymdSGOhhWzYDW+L5JgMpRGBi14/4F86to2jdoh9OP QE4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WMB4q8qs9epdEO2K9XxEQLmKp/HlF7veu4NSwCqgS3U=; b=jzW4z+iKQr87UUchzGdEe6WMeoVXVEuCQKQjektKqRcpBTNK7Og2wlkGzC1v8GSsGE gtUjEIYEvgW2fI+XrOmdSviAfTFf1Fz7x/QL2tHua95mIbK/9FSjcFbVOOLsTgOKnlEu awuGJcINIoXI9ZK/tfRbI+crvg9ThGjXl14fPpxG61ej81NrWujTS5Pb62WRtPp8U8gX s24VqrS7Kw69u6+PqjSp/9ubvl1N3V5AHFJFf5gAh9W5oEWJfzwCSMpeRthrNwNb6OJF kKlcxQ81IMqRw7WrQ3JpPp7zNNqvxGwFqaGYM2KNUcbWt7O9zHYN6TH21J7zGHsbjT9l 4mQw== X-Gm-Message-State: AEkoousBZb6GFJ3sRw7iCvqt0bQv4remD2gY8AMDhqV1eKkMIDQw3RrVj3Ra17AYIF0U70otzANlrtfSX7mY1w== X-Received: by 10.107.133.93 with SMTP id h90mr23629391iod.16.1469507094415; Mon, 25 Jul 2016 21:24:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Mon, 25 Jul 2016 21:24:53 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> From: Warner Losh Date: Mon, 25 Jul 2016 22:24:53 -0600 X-Google-Sender-Auth: kzVHCycSi51vnhDA-XUlIEAYMX0 Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 04:24:55 -0000 On Mon, Jul 25, 2016 at 10:48 AM, Nathan Whitehorn wrote: > > > On 07/25/16 09:32, Warner Losh wrote: >> >> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn >> wrote: >>> >>> That wasn't my question. Are these particular device drivers allocating >>> interrupts both on the GPIOs in their "interrupts" property (which are >>> entirely GPIOs in this example) *and* on the GPIOs listed as resources >>> but >>> not listed as interrupts? If they are, then you need a switching >>> mechanism, >>> but that seems pretty unlikely given the names of the non-interrupt GPIOs >>> (they look like outputs). It would also be a somewhat deranged way to set >>> up >>> a device tree -- not that that rules it out or anything. >> >> On Atmel, there's a situation that this covers, I think. >> >> The MCI device has an interrupt in the core: >> >> mmc0: mmc@fffa8000 { >> compatible = "atmel,hsmci"; >> reg = <0xfffa8000 0x600>; >> interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>; >> #address-cells = <1>; >> #size-cells = <0>; >> pinctrl-names = "default"; >> clocks = <&mci0_clk>; >> clock-names = "mci_clk"; >> status = "disabled"; >> }; >> >> and in other places wires in GPIO interrupts for things like card >> eject / insertion. >> >> mmc0: mmc@f0008000 { >> pinctrl-0 = < >> &pinctrl_board_mmc0 >> &pinctrl_mmc0_slot0_clk_cmd_dat0 >> &pinctrl_mmc0_slot0_dat1_3>; >> status = "okay"; >> slot@0 { >> reg = <0>; >> bus-width = <4>; >> cd-gpios = <&pioD 15 >> GPIO_ACTIVE_HIGH>; >> }; >> }; >> >> an interrupt is registered on the cd-gpios pin for when the card changes. >> At >> least in linux, FreeBSD doesn't (yet) implement this, but will someday if >> I get >> back to the armv6 atmel work I started (see at91-cosino.dts for example, >> there's >> others). >> >> I think this is an example of what you are asking about, or did I get >> lost in the >> twisty maze of conversation zigs and zags... >> >> Warner >> > > Where we would run into (minor) problems is if the interrupt parent for the > first mmc0 is the GPIO controller. More generally, if &pioD has interrupt > children specified in some way that is not a > tuple somewhere else in the tree then you would have to have methods to > parse both interrupt specifiers as-obtained-from-interrupts-properties (or > equivalent) and specifiers as-obtained-from-gpio-properties. If the tree > picks one format and sticks with it, you can get away with just the one. > Glancing through the DTS source for this board, that doesn't appear to be > the case and the property formatting is uniform, but I might have missed > something in one of the many #includes. Interrupts and GPIO specifiers are different in subtle ways. The interrupt parent for mmc0 is an AIC, which is also the ultimate parent of the GPIO controller. But the properties for the GPIO pins that act as interrupts and the interrupt specifiers are different. > As a general point, GPIO weirdness would be easy enough case to handle if it > did come up (add some mapping method, as above) that I think we shouldn't > worry too much about it from an architectural point of view. If a board > appears that is set up this way, we can roll with the punches at that point > and add whatever small amount of shim code that is required. It would be > annoyance, sure, but not a real complication. I suspect that either I don't understand the issue, or we'll have such boards very quickly. The Atmel design is fairly clean in comparison to other franken-horrors I've seen... Warner From owner-freebsd-arm@freebsd.org Tue Jul 26 05:29:15 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84B08BA528C for ; Tue, 26 Jul 2016 05:29:15 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50F051563 for ; Tue, 26 Jul 2016 05:29:15 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x22f.google.com with SMTP id x72so71540899pfd.2 for ; Mon, 25 Jul 2016 22:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to; bh=72QqPwHYZcHCNlwHVvCE7XBUArT9+b4xEgH1L4l+B44=; b=DKwKCUGwEFAYFJsWfrrDg74iTP8xXUNx0ssVcG2liw59rSN2I7oxPbmR+P2QjmaOKk 6+FcjiHO6iTdIzG8lEjYH+LtriFs6DyXgD4XW8oPGgZ8rbECWJcEoWBTKBtZ43Pt46CO 0oDmFPvKBeleWe5VF0upSY6rrdW5nNCMn4rq+qRuvXqOp/lgXgWcDZHjdiIjjxRBVDNW PDv+C13zU+ttB/TuKnfQ0XEcvhC0qkUvpaRluu/f6cW5CbOSm9025tgslUc0oRh4iCYN rc/GCucQqLIIY1eiHbW9UhqhmSThkfZRzFHPdVeFPoxaRtlk1vs2mhQQPGV5nTQF1jbu KflQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to; bh=72QqPwHYZcHCNlwHVvCE7XBUArT9+b4xEgH1L4l+B44=; b=PDdo4PyNROtiLAy/hXwBpIf8lcgod0FzCXa6euQXOUUHfckhAXVjT+SASi9b749tBi XDnCRJn5ia6w7+/GvwzyTnljopZ9Fk2f47t8NUgCRQwMVJGCBwMotwFJbS/Wlm7qLjXv EHQXuRJ4fge0ZmYzQZ8nZm4kMBIQ3wl6cDTM6y4mDacfC3KYMMysxKm+nL6XiZBqpeHo ptNU6WxAyOKg5u/zGktBG+aM07z1caUY9/jeXiXfAAsrZd0tCg5RXg8ZIvxYupkWvMLg 9dLyJcYuxZkQkkU6KLAzm8cuvFoGfZzFo36EqWAVeuKd445N3UdtkmFtCEgIt6e4xmEf tj9w== X-Gm-Message-State: AEkoouv83TMTaLcc7cwDBbAMf16Dz8xqOmaiX281cBA3PiJlLi5Wd3gpAfFlVMTxwASKcg== X-Received: by 10.98.22.212 with SMTP id 203mr36013362pfw.74.1469510954698; Mon, 25 Jul 2016 22:29:14 -0700 (PDT) Received: from [127.0.0.1] (69-11-46-165.yktn.hsdb.sasknet.sk.ca. [69.11.46.165]) by smtp.gmail.com with ESMTPSA id z10sm43964847pff.95.2016.07.25.22.29.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jul 2016 22:29:13 -0700 (PDT) X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160726052913.4907091.59991.9011@gmail.com> Date: Mon, 25 Jul 2016 23:29:13 -0600 Subject: Re: rpi2 as wireless router From: Russell Haley In-Reply-To: References: <4E1AB9F3-B7F8-49F3-BAD2-259584B04E3B@gmail.com> <20160725022255.GA6128@debian-macbookpro> <20160725050139.4907091.36565.8923@gmail.com> <20160725053414.GB6128@debian-macbookpro> <20160726043613.4907091.75531.9005@gmail.com> To: "Herminio Hernandez, Jr." , freebsd-arm MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 05:29:15 -0000 From owner-freebsd-arm@freebsd.org Tue Jul 26 05:41:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AD2CBA5518; Tue, 26 Jul 2016 05:41:44 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30F731A79; Tue, 26 Jul 2016 05:41:43 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6Q5fe9B016441 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Jul 2016 22:41:40 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Warner Losh References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> Cc: Michal Meloun , Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" From: Nathan Whitehorn Message-ID: Date: Mon, 25 Jul 2016 22:41:40 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbpDTl1BNmgl0Wr+5ocv7kfz684yOseer/bHoSJHwnOFcZHg91wGuPzUq0zW1vRIkGotifzkeSe0H6/7tEmjKhsI5DWIe9oNNI= X-Sonic-ID: C;XKtWoPNS5hGVlZtMTlz00w== M;6Ji+oPNS5hGVlZtMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 05:41:44 -0000 On 07/25/16 21:24, Warner Losh wrote: > On Mon, Jul 25, 2016 at 10:48 AM, Nathan Whitehorn > wrote: >> >> On 07/25/16 09:32, Warner Losh wrote: >>> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn >>> wrote: >>>> That wasn't my question. Are these particular device drivers allocating >>>> interrupts both on the GPIOs in their "interrupts" property (which are >>>> entirely GPIOs in this example) *and* on the GPIOs listed as resources >>>> but >>>> not listed as interrupts? If they are, then you need a switching >>>> mechanism, >>>> but that seems pretty unlikely given the names of the non-interrupt GPIOs >>>> (they look like outputs). It would also be a somewhat deranged way to set >>>> up >>>> a device tree -- not that that rules it out or anything. >>> On Atmel, there's a situation that this covers, I think. >>> >>> The MCI device has an interrupt in the core: >>> >>> mmc0: mmc@fffa8000 { >>> compatible = "atmel,hsmci"; >>> reg = <0xfffa8000 0x600>; >>> interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>; >>> #address-cells = <1>; >>> #size-cells = <0>; >>> pinctrl-names = "default"; >>> clocks = <&mci0_clk>; >>> clock-names = "mci_clk"; >>> status = "disabled"; >>> }; >>> >>> and in other places wires in GPIO interrupts for things like card >>> eject / insertion. >>> >>> mmc0: mmc@f0008000 { >>> pinctrl-0 = < >>> &pinctrl_board_mmc0 >>> &pinctrl_mmc0_slot0_clk_cmd_dat0 >>> &pinctrl_mmc0_slot0_dat1_3>; >>> status = "okay"; >>> slot@0 { >>> reg = <0>; >>> bus-width = <4>; >>> cd-gpios = <&pioD 15 >>> GPIO_ACTIVE_HIGH>; >>> }; >>> }; >>> >>> an interrupt is registered on the cd-gpios pin for when the card changes. >>> At >>> least in linux, FreeBSD doesn't (yet) implement this, but will someday if >>> I get >>> back to the armv6 atmel work I started (see at91-cosino.dts for example, >>> there's >>> others). >>> >>> I think this is an example of what you are asking about, or did I get >>> lost in the >>> twisty maze of conversation zigs and zags... >>> >>> Warner >>> >> Where we would run into (minor) problems is if the interrupt parent for the >> first mmc0 is the GPIO controller. More generally, if &pioD has interrupt >> children specified in some way that is not a >> tuple somewhere else in the tree then you would have to have methods to >> parse both interrupt specifiers as-obtained-from-interrupts-properties (or >> equivalent) and specifiers as-obtained-from-gpio-properties. If the tree >> picks one format and sticks with it, you can get away with just the one. >> Glancing through the DTS source for this board, that doesn't appear to be >> the case and the property formatting is uniform, but I might have missed >> something in one of the many #includes. > Interrupts and GPIO specifiers are different in subtle ways. The interrupt > parent for mmc0 is an AIC, which is also the ultimate parent of the GPIO > controller. That is what it looked like. > But the properties for the GPIO pins that act as interrupts and > the interrupt specifiers are different. So there are devices with both interrupts = , #interrupt-parent = <&gpio> and gpios = <&gpio bleh baz> where "Bleh baz" is formatted different than "foo bar" and both are meant to be treated as interrupts? It's fine if there are, but I haven't seen any such device trees yet. >> As a general point, GPIO weirdness would be easy enough case to handle if it >> did come up (add some mapping method, as above) that I think we shouldn't >> worry too much about it from an architectural point of view. If a board >> appears that is set up this way, we can roll with the punches at that point >> and add whatever small amount of shim code that is required. It would be >> annoyance, sure, but not a real complication. > I suspect that either I don't understand the issue, or we'll have such boards > very quickly. The Atmel design is fairly clean in comparison to other > franken-horrors > I've seen... People do weird things for sure. My point is just that the details of how (implicit) GPIO interrupts are formatted just isn't that important. It's easy enough to add special code for devices that are set up in bizarre ways as they are spotted in the wild and that special code is so minor that it doesn't matter for the design of the API. This is a point I was just curious about, since I had never actually seen device trees set up that way. The issue with this patch is, at its core, whether you have an architecture that relies on the newbus hierarchy (like r301453) or that allows links outside of that hierarchy that can cross branches or go the "wrong" way, like the previously existing code. There are some other differences, of varying degrees of importance, but that's the really fundamental one. I haven't seen any cases where r301453 provides functionality absent in the already existing system, but there seem to be a large number of cases (see the first email I sent to freebsd-arch or https://wiki.freebsd.org/Complicated_Interrupts) that the API in r301453 cannot accommodate and that are needed to support a variety of hardware. Since having two APIs will be a significant maintenance burden, if there are cases the existing code can't handle, I would like to know about them; otherwise, I think we should back out r301453 and stick to the standard device tree interrupt mapping mechanism on ARM instead. I'm happy to help implement any necessary enhancements there (for example, dealing with weirdly-encoded GPIOs). -Nathan > > Warner > From owner-freebsd-arm@freebsd.org Tue Jul 26 05:41:47 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A58B2BA5539 for ; Tue, 26 Jul 2016 05:41:47 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 665091A99 for ; Tue, 26 Jul 2016 05:41:47 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: by mail-io0-x232.google.com with SMTP id m101so196291447ioi.2 for ; Mon, 25 Jul 2016 22:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=taAqlKj6Hv7BFV+4J7ETezPKoPuJTZA66Rx+Z8OQtgA=; b=w8Tu00PzZulWpBI7504uPGZxXgFPZaBRnn8+SAf5L5ikAFcz/Ce481vFKiq7QIOI98 YJogTXfNVhf1E+duCRrV+WKSWDBM6nW5mU8MAQ0Ni1pMd5NeMj0Yip4bRX5/zbY4fvqU N/MoMvDRv4NwOHp+TlfgJPVcjWfKnaYS+sLkMvd/6PacN5ABfs/PgGOmdUJ5L4N2enqy oCg0lA5WXTTtYs8DwpESOVASbOuflLQhrPJT93pV6bHRVcGBzVEyUNEAsSdFUgtx1z+3 cgBt7BE71JGVRJuaCXAqX3FewtEtLat6rFxR9Me3XWddotCobPtMTJ03hIMN9c5eZIm6 kV0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=taAqlKj6Hv7BFV+4J7ETezPKoPuJTZA66Rx+Z8OQtgA=; b=S5dyAGCP7T71mUov/Kw4PguZ1geVRO8VTwJjFQ7s/P6t8Q8BmPiQXpXOSpH4O0sUmO 8Ka9XxZkjZCfm8GYIBl9E+JzLNrzU3ZfcPNbih9qyyiW9tWGi5IsJfix8J4svED64EyQ wHVIM0KagduXHkw1zcqzGrS1D3Eu89yn0aMxY4/BNfm/wCJRimxDSaGa/3PVkrj1E/e5 5w8+hnw8T4ePniLZ6MuQteLzXAtauEKydkidG80lWkCuvdH6Qoszc9iQY3lKdUlrCuW9 Dy2FulI5/5n9zb5RvCWmiOWf0DXyLLUN61kzhpTSgSnqGIvNE3zwhRUq0hRLA7L4qXPB AE4g== X-Gm-Message-State: AEkoousfvMx0flYTjvRGAiVuTFI9Pbl1ULFfQsvT5kWZRFNQ0lcn7nY6rEyizYnSl9xapKesOyLORlCzNts9jw== X-Received: by 10.202.182.85 with SMTP id g82mr11834004oif.58.1469511706701; Mon, 25 Jul 2016 22:41:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.7.1 with HTTP; Mon, 25 Jul 2016 22:41:46 -0700 (PDT) In-Reply-To: <20160726052913.4907091.59991.9011@gmail.com> References: <4E1AB9F3-B7F8-49F3-BAD2-259584B04E3B@gmail.com> <20160725022255.GA6128@debian-macbookpro> <20160725050139.4907091.36565.8923@gmail.com> <20160725053414.GB6128@debian-macbookpro> <20160726043613.4907091.75531.9005@gmail.com> <20160726052913.4907091.59991.9011@gmail.com> From: "Herminio Hernandez, Jr." Date: Mon, 25 Jul 2016 22:41:46 -0700 Message-ID: Subject: Re: rpi2 as wireless router To: Russell Haley Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 05:41:47 -0000 I am posting to paste bin, but I also received this in the freebsd forum The last step in these instruction is needlessly complicated. Copying files > manually? Why? *.ko are also not located in a single directory (anymore?) > but spread across the whole MAKEOBJDIRPREFIX. > > You can copy the new kernel and kernel modules with sudo -E make > DESTDIR=3D/mnt installkernel. They'll be in /mnt/boot/kernel. so I went to my obj dir and ran the command 'find . -iname "*.ko"' and I found the modules..they were in the /arm.armv6/usr/src/sys/RPI2/modules/usr/src/sys/modules dir On Mon, Jul 25, 2016 at 10:29 PM, Russell Haley wrote: > And your kernel toolchain build, and indicate the svn revision too. > Possibly though on of the guys is going to see a problem in the example. > Or you have a revision that doesn't build because the example uses the he= ad > revision. I've never exported my variables, so I can't talk to the validi= ty > of the example (although I did comment about -j). > > I just run > > script /tmp/buildout.txt > > Svn info (I think?) > ... > > And then exit when I'm done building and copy that file into pastebin. > > Russ > > Sent from my BlackBerry 10 smartphone on the Koodo network. > *From: *Herminio Hernandez, Jr. > *Sent: *Monday, July 25, 2016 11:13 PM > *To: *Russell Haley > *Subject: *Re: rpi2 as wireless router > > Do you want the entire output after make buildkernel? > > On Mon, Jul 25, 2016 at 9:36 PM, Russell Haley > wrote: > >> =E2=80=8ESorry for top post, >> >> Can you script your build output and post it in pastebin? >> >> Russ >> >> Sent from my BlackBerry 10 smartphone on the Koodo network. >> *From: *Herminio Hernandez, Jr. >> *Sent: *Monday, July 25, 2016 10:21 PM >> *To: *Russell Haley >> *Subject: *Re: rpi2 as wireless router >> >> All, >> >> I want to compile the kernel to enable wlandebug on the rpi2. I followed >> this *example >> , = *however >> in the end I am not seeing an .ko files. Is there a step I am missing? >> >> Can you script your build output and post it in pastebin? >> >> On Sun, Jul 24, 2016 at 10:34 PM, Herminio Hernandez Jr < >> herminio.hernandezjr@gmail.com> wrote: >> >>> On 07/24, Russell Haley wrote: >>> > Could I see your PCAP files? I'm no expert but I'm really curious. >>> > >>> > Thanks Russ >>> I have them attached. >>> >>> Herminio >>> > >>> > Sent from my BlackBerry 10 smartphone on the Koodo network. >>> > Original Message >>> > From: Herminio Hernandez Jr >>> > Sent: Sunday, July 24, 2016 8:23 PM >>> > To: Andriy Voskoboinyk >>> > Cc: Adrian Chadd; freebsd-arm@freebsd.org >>> > Subject: Re: rpi2 as wireless router >>> > >>> > On 07/24, Andriy Voskoboinyk wrote: >>> > > Thu, 21 Jul 2016 06:56:22 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0= =B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Herminio Hernandez Jr. >>> > > : >>> > > >>> > > Another idea: try to add >>> > > hw.usb.urtwn.enable_11n=3D"0" >>> > > into /boot/loader.conf (and reboot). >>> > > (described as "download speed" fix in >>> > > https://forums.freebsd.org/threads/48737/ - >>> > > but may help here too). >>> > > >>> > The same issue. Debian is not seeing the DHCP Offer from freebsd. >>> > > > No same issue. I am willing to help in any way I can. I can send >>> you the >>> > > > pcap files I made. >>> > > > >>> > > > Sent from my iPhone >>> > > > >>> > > > > On Jul 20, 2016, at 8:04 PM, Adrian Chadd < >>> adrian.chadd@gmail.com> >>> > > > > wrote: >>> > > > > >>> > > > > Hi, >>> > > > > >>> > > > > Ok. We'll have to set up a test environment here to see what's >>> going >>> > > > > on, complete with some packet sniffing. >>> > > > > >>> > > > > Question - if you configure up hostap to be open/no >>> authentication, >>> > > > > does it all work? >>> > > > > >>> > > > > >>> > > > > -a >>> >> >> >> > > From owner-freebsd-arm@freebsd.org Tue Jul 26 06:06:49 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B3D4BA5977 for ; Tue, 26 Jul 2016 06:06:49 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2F521691 for ; Tue, 26 Jul 2016 06:06:48 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: by mail-io0-x235.google.com with SMTP id b62so197305560iod.3 for ; Mon, 25 Jul 2016 23:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LhZlGhNPwXvp7meuQPyPfj+R590/HEHYYv2yURDbLwo=; b=Mwaa1bbv6lxnJl/yncvEA7cMBtK1Gg1BJUdiYFVe1Nt8+TzAVQgEDbst7zKlJSBZG0 8pH7+jm45lPusXITn2f41a3Xwcy7HdWUBSYZBWiLzhJaD3lVxc6i+HoYdsslJfhzHbKa KcjRS/fsyloTcH8P0tfivTTwqYeEP0a9In44ql3ZbP+Y4SAXaMmdG5EHo/86dwrHiRB/ qNWw+1PpZVBd2IFsP+Cg5lQOa3BPbSlgZTEW0CUaSAzDZB+Kx99HarSTGLMrdAcsOhtk dQJxwnXbYoTHpraZ9CaMf9c9yYv28UF92EYFwt+Z2RETJmFnOsCN5Y3NMN1cjDFnUYWl +Sqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LhZlGhNPwXvp7meuQPyPfj+R590/HEHYYv2yURDbLwo=; b=S5EdWHXfeDiuVQpdi7SPhnT0EqfSWqim12v9u77QeiJFY4Yl8WsugYbJRycusYzwB8 XaIzTZrcnK7Y52SQyFJMrnX2dfgVCFzi1R7t2mqZKhHtCKsUDqv8FYNf43uEJxpCbJUu t4NO8nNfswlCoSJtel/Kj8KsXs/IGQLKxQyGmCFP5KilT0DVFYgioFbO98b5IltF7ps8 YA7v5PArEVQvpXnrCtXZfCjhL1HyLhPt4DKQYoVXaGReqAyp1FSzk04+HTJNONzxte7J 6PlqdGci7lLy6gc0Mv0bY6a4m2qwvFZ0f2YBLTSCNAAhy2zU1FRoX8y06edVEecj+DXK 1Ojg== X-Gm-Message-State: AEkoouutARRhQzdB6yBFwuPkIMg2QLHy2ajQ73MTufu/OuhT9JaCkPa1O+CUxtmkFCpmbK9kA2xcKShpy4m9qg== X-Received: by 10.157.20.232 with SMTP id r37mr12134678otr.60.1469513208011; Mon, 25 Jul 2016 23:06:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.7.1 with HTTP; Mon, 25 Jul 2016 23:06:47 -0700 (PDT) In-Reply-To: References: <4E1AB9F3-B7F8-49F3-BAD2-259584B04E3B@gmail.com> <20160725022255.GA6128@debian-macbookpro> <20160725050139.4907091.36565.8923@gmail.com> <20160725053414.GB6128@debian-macbookpro> <20160726043613.4907091.75531.9005@gmail.com> <20160726052913.4907091.59991.9011@gmail.com> From: "Herminio Hernandez, Jr." Date: Mon, 25 Jul 2016 23:06:47 -0700 Message-ID: Subject: Re: rpi2 as wireless router To: Russell Haley Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 06:06:49 -0000 here is the output https://drive.google.com/file/d/0ByNWUTbPhemsd0laOC15eFlGaVE/view?usp=3Dsha= ring On Mon, Jul 25, 2016 at 10:41 PM, Herminio Hernandez, Jr. < herminio.hernandezjr@gmail.com> wrote: > I am posting to paste bin, but I also received this in the freebsd forum > > The last step in these instruction is needlessly complicated. Copying >> files manually? Why? *.ko are also not located in a single directory >> (anymore?) but spread across the whole MAKEOBJDIRPREFIX. >> >> You can copy the new kernel and kernel modules with sudo -E make >> DESTDIR=3D/mnt installkernel. They'll be in /mnt/boot/kernel. > > > so I went to my obj dir and ran the command 'find . -iname "*.ko"' and I > found the modules..they were in the > /arm.armv6/usr/src/sys/RPI2/modules/usr/src/sys/modules dir > > > > On Mon, Jul 25, 2016 at 10:29 PM, Russell Haley > wrote: > >> And your kernel toolchain build, and indicate the svn revision too. >> Possibly though on of the guys is going to see a problem in the example. >> Or you have a revision that doesn't build because the example uses the h= ead >> revision. I've never exported my variables, so I can't talk to the valid= ity >> of the example (although I did comment about -j). >> >> I just run >> >> script /tmp/buildout.txt >> >> Svn info (I think?) >> ... >> >> And then exit when I'm done building and copy that file into pastebin. >> >> Russ >> >> Sent from my BlackBerry 10 smartphone on the Koodo network. >> *From: *Herminio Hernandez, Jr. >> *Sent: *Monday, July 25, 2016 11:13 PM >> *To: *Russell Haley >> *Subject: *Re: rpi2 as wireless router >> >> Do you want the entire output after make buildkernel? >> >> On Mon, Jul 25, 2016 at 9:36 PM, Russell Haley >> wrote: >> >>> =E2=80=8ESorry for top post, >>> >>> Can you script your build output and post it in pastebin? >>> >>> Russ >>> >>> Sent from my BlackBerry 10 smartphone on the Koodo network. >>> *From: *Herminio Hernandez, Jr. >>> *Sent: *Monday, July 25, 2016 10:21 PM >>> *To: *Russell Haley >>> *Subject: *Re: rpi2 as wireless router >>> >>> All, >>> >>> I want to compile the kernel to enable wlandebug on the rpi2. I followe= d >>> this *example >>> ,= *however >>> in the end I am not seeing an .ko files. Is there a step I am missing? >>> >>> Can you script your build output and post it in pastebin? >>> >>> On Sun, Jul 24, 2016 at 10:34 PM, Herminio Hernandez Jr < >>> herminio.hernandezjr@gmail.com> wrote: >>> >>>> On 07/24, Russell Haley wrote: >>>> > Could I see your PCAP files? I'm no expert but I'm really curious. >>>> > >>>> > Thanks Russ >>>> I have them attached. >>>> >>>> Herminio >>>> > >>>> > Sent from my BlackBerry 10 smartphone on the Koodo network. >>>> > Original Message >>>> > From: Herminio Hernandez Jr >>>> > Sent: Sunday, July 24, 2016 8:23 PM >>>> > To: Andriy Voskoboinyk >>>> > Cc: Adrian Chadd; freebsd-arm@freebsd.org >>>> > Subject: Re: rpi2 as wireless router >>>> > >>>> > On 07/24, Andriy Voskoboinyk wrote: >>>> > > Thu, 21 Jul 2016 06:56:22 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0= =B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Herminio Hernandez Jr. >>>> > > : >>>> > > >>>> > > Another idea: try to add >>>> > > hw.usb.urtwn.enable_11n=3D"0" >>>> > > into /boot/loader.conf (and reboot). >>>> > > (described as "download speed" fix in >>>> > > https://forums.freebsd.org/threads/48737/ - >>>> > > but may help here too). >>>> > > >>>> > The same issue. Debian is not seeing the DHCP Offer from freebsd. >>>> > > > No same issue. I am willing to help in any way I can. I can send >>>> you the >>>> > > > pcap files I made. >>>> > > > >>>> > > > Sent from my iPhone >>>> > > > >>>> > > > > On Jul 20, 2016, at 8:04 PM, Adrian Chadd < >>>> adrian.chadd@gmail.com> >>>> > > > > wrote: >>>> > > > > >>>> > > > > Hi, >>>> > > > > >>>> > > > > Ok. We'll have to set up a test environment here to see what's >>>> going >>>> > > > > on, complete with some packet sniffing. >>>> > > > > >>>> > > > > Question - if you configure up hostap to be open/no >>>> authentication, >>>> > > > > does it all work? >>>> > > > > >>>> > > > > >>>> > > > > -a >>>> >>> >>> >>> >> >> > From owner-freebsd-arm@freebsd.org Tue Jul 26 08:50:08 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29084BA3001 for ; Tue, 26 Jul 2016 08:50:08 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh602-vm6.bullet.mail.ssk.yahoo.co.jp (nh602-vm6.bullet.mail.ssk.yahoo.co.jp [182.22.90.31]) by mx1.freebsd.org (Postfix) with SMTP id A641A1F55 for ; Tue, 26 Jul 2016 08:50:07 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.106] by nh602.bullet.mail.ssk.yahoo.co.jp with NNFMP; 26 Jul 2016 08:50:02 -0000 Received: from [182.22.91.131] by t604.bullet.mail.ssk.yahoo.co.jp with NNFMP; 26 Jul 2016 08:50:02 -0000 Received: from [127.0.0.1] by omp604.mail.ssk.yahoo.co.jp with NNFMP; 26 Jul 2016 08:50:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 567796.20617.bm@omp604.mail.ssk.yahoo.co.jp Received: (qmail 52762 invoked by uid 60001); 26 Jul 2016 08:50:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1469523002; bh=7Q43vmBmvJkJMn0qPtJfu5XLqZQy0fInvYBAkC5wkIs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=gLUf19emYdIL32IdePOFzh6E6wVGuIekxo397JI6YBKISYntaR1oKzKiCYCUo0awzIvxEnxHkIHPbEE7CBuKK5MTESSbRZRxqUpvvu/KUZmgB6OwSxs1HNJ4U4L1b2S+cUaSPUaigobANKCse/wOGj4Lo2fHC5trlpPJNKmYQ4U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=e3pQaY7jm86mmMNMpagEC5kMuC+51jHeYQ51zOlsUgDGFH0EtmulubJFTMxaRLbu1pasqqpUzJGontiaZsEjZMVoXWQX2Tv6kTwsJUKU32kx/jpO8Iyez064UYMOhQwWzEYHKHxkoQVNeqHz12f0almYUSy08zkUAsoiPpsnXuQ=; Message-ID: <308695.46813.qm@web101704.mail.ssk.yahoo.co.jp> X-YMail-OSG: AkM6QDIVM1kKTcZ3cWkmMdocXvmawIMoNCUHjfXnXsmR_1_9REMx3DnECFUqNlPiBuPPE86kr3ZqQyF5mDATtIkKFVo8kMP5VDAh3uG2PygAbNlUSAasyT.f2cEwbs7Ystv9qwnfm0hOIlj8P4URVcnKqu3Wjhfqg7ylr.XPZnoEr.GCmSH2KKGhB_LJu_x_6p7iKCmS4bTYiS3S327NqYDeIp84pjsDQx7wN10dRv4xP78aKACQwjvwHNjbyhBt7Lw94mLyA5gfk9VGrC4hwadsFQYp0ShI0NPxKlkp.5yLodPAdLslxIeDrFNgdihQD6cto7jB_f5RKyGVrtKSezX_Pt5CvjD7bhxJo415..MoYdDpIbwo7.6NFe1VFOGzJpGl9yEGOf.BKyXErdzc8qpBRVCEFt1LGsy0B.MLDmSGN64RDFHzEMPvKRSV3gVoLpDpFWRMVkRIs2VeMhQcI7czjHhpsB.Jzw9FIEmryMYiEpkW8H1L0URmow8L85IGBFS_f8AQW8R7WxthHVwwtFOY8t2Fd9QfSqQY5F0YNqv2LR5M568ck4Y- Received: from [110.134.196.53] by web101704.mail.ssk.yahoo.co.jp via HTTP; Tue, 26 Jul 2016 17:50:01 JST X-Mailer: YahooMailWebService/0.8.111_69 X-YMail-JAS: iH3PmLIVM1njCgbBUJ3ml.htQIKa6MQqihq2pJYc80Ow0RAuiIY09uvqIiIR4WTEXEvuFvZOp.eUpT7YFOClvlt_M08z2uAGrJwHc1eKgX._WS1Vk_R2cVWYYfjTFUFSRW9S Date: Tue, 26 Jul 2016 17:50:01 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: hang up at cns11xx To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 08:50:08 -0000 Hi.=0A=0AI try to cns11xx use gcc. I add EventTimer,FTD,INTRNG.=A0=0A=0AI h= ave hang up problem. I seem uart read is trigger at hang up.=0A=0AI can't u= se break.=0A=0AThis is hang up by single user sh input.=0A=0Ahttps://gist.g= ithub.com/yamori813/ae047a28a825aac255e436fd8ccaf785=0A=0A=0AHow to debug i= n this case...=0A=0AIf you have advice, please let me know.=0A=0AI spend ma= ny time this target. Because of I love vintage soc. :)=0A=0AThanks.=0A=0AHi= roki Mori From owner-freebsd-arm@freebsd.org Tue Jul 26 13:41:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59B47BA593C; Tue, 26 Jul 2016 13:41:04 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 147FA1A92; Tue, 26 Jul 2016 13:41:03 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id C93E63AC81; Tue, 26 Jul 2016 15:40:55 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> Cc: Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <57976867.6080705@FreeBSD.org> Date: Tue, 26 Jul 2016 15:40:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Tue, 26 Jul 2016 15:40:55 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:41:04 -0000 Dne 26.07.2016 v 7:41 Nathan Whitehorn napsal(a): > > > On 07/25/16 21:24, Warner Losh wrote: >> On Mon, Jul 25, 2016 at 10:48 AM, Nathan Whitehorn >> wrote: >>> >>> On 07/25/16 09:32, Warner Losh wrote: >>>> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn >>>> wrote: >>>>> That wasn't my question. Are these particular device drivers >>>>> allocating >>>>> interrupts both on the GPIOs in their "interrupts" property (which >>>>> are >>>>> entirely GPIOs in this example) *and* on the GPIOs listed as >>>>> resources >>>>> but >>>>> not listed as interrupts? If they are, then you need a switching >>>>> mechanism, >>>>> but that seems pretty unlikely given the names of the >>>>> non-interrupt GPIOs >>>>> (they look like outputs). It would also be a somewhat deranged way >>>>> to set >>>>> up >>>>> a device tree -- not that that rules it out or anything. >>>> On Atmel, there's a situation that this covers, I think. >>>> >>>> The MCI device has an interrupt in the core: >>>> >>>> mmc0: mmc@fffa8000 { >>>> compatible = "atmel,hsmci"; >>>> reg = <0xfffa8000 0x600>; >>>> interrupts = <9 >>>> IRQ_TYPE_LEVEL_HIGH 0>; >>>> #address-cells = <1>; >>>> #size-cells = <0>; >>>> pinctrl-names = "default"; >>>> clocks = <&mci0_clk>; >>>> clock-names = "mci_clk"; >>>> status = "disabled"; >>>> }; >>>> >>>> and in other places wires in GPIO interrupts for things like card >>>> eject / insertion. >>>> >>>> mmc0: mmc@f0008000 { >>>> pinctrl-0 = < >>>> &pinctrl_board_mmc0 >>>> >>>> &pinctrl_mmc0_slot0_clk_cmd_dat0 >>>> &pinctrl_mmc0_slot0_dat1_3>; >>>> status = "okay"; >>>> slot@0 { >>>> reg = <0>; >>>> bus-width = <4>; >>>> cd-gpios = <&pioD 15 >>>> GPIO_ACTIVE_HIGH>; >>>> }; >>>> }; >>>> >>>> an interrupt is registered on the cd-gpios pin for when the card >>>> changes. >>>> At >>>> least in linux, FreeBSD doesn't (yet) implement this, but will >>>> someday if >>>> I get >>>> back to the armv6 atmel work I started (see at91-cosino.dts for >>>> example, >>>> there's >>>> others). >>>> >>>> I think this is an example of what you are asking about, or did I get >>>> lost in the >>>> twisty maze of conversation zigs and zags... >>>> >>>> Warner >>>> >>> Where we would run into (minor) problems is if the interrupt parent >>> for the >>> first mmc0 is the GPIO controller. More generally, if &pioD has >>> interrupt >>> children specified in some way that is not a >> high/whatever> >>> tuple somewhere else in the tree then you would have to have methods to >>> parse both interrupt specifiers >>> as-obtained-from-interrupts-properties (or >>> equivalent) and specifiers as-obtained-from-gpio-properties. If the >>> tree >>> picks one format and sticks with it, you can get away with just the >>> one. >>> Glancing through the DTS source for this board, that doesn't appear >>> to be >>> the case and the property formatting is uniform, but I might have >>> missed >>> something in one of the many #includes. >> Interrupts and GPIO specifiers are different in subtle ways. The >> interrupt >> parent for mmc0 is an AIC, which is also the ultimate parent of the GPIO >> controller. > > That is what it looked like. > >> But the properties for the GPIO pins that act as interrupts and >> the interrupt specifiers are different. > > So there are devices with both interrupts = , > #interrupt-parent = <&gpio> and gpios = <&gpio bleh baz> where "Bleh > baz" is formatted different than "foo bar" and both are meant to be > treated as interrupts? > > It's fine if there are, but I haven't seen any such device trees yet. I think that yes, but I'm not ready to search all 1372 Linux DT files only for explicit example. But your question is invalid from beginning. 1) Format of each single 'interrupts' and '*-gpios' property is different because each single one are defined differently. 2) The question should not be 'Are there device' but 'Is this combination valid' Moreover, I'm curious why you want OFW property for gpio interrupts at all, given gpio can be instantiated by other entity (PCIe, USB). Please see: https://svnweb.freebsd.org/base/head/sys/dev/gpio/gpiobus.c?revision=301539&view=markup#l92 and, for example this one controller https://svnweb.freebsd.org/base/head/sys/arm/nvidia/tegra_gpio.c?revision=300149&view=markup#l575 > >>> As a general point, GPIO weirdness would be easy enough case to >>> handle if it >>> did come up (add some mapping method, as above) that I think we >>> shouldn't >>> worry too much about it from an architectural point of view. If a board >>> appears that is set up this way, we can roll with the punches at >>> that point >>> and add whatever small amount of shim code that is required. It >>> would be >>> annoyance, sure, but not a real complication. >> I suspect that either I don't understand the issue, or we'll have >> such boards >> very quickly. The Atmel design is fairly clean in comparison to other >> franken-horrors >> I've seen... > > People do weird things for sure. My point is just that the details of > how (implicit) GPIO interrupts are formatted just isn't that > important. It's easy enough to add special code for devices that are > set up in bizarre ways as they are spotted in the wild and that > special code is so minor that it doesn't matter for the design of the > API. This is a point I was just curious about, since I had never > actually seen device trees set up that way. > > The issue with this patch is, at its core, whether you have an > architecture that relies on the newbus hierarchy (like r301453) or > that allows links outside of that hierarchy that can cross branches or > go the "wrong" way, like the previously existing code. OK. The r301453 : - it removes unnecessary idea of virtual IRQs. I gave you some examples where virtual IRQ concept fails. Also, both variants needs attached PIC at bus_alloc_resource() time, so timing wasn't been changed. - it implements new BUS_MAP_INTR(). As I understand it, this is problematic for you, and I'm ready to change it. But I need more details than "it's fundamentally broken". > There are some other differences, of varying degrees of importance, > but that's the really fundamental one. I haven't seen any cases where > r301453 provides functionality absent in the already existing system, > but there seem to be a large number of cases (see the first email I > sent to freebsd-arch or > https://wiki.freebsd.org/Complicated_Interrupts) that the API in > r301453 cannot accommodate and that are needed to support a variety of > hardware. Which single feature has been removed by r301453? Michal > Since having two APIs will be a significant maintenance burden, if > there are cases the existing code can't handle, I would like to know > about them; otherwise, I think we should back out r301453 and stick to > the standard device tree interrupt mapping mechanism on ARM instead. > I'm happy to help implement any necessary enhancements there (for > example, dealing with weirdly-encoded GPIOs). > -Nathan > >> >> Warner >> > From owner-freebsd-arm@freebsd.org Tue Jul 26 13:43:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA7DCBA5AAC for ; Tue, 26 Jul 2016 13:43:13 +0000 (UTC) (envelope-from george@vagner.com) Received: from mailrelay2.pub.mailoutpod1-wdc1.one.com (mailrelay2.pub.mailoutpod1-wdc1.one.com [104.37.35.57]) (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 6D7941D8D for ; Tue, 26 Jul 2016 13:43:12 +0000 (UTC) (envelope-from george@vagner.com) X-HalOne-Cookie: 2d002a5986f626d5424fb107d677eb6b56d079c3 X-HalOne-ID: bd395bba-5336-11e6-ab40-549f35fe4221 Received: from [192.168.0.140] (unknown [172.242.238.151]) by mailrelay1.pub.mailoutpod1-wdc1.one.com (Halon Mail Gateway) with ESMTPSA; Tue, 26 Jul 2016 13:41:59 +0000 (UTC) Date: Tue, 26 Jul 2016 09:41:53 -0400 Subject: Re: rpi2 as wireless router Message-ID: From: laszlo g vagner To: "Herminio Hernandez, Jr." , Russell Haley Cc: freebsd-arm MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:43:13 -0000 SSB0cmllZCB0byB1c2UgbXkgcGkgYXMgYSByb3V0ZXIgYW5kIGl0IHdvcmtlZCBzb21ld2hhdC4K VGhlIHByb2JsZW0gSSBoYWQgd2FzIGlmIEkgbG9zdCAgbXkgY29ubmVjdGlvbiB0byBpbnRlcm5l dApEaGNwIHdvdWxkIG5ldmVyIGdldCBhIG5ldyBJUCB1bmxlc3MgSSBtYXJrZWQgdGhlIEkgaW50 ZXJmYWNlCkRvd24gdGhlbiB1cC4gT3RoZXIgYm94ZXMgSSBoYXZlIGRvbid0IGRvIHRoaXMKCk9u IEp1bHkgMjYsIDIwMTYsIGF0IDI6MDYgQU0sICJIZXJtaW5pbyBIZXJuYW5kZXosIEpyLiIgPGhl cm1pbmlvLmhlcm5hbmRlempyQGdtYWlsLmNvbT4gd3JvdGU6CgpoZXJlIGlzIHRoZSBvdXRwdXQK aHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL2ZpbGUvZC8wQnlOV1VUYlBoZW1zZDBsYU9DMTVlRmxH YVZFL3ZpZXc/dXNwPXNoYXJpbmcKCk9uIE1vbiwgSnVsIDI1LCAyMDE2IGF0IDEwOjQxIFBNLCBI ZXJtaW5pbyBIZXJuYW5kZXosIEpyLiA8Cmhlcm1pbmlvLmhlcm5hbmRlempyQGdtYWlsLmNvbT4g d3JvdGU6Cgo+IEkgYW0gcG9zdGluZyB0byBwYXN0ZSBiaW4sIGJ1dCBJIGFsc28gcmVjZWl2ZWQg dGhpcyBpbiB0aGUgZnJlZWJzZCBmb3J1bQo+Cj4gVGhlIGxhc3Qgc3RlcCBpbiB0aGVzZSBpbnN0 cnVjdGlvbiBpcyBuZWVkbGVzc2x5IGNvbXBsaWNhdGVkLiBDb3B5aW5nCj4+IGZpbGVzIG1hbnVh bGx5PyBXaHk/ICoua28gYXJlIGFsc28gbm90IGxvY2F0ZWQgaW4gYSBzaW5nbGUgZGlyZWN0b3J5 Cj4+IChhbnltb3JlPykgYnV0IHNwcmVhZCBhY3Jvc3MgdGhlIHdob2xlIE1BS0VPQkpESVJQUkVG SVguCj4+Cj4+IFlvdSBjYW4gY29weSB0aGUgbmV3IGtlcm5lbCBhbmQga2VybmVsIG1vZHVsZXMg d2l0aCBzdWRvIC1FIG1ha2UKPj4gREVTVERJUj0vbW50IGluc3RhbGxrZXJuZWwuIFRoZXknbGwg YmUgaW4gL21udC9ib290L2tlcm5lbC4KPgo+Cj4gc28gSSB3ZW50IHRvIG15IG9iaiBkaXIgYW5k IHJhbiB0aGUgY29tbWFuZCAnZmluZCAuIC1pbmFtZSAiKi5rbyInIGFuZCBJCj4gZm91bmQgdGhl IG1vZHVsZXMuLnRoZXkgd2VyZSBpbiB0aGUKPiAvYXJtLmFybXY2L3Vzci9zcmMvc3lzL1JQSTIv bW9kdWxlcy91c3Ivc3JjL3N5cy9tb2R1bGVzIGRpcgo+Cj4KPgo+IE9uIE1vbiwgSnVsIDI1LCAy MDE2IGF0IDEwOjI5IFBNLCBSdXNzZWxsIEhhbGV5IDxydXNzLmhhbGV5QGdtYWlsLmNvbT4KPiB3 cm90ZToKPgo+PiBBbmQgeW91ciBrZXJuZWwgdG9vbGNoYWluIGJ1aWxkLCBhbmQgaW5kaWNhdGUg dGhlIHN2biByZXZpc2lvbiB0b28uCj4+IFBvc3NpYmx5IHRob3VnaCBvbiBvZiB0aGUgZ3V5cyBp cyBnb2luZyB0byBzZWUgYSBwcm9ibGVtIGluIHRoZSBleGFtcGxlLgo+PiBPciB5b3UgaGF2ZSBh IHJldmlzaW9uIHRoYXQgZG9lc24ndCBidWlsZCBiZWNhdXNlIHRoZSBleGFtcGxlIHVzZXMgdGhl IGhlYWQKPj4gcmV2aXNpb24uIEkndmUgbmV2ZXIgZXhwb3J0ZWQgbXkgdmFyaWFibGVzLCBzbyBJ IGNhbid0IHRhbGsgdG8gdGhlIHZhbGlkaXR5Cj4+IG9mIHRoZSBleGFtcGxlIChhbHRob3VnaCBJ IGRpZCBjb21tZW50IGFib3V0IC1qKS4KPj4KPj4gSSBqdXN0IHJ1bgo+Pgo+PiBzY3JpcHQgL3Rt cC9idWlsZG91dC50eHQKPj4KPj4gU3ZuIGluZm8gKEkgdGhpbms/KQo+PiAuLi4KPj4KPj4gQW5k IHRoZW4gZXhpdCB3aGVuIEknbSBkb25lIGJ1aWxkaW5nIGFuZCBjb3B5IHRoYXQgZmlsZSBpbnRv IHBhc3RlYmluLgo+Pgo+PiBSdXNzCj4+Cj4+IFNlbnQgZnJvbSBteSBCbGFja0JlcnJ5IDEwIHNt YXJ0cGhvbmUgb24gdGhlIEtvb2RvIG5ldHdvcmsuCj4+ICpGcm9tOiAqSGVybWluaW8gSGVybmFu ZGV6LCBKci4KPj4gKlNlbnQ6ICpNb25kYXksIEp1bHkgMjUsIDIwMTYgMTE6MTMgUE0KPj4gKlRv OiAqUnVzc2VsbCBIYWxleQo+PiAqU3ViamVjdDogKlJlOiBycGkyIGFzIHdpcmVsZXNzIHJvdXRl cgo+Pgo+PiBEbyB5b3Ugd2FudCB0aGUgZW50aXJlIG91dHB1dCBhZnRlciBtYWtlIGJ1aWxka2Vy bmVsPwo+Pgo+PiBPbiBNb24sIEp1bCAyNSwgMjAxNiBhdCA5OjM2IFBNLCBSdXNzZWxsIEhhbGV5 IDxydXNzLmhhbGV5QGdtYWlsLmNvbT4KPj4gd3JvdGU6Cj4+Cj4+PiDigI5Tb3JyeSBmb3IgdG9w IHBvc3QsCj4+Pgo+Pj4gQ2FuIHlvdSBzY3JpcHQgeW91ciBidWlsZCBvdXRwdXQgYW5kIHBvc3Qg aXQgaW4gcGFzdGViaW4/Cj4+Pgo+Pj4gUnVzcwo+Pj4KPj4+IFNlbnQgZnJvbSBteSBCbGFja0Jl cnJ5IDEwIHNtYXJ0cGhvbmUgb24gdGhlIEtvb2RvIG5ldHdvcmsuCj4+PiAqRnJvbTogKkhlcm1p bmlvIEhlcm5hbmRleiwgSnIuCj4+PiAqU2VudDogKk1vbmRheSwgSnVseSAyNSwgMjAxNiAxMDoy MSBQTQo+Pj4gKlRvOiAqUnVzc2VsbCBIYWxleQo+Pj4gKlN1YmplY3Q6ICpSZTogcnBpMiBhcyB3 aXJlbGVzcyByb3V0ZXIKPj4+Cj4+PiBBbGwsCj4+Pgo+Pj4gSSB3YW50IHRvIGNvbXBpbGUgdGhl IGtlcm5lbCB0byBlbmFibGUgd2xhbmRlYnVnIG9uIHRoZSBycGkyLiBJIGZvbGxvd2VkCj4+PiB0 aGlzICpleGFtcGxlCj4+PiA8aHR0cDovL2Jsb2cua2h1YmxhLmNvbS9mcmVlYnNkL2Nyb3NzLWNv bXBpbGluZy1mcmVlYnNkLWFybS1vbi1hbWQtNjQ+LCAqaG93ZXZlcgo+Pj4gaW4gdGhlIGVuZCBJ IGFtIG5vdCBzZWVpbmcgYW4gLmtvIGZpbGVzLiBJcyB0aGVyZSBhIHN0ZXAgSSBhbSBtaXNzaW5n Pwo+Pj4KPj4+IENhbiB5b3Ugc2NyaXB0IHlvdXIgYnVpbGQgb3V0cHV0IGFuZCBwb3N0IGl0IGlu IHBhc3RlYmluPwo+Pj4KPj4+IE9uIFN1biwgSnVsIDI0LCAyMDE2IGF0IDEwOjM0IFBNLCBIZXJt aW5pbyBIZXJuYW5kZXogSnIgPAo+Pj4gaGVybWluaW8uaGVybmFuZGV6anJAZ21haWwuY29tPiB3 cm90ZToKPj4+Cj4+Pj4gT24gMDcvMjQsIFJ1c3NlbGwgSGFsZXkgd3JvdGU6Cj4+Pj4gPiBDb3Vs ZCBJIHNlZSB5b3VyIFBDQVAgZmlsZXM/IEknbSBubyBleHBlcnQgYnV0IEknbSByZWFsbHkgY3Vy aW91cy4KPj4+PiA+Cj4+Pj4gPiBUaGFua3MgUnVzcwo+Pj4+IEkgaGF2ZSB0aGVtIGF0dGFjaGVk Lgo+Pj4+Cj4+Pj4gSGVybWluaW8KPj4+PiA+Cj4+Pj4gPiBTZW50IGZyb20gbXkgQmxhY2tCZXJy eSAxMCBzbWFydHBob25lIG9uIHRoZSBLb29kbyBuZXR3b3JrLgo+Pj4+ID4gICBPcmlnaW5hbCBN ZXNzYWdlCj4+Pj4gPiBGcm9tOiBIZXJtaW5pbyBIZXJuYW5kZXogSnIKPj4+PiA+IFNlbnQ6IFN1 bmRheSwgSnVseSAyNCwgMjAxNiA4OjIzIFBNCj4+Pj4gPiBUbzogQW5kcml5IFZvc2tvYm9pbnlr Cj4+Pj4gPiBDYzogQWRyaWFuIENoYWRkOyBmcmVlYnNkLWFybUBmcmVlYnNkLm9yZwo+Pj4+ID4g U3ViamVjdDogUmU6IHJwaTIgYXMgd2lyZWxlc3Mgcm91dGVyCj4+Pj4gPgo+Pj4+ID4gT24gMDcv MjQsIEFuZHJpeSBWb3Nrb2JvaW55ayB3cm90ZToKPj4+PiA+ID4gVGh1LCAyMSBKdWwgMjAxNiAw Njo1NjoyMiArMDMwMCDQsdGD0LvQviDQvdCw0L/QuNGB0LDQvdC+IEhlcm1pbmlvIEhlcm5hbmRl eiBKci4KPj4+PiA+ID4gPGhlcm1pbmlvLmhlcm5hbmRlempyQGdtYWlsLmNvbT46Cj4+Pj4gPiA+ Cj4+Pj4gPiA+IEFub3RoZXIgaWRlYTogdHJ5IHRvIGFkZAo+Pj4+ID4gPiBody51c2IudXJ0d24u ZW5hYmxlXzExbj0iMCIKPj4+PiA+ID4gaW50byAvYm9vdC9sb2FkZXIuY29uZiAoYW5kIHJlYm9v dCkuCj4+Pj4gPiA+IChkZXNjcmliZWQgYXMgImRvd25sb2FkIHNwZWVkIiBmaXggaW4KPj4+PiA+ ID4gaHR0cHM6Ly9mb3J1bXMuZnJlZWJzZC5vcmcvdGhyZWFkcy80ODczNy8gLQo+Pj4+ID4gPiBi dXQgbWF5IGhlbHAgaGVyZSB0b28pLgo+Pj4+ID4gPgo+Pj4+ID4gVGhlIHNhbWUgaXNzdWUuIERl YmlhbiBpcyBub3Qgc2VlaW5nIHRoZSBESENQIE9mZmVyIGZyb20gZnJlZWJzZC4KPj4+PiA+ID4g PiBObyBzYW1lIGlzc3VlLiBJIGFtIHdpbGxpbmcgdG8gaGVscCBpbiBhbnkgd2F5IEkgY2FuLiBJ IGNhbiBzZW5kCj4+Pj4geW91IHRoZQo+Pj4+ID4gPiA+IHBjYXAgZmlsZXMgSSBtYWRlLgo+Pj4+ ID4gPiA+Cj4+Pj4gPiA+ID4gU2VudCBmcm9tIG15IGlQaG9uZQo+Pj4+ID4gPiA+Cj4+Pj4gPiA+ ID4gPiBPbiBKdWwgMjAsIDIwMTYsIGF0IDg6MDQgUE0sIEFkcmlhbiBDaGFkZCA8Cj4+Pj4gYWRy aWFuLmNoYWRkQGdtYWlsLmNvbT4KPj4+PiA+ID4gPiA+IHdyb3RlOgo+Pj4+ID4gPiA+ID4KPj4+ PiA+ID4gPiA+IEhpLAo+Pj4+ID4gPiA+ID4KPj4+PiA+ID4gPiA+IE9rLiBXZSdsbCBoYXZlIHRv IHNldCB1cCBhIHRlc3QgZW52aXJvbm1lbnQgaGVyZSB0byBzZWUgd2hhdCdzCj4+Pj4gZ29pbmcK Pj4+PiA+ID4gPiA+IG9uLCBjb21wbGV0ZSB3aXRoIHNvbWUgcGFja2V0IHNuaWZmaW5nLgo+Pj4+ ID4gPiA+ID4KPj4+PiA+ID4gPiA+IFF1ZXN0aW9uIC0gaWYgeW91IGNvbmZpZ3VyZSB1cCBob3N0 YXAgdG8gYmUgb3Blbi9ubwo+Pj4+IGF1dGhlbnRpY2F0aW9uLAo+Pj4+ID4gPiA+ID4gZG9lcyBp dCBhbGwgd29yaz8KPj4+PiA+ID4gPiA+Cj4+Pj4gPiA+ID4gPgo+Pj4+ID4gPiA+ID4gLWEKPj4+ Pgo+Pj4KPj4+Cj4+Pgo+Pgo+Pgo+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmZyZWVic2QtYXJtQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdApodHRwczov L2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcm0KVG8gdW5zdWJz Y3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtYXJtLXVuc3Vic2NyaWJlQGZyZWVic2Qu b3JnIg== From owner-freebsd-arm@freebsd.org Tue Jul 26 14:56:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E535BA4EE5; Tue, 26 Jul 2016 14:56:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD6515C6; Tue, 26 Jul 2016 14:56:12 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6QEu9ln012679 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Jul 2016 07:56:10 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> Cc: Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" From: Nathan Whitehorn Message-ID: Date: Tue, 26 Jul 2016 07:56:09 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57976867.6080705@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaniCWrbJX6qqHh22bYhEhWifzY8aePNVKjBopjasWF9M3oXmzYWVnt0Cr9bHpsUzjkB2nOfrKUTUEkOrKfAyUbcNU17NW4YS0= X-Sonic-ID: C;PlpNFkFT5hGHx5tMTlz00w== M;4ry0FkFT5hGHx5tMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 14:56:13 -0000 On 07/26/16 06:40, Michal Meloun wrote: > Dne 26.07.2016 v 7:41 Nathan Whitehorn napsal(a): >> >> On 07/25/16 21:24, Warner Losh wrote: >>> On Mon, Jul 25, 2016 at 10:48 AM, Nathan Whitehorn >>> wrote: >>>> On 07/25/16 09:32, Warner Losh wrote: >>>>> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn >>>>> wrote: >>>>>> That wasn't my question. Are these particular device drivers >>>>>> allocating >>>>>> interrupts both on the GPIOs in their "interrupts" property (which >>>>>> are >>>>>> entirely GPIOs in this example) *and* on the GPIOs listed as >>>>>> resources >>>>>> but >>>>>> not listed as interrupts? If they are, then you need a switching >>>>>> mechanism, >>>>>> but that seems pretty unlikely given the names of the >>>>>> non-interrupt GPIOs >>>>>> (they look like outputs). It would also be a somewhat deranged way >>>>>> to set >>>>>> up >>>>>> a device tree -- not that that rules it out or anything. >>>>> On Atmel, there's a situation that this covers, I think. >>>>> >>>>> The MCI device has an interrupt in the core: >>>>> >>>>> mmc0: mmc@fffa8000 { >>>>> compatible = "atmel,hsmci"; >>>>> reg = <0xfffa8000 0x600>; >>>>> interrupts = <9 >>>>> IRQ_TYPE_LEVEL_HIGH 0>; >>>>> #address-cells = <1>; >>>>> #size-cells = <0>; >>>>> pinctrl-names = "default"; >>>>> clocks = <&mci0_clk>; >>>>> clock-names = "mci_clk"; >>>>> status = "disabled"; >>>>> }; >>>>> >>>>> and in other places wires in GPIO interrupts for things like card >>>>> eject / insertion. >>>>> >>>>> mmc0: mmc@f0008000 { >>>>> pinctrl-0 = < >>>>> &pinctrl_board_mmc0 >>>>> >>>>> &pinctrl_mmc0_slot0_clk_cmd_dat0 >>>>> &pinctrl_mmc0_slot0_dat1_3>; >>>>> status = "okay"; >>>>> slot@0 { >>>>> reg = <0>; >>>>> bus-width = <4>; >>>>> cd-gpios = <&pioD 15 >>>>> GPIO_ACTIVE_HIGH>; >>>>> }; >>>>> }; >>>>> >>>>> an interrupt is registered on the cd-gpios pin for when the card >>>>> changes. >>>>> At >>>>> least in linux, FreeBSD doesn't (yet) implement this, but will >>>>> someday if >>>>> I get >>>>> back to the armv6 atmel work I started (see at91-cosino.dts for >>>>> example, >>>>> there's >>>>> others). >>>>> >>>>> I think this is an example of what you are asking about, or did I get >>>>> lost in the >>>>> twisty maze of conversation zigs and zags... >>>>> >>>>> Warner >>>>> >>>> Where we would run into (minor) problems is if the interrupt parent >>>> for the >>>> first mmc0 is the GPIO controller. More generally, if &pioD has >>>> interrupt >>>> children specified in some way that is not a >>> high/whatever> >>>> tuple somewhere else in the tree then you would have to have methods to >>>> parse both interrupt specifiers >>>> as-obtained-from-interrupts-properties (or >>>> equivalent) and specifiers as-obtained-from-gpio-properties. If the >>>> tree >>>> picks one format and sticks with it, you can get away with just the >>>> one. >>>> Glancing through the DTS source for this board, that doesn't appear >>>> to be >>>> the case and the property formatting is uniform, but I might have >>>> missed >>>> something in one of the many #includes. >>> Interrupts and GPIO specifiers are different in subtle ways. The >>> interrupt >>> parent for mmc0 is an AIC, which is also the ultimate parent of the GPIO >>> controller. >> That is what it looked like. >> >>> But the properties for the GPIO pins that act as interrupts and >>> the interrupt specifiers are different. >> So there are devices with both interrupts = , >> #interrupt-parent = <&gpio> and gpios = <&gpio bleh baz> where "Bleh >> baz" is formatted different than "foo bar" and both are meant to be >> treated as interrupts? >> >> It's fine if there are, but I haven't seen any such device trees yet. > I think that yes, but I'm not ready to search all 1372 Linux DT files > only for explicit example. > But your question is invalid from beginning. > 1) Format of each single 'interrupts' and '*-gpios' property is > different because each single one are defined differently. > 2) The question should not be 'Are there device' but 'Is this > combination valid' > > Moreover, I'm curious why you want OFW property for gpio interrupts at all, > given gpio can be instantiated by other entity (PCIe, USB). > > Please see: > https://svnweb.freebsd.org/base/head/sys/dev/gpio/gpiobus.c?revision=301539&view=markup#l92 > and, for example this one controller > https://svnweb.freebsd.org/base/head/sys/arm/nvidia/tegra_gpio.c?revision=300149&view=markup#l575 Well, it's part of the device tree standard, so dealing with GPIO properties seems reasonable where they occur. You could, of course, have systems without device trees and GPIOs. I'm not sure where you are going with this. > >>>> As a general point, GPIO weirdness would be easy enough case to >>>> handle if it >>>> did come up (add some mapping method, as above) that I think we >>>> shouldn't >>>> worry too much about it from an architectural point of view. If a board >>>> appears that is set up this way, we can roll with the punches at >>>> that point >>>> and add whatever small amount of shim code that is required. It >>>> would be >>>> annoyance, sure, but not a real complication. >>> I suspect that either I don't understand the issue, or we'll have >>> such boards >>> very quickly. The Atmel design is fairly clean in comparison to other >>> franken-horrors >>> I've seen... >> People do weird things for sure. My point is just that the details of >> how (implicit) GPIO interrupts are formatted just isn't that >> important. It's easy enough to add special code for devices that are >> set up in bizarre ways as they are spotted in the wild and that >> special code is so minor that it doesn't matter for the design of the >> API. This is a point I was just curious about, since I had never >> actually seen device trees set up that way. >> >> The issue with this patch is, at its core, whether you have an >> architecture that relies on the newbus hierarchy (like r301453) or >> that allows links outside of that hierarchy that can cross branches or >> go the "wrong" way, like the previously existing code. > OK. The r301453 : > - it removes unnecessary idea of virtual IRQs. I gave you some examples > where virtual IRQ concept fails. I have never seen any of these examples. The concept is *extremely* necessary, which is why both Linux and FreeBSD decided to use it independently There is no way to handle parent buses with a single rman and devices on multiple PICs with overlapping interrupt ranges without them; neither is there a way to decode arbitrary-length interrupt specifiers or to handle things like MSIs. Please see the list of cases at https://wiki.freebsd.org/Complicated_Interrupts and in my earlier email for some examples of things that you just can't represent with this new system, as far as I can tell. > Also, both variants needs attached PIC at bus_alloc_resource() time, > so timing wasn't been changed. They absolutely do not, as I have explained repeatedly. Due to parent devices with interrupts handled by their bus children, this is a hard requirement of any workable system. This is not a theoretical issue; I have lots of hardware like this. > > - it implements new BUS_MAP_INTR(). As I understand it, this is > problematic for you, and I'm ready to change it. But I need more details > than "it's fundamentally broken". Please explain (a) what cases it handles that the existing code and does, and (b) how you would resolve each of the cases on the wiki page I sent. The general issue is that it traces the newbus hierarchy, when interrupts often do not, and so breaks when you have links to as-yet-unattached parts of the hierarchy. It also relies on the assigned "IRQ" numbers being nonoverlapping to avoid rman errors, but that's a relatively minor thing. > >> There are some other differences, of varying degrees of importance, >> but that's the really fundamental one. I haven't seen any cases where >> r301453 provides functionality absent in the already existing system, >> but there seem to be a large number of cases (see the first email I >> sent to freebsd-arch or >> https://wiki.freebsd.org/Complicated_Interrupts) that the API in >> r301453 cannot accommodate and that are needed to support a variety of >> hardware. > Which single feature has been removed by r301453? Nothing has been removed by it, because the normal code is intact. However, the new code is less functional than the old code, so cannot replace it. In particular, it is architecturally incapable of working with the kinds of device trees found on PowerPC systems (see the wiki page). That means we would have to keep both indefinitely, which is a significant maintenance burden to no gain whatsoever. -Nathan > Michal > >> Since having two APIs will be a significant maintenance burden, if >> there are cases the existing code can't handle, I would like to know >> about them; otherwise, I think we should back out r301453 and stick to >> the standard device tree interrupt mapping mechanism on ARM instead. >> I'm happy to help implement any necessary enhancements there (for >> example, dealing with weirdly-encoded GPIOs). >> -Nathan >> >>> Warner >>> From owner-freebsd-arm@freebsd.org Tue Jul 26 17:42:54 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9295BA599A for ; Tue, 26 Jul 2016 17:42:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 C956C156B for ; Tue, 26 Jul 2016 17:42:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6QHgslS061859 for ; Tue, 26 Jul 2016 17:42:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 211389] Translation Fault (L1) when executing a DTrace script Date: Tue, 26 Jul 2016 17:42:54 +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-BETA2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: venture37@geeklan.co.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org 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 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 17:42:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211389 Bug ID: 211389 Summary: Translation Fault (L1) when executing a DTrace script Product: Base System Version: 11.0-BETA2 Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: venture37@geeklan.co.uk Executing the following one liner on a Raspberry Pi (type B, 256MB RAM) res= ults in a Translation Fault (L1) error & the system reboots dtrace -n 'fbt:kernel:*_interrupt:entry { @m[execname] =3D count() }' login: IMPLEMENT ME: dtrace_toxic_ranges Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc12fbad8 FSR=3D00000005, FAR=3Dbfbfebc0, spsr=3D60000193 r0 =3Dc2132de8, r1 =3Dc12fbb98, r2 =3D00000000, r3 =3Dbfbfebc0 r4 =3Dc2598bc0, r5 =3Dc2132f00, r6 =3Dc01ba5c0, r7 =3Dc1b50670 r8 =3Dc12fbc90, r9 =3Dc1ab5370, r10=3Dc1b4a000, r11=3Dc12fbb78 r12=3D00000000, ssp=3Dc12fbb68, slr=3Dc215a39c, pc =3Dc219324c running the stock FreeBSD 11.0-BETA2 r303168 image. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Jul 27 16:27:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7F47BA6EEB; Wed, 27 Jul 2016 16:27:58 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 42F7A1957; Wed, 27 Jul 2016 16:27:57 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 3A17C3AC87; Wed, 27 Jul 2016 18:27:49 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> Cc: Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <5798E104.5020104@FreeBSD.org> Date: Wed, 27 Jul 2016 18:27:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Wed, 27 Jul 2016 18:27:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 16:27:58 -0000 Dne 26.07.2016 v 16:56 Nathan Whitehorn napsal(a): > > > On 07/26/16 06:40, Michal Meloun wrote: >> Dne 26.07.2016 v 7:41 Nathan Whitehorn napsal(a): >>> >>> On 07/25/16 21:24, Warner Losh wrote: >>>> On Mon, Jul 25, 2016 at 10:48 AM, Nathan Whitehorn >>>> wrote: >>>>> On 07/25/16 09:32, Warner Losh wrote: >>>>>> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn >>>>>> wrote: >>>>>>> That wasn't my question. Are these particular device drivers >>>>>>> allocating >>>>>>> interrupts both on the GPIOs in their "interrupts" property (which >>>>>>> are >>>>>>> entirely GPIOs in this example) *and* on the GPIOs listed as >>>>>>> resources >>>>>>> but >>>>>>> not listed as interrupts? If they are, then you need a switching >>>>>>> mechanism, >>>>>>> but that seems pretty unlikely given the names of the >>>>>>> non-interrupt GPIOs >>>>>>> (they look like outputs). It would also be a somewhat deranged way >>>>>>> to set >>>>>>> up >>>>>>> a device tree -- not that that rules it out or anything. >>>>>> On Atmel, there's a situation that this covers, I think. >>>>>> >>>>>> The MCI device has an interrupt in the core: >>>>>> >>>>>> mmc0: mmc@fffa8000 { >>>>>> compatible = "atmel,hsmci"; >>>>>> reg = <0xfffa8000 0x600>; >>>>>> interrupts = <9 >>>>>> IRQ_TYPE_LEVEL_HIGH 0>; >>>>>> #address-cells = <1>; >>>>>> #size-cells = <0>; >>>>>> pinctrl-names = "default"; >>>>>> clocks = <&mci0_clk>; >>>>>> clock-names = "mci_clk"; >>>>>> status = "disabled"; >>>>>> }; >>>>>> >>>>>> and in other places wires in GPIO interrupts for things like card >>>>>> eject / insertion. >>>>>> >>>>>> mmc0: mmc@f0008000 { >>>>>> pinctrl-0 = < >>>>>> &pinctrl_board_mmc0 >>>>>> >>>>>> &pinctrl_mmc0_slot0_clk_cmd_dat0 >>>>>> >>>>>> &pinctrl_mmc0_slot0_dat1_3>; >>>>>> status = "okay"; >>>>>> slot@0 { >>>>>> reg = <0>; >>>>>> bus-width = <4>; >>>>>> cd-gpios = <&pioD 15 >>>>>> GPIO_ACTIVE_HIGH>; >>>>>> }; >>>>>> }; >>>>>> >>>>>> an interrupt is registered on the cd-gpios pin for when the card >>>>>> changes. >>>>>> At >>>>>> least in linux, FreeBSD doesn't (yet) implement this, but will >>>>>> someday if >>>>>> I get >>>>>> back to the armv6 atmel work I started (see at91-cosino.dts for >>>>>> example, >>>>>> there's >>>>>> others). >>>>>> >>>>>> I think this is an example of what you are asking about, or did I >>>>>> get >>>>>> lost in the >>>>>> twisty maze of conversation zigs and zags... >>>>>> >>>>>> Warner >>>>>> >>>>> Where we would run into (minor) problems is if the interrupt parent >>>>> for the >>>>> first mmc0 is the GPIO controller. More generally, if &pioD has >>>>> interrupt >>>>> children specified in some way that is not a >>>> high/whatever> >>>>> tuple somewhere else in the tree then you would have to have >>>>> methods to >>>>> parse both interrupt specifiers >>>>> as-obtained-from-interrupts-properties (or >>>>> equivalent) and specifiers as-obtained-from-gpio-properties. If the >>>>> tree >>>>> picks one format and sticks with it, you can get away with just the >>>>> one. >>>>> Glancing through the DTS source for this board, that doesn't appear >>>>> to be >>>>> the case and the property formatting is uniform, but I might have >>>>> missed >>>>> something in one of the many #includes. >>>> Interrupts and GPIO specifiers are different in subtle ways. The >>>> interrupt >>>> parent for mmc0 is an AIC, which is also the ultimate parent of the >>>> GPIO >>>> controller. >>> That is what it looked like. >>> >>>> But the properties for the GPIO pins that act as interrupts and >>>> the interrupt specifiers are different. >>> So there are devices with both interrupts = , >>> #interrupt-parent = <&gpio> and gpios = <&gpio bleh baz> where "Bleh >>> baz" is formatted different than "foo bar" and both are meant to be >>> treated as interrupts? >>> >>> It's fine if there are, but I haven't seen any such device trees yet. >> I think that yes, but I'm not ready to search all 1372 Linux DT files >> only for explicit example. >> But your question is invalid from beginning. >> 1) Format of each single 'interrupts' and '*-gpios' property is >> different because each single one are defined differently. >> 2) The question should not be 'Are there device' but 'Is this >> combination valid' >> >> Moreover, I'm curious why you want OFW property for gpio interrupts >> at all, >> given gpio can be instantiated by other entity (PCIe, USB). >> >> Please see: >> https://svnweb.freebsd.org/base/head/sys/dev/gpio/gpiobus.c?revision=301539&view=markup#l92 >> >> and, for example this one controller >> https://svnweb.freebsd.org/base/head/sys/arm/nvidia/tegra_gpio.c?revision=300149&view=markup#l575 >> > > Well, it's part of the device tree standard, so dealing with GPIO > properties seems reasonable where they occur. You could, of course, > have systems without device trees and GPIOs. I'm not sure where you > are going with this. > >> >>>>> As a general point, GPIO weirdness would be easy enough case to >>>>> handle if it >>>>> did come up (add some mapping method, as above) that I think we >>>>> shouldn't >>>>> worry too much about it from an architectural point of view. If a >>>>> board >>>>> appears that is set up this way, we can roll with the punches at >>>>> that point >>>>> and add whatever small amount of shim code that is required. It >>>>> would be >>>>> annoyance, sure, but not a real complication. >>>> I suspect that either I don't understand the issue, or we'll have >>>> such boards >>>> very quickly. The Atmel design is fairly clean in comparison to other >>>> franken-horrors >>>> I've seen... >>> People do weird things for sure. My point is just that the details of >>> how (implicit) GPIO interrupts are formatted just isn't that >>> important. It's easy enough to add special code for devices that are >>> set up in bizarre ways as they are spotted in the wild and that >>> special code is so minor that it doesn't matter for the design of the >>> API. This is a point I was just curious about, since I had never >>> actually seen device trees set up that way. >>> >>> The issue with this patch is, at its core, whether you have an >>> architecture that relies on the newbus hierarchy (like r301453) or >>> that allows links outside of that hierarchy that can cross branches or >>> go the "wrong" way, like the previously existing code. >> OK. The r301453 : >> - it removes unnecessary idea of virtual IRQs. I gave you some examples >> where virtual IRQ concept fails. > > I have never seen any of these examples. See [1]. > > The concept is *extremely* necessary, which is why both Linux and > FreeBSD decided to use it independently There is no way to handle > parent buses with a single rman and devices on multiple PICs with > overlapping interrupt ranges without them; neither is there a way to > decode arbitrary-length interrupt specifiers or to handle things like > MSIs. Please see the list of cases at > https://wiki.freebsd.org/Complicated_Interrupts and in my earlier > email for some examples of things that you just can't represent with > this new system, as far as I can tell. > >> Also, both variants needs attached PIC at bus_alloc_resource() time, >> so timing wasn't been changed. > > They absolutely do not, as I have explained repeatedly. Due to parent > devices with interrupts handled by their bus children, this is a hard > requirement of any workable system. This is not a theoretical issue; I > have lots of hardware like this. Nathan, I'm talking about pre /post r301453 state. Current INTRNG it has never supported. But yes, I'm fully understand why you want it. See [2]. > >> >> - it implements new BUS_MAP_INTR(). As I understand it, this is >> problematic for you, and I'm ready to change it. But I need more details >> than "it's fundamentally broken". > > Please explain (a) what cases it handles that the existing code and > does, and (b) how you would resolve each of the cases on the wiki page > I sent. > > The general issue is that it traces the newbus hierarchy, when > interrupts often do not, and so breaks when you have links to > as-yet-unattached parts of the hierarchy. It also relies on the > assigned "IRQ" numbers being nonoverlapping to avoid rman errors, but > that's a relatively minor thing. Well, from my point of view, only "get interrupt data from OFW/GPIO/.." part of bus_alloc_resource() follows bus hierarchy, real execution not changed. In any case, I see many possible variants how we can modify current implementation. For rest, see [2]. > >> >>> There are some other differences, of varying degrees of importance, >>> but that's the really fundamental one. I haven't seen any cases where >>> r301453 provides functionality absent in the already existing system, >>> but there seem to be a large number of cases (see the first email I >>> sent to freebsd-arch or >>> https://wiki.freebsd.org/Complicated_Interrupts) that the API in >>> r301453 cannot accommodate and that are needed to support a variety of >>> hardware. >> Which single feature has been removed by r301453? > > Nothing has been removed by it, because the normal code is intact. > However, the new code is less functional than the old code, so cannot > replace it. In particular, it is architecturally incapable of working > with the kinds of device trees found on PowerPC systems (see the wiki > page). That means we would have to keep both indefinitely, which is a > significant maintenance burden to no gain whatsoever. > -Nathan Firstly, please, ignore dependency problem. It will be explained later in [2]. [1] The original (your) INTRNG assume several things: - value of interrupt parent xref together with byte contents of 'interrupts' property forms some sort of 'key' (aka virtual IRQ) - byte contents of 'interrupts' property cannot be parsed in any way inside INTRNG core. - data forming this key are sufficient for subsequent mapping (and/or configuring) to real IRQ. - there must exist bidirectional unique relation between virtual and real IRQs. So one key (virtual IRQ) can be mappable to one and just one real IRQ. And only one virtual IRQ can be mapped to any given real IRQ. - we have cache that stores all observed 'keys' and associated real IRQ ) the they already mapped. Unfortunately, necessity of unique mapping is very problematic. We cannot handle situation, where shared interrupt is declared by different but compatible 'interrupts' properties. For example: ------------------------- foo1: bar@12345678 { interrupt-parent = <&pic1>; interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; } foo2: bar@1234567C { interrupt-parent = <&pic1>; interrupts = <1 IRQ_TYPE_NONE>; } Is this valid (from DT point of view) configuration? I think that yes. Is this frequent configuration? I'm sure, isn't. Is this possible configuration? I'm afraid that yes. -------------------------- Next example are GPIO interrupts. These are encoded differently, so two 'keys' may point to to same real IRQ. After that we decided to change our approach and utilize standard resources and resource list entries to deliveryconfiguration data from various sources (OFW/GPIO/...) to consumers. [2] Each OFW device has a lot of dependencies. It must enable clocks, power regulators..., it must be taken from reset. All these action must be done before we can access single register. Most of these action can be done only with attached clock/power/reset controller. Within this, interrupts are not special. Moreover, 'cross type' circular dependencies are not that rare. I want to say: Resource dependencies are must solved (and resolved) at different level than is INTRNG. Blind resource allocation is not universal solution because given resource may/must be accessible immediately after allocation (in many cases). Unfortunately, and at time time, I known only one really working solution: staggered driver initialization combined with multipass bus initialization. I'm sorry, I'm not able to express all this accurately and clearly, but I've really tried... Michal From owner-freebsd-arm@freebsd.org Wed Jul 27 17:31:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29B7FBA6F84; Wed, 27 Jul 2016 17:31:41 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2C5A16D0; Wed, 27 Jul 2016 17:31:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6RHJfQN032767 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Jul 2016 10:19:41 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: Date: Wed, 27 Jul 2016 10:19:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5798E104.5020104@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbQ0VGJh58dOgo9QFfuMJ7LNjMiw2aRGURT+ReQNg4twk6TiYUaVL4uTDA1IPPZ383KRl5eyuc0gDpaxPYFvlIMm6I0g5BUCYM= X-Sonic-ID: C;rKnFTR5U5hGPcpNwxPCmMQ== M;tjkDTh5U5hGPcpNwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 17:31:41 -0000 On 07/27/16 09:27, Michal Meloun wrote: [snip] >> The concept is *extremely* necessary, which is why both Linux and >> FreeBSD decided to use it independently There is no way to handle >> parent buses with a single rman and devices on multiple PICs with >> overlapping interrupt ranges without them; neither is there a way to >> decode arbitrary-length interrupt specifiers or to handle things like >> MSIs. Please see the list of cases at >> https://wiki.freebsd.org/Complicated_Interrupts and in my earlier >> email for some examples of things that you just can't represent with >> this new system, as far as I can tell. >> >>> Also, both variants needs attached PIC at bus_alloc_resource() time, >>> so timing wasn't been changed. >> They absolutely do not, as I have explained repeatedly. Due to parent >> devices with interrupts handled by their bus children, this is a hard >> requirement of any workable system. This is not a theoretical issue; I >> have lots of hardware like this. > Nathan, I'm talking about pre /post r301453 state. Current INTRNG it > has never supported. But yes, I'm fully understand why you want it. See > [2]. Current "INTRNG", at least on PowerPC, has supported this for 10 years. If it doesn't on ARM, it's because of some trivial implementation bug. > >>> - it implements new BUS_MAP_INTR(). As I understand it, this is >>> problematic for you, and I'm ready to change it. But I need more details >>> than "it's fundamentally broken". >> Please explain (a) what cases it handles that the existing code and >> does, and (b) how you would resolve each of the cases on the wiki page >> I sent. >> >> The general issue is that it traces the newbus hierarchy, when >> interrupts often do not, and so breaks when you have links to >> as-yet-unattached parts of the hierarchy. It also relies on the >> assigned "IRQ" numbers being nonoverlapping to avoid rman errors, but >> that's a relatively minor thing. > Well, from my point of view, only "get interrupt data from > OFW/GPIO/.." part of bus_alloc_resource() follows bus hierarchy, real > execution not changed. > In any case, I see many possible variants how we can modify current > implementation. For rest, see [2]. But that's an important part, for three reasons: 1. The PIC may not exist when bus_alloc_resource() is called 2. The bus parents have no useful information to contribute to this since the hierarchy doesn't go that way 3. If you try to use the interrupt pin as the resource ID, which r301453 does, you end up with rman conflicts if, for example, a bus has two children with interrupts on identically numbered pins on two different interrupt controllers. > >>> >>>> There are some other differences, of varying degrees of importance, >>>> but that's the really fundamental one. I haven't seen any cases where >>>> r301453 provides functionality absent in the already existing system, >>>> but there seem to be a large number of cases (see the first email I >>>> sent to freebsd-arch or >>>> https://wiki.freebsd.org/Complicated_Interrupts) that the API in >>>> r301453 cannot accommodate and that are needed to support a variety of >>>> hardware. >>> Which single feature has been removed by r301453? >> Nothing has been removed by it, because the normal code is intact. >> However, the new code is less functional than the old code, so cannot >> replace it. In particular, it is architecturally incapable of working >> with the kinds of device trees found on PowerPC systems (see the wiki >> page). That means we would have to keep both indefinitely, which is a >> significant maintenance burden to no gain whatsoever. >> -Nathan > Firstly, please, ignore dependency problem. It will be explained later > in [2]. Except that that isn't a workable solution (see the end) > > [1] > The original (your) INTRNG assume several things: > > - value of interrupt parent xref together with byte contents of > 'interrupts' property forms some sort of 'key' (aka virtual IRQ) > - byte contents of 'interrupts' property cannot be parsed in any way > inside INTRNG core. > - data forming this key are sufficient for subsequent mapping (and/or > configuring) to real IRQ. > - there must exist bidirectional unique relation between virtual and > real IRQs. So one key (virtual IRQ) can be mappable to one and just one > real IRQ. And only one virtual IRQ can be mapped to any given real > IRQ. > - we have cache that stores all observed 'keys' and associated real IRQ > ) the they already mapped. > > Unfortunately, necessity of unique mapping is very problematic. > We cannot handle situation, where shared interrupt is declared by > different but compatible 'interrupts' properties. There isn't actually a requirement of bidirectional uniqueness, as I explained the last time you brought this up. One "virtual" IRQ does need to map to exactly one interrupt specifier, but the reverse is not the case. The PIC driver is absolutely free to map and dispatch multiple virtual IRQs from the same shared interrupt pin, with no more overhead than you usually get from shared interrupt lines. > > For example: > ------------------------- > foo1: bar@12345678 { > interrupt-parent = <&pic1>; > interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; > } > > foo2: bar@1234567C { > interrupt-parent = <&pic1>; > interrupts = <1 IRQ_TYPE_NONE>; > } > > Is this valid (from DT point of view) configuration? I think that yes. No, it's malformed and a violation of the standard. > Is this frequent configuration? I'm sure, isn't. > Is this possible configuration? I'm afraid that yes. People do in fact do deranged non-conformant things with device trees sometimes, unfortunately, so it is indeed worth worrying about. > -------------------------- > > Next example are GPIO interrupts. These are encoded differently, so two > 'keys' may point to to same real IRQ. > After that we decided to change our approach and utilize standard > resources and resource list entries to deliveryconfiguration data from > various sources (OFW/GPIO/...) to consumers. This is a non-issue. You make the GPIO controller a PIC, it handles interrupts however you like. If you got a weird device tree that uses two encodings (one for "interrupts" properties with GPIOs and one for "GPIO" properties on which you need to take interrupts but that weren't added to the "interrupts" list for mysterious reasons), you introduce a helper function for the GPIO case. Are there any actual problems with the pre-existing interrupt mapping code? I have not seen any so far. > [2] > Each OFW device has a lot of dependencies. It must enable clocks, power > regulators..., it must be taken from reset. All these action must be > done before we can access single register. > Most of these action can be done only with attached clock/power/reset > controller. > Within this, interrupts are not special. They are actually quite special in that the kernel enables them late and so you can defer setup. They are also special in that, for that reason, it is possible to design systems with circular dependency graphs with interrupts. It is not possible to do this with, for example, clocks: if I need to apply a clock to the clock controller with itself, the system is just not bootable and such a system will not be built or shipped. Interrupts need only happen later, after device setup, and so such systems *are* designed and shipped. The same is true for power. > Moreover, 'cross type' circular > dependencies are not that rare. > I want to say: > Resource dependencies are must solved (and resolved) at different level > than is INTRNG. > Blind resource allocation is not universal solution because given > resource may/must be accessible immediately after allocation (in many > cases). Absolutely: for GPIOs, clocks, power, etc. you want a system that looks different than the interrupt virtualization system. Probably with extra resource types and maybe with some API similar to r301453. But interrupts have different, and more complex, requirements and cannot be mapped this way. > > Unfortunately, and at time time, I known only one really working solution: > staggered driver initialization combined with multipass bus initialization. That does not solve the interrupt problem. If devices have interrupts on their own children, no amount of multipass initialization can possibly break the loop. Multipass would work for other kinds of resources (clocks, power, etc.) and is a perfect match for those resource types. A dynamic multipass (where a driver can return EAGAIN or something from attach if its resources don't exist yet) would work great. *But* in the specific, special case of interrupts, it is not a workable model. You could imagine some change to initialization that gives devices a late attach and an early attach method and does interrupts in the late part, but that is hugely invasive change that would need to touch every single driver in the tree -- to solve a problem that is already solved by interrupt virtualization. -Nathan > I'm sorry, I'm not able to express all this accurately and clearly, but > I've really tried... > Michal > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Wed Jul 27 18:20:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7655FBA6FAB for ; Wed, 27 Jul 2016 18:20:19 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FEF615F6 for ; Wed, 27 Jul 2016 18:20:19 +0000 (UTC) (envelope-from herminio.hernandezjr@gmail.com) Received: by mail-pf0-x235.google.com with SMTP id p64so13271332pfb.1 for ; Wed, 27 Jul 2016 11:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H+46P0EURQ5Zdb+5OHShYhXnzxVSFCe8pYn8ZO2NDXQ=; b=YMd0X9n0rZumgbfW+8x1SHdF0ocyZBv+5Aufh7E6MD22xpvYsPa7yh42awQETonYRk 7jrZIINA/IFFJymxOB60fRdZpGjHLX+vuzBm+0/BBY+UnCXckP2h86jH9m/MiEeaLGTz YDFMPsl0WurGEg2+2Tt+mQpyf6c04lZ32cPrUDa4Kd00AW6n+fxJuSV2otsePSHcwdQ2 RC4d8wEC0aM+TBarHG80NmKmCbz06FxtNyt52jDiQcqHqrjcPvF9pl1b+b8+7qXdfUj9 kxsDZ3A8LrVFqakLhb8IFiiJBxPd/lh+iHOym1lxv+RKk+upXXwQMqeV33K4+REdMq0i QC3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H+46P0EURQ5Zdb+5OHShYhXnzxVSFCe8pYn8ZO2NDXQ=; b=NPo+3K20PFnW13aApOxdDh0sv3e1gLEDlLLCt4ag2P0GZT2ZYdkiGyzblNRju7j02o tUkSkESGhOR1xaEjT7Eh/L2QCCNmL5heXIEB5+qe8jPH22rjgP2Hrqi5PdNZreEW26wI 5zT5+doN+NaCNzBPsEn5oY/wPr2/4HpLhDRgx1d3No+HGg0AUYEQnxzhrGajna9g4Yra 72pB3t9pr3M9KM5wdd/4+YcRghWkyCc0JHXhMVLxGMW+2RRFR1SJeOOkxGl1vryZqFBo 7gjnqn7mS8Fw67y4+OBote1p6+L4yJsCdhgUllDg1+XoknWt7UysMYvJ37NAh5x3rZCt w3dA== X-Gm-Message-State: AEkoouu089LcF9sz7TzT/O0nEDv+y4Ckgj369VN+C4dObEA6S7hP6DJJ8njy546OqVxKGg== X-Received: by 10.98.14.208 with SMTP id 77mr51720308pfo.23.1469643618629; Wed, 27 Jul 2016 11:20:18 -0700 (PDT) Received: from [192.168.255.77] (wsip-24-249-178-180.ph.ph.cox.net. [24.249.178.180]) by smtp.gmail.com with ESMTPSA id 15sm10905206pfz.36.2016.07.27.11.20.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Jul 2016 11:20:17 -0700 (PDT) Mime-Version: 1.0 (1.0) Subject: Re: rpi2 as wireless router From: "Herminio Hernandez Jr. " X-Mailer: iPhone Mail (13F69) In-Reply-To: <20160726052913.4907091.59991.9011@gmail.com> Date: Wed, 27 Jul 2016 11:20:16 -0700 Cc: freebsd-arm Message-Id: <24B1C2AB-EEA7-4A6E-AE3A-2BA3A6888E94@gmail.com> References: <4E1AB9F3-B7F8-49F3-BAD2-259584B04E3B@gmail.com> <20160725022255.GA6128@debian-macbookpro> <20160725050139.4907091.36565.8923@gmail.com> <20160725053414.GB6128@debian-macbookpro> <20160726043613.4907091.75531.9005@gmail.com> <20160726052913.4907091.59991.9011@gmail.com> To: Russell Haley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 18:20:19 -0000 Ok so I rebuilt the kernel to enable ieee80211_debug. So when run the comman= d wlandebug -d +dumppkts I am seeing nothing. Is there an option I am missin= g? Sent from my iPhone > On Jul 25, 2016, at 10:29 PM, Russell Haley wrote: >=20 > And your kernel toolchain build, and indicate the svn revision too. Possib= ly though on of the guys is going to see a problem in the example. Or you h= ave a revision that doesn't build because the example uses the head revision= . I've never exported my variables, so I can't talk to the validity of the e= xample (although I did comment about -j). >=20 > I just run=20 >=20 > script /tmp/buildout.txt >=20 > Svn info (I think?) > ... >=20 > And then exit when I'm done building and copy that file into pastebin.=20 >=20 > Russ >=20 > Sent from my BlackBerry 10 smartphone on the Koodo network. > From: Herminio Hernandez, Jr. > Sent: Monday, July 25, 2016 11:13 PM > To: Russell Haley > Subject: Re: rpi2 as wireless router >=20 > Do you want the entire output after make buildkernel? >=20 >> On Mon, Jul 25, 2016 at 9:36 PM, Russell Haley wro= te: >> =E2=80=8ESorry for top post, >>=20 >> Can you script your build output and post it in pastebin? >>=20 >> Russ >>=20 >> Sent from my BlackBerry 10 smartphone on the Koodo network. >> From: Herminio Hernandez, Jr. >> Sent: Monday, July 25, 2016 10:21 PM >> To: Russell Haley >> Subject: Re: rpi2 as wireless router >>=20 >> All, >>=20 >> I want to compile the kernel to enable wlandebug on the rpi2. I followed t= his example, however in the end I am not seeing an .ko files. Is there a ste= p I am missing? >>=20 >> Can you script your build output and post it in pastebin? >>=20 >>> On Sun, Jul 24, 2016 at 10:34 PM, Herminio Hernandez Jr wrote: >>> On 07/24, Russell Haley wrote: >>> > Could I see your PCAP files? I'm no expert but I'm really curious.=20 >>> > >>> > Thanks Russ >>> I have them attached. >>>=20 >>> Herminio >>> > >>> > Sent from my BlackBerry 10 smartphone on the Koodo network. >>> > Original Message =20 >>> > From: Herminio Hernandez Jr >>> > Sent: Sunday, July 24, 2016 8:23 PM >>> > To: Andriy Voskoboinyk >>> > Cc: Adrian Chadd; freebsd-arm@freebsd.org >>> > Subject: Re: rpi2 as wireless router >>> > >>> > On 07/24, Andriy Voskoboinyk wrote: >>> > > Thu, 21 Jul 2016 06:56:22 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Herminio Hernandez Jr. >>> > > : >>> > > >>> > > Another idea: try to add >>> > > hw.usb.urtwn.enable_11n=3D"0" >>> > > into /boot/loader.conf (and reboot). >>> > > (described as "download speed" fix in >>> > > https://forums.freebsd.org/threads/48737/ - >>> > > but may help here too). >>> > > >>> > The same issue. Debian is not seeing the DHCP Offer from freebsd. >>> > > > No same issue. I am willing to help in any way I can. I can send y= ou the >>> > > > pcap files I made. >>> > > > >>> > > > Sent from my iPhone >>> > > > >>> > > > > On Jul 20, 2016, at 8:04 PM, Adrian Chadd >>> > > > > wrote: >>> > > > > >>> > > > > Hi, >>> > > > > >>> > > > > Ok. We'll have to set up a test environment here to see what's g= oing >>> > > > > on, complete with some packet sniffing. >>> > > > > >>> > > > > Question - if you configure up hostap to be open/no authenticati= on, >>> > > > > does it all work? >>> > > > > >>> > > > > >>> > > > > -a >=20 >=20 From owner-freebsd-arm@freebsd.org Wed Jul 27 19:38:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BD36BA64D3; Wed, 27 Jul 2016 19:38:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D78911E5D; Wed, 27 Jul 2016 19:38:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id b62so79823326iod.3; Wed, 27 Jul 2016 12:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=63dXpzYpNTjTyhQYIGqSPAsI245KkU/gHEQP+yB1GQA=; b=rLebOTx3ZJTpySs/oPxZ24u4RUsT5E6R1uT/GKFeQ86Ul+fOjH7aoSBWrmuEejKLKv SB+ZG5VZDmkveMGgUgqq+jscnm976oHRH1kfLEjmd0idfLPQGUmMhexSKUdSziFmnyoj 5PdxwkBKuJrxjiXjTx8/jOfI9z2uoAIqYFeTZ85cTmYd4eMPBItNzVooAUe3UhhKWSkn 5n+8pId49qtM0sWfsQ8UT84MDzFYdHXB9gQqRVSGL/EzNj1QYvjfuJHNp0jqrvqWtd4+ XzBVE0uSr08HdGu4Jhf52TghldjBd09uymuCnXX3yFGp49LUTUSyLYJIKI9alrZ0Ncf5 9eyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=63dXpzYpNTjTyhQYIGqSPAsI245KkU/gHEQP+yB1GQA=; b=aPuGtII+DfrMeFDge887yxt5Tqy6I2OGYV660AddVdRw+2+qPWCwm4e1KhCy0O4V3t sUz5CxAsVOhSrhg9CbkcUx9UZmz3sYZyfymw+3EIh9je8rvA02uWZNY4AaNnnRAW7AEC /gEd7H7xJ2PQPNNp54L7iJOARJA3iZg18ejmbvxYBZ/dFz9RFmkVlUPpemdWx/M+WjEo FBcN2shXX9UjzumZhSA+UEj920oYC3ejZ+pP9plII/COFaf1XR0n1B6PK+wgX8gGUn+m yhY/sCoKEEfzo3k9PHf0DNxzJUf03GNG0R6ht/jEnVYbgKPCtDbAe09eKz/rEFXM0GuH oqrg== X-Gm-Message-State: AEkoouvuduXTmAPdgcCAKApwGQB48qERBuj/yP+sb9dEEKSVIzkVjBzYw60ufY1sGGQ4Ckuit50PSWSmmTlLrA== X-Received: by 10.107.144.10 with SMTP id s10mr32964662iod.165.1469648292079; Wed, 27 Jul 2016 12:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Wed, 27 Jul 2016 12:38:11 -0700 (PDT) In-Reply-To: References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> From: Adrian Chadd Date: Wed, 27 Jul 2016 12:38:11 -0700 Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 19:38:13 -0000 [snip] can the ARM specific bits be added to Nathan's wiki page describing interrupt stuff? I'd like to see some of this complication documented so people see the full variety of hilarity. Thanks! -adrian From owner-freebsd-arm@freebsd.org Wed Jul 27 21:38:30 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94439BA644F for ; Wed, 27 Jul 2016 21:38:30 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD981E82; Wed, 27 Jul 2016 21:38:30 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 86B2E12C; Wed, 27 Jul 2016 21:38:30 +0000 (UTC) Date: Wed, 27 Jul 2016 21:38:28 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bdrewery@FreeBSD.org, jhb@FreeBSD.org, stevek@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1617691874.20.1469655510563.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3711 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 21:38:30 -0000 FreeBSD_HEAD_arm64 - Build #3711 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3711/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3711/ch= anges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3711/con= sole Change summaries: 303411 by stevek: Prepare for network stack as a module - Move cr_canseeinpcb to sys/netinet/in_prot.c in order to separate the INET and INET6-specific code from the rest of the prot code (It is only used by the network stack, so it makes sense for it to live with the other network stack code.) - Move cr_canseeinpcb prototype from sys/systm.h to netinet/in_systm.h - Rename cr_seeotheruids to cr_canseeotheruids and cr_seeothergids to cr_canseeothergids, make them non-static, and add prototypes (so they can be seen/called by in_prot.c functions.) - Remove sw_csum variable from ip6_forward in ip6_forward.c, as it is an unused variable. Reviewed by:=09gnn, jtl Approved by:=09sjg (mentor) Sponsored by:=09Juniper Networks, Inc. Differential Revision:=09https://reviews.freebsd.org/D2901 303410 by bdrewery: Reconnect pmcstudy, lost in r291021 Reported by:=09pluknet MFC after:=093 days Sponsored by:=09EMC / Isilon Storage Division 303406 by jhb: Adjust tests in fsync job scheduling loop to reduce indentation. 303405 by jhb: Add support for zero-copy aio_write() on TOE sockets. AIO write requests for a TOE socket on a Chelsio T4+ adapter can now DMA directly from the user-supplied buffer. This is implemented by wiring the pages backing the user-supplied buffer and queueing special mbufs backed by raw VM pages to the socket buffer. The TOE code recognizes these special mbufs and builds a sglist from the VM page array associated with the mbuf when queueing a work request to the TOE. Because these mbufs do not have an associated virtual address, m_data is not valid. Thus, the AIO handler does not invoke sosend() directly for these mbufs but instead inlines portions of sosend_generic() and tcp_usr_send(). An aiotx_buffer structure is used to describe the user buffer (e.g. it holds the array of VM pages and a reference to the AIO job). The special mbufs reference this structure via m_ext. Note that a single job might be split across multiple mbufs (e.g. if it is larger than the socket buffer size). The 'ext_arg2' member of each mbuf gives an offset relative to the backing aiotx_buffer. The AIO job associated with an aiotx_buffer structure is completed when the last reference to the structure is released. Zero-copy aio_write()'s for connections associated with a given adapter can be enabled/disabled at runtime via the 'dev.t[45]nex.N.toe.tx_zcopy' sysctl. MFC after:=091 month Relnotes:=09yes Sponsored by:=09Chelsio Communications The end of the build log: [...truncated 137741 lines...] cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_iso9660_zisofs.o -MTtest_write_format_iso9660_zisofs.o -std=3Dgnu99 -fst= ack-protector-strong -Qunused-arguments -c /usr/src/contrib/libarchive/= libarchive/test/test_write_format_iso9660_zisofs.c -o test_write_format_iso= 9660_zisofs.o --- all_subdir_usr.sbin --- --- .depend --- echo pmcstat.full: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a /usr/o= bj/arm64.aarch64/usr/src/tmp/usr/lib/libelf.a /usr/obj/arm64.aarch64/usr/sr= c/tmp/usr/lib/libkvm.a /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libpmc.a = /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libm.a /usr/obj/arm64.aarch64/us= r/src/tmp/usr/lib/libncursesw.a >> .depend --- pmcstat.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.pmcstat= .o -MTpmcstat.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wer= ror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmi= ssing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings = -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winlin= e -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-si= gn -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-str= ing-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/us= r.sbin/pmcstat/pmcstat.c -o pmcstat.o --- all_subdir_usr.sbin/ntp --- --- ntp_leapsec.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/usr.sbin/ntp/nt= pd/../../../contrib/ntp/ntpd -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib= /ntp/include -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/inc= lude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/pthreads/in= clude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/unix/inclu= de -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/sntp/libopts -I/usr/= src/usr.sbin/ntp/ntpd/../ -I/usr/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPAR= SE -DHAVE_CONFIG_H -DOPENSSL -DUSE_OPENSSL_CRYPTO_RAND -DAUTOKEY -g -MD -= MF.depend.ntp_leapsec.o -MTntp_leapsec.o -std=3Dgnu99 -fstack-protector-str= ong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-cons= t-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equ= ality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -= Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -= Qunused-arguments -c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/= ntp_leapsec.c -o ntp_leapsec.o --- all_subdir_lib --- --- test_write_format_mtree.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_mtree.o -MTtest_write_format_mtree.o -std=3Dgnu99 -fstack-protector-stro= ng -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/te= st_write_format_mtree.c -o test_write_format_mtree.o --- test_write_format_mtree_absolute_path.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_mtree_absolute_path.o -MTtest_write_format_mtree_absolute_path.o -std=3D= gnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/contrib/l= ibarchive/libarchive/test/test_write_format_mtree_absolute_path.c -o test_w= rite_format_mtree_absolute_path.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/pmcstat --- --- pmcstat_log.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.pmcstat= _log.o -MTpmcstat_log.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-= strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts= -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-po= inter-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /us= r/src/usr.sbin/pmcstat/pmcstat_log.c -o pmcstat_log.o --- all_subdir_lib --- --- test_write_format_mtree_classic.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_mtree_classic.o -MTtest_write_format_mtree_classic.o -std=3Dgnu99 -fstac= k-protector-strong -Qunused-arguments -c /usr/src/contrib/libarchive/li= barchive/test/test_write_format_mtree_classic.c -o test_write_format_mtree_= classic.o --- test_write_format_mtree_classic_indent.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_mtree_classic_indent.o -MTtest_write_format_mtree_classic_indent.o -std= =3Dgnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/contri= b/libarchive/libarchive/test/test_write_format_mtree_classic_indent.c -o te= st_write_format_mtree_classic_indent.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/ntp --- --- ntp_loopfilter.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/usr.sbin/ntp/nt= pd/../../../contrib/ntp/ntpd -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib= /ntp/include -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/inc= lude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/pthreads/in= clude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/unix/inclu= de -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/sntp/libopts -I/usr/= src/usr.sbin/ntp/ntpd/../ -I/usr/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPAR= SE -DHAVE_CONFIG_H -DOPENSSL -DUSE_OPENSSL_CRYPTO_RAND -DAUTOKEY -g -MD -= MF.depend.ntp_loopfilter.o -MTntp_loopfilter.o -std=3Dgnu99 -fstack-protect= or-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parenthe= ses -Qunused-arguments -c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp= /ntpd/ntp_loopfilter.c -o ntp_loopfilter.o --- all_subdir_lib --- --- test_write_format_mtree_fflags.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_mtree_fflags.o -MTtest_write_format_mtree_fflags.o -std=3Dgnu99 -fstack-= protector-strong -Qunused-arguments -c /usr/src/contrib/libarchive/liba= rchive/test/test_write_format_mtree_fflags.c -o test_write_format_mtree_ffl= ags.o --- test_write_format_mtree_no_separator.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_mtree_no_separator.o -MTtest_write_format_mtree_no_separator.o -std=3Dgn= u99 -fstack-protector-strong -Qunused-arguments -c /usr/src/contrib/lib= archive/libarchive/test/test_write_format_mtree_no_separator.c -o test_writ= e_format_mtree_no_separator.o --- test_write_format_mtree_quoted_filename.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_mtree_quoted_filename.o -MTtest_write_format_mtree_quoted_filename.o -st= d=3Dgnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/contr= ib/libarchive/libarchive/test/test_write_format_mtree_quoted_filename.c -o = test_write_format_mtree_quoted_filename.o --- test_write_format_pax.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_pax.o -MTtest_write_format_pax.o -std=3Dgnu99 -fstack-protector-strong = -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/test_w= rite_format_pax.c -o test_write_format_pax.o --- all_subdir_usr.sbin --- --- ntp_monitor.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/usr.sbin/ntp/nt= pd/../../../contrib/ntp/ntpd -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib= /ntp/include -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/inc= lude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/pthreads/in= clude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/unix/inclu= de -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/sntp/libopts -I/usr/= src/usr.sbin/ntp/ntpd/../ -I/usr/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPAR= SE -DHAVE_CONFIG_H -DOPENSSL -DUSE_OPENSSL_CRYPTO_RAND -DAUTOKEY -g -MD -= MF.depend.ntp_monitor.o -MTntp_monitor.o -std=3Dgnu99 -fstack-protector-str= ong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-cons= t-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equ= ality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -= Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -= Qunused-arguments -c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/= ntp_monitor.c -o ntp_monitor.o --- all_subdir_lib --- --- test_write_format_raw.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_raw.o -MTtest_write_format_raw.o -std=3Dgnu99 -fstack-protector-strong = -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/test_w= rite_format_raw.c -o test_write_format_raw.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/pmcstat --- --- pmcpl_callgraph.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.pmcpl_c= allgraph.o -MTpmcpl_callgraph.o -std=3Dgnu99 -fstack-protector-strong -Wsys= tem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict= -prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-su= bscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition= -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments= -c /usr/src/usr.sbin/pmcstat/pmcpl_callgraph.c -o pmcpl_callgraph.o --- all_subdir_lib --- --- test_write_format_raw_b64.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_raw_b64.o -MTtest_write_format_raw_b64.o -std=3Dgnu99 -fstack-protector-= strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/tes= t/test_write_format_raw_b64.c -o test_write_format_raw_b64.o --- test_write_format_shar_empty.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_shar_empty.o -MTtest_write_format_shar_empty.o -std=3Dgnu99 -fstack-prot= ector-strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchi= ve/test/test_write_format_shar_empty.c -o test_write_format_shar_empty.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/ntp --- --- ntp_parser.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/usr.sbin/ntp/nt= pd/../../../contrib/ntp/ntpd -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib= /ntp/include -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/inc= lude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/pthreads/in= clude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/unix/inclu= de -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/sntp/libopts -I/usr/= src/usr.sbin/ntp/ntpd/../ -I/usr/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPAR= SE -DHAVE_CONFIG_H -DOPENSSL -DUSE_OPENSSL_CRYPTO_RAND -DAUTOKEY -g -MD -= MF.depend.ntp_parser.o -MTntp_parser.o -std=3Dgnu99 -fstack-protector-stron= g -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-= variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equal= ity -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wn= o-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qu= nused-arguments -c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/nt= p_parser.c -o ntp_parser.o --- all_subdir_lib --- --- test_write_format_tar.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_tar.o -MTtest_write_format_tar.o -std=3Dgnu99 -fstack-protector-strong = -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/test_w= rite_format_tar.c -o test_write_format_tar.o --- test_write_format_tar_empty.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_tar_empty.o -MTtest_write_format_tar_empty.o -std=3Dgnu99 -fstack-protec= tor-strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive= /test/test_write_format_tar_empty.c -o test_write_format_tar_empty.o --- test_write_format_tar_sparse.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_tar_sparse.o -MTtest_write_format_tar_sparse.o -std=3Dgnu99 -fstack-prot= ector-strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchi= ve/test/test_write_format_tar_sparse.c -o test_write_format_tar_sparse.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/pmcstat --- --- pmcpl_gprof.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.pmcpl_g= prof.o -MTpmcpl_gprof.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-= strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts= -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-po= inter-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /us= r/src/usr.sbin/pmcstat/pmcpl_gprof.c -o pmcpl_gprof.o --- all_subdir_lib --- --- test_write_format_tar_ustar.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_tar_ustar.o -MTtest_write_format_tar_ustar.o -std=3Dgnu99 -fstack-protec= tor-strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive= /test/test_write_format_tar_ustar.c -o test_write_format_tar_ustar.o --- all_subdir_usr.sbin --- --- pmcpl_annotate.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.pmcpl_a= nnotate.o -MTpmcpl_annotate.o -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -W= write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subs= cripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -= Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty= -body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments = -c /usr/src/usr.sbin/pmcstat/pmcpl_annotate.c -o pmcpl_annotate.o --- pmcpl_annotate_cg.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.pmcpl_a= nnotate_cg.o -MTpmcpl_annotate_cg.o -std=3Dgnu99 -fstack-protector-strong -= Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-q= ual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wcha= r-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-defini= tion -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno= -empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-argum= ents -c /usr/src/usr.sbin/pmcstat/pmcpl_annotate_cg.c -o pmcpl_annotate_cg= .o --- all_subdir_usr.sbin/ntp --- --- ntp_peer.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/usr.sbin/ntp/nt= pd/../../../contrib/ntp/ntpd -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib= /ntp/include -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/inc= lude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/pthreads/in= clude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/unix/inclu= de -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/sntp/libopts -I/usr/= src/usr.sbin/ntp/ntpd/../ -I/usr/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPAR= SE -DHAVE_CONFIG_H -DOPENSSL -DUSE_OPENSSL_CRYPTO_RAND -DAUTOKEY -g -MD -= MF.depend.ntp_peer.o -MTntp_peer.o -std=3Dgnu99 -fstack-protector-strong -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-sw= itch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunuse= d-arguments -c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntp_pe= er.c -o ntp_peer.o --- all_subdir_lib --- --- test_write_format_tar_v7tar.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_tar_v7tar.o -MTtest_write_format_tar_v7tar.o -std=3Dgnu99 -fstack-protec= tor-strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive= /test/test_write_format_tar_v7tar.c -o test_write_format_tar_v7tar.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/pmcstat --- --- pmcpl_calltree.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.pmcpl_c= alltree.o -MTpmcpl_calltree.o -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -W= write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subs= cripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -= Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty= -body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments = -c /usr/src/usr.sbin/pmcstat/pmcpl_calltree.c -o pmcpl_calltree.o --- all_subdir_lib --- --- test_write_format_warc.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_warc.o -MTtest_write_format_warc.o -std=3Dgnu99 -fstack-protector-strong= -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/test= _write_format_warc.c -o test_write_format_warc.o --- test_write_format_warc_empty.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_warc_empty.o -MTtest_write_format_warc_empty.o -std=3Dgnu99 -fstack-prot= ector-strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchi= ve/test/test_write_format_warc_empty.c -o test_write_format_warc_empty.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/ntp --- --- ntp_proto.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/usr.sbin/ntp/nt= pd/../../../contrib/ntp/ntpd -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib= /ntp/include -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/inc= lude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/pthreads/in= clude -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/lib/isc/unix/inclu= de -I/usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/sntp/libopts -I/usr/= src/usr.sbin/ntp/ntpd/../ -I/usr/src/usr.sbin/ntp/ntpd -DSYS_FREEBSD -DPAR= SE -DHAVE_CONFIG_H -DOPENSSL -DUSE_OPENSSL_CRYPTO_RAND -DAUTOKEY -g -MD -= MF.depend.ntp_proto.o -MTntp_proto.o -std=3Dgnu99 -fstack-protector-strong = -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-va= riable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit= y -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-= switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunu= sed-arguments -c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntp_= proto.c -o ntp_proto.o --- all_subdir_lib --- --- test_write_format_xar.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_xar.o -MTtest_write_format_xar.o -std=3Dgnu99 -fstack-protector-strong = -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/test_w= rite_format_xar.c -o test_write_format_xar.o --- test_write_format_xar_empty.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_xar_empty.o -MTtest_write_format_xar_empty.o -std=3Dgnu99 -fstack-protec= tor-strong -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive= /test/test_write_format_xar_empty.c -o test_write_format_xar_empty.o --- test_write_format_zip.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/lib/libarchive -I= /usr/obj/arm64.aarch64/usr/src/lib/libarchive/tests -I/usr/src/contrib/liba= rchive/libarchive -I/usr/src/contrib/libarchive/test_utils -DHAVE_LIBLZMA= =3D1 -DHAVE_LZMA_H=3D1 -g -MD -MF.depend.libarchive_test.test_write_form= at_zip.o -MTtest_write_format_zip.o -std=3Dgnu99 -fstack-protector-strong = -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/test_w= rite_format_zip.c -o test_write_format_zip.o --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/pmcstat --- --- pmcstat.full --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -std=3Dgnu99 -fstack-prot= ector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn= -type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wca= st-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wol= d-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthre= ad-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Qunused-arguments -o pmcstat.full pmcstat.o pmcstat_log.o pmcpl_callgraph.= o pmcpl_gprof.o pmcpl_annotate.o pmcpl_annotate_cg.o pmcpl_calltree.o -le= lf -lkvm -lpmc -lm -lncursesw --- all_subdir_usr.bin --- --- all_subdir_usr.bin/readelf --- --- readelf.1.gz --- gzip -cn /usr/src/contrib/elftoolchain/readelf/readelf.1 > readelf.1.gz --- readelf.full --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/contrib/elftoolch= ain/libelftc -I/usr/src/contrib/elftoolchain/common -I. -g -std=3Dgnu99 -fs= tack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wn= o-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-param= eter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-d= ecls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declaratio= ns -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-v= ariable -Qunused-arguments -o readelf.full readelf.o -ldwarf -L/usr/obj/= arm64.aarch64/usr/src/lib/libelftc -lelftc -lelf --- all_subdir_usr.sbin --- --- pmcstat.8.gz --- gzip -cn /usr/src/usr.sbin/pmcstat/pmcstat.8 > pmcstat.8.gz --- pmcstat.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug pmcstat.full pmcst= at.debug --- pmcstat --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= pmcstat.debug pmcstat.full pmcstat --- all_subdir_usr.bin --- --- all_subdir_usr.bin/rpcgen --- =3D=3D=3D> usr.bin/rpcgen (all) --- all_subdir_usr.bin/readelf --- --- readelf.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug readelf.full reade= lf.debug --- readelf --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= readelf.debug readelf.full readelf --- all_subdir_usr.bin/rpcgen --- --- .depend --- echo rpcgen.full: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a >> .de= pend --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/pmcstudy --- =3D=3D=3D> usr.sbin/pmcstudy (all) --- all_subdir_usr.bin --- --- rpc_main.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.rpc_mai= n.o -MTrpc_main.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -W= error -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -W= missing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-string= s -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winl= ine -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-= sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-s= tring-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/= usr.bin/rpcgen/rpc_main.c -o rpc_main.o --- all_subdir_usr.sbin --- --- .depend --- echo pmcstudy.full: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a >> .= depend --- pmcstudy.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -Wall -Werror -g -MD -MF.= depend.pmcstudy.o -MTpmcstudy.o -std=3Dgnu99 -fstack-protector-strong -Wsys= tem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict= -prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-su= bscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition= -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments= -c /usr/src/usr.sbin/pmcstudy/pmcstudy.c -o pmcstudy.o /usr/src/usr.sbin/pmcstudy/pmcstudy.c:2326:16: error: unused parameter 'ax'= [-Werror,-Wunused-parameter] do_cpuid(u_int ax, u_int cx, u_int *p) ^ /usr/src/usr.sbin/pmcstudy/pmcstudy.c:2326:26: error: unused parameter 'cx'= [-Werror,-Wunused-parameter] do_cpuid(u_int ax, u_int cx, u_int *p) ^ /usr/src/usr.sbin/pmcstudy/pmcstudy.c:2326:37: error: unused parameter 'p' = [-Werror,-Wunused-parameter] do_cpuid(u_int ax, u_int cx, u_int *p) ^ 3 errors generated. *** [pmcstudy.o] Error code 1 bmake[4]: stopped in /usr/src/usr.sbin/pmcstudy 1 error bmake[4]: stopped in /usr/src/usr.sbin/pmcstudy *** [all_subdir_usr.sbin/pmcstudy] Error code 2 bmake[3]: stopped in /usr/src/usr.sbin --- all_subdir_lib --- A failure has been detected in another branch of the parallel make bmake[6]: stopped in /usr/src/lib/libarchive/tests *** [libarchive_test] Error code 2 bmake[5]: stopped in /usr/src/lib/libarchive/tests 1 error bmake[5]: stopped in /usr/src/lib/libarchive/tests *** [all] Error code 2 bmake[4]: stopped in /usr/src/lib/libarchive 1 error bmake[4]: stopped in /usr/src/lib/libarchive *** [all_subdir_lib/libarchive] Error code 2 bmake[3]: stopped in /usr/src/lib 1 error bmake[3]: stopped in /usr/src/lib *** [all_subdir_lib] Error code 2 bmake[2]: stopped in /usr/src --- all_subdir_usr.bin --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/usr.bin/rpcgen *** [all_subdir_usr.bin/rpcgen] Error code 2 bmake[3]: stopped in /usr/src/usr.bin 1 error bmake[3]: stopped in /usr/src/usr.bin *** [all_subdir_usr.bin] Error code 2 bmake[2]: stopped in /usr/src --- all_subdir_usr.sbin --- --- all_subdir_usr.sbin/ntp --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/usr.sbin/ntp/ntpd *** [all_subdir_usr.sbin/ntp/ntpd] Error code 2 bmake[4]: stopped in /usr/src/usr.sbin/ntp 1 error bmake[4]: stopped in /usr/src/usr.sbin/ntp *** [all_subdir_usr.sbin/ntp] Error code 2 bmake[3]: stopped in /usr/src/usr.sbin 2 errors bmake[3]: stopped in /usr/src/usr.sbin *** [all_subdir_usr.sbin] Error code 2 bmake[2]: stopped in /usr/src 3 errors bmake[2]: stopped in /usr/src *** [everything] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson3568635552635834485.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Wed Jul 27 23:10:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0763BA6AAD for ; Wed, 27 Jul 2016 23:10:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C3DE31DB7; Wed, 27 Jul 2016 23:10:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D2685130; Wed, 27 Jul 2016 23:10:39 +0000 (UTC) Date: Wed, 27 Jul 2016 23:10:37 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: rrs@FreeBSD.org, ivadasz@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <249861072.24.1469661039868.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1617691874.20.1469655510563.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1617691874.20.1469655510563.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3712 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 23:10:39 -0000 FreeBSD_HEAD_arm64 - Build #3712 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3712/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3712/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3712/console Change summaries: 303419 by bdrewery: Fix non-amd64 build from r292043 after reconnecting in r303410. MFC after: 3 days X-MFC-With: r303410 Sponsored by: EMC / Isilon Storage Division 303418 by ivadasz: [iwm] When stopping TX DMA, wait for all channels at once. * Makes the TX DMA stopping more similar to Linux code, and potentially a bit faster. Also, output an error message when TX DMA idling fails. Taken-From: Linux iwlwifi Tested: * AC3165, STA mode Approved by: adrian (mentor) Obtained from: DragonFlyBSD git 2ee486ddff973ac552ff787c17e8d83e8ae0f24c Differential Revision: https://reviews.freebsd.org/D7325 303417 by bdrewery: opt_bdg.h was removed in r150636. MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 303416 by ivadasz: [iwm] Set different pm_timeout for action frames. When building a Tx Command for management frames, we are lacking a check for action frames, for which we should set a different pm_timeout. This cause the fw to stay awake for 100TU after each such frame is transmitted, resulting an excessive power consumption. Taken-From: Linux iwlwifi (git b084a35663c3f1f7) Approved by: adrian (mentor) Obtained from: Linux git b084a35663c3f1f7de1c45c4ae3006864c940fe7 Obtained from: DragonFlyBSD git ba00f0e3ae873d6f0d5743e22c3ebc49c44dfdac Differential Revision: https://reviews.freebsd.org/D7324 303415 by bdrewery: opt_apic.h is only used on i386. MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 303414 by bdrewery: opt_random.h was removed in r287558 for opt_global.h MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 303413 by ivadasz: [iwm] Fix inverted logic in iwm_tx(). The PROT_REQUIRE flag in should be set for data frames above a certain length, but we were setting it for !data frames above a certain length, which makes no sense at all. Taken-From: OpenBSD, Linux iwlwifi Approved by: adrian (mentor) Obtained from: DragonFlyBSD git 8cc03924a36c572c2908e659e624f44636dc2b33 Differential Revision: https://reviews.freebsd.org/D7323 303412 by rrs: Remove myself from kern_timeout.c yeah! From owner-freebsd-arm@freebsd.org Thu Jul 28 07:57:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E814EBA5726 for ; Thu, 28 Jul 2016 07:57:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C01281BDC; Thu, 28 Jul 2016 07:57:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CF27A145; Thu, 28 Jul 2016 07:57:23 +0000 (UTC) Date: Thu, 28 Jul 2016 07:57:07 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: sephe@FreeBSD.org, loos@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <270823664.28.1469692643854.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3713 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 07:57:34 -0000 FreeBSD_HEAD_arm64 - Build #3713 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3713/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3713/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3713/console Change summaries: 303422 by sephe: hyperv/vmbus: Inclusion cleanup MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D7334 303421 by sephe: hyperv/vmbus: Avoid unnecessary mb() MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D7333 303420 by loos: Enable the build of micphy as part of generic miibus build, but only for FDT enabled systems. Sponsored by: Rubicon Communications (Netgate) The end of the build log: Started by an SCM change Building remotely on kyua1.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_arm64 Updating svn://svnmir.freebsd.org/base/head at revision '2016-07-28T07:55:13.152 +0000' U sys/dev/hyperv/include/hyperv.h U sys/dev/hyperv/include/vmbus.h U sys/dev/hyperv/netvsc/hv_net_vsc.h U sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c U sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c U sys/dev/hyperv/utilities/hv_heartbeat.c U sys/dev/hyperv/utilities/hv_shutdown.c U sys/dev/hyperv/utilities/hv_timesync.c U sys/dev/hyperv/vmbus/hyperv.c U sys/dev/hyperv/vmbus/vmbus.c U sys/dev/hyperv/vmbus/vmbus_chan.c U sys/dev/hyperv/vmbus/vmbus_et.c U sys/dev/hyperv/vmbus/vmbus_var.h U sys/dev/hyperv/vmbus/vmbus_br.c U sys/dev/iwm/if_iwm.c U sys/dev/iwm/if_iwmreg.h U sys/arm/altera/socfpga/files.socfpga U sys/arm/ti/files.ti U sys/conf/files U sys/modules/ixl/Makefile U sys/modules/ixlv/Makefile U sys/modules/hyperv/vmbus/Makefile U sys/modules/linux64/Makefile U sys/modules/mlx5/Makefile U usr.sbin/pmcstudy/pmcstudy.c U MAINTAINERS At revision 303422 No emails were triggered. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson7207983139235369971.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + true + sudo umount FreeBSD_HEAD_arm64/usr/src + true + sudo umount FreeBSD_HEAD_arm64/dev + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 + true + sudo rm -fr FreeBSD_HEAD_arm64 [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson2618368776649168218.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo env: env: + /usr/bin/env BUILD_NUMBER=3713 HUDSON_SERVER_COOKIE=0657dbe3541f1b1a JOB_NAME=FreeBSD_HEAD_arm64 LOGNAME=jenkins JAVA_HOME=/usr/local/openjdk8 SVN_URL=svn://svnmir.freebsd.org/base/head BUILDER_JAIL_IP=2610:1c1:1:607c::101:1 jname=FreeBSD_HEAD_arm64 JENKINS_URL=https://jenkins.FreeBSD.org/ JENKINS_HOME=/usr/local/jenkins PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin JOB_BASE_NAME=FreeBSD_HEAD_arm64 HUDSON_HOME=/usr/local/jenkins OLDPWD=/ BUILD_ID=3713 BUILDER_NETIF=igb0 JENKINS_SERVER_COOKIE=0657dbe3541f1b1a PWD=/jenkins/workspace/FreeBSD_HEAD_arm64 BUILD_TAG=jenkins-FreeBSD_HEAD_arm64-3713 NODE_LABELS=jailer kyua1.nyi.freebsd.org BUILD_DISPLAY_NAME=#3713 HOME=/jenkins USER=jenkins BUILD_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3713/ SVN_URL_1=svn://svnmir.freebsd.org/base/head SVN_REVISION=303422 SVN_REVISION_1=303422 BUILDER_JAIL_IP6=2610:1c1:1:607c::101:1 JOB_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/ SHELL=/bin/sh HUDSON_URL=https://jenkins.FreeBSD.org/ HUDSON_COOKIE=a211273d-9ddb-433e-91c6-4ee5e7514a02 BUILDER_RESOLV_CONF=nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n WORKSPACE=/jenkins/workspace/FreeBSD_HEAD_arm64 NODE_NAME=kyua1.nyi.freebsd.org EXECUTOR_NUMBER=0 + echo 'setup jail FreeBSD_HEAD_arm64' setup jail FreeBSD_HEAD_arm64 + fetch -m http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/base.txz + fetch -m http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/lib32.txz + mkdir FreeBSD_HEAD_arm64 + cd FreeBSD_HEAD_arm64 + sudo tar Jxf ../base.txz + sudo tar Jxf ../lib32.txz + cd - + sudo mount -t devfs devfs FreeBSD_HEAD_arm64/dev + sudo devfs -m FreeBSD_HEAD_arm64/dev rule -s 4 applyset + sudo mount -t nullfs src FreeBSD_HEAD_arm64/usr/src + printf 'nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n' + sudo tee FreeBSD_HEAD_arm64/etc/resolv.conf nameserver 2610:1c1:1:6002::100 nameserver 2610:1c1:1:6002::200 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 alias + sudo jail -c persist 'name=FreeBSD_HEAD_arm64' 'path=FreeBSD_HEAD_arm64' 'host.hostname=FreeBSD_HEAD_arm64.jail.ci.FreeBSD.org' 'ip6.addr=2610:1c1:1:607c::101:1' 'ip4=disable' allow.chflags + echo 'setup build environment' setup build environment + sudo pkg -j FreeBSD_HEAD_arm64 install -y aarch64-binutils pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended Updating FreeBSD repository catalogue... pkg: http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/meta.txz: No address record repository FreeBSD has no meta file, using default settings pkg: http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/packagesite.txz: No address record Unable to update repository FreeBSD All repositories are up-to-date. pkg: Repository FreeBSD cannot be opened. 'pkg update' required pkg: No packages available to install matching 'aarch64-binutils' have been found in the repositories Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson9107979672129962143.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Thu Jul 28 09:56:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 111F3BA79E4 for ; Thu, 28 Jul 2016 09:56:45 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 042FC1E39; Thu, 28 Jul 2016 09:56:45 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E802B148; Thu, 28 Jul 2016 09:56:34 +0000 (UTC) Date: Thu, 28 Jul 2016 09:56:18 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: ed@FreeBSD.org, kib@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1390700155.30.1469699794957.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <270823664.28.1469692643854.JavaMail.jenkins@jenkins-9.freebsd.org> References: <270823664.28.1469692643854.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3714 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 09:56:45 -0000 FreeBSD_HEAD_arm64 - Build #3714 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3714/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3714/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3714/console Change summaries: 303427 by ed: Change type of MB_CUR_MAX and MB_CUR_MAX_L() to size_t. POSIX requires that MB_CUR_MAX expands to an expression of type size_t. It currently expands to an int. As these are already macros, don't change the underlying type of these functions. There is no ned to touch those. Differential Revision: https://reviews.freebsd.org/D6645 303426 by kib: Rewrite subr_sleepqueue.c use of callouts to not depend on the specifics of callout KPI. Esp., do not depend on the exact interface of callout_stop(9) return values. The main change is that instead of requiring precise callouts, code maintains absolute time to wake up. Callouts now should ensure that a wake occurs at the requested moment, but we can tolerate both run-away callout, and callout_stop(9) lying about running callout either way. As consequence, it removes the constant source of the bugs where sleepq_check_timeout() causes uninterruptible thread state where the thread is detached from CPU, see e.g. r234952 and r296320. Patch also removes dual meaning of the TDF_TIMEOUT flag, making code (IMO much) simpler to reason about. Tested by: pho Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 1 month Differential revision: https://reviews.freebsd.org/D7137 303425 by kib: Extract the calculation of the callout fire time into the new function callout_when(9). See the man page update for the description of the intended use. Tested by: pho Reviewed by: jhb, bjk (man page updates) Sponsored by: The FreeBSD Foundation MFC after: 1 month X-Differential revision: https://reviews.freebsd.org/D7137 303424 by kib: Fix typo in comment. MFC after: 3 days 303423 by kib: When a debugger attaches to the process, SIGSTOP is sent to the target. Due to a way issignal() selects the next signal to deliver and report, if the simultaneous or already pending another signal exists, that signal might be reported by the next waitpid(2) call. This causes minor annoyance for debuggers, which must be prepared to take any signal as the first event, then filter SIGSTOP later. More importantly, for tools like gcore(1), which attach and then detach without processing events, SIGSTOP might leak to be delivered after PT_DETACH. This results in the process being unintentionally stopped after detach, which is fatal for automatic tools. The solution is to force SIGSTOP to be the first signal reported after the attach. Attach code is modified to set P2_PTRACE_FSTP to indicate that the attaching ritual was not yet finished, and issignal() prefers SIGSTOP in that condition. Also, the thread which handles P2_PTRACE_FSTP is made to guarantee to own p_xthread during the first waitpid(2). All that ensures that SIGSTOP is consumed first. Additionally, if P2_PTRACE_FSTP is still set on detach, which means that waitpid(2) was not called at all, SIGSTOP is removed from the queue, ensuring that the process is resumed on detach. In issignal(), when acting on STOPing signals, remove the signal from queue before suspending. Otherwise parallel attach could result in ptracestop() acting on that STOP as if it was the STOP signal from the attach. Then SIGSTOP from attach leaks again. As a minor refactoring, some bits of the common attach code is moved to new helper proc_set_traced(). Reported by: markj Reviewed by: jhb, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D7256 The end of the build log: Started by an SCM change Building remotely on kyua1.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_arm64 Updating svn://svnmir.freebsd.org/base/head at revision '2016-07-28T09:55:07.885 +0000' U include/stdlib.h U include/xlocale/_stdlib.h U sys/ddb/db_ps.c U sys/kern/kern_thread.c U sys/kern/subr_sleepqueue.c U sys/kern/kern_timeout.c U sys/kern/kern_exit.c U sys/kern/kern_fork.c U sys/kern/kern_sig.c U sys/kern/sys_process.c U sys/sys/proc.h U sys/sys/callout.h U share/man/man9/Makefile U share/man/man9/timeout.9 U bin/ps/ps.1 At revision 303427 No emails were triggered. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson8140774213607810473.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + true + sudo umount FreeBSD_HEAD_arm64/usr/src + true + sudo umount FreeBSD_HEAD_arm64/dev + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 + true + sudo rm -fr FreeBSD_HEAD_arm64 [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson164767804803916947.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo env: env: + /usr/bin/env BUILD_NUMBER=3714 HUDSON_SERVER_COOKIE=0657dbe3541f1b1a JOB_NAME=FreeBSD_HEAD_arm64 LOGNAME=jenkins JAVA_HOME=/usr/local/openjdk8 SVN_URL=svn://svnmir.freebsd.org/base/head BUILDER_JAIL_IP=2610:1c1:1:607c::101:1 jname=FreeBSD_HEAD_arm64 JENKINS_URL=https://jenkins.FreeBSD.org/ JENKINS_HOME=/usr/local/jenkins PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin JOB_BASE_NAME=FreeBSD_HEAD_arm64 HUDSON_HOME=/usr/local/jenkins OLDPWD=/ BUILD_ID=3714 BUILDER_NETIF=igb0 JENKINS_SERVER_COOKIE=0657dbe3541f1b1a PWD=/jenkins/workspace/FreeBSD_HEAD_arm64 BUILD_TAG=jenkins-FreeBSD_HEAD_arm64-3714 NODE_LABELS=jailer kyua1.nyi.freebsd.org BUILD_DISPLAY_NAME=#3714 HOME=/jenkins USER=jenkins BUILD_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3714/ SVN_URL_1=svn://svnmir.freebsd.org/base/head SVN_REVISION=303427 SVN_REVISION_1=303427 BUILDER_JAIL_IP6=2610:1c1:1:607c::101:1 JOB_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/ SHELL=/bin/sh HUDSON_URL=https://jenkins.FreeBSD.org/ HUDSON_COOKIE=246a4d72-b116-4e42-9f69-1a7f4eb5a9d2 BUILDER_RESOLV_CONF=nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n WORKSPACE=/jenkins/workspace/FreeBSD_HEAD_arm64 NODE_NAME=kyua1.nyi.freebsd.org EXECUTOR_NUMBER=0 + echo 'setup jail FreeBSD_HEAD_arm64' setup jail FreeBSD_HEAD_arm64 + fetch -m http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/base.txz + fetch -m http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/lib32.txz + mkdir FreeBSD_HEAD_arm64 + cd FreeBSD_HEAD_arm64 + sudo tar Jxf ../base.txz + sudo tar Jxf ../lib32.txz + cd - + sudo mount -t devfs devfs FreeBSD_HEAD_arm64/dev + sudo devfs -m FreeBSD_HEAD_arm64/dev rule -s 4 applyset + sudo mount -t nullfs src FreeBSD_HEAD_arm64/usr/src + printf 'nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n' + sudo tee FreeBSD_HEAD_arm64/etc/resolv.conf nameserver 2610:1c1:1:6002::100 nameserver 2610:1c1:1:6002::200 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 alias ifconfig: ioctl (SIOCAIFADDR): File exists Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson6987722559903839461.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 jail: "FreeBSD_HEAD_arm64" not found + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Thu Jul 28 11:56:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D90D1BA712D for ; Thu, 28 Jul 2016 11:56:37 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id CC14A113E; Thu, 28 Jul 2016 11:56:37 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id BF66914E; Thu, 28 Jul 2016 11:56:27 +0000 (UTC) Date: Thu, 28 Jul 2016 11:56:11 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: mav@FreeBSD.org, ed@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <547463469.35.1469706987791.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1390700155.30.1469699794957.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1390700155.30.1469699794957.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3715 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 11:56:37 -0000 FreeBSD_HEAD_arm64 - Build #3715 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3715/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3715/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3715/console Change summaries: 303429 by mav: Once more refactor KPI between NTB hardware and consumers. New design allows hardware resources to be split between several consumers. For example, one BAR can be dedicated for remote memory access, while other resources can be used for packet transport for virtual Ethernet interface. And even without resource split, this code allows to specify which consumer driver should attach the hardware. >From some points this makes the code even closer to Linux one, even though Linux does not provide the described flexibility. 303428 by ed: Add NI_NUMERICSCOPE. POSIX also declares NI_NUMERICSCOPE, which makes getnameinfo() return a numerical scope identifier. The interesting thing is that support for this is already present in code, but #ifdef disabled. Expose this functionality by placing a definition for it in . While there, remove references to NI_WITHSCOPEID, as that got removed 11 years ago. The end of the build log: Started by an SCM change Building remotely on kyua1.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_arm64 Updating svn://svnmir.freebsd.org/base/head at revision '2016-07-28T11:55:01.804 +0000' U share/man/man4/ntb_hw.4 U sys/dev/ntb/ntb.c U sys/dev/ntb/ntb.h U sys/dev/ntb/ntb_hw/ntb_hw.c U sys/dev/ntb/ntb_if.m U sys/dev/ntb/ntb_transport.c U include/netdb.h U lib/libc/net/getnameinfo.3 U lib/libc/net/getnameinfo.c At revision 303433 No emails were triggered. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson928428954889779137.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + true + sudo umount FreeBSD_HEAD_arm64/usr/src + true + sudo umount FreeBSD_HEAD_arm64/dev + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 + true + sudo rm -fr FreeBSD_HEAD_arm64 [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson4176671167567003825.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo env: env: + /usr/bin/env BUILD_NUMBER=3715 HUDSON_SERVER_COOKIE=0657dbe3541f1b1a JOB_NAME=FreeBSD_HEAD_arm64 LOGNAME=jenkins JAVA_HOME=/usr/local/openjdk8 SVN_URL=svn://svnmir.freebsd.org/base/head BUILDER_JAIL_IP=2610:1c1:1:607c::101:1 jname=FreeBSD_HEAD_arm64 JENKINS_URL=https://jenkins.FreeBSD.org/ JENKINS_HOME=/usr/local/jenkins PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin JOB_BASE_NAME=FreeBSD_HEAD_arm64 HUDSON_HOME=/usr/local/jenkins OLDPWD=/ BUILD_ID=3715 BUILDER_NETIF=igb0 JENKINS_SERVER_COOKIE=0657dbe3541f1b1a PWD=/jenkins/workspace/FreeBSD_HEAD_arm64 BUILD_TAG=jenkins-FreeBSD_HEAD_arm64-3715 NODE_LABELS=jailer kyua1.nyi.freebsd.org BUILD_DISPLAY_NAME=#3715 HOME=/jenkins USER=jenkins BUILD_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3715/ SVN_URL_1=svn://svnmir.freebsd.org/base/head SVN_REVISION=303429 SVN_REVISION_1=303429 BUILDER_JAIL_IP6=2610:1c1:1:607c::101:1 JOB_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/ SHELL=/bin/sh HUDSON_URL=https://jenkins.FreeBSD.org/ HUDSON_COOKIE=9c53cef4-7953-4b81-bceb-fd4caee7ae6f BUILDER_RESOLV_CONF=nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n WORKSPACE=/jenkins/workspace/FreeBSD_HEAD_arm64 NODE_NAME=kyua1.nyi.freebsd.org EXECUTOR_NUMBER=0 + echo 'setup jail FreeBSD_HEAD_arm64' setup jail FreeBSD_HEAD_arm64 + fetch -m http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/base.txz + fetch -m http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/lib32.txz + mkdir FreeBSD_HEAD_arm64 + cd FreeBSD_HEAD_arm64 + sudo tar Jxf ../base.txz + sudo tar Jxf ../lib32.txz + cd - + sudo mount -t devfs devfs FreeBSD_HEAD_arm64/dev + sudo devfs -m FreeBSD_HEAD_arm64/dev rule -s 4 applyset + sudo mount -t nullfs src FreeBSD_HEAD_arm64/usr/src + printf 'nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n' + sudo tee FreeBSD_HEAD_arm64/etc/resolv.conf nameserver 2610:1c1:1:6002::100 nameserver 2610:1c1:1:6002::200 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 alias ifconfig: ioctl (SIOCAIFADDR): File exists Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson2505923319684232629.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 jail: "FreeBSD_HEAD_arm64" not found + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Thu Jul 28 14:21:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85A7CBA74E6 for ; Thu, 28 Jul 2016 14:21:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7913E1F67; Thu, 28 Jul 2016 14:21:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7F953154; Thu, 28 Jul 2016 14:20:51 +0000 (UTC) Date: Thu, 28 Jul 2016 14:20:33 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: mav@FreeBSD.org, ed@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <104979039.41.1469715651530.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <547463469.35.1469706987791.JavaMail.jenkins@jenkins-9.freebsd.org> References: <547463469.35.1469706987791.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3716 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 14:21:01 -0000 FreeBSD_HEAD_arm64 - Build #3716 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3716/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3716/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3716/console Change summaries: 303437 by mav: Fix r303429 build with invariants. 303436 by ed: Regenerate system call table for r303435. 303435 by ed: Change the return type of msgrcv() to ssize_t as required by POSIX. It looks like the msgrcv() system call is already written in such a way that the size is internally computed as a size_t and written into all of td_retval[0]. This means that it is effectively already returning ssize_t. It's just that the userspace prototype doesn't match up. From owner-freebsd-arm@freebsd.org Thu Jul 28 15:33:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BB12BA670E; Thu, 28 Jul 2016 15:33:19 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 15D5C1A84; Thu, 28 Jul 2016 15:33:18 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 7F2003ACCF; Thu, 28 Jul 2016 17:33:15 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <579A25BB.8070206@FreeBSD.org> Date: Thu, 28 Jul 2016 17:33:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Thu, 28 Jul 2016 17:33:15 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 15:33:19 -0000 Dne 27.07.2016 v 19:19 Nathan Whitehorn napsal(a): > > > On 07/27/16 09:27, Michal Meloun wrote: > > > [snip] >>> The concept is *extremely* necessary, which is why both Linux and >>> FreeBSD decided to use it independently There is no way to handle >>> parent buses with a single rman and devices on multiple PICs with >>> overlapping interrupt ranges without them; neither is there a way to >>> decode arbitrary-length interrupt specifiers or to handle things like >>> MSIs. Please see the list of cases at >>> https://wiki.freebsd.org/Complicated_Interrupts and in my earlier >>> email for some examples of things that you just can't represent with >>> this new system, as far as I can tell. >>> >>>> Also, both variants needs attached PIC at bus_alloc_resource() >>>> time, >>>> so timing wasn't been changed. >>> They absolutely do not, as I have explained repeatedly. Due to parent >>> devices with interrupts handled by their bus children, this is a hard >>> requirement of any workable system. This is not a theoretical issue; I >>> have lots of hardware like this. >> Nathan, I'm talking about pre /post r301453 state. Current INTRNG it >> has never supported. But yes, I'm fully understand why you want it. See >> [2]. > > Current "INTRNG", at least on PowerPC, has supported this for 10 > years. If it doesn't on ARM, it's because of some trivial > implementation bug. >> >>>> - it implements new BUS_MAP_INTR(). As I understand it, this is >>>> problematic for you, and I'm ready to change it. But I need more >>>> details >>>> than "it's fundamentally broken". >>> Please explain (a) what cases it handles that the existing code and >>> does, and (b) how you would resolve each of the cases on the wiki page >>> I sent. >>> >>> The general issue is that it traces the newbus hierarchy, when >>> interrupts often do not, and so breaks when you have links to >>> as-yet-unattached parts of the hierarchy. It also relies on the >>> assigned "IRQ" numbers being nonoverlapping to avoid rman errors, but >>> that's a relatively minor thing. >> Well, from my point of view, only "get interrupt data from >> OFW/GPIO/.." part of bus_alloc_resource() follows bus hierarchy, real >> execution not changed. >> In any case, I see many possible variants how we can modify current >> implementation. For rest, see [2]. > > But that's an important part, for three reasons: > 1. The PIC may not exist when bus_alloc_resource() is called > 2. The bus parents have no useful information to contribute to this > since the hierarchy doesn't go that way See [2] > 3. If you try to use the interrupt pin as the resource ID, which > r301453 does, you end up with rman conflicts if, for example, a bus > has two children with interrupts on identically numbered pins on two > different interrupt controllers. No, r301453 doesn't do this. Index to global interrupt source table (irq_sources) is used as resource ID (and r301453 not changed it). > >> >>>> >>>>> There are some other differences, of varying degrees of importance, >>>>> but that's the really fundamental one. I haven't seen any cases where >>>>> r301453 provides functionality absent in the already existing system, >>>>> but there seem to be a large number of cases (see the first email I >>>>> sent to freebsd-arch or >>>>> https://wiki.freebsd.org/Complicated_Interrupts) that the API in >>>>> r301453 cannot accommodate and that are needed to support a >>>>> variety of >>>>> hardware. >>>> Which single feature has been removed by r301453? >>> Nothing has been removed by it, because the normal code is intact. >>> However, the new code is less functional than the old code, so cannot >>> replace it. In particular, it is architecturally incapable of working >>> with the kinds of device trees found on PowerPC systems (see the wiki >>> page). That means we would have to keep both indefinitely, which is a >>> significant maintenance burden to no gain whatsoever. >>> -Nathan >> Firstly, please, ignore dependency problem. It will be explained later >> in [2]. > > Except that that isn't a workable solution (see the end) > >> >> [1] >> The original (your) INTRNG assume several things: >> >> - value of interrupt parent xref together with byte contents of >> 'interrupts' property forms some sort of 'key' (aka virtual IRQ) >> - byte contents of 'interrupts' property cannot be parsed in any way >> inside INTRNG core. >> - data forming this key are sufficient for subsequent mapping (and/or >> configuring) to real IRQ. >> - there must exist bidirectional unique relation between virtual and >> real IRQs. So one key (virtual IRQ) can be mappable to one and just >> one >> real IRQ. And only one virtual IRQ can be mapped to any given real >> IRQ. >> - we have cache that stores all observed 'keys' and associated real IRQ >> ) the they already mapped. >> >> Unfortunately, necessity of unique mapping is very problematic. >> We cannot handle situation, where shared interrupt is declared by >> different but compatible 'interrupts' properties. > > There isn't actually a requirement of bidirectional uniqueness, as I > explained the last time you brought this up. One "virtual" IRQ does > need to map to exactly one interrupt specifier, but the reverse is not > the case. The PIC driver is absolutely free to map and dispatch > multiple virtual IRQs from the same shared interrupt pin, with no more > overhead than you usually get from shared interrupt lines. Oki, lets me to expand this a little bit more. The pre r301453 INTRNG[ARM] does this: - ofw_bus_intr_to_rl() reads and pre-parses 'interrupts' property into 'key'. - cache is searched for duplicates and new entry is created. - position of this entry in cache is used as resource ID. - given resource ID is stored to RL and is later used in bus_alloc_resource() I'm right ? In the above model, individual cache entries may be shared are referenced by multiple entities (PIC, RL, ..). Due to this, life cycle of cache entries is not well defined and we probably must use some sort of reference counting to control it. But, as you wrote, INTRNG code is "absolutely free to map and dispatch multiple virtual IRQs from the same shared interrupt pin" (allow me to expand this also to INTRNG code itself) . In attempt to simply situation abound cache, in first step, we removed duplicates check from above model. This also removes unpleasantly sharing of entries. This step converts cache to some sort of duplicate of resource list entries. Each existing RLE have exactly one corresponding entry in cache. Also, the cache is not needed for INTRNG core. At this point, its only transfers data from ofw_bus_intr_to_rl() to consumers PIC. So, if we are able to attach 'key' to RLE, then we can remove the whole cache machinery from INTRNG. Do you agree? > >> >> For example: >> ------------------------- >> foo1: bar@12345678 { >> interrupt-parent = <&pic1>; >> interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; >> } >> >> foo2: bar@1234567C { >> interrupt-parent = <&pic1>; >> interrupts = <1 IRQ_TYPE_NONE>; >> } >> >> Is this valid (from DT point of view) configuration? I think that yes. > > No, it's malformed and a violation of the standard. Can you give me pointer, please? I'm not able to find anything about this... > >> Is this frequent configuration? I'm sure, isn't. >> Is this possible configuration? I'm afraid that yes. > > People do in fact do deranged non-conformant things with device trees > sometimes, unfortunately, so it is indeed worth worrying about. > >> -------------------------- >> >> Next example are GPIO interrupts. These are encoded differently, so two >> 'keys' may point to to same real IRQ. >> After that we decided to change our approach and utilize standard >> resources and resource list entries to deliveryconfiguration data from >> various sources (OFW/GPIO/...) to consumers. > > This is a non-issue. You make the GPIO controller a PIC, it handles > interrupts however you like. If you got a weird device tree that uses > two encodings (one for "interrupts" properties with GPIOs and one for > "GPIO" properties on which you need to take interrupts but that > weren't added to the "interrupts" list for mysterious reasons), you > introduce a helper function for the GPIO case. > > Are there any actual problems with the pre-existing interrupt mapping > code? I have not seen any so far. > >> [2] >> Each OFW device has a lot of dependencies. It must enable clocks, power >> regulators..., it must be taken from reset. All these action must be >> done before we can access single register. >> Most of these action can be done only with attached clock/power/reset >> controller. >> Within this, interrupts are not special. > > They are actually quite special in that the kernel enables them late > and so you can defer setup. They are also special in that, for that > reason, it is possible to design systems with circular dependency > graphs with interrupts. It is not possible to do this with, for > example, clocks: if I need to apply a clock to the clock controller > with itself, the system is just not bootable and such a system will > not be built or shipped. Interrupts need only happen later, after > device setup, and so such systems *are* designed and shipped. The same > is true for power. The G5 problem is standard 'cross type' circular dependency. You must (at BUS_PASS_BUS) initialize memory address window of PCI bridge and start bus enumeration. Rest of PCI bridge initialization (including all IRQ stuff) must be postponed to any later pass. Of course, all interrupt controllers must be attached at BUS_PASS_INTERRUPT. Or I missed something? >> Moreover, 'cross type' circular >> dependencies are not that rare. >> I want to say: >> Resource dependencies are must solved (and resolved) at different level >> than is INTRNG. >> Blind resource allocation is not universal solution because given >> resource may/must be accessible immediately after allocation (in many >> cases). > > Absolutely: for GPIOs, clocks, power, etc. you want a system that > looks different than the interrupt virtualization system. Probably > with extra resource types and maybe with some API similar to r301453. > But interrupts have different, and more complex, requirements and > cannot be mapped this way. > >> >> Unfortunately, and at time time, I known only one really working >> solution: >> staggered driver initialization combined with multipass bus >> initialization. > > That does not solve the interrupt problem. If devices have interrupts > on their own children, no amount of multipass initialization can > possibly break the loop. Multipass would work for other kinds of > resources (clocks, power, etc.) and is a perfect match for those > resource types. A dynamic multipass (where a driver can return EAGAIN > or something from attach if its resources don't exist yet) would work > great. > > *But* in the specific, special case of interrupts, it is not a > workable model. You could imagine some change to initialization that > gives devices a late attach and an early attach method and does > interrupts in the late part, but that is hugely invasive change that > would need to touch every single driver in the tree -- to solve a > problem that is already solved by interrupt virtualization. > -Nathan > >> I'm sorry, I'm not able to express all this accurately and clearly, but >> I've really tried... >> Michal >> >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > From owner-freebsd-arm@freebsd.org Thu Jul 28 17:34:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9526CBA7C46; Thu, 28 Jul 2016 17:34:29 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7817C1876; Thu, 28 Jul 2016 17:34:28 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6SHNUjT014395 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 10:23:31 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> Date: Thu, 28 Jul 2016 10:23:30 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <579A25BB.8070206@FreeBSD.org> X-Sonic-CAuth: UmFuZG9tSVbdmXzutuUe3AvM/XnDGFJxM3mv5WJ7H+35zkiJ+klXdGk/muOvp0UKqptpST0bVl5UYaMmEBlQ8zJ6zTA+cBGsQty6DFa0pM4= X-Sonic-ID: C;dnj/AOhU5hGYbJtMTlz00w== M;IAFKAehU5hGYbJtMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 17:34:29 -0000 On 07/28/16 08:33, Michal Meloun wrote: > Dne 27.07.2016 v 19:19 Nathan Whitehorn napsal(a): >> >> On 07/27/16 09:27, Michal Meloun wrote: >> >> >> [snip] >>>> The concept is *extremely* necessary, which is why both Linux and >>>> FreeBSD decided to use it independently There is no way to handle >>>> parent buses with a single rman and devices on multiple PICs with >>>> overlapping interrupt ranges without them; neither is there a way to >>>> decode arbitrary-length interrupt specifiers or to handle things like >>>> MSIs. Please see the list of cases at >>>> https://wiki.freebsd.org/Complicated_Interrupts and in my earlier >>>> email for some examples of things that you just can't represent with >>>> this new system, as far as I can tell. >>>> >>>>> Also, both variants needs attached PIC at bus_alloc_resource() >>>>> time, >>>>> so timing wasn't been changed. >>>> They absolutely do not, as I have explained repeatedly. Due to parent >>>> devices with interrupts handled by their bus children, this is a hard >>>> requirement of any workable system. This is not a theoretical issue; I >>>> have lots of hardware like this. >>> Nathan, I'm talking about pre /post r301453 state. Current INTRNG it >>> has never supported. But yes, I'm fully understand why you want it. See >>> [2]. >> Current "INTRNG", at least on PowerPC, has supported this for 10 >> years. If it doesn't on ARM, it's because of some trivial >> implementation bug. >>>>> - it implements new BUS_MAP_INTR(). As I understand it, this is >>>>> problematic for you, and I'm ready to change it. But I need more >>>>> details >>>>> than "it's fundamentally broken". >>>> Please explain (a) what cases it handles that the existing code and >>>> does, and (b) how you would resolve each of the cases on the wiki page >>>> I sent. >>>> >>>> The general issue is that it traces the newbus hierarchy, when >>>> interrupts often do not, and so breaks when you have links to >>>> as-yet-unattached parts of the hierarchy. It also relies on the >>>> assigned "IRQ" numbers being nonoverlapping to avoid rman errors, but >>>> that's a relatively minor thing. >>> Well, from my point of view, only "get interrupt data from >>> OFW/GPIO/.." part of bus_alloc_resource() follows bus hierarchy, real >>> execution not changed. >>> In any case, I see many possible variants how we can modify current >>> implementation. For rest, see [2]. >> But that's an important part, for three reasons: >> 1. The PIC may not exist when bus_alloc_resource() is called >> 2. The bus parents have no useful information to contribute to this >> since the hierarchy doesn't go that way > See [2] > >> 3. If you try to use the interrupt pin as the resource ID, which >> r301453 does, you end up with rman conflicts if, for example, a bus >> has two children with interrupts on identically numbered pins on two >> different interrupt controllers. > No, r301453 doesn't do this. > Index to global interrupt source table (irq_sources) is used as resource > ID (and r301453 not changed it). Ah, I see that now. Apologies for the confusion. So, to understand fully: your major complaint about the existing code is that it uses arbitrary numbers reflecting some table lookup value as IRQ numbers, which r301453 *also* does? >>>>> >>>>>> There are some other differences, of varying degrees of importance, >>>>>> but that's the really fundamental one. I haven't seen any cases where >>>>>> r301453 provides functionality absent in the already existing system, >>>>>> but there seem to be a large number of cases (see the first email I >>>>>> sent to freebsd-arch or >>>>>> https://wiki.freebsd.org/Complicated_Interrupts) that the API in >>>>>> r301453 cannot accommodate and that are needed to support a >>>>>> variety of >>>>>> hardware. >>>>> Which single feature has been removed by r301453? >>>> Nothing has been removed by it, because the normal code is intact. >>>> However, the new code is less functional than the old code, so cannot >>>> replace it. In particular, it is architecturally incapable of working >>>> with the kinds of device trees found on PowerPC systems (see the wiki >>>> page). That means we would have to keep both indefinitely, which is a >>>> significant maintenance burden to no gain whatsoever. >>>> -Nathan >>> Firstly, please, ignore dependency problem. It will be explained later >>> in [2]. >> Except that that isn't a workable solution (see the end) >> >>> [1] >>> The original (your) INTRNG assume several things: >>> >>> - value of interrupt parent xref together with byte contents of >>> 'interrupts' property forms some sort of 'key' (aka virtual IRQ) >>> - byte contents of 'interrupts' property cannot be parsed in any way >>> inside INTRNG core. >>> - data forming this key are sufficient for subsequent mapping (and/or >>> configuring) to real IRQ. >>> - there must exist bidirectional unique relation between virtual and >>> real IRQs. So one key (virtual IRQ) can be mappable to one and just >>> one >>> real IRQ. And only one virtual IRQ can be mapped to any given real >>> IRQ. >>> - we have cache that stores all observed 'keys' and associated real IRQ >>> ) the they already mapped. >>> >>> Unfortunately, necessity of unique mapping is very problematic. >>> We cannot handle situation, where shared interrupt is declared by >>> different but compatible 'interrupts' properties. >> There isn't actually a requirement of bidirectional uniqueness, as I >> explained the last time you brought this up. One "virtual" IRQ does >> need to map to exactly one interrupt specifier, but the reverse is not >> the case. The PIC driver is absolutely free to map and dispatch >> multiple virtual IRQs from the same shared interrupt pin, with no more >> overhead than you usually get from shared interrupt lines. > Oki, lets me to expand this a little bit more. > > The pre r301453 INTRNG[ARM] does this: > - ofw_bus_intr_to_rl() reads and pre-parses 'interrupts' property > into 'key'. Sometimes. For some buses. ofw_bus_intr_to_rl() is a function of very limited application that should really only be used by simplebus; how that works depends on the bus bindings. There are many cases (e.g. MSIs, PCI buses generally) where interrupts are set up by a different route. > - cache is searched for duplicates and new entry is created. > - position of this entry in cache is used as resource ID. Resource ID is arbitrary, but it could be this. > - given resource ID is stored to RL and is later used in > bus_alloc_resource() Yes. > I'm right ? > > In the above model, individual cache entries may be shared are > referenced by multiple entities (PIC, RL, ..). Due to this, life cycle > of cache entries is not well defined and we probably must use some sort > of reference counting to control it. Why? Interrupts are not unmapped and remapped with unique values often enough (or, really, at all) to warrant even thinking about life-cycle management. The maximum number is limited by the maximum of the number of interrupt specifiers in the device tree, which are all static values. > But, as you wrote, INTRNG code is "absolutely free to map and dispatch > multiple virtual IRQs from the same shared interrupt pin" (allow me to > expand this also to INTRNG code itself) . > In attempt to simply situation abound cache, in first step, we removed > duplicates check from above model. This also removes unpleasantly > sharing of entries. > This step converts cache to some sort of duplicate of resource list > entries. Each existing RLE have exactly one corresponding entry in cache. > Also, the cache is not needed for INTRNG core. At this point, its only > transfers data from ofw_bus_intr_to_rl() to consumers PIC. > > So, if we are able to attach 'key' to RLE, then we can remove the whole > cache machinery from INTRNG. > Do you agree? No. Because you have to support two things that this still can't allow: 1. Devices attaching before their interrupt controllers. 2. Interrupts encoded entirely in a 32-bit integer rather than a struct resource * in a shared rman. This is required to support PCI (both LSI and MSI). #2 could of course be fixed by completely retooling the API of the PCI bus code, but, since it fixes something that currently is not a problem, why would we do that? > >>> For example: >>> ------------------------- >>> foo1: bar@12345678 { >>> interrupt-parent = <&pic1>; >>> interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; >>> } >>> >>> foo2: bar@1234567C { >>> interrupt-parent = <&pic1>; >>> interrupts = <1 IRQ_TYPE_NONE>; >>> } >>> >>> Is this valid (from DT point of view) configuration? I think that yes. >> No, it's malformed and a violation of the standard. > Can you give me pointer, please? I'm not able to find anything about > this... I will try to find the reference -- unfortunately these things are scattered about and not all of the documents are public. You can see that this must be invalid immediately, however, because it would make the interrupt configuration dependent on which devices attach and in which order. I've attached the main interrupt mapping spec if you would like to look at it. > >>> Is this frequent configuration? I'm sure, isn't. >>> Is this possible configuration? I'm afraid that yes. >> People do in fact do deranged non-conformant things with device trees >> sometimes, unfortunately, so it is indeed worth worrying about. >> >>> -------------------------- >>> >>> Next example are GPIO interrupts. These are encoded differently, so two >>> 'keys' may point to to same real IRQ. >>> After that we decided to change our approach and utilize standard >>> resources and resource list entries to deliveryconfiguration data from >>> various sources (OFW/GPIO/...) to consumers. >> This is a non-issue. You make the GPIO controller a PIC, it handles >> interrupts however you like. If you got a weird device tree that uses >> two encodings (one for "interrupts" properties with GPIOs and one for >> "GPIO" properties on which you need to take interrupts but that >> weren't added to the "interrupts" list for mysterious reasons), you >> introduce a helper function for the GPIO case. >> >> Are there any actual problems with the pre-existing interrupt mapping >> code? I have not seen any so far. >> >>> [2] >>> Each OFW device has a lot of dependencies. It must enable clocks, power >>> regulators..., it must be taken from reset. All these action must be >>> done before we can access single register. >>> Most of these action can be done only with attached clock/power/reset >>> controller. >>> Within this, interrupts are not special. >> They are actually quite special in that the kernel enables them late >> and so you can defer setup. They are also special in that, for that >> reason, it is possible to design systems with circular dependency >> graphs with interrupts. It is not possible to do this with, for >> example, clocks: if I need to apply a clock to the clock controller >> with itself, the system is just not bootable and such a system will >> not be built or shipped. Interrupts need only happen later, after >> device setup, and so such systems *are* designed and shipped. The same >> is true for power. > The G5 problem is standard 'cross type' circular dependency. You must > (at BUS_PASS_BUS) initialize memory address window of PCI bridge and > start bus enumeration. > Rest of PCI bridge initialization (including all IRQ stuff) must be > postponed to any later pass. Of course, all interrupt controllers must > be attached at BUS_PASS_INTERRUPT. > Or I missed something? Yes. As I said, you could solve it that way. It would, of course, require a massive retooling of newbus (to allow partial delayed attach), everything in dev/pci (which doesn't expect that), and (almost) every PCI driver in and out of the tree. Or: you could skip all of that and use the fully functional mechanism that already exists. This is my point in a nutshell, basically. This code reinvents a perfectly functional wheel in a way that could, in the future, with a huge amount of work, accomplish the same things. For now, it is less functional and offers no visible advantages or new capabilities of any kind -- nor are there any such capabilities it could obviously provide in the future. Between now and that future, which will likely never arrive, we will have to maintain both in parallel and cause the device tree support on ARM and PowerPC to diverge. -Nathan >>> Moreover, 'cross type' circular >>> dependencies are not that rare. >>> I want to say: >>> Resource dependencies are must solved (and resolved) at different level >>> than is INTRNG. >>> Blind resource allocation is not universal solution because given >>> resource may/must be accessible immediately after allocation (in many >>> cases). >> Absolutely: for GPIOs, clocks, power, etc. you want a system that >> looks different than the interrupt virtualization system. Probably >> with extra resource types and maybe with some API similar to r301453. >> But interrupts have different, and more complex, requirements and >> cannot be mapped this way. >> >>> Unfortunately, and at time time, I known only one really working >>> solution: >>> staggered driver initialization combined with multipass bus >>> initialization. >> That does not solve the interrupt problem. If devices have interrupts >> on their own children, no amount of multipass initialization can >> possibly break the loop. Multipass would work for other kinds of >> resources (clocks, power, etc.) and is a perfect match for those >> resource types. A dynamic multipass (where a driver can return EAGAIN >> or something from attach if its resources don't exist yet) would work >> great. >> >> *But* in the specific, special case of interrupts, it is not a >> workable model. You could imagine some change to initialization that >> gives devices a late attach and an early attach method and does >> interrupts in the late part, but that is hugely invasive change that >> would need to touch every single driver in the tree -- to solve a >> problem that is already solved by interrupt virtualization. >> -Nathan >> >>> I'm sorry, I'm not able to express all this accurately and clearly, but >>> I've really tried... >>> Michal >>> >>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Jul 28 23:50:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99D3BBA7D82 for ; Thu, 28 Jul 2016 23:50:09 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp-fo.rcn.cmh.synacor.com [69.168.97.80]) (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 6B4831EEB for ; Thu, 28 Jul 2016 23:50:08 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=UPOfJ2Xy c=1 sm=1 tr=0 a=dx250bZxW1HngxdpQMIA3g==:117 a=dx250bZxW1HngxdpQMIA3g==:17 a=IkcTkHD0fZMA:10 a=YfCOm-DyAAAA:8 a=pI9CPU1vSd18lklMK-kA:9 a=dlp_2DpfmD4A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=NWVoK91CQySWRX1oVYDe:22 a=zQLMK8awuJ6_Hvp-_9Ux:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 24.148.20.233 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.233] ([24.148.20.233:10222] helo=[192.168.3.100]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPSA (cipher=DHE-RSA-AES256-SHA) id 25/6F-61435-92A9A975; Thu, 28 Jul 2016 19:50:02 -0400 From: Erik Moe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: U-boot issues on Banana Pi M2 Message-Id: <0403B533-40BC-4674-84CC-2CC3F732B45E@rcn.com> Date: Thu, 28 Jul 2016 18:49:59 -0500 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 23:50:09 -0000 I=E2=80=99m having some issues with the u-boot-bananapim2 in ports. It = looks like a data abort exception. Does anybody else have a BPI M2 that = this port is working for them? If I read this right it=E2=80=99s dying = in the following function: 4a00218c g F .text 00000038 sunxi_gpio_set_cfgpin I think someone reported a similar but not the same issue upstream: = http://lists.denx.de/pipermail/u-boot/2016-June/258837.html Thanks, Erik U-Boot SPL 2016.07 (Jul 16 2016 - 02:40:04) DRAM: 1024 MiB Trying to boot from MMC1 U-Boot 2016.07 (Jul 16 2016 - 02:40:04 -0500) Allwinner Technology CPU: Allwinner A31s (SUN6I) Model: Sinovoip BPI-M2 DRAM: 1 GiB WARNING: Caches not enabled MMC: SUNXI SD/MMC: 0 reading u-boot.env ** Unable to read "u-boot.env" from mmc0:1 ** Using default environment In: serial Out: serial Err: serial Net: data abort pc : [<7ef5f180>] lr : [<00000000>] reloc pc : [<4a002180>] lr : [] sp : 7af35f84 ip : 7efab502 fp : 00000017 r10: 7efaaefe r9 : 7af3cee8 r8 : 000040a0 r7 : 7ef9ee14 r6 : 00000000 r5 : 00000001 r4 : 00000000 r3 : 0000000f r2 : 00000001 r1 : 00000000 r0 : ea00000e Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... From owner-freebsd-arm@freebsd.org Fri Jul 29 07:03:42 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D14CBA6D4B; Fri, 29 Jul 2016 07:03:42 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E2F3B1D3D; Fri, 29 Jul 2016 07:03:41 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 781CD3ACF0; Fri, 29 Jul 2016 09:03:33 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <579AFFC5.1040005@FreeBSD.org> Date: Fri, 29 Jul 2016 09:03:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Fri, 29 Jul 2016 09:03:33 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 07:03:42 -0000 Dne 28.07.2016 v 19:23 Nathan Whitehorn napsal(a): > > > On 07/28/16 08:33, Michal Meloun wrote: >> Dne 27.07.2016 v 19:19 Nathan Whitehorn napsal(a): >>> >>> On 07/27/16 09:27, Michal Meloun wrote: >>> >>> >>> [snip] >>>>> The concept is *extremely* necessary, which is why both Linux and >>>>> FreeBSD decided to use it independently There is no way to handle >>>>> parent buses with a single rman and devices on multiple PICs with >>>>> overlapping interrupt ranges without them; neither is there a way to >>>>> decode arbitrary-length interrupt specifiers or to handle things like >>>>> MSIs. Please see the list of cases at >>>>> https://wiki.freebsd.org/Complicated_Interrupts and in my earlier >>>>> email for some examples of things that you just can't represent with >>>>> this new system, as far as I can tell. >>>>> >>>>>> Also, both variants needs attached PIC at bus_alloc_resource() >>>>>> time, >>>>>> so timing wasn't been changed. >>>>> They absolutely do not, as I have explained repeatedly. Due to parent >>>>> devices with interrupts handled by their bus children, this is a hard >>>>> requirement of any workable system. This is not a theoretical >>>>> issue; I >>>>> have lots of hardware like this. >>>> Nathan, I'm talking about pre /post r301453 state. Current >>>> INTRNG it >>>> has never supported. But yes, I'm fully understand why you want >>>> it. See >>>> [2]. >>> Current "INTRNG", at least on PowerPC, has supported this for 10 >>> years. If it doesn't on ARM, it's because of some trivial >>> implementation bug. >>>>>> - it implements new BUS_MAP_INTR(). As I understand it, this is >>>>>> problematic for you, and I'm ready to change it. But I need more >>>>>> details >>>>>> than "it's fundamentally broken". >>>>> Please explain (a) what cases it handles that the existing code and >>>>> does, and (b) how you would resolve each of the cases on the wiki >>>>> page >>>>> I sent. >>>>> >>>>> The general issue is that it traces the newbus hierarchy, when >>>>> interrupts often do not, and so breaks when you have links to >>>>> as-yet-unattached parts of the hierarchy. It also relies on the >>>>> assigned "IRQ" numbers being nonoverlapping to avoid rman errors, but >>>>> that's a relatively minor thing. >>>> Well, from my point of view, only "get interrupt data from >>>> OFW/GPIO/.." part of bus_alloc_resource() follows bus hierarchy, >>>> real >>>> execution not changed. >>>> In any case, I see many possible variants how we can modify current >>>> implementation. For rest, see [2]. >>> But that's an important part, for three reasons: >>> 1. The PIC may not exist when bus_alloc_resource() is called >>> 2. The bus parents have no useful information to contribute to this >>> since the hierarchy doesn't go that way >> See [2] >> >>> 3. If you try to use the interrupt pin as the resource ID, which >>> r301453 does, you end up with rman conflicts if, for example, a bus >>> has two children with interrupts on identically numbered pins on two >>> different interrupt controllers. >> No, r301453 doesn't do this. >> Index to global interrupt source table (irq_sources) is used as resource >> ID (and r301453 not changed it). > > Ah, I see that now. Apologies for the confusion. > > So, to understand fully: your major complaint about the existing code > is that it uses arbitrary numbers reflecting some table lookup value > as IRQ numbers, which r301453 *also* does? No, my major complaint is that MIPS and pre-r301453 INTRNG mixes data from independent sources in one table (irq_sources) . Which r301453 eliminates. All what I want is to have data associated to RLE separated from data associated to already allocated (by bus_alloc_resouce()) interrupts. >>>>>> >>>>>>> There are some other differences, of varying degrees of importance, >>>>>>> but that's the really fundamental one. I haven't seen any cases >>>>>>> where >>>>>>> r301453 provides functionality absent in the already existing >>>>>>> system, >>>>>>> but there seem to be a large number of cases (see the first email I >>>>>>> sent to freebsd-arch or >>>>>>> https://wiki.freebsd.org/Complicated_Interrupts) that the API in >>>>>>> r301453 cannot accommodate and that are needed to support a >>>>>>> variety of >>>>>>> hardware. >>>>>> Which single feature has been removed by r301453? >>>>> Nothing has been removed by it, because the normal code is intact. >>>>> However, the new code is less functional than the old code, so cannot >>>>> replace it. In particular, it is architecturally incapable of working >>>>> with the kinds of device trees found on PowerPC systems (see the wiki >>>>> page). That means we would have to keep both indefinitely, which is a >>>>> significant maintenance burden to no gain whatsoever. >>>>> -Nathan >>>> Firstly, please, ignore dependency problem. It will be explained >>>> later >>>> in [2]. >>> Except that that isn't a workable solution (see the end) >>> >>>> [1] >>>> The original (your) INTRNG assume several things: >>>> >>>> - value of interrupt parent xref together with byte contents of >>>> 'interrupts' property forms some sort of 'key' (aka virtual IRQ) >>>> - byte contents of 'interrupts' property cannot be parsed in any way >>>> inside INTRNG core. >>>> - data forming this key are sufficient for subsequent mapping (and/or >>>> configuring) to real IRQ. >>>> - there must exist bidirectional unique relation between virtual and >>>> real IRQs. So one key (virtual IRQ) can be mappable to one and just >>>> one >>>> real IRQ. And only one virtual IRQ can be mapped to any >>>> given real >>>> IRQ. >>>> - we have cache that stores all observed 'keys' and associated real >>>> IRQ >>>> ) the they already mapped. >>>> >>>> Unfortunately, necessity of unique mapping is very problematic. >>>> We cannot handle situation, where shared interrupt is declared by >>>> different but compatible 'interrupts' properties. >>> There isn't actually a requirement of bidirectional uniqueness, as I >>> explained the last time you brought this up. One "virtual" IRQ does >>> need to map to exactly one interrupt specifier, but the reverse is not >>> the case. The PIC driver is absolutely free to map and dispatch >>> multiple virtual IRQs from the same shared interrupt pin, with no more >>> overhead than you usually get from shared interrupt lines. >> Oki, lets me to expand this a little bit more. >> >> The pre r301453 INTRNG[ARM] does this: >> - ofw_bus_intr_to_rl() reads and pre-parses 'interrupts' property >> into 'key'. > > Sometimes. For some buses. ofw_bus_intr_to_rl() is a function of very > limited application that should really only be used by simplebus; how > that works depends on the bus bindings. There are many cases (e.g. > MSIs, PCI buses generally) where interrupts are set up by a different > route. Yes, I agree. >> - cache is searched for duplicates and new entry is created. >> - position of this entry in cache is used as resource ID. > > Resource ID is arbitrary, but it could be this. > >> - given resource ID is stored to RL and is later used in >> bus_alloc_resource() > Yes. >> I'm right ? >> >> In the above model, individual cache entries may be shared are >> referenced by multiple entities (PIC, RL, ..). Due to this, life cycle >> of cache entries is not well defined and we probably must use some sort >> of reference counting to control it. > > Why? Interrupts are not unmapped and remapped with unique values often > enough (or, really, at all) to warrant even thinking about life-cycle > management. The maximum number is limited by the maximum of the number > of interrupt specifiers in the device tree, which are all static values. No, we must also support attachable/removable devices. GPIO board attached to hot-pug capable interfaces(USB, ExpressCard,...) for example. Due to this we must be able to attach/detach PIC at run-time. > >> But, as you wrote, INTRNG code is "absolutely free to map and dispatch >> multiple virtual IRQs from the same shared interrupt pin" (allow me to >> expand this also to INTRNG code itself) . >> In attempt to simply situation abound cache, in first step, we removed >> duplicates check from above model. This also removes unpleasantly >> sharing of entries. >> This step converts cache to some sort of duplicate of resource list >> entries. Each existing RLE have exactly one corresponding entry in >> cache. >> Also, the cache is not needed for INTRNG core. At this point, its only >> transfers data from ofw_bus_intr_to_rl() to consumers PIC. >> >> So, if we are able to attach 'key' to RLE, then we can remove the whole >> cache machinery from INTRNG. >> Do you agree? > > No. Because you have to support two things that this still can't allow: > 1. Devices attaching before their interrupt controllers. You still expect that data readed from OFW must be parsed at RLE creation time. I don't see single reason why we cannot postpone parsing to bus_alloc_resource() time. At this point, its irrelevant if bus_alloc_resource() supports detached PIC or not. > 2. Interrupts encoded entirely in a 32-bit integer rather than a > struct resource * in a shared rman. This is required to support PCI > (both LSI and MSI). > > #2 could of course be fixed by completely retooling the API of the PCI > bus code, but, since it fixes something that currently is not a > problem, why would we do that? All relevant bus functions have struct resource * as an argument. And, in post r301453 kernel, all necessary data are attached to it. I don't see any reason for API change. > >> >>>> For example: >>>> ------------------------- >>>> foo1: bar@12345678 { >>>> interrupt-parent = <&pic1>; >>>> interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; >>>> } >>>> >>>> foo2: bar@1234567C { >>>> interrupt-parent = <&pic1>; >>>> interrupts = <1 IRQ_TYPE_NONE>; >>>> } >>>> >>>> Is this valid (from DT point of view) configuration? I think that >>>> yes. >>> No, it's malformed and a violation of the standard. >> Can you give me pointer, please? I'm not able to find anything about >> this... > > I will try to find the reference -- unfortunately these things are > scattered about and not all of the documents are public. Don't worry, I trust you :) > You can see that this must be invalid immediately, however, because it > would make the interrupt configuration dependent on which devices > attach and in which order. I've attached the main interrupt mapping > spec if you would like to look at it. Well, if IRQ_TYPE_LEVEL_HIGH is default interrupt configuration then not. And with current hell with various shield boards and its overlays... >> >>>> Is this frequent configuration? I'm sure, isn't. >>>> Is this possible configuration? I'm afraid that yes. >>> People do in fact do deranged non-conformant things with device trees >>> sometimes, unfortunately, so it is indeed worth worrying about. >>> >>>> -------------------------- >>>> >>>> Next example are GPIO interrupts. These are encoded differently, >>>> so two >>>> 'keys' may point to to same real IRQ. >>>> After that we decided to change our approach and utilize standard >>>> resources and resource list entries to deliveryconfiguration data from >>>> various sources (OFW/GPIO/...) to consumers. >>> This is a non-issue. You make the GPIO controller a PIC, it handles >>> interrupts however you like. If you got a weird device tree that uses >>> two encodings (one for "interrupts" properties with GPIOs and one for >>> "GPIO" properties on which you need to take interrupts but that >>> weren't added to the "interrupts" list for mysterious reasons), you >>> introduce a helper function for the GPIO case. >>> >>> Are there any actual problems with the pre-existing interrupt mapping >>> code? I have not seen any so far. >>> >>>> [2] >>>> Each OFW device has a lot of dependencies. It must enable clocks, >>>> power >>>> regulators..., it must be taken from reset. All these action must be >>>> done before we can access single register. >>>> Most of these action can be done only with attached clock/power/reset >>>> controller. >>>> Within this, interrupts are not special. >>> They are actually quite special in that the kernel enables them late >>> and so you can defer setup. They are also special in that, for that >>> reason, it is possible to design systems with circular dependency >>> graphs with interrupts. It is not possible to do this with, for >>> example, clocks: if I need to apply a clock to the clock controller >>> with itself, the system is just not bootable and such a system will >>> not be built or shipped. Interrupts need only happen later, after >>> device setup, and so such systems *are* designed and shipped. The same >>> is true for power. >> The G5 problem is standard 'cross type' circular dependency. You must >> (at BUS_PASS_BUS) initialize memory address window of PCI bridge and >> start bus enumeration. >> Rest of PCI bridge initialization (including all IRQ stuff) must be >> postponed to any later pass. Of course, all interrupt controllers must >> be attached at BUS_PASS_INTERRUPT. >> Or I missed something? > > Yes. As I said, you could solve it that way. It would, of course, > require a massive retooling of newbus (to allow partial delayed > attach), everything in dev/pci (which doesn't expect that), and > (almost) every PCI driver in and out of the tree. I still think that only host to PCI bridge must me modified, and PCI-PCI bridge must be run at BUS_PASS_BUS (which is single line modification). > > Or: you could skip all of that and use the fully functional mechanism > that already exists. The problem is, at least from my point of view, that we don't have it. The actual MIPS code doesn't work on ARM for numerous reasons. This is first one -> https://svnweb.freebsd.org/base/head/sys/powerpc/powerpc/nexus.c?revision=297000&view=markup#l186 The pre-r301453 ARM INTRNG doesn't support detached interrupts. And r301453 doesn't changed nothing about this. Michal > This is my point in a nutshell, basically. This code reinvents a > perfectly functional wheel in a way that could, in the future, with a > huge amount of work, accomplish the same things. For now, it is less > functional and offers no visible advantages or new capabilities of any > kind -- nor are there any such capabilities it could obviously provide > in the future. Between now and that future, which will likely never > arrive, we will have to maintain both in parallel and cause the device > tree support on ARM and PowerPC to diverge. > -Nathan > >>>> Moreover, 'cross type' circular >>>> dependencies are not that rare. >>>> I want to say: >>>> Resource dependencies are must solved (and resolved) at different >>>> level >>>> than is INTRNG. >>>> Blind resource allocation is not universal solution because given >>>> resource may/must be accessible immediately after allocation (in many >>>> cases). >>> Absolutely: for GPIOs, clocks, power, etc. you want a system that >>> looks different than the interrupt virtualization system. Probably >>> with extra resource types and maybe with some API similar to r301453. >>> But interrupts have different, and more complex, requirements and >>> cannot be mapped this way. >>> >>>> Unfortunately, and at time time, I known only one really working >>>> solution: >>>> staggered driver initialization combined with multipass bus >>>> initialization. >>> That does not solve the interrupt problem. If devices have interrupts >>> on their own children, no amount of multipass initialization can >>> possibly break the loop. Multipass would work for other kinds of >>> resources (clocks, power, etc.) and is a perfect match for those >>> resource types. A dynamic multipass (where a driver can return EAGAIN >>> or something from attach if its resources don't exist yet) would work >>> great. >>> >>> *But* in the specific, special case of interrupts, it is not a >>> workable model. You could imagine some change to initialization that >>> gives devices a late attach and an early attach method and does >>> interrupts in the late part, but that is hugely invasive change that >>> would need to touch every single driver in the tree -- to solve a >>> problem that is already solved by interrupt virtualization. >>> -Nathan >>> >>>> I'm sorry, I'm not able to express all this accurately and clearly, >>>> but >>>> I've really tried... >>>> Michal >>>> >>>> >>>> _______________________________________________ >>>> freebsd-arch@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >>>> To unsubscribe, send any mail to >>>> "freebsd-arch-unsubscribe@freebsd.org" >>>> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > From owner-freebsd-arm@freebsd.org Fri Jul 29 07:29:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00CF4BA764F for ; Fri, 29 Jul 2016 07:29:35 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6608B18BE for ; Fri, 29 Jul 2016 07:29:33 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id aa6b58d0; Fri, 29 Jul 2016 09:29:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=x+rGTatNY6ACHt76EVeo31y6nuQ=; b=dOYPRf7u+cnjIs9/7nLbwlSy/Xuw AiRs8lTUHs/ybSBxSjwC5ILyjZq6793fzRcpC+c9yGiUkfU571pegeT7P0ORuiHu lBxcRpZkVMFtL43CnrnikIGJQzQyZ4EFfrNsjvpF+j91i7hwwSkeELkOh9GJMtwn +VCQbsGU8/qdOXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=bgC8nc0q3+jMK5ghPLR6RDWHIyRqXpBobcsCWPnRpfwR+2nnRQApr6Wk L7GCYK3BK9wMRgUbAoamB+ntnYflh8gQ+ulYF7XIazBD9FueufszJh9VDOaIIJdt ZQWXYrWgjrmVyLDV0z27qBToSYLJJbnOTuPAhgCLwY2OiwFpseU= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id b9c917db TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 29 Jul 2016 09:29:24 +0200 (CEST) Date: Fri, 29 Jul 2016 09:29:24 +0200 From: Emmanuel Vadot To: Erik Moe Cc: freebsd-arm Subject: Re: U-boot issues on Banana Pi M2 Message-Id: <20160729092924.76acd5aaae62560f0c7b58b4@bidouilliste.com> In-Reply-To: <0403B533-40BC-4674-84CC-2CC3F732B45E@rcn.com> References: <0403B533-40BC-4674-84CC-2CC3F732B45E@rcn.com> X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 07:29:35 -0000 Hello Erik, I can reproduce the issue, until I fix it can you test reverting the last update of sysutils/u-boot-olimex-a20-som-evb (this is the master port that u-boot-bananapim2 is using) ? Switching back to 2016.05 worked for me. I'll try to find some times this weekend to fix this. Thanks, On Thu, 28 Jul 2016 18:49:59 -0500 Erik Moe wrote: > I?m having some issues with the u-boot-bananapim2 in ports. It looks lik= e a data abort exception. Does anybody else have a BPI M2 that this port i= s working for them? If I read this right it?s dying in the following funct= ion: >=20 > 4a00218c g F .text 00000038 sunxi_gpio_set_cfgpin >=20 > I think someone reported a similar but not the same issue upstream: http= ://lists.denx.de/pipermail/u-boot/2016-June/258837.html >=20 > Thanks, > Erik >=20 >=20 > U-Boot SPL 2016.07 (Jul 16 2016 - 02:40:04) > DRAM: 1024 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2016.07 (Jul 16 2016 - 02:40:04 -0500) Allwinner Technology >=20 > CPU: Allwinner A31s (SUN6I) > Model: Sinovoip BPI-M2 > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: SUNXI SD/MMC: 0 > reading u-boot.env >=20 > ** Unable to read "u-boot.env" from mmc0:1 ** > Using default environment >=20 > In: serial > Out: serial > Err: serial > Net: data abort > pc : [<7ef5f180>] lr : [<00000000>] > reloc pc : [<4a002180>] lr : [] > sp : 7af35f84 ip : 7efab502 fp : 00000017 > r10: 7efaaefe r9 : 7af3cee8 r8 : 000040a0 > r7 : 7ef9ee14 r6 : 00000000 r5 : 00000001 r4 : 00000000 > r3 : 0000000f r2 : 00000001 r1 : 00000000 r0 : ea00000e > Flags: nzCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... >=20 > resetting ... >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Jul 29 14:41:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BD16BA74F5; Fri, 29 Jul 2016 14:41:32 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 114C1135A; Fri, 29 Jul 2016 14:41:31 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6TEfMW1014844 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2016 07:41:22 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: Date: Fri, 29 Jul 2016 07:41:22 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <579AFFC5.1040005@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVagc1QqOjDoKcjiAOycMFsq9P5oNOKeSVIPQqgGl3SzQ6ACkveVsPokOKkjrdqa9byoYMxgMwsv+uWmGcHpXMkQOMNW1Mc7TBs= X-Sonic-ID: C;aArRhJpV5hGZNpNwxPCmMQ== M;2t8QhZpV5hGZNpNwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 14:41:32 -0000 On 07/29/16 00:03, Michal Meloun wrote: > Dne 28.07.2016 v 19:23 Nathan Whitehorn napsal(a): >> >> On 07/28/16 08:33, Michal Meloun wrote: >>> Dne 27.07.2016 v 19:19 Nathan Whitehorn napsal(a): >>>> On 07/27/16 09:27, Michal Meloun wrote: >>>> >>>> >>>> [snip] >>>>>> The concept is *extremely* necessary, which is why both Linux and >>>>>> FreeBSD decided to use it independently There is no way to handle >>>>>> parent buses with a single rman and devices on multiple PICs with >>>>>> overlapping interrupt ranges without them; neither is there a way to >>>>>> decode arbitrary-length interrupt specifiers or to handle things like >>>>>> MSIs. Please see the list of cases at >>>>>> https://wiki.freebsd.org/Complicated_Interrupts and in my earlier >>>>>> email for some examples of things that you just can't represent with >>>>>> this new system, as far as I can tell. >>>>>> >>>>>>> Also, both variants needs attached PIC at bus_alloc_resource() >>>>>>> time, >>>>>>> so timing wasn't been changed. >>>>>> They absolutely do not, as I have explained repeatedly. Due to parent >>>>>> devices with interrupts handled by their bus children, this is a hard >>>>>> requirement of any workable system. This is not a theoretical >>>>>> issue; I >>>>>> have lots of hardware like this. >>>>> Nathan, I'm talking about pre /post r301453 state. Current >>>>> INTRNG it >>>>> has never supported. But yes, I'm fully understand why you want >>>>> it. See >>>>> [2]. >>>> Current "INTRNG", at least on PowerPC, has supported this for 10 >>>> years. If it doesn't on ARM, it's because of some trivial >>>> implementation bug. >>>>>>> - it implements new BUS_MAP_INTR(). As I understand it, this is >>>>>>> problematic for you, and I'm ready to change it. But I need more >>>>>>> details >>>>>>> than "it's fundamentally broken". >>>>>> Please explain (a) what cases it handles that the existing code and >>>>>> does, and (b) how you would resolve each of the cases on the wiki >>>>>> page >>>>>> I sent. >>>>>> >>>>>> The general issue is that it traces the newbus hierarchy, when >>>>>> interrupts often do not, and so breaks when you have links to >>>>>> as-yet-unattached parts of the hierarchy. It also relies on the >>>>>> assigned "IRQ" numbers being nonoverlapping to avoid rman errors, but >>>>>> that's a relatively minor thing. >>>>> Well, from my point of view, only "get interrupt data from >>>>> OFW/GPIO/.." part of bus_alloc_resource() follows bus hierarchy, >>>>> real >>>>> execution not changed. >>>>> In any case, I see many possible variants how we can modify current >>>>> implementation. For rest, see [2]. >>>> But that's an important part, for three reasons: >>>> 1. The PIC may not exist when bus_alloc_resource() is called >>>> 2. The bus parents have no useful information to contribute to this >>>> since the hierarchy doesn't go that way >>> See [2] >>> >>>> 3. If you try to use the interrupt pin as the resource ID, which >>>> r301453 does, you end up with rman conflicts if, for example, a bus >>>> has two children with interrupts on identically numbered pins on two >>>> different interrupt controllers. >>> No, r301453 doesn't do this. >>> Index to global interrupt source table (irq_sources) is used as resource >>> ID (and r301453 not changed it). >> Ah, I see that now. Apologies for the confusion. >> >> So, to understand fully: your major complaint about the existing code >> is that it uses arbitrary numbers reflecting some table lookup value >> as IRQ numbers, which r301453 *also* does? > No, my major complaint is that MIPS and pre-r301453 INTRNG mixes data > from independent sources in one table (irq_sources) . Which r301453 > eliminates. > All what I want is to have data associated to RLE separated from data > associated to already allocated (by bus_alloc_resouce()) interrupts. So the complaint is that pre-r301453 stores the raw interrupt specifier in the table and post-r301453 stores a decoded version of the interrupt specifier in the table? >>>>>>> >>>>>>>> There are some other differences, of varying degrees of importance, >>>>>>>> but that's the really fundamental one. I haven't seen any cases >>>>>>>> where >>>>>>>> r301453 provides functionality absent in the already existing >>>>>>>> system, >>>>>>>> but there seem to be a large number of cases (see the first email I >>>>>>>> sent to freebsd-arch or >>>>>>>> https://wiki.freebsd.org/Complicated_Interrupts) that the API in >>>>>>>> r301453 cannot accommodate and that are needed to support a >>>>>>>> variety of >>>>>>>> hardware. >>>>>>> Which single feature has been removed by r301453? >>>>>> Nothing has been removed by it, because the normal code is intact. >>>>>> However, the new code is less functional than the old code, so cannot >>>>>> replace it. In particular, it is architecturally incapable of working >>>>>> with the kinds of device trees found on PowerPC systems (see the wiki >>>>>> page). That means we would have to keep both indefinitely, which is a >>>>>> significant maintenance burden to no gain whatsoever. >>>>>> -Nathan >>>>> Firstly, please, ignore dependency problem. It will be explained >>>>> later >>>>> in [2]. >>>> Except that that isn't a workable solution (see the end) >>>> >>>>> [1] >>>>> The original (your) INTRNG assume several things: >>>>> >>>>> - value of interrupt parent xref together with byte contents of >>>>> 'interrupts' property forms some sort of 'key' (aka virtual IRQ) >>>>> - byte contents of 'interrupts' property cannot be parsed in any way >>>>> inside INTRNG core. >>>>> - data forming this key are sufficient for subsequent mapping (and/or >>>>> configuring) to real IRQ. >>>>> - there must exist bidirectional unique relation between virtual and >>>>> real IRQs. So one key (virtual IRQ) can be mappable to one and just >>>>> one >>>>> real IRQ. And only one virtual IRQ can be mapped to any >>>>> given real >>>>> IRQ. >>>>> - we have cache that stores all observed 'keys' and associated real >>>>> IRQ >>>>> ) the they already mapped. >>>>> >>>>> Unfortunately, necessity of unique mapping is very problematic. >>>>> We cannot handle situation, where shared interrupt is declared by >>>>> different but compatible 'interrupts' properties. >>>> There isn't actually a requirement of bidirectional uniqueness, as I >>>> explained the last time you brought this up. One "virtual" IRQ does >>>> need to map to exactly one interrupt specifier, but the reverse is not >>>> the case. The PIC driver is absolutely free to map and dispatch >>>> multiple virtual IRQs from the same shared interrupt pin, with no more >>>> overhead than you usually get from shared interrupt lines. >>> Oki, lets me to expand this a little bit more. >>> >>> The pre r301453 INTRNG[ARM] does this: >>> - ofw_bus_intr_to_rl() reads and pre-parses 'interrupts' property >>> into 'key'. >> Sometimes. For some buses. ofw_bus_intr_to_rl() is a function of very >> limited application that should really only be used by simplebus; how >> that works depends on the bus bindings. There are many cases (e.g. >> MSIs, PCI buses generally) where interrupts are set up by a different >> route. > Yes, I agree. >>> - cache is searched for duplicates and new entry is created. >>> - position of this entry in cache is used as resource ID. >> Resource ID is arbitrary, but it could be this. >> >>> - given resource ID is stored to RL and is later used in >>> bus_alloc_resource() >> Yes. >>> I'm right ? >>> >>> In the above model, individual cache entries may be shared are >>> referenced by multiple entities (PIC, RL, ..). Due to this, life cycle >>> of cache entries is not well defined and we probably must use some sort >>> of reference counting to control it. >> Why? Interrupts are not unmapped and remapped with unique values often >> enough (or, really, at all) to warrant even thinking about life-cycle >> management. The maximum number is limited by the maximum of the number >> of interrupt specifiers in the device tree, which are all static values. > No, we must also support attachable/removable devices. GPIO board > attached to hot-pug capable interfaces(USB, ExpressCard,...) for example. > Due to this we must be able to attach/detach PIC at run-time. OK... There just really aren't that many cases of this, but fine. If you find yourself needing hot-pluggable PICs, neither API is any more or less complicated than the other. You can't use FDT entries for this, since new devices aren't in the FDT, and you presumably end up in a much more packaged situation where only the things on the hotplug card depend on the PIC on the hotplug device, so that's nice. In either case, you just have to clean up mappings to the associated PIC when the PIC detaches (and would, in both cases, have some assert that all IRQs handled by that PIC have been deallocated first before cleaning up). But it's just not that bad. >>> But, as you wrote, INTRNG code is "absolutely free to map and dispatch >>> multiple virtual IRQs from the same shared interrupt pin" (allow me to >>> expand this also to INTRNG code itself) . >>> In attempt to simply situation abound cache, in first step, we removed >>> duplicates check from above model. This also removes unpleasantly >>> sharing of entries. >>> This step converts cache to some sort of duplicate of resource list >>> entries. Each existing RLE have exactly one corresponding entry in >>> cache. >>> Also, the cache is not needed for INTRNG core. At this point, its only >>> transfers data from ofw_bus_intr_to_rl() to consumers PIC. >>> >>> So, if we are able to attach 'key' to RLE, then we can remove the whole >>> cache machinery from INTRNG. >>> Do you agree? >> No. Because you have to support two things that this still can't allow: >> 1. Devices attaching before their interrupt controllers. > You still expect that data readed from OFW must be parsed at RLE > creation time. I don't see single reason why we cannot postpone > parsing to bus_alloc_resource() time. > At this point, its irrelevant if bus_alloc_resource() supports > detached PIC or not. Because there are *lots* of cases in the kernel where interrupts are represented as a number and not a struct resource *. I've listed many of them; I'm sure there are more. PCI is the most notable example (both LSI and MSI). For both of these, the route_interrupt (LSI) and alloc_msi[x]() (MSI) functions give the bus driver a chance to look at the device tree and then they return an IRQ number. There doesn't seem to be any way to map that back to a struct resource * or something besides an internal table. Moreover, there are cases (self-added interrupts by children, for instance) in which the RL assigned by the parent does not reflect the final RL used by the child and there is no way for the parent bus to map an RID to a device tree entry. When we moved to doing this at interrupt assignment time rather than resource allocation time or another occasion on PowerPC, it was for these kinds of reasons. There were ways to do it later, but they were hugely invasive and involved changing large parts of the kernel. Even then, it would still be fragile: Trying to guess what device tree entry was meant at bus_alloc_resource() time is much more error-prone than doing the mapping when reading that device tree to assign the resources in the first place, when you can make guarantees. > >> 2. Interrupts encoded entirely in a 32-bit integer rather than a >> struct resource * in a shared rman. This is required to support PCI >> (both LSI and MSI). >> >> #2 could of course be fixed by completely retooling the API of the PCI >> bus code, but, since it fixes something that currently is not a >> problem, why would we do that? > All relevant bus functions have struct resource * as an argument. And, > in post r301453 kernel, all necessary data are attached to it. > I don't see any reason for API change. There is: int PCIB_ROUTE_INTERRUPT(device_t, device_t, pin) Which takes a PIN (A, B, C, D) and returns the IRQ to add to the RL. This is the only real opportunity to parse an interrupt-map and does not deal with struct resource. There are also PCIB_ALLOC_MSI[X], which take a device_t and count and return a vector of IRQ numbers. How would you do resource allocation given these APIs? There seem to be some dubious-looking attempts at generic MSI mapping code in the new kern/subr_intr.c that don't allow the specification of more than 32-bit interrupt specifiers and otherwise exactly duplicate the pre-301453 flow for MSIs, but in a more complicated and less-functional way. (While investigating this, I also just found dev/pci/pci_host_generic.c, which mostly does the wrong things, is actually specific to a couple of ARM boards, and duplicates code in dev/ofw/ofwpci.c. But that's another discussion...) > >>>>> For example: >>>>> ------------------------- >>>>> foo1: bar@12345678 { >>>>> interrupt-parent = <&pic1>; >>>>> interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; >>>>> } >>>>> >>>>> foo2: bar@1234567C { >>>>> interrupt-parent = <&pic1>; >>>>> interrupts = <1 IRQ_TYPE_NONE>; >>>>> } >>>>> >>>>> Is this valid (from DT point of view) configuration? I think that >>>>> yes. >>>> No, it's malformed and a violation of the standard. >>> Can you give me pointer, please? I'm not able to find anything about >>> this... >> I will try to find the reference -- unfortunately these things are >> scattered about and not all of the documents are public. > Don't worry, I trust you :) > >> You can see that this must be invalid immediately, however, because it >> would make the interrupt configuration dependent on which devices >> attach and in which order. I've attached the main interrupt mapping >> spec if you would like to look at it. > Well, if IRQ_TYPE_LEVEL_HIGH is default interrupt configuration then > not. And with current hell with various shield boards and its overlays... As I said, people do stupid things. This is such a minor problem that it is best worried about when seen in the wild. > >>>>> Is this frequent configuration? I'm sure, isn't. >>>>> Is this possible configuration? I'm afraid that yes. >>>> People do in fact do deranged non-conformant things with device trees >>>> sometimes, unfortunately, so it is indeed worth worrying about. >>>> >>>>> -------------------------- >>>>> >>>>> Next example are GPIO interrupts. These are encoded differently, >>>>> so two >>>>> 'keys' may point to to same real IRQ. >>>>> After that we decided to change our approach and utilize standard >>>>> resources and resource list entries to deliveryconfiguration data from >>>>> various sources (OFW/GPIO/...) to consumers. >>>> This is a non-issue. You make the GPIO controller a PIC, it handles >>>> interrupts however you like. If you got a weird device tree that uses >>>> two encodings (one for "interrupts" properties with GPIOs and one for >>>> "GPIO" properties on which you need to take interrupts but that >>>> weren't added to the "interrupts" list for mysterious reasons), you >>>> introduce a helper function for the GPIO case. >>>> >>>> Are there any actual problems with the pre-existing interrupt mapping >>>> code? I have not seen any so far. >>>> >>>>> [2] >>>>> Each OFW device has a lot of dependencies. It must enable clocks, >>>>> power >>>>> regulators..., it must be taken from reset. All these action must be >>>>> done before we can access single register. >>>>> Most of these action can be done only with attached clock/power/reset >>>>> controller. >>>>> Within this, interrupts are not special. >>>> They are actually quite special in that the kernel enables them late >>>> and so you can defer setup. They are also special in that, for that >>>> reason, it is possible to design systems with circular dependency >>>> graphs with interrupts. It is not possible to do this with, for >>>> example, clocks: if I need to apply a clock to the clock controller >>>> with itself, the system is just not bootable and such a system will >>>> not be built or shipped. Interrupts need only happen later, after >>>> device setup, and so such systems *are* designed and shipped. The same >>>> is true for power. >>> The G5 problem is standard 'cross type' circular dependency. You must >>> (at BUS_PASS_BUS) initialize memory address window of PCI bridge and >>> start bus enumeration. >>> Rest of PCI bridge initialization (including all IRQ stuff) must be >>> postponed to any later pass. Of course, all interrupt controllers must >>> be attached at BUS_PASS_INTERRUPT. >>> Or I missed something? >> Yes. As I said, you could solve it that way. It would, of course, >> require a massive retooling of newbus (to allow partial delayed >> attach), everything in dev/pci (which doesn't expect that), and >> (almost) every PCI driver in and out of the tree. > I still think that only host to PCI bridge must me modified, and PCI-PCI > bridge must be run at BUS_PASS_BUS (which is single line modification). On Powermacs, one PIC is 5 levels deep in the bus hierarchy, under 3 PCI<->PCI bridges and a device that also has an ATA controller and a bunch of other things. Some of those can have their own interrupts (which is fairly common for error reporting or PCI-E hotplug). It wouldn't be impossible, but it is decidedly nontrivial. >> Or: you could skip all of that and use the fully functional mechanism >> that already exists. > The problem is, at least from my point of view, that we don't have it. > The actual MIPS code doesn't work on ARM for numerous reasons. This is > first one -> > > https://svnweb.freebsd.org/base/head/sys/powerpc/powerpc/nexus.c?revision=297000&view=markup#l186 > The pre-r301453 ARM INTRNG doesn't support detached interrupts. > And r301453 doesn't changed nothing about this. I'm happy to write whatever code is missing. The ARM implementation of ofw_bus_map_intr() does seem fairly braindead and should be replaced. So here is where I am right now: - The perceived advantage of the new API seems to be that the mapping information (interrupt parent, etc.) ends up in a struct resource instead of in a centralized mapping table - Additionally, it gives you a better shot at having the PIC online before the PIC's interrupts are parsed (which is not required, but nice). - Beyond these aesthetic points, there are no concrete examples of new functionality added by this API, aside from some minor implementation bugs of the old one on ARM that are easily fixed. - There are, conversely, a number of concrete cases where this new API would not be able to do the right thing. Some of these can be worked around or fixed with significant restructuring in the MI parts of the kernel. - If we have both, the interrupt handling code in the MI parts of the kernel will bifurcate. This patch alone has added a bunch of #ifdef to kern/subr_bus.c, a new file to kern/, and lots of #ifdef to dev/ofw. This is going to be really hard to maintain if we need both. Is this all correct? If so, can we please back this out until this discussion is complete? I'm asking this formally at this point, under the Committer's Guide section about reversion requests. -Nathan > Michal > >> This is my point in a nutshell, basically. This code reinvents a >> perfectly functional wheel in a way that could, in the future, with a >> huge amount of work, accomplish the same things. For now, it is less >> functional and offers no visible advantages or new capabilities of any >> kind -- nor are there any such capabilities it could obviously provide >> in the future. Between now and that future, which will likely never >> arrive, we will have to maintain both in parallel and cause the device >> tree support on ARM and PowerPC to diverge. >> -Nathan >> >>>>> Moreover, 'cross type' circular >>>>> dependencies are not that rare. >>>>> I want to say: >>>>> Resource dependencies are must solved (and resolved) at different >>>>> level >>>>> than is INTRNG. >>>>> Blind resource allocation is not universal solution because given >>>>> resource may/must be accessible immediately after allocation (in many >>>>> cases). >>>> Absolutely: for GPIOs, clocks, power, etc. you want a system that >>>> looks different than the interrupt virtualization system. Probably >>>> with extra resource types and maybe with some API similar to r301453. >>>> But interrupts have different, and more complex, requirements and >>>> cannot be mapped this way. >>>> >>>>> Unfortunately, and at time time, I known only one really working >>>>> solution: >>>>> staggered driver initialization combined with multipass bus >>>>> initialization. >>>> That does not solve the interrupt problem. If devices have interrupts >>>> on their own children, no amount of multipass initialization can >>>> possibly break the loop. Multipass would work for other kinds of >>>> resources (clocks, power, etc.) and is a perfect match for those >>>> resource types. A dynamic multipass (where a driver can return EAGAIN >>>> or something from attach if its resources don't exist yet) would work >>>> great. >>>> >>>> *But* in the specific, special case of interrupts, it is not a >>>> workable model. You could imagine some change to initialization that >>>> gives devices a late attach and an early attach method and does >>>> interrupts in the late part, but that is hugely invasive change that >>>> would need to touch every single driver in the tree -- to solve a >>>> problem that is already solved by interrupt virtualization. >>>> -Nathan >>>> >>>>> I'm sorry, I'm not able to express all this accurately and clearly, >>>>> but >>>>> I've really tried... >>>>> Michal >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-arch@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >>>>> To unsubscribe, send any mail to >>>>> "freebsd-arch-unsubscribe@freebsd.org" >>>>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> From owner-freebsd-arm@freebsd.org Fri Jul 29 23:16:27 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 332D8BA75D6; Fri, 29 Jul 2016 23:16:27 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F24F211EA; Fri, 29 Jul 2016 23:16:26 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-io0-f179.google.com with SMTP id q83so142358604iod.1; Fri, 29 Jul 2016 16:16:26 -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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1/dzjY4rjQhu54eGdT3PiIKE5UVeyEAndD2vRgbSnzI=; b=aETbDCHCz4ywEilPcMPYCXkMwL9Tc6Wu0e8QeMDoxL35I4iznmFyihDvLmMcgvgneZ +Ew3snOLOyLq+xRagq1B2zHDCwJxWEspsrAVfCE/lSmt0WxExa/wOcySCvUYphY7f7UL /gq6chGap5kZscmOdZ6qhQTODfCmhU0sz/XgEn5AW+vsJoemjekoNIFB6tObUfohWLvQ LrH/q5aIMyZ6au6II3cY5BuClKEAFP12I8LqF5ZYLXVKAesewUC1e6gUSDKtKn6XKVh3 v26SSuxa+DYpw5GhJzEYsigiKxEM7ET4Ugv0yAPqukoNzp3ogKP5jrTi3gNJ+M7g6dPb g8GQ== X-Gm-Message-State: AEkoouv4rjU94FXcr2P2NwpXt0xA9ghnpZffjVLy7F6qeygb5vv6Mequ0oeqb4WpP+v7Hw== X-Received: by 10.107.175.27 with SMTP id y27mr52111077ioe.137.1469830590332; Fri, 29 Jul 2016 15:16:30 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id e201sm2152444itc.21.2016.07.29.15.16.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 15:16:30 -0700 (PDT) Received: by mail-io0-f177.google.com with SMTP id b62so140912024iod.3; Fri, 29 Jul 2016 15:16:30 -0700 (PDT) X-Received: by 10.107.142.129 with SMTP id q123mr38715103iod.84.1469830589842; Fri, 29 Jul 2016 15:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.162.75 with HTTP; Fri, 29 Jul 2016 15:16:28 -0700 (PDT) In-Reply-To: References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> From: Svatopluk Kraus Date: Sat, 30 Jul 2016 00:16:28 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 23:16:27 -0000 Well, I'm online again, unfortanately, I'm quite busy, so just quick response for now to the formal ask for the reversion. On Fri, Jul 29, 2016 at 4:41 PM, Nathan Whitehorn wrote: > [snip] > > So here is where I am right now: > - The perceived advantage of the new API seems to be that the mapping > information (interrupt parent, etc.) ends up in a struct resource instead of > in a centralized mapping table It's more than that. The change has made INTRNG framework not dependent on OFW(FDT) stuff. So after next r301543, the framework is clean of all additions related to various buses. It was something I wanted to do before FreeBSD-11 release, once when adrian@ moved INTRNG to sys/kern. The framework is used by arm, arm64 and mips now, so from my point of view, it was quite important. The way how it was done is not perfect and may be changed in the future. However, it does not break anything, does not change old functionality, and only few bus drivers were modified slightly. It was also only way which I and Michal have agreed on considering current kernel code. > - Additionally, it gives you a better shot at having the PIC online before > the PIC's interrupts are parsed (which is not required, but nice). For me, it's just correct design. Please, not all world is about OFW. > - Beyond these aesthetic points, there are no concrete examples of new > functionality added by this API, aside from some minor implementation bugs > of the old one on ARM that are easily fixed. Please, don't use subjective attributes like "aesthetic". > - There are, conversely, a number of concrete cases where this new API would > not be able to do the right thing. Some of these can be worked around or > fixed with significant restructuring in the MI parts of the kernel. I have not looked yet at these concrete cases, but which MI parts of kernel do you think of? It may be supposed that some bus drivers would be modified, but not MI parts of kernel! > - If we have both, the interrupt handling code in the MI parts of the kernel > will bifurcate. This patch alone has added a bunch of #ifdef to > kern/subr_bus.c, a new file to kern/, and lots of #ifdef to dev/ofw. This is > going to be really hard to maintain if we need both. IMO, this point is bogus totally. The #ifdefs in kern/subr_bus.c were added just to be polite to not-INTRNG kernels. They can be removed. No one new file was added. Lots of #ifdef in dev/ofw were added because ofw_bus_map_intr() return value is not checked in ofw_bus_intr_to_rl(), so resource list entry is always added. They are there also to clearly manifest INTRNG needs. > > Is this all correct? > I don't think so. Further, considering the reversion, I don't think that it can be done simply now. I suppose that more files were changed afterwards when no bus header is polluted by the framework now. However, as I have already wrote, this part of INTRNG may be changed to serve well for everyone. On the other hand, IMO, a centralized global interrupt mapping table is not good design, and if established after all, it should not be a part of the framework. That said, I suggest to continue with work on INTRNG. Svata > If so, can we please back this out until this discussion is complete? I'm > asking this formally at this point, under the Committer's Guide section > about reversion requests. > -Nathan > > From owner-freebsd-arm@freebsd.org Sat Jul 30 01:35:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDAFABA7F92; Sat, 30 Jul 2016 01:35:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBAF412E5; Sat, 30 Jul 2016 01:35:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6U1ZUpP029127 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2016 18:35:31 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Svatopluk Kraus References: <201606051620.u55GKD5S066398@repo.freebsd.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> Cc: Michal Meloun , "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> Date: Fri, 29 Jul 2016 18:35:30 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaAqmOkWSG1yDcFr4npweYNEYuVMAL+kwkFbqCX8t7eFnj92NW0YBGQFI6dUiiaLP7nVCu76DwRvecJujjdvHtxAJTIl3ekOaE= X-Sonic-ID: C;6gmc5vVV5hGfPJtMTlz00w== M;1Kz65vVV5hGfPJtMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 01:35:41 -0000 On 07/29/16 15:16, Svatopluk Kraus wrote: > Well, I'm online again, unfortanately, I'm quite busy, so just quick > response for now to the formal ask for the reversion. > > On Fri, Jul 29, 2016 at 4:41 PM, Nathan Whitehorn > wrote: > [snip] > >> So here is where I am right now: >> - The perceived advantage of the new API seems to be that the mapping >> information (interrupt parent, etc.) ends up in a struct resource instead of >> in a centralized mapping table > It's more than that. The change has made INTRNG framework not > dependent on OFW(FDT) stuff. So after next r301543, the framework is > clean of all additions related to various buses. It was something I > wanted to do before FreeBSD-11 release, once when adrian@ moved INTRNG > to sys/kern. The framework is used by arm, arm64 and mips now, so from > my point of view, it was quite important. The way how it was done is > not perfect and may be changed in the future. However, it does not > break anything, does not change old functionality, and only few bus > drivers were modified slightly. It was also only way which I and > Michal have agreed on considering current kernel code. Except that the API cannot support all the existing things, so now we have two APIs to support for the lifetime of the 11.x branch. This needed extensive review from platform maintainers and from arch@, which it did not get. > >> - Additionally, it gives you a better shot at having the PIC online before >> the PIC's interrupts are parsed (which is not required, but nice). > For me, it's just correct design. Please, not all world is about OFW. Of course not! But it does affect OFW platforms, which worked fine before. I also disagree strongly about the "correct design" in this case. This API is fragile since it requires coordination between resource list enumeration and allocation and it provides fewer features than the old one (which was not OFW-only either). >> - Beyond these aesthetic points, there are no concrete examples of new >> functionality added by this API, aside from some minor implementation bugs >> of the old one on ARM that are easily fixed. > Please, don't use subjective attributes like "aesthetic". If the issues are not aesthetic, then what concrete, technical problems does this solve? > > >> - There are, conversely, a number of concrete cases where this new API would >> not be able to do the right thing. Some of these can be worked around or >> fixed with significant restructuring in the MI parts of the kernel. > I have not looked yet at these concrete cases, but which MI parts of > kernel do you think of? It may be supposed that some bus drivers would > be modified, but not MI parts of kernel! If you don't want a global IRQ lookup table, the PCI interrupt routing APIs need to change, for one thing. You would also need a partial delayed attach mechanism to handle bus bridges that themselves have interrupts (hot-plug bridges, for example) and might have interrupt controllers as children athat does not currently exist in newbus. > >> - If we have both, the interrupt handling code in the MI parts of the kernel >> will bifurcate. This patch alone has added a bunch of #ifdef to >> kern/subr_bus.c, a new file to kern/, and lots of #ifdef to dev/ofw. This is >> going to be really hard to maintain if we need both. > IMO, this point is bogus totally. The #ifdefs in kern/subr_bus.c were > added just to be polite to not-INTRNG kernels. They can be removed. No > one new file was added. Lots of #ifdef in dev/ofw were added because > ofw_bus_map_intr() return value is not checked in > ofw_bus_intr_to_rl(), so resource list entry is always added. They are > there also to clearly manifest INTRNG needs. #ifdef or not, there are now two unrelated mechanisms and code paths for dealing with device tree interrupts. One of them cannot possibly be used on PowerPC (this one) and so there will have to be two parallel code paths in perpetuity. >> Is this all correct? >> > I don't think so. Further, considering the reversion, I don't think > that it can be done simply now. I suppose that more files were changed > afterwards when no bus header is polluted by the framework now. > However, as I have already wrote, this part of INTRNG may be changed > to serve well for everyone. On the other hand, IMO, a centralized > global interrupt mapping table is not good design, and if established > after all, it should not be a part of the framework. That said, I > suggest to continue with work on INTRNG. It cannot be done simply because the code was checked in without review or warning during a code slush with a cryptic commit message and now we are stuck with it for 11.x. In HEAD, there are only a few commits based on this that seem to provide no functional changes, so I really don't think reverting would be that bad. My concerns here are technical and I will stop complaining about this instantly if: 1. Anyone can point me to a single concrete example of a problem solved by this API that could not be solved with the existing code. You spent time writing this code, so there must be such a case! 2. Anyone can tell me how to implement the cases in my email to arch and on the wiki at https://wiki.freebsd.org/Complicated_Interrupts using this API. These work perfectly fine with the normal newbus APIs but appear to break with this one. This affects me directly since I maintain, or try to maintain, the content of dev/ofw and a platform (PowerPC) that relies on this code. I'm happy to switch the interrupt architecture, but it needs to be at least as functional as the old code to do that. Ideally, it would also be *more* functional so that it wasn't just churn -- but I would be willing to do the work regardless. As it is, however, having this new API that seemingly can't be supported on one of our platforms imposes a significant burden on doing those things. That absolutely needs to be resolved before we can continue here. The normal procedure would be to revert, have a discussion, and then recommit. If you refuse to do that, or to have any meaningful discussion about the design of this patch, I am not sure what the path forward is. -Nathan > > Svata > > >> If so, can we please back this out until this discussion is complete? I'm >> asking this formally at this point, under the Committer's Guide section >> about reversion requests. >> -Nathan >> >> From owner-freebsd-arm@freebsd.org Sat Jul 30 06:55:11 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FC30BA9774; Sat, 30 Jul 2016 06:55:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4CB21AFB; Sat, 30 Jul 2016 06:55:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x235.google.com with SMTP id f6so208922225ith.1; Fri, 29 Jul 2016 23:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r3zXziOYd9pqy0GFrs1nO7oSeiuRS/Krdz943pVwbRo=; b=KqrV5gxuRWwARwUMLZiz3kLcaCSk30LU5dzZm4wo2Uqoie2e5cX5nrtZO4lpJ+piBh q3fLaheXESvmtWfKDb8/vgIYfe/8Idr+iOxOvMhhDKPpAy0VjCew6YbYs0o/datpam8r zqg57BvQL0QYOJoiWuvO6wOzSz1y2Nvgq0juQNsFcoK+QZNIcibpbWd8m85qiKlU77nD 7HYQy6Ouq12HpGUZPvCj+Lc676mXo5XnteteYciqK2TWG2gIe6f/gjr+drcDm7hhmXnB PxlqMS1DL6h1xBYlbXMkHWVU/yYg62ePXIoB41IUyliUut/vVubagPS8cvC6oVIT/dfb dd1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r3zXziOYd9pqy0GFrs1nO7oSeiuRS/Krdz943pVwbRo=; b=PXHBzFaBffAZiIcz5AMLVWSDnzI1fcm+cMXw9itKb4G1ltThoE5/1GLWjBUJquOJFM B1zxsQTAmLV/dgcaY0EOR/e+k6TcOjW24pPFtCkPwkViYf8mU8/FpfXLfNoQlLQ77fUK ikL7Qmafl/axsPEQWbdKWfnecFJuD04vuZREvNFmhlcUgku7kb1PHh5B+MsspSKfLYu0 NNnuRJ//8V1nKd/GbIpQkfudUt2wjYCABtd4tBuaGxMnfPaBrv25DgS6pLYwHMQY8/6F owFkipcSRRc9kSAzJmim3WuRPreq0BLPwo1Z7dgZYVM33pTApYiXw4zSMFKK0mB8Dke/ BmHw== X-Gm-Message-State: AEkoouum/9iVtMhobtoNNuwJsrSzcwlVl3FwfUD5/oXU9wco+xedaBS20Bci33q8kaFZS2JVR9ZF+MvDjQMwNQ== X-Received: by 10.36.101.195 with SMTP id u186mr45792625itb.80.1469861709935; Fri, 29 Jul 2016 23:55:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Fri, 29 Jul 2016 23:55:08 -0700 (PDT) In-Reply-To: References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> From: Adrian Chadd Date: Fri, 29 Jul 2016 23:55:08 -0700 Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Svatopluk Kraus Cc: Nathan Whitehorn , "freebsd-arm@freebsd.org" , Michal Meloun , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 06:55:11 -0000 On 29 July 2016 at 15:16, Svatopluk Kraus wrote: > Well, I'm online again, unfortanately, I'm quite busy, so just quick > response for now to the formal ask for the reversion. > > On Fri, Jul 29, 2016 at 4:41 PM, Nathan Whitehorn > wrote: >> > > [snip] > >> >> So here is where I am right now: >> - The perceived advantage of the new API seems to be that the mapping >> information (interrupt parent, etc.) ends up in a struct resource instead of >> in a centralized mapping table > > It's more than that. The change has made INTRNG framework not > dependent on OFW(FDT) stuff. So after next r301543, the framework is > clean of all additions related to various buses. It was something I > wanted to do before FreeBSD-11 release, once when adrian@ moved INTRNG > to sys/kern. The framework is used by arm, arm64 and mips now, so from > my point of view, it was quite important. The way how it was done is > not perfect and may be changed in the future. However, it does not > break anything, does not change old functionality, and only few bus > drivers were modified slightly. It was also only way which I and > Michal have agreed on considering current kernel code. > > >> - Additionally, it gives you a better shot at having the PIC online before >> the PIC's interrupts are parsed (which is not required, but nice). > > For me, it's just correct design. Please, not all world is about OFW. Hi, Right, but the world does include open firmware, and Nathan/Justin have a lot of experience over on the powerpc side with all the crazy variants on interrupt enumeration and handling there. I think you and Nathan are sort of on the same page, but sort of not on the same page, and Nathan is trying to ensure things don't become more complicated moving forward. I really do suggest this stuff get written down and thought about a little more, and not just in the context of the ARM style GIC/PIC+GPIO interrupt setups that people are writing code for. Don't get me wrong, I'm glad it's happening, but there are more consumers involved than just ARM. :) So, are you/Michal willing to describe some of the ARM interrupt/platform hilarity on his wiki page (https://wiki.freebsd.org/Complicated_Interrupts ) so everyone can be on the same page (heh!) ? Right now there's a lot of information floating around in emails but it's hard to pull out exactly what's going on unless you're knee deep in it all working on that platform. I'm trying to figure it out too for the MIPS + GPIO interrupt stuff that people are now doing with the QCA MIPS hardware and I'd like to make sure I know what's required for the QCA ARM (Dakota/IPQ8019) hardware. Thanks! -adrian -adrian From owner-freebsd-arm@freebsd.org Sat Jul 30 16:18:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1F45BA9F15; Sat, 30 Jul 2016 16:18:39 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 986EB1C7F; Sat, 30 Jul 2016 16:18:39 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 5239F3AC96; Sat, 30 Jul 2016 18:18:30 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <579CD355.1050203@FreeBSD.org> Date: Sat, 30 Jul 2016 18:18:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sat, 30 Jul 2016 18:18:30 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 16:18:40 -0000 Dne 29.07.2016 v 16:41 Nathan Whitehorn napsal(a): [snip] Svata is online now, so i think that he is more competent for responding to all questions about INTRNG internals. >>>> But, as you wrote, INTRNG code is "absolutely free to map and >>>> dispatch >>>> multiple virtual IRQs from the same shared interrupt pin" (allow me to >>>> expand this also to INTRNG code itself) . >>>> In attempt to simply situation abound cache, in first step, we >>>> removed >>>> duplicates check from above model. This also removes unpleasantly >>>> sharing of entries. >>>> This step converts cache to some sort of duplicate of resource list >>>> entries. Each existing RLE have exactly one corresponding entry in >>>> cache. >>>> Also, the cache is not needed for INTRNG core. At this point, its >>>> only >>>> transfers data from ofw_bus_intr_to_rl() to consumers PIC. >>>> >>>> So, if we are able to attach 'key' to RLE, then we can remove the >>>> whole >>>> cache machinery from INTRNG. >>>> Do you agree? >>> No. Because you have to support two things that this still can't allow: >>> 1. Devices attaching before their interrupt controllers. >> You still expect that data readed from OFW must be parsed at RLE >> creation time. I don't see single reason why we cannot postpone >> parsing to bus_alloc_resource() time. >> At this point, its irrelevant if bus_alloc_resource() supports >> detached PIC or not. > > Because there are *lots* of cases in the kernel where interrupts are > represented as a number and not a struct resource *. I've listed many > of them; I'm sure there are more. PCI is the most notable example > (both LSI and MSI). For both of these, the route_interrupt (LSI) and > alloc_msi[x]() (MSI) functions give the bus driver a chance to look at > the device tree and then they return an IRQ number. There doesn't seem > to be any way to map that back to a struct resource * or something > besides an internal table. > > Moreover, there are cases (self-added interrupts by children, for > instance) in which the RL assigned by the parent does not reflect the > final RL used by the child and there is no way for the parent bus to > map an RID to a device tree entry. > > When we moved to doing this at interrupt assignment time rather than > resource allocation time or another occasion on PowerPC, it was for > these kinds of reasons. There were ways to do it later, but they were > hugely invasive and involved changing large parts of the kernel. Even > then, it would still be fragile: Trying to guess what device tree > entry was meant at bus_alloc_resource() time is much more error-prone > than doing the mapping when reading that device tree to assign the > resources in the first place, when you can make guarantees. > >> >>> 2. Interrupts encoded entirely in a 32-bit integer rather than a >>> struct resource * in a shared rman. This is required to support PCI >>> (both LSI and MSI). >>> >>> #2 could of course be fixed by completely retooling the API of the PCI >>> bus code, but, since it fixes something that currently is not a >>> problem, why would we do that? >> All relevant bus functions have struct resource * as an argument. And, >> in post r301453 kernel, all necessary data are attached to it. >> I don't see any reason for API change. > > There is: > int PCIB_ROUTE_INTERRUPT(device_t, device_t, pin) > > Which takes a PIN (A, B, C, D) and returns the IRQ to add to the RL. > This is the only real opportunity to parse an interrupt-map and does > not deal with struct resource. > > There are also PCIB_ALLOC_MSI[X], which take a device_t and count and > return a vector of IRQ numbers. > > How would you do resource allocation given these APIs? There seem to > be some dubious-looking attempts at generic MSI mapping code in the > new kern/subr_intr.c that don't allow the specification of more than > 32-bit interrupt specifiers and otherwise exactly duplicate the > pre-301453 flow for MSIs, but in a more complicated and > less-functional way. > > (While investigating this, I also just found > dev/pci/pci_host_generic.c, which mostly does the wrong things, is > actually specific to a couple of ARM boards, and duplicates code in > dev/ofw/ofwpci.c. But that's another discussion...) [snip][2] >>>>>> Each OFW device has a lot of dependencies. It must enable clocks, >>>>>> power >>>>>> regulators..., it must be taken from reset. All these action must be >>>>>> done before we can access single register. >>>>>> Most of these action can be done only with attached >>>>>> clock/power/reset >>>>>> controller. >>>>>> Within this, interrupts are not special. >>>>> They are actually quite special in that the kernel enables them late >>>>> and so you can defer setup. They are also special in that, for that >>>>> reason, it is possible to design systems with circular dependency >>>>> graphs with interrupts. It is not possible to do this with, for >>>>> example, clocks: if I need to apply a clock to the clock controller >>>>> with itself, the system is just not bootable and such a system will >>>>> not be built or shipped. Interrupts need only happen later, after >>>>> device setup, and so such systems *are* designed and shipped. The >>>>> same >>>>> is true for power. >>>> The G5 problem is standard 'cross type' circular dependency. You >>>> must >>>> (at BUS_PASS_BUS) initialize memory address window of PCI bridge and >>>> start bus enumeration. >>>> Rest of PCI bridge initialization (including all IRQ stuff) must be >>>> postponed to any later pass. Of course, all interrupt controllers must >>>> be attached at BUS_PASS_INTERRUPT. >>>> Or I missed something? >>> Yes. As I said, you could solve it that way. It would, of course, >>> require a massive retooling of newbus (to allow partial delayed >>> attach), everything in dev/pci (which doesn't expect that), and >>> (almost) every PCI driver in and out of the tree. >> I still think that only host to PCI bridge must me modified, and PCI-PCI >> bridge must be run at BUS_PASS_BUS (which is single line modification). > > On Powermacs, one PIC is 5 levels deep in the bus hierarchy, under 3 > PCI<->PCI bridges and a device that also has an ATA controller and a > bunch of other things. Yes, I see. And, as a said before, it's pretty common situation in OFW based world. Imho, all whats is needed is: https://github.com/strejda/freebsd/commit/96ab64e04dcebb131643c2ae1cf373194d23e8e5 (of course, it's not tested, I havn't access to powermac HW) It's hard for me to understand why you say that this change requires "massive retooling of newbus, everything in dev/pci, every PCI driver). > Some of those can have their own interrupts (which is fairly common > for error reporting or PCI-E hotplug). It wouldn't be impossible, but > it is decidedly nontrivial. That's true. Any 'bus' driver, in multipass environment, *must* export provided resources, make bus accessible and enumerate it at 'BUS_PASS_BUS', and consume resources at some later bus pass. At this time, only pcie-hotplug needs this change. But I don't see why a few lines change is "decidedly nontrivial". > >>> Or: you could skip all of that and use the fully functional mechanism >>> that already exists. >> The problem is, at least from my point of view, that we don't have it. >> The actual MIPS code doesn't work on ARM for numerous reasons. This is >> first one -> >> >> https://svnweb.freebsd.org/base/head/sys/powerpc/powerpc/nexus.c?revision=297000&view=markup#l186 >> The pre-r301453 ARM INTRNG doesn't support detached interrupts. >> And r301453 doesn't changed nothing about this. > > I'm happy to write whatever code is missing. The ARM implementation of > ofw_bus_map_intr() does seem fairly braindead and should be replaced. > > So here is where I am right now: > - The perceived advantage of the new API seems to be that the mapping > information (interrupt parent, etc.) ends up in a struct resource > instead of in a centralized mapping table True. And, in optimal case, also in RLE. See [1]. > - Additionally, it gives you a better shot at having the PIC online > before the PIC's interrupts are parsed (which is not required, but nice). Nope, we simply fount that detached pics is very dangerous and not needed. But, if you love it, it can be added as MD extension. > - Beyond these aesthetic points, there are no concrete examples of new > functionality added by this API, aside from some minor implementation > bugs of the old one on ARM that are easily fixed. Really? Or you just ignore it? > - There are, conversely, a number of concrete cases where this new API > would not be able to do the right thing. Some of these can be worked > around or fixed with significant restructuring in the MI parts of the > kernel. And i offer you a fix, without "significant restructuring in the MI parts of the kernel". Unfortunately, you did not want to accept anything other than the old API. > - If we have both, the interrupt handling code in the MI parts of the > kernel will bifurcate. This patch alone has added a bunch of #ifdef to > kern/subr_bus.c, a new file to kern/, and lots of #ifdef to dev/ofw. > This is going to be really hard to maintain if we need both. All those #ifdefs has been added as safeguards for 11/stable and they can be removed immediately. Michal > > Is this all correct? > > If so, can we please back this out until this discussion is complete? > I'm asking this formally at this point, under the Committer's Guide > section about reversion requests. > -Nathan From owner-freebsd-arm@freebsd.org Sat Jul 30 16:59:08 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B6B3BA7742; Sat, 30 Jul 2016 16:59:08 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DDE1A1C93; Sat, 30 Jul 2016 16:59:07 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6UGx3oR010291 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Jul 2016 09:59:04 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Michal Meloun References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> Date: Sat, 30 Jul 2016 09:59:03 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <579CD355.1050203@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaNqEs/52CO7aYgImcJHsbGiejG9webnZt5xuzaFk3Rwp/vCJz2LezyE6wTS70TfhPAxexIhmzT7osYDdWf6sHyaZn3t6uv+14= X-Sonic-ID: C;pslJ63ZW5hG/eKDx2xNB0g== M;rIOY63ZW5hG/eKDx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 16:59:08 -0000 On 07/30/16 09:18, Michal Meloun wrote: > Dne 29.07.2016 v 16:41 Nathan Whitehorn napsal(a): > [snip] > Svata is online now, so i think that he is more competent for responding > to all questions about INTRNG internals. > > >>>>> But, as you wrote, INTRNG code is "absolutely free to map and >>>>> dispatch >>>>> multiple virtual IRQs from the same shared interrupt pin" (allow me to >>>>> expand this also to INTRNG code itself) . >>>>> In attempt to simply situation abound cache, in first step, we >>>>> removed >>>>> duplicates check from above model. This also removes unpleasantly >>>>> sharing of entries. >>>>> This step converts cache to some sort of duplicate of resource list >>>>> entries. Each existing RLE have exactly one corresponding entry in >>>>> cache. >>>>> Also, the cache is not needed for INTRNG core. At this point, its >>>>> only >>>>> transfers data from ofw_bus_intr_to_rl() to consumers PIC. >>>>> >>>>> So, if we are able to attach 'key' to RLE, then we can remove the >>>>> whole >>>>> cache machinery from INTRNG. >>>>> Do you agree? >>>> No. Because you have to support two things that this still can't allow: >>>> 1. Devices attaching before their interrupt controllers. >>> You still expect that data readed from OFW must be parsed at RLE >>> creation time. I don't see single reason why we cannot postpone >>> parsing to bus_alloc_resource() time. >>> At this point, its irrelevant if bus_alloc_resource() supports >>> detached PIC or not. >> Because there are *lots* of cases in the kernel where interrupts are >> represented as a number and not a struct resource *. I've listed many >> of them; I'm sure there are more. PCI is the most notable example >> (both LSI and MSI). For both of these, the route_interrupt (LSI) and >> alloc_msi[x]() (MSI) functions give the bus driver a chance to look at >> the device tree and then they return an IRQ number. There doesn't seem >> to be any way to map that back to a struct resource * or something >> besides an internal table. >> >> Moreover, there are cases (self-added interrupts by children, for >> instance) in which the RL assigned by the parent does not reflect the >> final RL used by the child and there is no way for the parent bus to >> map an RID to a device tree entry. >> >> When we moved to doing this at interrupt assignment time rather than >> resource allocation time or another occasion on PowerPC, it was for >> these kinds of reasons. There were ways to do it later, but they were >> hugely invasive and involved changing large parts of the kernel. Even >> then, it would still be fragile: Trying to guess what device tree >> entry was meant at bus_alloc_resource() time is much more error-prone >> than doing the mapping when reading that device tree to assign the >> resources in the first place, when you can make guarantees. >> >>>> 2. Interrupts encoded entirely in a 32-bit integer rather than a >>>> struct resource * in a shared rman. This is required to support PCI >>>> (both LSI and MSI). >>>> >>>> #2 could of course be fixed by completely retooling the API of the PCI >>>> bus code, but, since it fixes something that currently is not a >>>> problem, why would we do that? >>> All relevant bus functions have struct resource * as an argument. And, >>> in post r301453 kernel, all necessary data are attached to it. >>> I don't see any reason for API change. >> There is: >> int PCIB_ROUTE_INTERRUPT(device_t, device_t, pin) >> >> Which takes a PIN (A, B, C, D) and returns the IRQ to add to the RL. >> This is the only real opportunity to parse an interrupt-map and does >> not deal with struct resource. >> >> There are also PCIB_ALLOC_MSI[X], which take a device_t and count and >> return a vector of IRQ numbers. >> >> How would you do resource allocation given these APIs? There seem to >> be some dubious-looking attempts at generic MSI mapping code in the >> new kern/subr_intr.c that don't allow the specification of more than >> 32-bit interrupt specifiers and otherwise exactly duplicate the >> pre-301453 flow for MSIs, but in a more complicated and >> less-functional way. >> >> (While investigating this, I also just found >> dev/pci/pci_host_generic.c, which mostly does the wrong things, is >> actually specific to a couple of ARM boards, and duplicates code in >> dev/ofw/ofwpci.c. But that's another discussion...) > [snip][2] >>>>>>> Each OFW device has a lot of dependencies. It must enable clocks, >>>>>>> power >>>>>>> regulators..., it must be taken from reset. All these action must be >>>>>>> done before we can access single register. >>>>>>> Most of these action can be done only with attached >>>>>>> clock/power/reset >>>>>>> controller. >>>>>>> Within this, interrupts are not special. >>>>>> They are actually quite special in that the kernel enables them late >>>>>> and so you can defer setup. They are also special in that, for that >>>>>> reason, it is possible to design systems with circular dependency >>>>>> graphs with interrupts. It is not possible to do this with, for >>>>>> example, clocks: if I need to apply a clock to the clock controller >>>>>> with itself, the system is just not bootable and such a system will >>>>>> not be built or shipped. Interrupts need only happen later, after >>>>>> device setup, and so such systems *are* designed and shipped. The >>>>>> same >>>>>> is true for power. >>>>> The G5 problem is standard 'cross type' circular dependency. You >>>>> must >>>>> (at BUS_PASS_BUS) initialize memory address window of PCI bridge and >>>>> start bus enumeration. >>>>> Rest of PCI bridge initialization (including all IRQ stuff) must be >>>>> postponed to any later pass. Of course, all interrupt controllers must >>>>> be attached at BUS_PASS_INTERRUPT. >>>>> Or I missed something? >>>> Yes. As I said, you could solve it that way. It would, of course, >>>> require a massive retooling of newbus (to allow partial delayed >>>> attach), everything in dev/pci (which doesn't expect that), and >>>> (almost) every PCI driver in and out of the tree. >>> I still think that only host to PCI bridge must me modified, and PCI-PCI >>> bridge must be run at BUS_PASS_BUS (which is single line modification). >> On Powermacs, one PIC is 5 levels deep in the bus hierarchy, under 3 >> PCI<->PCI bridges and a device that also has an ATA controller and a >> bunch of other things. > Yes, I see. And, as a said before, it's pretty common situation in OFW > based world. > Imho, all whats is needed is: > https://github.com/strejda/freebsd/commit/96ab64e04dcebb131643c2ae1cf373194d23e8e5 > (of course, it's not tested, I havn't access to powermac HW) That would probably work on at least some of the hardware. Some of those parents can have their own interrupts, however, which would break. I'll investigate how often this happens. > It's hard for me to understand why you say that this change requires > "massive retooling of newbus, everything in dev/pci, every PCI driver). > >> Some of those can have their own interrupts (which is fairly common >> for error reporting or PCI-E hotplug). It wouldn't be impossible, but >> it is decidedly nontrivial. > That's true. Any 'bus' driver, in multipass environment, *must* export > provided resources, make bus accessible and enumerate it at > 'BUS_PASS_BUS', and > consume resources at some later bus pass. > At this time, only pcie-hotplug needs this change. But I don't see why > a few lines change is "decidedly nontrivial". It's not just a few lines change. Newbus provides no mechanism for a bus to attach at two different bus passes. >>>> Or: you could skip all of that and use the fully functional mechanism >>>> that already exists. >>> The problem is, at least from my point of view, that we don't have it. >>> The actual MIPS code doesn't work on ARM for numerous reasons. This is >>> first one -> >>> >>> https://svnweb.freebsd.org/base/head/sys/powerpc/powerpc/nexus.c?revision=297000&view=markup#l186 >>> The pre-r301453 ARM INTRNG doesn't support detached interrupts. >>> And r301453 doesn't changed nothing about this. >> I'm happy to write whatever code is missing. The ARM implementation of >> ofw_bus_map_intr() does seem fairly braindead and should be replaced. >> >> So here is where I am right now: >> - The perceived advantage of the new API seems to be that the mapping >> information (interrupt parent, etc.) ends up in a struct resource >> instead of in a centralized mapping table > True. And, in optimal case, also in RLE. See [1]. Your code also has a centralized table (static struct intr_irqsrc *irq_sources[NIRQ];), basically the same one, so I'm actually really confused on this point. The only actual difference seems to be that the firmware interrupt descriptor is stored in the RLE at bus_alloc_resource() time instead of in the table at bus enumeration time and that the new code requires some extra bus methods. >> - Additionally, it gives you a better shot at having the PIC online >> before the PIC's interrupts are parsed (which is not required, but nice). > Nope, we simply fount that detached pics is very dangerous and not > needed. But, if you love it, it can be added as MD extension. Dangerous how? I don't "love it"; it's an unfortunate necessity. >> - Beyond these aesthetic points, there are no concrete examples of new >> functionality added by this API, aside from some minor implementation >> bugs of the old one on ARM that are easily fixed. > Really? Or you just ignore it? Which ones? I've been asking for a week and a half now and you have responded with some hypothetical examples, all of which either (a) do not seem to occur in the real world and (b) were trivially implementable with the existing code. > >> - There are, conversely, a number of concrete cases where this new API >> would not be able to do the right thing. Some of these can be worked >> around or fixed with significant restructuring in the MI parts of the >> kernel. > And i offer you a fix, without "significant restructuring in the MI > parts of the kernel". Unfortunately, you did not want to accept anything > other than the old API. For one of them, partially. For the others, not so much. For example, I have no idea how to implement PCI interrupts (PCIB_ROUTE_INTERRUPT) in this framework. I am perfectly happy to accept a new API. What I am not perfectly happy to accept is an API that makes it impossible for me to support the platforms that I need to support and that, simultaneously, doesn't even provide any new capabilities on other platforms. The current API is certainly a bit of a hack and I would be pleased to see it go; but the replacement needs to be more functional and more robust. As far as I can tell, I literally *cannot* move PowerPC over to this architecture. The ideal API would be one in which the resource enumeration code could assign, instead of numbers, some structured information that contains the full firmware specifier (string parent + interrupt pin for ACPI, interrupt parent phandle + specifier for device tree, bare numbers for simple systems). That seemed, and seems, too invasive. I think we agree on this and have chosen to approximate that API in two different ways. When we designed the interrupt mapping code, we evaluated a large number of possible approaches. Something very much like this was one of them. It was rejected as being too fragile (it requires resource allocation and enumeration to be coupled) and to have too many corner cases (the PCI MSI and LSI APIs, for instance). The interrupt mapping stuff seemed at the time, and so far still seems, like the least-bad approximation to the ideal case: it is essentially that ideal API, in that it happens at bus enumeration and involves just assigning the firmware specifiers, but with lookup keys to that information stuffed into the 32-bit numbers that the rest of the system uses. >> - If we have both, the interrupt handling code in the MI parts of the >> kernel will bifurcate. This patch alone has added a bunch of #ifdef to >> kern/subr_bus.c, a new file to kern/, and lots of #ifdef to dev/ofw. >> This is going to be really hard to maintain if we need both. > All those #ifdefs has been added as safeguards for 11/stable and they > can be removed immediately. They should not be and I will request immediate reversion and appeal to core@ if they are before this discussion is complete. -Nathan > Michal > >> Is this all correct? >> >> If so, can we please back this out until this discussion is complete? >> I'm asking this formally at this point, under the Committer's Guide >> section about reversion requests. >> -Nathan > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sat Jul 30 18:06:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A04AABA894F for ; Sat, 30 Jul 2016 18:06:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60B8D1B17 for ; Sat, 30 Jul 2016 18:06:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id u186so216530733ita.0 for ; Sat, 30 Jul 2016 11:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DNE2xl5AL68CunojHSXzb7aIZvbRL9t61wTxvWudrF8=; b=vwTez8euEf9PneaDNPkBk28NZMYCS1BMgUAeEV+cnS7b0zIaGjtLyVdDN39f3AUyEf 2MGq8Vi5Vey/DpYZWPTTpVGC/jWa+43lcf5TJzl/SOlcP/Q9rAPERLsfUmOAfVjWMYPb FNFcNZSrau5dR/CRKIG0TP33ypfgdlzpaYgxHAjwb7Tz954IgD89w4fT8YGijrehKLX9 nVY8GsFRR9Ch3lVyt2CzHjAamkjyzaz4SBOY7gyPGh/fcCj1V0be4RLaOLQDOKRUX5Br SqudUPv85NFnmH9LxQld0Cj1FxL8pdZ4sUlKB7xRBjVaC+pqU34fnP3qo4eAsTyfPkp+ 6G2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DNE2xl5AL68CunojHSXzb7aIZvbRL9t61wTxvWudrF8=; b=i2VWxH3U2RXS2Q9zK8eFjZQLburgwPwcLR4VtzhxM4fF6ux08JGsOhlkWNs7LpW8Q2 PAiCCbO0A2NoyabOQCtEqZfNoVC4K9nsm7FvTRCliKherBsvyMHodBhKD0WB1uY5moaZ VxF9io4aF2FUaopXNsVm9DkQLgGnP7k6oA5IzSj+psU8WEwq7zLy5wDv6zPwFWdX8DXR Br0e7MMl8WBQeZJ3HxQLJmThW+QkDh/ueU+lInAMQLfB9mLeq7iMv7A03veCWUqHONtU 3rcWeDeUxG1neTVG1M133ys/UX0zx2UnEepsrUKp9eWnaWGBiiu/SEC7gHirb3xy1R9m ssJw== X-Gm-Message-State: AEkoouvWTZQpnqCZIKOADRO+7NurRBFgRT80U7UJcRAooyVmbWxcpgLoZdvuZGlpzof6P+Odqj6Bmwa0vDoDuQ== X-Received: by 10.36.16.138 with SMTP id 132mr7311518ity.60.1469901991766; Sat, 30 Jul 2016 11:06:31 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Sat, 30 Jul 2016 11:06:30 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> From: Warner Losh Date: Sat, 30 Jul 2016 12:06:30 -0600 X-Google-Sender-Auth: blMql6EKvNas1ndlZIGB-cpG4_0 Message-ID: Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn Cc: Michal Meloun , "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 18:06:32 -0000 On Sat, Jul 30, 2016 at 10:59 AM, Nathan Whitehorn wrote: > It's not just a few lines change. Newbus provides no mechanism for a bus to > attach at two different bus passes. Sure it does. That's used in the Atmel code (which might not be in the tree) for some things. Newbus lets you know for each new pass that something is happening. Perhaps you could be clearer as to what exactly it doesn't provide. Warner From owner-freebsd-arm@freebsd.org Sat Jul 30 18:54:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0F47BA92C3; Sat, 30 Jul 2016 18:54:04 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 57B721CB1; Sat, 30 Jul 2016 18:54:04 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 135D43AC9C; Sat, 30 Jul 2016 20:54:01 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <579CF7C8.1040302@FreeBSD.org> Date: Sat, 30 Jul 2016 20:54:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sat, 30 Jul 2016 20:54:01 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 18:54:04 -0000 Dne 30.07.2016 v 18:59 Nathan Whitehorn napsal(a): > > > On 07/30/16 09:18, Michal Meloun wrote: >> Dne 29.07.2016 v 16:41 Nathan Whitehorn napsal(a): >> [snip] >> Svata is online now, so i think that he is more competent for responding >> to all questions about INTRNG internals. >> >> >>>>>> But, as you wrote, INTRNG code is "absolutely free to map and >>>>>> dispatch >>>>>> multiple virtual IRQs from the same shared interrupt pin" (allow >>>>>> me to >>>>>> expand this also to INTRNG code itself) . >>>>>> In attempt to simply situation abound cache, in first step, we >>>>>> removed >>>>>> duplicates check from above model. This also removes unpleasantly >>>>>> sharing of entries. >>>>>> This step converts cache to some sort of duplicate of resource list >>>>>> entries. Each existing RLE have exactly one corresponding entry in >>>>>> cache. >>>>>> Also, the cache is not needed for INTRNG core. At this point, its >>>>>> only >>>>>> transfers data from ofw_bus_intr_to_rl() to consumers PIC. >>>>>> >>>>>> So, if we are able to attach 'key' to RLE, then we can remove the >>>>>> whole >>>>>> cache machinery from INTRNG. >>>>>> Do you agree? >>>>> No. Because you have to support two things that this still can't >>>>> allow: >>>>> 1. Devices attaching before their interrupt controllers. >>>> You still expect that data readed from OFW must be parsed at RLE >>>> creation time. I don't see single reason why we cannot postpone >>>> parsing to bus_alloc_resource() time. >>>> At this point, its irrelevant if bus_alloc_resource() supports >>>> detached PIC or not. >>> Because there are *lots* of cases in the kernel where interrupts are >>> represented as a number and not a struct resource *. I've listed many >>> of them; I'm sure there are more. PCI is the most notable example >>> (both LSI and MSI). For both of these, the route_interrupt (LSI) and >>> alloc_msi[x]() (MSI) functions give the bus driver a chance to look at >>> the device tree and then they return an IRQ number. There doesn't seem >>> to be any way to map that back to a struct resource * or something >>> besides an internal table. >>> >>> Moreover, there are cases (self-added interrupts by children, for >>> instance) in which the RL assigned by the parent does not reflect the >>> final RL used by the child and there is no way for the parent bus to >>> map an RID to a device tree entry. >>> >>> When we moved to doing this at interrupt assignment time rather than >>> resource allocation time or another occasion on PowerPC, it was for >>> these kinds of reasons. There were ways to do it later, but they were >>> hugely invasive and involved changing large parts of the kernel. Even >>> then, it would still be fragile: Trying to guess what device tree >>> entry was meant at bus_alloc_resource() time is much more error-prone >>> than doing the mapping when reading that device tree to assign the >>> resources in the first place, when you can make guarantees. >>> >>>>> 2. Interrupts encoded entirely in a 32-bit integer rather than a >>>>> struct resource * in a shared rman. This is required to support PCI >>>>> (both LSI and MSI). >>>>> >>>>> #2 could of course be fixed by completely retooling the API of the >>>>> PCI >>>>> bus code, but, since it fixes something that currently is not a >>>>> problem, why would we do that? >>>> All relevant bus functions have struct resource * as an argument. And, >>>> in post r301453 kernel, all necessary data are attached to it. >>>> I don't see any reason for API change. >>> There is: >>> int PCIB_ROUTE_INTERRUPT(device_t, device_t, pin) >>> >>> Which takes a PIN (A, B, C, D) and returns the IRQ to add to the RL. >>> This is the only real opportunity to parse an interrupt-map and does >>> not deal with struct resource. >>> >>> There are also PCIB_ALLOC_MSI[X], which take a device_t and count and >>> return a vector of IRQ numbers. >>> >>> How would you do resource allocation given these APIs? There seem to >>> be some dubious-looking attempts at generic MSI mapping code in the >>> new kern/subr_intr.c that don't allow the specification of more than >>> 32-bit interrupt specifiers and otherwise exactly duplicate the >>> pre-301453 flow for MSIs, but in a more complicated and >>> less-functional way. >>> >>> (While investigating this, I also just found >>> dev/pci/pci_host_generic.c, which mostly does the wrong things, is >>> actually specific to a couple of ARM boards, and duplicates code in >>> dev/ofw/ofwpci.c. But that's another discussion...) >> [snip][2] >>>>>>>> Each OFW device has a lot of dependencies. It must enable clocks, >>>>>>>> power >>>>>>>> regulators..., it must be taken from reset. All these action >>>>>>>> must be >>>>>>>> done before we can access single register. >>>>>>>> Most of these action can be done only with attached >>>>>>>> clock/power/reset >>>>>>>> controller. >>>>>>>> Within this, interrupts are not special. >>>>>>> They are actually quite special in that the kernel enables them >>>>>>> late >>>>>>> and so you can defer setup. They are also special in that, for that >>>>>>> reason, it is possible to design systems with circular dependency >>>>>>> graphs with interrupts. It is not possible to do this with, for >>>>>>> example, clocks: if I need to apply a clock to the clock controller >>>>>>> with itself, the system is just not bootable and such a system will >>>>>>> not be built or shipped. Interrupts need only happen later, after >>>>>>> device setup, and so such systems *are* designed and shipped. The >>>>>>> same >>>>>>> is true for power. >>>>>> The G5 problem is standard 'cross type' circular dependency. You >>>>>> must >>>>>> (at BUS_PASS_BUS) initialize memory address window of PCI bridge >>>>>> and >>>>>> start bus enumeration. >>>>>> Rest of PCI bridge initialization (including all IRQ stuff) must be >>>>>> postponed to any later pass. Of course, all interrupt controllers >>>>>> must >>>>>> be attached at BUS_PASS_INTERRUPT. >>>>>> Or I missed something? >>>>> Yes. As I said, you could solve it that way. It would, of course, >>>>> require a massive retooling of newbus (to allow partial delayed >>>>> attach), everything in dev/pci (which doesn't expect that), and >>>>> (almost) every PCI driver in and out of the tree. >>>> I still think that only host to PCI bridge must me modified, and >>>> PCI-PCI >>>> bridge must be run at BUS_PASS_BUS (which is single line >>>> modification). >>> On Powermacs, one PIC is 5 levels deep in the bus hierarchy, under 3 >>> PCI<->PCI bridges and a device that also has an ATA controller and a >>> bunch of other things. >> Yes, I see. And, as a said before, it's pretty common situation in OFW >> based world. >> Imho, all whats is needed is: >> https://github.com/strejda/freebsd/commit/96ab64e04dcebb131643c2ae1cf373194d23e8e5 >> >> (of course, it's not tested, I havn't access to powermac HW) > > That would probably work on at least some of the hardware. Some of > those parents can have their own interrupts, however, which would > break. I'll investigate how often this happens. > >> It's hard for me to understand why you say that this change requires >> "massive retooling of newbus, everything in dev/pci, every PCI >> driver). >> >>> Some of those can have their own interrupts (which is fairly common >>> for error reporting or PCI-E hotplug). It wouldn't be impossible, but >>> it is decidedly nontrivial. >> That's true. Any 'bus' driver, in multipass environment, *must* export >> provided resources, make bus accessible and enumerate it at >> 'BUS_PASS_BUS', and >> consume resources at some later bus pass. >> At this time, only pcie-hotplug needs this change. But I don't see why >> a few lines change is "decidedly nontrivial". > > It's not just a few lines change. Newbus provides no mechanism for a > bus to attach at two different bus passes. ?? Please see: https://github.com/strejda/tegra/blob/master/sys/arm/nvidia/drm2/tegra_host1x.c#L639 and https://github.com/strejda/tegra/blob/master/sys/arm/nvidia/drm2/tegra_host1x.c#L451 > >>>>> Or: you could skip all of that and use the fully functional mechanism >>>>> that already exists. >>>> The problem is, at least from my point of view, that we don't have it. >>>> The actual MIPS code doesn't work on ARM for numerous reasons. >>>> This is >>>> first one -> >>>> >>>> https://svnweb.freebsd.org/base/head/sys/powerpc/powerpc/nexus.c?revision=297000&view=markup#l186 >>>> The pre-r301453 ARM INTRNG doesn't support detached interrupts. >>>> And r301453 doesn't changed nothing about this. >>> I'm happy to write whatever code is missing. The ARM implementation of >>> ofw_bus_map_intr() does seem fairly braindead and should be replaced. >>> >>> So here is where I am right now: >>> - The perceived advantage of the new API seems to be that the mapping >>> information (interrupt parent, etc.) ends up in a struct resource >>> instead of in a centralized mapping table >> True. And, in optimal case, also in RLE. See [1]. > > Your code also has a centralized table (static struct intr_irqsrc > *irq_sources[NIRQ];), basically the same one, so I'm actually really > confused on this point. The only actual difference seems to be that > the firmware interrupt descriptor is stored in the RLE at > bus_alloc_resource() time instead of in the table at bus enumeration > time and that the new code requires some extra bus methods. The irq_sources holds only real interrupts (all interrupts pin from all interrupts controllers). Your effort is move all 'interrupt description data' out of INTRNG code - to RLE (at bus enumeration time) (see [1]) and to struct resource (at bus_alloc_resource() time). The new bus method is only temporary shortcut to bypass 11 release. But, to be fair, I was hoping it might be necessary. [1] This is last missing step in whole patch series and, in optimal case, it need new filed(s) in RLE structure. So we chose to postpone discussion about this to time after 11 release. > >>> - Additionally, it gives you a better shot at having the PIC online >>> before the PIC's interrupts are parsed (which is not required, but >>> nice). >> Nope, we simply fount that detached pics is very dangerous and not >> needed. But, if you love it, it can be added as MD extension. > > Dangerous how? I don't "love it"; it's an unfortunate necessity. Imho, some drivers may rely on correct return code from bus_alloc_resource() or from bus_setup_intr(). For example to detect if interrupt exist, or if given interrupt configuration is supported. > >>> - Beyond these aesthetic points, there are no concrete examples of new >>> functionality added by this API, aside from some minor implementation >>> bugs of the old one on ARM that are easily fixed. >> Really? Or you just ignore it? > > Which ones? I've been asking for a week and a half now and you have > responded with some hypothetical examples, all of which either (a) do > not seem to occur in the real world and (b) were trivially > implementable with the existing code. > >> >>> - There are, conversely, a number of concrete cases where this new API >>> would not be able to do the right thing. Some of these can be worked >>> around or fixed with significant restructuring in the MI parts of the >>> kernel. >> And i offer you a fix, without "significant restructuring in the MI >> parts of the kernel". Unfortunately, you did not want to accept anything >> other than the old API. > > For one of them, partially. For the others, not so much. For example, > I have no idea how to implement PCI interrupts (PCIB_ROUTE_INTERRUPT) > in this framework. I am perfectly happy to accept a new API. What I am > not perfectly happy to accept is an API that makes it impossible for > me to support the platforms that I need to support and that, > simultaneously, doesn't even provide any new capabilities on other > platforms. >From one of previous mail: But again, all what I want in this area is (for me) simple change of your ofw_bus_map_intr() method to something like: enum intr_map_data_type { INTR_MAP_DATA_OFW, INTR_MAP_DATA_GPIO, ... }; int bus_map_intr(device_t dev, enum intr_map_data_type type, uintptr_t pic_id, void *config_data, int config_size) > The current API is certainly a bit of a hack and I would be pleased to > see it go; but the replacement needs to be more functional and more > robust. As far as I can tell, I literally *cannot* move PowerPC over > to this architecture. Yes, at this time, I agree. If you can accept enhancement of (owf_)bus_map_intr() then we can move to next, significantly less hackish, state. > The ideal API would be one in which the resource enumeration code > could assign, instead of numbers, some structured information that > contains the full firmware specifier (string parent + interrupt pin > for ACPI, interrupt parent phandle + specifier for device tree, bare > numbers for simple systems). Yes, exactly. I am happy that at least we agree on something. The only difference is that we want triplet or > That seemed, and seems, too invasive. I think we agree on this and > have chosen to approximate that API in two different ways. I still think that we found way how we can realize the above idea in non-invasive way. >From my point of view the solution is: Put/attach the above triplet to RLE and then copy it (within bus_resource_attach() to struct resource. But yes, I understand that I am not able to explain clearly enough. > > When we designed the interrupt mapping code, we evaluated a large > number of possible approaches. Something very much like this was one > of them. It was rejected as being too fragile (it requires resource > allocation and enumeration to be coupled) and to have too many corner > cases (the PCI MSI and LSI APIs, for instance). The interrupt mapping > stuff seemed at the time, and so far still seems, like the least-bad > approximation to the ideal case: it is essentially that ideal API, in > that it happens at bus enumeration and involves just assigning the > firmware specifiers, but with lookup keys to that information stuffed > into the 32-bit numbers that the rest of the system uses. The raw PCI (or MSIX) case is relatively simple. The PCI domain uses raw numbers and it's host-to-pci bridge job to translate raw numbers from PCI domain to (for example) OFW based resource. At this point, I'm still not sure about MSI... Michal >>> - If we have both, the interrupt handling code in the MI parts of the >>> kernel will bifurcate. This patch alone has added a bunch of #ifdef to >>> kern/subr_bus.c, a new file to kern/, and lots of #ifdef to dev/ofw. >>> This is going to be really hard to maintain if we need both. >> All those #ifdefs has been added as safeguards for 11/stable and they >> can be removed immediately. > > They should not be and I will request immediate reversion and appeal > to core@ if they are before this discussion is complete. > -Nathan > >> Michal >> >>> Is this all correct? >>> >>> If so, can we please back this out until this discussion is complete? >>> I'm asking this formally at this point, under the Committer's Guide >>> section about reversion requests. >>> -Nathan >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Jul 30 19:26:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 156C9BA9D49; Sat, 30 Jul 2016 19:26:12 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D05931F2C; Sat, 30 Jul 2016 19:26:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6UJQ2dD027948 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Jul 2016 12:26:03 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Warner Losh References: <201606051620.u55GKD5S066398@repo.freebsd.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> Cc: Michal Meloun , "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <3d17565e-8831-295a-46be-6341e17a8e6b@freebsd.org> Date: Sat, 30 Jul 2016 12:26:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYLmf2grmlq2PiNmyOV9dAUyln7hd83lNxrQFynRaMakcpYmtQWfOwdzhKNaSQU5jywvaBcpbGFBrUqEoRrRvx8qtoqPTc3IGA= X-Sonic-ID: C;5DEQdItW5hG6eq/hcgQksw== M;mthndItW5hG6eq/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 19:26:12 -0000 On 07/30/16 11:06, Warner Losh wrote: > On Sat, Jul 30, 2016 at 10:59 AM, Nathan Whitehorn > wrote: >> It's not just a few lines change. Newbus provides no mechanism for a bus to >> attach at two different bus passes. > Sure it does. That's used in the Atmel code (which might not be in the tree) for > some things. Newbus lets you know for each new pass that something is happening. > > Perhaps you could be clearer as to what exactly it doesn't provide. > > Warner > interesting. I hadn't realized that. We'd need to find all the bus drivers in the tree and make them attach this way, I guess. There are still some ordering dilemmas here coming from the static nature of the ordering. For example, if you have two PICs supported by the same driver, one of which is attached to the other, how do you order their attachments? I have a whole list of these at https://wiki.freebsd.org/Complicated_Interrupts. The list is basically the full set of weird cases we support with the current code. It would be great to get some responses to how you would implement those specific things with this new API. As usual, there are two things I would like to see: 1. A case of something that wasn't supported by the old API, but is supported by the new API. 2. How I would support all of the complicated cases the existing code supports, listed on the wiki, with the new API. -Nathan From owner-freebsd-arm@freebsd.org Sat Jul 30 23:39:49 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7E60BA9563 for ; Sat, 30 Jul 2016 23:39:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-169.reflexion.net [208.70.211.169]) (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 7F9A71F41 for ; Sat, 30 Jul 2016 23:39:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23601 invoked from network); 30 Jul 2016 23:39:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Jul 2016 23:39:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.6) with SMTP; Sat, 30 Jul 2016 19:39:47 -0400 (EDT) Received: (qmail 7012 invoked from network); 30 Jul 2016 23:39:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jul 2016 23:39:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 8EAED1C4392; Sat, 30 Jul 2016 16:39:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: BETA3 new message on rpi2 boot (just one boot?): dhclient[836]: send_packet: No buffer space available Message-Id: <15DC680E-7CED-4522-930B-EABF2C7EFA72@dsl-only.net> Date: Sat, 30 Jul 2016 16:39:40 -0700 To: freebsd-stable@freebsd.org, freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 23:39:49 -0000 [This appears to be something that does not repeat (often?) but I = figured I'd mention it.] I've not seen this send_packet report before the first BETA3 boot: > # dmesg -a | tail > Configuring vt: blanktime. > Performing sanity check on sshd configuration. > Starting sshd. > Starting cron. > Starting background file system checks in 60 seconds. > =20 > Sat Jul 30 16:14:32 PDT 2016 > wlan0: link state changed to UP > Jul 30 16:14:35 rpi2 dhclient[836]: send_packet: No buffer space = available > Jul 30 16:15:08 rpi2 login: ROOT LOGIN (root) ON ttyu0 Trying shutdown -r now again to see if it repeated shows that it did = not. So far I do not see later problems in the first or later boots. Context: > # uname -apKU > FreeBSD rpi2 11.0-BETA3 FreeBSD 11.0-BETA3 #2 r303469M: Fri Jul 29 = 19:09:12 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm=20= > armv6 1100120 1100120 FYI: > ue0: link state changed to DOWN > ue0: link state changed to UP > Starting Network: lo0 ue0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128=20 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 > inet 127.0.0.1 netmask 0xff000000=20 > groups: lo=20 > nd6 options=3D21 > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D80009 > ether b8:27:eb:5e:35:df > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > Starting devd. > urtwn0: on usbus0 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > urtwn0: enabling 11n > Starting dhclient. > DHCPREQUEST on ue0 to 255.255.255.255 port 67 > DHCPACK from 192.168.0.1 > bound to 192.168.0.119 -- renewal in 15768000 seconds. > wlan0: Ethernet address: 00:e0:4c:1d:49:24 > Created wlan(4) interfaces: wlan0. > Starting wpa_supplicant. > Starting Network: wlan0. > wlan0: flags=3D8843 metric 0 = mtu 1500 > ether 00:e0:4c:1d:49:24 > groups: wlan=20 > ssid "" channel 1 (2412 MHz 11b) > regdomain FCC country US authmode WPA1+WPA2/802.11i privacy = MIXED > deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 wme roaming = MANUAL > bintval 0 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > nd6 options=3D29 > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Generating host.conf. =3D=3D=3D Mark Millard markmi at dsl-only.net