From owner-freebsd-arm@freebsd.org Sun Apr 2 00:00:13 2017 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 D1501D2A63C for ; Sun, 2 Apr 2017 00:00:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 68984392 for ; Sun, 2 Apr 2017 00:00:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x233.google.com with SMTP id w43so127033512wrb.0 for ; Sat, 01 Apr 2017 17:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VIPTLAUbo7WkWsKTb2BkEERmlCIm/Bwi/NfifqPYlkw=; b=DhI/wyQCwWnsLxN1RcRw1Zqp1CVLutxmkYReojmCOPcqbJWeRCaYnnDIfGYhMPhTAV 91SartSSRClMqKcOhNHEtkT7m/b37vTKtoKD0DJ2PzX6mZaNr6/nU1PIWLOwK6FEAm1Q XcBp2zA+6eDk2uOdogvL11QdTgcQFxJCvXZ8QudmwmMBtBLy87iCCFAsfaH3h+kLHtG7 zB09j6dFZ/ASVambsvs3Hl/xLQSBe+PC9unnTzd1fg6Z/3rQYuRZkf6wJU8STGZ0f6hW Bqz5i42D1+Xbn7aMbO7si+LDOK/sz5s7Om3ZQP/hcA+YHFokcCFKDis/ZFK24XBiaxfB 3OaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VIPTLAUbo7WkWsKTb2BkEERmlCIm/Bwi/NfifqPYlkw=; b=b93xSsNu2Amv1SewiKDafGc2vyzi3BHmY9QG62NPhOo1uQg+De2A604s74KDv1YE6D 9DJLd50pqUwemdq0bpybbV/DnhQJzAnHrkUHBiqGRqkDe29Mb+wufcFaA/IwhzkmjBFa xWvldLZB2PNr4ZJOyAiamQzR9nFbXe3lqXfMauLMD9AItam9tmyFnSg/yi8vhkxXMjPj ZiRnvuDvzgJZjHFdh5bBINfLxeOjOtbNG5NxNn4yMeqbcbsW6smlPx6Ds3TChA/Zib95 +NJWExs2U1Ib2s+RHBLRnft1zoIiujBfrGkL3zphVXG1B8fZGOisnMfc5cPgLvR2+6Sv n1ng== X-Gm-Message-State: AFeK/H3AQ3/JdEUjCAGwpi/PxWU1qZu03EA4L7i7D149AXmYfaaaO7abRM5Q6dHyEmjUtvWUh2CKrcWo69p46g== X-Received: by 10.223.180.69 with SMTP id v5mr9611559wrd.62.1491091211295; Sat, 01 Apr 2017 17:00:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.128.133 with HTTP; Sat, 1 Apr 2017 17:00:10 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Sat, 1 Apr 2017 17:00:10 -0700 Message-ID: Subject: Re: Coherent bus_dma for ARMv7 To: Marcin Wojtas Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 00:00:13 -0000 hiya, so why's this need to be different? can't it somehow be merged with the existing busdma code? -adrian On 31 March 2017 at 07:05, Marcin Wojtas wrote: > Patch with the coherent bus_dma support attached. > > Marcin > > 2017-03-31 16:01 GMT+02:00 Marcin Wojtas : >> Hi, >> >> In current FreeBSD-HEAD ARMv7 platforms, which support hardware IO >> cache coherency cannot make use of this feature. In our project we >> implemented coherent variant bus_dma, which is basing on x86 and arm64 >> approach. Using of above solution is not obligatory and depends on >> setting newly added option for that purpose. >> >> Needless to say, our platform (Marvell Armada 38x) IO performance >> boosted after switching to it. Do you wish to enable such option in >> HEAD? >> >> Regards, >> Marcin > > _______________________________________________ > 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" From owner-freebsd-arm@freebsd.org Sun Apr 2 09:36:50 2017 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 7F2D6D297C5 for ; Sun, 2 Apr 2017 09:36:50 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 53211B28 for ; Sun, 2 Apr 2017 09:36:49 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A0726205BA for ; Sun, 2 Apr 2017 05:36:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 02 Apr 2017 05:36:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=5VZ+CCa61eVgMWo+sjVO5oqKBHpwDLYmyb+FVQ2pv Pc=; b=XlDoHa6TtOuPG+SnlhTVnBZdDMQnWkyy2wEFnyLJuYBAgTCKhx4dPfP7z F+WRTKJmk45dRmlGnQMB6+ywOHUQx4Apu/r4C3cxnrHDsK1zI5RbvabxcoUx5JFT GhKsWJypmxJYOEDlPkdrMe14MvTJuZxl2hHqPA72QFyYMj4EPJiuIJ+FuvEbs7ke tPxylnlEdTm3lrhWGR0h6vKC77MtV2CKkOhfl6dTBJGOyrEkAN9YLSDlhX8aCeJx L15zDMJtRr7TtjWy4depNo64CnU7QRxROh80xAeHVhS6BU+ZLDzn79D4F2e7l36k 3/O1wn9cw0RiSzyAvqVLAprexjf9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=5VZ+CCa61eVgMWo+sj VO5oqKBHpwDLYmyb+FVQ2pvPc=; b=p9lWuVllu3/2GGzHk+DbDCrqnno6RFDXW7 rUO22A54bNnFfiCpcLRpI6xFxjs6a82Q74zX2mFxnJ1RbA/E0dplm5qK49urcsgV 7tfMDaMIUvcg9S7aKjS0tTt0VATujvfjz1lBTKv8azsMnM9M8XMiuBnpz5jVmF1E 4T2S7MVKnx7C3KxJWc8BY5OuypwVQ87nD2tRJxBwTfct/+xt3xCvr+KsT1hD9ACa vPzSQPfmN81YQ/KL2RjWuGbe/uYAdkt8r+c1MPeTn1J+ODD00cqHC2c/l5eaiqDo m4CBpYfty3x/fuQWAHQn8DvGlSaejZTJK/w7gjKFFtVHQYDjuvHg== X-ME-Sender: X-Sasl-enc: hycpQvrvNviPTLocTjJDe5Fdoc+79obbhN+ECsuqm1CB 1491125803 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 466C3240CA for ; Sun, 2 Apr 2017 05:36:43 -0400 (EDT) To: freebsd-arm@freebsd.org From: tech-lists Subject: SoC single boards with dual ethernet that work with FreeBSD Message-ID: <4f0d7bee-aa5a-17a3-bfba-e577cc3fcfa3@zyxst.net> Date: Sun, 2 Apr 2017 10:36:42 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 09:36:50 -0000 Hello arm@, I thought the best place to ask would be here. I was wondering, are there any SoC single boards made yet with dual ethernet that work with FreeBSD? Searches so far have turned up as vapourware. Basically need dual ethernet 1GB RAM, more is better usb2. usb3 is better doesn't have to be quick it doesn't NEED to be arm, but I thought arm was better at the low power stuff 64-bit is better but 32-bit I can live with It's to replace an elderly openbsd pc functioning as a pppoe router, which consumes 55W at idle. thanks, -- J. From owner-freebsd-arm@freebsd.org Sun Apr 2 10:13:23 2017 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 4BC11D2A871 for ; Sun, 2 Apr 2017 10:13:23 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 1368EA84 for ; Sun, 2 Apr 2017 10:13:22 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cucVe-000AqD-Po; Sun, 02 Apr 2017 12:13:22 +0200 Date: Sun, 2 Apr 2017 12:13:22 +0200 From: Kurt Jaeger To: tech-lists Cc: freebsd-arm@freebsd.org Subject: Re: SoC single boards with dual ethernet that work with FreeBSD Message-ID: <20170402101322.GV64587@home.opsec.eu> References: <4f0d7bee-aa5a-17a3-bfba-e577cc3fcfa3@zyxst.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4f0d7bee-aa5a-17a3-bfba-e577cc3fcfa3@zyxst.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 10:13:23 -0000 Hi! > I thought the best place to ask would be here. I was wondering, are > there any SoC single boards made yet with dual ethernet that work with > FreeBSD? Searches so far have turned up as vapourware. http://www.pcengines.ch/apu2.htm is amd64, up to 4 GB RAM, 3 ethernet ports, low power, works fine with FreeBSD. -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-arm@freebsd.org Sun Apr 2 14:11:39 2017 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 7ACADD2A67C for ; Sun, 2 Apr 2017 14:11:39 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (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 4AF9C697 for ; Sun, 2 Apr 2017 14:11:38 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from [127.0.0.1] (exit1.ipredator.se [197.231.221.211]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id v32Egp1F019094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 2 Apr 2017 10:42:53 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Subject: Re: SoC single boards with dual ethernet that work with FreeBSD To: freebsd-arm@freebsd.org References: <4f0d7bee-aa5a-17a3-bfba-e577cc3fcfa3@zyxst.net> <20170402101322.GV64587@home.opsec.eu> From: George Rosamond Message-ID: <34187097-f7ce-ae10-60df-66ed7fd136f0@ceetonetechnology.com> Date: Sun, 02 Apr 2017 14:11:00 +0000 MIME-Version: 1.0 In-Reply-To: <20170402101322.GV64587@home.opsec.eu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 14:11:39 -0000 Kurt Jaeger: > Hi! > >> I thought the best place to ask would be here. I was wondering, are >> there any SoC single boards made yet with dual ethernet that work with >> FreeBSD? Searches so far have turned up as vapourware. > > http://www.pcengines.ch/apu2.htm > > is amd64, up to 4 GB RAM, 3 ethernet ports, low power, works fine > with FreeBSD. > I love and use loads of the APU2, and am happy with the general BSD support, but this is an ARM list :) The only "big picture" view I know of all SoCs is the wikipedia page "comparison of single-board computers" but I don't know how accurate it is, nor does it indicate FreeBSD support. You can compare to the chips listed on https://www.freebsd.org/plaforms/arm.html Netgate seems to have an ARM product with two gigabit NICs with the TI AM3352 chip. I know this question has come up on the list in the past. . . g From owner-freebsd-arm@freebsd.org Sun Apr 2 17:45:05 2017 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 75FA0D2AD55 for ; Sun, 2 Apr 2017 17:45:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 5181F2AA for ; Sun, 2 Apr 2017 17:45:04 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1b548587-17cc-11e7-bfb5-0d159cd3c324 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 1b548587-17cc-11e7-bfb5-0d159cd3c324; Sun, 02 Apr 2017 17:45:06 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v32Hiuuj001548; Sun, 2 Apr 2017 11:44:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1491155096.37037.14.camel@freebsd.org> Subject: Re: Current state of FreeBSD iMX6 porting efforts? From: Ian Lepore To: DJ Regan , freebsd-arm@freebsd.org Date: Sun, 02 Apr 2017 11:44:56 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 17:45:05 -0000 On Fri, 2017-03-31 at 09:11 -0500, DJ Regan wrote: > According to wiki page... > >     https://wiki.freebsd.org/FreeBSD/arm/imx6/ > > ...the last update of 'what works' vs 'what still needs to be done', > was... > >     FreeBSD/arm/imx6 (last edited 2015-02-02 01:54:07 by IanLepore > ) > > ...what is the current state of iMX6 development? > > And, where can I start to help? :) > > Thanks, > --DJ Regan Sadly, the status now isn't all that different.  I think audio and video work now, including HDMI.  Even though I have like a dozen imx6 boards here, I've never tried audio or video. The imx6 things I'm most likely to focus on this year are driven by the needs of $work:    - IEEE-1588 / PTP  - Better power management  - imx6ul support On a personal level, I've thought about buying an imx6qp board and see if the 'quad-plus' enhancements noticibly speed up anything except the graphics processors we don't support.  What doesn't work that you'd like to see working?  That's probably the best place to start with helping, but sometimes even just asking for something gets surprising results.  For example I think we lack a SPI driver, and that's the kind of thing someone might spend a few days writing if there were a request for it. -- Ian From owner-freebsd-arm@freebsd.org Sun Apr 2 18:55:27 2017 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 25CDBD2BE95 for ; Sun, 2 Apr 2017 18:55:27 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 DCB4A981 for ; Sun, 2 Apr 2017 18:55:26 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id f193so105513639oib.2 for ; Sun, 02 Apr 2017 11:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Gwti9afwErunzjUseMNlil3cK+jO26rCG9nygwCucLI=; b=Zb3DGvqQEeXXk5LT55VqN/7S+MUCLs5PS546EBME7+X5+T2/HgDQqUjleHLTdWDopJ J2YZq4qRZVCnpHmcu5Idnu8xxWa9TazEz67r4rwkLb/Aa4c8MzWQ6QzJNG4KKDW4Nkbr dXMdEHIagJUqzvUUYk3bxkASR/dIQPdVCiR+19hvLibuhl6cYpzPIHx4iq3JKpqn52Kj x4NOcRNenv8/gmq+yvU5F+zRbwrzv4SW+QS0nGPP+Hk/oQ7bJyczOQvR/3CscJjOuvMi WE8HHo+mzo5+CmZvo1jgIYfIRWifqvS1BBNhqy+xvoI3h6eqm7MhPoSCVUnXpEB5RqPl 6H8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Gwti9afwErunzjUseMNlil3cK+jO26rCG9nygwCucLI=; b=WNm+t+fn4Qux1Dxg3zenWsZxlrh+sTlTJEPuyJqc01bcRHZriR94zJpBQ6kkBzKtTl LmX7eJliBaTTPmzswX4Peo8PWTUq9bymVmcJtMIuCmzno6GJ5BLm7PSIrSLFsjMYMeh+ 1JanUVqjwHsnVtwhq019pgo0UCOnjSGBxHRX9Be0/1wBeG3HCG1Kd9iNDUNkIAzyRWp4 tLsvJYp+KsbpkShSK2zNqE26ihtxCraABcgHMsaF5ybS/8EI+txy3jNgmaWYfhCBcLyX KJ5aAtiOZjfQe1lS/QoNTTtHf+bQFQi+etJ7QS55vSR5YZ3+fHbsajkjqZgTqFc2MurX 4eqA== X-Gm-Message-State: AFeK/H38pxRuw5rSjzcmv8SaVUdASfHWddGTer0uQxwawlD+e8YBs0uqQOkueD6Mcp5Hb9dTB/dZL8xHdlKM/w== X-Received: by 10.202.222.137 with SMTP id v131mr7401825oig.190.1491159326113; Sun, 02 Apr 2017 11:55:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.68.145 with HTTP; Sun, 2 Apr 2017 11:55:25 -0700 (PDT) In-Reply-To: <20170401100631.GA29011@jrl.uk.to> References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> <20170331094127.GA29618@jrl.uk.to> <20170331111538.GB31398@jrl.uk.to> <20170331234216.GA16657@jrl.uk.to> <20170401100631.GA29011@jrl.uk.to> From: Jan Sieka Date: Sun, 2 Apr 2017 20:55:25 +0200 Message-ID: Subject: Re: [SOLUTION] DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) To: Rasmus Liland , Jan Sieka , Mori Hiroki , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 18:55:27 -0000 Great to read such a news! Best regards, Jan 2017-04-01 12:06 GMT+02:00 Rasmus Liland : > On 2017-04-01 01:42 +0200, Rasmus Liland wrote: > > > > Unable to calculate the addresses myself, I found in U-boot > > already stated address variables of Linux kernel /boot/uImage and > > ramdisk /uInitrd to be respecively addr_kern=3D0x680000, and > > addr_rd=3D0x1100000, which is an offset of 5568KiB. > > > > As stated earlier, it is possible to load kernel.bin from address > > 0x600000, perhaps 0x680000 is just enough. Will try this, > > reporting back in some hours. > > GUYS!!! > IT'S BOOTING!!! > > The proper way of booting is: > > =C2=B7 Taking the DOCKSTAR kernel, ripping out the IPSEC_NAT_T to > make it compile at all (why this module does not compile on > TARGET_ARCH=3Darm despite being enabled in this stock kernel I > do not know) > > =C2=B7 Loading resulting kernel.bin to address 0x1100000, which is > the address already defined in $addr_rd to normally load the > Linux ramdisk uInitrd > > /Rasmus > From owner-freebsd-arm@freebsd.org Sun Apr 2 22:11:12 2017 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 00E14D2B132 for ; Sun, 2 Apr 2017 22:11:12 +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 C5CA8BC3 for ; Sun, 2 Apr 2017 22:11:11 +0000 (UTC) (envelope-from george@vagner.com) X-HalOne-Cookie: 06d967ca37b62c9fc355c55d385dd7c1d16b9162 X-HalOne-ID: 1a1c88d2-17f1-11e7-b39d-549f35fe4221 Received: from [192.168.0.249] (unknown [99.197.8.237]) by mailrelay1.pub.mailoutpod1-wdc1.one.com (Halon) with ESMTPSA id 1a1c88d2-17f1-11e7-b39d-549f35fe4221; Sun, 02 Apr 2017 22:09:59 +0000 (UTC) To: freebsd-arm@freebsd.org From: vagner Subject: how to get into single user mode Message-ID: <7cf8239d-b2b2-9d30-51d5-907d8feab967@vagner.com> Date: Sun, 2 Apr 2017 18:09:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:11:12 -0000 i made a mistake in my /etc/fstab on an external drive setting not on the boot device and the system wont boot, it stops after the ethernet detection and then random unblocking device. as the system boots up it does show to press a key to get into single user mode but the keyboard is not initialized yet. how can i get in to fix my fstab file? George From owner-freebsd-arm@freebsd.org Sun Apr 2 22:11:27 2017 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 60379D2B237 for ; Sun, 2 Apr 2017 22:11:27 +0000 (UTC) (envelope-from george@vagner.com) Received: from mailrelay2-2.pub.mailoutpod1-wdc1.one.com (mailrelay2-2.pub.mailoutpod1-wdc1.one.com [104.37.35.58]) (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 33530D47 for ; Sun, 2 Apr 2017 22:11:26 +0000 (UTC) (envelope-from george@vagner.com) X-HalOne-Cookie: 25c46edcdd9f3329e1c9fa709e98eb935404193e X-HalOne-ID: 24fc05a3-17f1-11e7-a84d-549f35fe7f6e Received: from [192.168.0.249] (unknown [99.197.8.237]) by mailrelay2-1.pub.mailoutpod1-wdc1.one.com (Halon) with ESMTPSA id 24fc05a3-17f1-11e7-a84d-549f35fe7f6e; Sun, 02 Apr 2017 22:10:17 +0000 (UTC) To: freebsd-arm@freebsd.org From: vagner Subject: how to get into single user mode Message-ID: Date: Sun, 2 Apr 2017 18:10:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:11:27 -0000 i made a mistake in my /etc/fstab on an external drive setting not on the boot device and the system wont boot, it stops after the ethernet detection and then random unblocking device. as the system boots up it does show to press a key to get into single user mode but the keyboard is not initialized yet. how can i get in to fix my fstab file? George From owner-freebsd-arm@freebsd.org Sun Apr 2 22:27:26 2017 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 4FF4AD2B56E for ; Sun, 2 Apr 2017 22:27:26 +0000 (UTC) (envelope-from regantechservicesinc@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 0BE2F3EF; Sun, 2 Apr 2017 22:27:26 +0000 (UTC) (envelope-from regantechservicesinc@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id r45so99312671qte.3; Sun, 02 Apr 2017 15:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bPYWm4yBFJridcqNss/r0tdzjWKgbGDdL9MbhhcKDdU=; b=eyEAfciR1M9onqznHjaV/ZIA8SYZMHg/JUVaEtayKQMYdyMqoY+vorN1kghDOk1g0F zV7AoopfLGi15ss/X5k/JelCDAJEZKsQ7NRlwRTalAo7UHgkN/rLl8QGGB5j0Q9bXObU ORZXI+x2euRTkN0+AlyFXBA32uh3GzRCuI3WfftFYn7SGD+6TWJKiMgYmWPNB1CDOkuy gGRQUNpDM0OOE29tgf8mnr5mqp+08Y98WeBsejqj0+TgpmEhORl3vnJFmtNDruiX8eKp 7N592gpCG4dbKzjd5/U/3ljnrquyRUTCil7xxae/jBvK6CxbnhpaGQ4nhoqa5a+IEpkh GlWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bPYWm4yBFJridcqNss/r0tdzjWKgbGDdL9MbhhcKDdU=; b=ne4I60t8Y8danPu5pRYLQnaGqWvyYZtONvLCvYWZ/8mj/7pZl+M9BOx3r/EnC/ifbn mB/3BpwJ1RsZbyBl3UoArcMeds5ojSZIGVQRkdfKuOmygE8LSwDJ+DvsfIQlgSf3rFV4 SixzhzMarZy94lHVvkKPDkY+yOf6Ec3BrkNPa0UATqA02yYYPZ1zjzZsorYWGlX09nqN 9qSN3SLc4h646nAiLrVIxbfVtCPk+ezHAHEQYdJ63xJDI3Ha1pcBnmy+QV9MdWK8Rg/N uays6GNqF2Bg69mJhgYQOtwdjZSOMUwfRxlNCdc445CHxKVIiWGnXolRfcYJ9yS5jzxb ofhA== X-Gm-Message-State: AFeK/H00O01YTh2My/Wr3mOBw0vcnjKkPmBjWpT7gc+S9JxEr1iqXyJe7Kq7nAJFvDc0eVgo4Ys7yZO/GFD/Rw== X-Received: by 10.200.54.247 with SMTP id b52mr13544777qtc.160.1491172044888; Sun, 02 Apr 2017 15:27:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.62.218 with HTTP; Sun, 2 Apr 2017 15:27:24 -0700 (PDT) In-Reply-To: <1491155096.37037.14.camel@freebsd.org> References: <1491155096.37037.14.camel@freebsd.org> From: DJ Regan Date: Sun, 2 Apr 2017 17:27:24 -0500 Message-ID: Subject: Re: Current state of FreeBSD iMX6 porting efforts? To: Ian Lepore Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:27:26 -0000 Hi Ian, Understood sir. It happened to be the i.MX6UL (with ARM Cortex-A7, right?) was most curious about. For embedded projects that don't require video or audio... the Cortex-A7 may be all the power those embedded projects require. I saw the SPI driver in the list of unfinished drivers. I also didn't think it would be hard to port SPI from a working project over to the iMX6. :) Some i.MX6UL SOMs are being priced in the $24-ish (ex Variscite DART-6UL) range, so at those low prices - > you'd think there are a lot of good embedded application problems waiting to be solved with embedded FreeBSD. :) I'm new to FreeBSD - but, I'm excited to learn more and try to make myself useful to the community. Thanks sir... --DJ Regan On Sun, Apr 2, 2017 at 12:44 PM, Ian Lepore wrote: > On Fri, 2017-03-31 at 09:11 -0500, DJ Regan wrote: > > According to wiki page... > > > > https://wiki.freebsd.org/FreeBSD/arm/imx6/ > > > > ...the last update of 'what works' vs 'what still needs to be done', > > was... > > > > FreeBSD/arm/imx6 (last edited 2015-02-02 01:54:07 by IanLepore > > ) > > > > ...what is the current state of iMX6 development? > > > > And, where can I start to help? :) > > > > Thanks, > > --DJ Regan > > Sadly, the status now isn't all that different. I think audio and > video work now, including HDMI. Even though I have like a dozen imx6 > boards here, I've never tried audio or video. > > The imx6 things I'm most likely to focus on this year are driven by the > needs of $work: > > - IEEE-1588 / PTP > - Better power management > - imx6ul support > > On a personal level, I've thought about buying an imx6qp board and see > if the 'quad-plus' enhancements noticibly speed up anything except the > graphics processors we don't support. > > What doesn't work that you'd like to see working? That's probably the > best place to start with helping, but sometimes even just asking for > something gets surprising results. For example I think we lack a SPI > driver, and that's the kind of thing someone might spend a few days > writing if there were a request for it. > > -- Ian > > From owner-freebsd-arm@freebsd.org Mon Apr 3 01:00:51 2017 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 A2DDFD2ABD5 for ; Mon, 3 Apr 2017 01:00:51 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (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 5D8A599F for ; Mon, 3 Apr 2017 01:00:50 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=31671 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cuq4t-0005ds-SL; Mon, 03 Apr 2017 00:42:39 +0000 Received: from [127.0.0.1] (port=18123 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.89 (FreeBSD)) (envelope-from ) id 1cuq4t-0000wD-3p; Mon, 03 Apr 2017 00:42:39 +0000 From: Andrew Gierth To: vagner Cc: freebsd-arm@freebsd.org Subject: Re: how to get into single user mode In-Reply-To: <7cf8239d-b2b2-9d30-51d5-907d8feab967@vagner.com> (vagner's message of "Sun, 2 Apr 2017 18:09:53 -0400") Message-ID: <87h926tjb6.fsf@news-spur.riddles.org.uk> References: <7cf8239d-b2b2-9d30-51d5-907d8feab967@vagner.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Mon, 03 Apr 2017 01:42:38 +0100 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 01:00:51 -0000 >>>>> "vagner" == vagner writes: vagner> i made a mistake in my /etc/fstab on an external drive setting vagner> not on the boot device and the system wont boot, it stops after vagner> the ethernet detection and then random unblocking device. vagner> as the system boots up it does show to press a key to get into vagner> single user mode but the keyboard is not initialized yet. You don't say what hardware this is? But my guess is that it's expecting a serial console, and so the single-user prompts are going there rather than to the screen. (I had that a lot when first setting up the RPI.) -- Andrew. From owner-freebsd-arm@freebsd.org Mon Apr 3 02:32:25 2017 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 B6C09D2955E for ; Mon, 3 Apr 2017 02:32:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 51E4631E for ; Mon, 3 Apr 2017 02:32:24 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: bfa1c86c-1815-11e7-b96e-2378c10e3beb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id bfa1c86c-1815-11e7-b96e-2378c10e3beb; Mon, 03 Apr 2017 02:32:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v332WD0x002249; Sun, 2 Apr 2017 20:32:13 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1491186733.37037.28.camel@freebsd.org> Subject: Re: Current state of FreeBSD iMX6 porting efforts? From: Ian Lepore To: DJ Regan Cc: freebsd-arm@freebsd.org Date: Sun, 02 Apr 2017 20:32:13 -0600 In-Reply-To: References: <1491155096.37037.14.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 02:32:25 -0000 On Sun, 2017-04-02 at 17:27 -0500, DJ Regan wrote: > Hi Ian, > > Understood sir. It happened to be the i.MX6UL (with ARM Cortex-A7, > right?) > was most curious about. For embedded projects that don't require > video or > audio... the Cortex-A7 may be all the power those embedded projects > require. I saw the SPI driver in the list of unfinished drivers. I > also > didn't think it would be hard to port SPI from a working project over > to > the iMX6. :) > > Some i.MX6UL SOMs are being priced in the $24-ish (ex Variscite DART- > 6UL) > range, so at those low prices - > you'd think there are a lot of good > embedded application problems waiting to be solved with embedded > FreeBSD. :) > > I'm new to FreeBSD - but, I'm excited to learn more and try to make > myself > useful to the community. > > Thanks sir... > --DJ Regan I made some time to play with my new imx6ul hobbitboard today.  A bit of crude hackery has it booting most of the way through device setup, but then it hangs.  Also, no devices work yet that could host the rootfs.  The ethernet never sees a link-up, usb never probes the busses sucessfully, and something hangs before mmc/sd even gets a chance to do its bus probing. Still, I made some progress compared to my 15-minute attempt a few days ago where I couldn't even seem to get the kernel to start (turns out it was kinda starting, but the hobbitboard puts the serial debug console on uart6 so I didn't see it). -- Ian From owner-freebsd-arm@freebsd.org Mon Apr 3 06:05:46 2017 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 3D932D2BBEB for ; Mon, 3 Apr 2017 06:05:46 +0000 (UTC) (envelope-from hm@hellmuth-michaelis.de) Received: from mail.agsec.de (mail.kts.org [IPv6:2a00:14b0:f000:1::222]) (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 EAE6197D for ; Mon, 3 Apr 2017 06:05:45 +0000 (UTC) (envelope-from hm@hellmuth-michaelis.de) Received: from hh01.agsec.de (localhost [127.0.0.1]) by mail.agsec.de (Postfix) with ESMTP id 6E57961FA0 for ; Mon, 3 Apr 2017 08:05:42 +0200 (CEST) X-Virus-Scanned-AGSEC: MailMurkxDeScraCxler at agsec.de Received: from mail.agsec.de ([194.55.156.222]) by hh01.agsec.de (hh01.agsec.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08V7uTXPKCNA for ; Mon, 3 Apr 2017 08:05:39 +0200 (CEST) Received: from ernie.int.kts.org (unknown [IPv6:2a02:2028:710:5a01:20d:b9ff:fe1e:cf00]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.agsec.de (Postfix) with ESMTPSA id 0607D61F80 for ; Mon, 3 Apr 2017 08:05:39 +0200 (CEST) X-Virus-Scanned-KTS: Mail-UnWroks-U-Laksler at KTS.ORG Received: from frazzle.int.kts.org (frazzle.int.kts.org [172.31.42.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ernie.int.kts.org (Postfix) with ESMTPS id F29A38C9B1C for ; Mon, 3 Apr 2017 08:05:34 +0200 (CEST) From: Hellmuth Michaelis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: SoC single boards with dual ethernet that work with FreeBSD Date: Mon, 3 Apr 2017 08:05:34 +0200 References: <4f0d7bee-aa5a-17a3-bfba-e577cc3fcfa3@zyxst.net> <20170402101322.GV64587@home.opsec.eu> <34187097-f7ce-ae10-60df-66ed7fd136f0@ceetonetechnology.com> To: freebsd-arm@freebsd.org In-Reply-To: <34187097-f7ce-ae10-60df-66ed7fd136f0@ceetonetechnology.com> Message-Id: <872B635D-CF81-4826-A5E0-709DC561C54D@hellmuth-michaelis.de> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:05:46 -0000 > Am 02.04.2017 um 16:11 schrieb George Rosamond = : >=20 > Kurt Jaeger: >> Hi! >>=20 >>> I thought the best place to ask would be here. I was wondering, are >>> there any SoC single boards made yet with dual ethernet that work = with >>> FreeBSD? Searches so far have turned up as vapourware. >>=20 >> http://www.pcengines.ch/apu2.htm >>=20 >> is amd64, up to 4 GB RAM, 3 ethernet ports, low power, works fine >> with FreeBSD. >>=20 >=20 > I love and use loads of the APU2, and am happy with the general BSD > support, but this is an ARM list :) >=20 > The only "big picture" view I know of all SoCs is the wikipedia page > "comparison of single-board computers" but I don't know how accurate = it > is, nor does it indicate FreeBSD support. >=20 > You can compare to the chips listed on > https://www.freebsd.org/plaforms/arm.html >=20 > Netgate seems to have an ARM product with two gigabit NICs with the TI > AM3352 chip. Some time ago i found this one = http://www.adiengineering.com/products/micro-firewall, they say that = FreeBSD is running on it and it would be nice to know where one can get = one or two of them. -hm= From owner-freebsd-arm@freebsd.org Mon Apr 3 08:52:53 2017 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 5883AD272E9 for ; Mon, 3 Apr 2017 08:52:53 +0000 (UTC) (envelope-from info@polilingua.it) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 1ABF6874 for ; Mon, 3 Apr 2017 08:52:53 +0000 (UTC) (envelope-from info@polilingua.it) Received: by mail-vk0-x233.google.com with SMTP id s68so130306342vke.3 for ; Mon, 03 Apr 2017 01:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polilingua-it.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=RU4oGTnZxmXaDv/pdpwZjIp67X+8nxliV6cDEkE7SiA=; b=cEcaz+qRgwuDpq2DyA5z2O/dV9fjlDoBT0EMluF9fv+H3oNnguhn7su5tnWdJ72EJD YlkYOTvaeAtMXM94b3EBPar32M0eLHY4qJbcsocLfOKPwXMY5+CHP6wpV8SIlt1TN1H1 s7Gfa7a50py6FM1bUl4BcePZpLgU9vqveM0fA+ksulBpsdfYe06WqHzHRaoeMFoDMxvL eZSMurDpioxJ2ZNUFN3ci+pEP0/eBJzKteazUxBLvUrNOMbLrtgl9AfKoEu5/ERuaXUZ rdrNSU7arU/uUU+Ic0GAmBfe3G2advB/RfMuBUVGU9r0r6EeXRGGsBctdeaKS+uQn6vw I+NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RU4oGTnZxmXaDv/pdpwZjIp67X+8nxliV6cDEkE7SiA=; b=Pnn26TkWvTsPcrN+zfi1GOHuRec7szuliqWufH4OxjAM8CglYAiBwvtE87BMNFGOWL Z2DQ+q/bpsWUCQ+o5UR9qa0KFVc1paUMkhtR68gfuNMY//S3jeL6JjSsKSWnm0iTTTCC KpEvRKFgg0ri8vi2EzFP7v4LADBdvmSWCb/yOoM7oUBfC1Jrd7IQv1RNwRkLnraoDt73 LKZZVkCSRo9V6qPB5pIYi9645YdFLsIikQZZdB9vRncLCY4/yOxYUWPadgGZa5hPIgNy D/CIT7No4UMMnHrBfVsPm1Vup6MDOeGq+QDrqxTtLZMN0SPbidP8B+UysXcrI1bTE0zL C9uw== X-Gm-Message-State: AFeK/H2fvkprMZevVlXVza/qYOBtJlR6h2jP8AtFqT8zdOaJ8zto+FG67j9Fr6hwwzYW2+kEFCgcGrD80Zpb6Q== X-Received: by 10.31.51.12 with SMTP id z12mr7268186vkz.69.1491209568682; Mon, 03 Apr 2017 01:52:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.162 with HTTP; Mon, 3 Apr 2017 01:52:48 -0700 (PDT) From: "Irina Gutu - PoliLingua Ltd." Date: Mon, 3 Apr 2017 11:52:48 +0300 Message-ID: Subject: Inserire annuncio To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 08:52:53 -0000 PoliLingua!!! Ha l=E2=80=99esperienza in traduzione dell=E2=80=99azienda pi= =C3=B9 competente. Con anni di presenza nel settore alle spalle e un network di oltre 1.500 traduttori esperti =E2=80=93 anche per lavori di grandi dimensioni =E2=80= =93 nella traduzione da e verso oltre 180 lingue, la nostra azienda =C3=A8 in grado d= i garantire la massima qualit=C3=A0 e le pi=C3=B9 accurate traduzioni ai prez= zi pi=C3=B9 competitivi sul mercato. Con una clientela che spazia da piccoli studi a grandi multinazionali. PoliLingua vi offre una comprovata esperienza nelle traduzioni, aiutandovi a raggiungere i vostri obiettivi nei mercati locali, nazionali ed internazionali. Grazie al nostro controllo gestionale diretto e al nostro team di interpreti esperti, progettisti possiamo consegnare traduzioni professionali gestendo team di traduttori provenienti da tutto il mondo, capaci di soddisfare le richieste pi=C3=B9 complesse. La nostra azienda offre servizi di traduzione professionali e veloci, oltre che accurati e affidabili. Siamo in grado di lavorare ed elaborare qualsiasi tipologia di documento, in tutti i formati e lingue. Traduciamo testi in molte lingue, tra cui quelle principali come inglese, francese, spagnolo, olandese, tedesco, italiano, portoghese, coreano, cinese, giapponese, rumeno, russo , ma anche molte altre grazie alle conoscenze di esperti traduttori madrelingua, persone di comprovata esperienza nel settore. Inoltre i servizi di traduzione professionale da noi regolarmente forniti riguardano le traduzioni di documenti cartacei, siti web, software, elementi multimediali, interpretariato. Polilingua garantisce una traduzione veloce, accurata e professionale, dai siti web alla brochure aziendali, dai documenti scientifici a quelli ufficiali. Per maggiori dettagli possono visitare il seguente sito web: www.PoliLingua.it oppure mandare una mail per avere varie informazioni: info@polilingua.it La ringrazio della Sua cortese attenzione e rimango a sua disposizione per ulteriori informazioni. Distinti Saluti. Irina Gutu Project Manager per l=E2=80=99Italia - PoliLingua Ltd Tel.0294752297 Skype:info.polilingua.it Email: info@polilingua.it *Altri servizi offerti da PoliLingua* *Servizi di traduzioni | Servizi di trascrizione | Doppiaggio multilingua | Traduzioni certificate * From owner-freebsd-arm@freebsd.org Mon Apr 3 09:47:59 2017 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 B3B10D2A77A for ; Mon, 3 Apr 2017 09:47:59 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 2A2758A0 for ; Mon, 3 Apr 2017 09:47:59 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id x137so69494519lff.3 for ; Mon, 03 Apr 2017 02:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=KFSz4TuMmCprKaKMtmJM6lv5Z6WuKGN8vDN6iP6GX+E=; b=Izh5Z+FtzcS3mZibZ+nC7WYhVsXyWeiZw5j+pqH9zIP0tmKoaRSRovPrwqZeWC1yIh AJuHwwPV4//tUfuvm7ZzGGgg+ca3NjXXOoxRz9D5TYVOsUNZmUPUNA3hMh+NXBxiMdJm MK39M8Udfe6L3CnY+81e5uzM3S4CtnCPTubj+9Uts43JTafCJ4Gh4OOiQ8LUTehtFKKQ kvqM24rX4OGKVwp5qL4tCBlLIpYMyCTiYPtiVANx0KJZxL/ssMVkFOgi+4kuGjiU0Y7J 4KTu47Pex7Vg5yQqctxSjVseOZGJKwMQ5JJVU9xJoZ+S6UqqmGNccOuTcBhABidjt4wM pOmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=KFSz4TuMmCprKaKMtmJM6lv5Z6WuKGN8vDN6iP6GX+E=; b=G1I4suLaSkq15Tr4SSYX02Diefe/c3xljgAv0TZU0y2BCphjZO7naBeLP75jSWoi6D abDnAuYPiXC+/h3AAkWlzcSF0+v0Fleali2FkLQDCTj2rpt7ufifYaeXpddWZF6b71u2 tNhvxyX5NcGMBs2tDYje8eoK9fFI5duCpZo1q3afDwOHdMPjDYkGhE9l7kG6565wZxvH euBikKay5H25zK4xwG/cjr75TlT2EHkRpXXLDDZXwWbAfVWJ/V2OKejyKRWxr4awWopx eD4KukLAqDR07Qd9hsPTEgRR+mL2kXXqWVOPc2tSWxb4APbwBXBGXAJGHFu2LKTzPsnS FSKA== X-Gm-Message-State: AFeK/H0a6xfxCFg97kcN+WpVrpQabX/ol/POI3Tx6pyCyfFlF+Lh/gEQwsg/SEI57f4Msg== X-Received: by 10.46.69.137 with SMTP id s131mr4830555lja.125.1491212876382; Mon, 03 Apr 2017 02:47:56 -0700 (PDT) Received: from jrl.uk.to (eduroam-193-157-113-243.uio.no. [193.157.113.243]) by smtp.gmail.com with ESMTPSA id q123sm2426808ljb.18.2017.04.03.02.47.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 02:47:55 -0700 (PDT) Date: Mon, 3 Apr 2017 11:47:05 +0200 From: Rasmus Liland To: Warner Losh Cc: Jan Sieka , Mori Hiroki , freebsd-arm Subject: Re: [SOLUTION] DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170403094705.GF6011@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Warner Losh , Jan Sieka , Mori Hiroki , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> <20170331094127.GA29618@jrl.uk.to> <20170331111538.GB31398@jrl.uk.to> <20170331234216.GA16657@jrl.uk.to> <20170401100631.GA29011@jrl.uk.to> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:47:59 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2017-04-02 20:55 +0200, Jan Sieka wrote: > 2017-04-01 12:06 GMT+02:00 Rasmus Liland: > > > > GUYS!!! > > IT'S BOOTING!!! > > > > The proper way of booting is: > > > > · Taking the DOCKSTAR kernel, ripping out the IPSEC_NAT_T to > > make it compile at all (why this module does not compile > > on TARGET_ARCH=arm despite being enabled in this stock > > kernel I do not know) > > > > · Loading resulting kernel.bin to address 0x1100000, which > > is the address already defined in $addr_rd to normally > > load the Linux ramdisk uInitrd > > Great to read such a news! > > Best regards, > > Jan Dear Warner, I wonder if it would be possible for you, as the original commiter of NSLU, or someone else, could properly commit this to CVS, as I lack commit bit, as I think it would be useful for other owners of this amazing device even if it is perhaps considered arm legacy by todays standards. Best regards, Rasmus --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="success_goflex.dts.diff" --- dockstar.dts 2017-03-31 12:28:49.296360000 +0200 +++ goflex.dts 2017-04-01 20:21:27.895671000 +0200 @@ -227,6 +227,13 @@ interrupts = <5 6 7 8>; interrupt-parent = <&PIC>; }; + + sata@80000 { + compatible = "mrvl,sata"; + reg = <0x80000 0x6000>; + interrupts = <21>; + interrupt-parent = <&PIC>; + }; }; SRAM: sram@fd000000 { --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="success_GOFLEX.diff" --- DOCKSTAR 2017-03-31 12:30:26.752632000 +0200 +++ GOFLEX 2017-04-01 20:10:43.480437000 +0200 @@ -19,7 +19,7 @@ # #NO_UNIVERSE -ident DOCKSTAR +ident GOFLEX include "std.arm" include "../mv/kirkwood/std.db88f6xxx" @@ -31,9 +31,6 @@ options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support -options NFSCL # Network Filesystem Client -options NFSLOCKD # Network Lock Manager -#options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 filesystem options NULLFS # NULL filesystem @@ -48,21 +45,10 @@ options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions -# Enable these options for nfs root configured via BOOTP. -#options BOOTP -#options BOOTP_NFSROOT -#options BOOTP_NFSV3 -#options BOOTP_WIRED_TO=mge0 - -# If not using BOOTP, use something like one of these... -#options ROOTDEVNAME=\"ufs:/dev/da0a\" -options ROOTDEVNAME=\"ufs:/dev/da0s1a\" -#options ROOTDEVNAME=\"ufs:/dev/da0p10\" -#options ROOTDEVNAME=\"nfs:192.168.0.254/dreamplug\" +options ROOTDEVNAME=\"ufs:/dev/ufs/kirkwoodroot\" # Misc pseudo devices device bpf # Required for DHCP -device firmware # firmware(9) required for USB wlan device gif # IPv6 and IPv4 tunneling device loop # Network loopback device md # Memory/malloc disk @@ -71,7 +57,6 @@ device tun # Packet tunnel. device ether # Required for all ethernet devices device vlan # 802.1Q VLAN support -device wlan # 802.11 WLAN support # cam support for umass and ahci device scbus @@ -92,23 +77,18 @@ device usb # Basic usb support device ehci # USB host controller device umass # Mass storage -device uhid # Human-interface devices -device rum # Ralink Technology RT2501USB wireless NICs -device uath # Atheros AR5523 wireless NICs -device ural # Ralink Technology RT2500USB wireless NICs -device zyd # ZyDAS zb1211/zb1211b wireless NICs -device urtw # Realtek RTL8187B/L USB -device upgt # Conexant/Intersil PrismGT SoftMAC USB -device u3g # USB-based 3G modems (Option, Huawei, Sierra) # I2C (TWSI) device iic device iicbus device twsi -# Sound -device sound -device snd_uaudio +# SATA +device mvs +device ahci + +# NAND +#device nand #crypto device cesa # Marvell security engine @@ -118,18 +98,13 @@ # IPSec device enc options IPSEC -options IPSEC_NAT_T options TCP_SIGNATURE # include support for RFC 2385 -# IPFW -options IPFIREWALL -options IPFIREWALL_DEFAULT_TO_ACCEPT -options IPFIREWALL_VERBOSE -options IPFIREWALL_VERBOSE_LIMIT=100 -options IPFIREWALL_NAT -options LIBALIAS -options DUMMYNET -options IPDIVERT +# DTrace +options KDTRACE_HOOKS +options DDB_CTF +makeoptions DEBUG=-g +makeoptions WITH_CTF=1 #PF device pf @@ -153,4 +128,4 @@ # Flattened Device Tree options FDT # Configure using FDT/DTB data options FDT_DTB_STATIC -makeoptions FDT_DTS_FILE=dockstar.dts +makeoptions FDT_DTS_FILE=goflex.dts --XsQoSWH+UP9D9v3l-- From owner-freebsd-arm@freebsd.org Mon Apr 3 13:16:47 2017 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 723C2D2CEF8 for ; Mon, 3 Apr 2017 13:16:47 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 3C3F49BA for ; Mon, 3 Apr 2017 13:16:47 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-io0-x22d.google.com with SMTP id b140so74800214iof.1 for ; Mon, 03 Apr 2017 06:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NNjOfgCkI5F9iFakIKsZE3xaRilOKxQvYHf/YQEEz/0=; b=DrZMcgeu5rNqFOvtax81Js8ymxMr1DaFpLdQO3RIMkEkSBCbhOmsV58mmMzoIJClqi GShK+DfRQsHODe11OhJ17x12dei/RjRlM9d2d2+RoVvFTehT9GMDzLGiDs0bR2+o54ja 35xvYIoqOGGcauu8Q9AzxJ0mUwdk9s1u6WTO//vS+KyDMKlELCJtj0dLH//YFqL9xdQ1 Gn4MoGlrgXUtcu32mv9f4b0InxG4ODP38KIZ0CV0EeC9DbDP2g6MrIHMcDkOO9AaPJLl yHB8YvBHaOskNx1w4Q/t/xIJQMj4YWPpC+jxq8prACNDkFxExQ8Ld8tffB/YGjeH1EA5 fanw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NNjOfgCkI5F9iFakIKsZE3xaRilOKxQvYHf/YQEEz/0=; b=hPu2RUrP/5gsnqoKFD7ENGM/eYrb9m2pyG+vXhuPYIwbatiJW9pUUWoA9RAZ2Z5q0m GjY59NXYFN/saWnwa6M2FFCLBL2rbyClX0QqBrtn6kmdEq3SLigz5CSL5uOvwTKqb+9z xOPMGxfkVp1vJQOaZURcq19Zm8BrN9AqmLCLLKdno1qYoPKsAbZUYClDKZBruzsRNnrV m1pDVEs6bBADveI0xMsdYfnUETktHWTIIxFHhWIKCFHmKT0LGfW3BxGJulO6BrddQCDd seIRiUFsdXKW1gdHcRXq/2jobEP5o6Fcw4fGOuy7iRoCU7gYpyNpS/1QP6r1/1vF6RHT uoKw== X-Gm-Message-State: AFeK/H1xSLGwexh7XERyD/TtC9hIuP5vxyBH9mduEr7XIUmQ59r+T4lY5LmBKGm+w8a2ICPa9lki0W9kIUZ47w== X-Received: by 10.107.32.199 with SMTP id g190mr17516459iog.117.1491225406572; Mon, 03 Apr 2017 06:16:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.146 with HTTP; Mon, 3 Apr 2017 06:16:45 -0700 (PDT) In-Reply-To: References: From: Marcin Wojtas Date: Mon, 3 Apr 2017 15:16:45 +0200 Message-ID: Subject: Re: Coherent bus_dma for ARMv7 To: Adrian Chadd Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:16:47 -0000 Hi Adrian, Frankly we are not such experts in armv6 bus_dma, which looks more complicated than one in arm64, so we thought it's much safer no to mix the two solutions and leave for the user a single switch to decide, which one to pick. Afaik Andrew Turner did the oposite for arm64 (implement not coherent solution on top of coherent bus_dma), however I'm not sure if it's possible here in an easy way - there's also pretty significant risk of regression for all platforms. Please let me know your opinion. Do you think some sort of update of armv6 is doable? Marcin 2017-04-02 2:00 GMT+02:00 Adrian Chadd : > hiya, > > so why's this need to be different? can't it somehow be merged with > the existing busdma code? > > > > -adrian > > > On 31 March 2017 at 07:05, Marcin Wojtas wrote: >> Patch with the coherent bus_dma support attached. >> >> Marcin >> >> 2017-03-31 16:01 GMT+02:00 Marcin Wojtas : >>> Hi, >>> >>> In current FreeBSD-HEAD ARMv7 platforms, which support hardware IO >>> cache coherency cannot make use of this feature. In our project we >>> implemented coherent variant bus_dma, which is basing on x86 and arm64 >>> approach. Using of above solution is not obligatory and depends on >>> setting newly added option for that purpose. >>> >>> Needless to say, our platform (Marvell Armada 38x) IO performance >>> boosted after switching to it. Do you wish to enable such option in >>> HEAD? >>> >>> Regards, >>> Marcin >> >> _______________________________________________ >> 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" From owner-freebsd-arm@freebsd.org Mon Apr 3 13:37:13 2017 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 1CD86D2C79B for ; Mon, 3 Apr 2017 13:37:13 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id DD1B3894 for ; Mon, 3 Apr 2017 13:37:12 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from dhcp-10-248-121-82.eduroam.wireless.private.cam.ac.uk (global-5-144.nat-2.net.cam.ac.uk [131.111.5.144]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id F18524E6DC; Mon, 3 Apr 2017 13:37:05 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Coherent bus_dma for ARMv7 From: Andrew Turner In-Reply-To: Date: Mon, 3 Apr 2017 14:37:05 +0100 Cc: Adrian Chadd , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0EA39E6B-3460-45B9-8247-CB6CC8631C5F@fubar.geek.nz> References: To: Marcin Wojtas X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:37:13 -0000 > On 3 Apr 2017, at 14:16, Marcin Wojtas wrote: >=20 > Hi Adrian, >=20 > Frankly we are not such experts in armv6 bus_dma, which looks more > complicated than one in arm64, so we thought it's much safer no to mix > the two solutions and leave for the user a single switch to decide, > which one to pick. Afaik Andrew Turner did the oposite for arm64 > (implement not coherent solution on top of coherent bus_dma), however > I'm not sure if it's possible here in an easy way - there's also > pretty significant risk of regression for all platforms. Please let me > know your opinion. Do you think some sort of update of armv6 is > doable? I don=E2=80=99t see any reason to think it would be difficult to add = support for coherent hardware to the existing armv6 busdma code. It=E2=80=99= s mostly skipping cache operations based on a flag in the dam tag. Andrew From owner-freebsd-arm@freebsd.org Mon Apr 3 14:14:26 2017 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 0ECD3D2B8BD for ; Mon, 3 Apr 2017 14:14:26 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 9A6172E8 for ; Mon, 3 Apr 2017 14:14:25 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by mail-lf0-x22a.google.com with SMTP id x137so75040728lff.3 for ; Mon, 03 Apr 2017 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6kfbienlrY7By3YGBBjAuh6vI7MRvvcpFm4UtuNzNU8=; b=PfvOol08dP2yfTeiIyTanQECNQDQWryKjPnWYkd7lYI/XjIsvf8qudZFlyaSn4iax1 c22wHc19aGUUD0ueMoxkAEpUfFUl7yUv4RLd5Ep2gk9tGx5UMiC/FRwBWemtDJVsbyn/ 15SJv0AoGpkbVKmcqf5ClNhzV8juomVXVTU1gI5UpMeO6PARGP3hRd8wY6I/bYcA84rf tR0OqPcw3/GoWDZ6msY8GEV7mZ7RbUebvB7/ZrlM/BOiTXdjeQ8amImK4G/pA1S5zaay Cgf/iboGAZW3+WOYf8yJVhWA5oqhosvD80rx0bXQzSN3BHWVd7qfgUaybIqqZ4Dy9Uun JTbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6kfbienlrY7By3YGBBjAuh6vI7MRvvcpFm4UtuNzNU8=; b=HCEUG5bAAbEdSWzlOgMxZD8uojoTRfEHvgiJxhObHeT3WnLgb4LL7S68snhuMQaNlf 4B3AkWTFUThK6pVEIt8I4e5z60wlXfZZIyJC8X+ZnqLQlhc1wol+4ds+wrRi+UG7Yelf VNH3sF0VRKACsBWCmPsB0EaJWF05DXfZypY8GMzAidMRXtt6kiVrVqUH5PY4gyWRSrf0 yl+BDVBptevydI7SoWsubLASB1coBHk0lm32OBYxVvBxs407pPH0KCWDNRsKjM+15tVS rDywlXKdWwvPkaWnqsJnpl9fu9dQeKOB+sq3tISAQYr/EbWf5XiWEWt7Pb5+EzAP8bCm ZIJg== X-Gm-Message-State: AFeK/H1MzYDtD4X6B7tB2UGpd6MkLycslR+EfaC/cj2H1XDGGuWjruQLw67ZdnZIs8kIaJUpdbFwTkTUyyr5Wg== X-Received: by 10.46.80.24 with SMTP id e24mr4943639ljb.29.1491228862652; Mon, 03 Apr 2017 07:14:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.181.220 with HTTP; Mon, 3 Apr 2017 07:14:02 -0700 (PDT) In-Reply-To: <0EA39E6B-3460-45B9-8247-CB6CC8631C5F@fubar.geek.nz> References: <0EA39E6B-3460-45B9-8247-CB6CC8631C5F@fubar.geek.nz> From: Zbigniew Bodek Date: Mon, 3 Apr 2017 16:14:02 +0200 Message-ID: Subject: Re: Coherent bus_dma for ARMv7 To: Andrew Turner Cc: Marcin Wojtas , Adrian Chadd , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:14:26 -0000 2017-04-03 15:37 GMT+02:00 Andrew Turner : > > > On 3 Apr 2017, at 14:16, Marcin Wojtas wrote: > > > > Hi Adrian, > > > > Frankly we are not such experts in armv6 bus_dma, which looks more > > complicated than one in arm64, so we thought it's much safer no to mix > > the two solutions and leave for the user a single switch to decide, > > which one to pick. Afaik Andrew Turner did the oposite for arm64 > > (implement not coherent solution on top of coherent bus_dma), however > > I'm not sure if it's possible here in an easy way - there's also > > pretty significant risk of regression for all platforms. Please let me > > know your opinion. Do you think some sort of update of armv6 is > > doable? > > I don=E2=80=99t see any reason to think it would be difficult to add supp= ort for > coherent hardware to the existing armv6 busdma code. It=E2=80=99s mostly = skipping > cache operations based on a flag in the dam tag. > > Andrew > Hello Andrew, I don't think anyone uses flags related to DMA coherency in bus_dma_tag_create. Nevertheless, for coherent platforms we want bus_dma to always map DMA memory as normal WBWA regardless of the flags passed to create a bus_dma MAP. For example, we don't want to perform any synchronization and we want to have the cacheable memory regardless of BUS_DMA_COHERENT flag used. Otherwise the performance improvement will apply only to those drivers that dare to use BUS_DMA_COHERENT flag and very few of them does that. In other words, what is the point of having coherent DMA if you do cache maintenance anyway? Another thing is that we need specific changes to the CPU configuration and mappings (SMP bit enabled + Shared attribute enabled) but this is for separate discussion. Kind regards zbb From owner-freebsd-arm@freebsd.org Mon Apr 3 14:37:25 2017 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 EB019D2C48B for ; Mon, 3 Apr 2017 14:37:25 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id B3ACA679 for ; Mon, 3 Apr 2017 14:37:25 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from dhcp-10-248-121-82.eduroam.wireless.private.cam.ac.uk (global-5-144.nat-2.net.cam.ac.uk [131.111.5.144]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 081EC4E721; Mon, 3 Apr 2017 14:37:24 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Coherent bus_dma for ARMv7 From: Andrew Turner In-Reply-To: Date: Mon, 3 Apr 2017 15:37:23 +0100 Cc: Marcin Wojtas , Adrian Chadd , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5586A20F-125D-41EC-9741-BBFFDB0A7A38@fubar.geek.nz> References: <0EA39E6B-3460-45B9-8247-CB6CC8631C5F@fubar.geek.nz> To: Zbigniew Bodek X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:37:26 -0000 > On 3 Apr 2017, at 15:14, Zbigniew Bodek wrote: >=20 > 2017-04-03 15:37 GMT+02:00 Andrew Turner : >=20 > > On 3 Apr 2017, at 14:16, Marcin Wojtas wrote: > > > > Hi Adrian, > > > > Frankly we are not such experts in armv6 bus_dma, which looks more > > complicated than one in arm64, so we thought it's much safer no to = mix > > the two solutions and leave for the user a single switch to decide, > > which one to pick. Afaik Andrew Turner did the oposite for arm64 > > (implement not coherent solution on top of coherent bus_dma), = however > > I'm not sure if it's possible here in an easy way - there's also > > pretty significant risk of regression for all platforms. Please let = me > > know your opinion. Do you think some sort of update of armv6 is > > doable? >=20 > I don=E2=80=99t see any reason to think it would be difficult to add = support for coherent hardware to the existing armv6 busdma code. It=E2=80=99= s mostly skipping cache operations based on a flag in the dam tag. >=20 > Andrew >=20 > Hello Andrew, >=20 > I don't think anyone uses flags related to DMA coherency in = bus_dma_tag_create. The generic PCI and ThunderX PCIe PEM drivers do. The former based on = the FDT dma-coherent flag. >=20 > Nevertheless, for coherent platforms we want bus_dma to always map DMA = memory as normal WBWA regardless of the flags passed to create a bus_dma = MAP. > For example, we don't want to perform any synchronization and we want = to have the cacheable memory regardless of BUS_DMA_COHERENT flag used. That=E2=80=99s already the case on arm64, the only synchronisation used = when the tag is created with BUS_DMA_COHERENT is a memory barrier. > Otherwise the performance improvement will apply only to those drivers = that dare to use BUS_DMA_COHERENT flag and very few of them does that. = In other words, what is the point of having coherent DMA if you do cache = maintenance anyway? The drivers should be getting the parent DMA tag and passing this to = bus_dma_tag_create. If this was created with BUS_DMA_COHERENT it will = pass this to the child tag. This is how the above PCI drivers work.=20 Andrew From owner-freebsd-arm@freebsd.org Mon Apr 3 14:59:12 2017 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 BB780D2CD5B for ; Mon, 3 Apr 2017 14:59:12 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 456D9336 for ; Mon, 3 Apr 2017 14:59:12 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by mail-lf0-x22f.google.com with SMTP id j90so76335691lfk.2 for ; Mon, 03 Apr 2017 07:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2aW8SrANOHuPdEFNgUgctZJTlXxdnSkd1NGUvndsgfM=; b=Vc67gSa4plB00nOGRWH5sb4mybSwBG605zcMu5312EdDfVmvOb1HKaVniJNv144t3c +rPEDLBUvzL9FB7MeoxviL+OiMu3ngUC080aPujR16sjmdyeotU7eOGo+gVjpxKTEvda 066n8r6/1WAnp+mt8QlmhLirMM8l3zUfJwjDgpB7V9OEWwW/a5faRlI0uSvZOAjbHxjo W7luk2pkyD1w4PiPis8zbdbATzhRk3axbPGbbC2ZX96XC2phxaHoHjdInZvaikHGpnOz Akv/nPi49lXQU9LsDFo6vnIkN5v37RlC7Krr3HIiazmjIoxGjD/LPbNBuoPKb5FLV3nW oFPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2aW8SrANOHuPdEFNgUgctZJTlXxdnSkd1NGUvndsgfM=; b=pEc5rl8OmTcNSvV1UGfhaHl7fYsOBRkHsN3fafQGJckWBuPER5xr1W0mH9vZuGWTR4 H5xhKNINwKLcPg4Gyj04Rfy3O2dP27KrRo0NJWY/OZ9Q093a14MTH6xiWVpbQWfvcOPb VQ5zK7udi5A3H+xEUHOqOXiVl1W2SF9G6Q4v5tRJIfb1fw+H7R3xcm2n+My+azUvPNwM i4Zn93H8WE6RaOG6BMFVAOezihcs9wd4Ia9qIy3rJIAoZE1gKpaqikVb/mJsHvQPvt15 wpmGlcU+eL0UCct+tzXAe3BMJGRX0mjE+VXIxWiLE538IjsYgLNP9a51UMao89ZnEGlH lrBw== X-Gm-Message-State: AFeK/H0QpSTqpSBBu1+bAb39Vm6YSR5FsMGrhCQWMcI6EY+dGLDTttMWMMWGhRJNwz667+8zfCo75WFkd4OdfQ== X-Received: by 10.25.32.80 with SMTP id g77mr4853909lfg.76.1491231550186; Mon, 03 Apr 2017 07:59:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.181.220 with HTTP; Mon, 3 Apr 2017 07:58:49 -0700 (PDT) In-Reply-To: <5586A20F-125D-41EC-9741-BBFFDB0A7A38@fubar.geek.nz> References: <0EA39E6B-3460-45B9-8247-CB6CC8631C5F@fubar.geek.nz> <5586A20F-125D-41EC-9741-BBFFDB0A7A38@fubar.geek.nz> From: Zbigniew Bodek Date: Mon, 3 Apr 2017 16:58:49 +0200 Message-ID: Subject: Re: Coherent bus_dma for ARMv7 To: Andrew Turner Cc: Marcin Wojtas , Adrian Chadd , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:59:12 -0000 2017-04-03 16:37 GMT+02:00 Andrew Turner : > > > On 3 Apr 2017, at 15:14, Zbigniew Bodek wrote: > > > > 2017-04-03 15:37 GMT+02:00 Andrew Turner : > > > > > On 3 Apr 2017, at 14:16, Marcin Wojtas wrote: > > > > > > Hi Adrian, > > > > > > Frankly we are not such experts in armv6 bus_dma, which looks more > > > complicated than one in arm64, so we thought it's much safer no to mi= x > > > the two solutions and leave for the user a single switch to decide, > > > which one to pick. Afaik Andrew Turner did the oposite for arm64 > > > (implement not coherent solution on top of coherent bus_dma), however > > > I'm not sure if it's possible here in an easy way - there's also > > > pretty significant risk of regression for all platforms. Please let m= e > > > know your opinion. Do you think some sort of update of armv6 is > > > doable? > > > > I don=E2=80=99t see any reason to think it would be difficult to add su= pport for > coherent hardware to the existing armv6 busdma code. It=E2=80=99s mostly = skipping > cache operations based on a flag in the dam tag. > > > > Andrew > > > > Hello Andrew, > > > > I don't think anyone uses flags related to DMA coherency in > bus_dma_tag_create. > > The generic PCI and ThunderX PCIe PEM drivers do. The former based on the > FDT dma-coherent flag. > In this particular example this will work as almost all (not all) devices on ThunderX are PCIe devices. For most ARMv7-based SoCs this is not true. We would need to create a coherent DMA tag for the top level buses and ensure that this is propagated correctly down to the subordinate buses and devices. > > > > > Nevertheless, for coherent platforms we want bus_dma to always map DMA > memory as normal WBWA regardless of the flags passed to create a bus_dma > MAP. > > For example, we don't want to perform any synchronization and we want t= o > have the cacheable memory regardless of BUS_DMA_COHERENT flag used. > > That=E2=80=99s already the case on arm64, the only synchronisation used w= hen the > tag is created with BUS_DMA_COHERENT is a memory barrier. > For PCI. > > > Otherwise the performance improvement will apply only to those drivers > that dare to use BUS_DMA_COHERENT flag and very few of them does that. In > other words, what is the point of having coherent DMA if you do cache > maintenance anyway? > > The drivers should be getting the parent DMA tag and passing this to > bus_dma_tag_create. If this was created with BUS_DMA_COHERENT it will pas= s > this to the child tag. This is how the above PCI drivers work. > > This basically makes sense to me if we do the same for all buses or once for every platform. The question is how much additional stuff is added to busdma_machdep-v6.c to make it work on all relevant platforms because it is quite different from the ARM64 implementation. Still we can go with the ARM64 approach and add new DMA handling, parallel to the existing one. Improve it over time to handle non-coherent DMA and replace the old one with the new one when it is proven to be correct for all. Kind regards zbb From owner-freebsd-arm@freebsd.org Mon Apr 3 16:42:56 2017 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 AA136D2B015 for ; Mon, 3 Apr 2017 16:42:56 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 6689796A for ; Mon, 3 Apr 2017 16:42:56 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22f.google.com with SMTP id g195so47376567qke.2 for ; Mon, 03 Apr 2017 09:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=3WEtYMbUb55DxBNo+2S/vfsEBLZ0ScCkYaAMeK7Fblo=; b=loJ8PsucC6UvmC0K3u9lHkVapqYvQGrFIyVYH5YZkjSUlGoyuIyTZOSsR51PR19Jhv uxBAw0tPgUfzP72pzKfdiyZyAHgK9Mlqttp7pGcnhFz8fC55KkH0umKB9vx6tbUgP1zE Mn/Y7piEyisvGjWlNUVPK5wiIP/hRvM7sRSa720SMgT6a34foETZ25nQhAkgv4e8Idyg Pj0Zk3Q8x4uf8FVEMlCt/DIaCg2477d6QYZd0kpeSUvDqpcC6RzaW1NDSU1GkwmfEyio qmJE1SxDjejybmMyCJA69FMJm1TAatglrNDgb5IIZulMA/reqbzIfvrvG6MrHTSergXH oISA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=3WEtYMbUb55DxBNo+2S/vfsEBLZ0ScCkYaAMeK7Fblo=; b=IPUANCH8IsZ8C0csm3DfsN9VtWEGVXm1Pj1KWS9hZJcpOORZqFTQRfLALMbDE7A697 A7lvmg810yJLWsCLqVDiNeFJaMX+GSzW1iDZK5P/dsCDNF1nix5wRyDFFz4JgfWOXnsM 8Tpu2sVYZvyaF2DJan1X53umV11h77OyIlC3PaQjOXtahCahpSJSr1Rmuy2KCgjc2nJi JTPgXEpGdtRv/wXH9qR0q5JOT4SKjbNFCww/6SYFUTeD8+3ubdEyJCdbHR5gfthmh4eV VtOVZD6BEoBIfL3PmfEU0nGM0eXK603YalgJyK+UJYYygAacRWz6nosPhpxqEtEnijY0 Y8zg== X-Gm-Message-State: AFeK/H3AsXYX+kfEMZpF+qUOrOm4h7PW4+uGLOpzeJIsiAs20n9/lHgkI8N/nVzOzoJ1jPGqnBdYLguw8RxOPZ2sbG99leN1nVuk3yOd4XV/kqGeTPELZhnRNupCkU3XLANUgx1nrFAIOzX43xuXUPss8Ypg2JmCxJp/hAKyzjXtM7H968Oy2BXyCMRIlWB4/7w= X-Received: by 10.55.183.133 with SMTP id h127mr18108148qkf.121.1491237775441; Mon, 03 Apr 2017 09:42:55 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id z196sm9932658qkb.42.2017.04.03.09.42.54 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Apr 2017 09:42:54 -0700 (PDT) Date: Mon, 3 Apr 2017 12:42:54 -0400 From: Shawn Webb To: freebsd-arm@freebsd.org Subject: Can't link base Message-ID: <20170403164254.erxbtdzqdjl3th54@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="myij2oirkd2nkv33" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:42:56 -0000 --myij2oirkd2nkv33 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Looks like aarch64-binutils 2.28 causes linking issues when building base. LLD 4.0.0 in base can't link aarch64 base, either. /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): R_AARC= H64_ABS64 used with TLS symbol udb /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): R_AARC= H64_ABS64 used with TLS symbol uf /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): R_AARCH64_= ABS64 used with TLS symbol futx_to_utx.ut /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): R_A= ARCH64_ABS64 used with TLS symbol __je_tsd_tls /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x146e): R= _AARCH64_ABS64 used with TLS symbol __je_tsd_initialized /usr/local/aarch64-freebsd/bin/ld: cxa_thread_atexit_impl.pico(.debug_info+= 0x3b): R_AARCH64_ABS64 used with TLS symbol dtors /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): R_AARCH= 64_ABS64 used with TLS symbol __thread_locale /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): R_= AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale cc: error: linker command failed with exit code 1 (use -v to see invocation) --- libc.so.7.full --- *** [libc.so.7.full] Error code 1 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --myij2oirkd2nkv33 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAljie4sACgkQaoRlj1JF bu4Wjg/+I55lE2n+gYV7NaWveRA657tq+U0fS/+jA5U4+fhdMY578r8AfI2iaN65 Fl9NOYQyJFv5j36gMhz+D/K138Mlor6wyN/Lo1Ze1uhEG3BsXLOmSwfwlFEJYUdC 5+Skdp6I42X5lanfJ4M2adm9m96zoN6vA0gQVAVjsa4ojGqZXlxZcrwpbLmuaQzU TjVQLNwqOuPD9bwnWt7QQ1gmY9KWbvAGoElH+PWVJYdfbXh2AgbSJMi+sg1sC4tX ZJ2FYdYDpw6G4rZm5xLzk+dBJO8nLUohFOB2hAtYdtH0OsPAqkakdOtza2WcDLcs 0VCYbII4l9ekjLnSb0AKO3WGNYWW77JEEs3PJenz8By7nC7+udAhvn9E/kUI1GGi rXBqAmXetAkEbQFCj+GSfOlhvwlxetzDCnq7h8FyJc8tUVXgUHWeNQoP3sW5R4lH 7rXlXt5uXCCpgHW9qFB3/DX5/fF+P4u5NWcsLyuC7WMkkHeY2ECddYgaKW0dhhKz aCQPufDnWu5mApYGMbF3rBh3/nIySscch9DLt8AkoUFuD1AyaVkbPOZeKAoEQWvh TNDjggtgQm6Zt8+ypVXW1lhL8ORplZYf9GmZTg0WVjyxlD5dOwInJFUBZJESYw70 kAQLTgzPnnOKQWO/BZG+29fGn3SV2Gd/X4kLJDWwUmFHIjhG3ls= =oPvy -----END PGP SIGNATURE----- --myij2oirkd2nkv33-- From owner-freebsd-arm@freebsd.org Mon Apr 3 17:54:14 2017 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 082A2D2C8D4 for ; Mon, 3 Apr 2017 17:54:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (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 AFE06843 for ; Mon, 3 Apr 2017 17:54:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5736 invoked from network); 3 Apr 2017 17:55:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 Apr 2017 17:55:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 03 Apr 2017 13:54:06 -0400 (EDT) Received: (qmail 22932 invoked from network); 3 Apr 2017 17:54:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Apr 2017 17:54:06 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 66EDDEC8AE2; Mon, 3 Apr 2017 10:54:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Can't link base From: Mark Millard In-Reply-To: <20170403164254.erxbtdzqdjl3th54@mutt-hbsd> Date: Mon, 3 Apr 2017 10:54:04 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <32C50831-55CF-48DC-857F-4E601AE3F9BD@dsl-only.net> References: <20170403164254.erxbtdzqdjl3th54@mutt-hbsd> To: Shawn Webb X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:54:14 -0000 On 2017-Apr-3, at 9:42 AM, Shawn Webb = wrote: > Looks like aarch64-binutils 2.28 causes linking issues when building > base. LLD 4.0.0 in base can't link aarch64 base, either. >=20 > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): = R_AARCH64_ABS64 used with TLS symbol udb > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): = R_AARCH64_ABS64 used with TLS symbol uf > /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): = R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut > /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_tls > /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_initialized > /usr/local/aarch64-freebsd/bin/ld: = cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with = TLS symbol dtors > /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): = R_AARCH64_ABS64 used with TLS symbol __thread_locale > /usr/local/aarch64-freebsd/bin/ld: = setrunelocale.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS = symbol _ThreadRuneLocale > cc: error: linker command failed with exit code 1 (use -v to see = invocation) > --- libc.so.7.full --- > *** [libc.so.7.full] Error code 1 See: Bugzilla 218198 ( = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218198 ) https://lists.freebsd.org/pipermail/freebsd-ports/2017-March/107859.html https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/1433/console Comment 7 of the Bugzilla report from Antoon Yuzhaninov says that 2.27 also generates those messages but returns a zero exit code. 2.28's ld returns a non-zero exit code because of the issue. So the messages are visible even in old logs for WITH_DEBUG contexts. Antoon has been pursuing evidence and has found: https://bugs.llvm.org//show_bug.cgi?id=3D21077 on the llvm side and: = https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;a=3Dcommit;h=3D= 4519d071387f374932616b588ddb4ec8cabe2a52 on the binutils side for the return code change. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Apr 3 22:45:44 2017 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 8654AD2DECC for ; Mon, 3 Apr 2017 22:45:44 +0000 (UTC) (envelope-from ash@aeria.net) Received: from death.aeria.net (death.aeria.net [205.134.176.45]) by mx1.freebsd.org (Postfix) with ESMTP id 65E71E60 for ; Mon, 3 Apr 2017 22:45:43 +0000 (UTC) (envelope-from ash@aeria.net) X-Comment: SPF not applicable to localhost connection - skipped check X-Comment: SPF not applicable to localhost connection - skipped check Received: from localhost (localhost [127.0.0.1]) by death.aeria.net (Postfix) with ESMTP id 5B7BC4E649; Mon, 3 Apr 2017 22:45:37 +0000 (UTC) From: ash To: Oleksandr Tymoshenko Cc: Subject: Re: BBB spi dts follow up Date: Mon, 03 Apr 2017 22:45:36 +0000 MIME-Version: 1.0 Message-ID: <7d96caf9-b9a2-4b2b-8d5d-e9925be7c95d@aeria.net> In-Reply-To: <20170401231324.GA50794@bluezbox.com> References: <3b095b47-f3fb-488f-92f3-518e69d282c1@aeria.net> <20170401231324.GA50794@bluezbox.com> Organization: aeria User-Agent: Trojita Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:45:44 -0000 On Saturday, 1 April 2017 23:13:24 UTC, Oleksandr Tymoshenko wrote: > ash (ash@aeria.net) wrote: >> I decompiled the stock dts to get started with: >>=20 >> #dtc -I dtb -O dts /boot/dtb/beaglebone-black.dtb > ... skipped ... >> But still no /dev/spi0 device. Any pointers are welcome. > There is no /dev/spi0 in FreeBSD at the moment. The only > way to access SPI from userland is by using spigen device. > With later HEAD builds (post r314934) you can load it as > a module: "kldload spigen" otherwise you'll need to add it > to kernel config as a "device spigen". > > spigen functionality is very limited, you can't specify > SPI mode or CS line. General procedure is to open > /dev/spigen0 with O_RDWR and then use ioctls to transfer > data. You can use this example as a simple reference: > > https://github.com/gonzoua/freebsd-embedded-demos/blob/master/libssd1306/ss= d1306_spi.c#L86 > #kldload /dtmp/spigen.ko =20 :root:~:22:40:48:468beaglebone spigen0: at cs 0 mode 0 on spibus0 *grin* Thank you so much.=20 --=20 -ash From owner-freebsd-arm@freebsd.org Tue Apr 4 06:33:18 2017 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 E4CBFD2DE73 for ; Tue, 4 Apr 2017 06:33:18 +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 BB3CF979 for ; Tue, 4 Apr 2017 06:33:18 +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 v346XIIo056908 for ; Tue, 4 Apr 2017 06:33:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 218344] No more /dev/mmc entry on Raspberry Pi 2 Date: Tue, 04 Apr 2017 06:33:18 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sylvain@sylvaingarrigues.com 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 06:33:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218344 Bug ID: 218344 Summary: No more /dev/mmc entry on Raspberry Pi 2 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: sylvain@sylvaingarrigues.com Hello, I have no /dev/mmc entry with vanilla 12-CURRENT GENERIC arm kernel as of today. I added bootverbose option in config and below is the sdhci output, in case= it will help you. sdhci_bcm0: mem 0x300000-0x3000ff irq 27 on simplebus0 sdhci_bcm0: SDHCI frequency: 250MHz sdhci_bcm0-slot0: 250MHz HS 4bits VDD: 3.3V 1.8V VCCQ: 3.3V DRV: B PIO sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUMP = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version: 0x00009902 sdhci_bcm0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_bcm0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_bcm0-slot0: Present: 0x1fff0000 | Host ctl: 0x00000000 sdhci_bcm0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci_bcm0-slot0: Timeout: 0x00000000 | Int stat: 0x00000040 sdhci_bcm0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2: 0x00000000 sdhci_bcm0-slot0: Caps: 0x00000000 | Caps2: 0x00000000 sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr: 0x00000000 | Slot int: 0x00000001 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Apr 4 11:44:36 2017 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 2730AD2DE6A for ; Tue, 4 Apr 2017 11:44:36 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh601-vm4.bullet.mail.ssk.yahoo.co.jp (nh601-vm4.bullet.mail.ssk.yahoo.co.jp [182.22.90.13]) by mx1.freebsd.org (Postfix) with SMTP id B684EC91 for ; Tue, 4 Apr 2017 11:44:35 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.103] by nh601.bullet.mail.ssk.yahoo.co.jp with NNFMP; 04 Apr 2017 11:42:50 -0000 Received: from [182.22.91.129] by t601.bullet.mail.ssk.yahoo.co.jp with NNFMP; 04 Apr 2017 11:42:50 -0000 Received: from [127.0.0.1] by omp602.mail.ssk.yahoo.co.jp with NNFMP; 04 Apr 2017 11:42:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 690932.57820.bm@omp602.mail.ssk.yahoo.co.jp Received: (qmail 4861 invoked by uid 60001); 4 Apr 2017 11:42:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1491306170; bh=y2pVv00gL6eq7vQvwu+6SSzogvIYOJcevAOsq9SHyNg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XeKcKb+8Qzrr0BWSTKbUDDduom4gRxIqcDo9Hg6GjVaTgkgHVyiNyn6ITXAaL0HvctlLqjjWzOlejiENp4oZEcWG17oQKRPMIEDizCNaAlBLjtZpnU9tSETGhA/CEkxokpeaomLcohiVkWENfwEXevrZh4fzeNzh2izY3fuNKUA= 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:Content-Transfer-Encoding; b=MnUoy+AUd8x91ebz8N/Sf/RKEgfWUKcBihmNwjZGGeNuQThiTkF4NPiTGLzCb9GIHwo4HiNm9OpXMDXsJ999smsBiAdpBon1Bt34/cOXLTmw1ybUq+5A0Tpmy+BkYpK1MqaiR2q1oErRHm4WPwzG78HTeua8W+FHVPLyaLffB+s=; Message-ID: <622336.93399.qm@web101714.mail.ssk.yahoo.co.jp> X-YMail-OSG: FllGVU8VM1mi7UkhJhkqjxO19XEkk5dAXKEw2V6ceaRE7DD.JgzNFtX7UJTcq8Ur09v7Z3CvWE65lTgF1F79KpJPOcwR_C4K8jvx2_UCCtO5yqZiWkdayx0w3DS_kV.eN7BHhWq6a8advs3za7YMlYCe.61l.r5UnPV6CRqR7Nx3PE8aTStjS3TDo5rLV24soGLYHNAkDBfkCTZ68ed5srzIOMxKUT3.q57EMX3CMZFW_pmvczaVcIINDL.nUAcQg4mqWNtXM.LhzsoBafjAecQP8iuo3YziZV7oOm.M58btXTDRaUyWGOnPBQy4RLWIi1qP2auQ2Gq5c1y5p4KHAc7xXK7wDplS9N13SIDRHfFj1CTtigKfChQY1OyWzE8BoQIh05301CjpVNwFt4ByUfT0Q7rK5Q5CQg7imoPnmqhGTWkJcv8_NU_QygT_vvmh2HBtYe7H4tdFY9k4ahxGmfXfXwIe419kc818bDOYyUaIdRgSLGRLF05GokV2CGGzJiMvrHGkDaZCJbTxZjOX77OwG0RhY3EOBcgyFhmh4EYX5VRX1RGz3ZQOs2gOjt9LNxnfi04Chof55QWiyYSAgPIsgAyeJS7bRhrHc84ZcA-- Received: from [210.20.198.8] by web101714.mail.ssk.yahoo.co.jp via HTTP; Tue, 04 Apr 2017 20:42:50 JST X-Mailer: YahooMailWebService/0.8.111_70 X-YMail-JAS: 7YulL2kVM1m_LjdydUItjhQhoo67A7Smm24dZOQq6DsEwhyQCKoAoH6s7mtUoId2KydALqzKnsZ.NNQfbDdwRMl4s47Hdg9PDK.97h7fJwOxTDVlo2PPhFWjk5ecTSeHVbws Date: Tue, 4 Apr 2017 20:42:50 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Can't use mge on 88F5181 To: "freebsd-arm@freebsd.org" 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 11:44:36 -0000 Hi.=0A=0AI try to use=A0Buffalo WZR-AMPG300NH. This module have=A088F5181 a= nd=A088E6131.=0AI modify dev/mge and dev/etherswitch/e600sw/e6000sw.c.=0A= =0ANetwork interface mge is detect but not work. Switch port is work by=0Ap= ort vlan. But=A0CPU connected port3 is nothing trans and receive packet.=0A= =0AI check marvell code but not fix this problem.=0A=0AIf you have advice, = please let me know.=0A=0A=0AThis is dmesg.=0A=0Ahttps://gist.github.com/yam= ori813/ecd5df1b314053a73f310c1122775540=0A=0A=0AThanks.=0A=0AHiroki Mori From owner-freebsd-arm@freebsd.org Tue Apr 4 12:21:35 2017 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 41E73D2D41C for ; Tue, 4 Apr 2017 12:21:35 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 043A19BD for ; Tue, 4 Apr 2017 12:21:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6A4312071A for ; Tue, 4 Apr 2017 08:21:33 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 04 Apr 2017 08:21:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=tSbg95wCqWV+TOMPrV BxpGA95pdm1w4xKUytAe82K/w=; b=rUQpXi/ragOpSGUkRRkpoynNUAozHDaRu6 FSqB6EFCZvN6EiJefwxkcpL/sipjmK/5WABWhe+PIoihiqFKXC4JsEdPRMzWxKHI 3yDVvztm2+f3Wd3IPKB0nzKfDw6jVr9svTGbEI5a2gc7uWAV8dNdGoZ7qy3QIJ21 jZf5xe916F1gpcMkMVoSw1wfRGqVNAVkVHgjPJUl0qf291VcyaYLL2lynOK3Na5D D327/anF2Jc9jx+nwyplKI/Oz7jLmtu91TIyutmOjYJwL6mEw2j2JnyfE1lakOuK 15hEiKPFo+jrg1Bv0GLTYjgk289eTcs1PP8707QCaER13EezCEYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=tSbg95wCqWV+TOMPrVBxpGA95pdm1w4xKUytAe82K/w=; b=orCT9ovl u1dj04afAl1334uAfyDKUstkq0rO2pjGK8XGHfbcCXaie5wamijiQEzRFc3nOnYJ wveVQeVtBed38QIf1GUxAcr42vJ5P6/3Dq8D2tPwB0m5UTgfEFOxDTjZEPIwna/n /nFclSAOU4QaPnkl4GWLExxgMbW5lTOszDVqbW9dIynQGFbVJnAmEN+V0cWrpmSy AmYX2NG01+fZUJy5lc3RdswM7fx7lt8DdoMSczCQStR9NhsEU/6H6iZfILpu2C86 pPUCWPwS2Ypke79Kvu9+qQ862s8vVzLHbqnPoYk8K9dC/gkyDB+X97l7dQp4z+Px sBXLSo/X87zCpA== X-ME-Sender: X-Sasl-enc: R0UpEAyjNthi9sgKzZrcv2IWmgFeOj+I2awJ4TramK0f 1491308493 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A0E57E168 for ; Tue, 4 Apr 2017 08:21:32 -0400 (EDT) Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' To: freebsd-arm@freebsd.org References: <20170310184210.GA38002@www.zefox.net> From: tech-lists Message-ID: <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> Date: Tue, 4 Apr 2017 13:21:32 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170310184210.GA38002@www.zefox.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:21:35 -0000 On 10/03/2017 18:42, bob prohaska wrote: > > After a successful build of > FreeBSD 12.0-CURRENT (RPI2) #5 r314923: Fri Mar 10 09:03:07 PST 2017 > > the next attempt at updating sources produced: > > svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' > > Trying > > root@www:/usr/src # svnlite info . > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 314923 > Node Kind: directory > Schedule: normal > Last Changed Author: avos > Last Changed Rev: 314923 > Last Changed Date: 2017-03-08 14:49:22 -0800 (Wed, 08 Mar 2017) > > root@www:/usr/src # svnlite status . > ? buildkernel.log > ? buildscript > ? buildscript.bak > ? buildworld.log > ? installkernel.log > ? installworld.log > > reveals no very obvious mischief. > > Cleanup didn't have any effect, is there something else to try? > I'd rather not checkout again if it can be avoided, it's very slow. Hi, were you able to fix this? I'm getting the same error on a newly installed freebsd-12 snapshot, also on rpi2 root@rpi-b:/usr/ports # svnlite info . Path: . Working Copy Root Path: /usr/ports URL: https://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 437727 Node Kind: directory Schedule: normal root@rpi-b:/usr/ports # root@rpi-b:/usr/ports # uname -a FreeBSD rpi-b 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315864: Fri Mar 24 02:35:48 UTC 2017 root@releng3.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm -- J. From owner-freebsd-arm@freebsd.org Tue Apr 4 12:30:08 2017 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 42FEDD2D712 for ; Tue, 4 Apr 2017 12:30:08 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 06BECD8B for ; Tue, 4 Apr 2017 12:30:07 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x22d.google.com with SMTP id n21so136871483qta.1 for ; Tue, 04 Apr 2017 05:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=QFdf4N7Vev1gOkxYfkubL+c9LSPtrweipVQ5QdSETAk=; b=DpzlapwHbZ4KlqHhXDGJ0LLTm2WDDo4tzpn70WqLX4ECSCrfW8h6CSPDOJPPXjGsVy K4qjmYLNT0iq/5V7b+cyHhOOrbcVwnckcEQiNMOMNEvPY9r2UvopcqFmVeBnr428Bm+5 6EbO94YiNy+kKHJx9nxWizIK1ME5SPWAJbZM8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QFdf4N7Vev1gOkxYfkubL+c9LSPtrweipVQ5QdSETAk=; b=mHDUZn9y+HbAPAJmVzWThq9gAQeC+/9b7JWkAsk1aI/sgG07tDh9LL23a85fUyZCIq mgg7z9LKjMT3dLy8sJCIbJMXLlNr02th4bNz2UZfymX/yHX2meX06epv+cO14chtI1Sr Ln+tvspE0U6bJuEL6w4LoiAWfT/hqhqvJsBE3KhAb2H2ooXvugqmDk4gRwZMx0pMIpDd sYkPhvYAQk4FKgyIvkfwci5uj8u9+GeY/UUb8o+w2M97yo/kguMfxaXV+wo5JniXyZ9R A3Aqs0aYbL3XLVQj52WeGFCcXLN6jcplwEsiQNMWmaZDXv6Xb/GsLSlljAKs/e83ap/c LZEg== X-Gm-Message-State: AFeK/H1VBcBqKx/su0cE1312wyTyYWYSAyWm245C2G8mjs6Oxx34obzD1FxmZqh78Ur3Mg== X-Received: by 10.200.56.162 with SMTP id f31mr22130462qtc.152.1491309006023; Tue, 04 Apr 2017 05:30:06 -0700 (PDT) Received: from [192.168.43.219] (179-240-166-54.3g.claro.net.br. [179.240.166.54]) by smtp.googlemail.com with ESMTPSA id w35sm11687038qtc.55.2017.04.04.05.30.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 05:30:05 -0700 (PDT) Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' To: freebsd-arm@freebsd.org References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Tue, 4 Apr 2017 09:30:01 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:30:08 -0000 Em 04/04/2017 09:21, tech-lists escreveu: > On 10/03/2017 18:42, bob prohaska wrote: >> After a successful build of >> FreeBSD 12.0-CURRENT (RPI2) #5 r314923: Fri Mar 10 09:03:07 PST 2017 >> >> the next attempt at updating sources produced: >> >> svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' >> >> Trying >> >> root@www:/usr/src # svnlite info . >> Path: . >> Working Copy Root Path: /usr/src >> URL: https://svn0.us-west.freebsd.org/base/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 314923 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: avos >> Last Changed Rev: 314923 >> Last Changed Date: 2017-03-08 14:49:22 -0800 (Wed, 08 Mar 2017) >> >> root@www:/usr/src # svnlite status . >> ? buildkernel.log >> ? buildscript >> ? buildscript.bak >> ? buildworld.log >> ? installkernel.log >> ? installworld.log >> >> reveals no very obvious mischief. >> >> Cleanup didn't have any effect, is there something else to try? >> I'd rather not checkout again if it can be avoided, it's very slow. > Hi, were you able to fix this? I'm getting the same error on a newly > installed freebsd-12 snapshot, also on rpi2 > > root@rpi-b:/usr/ports # svnlite info . > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 437727 > Node Kind: directory > Schedule: normal > > root@rpi-b:/usr/ports # > > root@rpi-b:/usr/ports # uname -a > FreeBSD rpi-b 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315864: Fri Mar 24 > 02:35:48 UTC 2017 > root@releng3.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > > I'm getting the same error with a beaglebone black running HEAD r315864. The workaround was install devel/subversion from packages and run svn instead svnlite. []'s -Otacilio From owner-freebsd-arm@freebsd.org Tue Apr 4 16:09:47 2017 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 3F6C9D2E35B for ; Tue, 4 Apr 2017 16:09:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DD22961 for ; Tue, 4 Apr 2017 16:09:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v34G9mpY087492 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 09:09:49 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v34G9lZw087491; Tue, 4 Apr 2017 09:09:47 -0700 (PDT) (envelope-from fbsd) Date: Tue, 4 Apr 2017 09:09:47 -0700 From: bob prohaska To: Otac??lio Cc: freebsd-arm@freebsd.org Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Message-ID: <20170404160947.GA82658@www.zefox.net> References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:09:47 -0000 On Tue, Apr 04, 2017 at 09:30:01AM -0300, Otac??lio wrote: > Em 04/04/2017 09:21, tech-lists escreveu: > > On 10/03/2017 18:42, bob prohaska wrote: > >> After a successful build of > >> FreeBSD 12.0-CURRENT (RPI2) #5 r314923: Fri Mar 10 09:03:07 PST 2017 > >> > >> the next attempt at updating sources produced: > >> > >> svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' [snip] > I'm getting the same error with a beaglebone black running HEAD r315864. > The workaround was install devel/subversion from packages and run svn > instead svnlite. > I ended up doing the same thing on RPI2, but also changed from https protocol to svn protocol. It's beginning to look as if the use of svn protocol is what fixed it, not the use of svn versus svnlite. hth, bob prohaska From owner-freebsd-arm@freebsd.org Tue Apr 4 16:32:09 2017 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 3C9D6D2EE1A for ; Tue, 4 Apr 2017 16:32:09 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id E3A03A2E for ; Tue, 4 Apr 2017 16:32:08 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from dhcp-10-248-96-130.eduroam.wireless.private.cam.ac.uk (global-5-141.nat-2.net.cam.ac.uk [131.111.5.141]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id B0B2E4E6EC; Tue, 4 Apr 2017 16:32:01 +0000 (UTC) From: Andrew Turner Message-Id: <67707E59-C2F6-4037-80A5-D9EFE7D5F52D@fubar.geek.nz> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Coherent bus_dma for ARMv7 Date: Tue, 4 Apr 2017 17:32:01 +0100 In-Reply-To: Cc: Marcin Wojtas , Adrian Chadd , "freebsd-arm@freebsd.org" To: Zbigniew Bodek References: <0EA39E6B-3460-45B9-8247-CB6CC8631C5F@fubar.geek.nz> <5586A20F-125D-41EC-9741-BBFFDB0A7A38@fubar.geek.nz> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:32:09 -0000 > On 3 Apr 2017, at 15:58, Zbigniew Bodek wrote: >=20 > 2017-04-03 16:37 GMT+02:00 Andrew Turner >: >=20 > > On 3 Apr 2017, at 15:14, Zbigniew Bodek > wrote: > > > > 2017-04-03 15:37 GMT+02:00 Andrew Turner >: > > > > > On 3 Apr 2017, at 14:16, Marcin Wojtas > wrote: > > > > > > Hi Adrian, > > > > > > Frankly we are not such experts in armv6 bus_dma, which looks more > > > complicated than one in arm64, so we thought it's much safer no to = mix > > > the two solutions and leave for the user a single switch to = decide, > > > which one to pick. Afaik Andrew Turner did the oposite for arm64 > > > (implement not coherent solution on top of coherent bus_dma), = however > > > I'm not sure if it's possible here in an easy way - there's also > > > pretty significant risk of regression for all platforms. Please = let me > > > know your opinion. Do you think some sort of update of armv6 is > > > doable? > > > > I don=E2=80=99t see any reason to think it would be difficult to add = support for coherent hardware to the existing armv6 busdma code. It=E2=80=99= s mostly skipping cache operations based on a flag in the dam tag. > > > > Andrew > > > > Hello Andrew, > > > > I don't think anyone uses flags related to DMA coherency in = bus_dma_tag_create. >=20 > The generic PCI and ThunderX PCIe PEM drivers do. The former based on = the FDT dma-coherent flag. >=20 > In this particular example this will work as almost all (not all) = devices on ThunderX are PCIe devices. For most ARMv7-based SoCs this is = not true. We would need to create a coherent DMA tag for the top level = buses and ensure that this is propagated correctly down to the = subordinate buses and devices. You will already need to ensure the property is propagated to children, = although DMA coherency is a property of the device, not the system, e.g. = it is possible for only some devices to be coherent depending on how the = vendor attached them to the internal bus. > =20 >=20 > > > > Nevertheless, for coherent platforms we want bus_dma to always map = DMA memory as normal WBWA regardless of the flags passed to create a = bus_dma MAP. > > For example, we don't want to perform any synchronization and we = want to have the cacheable memory regardless of BUS_DMA_COHERENT flag = used. >=20 > That=E2=80=99s already the case on arm64, the only synchronisation = used when the tag is created with BUS_DMA_COHERENT is a memory barrier. >=20 > For PCI. I have non-PCI devices with coherent DMA, I just haven=E2=80=99t had a = chance to finish testing and upstreaming the patches. > =20 >=20 > > Otherwise the performance improvement will apply only to those = drivers that dare to use BUS_DMA_COHERENT flag and very few of them does = that. In other words, what is the point of having coherent DMA if you do = cache maintenance anyway? >=20 > The drivers should be getting the parent DMA tag and passing this to = bus_dma_tag_create. If this was created with BUS_DMA_COHERENT it will = pass this to the child tag. This is how the above PCI drivers work. >=20 >=20 > This basically makes sense to me if we do the same for all buses or = once for every platform. The question is how much additional stuff is = added to busdma_machdep-v6.c to make it work on all relevant platforms = because it is quite different from the ARM64 implementation. It should just be setting a flag then using it to always allocate = cacheable memory and stop performing cache operations on a sync. It = shouldn=E2=80=99t affect existing platforms as they won=E2=80=99t set = the appropriate flag when creating the tag. >=20 > Still we can go with the ARM64 approach and add new DMA handling, = parallel to the existing one. Improve it over time to handle = non-coherent DMA and replace the old one with the new one when it is = proven to be correct for all. The arm64 approach would be to handle BUS_DMA_COHERENT when creating a = tag, and using this to decide how to correctly sync the DMA memory. The = current code has been well tested on multiple different SoCs. Andrew From owner-freebsd-arm@freebsd.org Tue Apr 4 20:47:14 2017 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 BAF74D2F2AC for ; Tue, 4 Apr 2017 20:47:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-82.reflexion.net [208.70.210.82]) (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 6FA67B80 for ; Tue, 4 Apr 2017 20:47:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4493 invoked from network); 4 Apr 2017 20:20:32 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Apr 2017 20:20:32 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 04 Apr 2017 16:20:32 -0400 (EDT) Received: (qmail 31653 invoked from network); 4 Apr 2017 20:20:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Apr 2017 20:20:32 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A9317EC893D; Tue, 4 Apr 2017 13:20:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' From: Mark Millard In-Reply-To: <20170404160947.GA82658@www.zefox.net> Date: Tue, 4 Apr 2017 13:20:30 -0700 Cc: Otac??lio , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> <20170404160947.GA82658@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:47:14 -0000 On 2017-Apr-4, at 9:09 AM, bob prohaska wrote: > On Tue, Apr 04, 2017 at 09:30:01AM -0300, Otac??lio wrote: >> Em 04/04/2017 09:21, tech-lists escreveu: >>> On 10/03/2017 18:42, bob prohaska wrote: >>>> After a successful build of >>>> FreeBSD 12.0-CURRENT (RPI2) #5 r314923: Fri Mar 10 09:03:07 PST 2017 >>>> >>>> the next attempt at updating sources produced: >>>> >>>> svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' > [snip] > >> I'm getting the same error with a beaglebone black running HEAD r315864. >> The workaround was install devel/subversion from packages and run svn >> instead svnlite. >> > > I ended up doing the same thing on RPI2, but also changed from https > protocol to svn protocol. It's beginning to look as if the use of svn > protocol is what fixed it, not the use of svn versus svnlite. I'd had problems with https/http for some time and so a while back I tried svn protocol instead and the problems stopped. I only used svnlite, not installing svn from ports at all. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Apr 4 22:40:13 2017 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 F052BD2F691 for ; Tue, 4 Apr 2017 22:40:13 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7072EE82 for ; Tue, 4 Apr 2017 22:40:12 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id v34MdwXS087988 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2017 00:39:59 +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 v34Mdu68078998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2017 00:39:56 +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 v34MduYq023295; Wed, 5 Apr 2017 00:39:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v34Mdsum023294; Wed, 5 Apr 2017 00:39:54 +0200 (CEST) (envelope-from ticso) Date: Wed, 5 Apr 2017 00:39:54 +0200 From: Bernd Walter To: Mark Millard Cc: bob prohaska , freebsd-arm@freebsd.org Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Message-ID: <20170404223954.GK16909@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> <20170404160947.GA82658@www.zefox.net> 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=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 22:40:14 -0000 On Tue, Apr 04, 2017 at 01:20:30PM -0700, Mark Millard wrote: > > On 2017-Apr-4, at 9:09 AM, bob prohaska wrote: > > > On Tue, Apr 04, 2017 at 09:30:01AM -0300, Otac??lio wrote: > >> Em 04/04/2017 09:21, tech-lists escreveu: > >>> On 10/03/2017 18:42, bob prohaska wrote: > >>>> After a successful build of > >>>> FreeBSD 12.0-CURRENT (RPI2) #5 r314923: Fri Mar 10 09:03:07 PST 2017 > >>>> > >>>> the next attempt at updating sources produced: > >>>> > >>>> svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' > > [snip] > > > >> I'm getting the same error with a beaglebone black running HEAD r315864. > >> The workaround was install devel/subversion from packages and run svn > >> instead svnlite. > >> > > > > I ended up doing the same thing on RPI2, but also changed from https > > protocol to svn protocol. It's beginning to look as if the use of svn > > protocol is what fixed it, not the use of svn versus svnlite. > > I'd had problems with https/http for some time and so > a while back I tried svn protocol instead and the problems > stopped. > > I only used svnlite, not installing svn from ports at all. Different problem, but I've switched to a local svn mirror because svn couldn't handle service timeout disconnections when writing to SD card. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Apr 5 00:37:52 2017 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 A9946D2CB9A for ; Wed, 5 Apr 2017 00:37:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 276C8140 for ; Wed, 5 Apr 2017 00:37:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v350bjlq089154 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 17:37:46 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v350bhlE089153; Tue, 4 Apr 2017 17:37:43 -0700 (PDT) (envelope-from fbsd) Date: Tue, 4 Apr 2017 17:37:42 -0700 From: bob prohaska To: ticso@cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Message-ID: <20170405003742.GA88592@www.zefox.net> References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> <20170404160947.GA82658@www.zefox.net> <20170404223954.GK16909@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170404223954.GK16909@cicely7.cicely.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 00:37:52 -0000 On Wed, Apr 05, 2017 at 12:39:54AM +0200, Bernd Walter wrote: > > Different problem, but I've switched to a local svn mirror because svn > couldn't handle service timeout disconnections when writing to SD card. > FWIW: Moving /usr to a usb3 flash drive solved that problem for me. bob prohaska From owner-freebsd-arm@freebsd.org Wed Apr 5 01:13:06 2017 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 51F53D2D7CE for ; Wed, 5 Apr 2017 01:13:06 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C5D889C0 for ; Wed, 5 Apr 2017 01:13:05 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id v351D0AS091017 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2017 03:13:01 +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 v351CmHZ082852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2017 03:12:48 +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 v351Cm8v024012; Wed, 5 Apr 2017 03:12:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v351CmBT024011; Wed, 5 Apr 2017 03:12:48 +0200 (CEST) (envelope-from ticso) Date: Wed, 5 Apr 2017 03:12:48 +0200 From: Bernd Walter To: bob prohaska Cc: ticso@cicely.de, freebsd-arm@freebsd.org Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Message-ID: <20170405011246.GL16909@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> <20170404160947.GA82658@www.zefox.net> <20170404223954.GK16909@cicely7.cicely.de> <20170405003742.GA88592@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170405003742.GA88592@www.zefox.net> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 autolearn=unavailable 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 01:13:06 -0000 On Tue, Apr 04, 2017 at 05:37:42PM -0700, bob prohaska wrote: > On Wed, Apr 05, 2017 at 12:39:54AM +0200, Bernd Walter wrote: > > > > Different problem, but I've switched to a local svn mirror because svn > > couldn't handle service timeout disconnections when writing to SD card. > > > > FWIW: > > Moving /usr to a usb3 flash drive solved that problem for me. Yes - there is some idle timeout somewhere with the official FreeBSD svn servers, which is too short for those super high write times with SD cards. But annoyingly svn not just terminates instead of reconnecting - it leaves the workdirectory in an unclean state requiring an svn cleanup rung, which by itself can be ultra slow on SD cards. Really not funny at all for /usr/ports. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Apr 5 01:50:36 2017 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 6D008D2E46F for ; Wed, 5 Apr 2017 01:50:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47FFED72 for ; Wed, 5 Apr 2017 01:50:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v351oe7u089373 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 18:50:41 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v351odvR089372; Tue, 4 Apr 2017 18:50:39 -0700 (PDT) (envelope-from fbsd) Date: Tue, 4 Apr 2017 18:50:39 -0700 From: bob prohaska To: ticso@cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Message-ID: <20170405015039.GB88592@www.zefox.net> References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> <20170404160947.GA82658@www.zefox.net> <20170404223954.GK16909@cicely7.cicely.de> <20170405003742.GA88592@www.zefox.net> <20170405011246.GL16909@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170405011246.GL16909@cicely7.cicely.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 01:50:36 -0000 On Wed, Apr 05, 2017 at 03:12:48AM +0200, Bernd Walter wrote: > > Yes - there is some idle timeout somewhere with the official FreeBSD > svn servers, which is too short for those super high write times with > SD cards. > But annoyingly svn not just terminates instead of reconnecting - it > leaves the workdirectory in an unclean state requiring an svn cleanup > rung, which by itself can be ultra slow on SD cards. > Really not funny at all for /usr/ports. Agreed entirely. That's what motivated me to buy Sandisk Extreme USB 3.0 flash drives. As an aside, I think using the very same grade of microSD cards (not outrageously expensive) solved, or mostly solved, the problem when using a single large filesystem on one microSD with no usb drives at all. That particular system is disturbed as little as possible, so its subversion performance isn't well-explored. bob prohaska From owner-freebsd-arm@freebsd.org Wed Apr 5 03:00:49 2017 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 832CFD2FE9E for ; Wed, 5 Apr 2017 03:00:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-81.reflexion.net [208.70.210.81]) (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 48754CAC for ; Wed, 5 Apr 2017 03:00:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24798 invoked from network); 5 Apr 2017 03:00:47 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Apr 2017 03:00:47 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 04 Apr 2017 23:00:47 -0400 (EDT) Received: (qmail 14817 invoked from network); 5 Apr 2017 03:00:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Apr 2017 03:00:47 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 83DDCEC88F3; Tue, 4 Apr 2017 20:00:46 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them Message-Id: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> Date: Tue, 4 Apr 2017 20:00:45 -0700 To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 03:00:49 -0000 Uncommenting/commenting parts of the below program allows exploring the problems with fork-then-swap-out-then-in on arm64. Note: By swap-out I mean that zero RES(ident memory) results, for the process(s) of interest, as shown by "top -PCwaopid" . I discovered recently that swapping-out just before the fork() prevents the failure from the swapping after the fork(). Note: Without the fork() no problem happens. Without the later swap-out no problem happens. Both are required. But some activities before the fork() or between fork() and the swap-out prevent the failures. Some of the comments are based on a pine64+ 2GB context. I use stress to force swap-outs during some sleeps in the program. See also Buzilla 217239 and 217138. (I now expect that they have the same cause.) In my environment I've seen the fork-then-swap-out/swap-in failures on a pine64+ 2GB and a rpi3. They are repeatable on both. I do not have access to server-class machines, or any other arm64 machines. // swap_testing5.c // Built via (cc was clang 4.0 in my case): // // cc -g -std=3Dc11 -Wpedantic -o swaptesting5 swap_testing5.c // -O0 and -O2 also gets the problem. // Note: jemalloc's tcache needs to be enabled to get the failure. // But FreeBSD can get into a state were /etc/malloc.conf // -> 'tcache:false' is ineffective. Also: the allocation // size needs to by sufficiently small (<=3D SMALL_MAXCLASS) // to see the problem. Other comments are based on a specific // context (pine64+ 2GB). #include // for raise(.), SIGABRT (induce core dump) #include // for fork(), sleep(.) #include // for pid_t #include // for wait(.) extern void test_setup(void); // Sets up the memory byte = patterns. extern void test_check(void); // Tests the memory byte patterns. extern void memory_willneed(void); // For seeing if // = posix_madvise(.,.,POSIX_MADV_WILLNEED) // makes a difference. int main(void) { sleep(30); // Potentialy force swap-out here. // [Swap-out here does not avoid later failures.] test_setup(); test_check(); // Before potential sleep(.)/swap-out or fork(.) = [passes] sleep(30); // Potentialy force swap-out here. // [Everything below passes if swapped-out here, // no matter if there are later swap-outs // or not.] pid_t pid =3D fork(); // To test no-fork use: =3D 0; no-fork does = not fail. int wait_status =3D 0; // HERE: After fork; before sleep/swap-out/wait. // if (0 < pid) memory_willneed(); // Does not prevent either = parent or // child failure if enabled. // if (0 =3D=3D pid) memory_willneed(); // Prevents both the parent = and the // child failure. Disable to see // failure of both parent and = child. // [Presuming no prior swap-out: = that // would make everything pass.] // During sleep/wait: manually force this process to // swap out. I use something like: // stress -m 1 --vm-bytes 1800M // in another shell and ^C'ing it after top shows the // swapped status desired. 1800M just happened to work // on the Pine64+ 2GB that I was using. I watch with // top -PCwaopid [checking for zero RES(ident memory)]. if (0 < pid) { sleep(30); // Intend to swap-out during sleep. // test_check(); // Test in parent before child runs (longer = sleep). // This test fails if run for a failing = region_size // unless earlier preventing-activity happened. wait(&wait_status); // Only if test_check above passes or is // disabled above. } if (-1 !=3D wait_status && 0 <=3D pid) { if (0 =3D=3D pid) { sleep(90); } // Intend to swap-out during = sleep. test_check(); // Fails for small-enough region_size, both // parent and child processes, unless earlier // preventing-activty happened. } } // The memory and test code follows. #include // for size_t, NULL #include // for malloc(.), free(.) #include // for POSIX_MADV_WILLNEED, posix_madvise(.,.,.) #define region_size (14u*1024u) // Bad dyn_region pattern, parent and child processes examples: // 256u, 2u*1024u, 4u*1024u, 8u*1024u, 9u*1024u, 12u*1024u, = 14u*1024u // No failure examples: // 14u*1024u+1u, 15u*1024u, 16u*1024u, 32u*1024u, = 256u*1024u*1024u #define num_regions (256u*1024u*1024u/region_size) typedef volatile unsigned char value_type; struct region_struct { value_type array[region_size]; }; typedef struct region_struct region; static region * volatile dyn_regions[num_regions] =3D {NULL,}; static value_type value(size_t v) { return (value_type)((v&0xFEu)|0x1u); = } // value avoids zero values: the bad values are zeros. void test_setup(void) { for(size_t i=3D0u; i 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 8FC86D2E2A9 for ; Wed, 5 Apr 2017 10:22:20 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 1AB2C6A7 for ; Wed, 5 Apr 2017 10:22:20 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by mail-lf0-x230.google.com with SMTP id x137so4874944lff.3 for ; Wed, 05 Apr 2017 03:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e8nYgqKVD5Q6RbTr9nXMV4NniR5SdOzfsF6gtnQwVd8=; b=PfGXXZITAHTmPiiRXaUfYQW4wVypjEZZBCl35AJVN+UKC49f62Hklb0NrEopI1S8WO 0vPEn73QycfkwBRP+JFq85F3AWkkRo49joFH19hOpmKDqU6HW5k6NlyBczD3XPBv+p7G kcKOPOXYcs3Q/ZZE+twnRWh1dKK3ssexjyZ6Bjkzr7xl75LUYWfckVN/efD6CS9wzjUl F/u0Vhlnqo3J5PLBCajSCOZXogyHZOHdreXXQnXu/W3Cr5xDs3dr+VOCyYbBxTR20kve n/ZdQGwUtMTIKEWaAtFPKddpUhmgZMYrTxjWLc49v2mxBFAOFLac+LUBOf9ZLZuWvpKe jxCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e8nYgqKVD5Q6RbTr9nXMV4NniR5SdOzfsF6gtnQwVd8=; b=BQ9pZBUThXyXfHeja6YUCXwyxhqD8mveKVxwkHzOmgMP9HXHHSvMBm0VvSbbL+GkA+ fCOMJ0HnHWFNp4RXRXmEARW38gegoJoeawmEOPD7/RK6zHa5YswTXCQZZeXax9MxgRuw aPk3NdHilzv+MRxfigaXVLQne9jA1wfRQbQY8MUkTbyhxrWMo89N+JkCWSHn4e4zZJlJ kO92Lu1ip2gLLO3IQyzZNkjl5ikDPRKe+YMTZ8UVjsGDe5k6ZYy7DkfPqw1GUY6X2cHG R4zQWQxbsfHUhcnOtuUPpEazZs7MTyVQdzu+AQjWyMf+BddWrFwZ6vXPO09Zmrs3Xb6s F9mw== X-Gm-Message-State: AFeK/H2HW9UVwO7xOeTOpXB3tQnVoaiBc3WawsfSDkO18UhNwTlVO2PXf+8fw+Iu6+I4A7uDO7ta4yB4nBAFyg== X-Received: by 10.46.33.164 with SMTP id h36mr7165121lji.57.1491387738023; Wed, 05 Apr 2017 03:22:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.181.220 with HTTP; Wed, 5 Apr 2017 03:21:57 -0700 (PDT) In-Reply-To: <67707E59-C2F6-4037-80A5-D9EFE7D5F52D@fubar.geek.nz> References: <0EA39E6B-3460-45B9-8247-CB6CC8631C5F@fubar.geek.nz> <5586A20F-125D-41EC-9741-BBFFDB0A7A38@fubar.geek.nz> <67707E59-C2F6-4037-80A5-D9EFE7D5F52D@fubar.geek.nz> From: Zbigniew Bodek Date: Wed, 5 Apr 2017 12:21:57 +0200 Message-ID: Subject: Re: Coherent bus_dma for ARMv7 To: Andrew Turner Cc: Marcin Wojtas , Adrian Chadd , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 10:22:20 -0000 2017-04-04 18:32 GMT+02:00 Andrew Turner : > > On 3 Apr 2017, at 15:58, Zbigniew Bodek wrote: > > 2017-04-03 16:37 GMT+02:00 Andrew Turner : > >> >> > On 3 Apr 2017, at 15:14, Zbigniew Bodek wrote: >> > >> > 2017-04-03 15:37 GMT+02:00 Andrew Turner : >> > >> > > On 3 Apr 2017, at 14:16, Marcin Wojtas wrote: >> > > >> > > Hi Adrian, >> > > >> > > Frankly we are not such experts in armv6 bus_dma, which looks more >> > > complicated than one in arm64, so we thought it's much safer no to m= ix >> > > the two solutions and leave for the user a single switch to decide, >> > > which one to pick. Afaik Andrew Turner did the oposite for arm64 >> > > (implement not coherent solution on top of coherent bus_dma), howeve= r >> > > I'm not sure if it's possible here in an easy way - there's also >> > > pretty significant risk of regression for all platforms. Please let = me >> > > know your opinion. Do you think some sort of update of armv6 is >> > > doable? >> > >> > I don=E2=80=99t see any reason to think it would be difficult to add s= upport >> for coherent hardware to the existing armv6 busdma code. It=E2=80=99s mo= stly >> skipping cache operations based on a flag in the dam tag. >> > >> > Andrew >> > >> > Hello Andrew, >> > >> > I don't think anyone uses flags related to DMA coherency in >> bus_dma_tag_create. >> >> The generic PCI and ThunderX PCIe PEM drivers do. The former based on th= e >> FDT dma-coherent flag. >> > > In this particular example this will work as almost all (not all) devices > on ThunderX are PCIe devices. For most ARMv7-based SoCs this is not true. > We would need to create a coherent DMA tag for the top level buses and > ensure that this is propagated correctly down to the subordinate buses an= d > devices. > > > You will already need to ensure the property is propagated to children, > although DMA coherency is a property of the device, not the system, e.g. = it > is possible for only some devices to be coherent depending on how the > vendor attached them to the internal bus. > > > >> >> > >> > Nevertheless, for coherent platforms we want bus_dma to always map DMA >> memory as normal WBWA regardless of the flags passed to create a bus_dma >> MAP. >> > For example, we don't want to perform any synchronization and we want >> to have the cacheable memory regardless of BUS_DMA_COHERENT flag used. >> >> That=E2=80=99s already the case on arm64, the only synchronisation used = when the >> tag is created with BUS_DMA_COHERENT is a memory barrier. >> > > For PCI. > > > I have non-PCI devices with coherent DMA, I just haven=E2=80=99t had a ch= ance to > finish testing and upstreaming the patches. > > > >> >> > Otherwise the performance improvement will apply only to those drivers >> that dare to use BUS_DMA_COHERENT flag and very few of them does that. I= n >> other words, what is the point of having coherent DMA if you do cache >> maintenance anyway? >> >> The drivers should be getting the parent DMA tag and passing this to >> bus_dma_tag_create. If this was created with BUS_DMA_COHERENT it will pa= ss >> this to the child tag. This is how the above PCI drivers work. >> >> > This basically makes sense to me if we do the same for all buses or once > for every platform. The question is how much additional stuff is added to > busdma_machdep-v6.c to make it work on all relevant platforms because it = is > quite different from the ARM64 implementation. > > > It should just be setting a flag then using it to always allocate > cacheable memory and stop performing cache operations on a sync. It > shouldn=E2=80=99t affect existing platforms as they won=E2=80=99t set the= appropriate flag > when creating the tag. > > > Still we can go with the ARM64 approach and add new DMA handling, paralle= l > to the existing one. Improve it over time to handle non-coherent DMA and > replace the old one with the new one when it is proven to be correct for > all. > > > The arm64 approach would be to handle BUS_DMA_COHERENT when creating a > tag, and using this to decide how to correctly sync the DMA memory. The > current code has been well tested on multiple different SoCs. > > Hello Andrew, Thanks for the elaborated response. Please send your patches and we will base on that then on armv7. Kind regards zbb From owner-freebsd-arm@freebsd.org Wed Apr 5 11:01:45 2017 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 E5B19D2EE08 for ; Wed, 5 Apr 2017 11:01:45 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 B2C629E1 for ; Wed, 5 Apr 2017 11:01:45 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cviRv-0000L7-GR for freebsd-arm@freebsd.org; Wed, 05 Apr 2017 12:46:03 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Date: Wed, 05 Apr 2017 12:46:01 +0200 Subject: newfs_nandfs compile error 11-STABLE MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 76f3589a93270604ea078d468a2051b3 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 11:01:46 -0000 Hi, I'm building 11-STABLE for SHEEVAPLUG on a 12-CURRENT/amd64. I get this compile error. How can I resolve this without a clean build? I would like to prevent recompiling llvm for 12 hours. --- newfs_nandfs.o --- cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o -std=gnu99 -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 -Wcast-align -Wchar-subscripts -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-arm/sbin/newfs_nandfs/newfs_nandfs.c -o newfs_nandfs.o /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking address of packed member 'f_uuid' of class or structure 'nandfs_fsdata' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member] uuidgen(&fsdata.f_uuid, 1); ^~~~~~~~~~~~~ 1 error generated. *** [newfs_nandfs.o] Error code 1 make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs 1 error make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs *** [all_subdir_sbin/newfs_nandfs] Error code 2 Do I have to clean and rebuild some specific library? Or something else? Regards, Ronald. From owner-freebsd-arm@freebsd.org Wed Apr 5 11:44:18 2017 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 87F39D2FEE2 for ; Wed, 5 Apr 2017 11:44:18 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 5B074762 for ; Wed, 5 Apr 2017 11:44:17 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EC60320B4E for ; Wed, 5 Apr 2017 07:44:10 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute4.internal (MEProxy); Wed, 05 Apr 2017 07:44:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=qlUIfoYpwGaVz8bfCYR8FlNN2q7Ac jjysKVfILa9XYA=; b=eaG7vvJoMgkKz5oQDWaG+SvMWGNPeumOl4YAp7afHaUb4 ttdX6L7943Y5qmr80p8xH1Qkpqcq9LYyOfzLd++v2Uk1Vb/DsbegWMT1ZdCgFmvS 32GtaFIffqjI6xzrYTDF8zqrZmPKW75EywRch+oXSthVgoU87/k3KKI/9AlFH0FF hRfLvje8YYXP9VH64TVLGEhjlDiIAARah0gcy4V3BB4cc2VaXpVYdD4CFde43+8I EuRqIszLBslP8d7TSKg87/Rkyzxbk5aKNW7/nQHDU5jfS/aM2MgvnX/K2NHgBcBG txPj3SOG7RKEqTgkb4lZn86vJ5SUx2VxHxCL35+lg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qlUIfo YpwGaVz8bfCYR8FlNN2q7AcjjysKVfILa9XYA=; b=aSQSWg9eVbqvTRMGByliNA jyZhGgVewNgcOYdUV3qAtF7kx8KxJR52w1rRLHmiBTcZYOYPiyI7ljPCZt3O7XJU GkeIbDqq9h9WF8yH32GHw23mQE4r5cLVvQAPEUT39HviLMtheWL5iY9Ow+NgBHzD RuAS3XNMrPGJ+VTEZt1Rn9Hbu8V3JEB1sidi7P6IGPPUKLnpEDwi7+W0ib/sKPo3 Sb479+3oLSSLdmAOkUs8Ppm0timPO6HcwKU4UKFy3hJfh38hJtbh1E6nvjDZYcHj gHjDUknyiNccwJGXpPQIIQFviDwJUTEayTx9zjLdLdAQt0vp9rXbxBKPJkXe2WZA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C87F248006; Wed, 5 Apr 2017 07:44:10 -0400 (EDT) Message-Id: <1491392650.3858180.934910232.6B42D704@webmail.messagingengine.com> From: John To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-8e6aa83c Subject: Re: svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' Date: Wed, 05 Apr 2017 12:44:10 +0100 In-Reply-To: <20170404223954.GK16909@cicely7.cicely.de> References: <20170310184210.GA38002@www.zefox.net> <26fa7189-fd35-cdb4-ccfc-5ba623be9e59@zyxst.net> <20170404160947.GA82658@www.zefox.net> <20170404223954.GK16909@cicely7.cicely.de> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 11:44:18 -0000 On Tue, 4 Apr 2017, at 23:39, Bernd Walter wrote: > Different problem, but I've switched to a local svn mirror because svn > couldn't handle service timeout disconnections when writing to SD card. As a general rule I move all fs/dirs where there's expected to be lots of read/write activity to either a usb3 stick, or one of those usb-powered spinning rust disks. Even though on the Pi, the interface is only usb2, for some reason using usb3-capable storage is more pain-free than something strictly usb2. I don't know why. I only get the problem you're describing with usb2 disks. So, on the usb3 key or disk I mount the following, before updating kernel world or building anything from ports: /ccache /var/log /usr/ports /usr/src /usr/obj /tmp /usr/home swap partition /var/tmp is a small mfs. -- J. tech-lists@zyxst.net From owner-freebsd-arm@freebsd.org Wed Apr 5 15:31:44 2017 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 56C3CD2F6B2 for ; Wed, 5 Apr 2017 15:31:44 +0000 (UTC) (envelope-from norman@astro.gla.ac.uk) Received: from smtp77.ord1c.emailsrvr.com (smtp77.ord1c.emailsrvr.com [108.166.43.77]) (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 37769C41 for ; Wed, 5 Apr 2017 15:31:43 +0000 (UTC) (envelope-from norman@astro.gla.ac.uk) Received: from smtp2.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 7DC63C01CC; Wed, 5 Apr 2017 11:26:05 -0400 (EDT) X-Auth-ID: astro@nxg.name Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: astro-AT-nxg.name) with ESMTPSA id 23AD4C0418; Wed, 5 Apr 2017 11:26:04 -0400 (EDT) X-Sender-Id: astro@nxg.name Received: from [130.209.45.140] (ptolemy.astro.gla.ac.uk [130.209.45.140]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256) by 0.0.0.0:587 (trex/5.7.12); Wed, 05 Apr 2017 11:26:05 -0400 From: "Norman Gray" To: freebsd-arm@freebsd.org Subject: SoC with multiple ethernet ports Date: Wed, 05 Apr 2017 16:26:02 +0100 Message-ID: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:31:44 -0000 Greetings. I'm looking for a SoC (or other small) machine to act as a gateway between two physical networks (in fact, an ordinary one and an IPMI). Thus I'm looking for such a device which has at least two ethernet interfaces, and can run FreeBSD. There are multiple boards listed at , but the boards under the 'Well supported boards' headings appear only to have single interfaces (though I wouldn't claim an exhaustive search). I can see what appear to be nice multiple-interface boards at , but they're listed under 'unknown support'. I can see some notes on some Marvell boards at , but these refer to FreeBSD 8.x and 9-CURRENT, so are clearly not up-to-date. Searching the list archives, I find that at least some people are using 11.0-CURRENT on an Armada/Marvell board, but (given that that's a bug report) I'm not sure if that usage counts as ...Brave or not. There's clearly a lot of hardware possibilities here, but I surely can't be the first person to want such a device. Does anyone on this list have any advice? Best wishes, Norman -- Norman Gray : https://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From owner-freebsd-arm@freebsd.org Wed Apr 5 15:37:03 2017 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 2A4A3D2F7EF for ; Wed, 5 Apr 2017 15:37:03 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 F38ADF8A for ; Wed, 5 Apr 2017 15:37:02 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2E02720961 for ; Wed, 5 Apr 2017 11:37:01 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute4.internal (MEProxy); Wed, 05 Apr 2017 11:37:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=eCRKjzI+Y56uekc9uzApidZ5Fehrk gedHMQaFlvpAnM=; b=G+H79clnC5IB0PWkZ+Vb8UOWtYZLhS2W0RUdUpRScqXS6 +jaL+LKah3g39cLBoZhZ5K7DIwh2pheYxY1Nk8/NkR28pborSTsg5ooI+WiW8fri ZgesdP4z5yo3jqXgWkH4wLT+4qkCgtwgK5aRz+nW9hr9D9bQhbt9FH3Ru1fGSkf/ JkM8okina5q9lz7+AfXYKKOiRj9KqgktWnXK4XssDiQ54UCKTVKl6XGK+djhjQ2s dXLHRvia4+sX/ySgA/7p5N+iNLw1Uhp3O5kzkTVgppmbESbpW0kSDrGGw9LbKljI lOlIOg4OWqCQC6+lIjK00ycrv94S8Xb1P+Mx64nPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=eCRKjz I+Y56uekc9uzApidZ5FehrkgedHMQaFlvpAnM=; b=TJ6av7VgdVpSyJpsD0YmK7 Z2Zmj89ZnQtpUBE+MBHMhxIeu+fp+7PtV6YxWVM5OTxC8lPDN69+YadHL9JugJ/B jOu0GV3OHWGoqNjmb24ij+HMmgEVOISWzt0DwfEq7h3d/q+rowkGfdVeD99ajgJQ P7GoKZYeaUDMhUFchkUHkyOlIL5XMaPSSCFSd3NgfYjTX5ftpi0a2YSXTVCMuTOt tza5uA3x9XoW2bOlual4GM99JpWDuwWLOLCjWcaR3RbIHmaRzU4ur4yjd6r7qoe/ QhXsE/VP33FYZoOrn+XYSUQUgjyNXZ72nTPTdltChU25louHD8DMmb4rcBBY7d5g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0892848006; Wed, 5 Apr 2017 11:37:01 -0400 (EDT) Message-Id: <1491406620.3919145.935191416.11687171@webmail.messagingengine.com> From: John To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-8e6aa83c References: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> Date: Wed, 05 Apr 2017 16:37:00 +0100 In-Reply-To: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> Subject: Re: SoC with multiple ethernet ports X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:37:03 -0000 On Wed, 5 Apr 2017, at 16:26, Norman Gray wrote: > > Greetings. > > I'm looking for a SoC (or other small) machine to act as a gateway > between two physical networks (in fact, an ordinary one and an IPMI). > Thus I'm looking for such a device which has at least two ethernet > interfaces, and can run FreeBSD. > > There are multiple boards listed at > , but the boards under the 'Well > supported boards' headings appear only to have single interfaces (though > I wouldn't claim an exhaustive search). > > I can see what appear to be nice multiple-interface boards at > , but they're listed > under 'unknown support'. I can see some notes on some Marvell boards at > , but these refer to FreeBSD > 8.x and 9-CURRENT, so are clearly not up-to-date. > > Searching the list archives, I find > > that at least some people are using 11.0-CURRENT on an Armada/Marvell > board, but (given that that's a bug report) I'm not sure if that usage > counts as ...Brave or not. > > There's clearly a lot of hardware possibilities here, but I surely can't > be the first person to want such a device. Does anyone on this list > have any advice? > See my thread of 3rd April ;) -- J. tech-lists@zyxst.net From owner-freebsd-arm@freebsd.org Wed Apr 5 21:49:09 2017 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 560B7D2D42F for ; Wed, 5 Apr 2017 21:49:09 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 1A62ADA7 for ; Wed, 5 Apr 2017 21:49:09 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-vk0-x231.google.com with SMTP id d188so21037271vka.0 for ; Wed, 05 Apr 2017 14:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=MuXM6nFgGRBXGt3ZwxIskXoChvPaUCGHNKgcwd5vPhs=; b=XN1t+mseXsFmvuKI/+EyQDQGZ3gT/zQJT1h3FRXHm8BHixXukTttHPcw/WAme0/s21 CTju3uVaepj2vTjlf18wWtUXLvsMERzv2Msv2hJ2epfdulIIarvPXrMCrLJYpOYCri+z ZtPszdUNE6INcuy1n18zILDa7/wJHPHxpK9KM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=MuXM6nFgGRBXGt3ZwxIskXoChvPaUCGHNKgcwd5vPhs=; b=pP1a2oMRI6FW/lJ8RbJ75TQqRm7K5uJM5aD804iCcYwWqICVGNqFGzffWzA6+ckTti 4jcYjo/gUAurJgNKebK5a9uKBLr+1EAM/XQybgBa4tg2hlsiSLRxUYJPmS3uOYvthNP9 xsEsoOyNWkIvzNsGIUHhuBHyUVpY9wsJVKWIEuhnvdBofoFE+zBhqBJui/fd3ffOTCO4 b9ZSmxzYWZjUDuiVrzdkfOW18+vahOjfdhP62MSzmOb436cdGheo4EW35YLpqisAObiI 6zwBGKvwoahW/IaWjbzhCM9nO7PtcseDndj0SQabB/rN8Jh/84kzwY0CjYl9eRHolOOy ZfAw== X-Gm-Message-State: AN3rC/6wRp7Xo8lzZhqPbaCp5EMQp674SspBhtt4HK0o5CdX7q8CcsQ/Ek5qovBB0iW8QMHJ791zAZrm0EBXOJvG X-Received: by 10.31.61.15 with SMTP id k15mr1261390vka.29.1491428947707; Wed, 05 Apr 2017 14:49:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.43.3 with HTTP; Wed, 5 Apr 2017 14:49:07 -0700 (PDT) In-Reply-To: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> References: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> From: Jim Thompson Date: Wed, 5 Apr 2017 16:49:07 -0500 Message-ID: Subject: Re: SoC with multiple ethernet ports To: Norman Gray , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 21:49:09 -0000 On Wed, Apr 5, 2017 at 10:26 AM, Norman Gray wrote= : > > Greetings. > > I'm looking for a SoC (or other small) machine to act as a gateway betwee= n > two physical networks (in fact, an ordinary one and an IPMI). Thus I'm > looking for such a device which has at least two ethernet interfaces, and > can run FreeBSD. > We (at Netgate) do a lot of work with ADI Engineering (now a division of Silicom). We sell tens of thousands of Intel-based systems per year, all with pfSense on them. Around 18 months ago, Steve Yates (the President of ADI) and I were bemoaning the lack of a truly open source (hw and sw) BMC solution in the industry. The ASpeed stuff you find on so many boards is fragile, expensive, and ... linux. So, for the BCC platform, we decided to embark on an ambitious project, which became known as 'microBMC' or uBMC. http://www.adiengineering.com/products/bcc-ve-board/ http://www.adiengineering.com/products/microbmc/ One of the ideas for uBMC was that it would leverage the on-die 3 port switch on the TI AM335x SoC. We picked the TI SoC *because* it already had decent support for FreeBSD (because of the Beaglebone series of boards.) That said, the support for that SoC wasn't as good as you might imagine. It wasn't "product" grade. We did quite a bit of work to what existed in FreeBSD, to get to a releasable product, then upstreamed it all. The whole point of the story up to this point is: "uBMC was desided to do exactly what you asked for: to sit between an IPMI port and another network." pfSense gets frequently deployed on small hardware (e.g. PC Engines) for this use case, and, of course, pfSense is based on FreeBSD. =E2=80=8B With this in-mind, and knowing that the software was coming together, one day, about a year ago, I asked Steve how difficult it would be to put the PHYs, magnetics and RJ45s on uBMC. There's more to it than that, of course, but that was the high-level concept. The result is uFW: http://www.adiengineering.com/products/micro-firewall/ which we sell as the "sg-1000": https://www.netgate.com/products/sg-1000.html If your volumes are high enough, you can purchase directly from ADI. If you want one, they'll send you to us. Full support for uBMC and uFW is upstreamed in the FreeBSD tree, mostly due to the efforts of Luiz Otavio O Souza (loos@). In particular, a lot of work was done to the cspw(4) driver to make it both more reliable and better performing. Case in-point, with *just* FreeBSD on the board, no packet fitlering, (and thus no NAT, etc), and using ptkg-en for source and sink, you can forward IPv4 traffic between the two ports at over 500Mbps. pkt-gen no firewall is ~580Mb/s: 313.994151 main_thread [2019] 45.851 Kpps (48.763 Kpkts 585.156 Mbps in 1063505 usec) 5.47 avg_batch 1015 min_space 315.057147 main_thread [2019] 45.838 Kpps (48.726 Kpkts 584.712 Mbps in 1062996 usec) 5.45 avg_batch 1015 min_space 316.092160 main_thread [2019] 45.854 Kpps (47.459 Kpkts 569.508 Mbps in 1035013 usec) 5.47 avg_batch 1015 min_space 317.116221 main_thread [2019] 45.838 Kpps (46.941 Kpkts 563.292 Mbps in 1024062 usec) 5.48 avg_batch 1015 min_space 318.140208 main_thread [2019] 45.846 Kpps (46.946 Kpkts 563.352 Mbps in 1023987 usec) 5.44 avg_batch 1015 min_space 319.203146 main_thread [2019] 45.831 Kpps (48.715 Kpkts 584.580 Mbps in 1062937 usec) 5.45 avg_batch 1015 min_space 320.266145 main_thread [2019] 45.827 Kpps (48.714 Kpkts 584.568 Mbps in 1063000 usec) 5.47 avg_batch 1015 min_space 321.329146 main_thread [2019] 45.842 Kpps (48.730 Kpkts 584.760 Mbps in 1063001 usec) 5.43 avg_batch 1015 min_space 322.392147 main_thread [2019] 45.845 Kpps (48.733 Kpkts 584.796 Mbps in 1063000 usec) 5.48 avg_batch 1015 min_space 323.455147 main_thread [2019] 45.850 Kpps (48.739 Kpkts 584.868 Mbps in 1063000 usec) 5.46 avg_batch 1015 min_space 324.509646 main_thread [2019] 45.850 Kpps (48.349 Kpkts 580.188 Mbps in 1054500 usec) 5.45 avg_batch 1015 min_space with pf: (one rule, basically "pass all") 498.389631 main_thread [2019] 27.494 Kpps (27.549 Kpkts 330.588 Mbps in 1002000 usec) 3.42 avg_batch 1019 min_space 499.391631 main_thread [2019] 27.513 Kpps (27.568 Kpkts 330.816 Mbps in 1002000 usec) 3.45 avg_batch 1019 min_space 500.393640 main_thread [2019] 27.503 Kpps (27.558 Kpkts 330.696 Mbps in 1002008 usec) 3.46 avg_batch 1019 min_space 501.419083 main_thread [2019] 27.502 Kpps (28.202 Kpkts 338.424 Mbps in 1025443 usec) 3.44 avg_batch 1019 min_space 502.419632 main_thread [2019] 27.509 Kpps (27.524 Kpkts 330.288 Mbps in 1000549 usec) 3.44 avg_batch 1019 min_space 503.420638 main_thread [2019] 27.545 Kpps (27.573 Kpkts 330.876 Mbps in 1001006 usec) 3.45 avg_batch 1019 min_space 504.430635 main_thread [2019] 27.530 Kpps (27.805 Kpkts 333.660 Mbps in 1009998 usec) 3.44 avg_batch 1019 min_space and with ipfw: (one rule, basically "pass all") 597.124126 main_thread [2019] 37.585 Kpps (39.953 Kpkts 479.436 Mbps in 1062999 usec) 4.61 avg_batch 1017 min_space 598.186628 main_thread [2019] 37.587 Kpps (39.936 Kpkts 479.232 Mbps in 1062502 usec) 4.60 avg_batch 1017 min_space 599.250127 main_thread [2019] 37.589 Kpps (39.976 Kpkts 479.712 Mbps in 1063500 usec) 4.60 avg_batch 1017 min_space 600.251626 main_thread [2019] 37.583 Kpps (37.639 Kpkts 451.668 Mbps in 1001498 usec) 4.62 avg_batch 1017 min_space 601.313294 main_thread [2019] 37.573 Kpps (39.890 Kpkts 478.680 Mbps in 1061669 usec) 4.60 avg_batch 1017 min_space 602.359629 main_thread [2019] 37.600 Kpps (39.342 Kpkts 472.104 Mbps in 1046334 usec) 4.63 avg_batch 1017 min_space Using iperf3, TCP, no firewall: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 1.19 GBytes 341 Mbits/sec 500 sende= r [ 4] 0.00-30.00 sec 1.19 GBytes 341 Mbits/sec receiver ipfw: (one rule) [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 1.01 GBytes 291 Mbits/sec 381 sende= r [ 4] 0.00-30.00 sec 1.01 GBytes 290 Mbits/sec receiver and pf: (one rule) [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 731 MBytes 204 Mbits/sec 361 sende= r [ 4] 0.00-30.00 sec 730 MBytes 204 Mbits/sec receiver I think this is pretty remarkable on a single core 550-600MHz ARM7 SoC. The performance of *pfSense* on the board isn't this high, because pfSense ships with a much more complex default ruleset. (If you configure pfSense to be the same "no filtering", then the performance is, indeed, as above.) So there is one solution that you can get today. =E2=80=8BSince the Marvell Armada 38x was also mentioned (both in this thre= ad and in the previous thread on the same subject), I'll let you know that, due largely to the efforts of Semihalf and Stormshield, with only tiny contributions from Netgate, full support for the Solid-Run boards should appear in FreeBSD soon. Stormshield and Netgate each have products coming that are somewhat different than the Solid-Run ClearFog boards, but the Solid-Run ClearFog boards are a target as well. A bootlog of -HEAD booting on a Solid-Run ClearFog Pro last week can be found here: https://gist.github.com/gonzopancho/2b0fb7c91eca140638b9953709b4dc4b =E2=80=8BAll of the above is 32-bit ARM. The future is 64-bit ARM.=E2=80= =8B =E2=80=8BWe're pretty engaged with both Marvell and NXP for their arm64 eff= orts. There are several interesting, low-cost boards based on SoCs from both NXP and Marvell. Marvell has the "expressoBIN" board, which is just under $50. It runs an Armada 3700 and a small Marvell switch to turn the two 1Gbps MACs on the 3700 into 3 1Gbps ports. NXP has the "FreedomFRDM-LS1012A: QorIQ " board, which is typically priced online just above $50. It runs a single-core LS1012A SoC, and has 2 x 1Gbps Ethernets. =E2=80=8B http://www.nxp.com/products/software-and-tools/hardware-development-tools/f= reedom-development-boards/qoriq-frdm-ls1012a-board:FRDM-LS1012A =E2=80=8BWhile neither of these run FreeBSD today, =E2=80=8B =E2=80=8BI hav= e several examples of both in my office, You decide what that might mean.=E2=80=8B =E2=80=8BAll that said, I would like to add this: =E2=80=8B The efforts undertaken to get pfSense out of the pit of being years behind FreeBSD -HEAD are finally paying off in two ways: - First, we can generate releases of pfSense that closely follow releases of FreeBSD, rather than the situation that had degraded to a point where pfSense was lagging as much as three years behind FreeBSD. - Second, being able to track -HEAD and the latest -RELEASE of FreeBSD in pfSense allows us to easily contribute back to FreeBSD (both ports and src)= . Both are important. =E2=80=8BJim =E2=80=8B > There are multiple boards listed at , > but the boards under the 'Well supported boards' headings appear only to > have single interfaces (though I wouldn't claim an exhaustive search). > > I can see what appear to be nice multiple-interface boards at < > https://www.solid-run.com/marvell-armada-family/>, but they're listed > under 'unknown support'. I can see some notes on some Marvell boards at = < > https://wiki.freebsd.org/FreeBSDMarvell>, but these refer to FreeBSD 8.x > and 9-CURRENT, so are clearly not up-to-date. > > Searching the list archives, I find ermail/freebsd-arm/2015-February/010300.html> that at least some people > are using 11.0-CURRENT on an Armada/Marvell board, but (given that that's= a > bug report) I'm not sure if that usage counts as ...Brave or not. > > There's clearly a lot of hardware possibilities here, but I surely can't > be the first person to want such a device. Does anyone on this list have > any advice? > > Best wishes, > > Norman > > > -- > Norman Gray : https://nxg.me.uk > SUPA School of Physics and Astronomy, University of Glasgow, UK > _______________________________________________ > 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" > From owner-freebsd-arm@freebsd.org Thu Apr 6 02:05:23 2017 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 5BABED31904 for ; Thu, 6 Apr 2017 02:05:23 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh604-vm4.bullet.mail.ssk.yahoo.co.jp (nh604-vm4.bullet.mail.ssk.yahoo.co.jp [182.22.90.61]) by mx1.freebsd.org (Postfix) with SMTP id EBA06E75 for ; Thu, 6 Apr 2017 02:05:22 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.106] by nh604.bullet.mail.ssk.yahoo.co.jp with NNFMP; 06 Apr 2017 02:02:12 -0000 Received: from [182.22.91.131] by t604.bullet.mail.ssk.yahoo.co.jp with NNFMP; 06 Apr 2017 02:02:12 -0000 Received: from [127.0.0.1] by omp604.mail.ssk.yahoo.co.jp with NNFMP; 06 Apr 2017 02:02:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 198126.40531.bm@omp604.mail.ssk.yahoo.co.jp Received: (qmail 6843 invoked by uid 60001); 6 Apr 2017 02:02:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1491444132; bh=nqGMGgLjt8ASJTrw3x2s06+D+khMf9j/WUvCiD+ooBQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bb8QBdIr/XSMRMhA13AX5wy2+P14V8p+B42DGZgV1ER1I8WS44qKgEj/ZoXBp45/EIpwzdqVMgGkuOdD7tMCtn8jPf48lFiK/urwR4VNLx4CuFncr6qyOXRXRy3lQq+Vq1/0V9FIjGS3q+Tae8CkS3U9/IEb1Gcft+Ohli2exko= 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:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AZy62W63STDkCSPu4OK5aWyOXeLi29YDYcuMOhpvmZkAgQBYIAnH5b1M65sUF9Y8erFlH157buPUdtLoiqQftpHaqRU09u+cN0OubMjWZHVCACaAvjjuahcl5q4Pn/orYhf4Fa+FYTIDJ31RPAAJib5LXBvoheLwaDFXqRUq8Ms=; Message-ID: <112641.90199.qm@web101703.mail.ssk.yahoo.co.jp> X-YMail-OSG: 6rsUugYVM1lx7FrndcswTlvXEv0E9wh39zug2qgGj9inmFp6._Ec87hOgJgm5_9wv02ZSgrGTleYl1goJ39A_A5wjzZLmnRnTtVcdrfUYp_WstBxpT2n3n0jLJcSiPPSp9kCv98rb8JaoalRbYkq4pqFkKEP3IbSdG5Uhyd_KD7dkMouDod6Qc0g5rmFfPa2KGQCKmrFtPqBI09XFXDkI3hH.VVZ2EaaAoPYnw17xFjD6Zr5fH5.hlIwdElRKhHLb6Lf.4y29yA8r23tJeeQ0kqhRf9a3DHwqdWmV23uZQ7S4qyr32LrYColyywazNvD2.DlDcEHE3vFQzhIBjjdzffewBnBBnkHhIUiaeQmyGeDUDapyIGFCwIJmsNoyjMXe2FiAPvX6DQumTQmSRc0C5joyzsf3rl6x4KdohRpsW.8DArz72BzbdQtFCSKD_pJF2oE5BgRWbgjvk0tRVBc4A3.q2ijnpHSn7KLE6ydm_ihcLWQX8fgZamc3p19Z1gBeBFoNY6znQ8_9j7wNoQCCYPNqdjvMyUmTOMPMdGkLTM33bp9A2BenKPyjCslSAsWDOaUs9RyB.Td0xNkCzzYAXc7HDPRf6cxLJvUJATvZGmekQ-- Received: from [210.20.198.8] by web101703.mail.ssk.yahoo.co.jp via HTTP; Thu, 06 Apr 2017 11:02:11 JST X-Mailer: YahooMailWebService/0.8.111_70 X-YMail-JAS: v0tJHFgVM1nui6EqmbkGDEDYbFX15hPSJyLjFBsQAzafrPxi4ZMekdjisHNR_58gcs6H17RmtGH7vhMuYeCz1F9K8rmwCNAZk6Qgdn9zcxKZp3Z3sXGwRhvyC.i9SXYVxO1_ References: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> Date: Thu, 6 Apr 2017 11:02:11 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: SoC with multiple ethernet ports To: Norman Gray , "freebsd-arm@freebsd.org" In-Reply-To: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 02:05:23 -0000 Hi.=0A=0AMy port of OLD Ralink arm soc that is RT1310 have two port first e= thernet=0Ainterface. My target of RT1310 is Buffalo WZR2-G300N that is one = port is=0Adirect=A0to out and other one is connect to icplus switch.=0A=0A#= ifconfig -a=0Afv0: flags=3D8843 me= tric 0 mtu 1500=0A=A0 =A0 =A0 =A0 ether 00:1a:f1:01:1f:23=0A=A0 =A0 =A0 =A0= inet 10.10.10.40 netmask 0xffffff00 broadcast 10.10.10.255=A0=0A=A0 =A0 = =A0 =A0 media: Ethernet autoselect=0A=A0 =A0 =A0 =A0 status: active=0Afv1: = flags=3D8843 metric 0 mtu 1500=0A= =A0 =A0 =A0 =A0 ether 00:1a:f1:01:1f:24=0A=A0 =A0 =A0 =A0 inet 10.0.1.123 n= etmask 0xffffff00 broadcast 10.0.1.255=A0=0A=A0 =A0 =A0 =A0 media: Ethernet= autoselect=0A=A0 =A0 =A0 =A0 status: active=0Alo0: flags=3D8049 metric 0 mtu 16384=0A=A0 =A0 =A0 =A0 options=3D600003<= RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>=0A=A0 =A0 =A0 =A0 inet 127.0.0.1 net= mask 0xff000000=A0=0A=A0 =A0 =A0 =A0 groups: lo=A0=0A# etherswitchcfg -v=0A= etherswitch0: IC+ IP17x switch driver with 5 ports and 16 VLAN groups=0Aeth= erswitch0: VLAN capabilities=3D6=0Aetherswitch0: VLAN mode: DOT= 1Q=0Aport0:=0A=A0 =A0 =A0 =A0 pvid: 1=0A=A0 =A0 =A0 =A0 flags=3D0<>=0A=A0 = =A0 =A0 =A0 media: Ethernet autoselect (100baseTX )=0A=A0 =A0 = =A0 =A0 status: active=0Aport1:=0A=A0 =A0 =A0 =A0 pvid: 1=0A=A0 =A0 =A0 =A0= flags=3D0<>=0A=A0 =A0 =A0 =A0 media: Ethernet autoselect (100baseTX )=0A=A0 =A0 =A0 =A0 status: active=0Aport2:=0A=A0 =A0 =A0 =A0 pvid: = 1=0A=A0 =A0 =A0 =A0 flags=3D0<>=0A=A0 =A0 =A0 =A0 media: Ethernet autoselec= t (none)=0A=A0 =A0 =A0 =A0 status: no carrier=0Aport3:=0A=A0 =A0 =A0 =A0 pv= id: 1=0A=A0 =A0 =A0 =A0 flags=3D0<>=0A=A0 =A0 =A0 =A0 media: Ethernet autos= elect (none)=0A=A0 =A0 =A0 =A0 status: no carrier=0Aport4:=0A=A0 =A0 =A0 = =A0 pvid: 1=0A=A0 =A0 =A0 =A0 flags=3D1=0A=A0 =A0 =A0 =A0 media: E= thernet 100baseTX =0A=A0 =A0 =A0 =A0 status: active=0Avlangrou= p0:=0A=A0 =A0 =A0 =A0 vlan: 1=0A=A0 =A0 =A0 =A0 members 0,1,2,3,4=0A=0AThis= is recent dmesg.=0A=0Ahttps://gist.github.com/yamori813/88224f1c96c9c592fb= 611b12a15e4ab5=0A=0A=0AReview is here.=0A=0Ahttps://reviews.freebsd.org/D72= 38=0A=0A=0A----- Original Message -----=0A> From: Norman Gray =0A> To: freebsd-arm@freebsd.org=0A> Cc: =0A> Date: 2017/4/6, Th= u 00:26=0A> Subject: SoC with multiple ethernet ports=0A> =0A> =0A> Greetin= gs.=0A> =0A> I'm looking for a SoC (or other small) machine to act as a gat= eway between =0A> two physical networks (in fact, an ordinary one and an IP= MI).=A0 Thus I'm =0A> looking for such a device which has at least two ethe= rnet interfaces, and can =0A> run FreeBSD.=0A> =0A> There are multiple boar= ds listed at =0A> , but the boards un= der the 'Well =0A> supported boards' headings appear only to have single in= terfaces (though I =0A> wouldn't claim an exhaustive search).=0A> =0A> I ca= n see what appear to be nice multiple-interface boards at =0A> , but they're listed =0A> under 'unkn= own support'.=A0 I can see some notes on some Marvell boards at =0A> , but these refer to FreeBSD 8.x =0A> an= d 9-CURRENT, so are clearly not up-to-date.=0A> =0A> Searching the list arc= hives, I find =0A> =0A> that at least some people are using 11.0-CURRENT o= n an Armada/Marvell board, but =0A> (given that that's a bug report) I'm no= t sure if that usage counts as =0A> ...Brave or not.=0A> =0A> There's clear= ly a lot of hardware possibilities here, but I surely can't =0A> be the fir= st person to want such a device.=A0 Does anyone on this list have any =0A> = advice?=0A> =0A> Best wishes,=0A> =0A> Norman=0A> =0A> =0A> -- Norman Gray= =A0 :=A0 https://nxg.me.uk=0A> SUPA School of Physics and Astronomy, Univer= sity of Glasgow, UK=0A> _______________________________________________=0A>= freebsd-arm@freebsd.org mailing list=0A> https://lists.freebsd.org/mailman= /listinfo/freebsd-arm=0A> To unsubscribe, send any mail to "freebsd-arm-uns= ubscribe@freebsd.org"=0A> From owner-freebsd-arm@freebsd.org Thu Apr 6 05:18:40 2017 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 3C62CD31C9E for ; Thu, 6 Apr 2017 05:18:40 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 0BE36121 for ; Thu, 6 Apr 2017 05:18:40 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pg0-x242.google.com with SMTP id 79so5850430pgf.0 for ; Wed, 05 Apr 2017 22:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to; bh=RN+GcoRxqBpN42HvMQBtPglP6Hyix6lQYO8UwC3tRvI=; b=YqVUC8U2hvPRHHJBAZkH6RLI24q+lxXdBiLevSl7U+8luwXqTmer6qd8gES/Yp2HNH pi46ycaZ5obz39CO8oxiq9hFlBPME6KRIC9vOHlMs6OuCTJgn2/qRRUGpV9S7aycUvmS hmQQTlmyjTCFM0zuI9L7s5NIycJGst/6VRmU3Uh0V9e+0qyT/XFAvG8iSCXvMDERTCrp Aa6Bpq+vlrtcKabb8H7BZX1Z1khxpVn2BTgLC5yrhWdM14H+7yf+VC5quXnTmoBCZYHq cpfFNag/bRSzhOYLpfoDq+N9aHCn237n15NaUziYWpY7EcnfpvmBzcJv+ybmW2Mnf7KD 1b2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to; bh=RN+GcoRxqBpN42HvMQBtPglP6Hyix6lQYO8UwC3tRvI=; b=r+7vpA/c2ZC7g/VGxRDDvgDFuA5yMJ1WXKv0YKpAT7QZqRSlzgyi7rHLWlk7+C+58g Jd1MJkfYIybjLux+l8L1SZnlLBdnSKJlO99eQ7G85L4s9N+EXuQzi3RaZF1jGMg9sSVS DzGNQizzTCKWS4WflipZJMc83RsPf92YTIMg9K1wirWoJPCoujDTuCLXDMMnD96+82GL IoaaYa5eiSc01GSo5LaY9YCwqasexvbMiuBgR6YTuAxl81KFmtNGniLCw7H7Ip2vJlmu HSNTbRxmPaxl513srFreAJ5X93zvnTttcW239xfSAQxCLzkZ479cZC/6wwq/e5FaZ68+ ZLdg== X-Gm-Message-State: AFeK/H0SvEwqfDCbXy37KViJwLFfVWHUFlEYukjYC02vcH+TbthIuTMxpUdcRRzozbLEUw== X-Received: by 10.98.214.3 with SMTP id r3mr33836305pfg.255.1491455919480; Wed, 05 Apr 2017 22:18:39 -0700 (PDT) Received: from [127.0.0.1] ([204.174.94.196]) by smtp.gmail.com with ESMTPSA id x21sm883395pfa.71.2017.04.05.22.18.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Apr 2017 22:18:37 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170406051837.5902420.12766.23772@gmail.com> Date: Wed, 05 Apr 2017 22:18:37 -0700 Subject: Re: SoC with multiple ethernet ports From: Russell Haley In-Reply-To: References: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> To: Jim Thompson , Norman Gray , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 05:18:40 -0000 Sorry for the top post.=C2=A0 We got a Solid Run clear fog at work and put openwrt on it. I was personall= y lamenting that I wouldn't be able to put freebsd on it so this is fantast= ic news. The mavell switching chip is FAST (the engineers response when I a= sked for details). We've created a 14 port switch (2x1gbps or 12x100mbps=E2= =80=8E I think he said?) by lashing two of the switching chips and a single= armada cpu. Sorry I don't have the model info of the chips handy. If I und= erstand correctly all the layer 2 stuff happens in hardware and only packet= filtering and advanced rules/inspection are sent to the cpu? Great news. Looking forward to hearing when you have something going Jim.= =C2=A0 Russ Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Virgin=C2=A0Mobile=C2=A0network. =C2=A0 Original Message =C2=A0 From: Jim Thompson Sent: Wednesday, April 5, 2017 2:49 PM To: Norman Gray; freebsd-arm@freebsd.org Subject: Re: SoC with multiple ethernet ports On Wed, Apr 5, 2017 at 10:26 AM, Norman Gray wrote: > > Greetings. > > I'm looking for a SoC (or other small) machine to act as a gateway between > two physical networks (in fact, an ordinary one and an IPMI). Thus I'm > looking for such a device which has at least two ethernet interfaces, and > can run FreeBSD. > We (at Netgate) do a lot of work with ADI Engineering (now a division of Silicom). We sell tens of thousands of Intel-based systems per year, all with pfSense on them. Around 18 months ago, Steve Yates (the President of ADI) and I were bemoaning the lack of a truly open source (hw and sw) BMC solution in the industry. The ASpeed stuff you find on so many boards is fragile, expensive, and ... linux. So, for the BCC platform, we decided to embark on an ambitious project, which became known as 'microBMC' or uBMC. http://www.adiengineering.com/products/bcc-ve-board/ http://www.adiengineering.com/products/microbmc/ One of the ideas for uBMC was that it would leverage the on-die 3 port switch on the TI AM335x SoC. We picked the TI SoC *because* it already had decent support for FreeBSD (because of the Beaglebone series of boards.) That said, the support for that SoC wasn't as good as you might imagine. It wasn't "product" grade. We did quite a bit of work to what existed in FreeBSD, to get to a releasable product, then upstreamed it all. The whole point of the story up to this point is: "uBMC was desided to do exactly what you asked for: to sit between an IPMI port and another network." pfSense gets frequently deployed on small hardware (e.g. PC Engines) for this use case, and, of course, pfSense is based on FreeBSD. =E2=80=8B With this in-mind, and knowing that the software was coming together, one day, about a year ago, I asked Steve how difficult it would be to put the PHYs, magnetics and RJ45s on uBMC. There's more to it than that, of course, but that was the high-level concept. The result is uFW: http://www.adiengineering.com/products/micro-firewall/ which we sell as the "sg-1000": https://www.netgate.com/products/sg-1000.html If your volumes are high enough, you can purchase directly from ADI. If you want one, they'll send you to us. Full support for uBMC and uFW is upstreamed in the FreeBSD tree, mostly due to the efforts of Luiz Otavio O Souza (loos@). In particular, a lot of work was done to the cspw(4) driver to make it both more reliable and better performing. Case in-point, with *just* FreeBSD on the board, no packet fitlering, (and thus no NAT, etc), and using ptkg-en for source and sink, you can forward IPv4 traffic between the two ports at over 500Mbps. pkt-gen no firewall is ~580Mb/s: 313.994151 main_thread [2019] 45.851 Kpps (48.763 Kpkts 585.156 Mbps in 1063505 usec) 5.47 avg_batch 1015 min_space 315.057147 main_thread [2019] 45.838 Kpps (48.726 Kpkts 584.712 Mbps in 1062996 usec) 5.45 avg_batch 1015 min_space 316.092160 main_thread [2019] 45.854 Kpps (47.459 Kpkts 569.508 Mbps in 1035013 usec) 5.47 avg_batch 1015 min_space 317.116221 main_thread [2019] 45.838 Kpps (46.941 Kpkts 563.292 Mbps in 1024062 usec) 5.48 avg_batch 1015 min_space 318.140208 main_thread [2019] 45.846 Kpps (46.946 Kpkts 563.352 Mbps in 1023987 usec) 5.44 avg_batch 1015 min_space 319.203146 main_thread [2019] 45.831 Kpps (48.715 Kpkts 584.580 Mbps in 1062937 usec) 5.45 avg_batch 1015 min_space 320.266145 main_thread [2019] 45.827 Kpps (48.714 Kpkts 584.568 Mbps in 1063000 usec) 5.47 avg_batch 1015 min_space 321.329146 main_thread [2019] 45.842 Kpps (48.730 Kpkts 584.760 Mbps in 1063001 usec) 5.43 avg_batch 1015 min_space 322.392147 main_thread [2019] 45.845 Kpps (48.733 Kpkts 584.796 Mbps in 1063000 usec) 5.48 avg_batch 1015 min_space 323.455147 main_thread [2019] 45.850 Kpps (48.739 Kpkts 584.868 Mbps in 1063000 usec) 5.46 avg_batch 1015 min_space 324.509646 main_thread [2019] 45.850 Kpps (48.349 Kpkts 580.188 Mbps in 1054500 usec) 5.45 avg_batch 1015 min_space with pf: (one rule, basically "pass all") 498.389631 main_thread [2019] 27.494 Kpps (27.549 Kpkts 330.588 Mbps in 1002000 usec) 3.42 avg_batch 1019 min_space 499.391631 main_thread [2019] 27.513 Kpps (27.568 Kpkts 330.816 Mbps in 1002000 usec) 3.45 avg_batch 1019 min_space 500.393640 main_thread [2019] 27.503 Kpps (27.558 Kpkts 330.696 Mbps in 1002008 usec) 3.46 avg_batch 1019 min_space 501.419083 main_thread [2019] 27.502 Kpps (28.202 Kpkts 338.424 Mbps in 1025443 usec) 3.44 avg_batch 1019 min_space 502.419632 main_thread [2019] 27.509 Kpps (27.524 Kpkts 330.288 Mbps in 1000549 usec) 3.44 avg_batch 1019 min_space 503.420638 main_thread [2019] 27.545 Kpps (27.573 Kpkts 330.876 Mbps in 1001006 usec) 3.45 avg_batch 1019 min_space 504.430635 main_thread [2019] 27.530 Kpps (27.805 Kpkts 333.660 Mbps in 1009998 usec) 3.44 avg_batch 1019 min_space and with ipfw: (one rule, basically "pass all") 597.124126 main_thread [2019] 37.585 Kpps (39.953 Kpkts 479.436 Mbps in 1062999 usec) 4.61 avg_batch 1017 min_space 598.186628 main_thread [2019] 37.587 Kpps (39.936 Kpkts 479.232 Mbps in 1062502 usec) 4.60 avg_batch 1017 min_space 599.250127 main_thread [2019] 37.589 Kpps (39.976 Kpkts 479.712 Mbps in 1063500 usec) 4.60 avg_batch 1017 min_space 600.251626 main_thread [2019] 37.583 Kpps (37.639 Kpkts 451.668 Mbps in 1001498 usec) 4.62 avg_batch 1017 min_space 601.313294 main_thread [2019] 37.573 Kpps (39.890 Kpkts 478.680 Mbps in 1061669 usec) 4.60 avg_batch 1017 min_space 602.359629 main_thread [2019] 37.600 Kpps (39.342 Kpkts 472.104 Mbps in 1046334 usec) 4.63 avg_batch 1017 min_space Using iperf3, TCP, no firewall: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 1.19 GBytes 341 Mbits/sec 500 sender [ 4] 0.00-30.00 sec 1.19 GBytes 341 Mbits/sec receiver ipfw: (one rule) [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 1.01 GBytes 291 Mbits/sec 381 sender [ 4] 0.00-30.00 sec 1.01 GBytes 290 Mbits/sec receiver and pf: (one rule) [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 731 MBytes 204 Mbits/sec 361 sender [ 4] 0.00-30.00 sec 730 MBytes 204 Mbits/sec receiver I think this is pretty remarkable on a single core 550-600MHz ARM7 SoC. The performance of *pfSense* on the board isn't this high, because pfSense ships with a much more complex default ruleset. (If you configure pfSense to be the same "no filtering", then the performance is, indeed, as above.) So there is one solution that you can get today. =E2=80=8BSince the Marvell Armada 38x was also mentioned (both in this thre= ad and in the previous thread on the same subject), I'll let you know that, due largely to the efforts of Semihalf and Stormshield, with only tiny contributions from Netgate, full support for the Solid-Run boards should appear in FreeBSD soon. Stormshield and Netgate each have products coming that are somewhat different than the Solid-Run ClearFog boards, but the Solid-Run ClearFog boards are a target as well. A bootlog of -HEAD booting on a Solid-Run ClearFog Pro last week can be found here: https://gist.github.com/gonzopancho/2b0fb7c91eca140638b9953709b4dc4b =E2=80=8BAll of the above is 32-bit ARM. The future is 64-bit ARM.=E2=80=8B =E2=80=8BWe're pretty engaged with both Marvell and NXP for their arm64 eff= orts. There are several interesting, low-cost boards based on SoCs from both NXP and Marvell. Marvell has the "expressoBIN" board, which is just under $50. It runs an Armada 3700 and a small Marvell switch to turn the two 1Gbps MACs on the 3700 into 3 1Gbps ports. NXP has the "FreedomFRDM-LS1012A: QorIQ " board, which is typically priced online just above $50. It runs a single-core LS1012A SoC, and has 2 x 1Gbps Ethernets. =E2=80=8B http://www.nxp.com/products/software-and-tools/hardware-development-tools/f= reedom-development-boards/qoriq-frdm-ls1012a-board:FRDM-LS1012A =E2=80=8BWhile neither of these run FreeBSD today, =E2=80=8B =E2=80=8BI hav= e several examples of both in my office, You decide what that might mean.=E2=80=8B =E2=80=8BAll that said, I would like to add this: =E2=80=8B The efforts undertaken to get pfSense out of the pit of being years behind FreeBSD -HEAD are finally paying off in two ways: - First, we can generate releases of pfSense that closely follow releases of FreeBSD, rather than the situation that had degraded to a point where pfSense was lagging as much as three years behind FreeBSD. - Second, being able to track -HEAD and the latest -RELEASE of FreeBSD in pfSense allows us to easily contribute back to FreeBSD (both ports and src). Both are important. =E2=80=8BJim =E2=80=8B > There are multiple boards listed at , > but the boards under the 'Well supported boards' headings appear only to > have single interfaces (though I wouldn't claim an exhaustive search). > > I can see what appear to be nice multiple-interface boards at < > https://www.solid-run.com/marvell-armada-family/>, but they're listed > under 'unknown support'. I can see some notes on some Marvell boards at < > https://wiki.freebsd.org/FreeBSDMarvell>, but these refer to FreeBSD 8.x > and 9-CURRENT, so are clearly not up-to-date. > > Searching the list archives, I find ermail/freebsd-arm/2015-February/010300.html> that at least some people > are using 11.0-CURRENT on an Armada/Marvell board, but (given that that's= a > bug report) I'm not sure if that usage counts as ...Brave or not. > > There's clearly a lot of hardware possibilities here, but I surely can't > be the first person to want such a device. Does anyone on this list have > any advice? > > Best wishes, > > Norman > > > -- > Norman Gray : https://nxg.me.uk > SUPA School of Physics and Astronomy, University of Glasgow, UK > _______________________________________________ > 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" > _______________________________________________ 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" From owner-freebsd-arm@freebsd.org Thu Apr 6 06:06:45 2017 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 43A6CD31186 for ; Thu, 6 Apr 2017 06:06:45 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 03317405 for ; Thu, 6 Apr 2017 06:06:44 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-vk0-x22e.google.com with SMTP id r69so29617362vke.2 for ; Wed, 05 Apr 2017 23:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B6+EIasyXJJdZa7TiGzgfVtvYNy5mWHZxexKgL/G7rY=; b=jI5K/1wJi8e3hIQg+n9zUEV/ltfL5on6cKVaDVVrliHuv1ShhQ4e9OyYcqnAFCmab+ a2U6LNLPUmvQNPptdnPlI7QgPZNl8MsGyj3J0xrZ5bq/TztIUXufpkGYVCgdTH5TNcuT gJRrC1avo9NPiqu+1gREdPo0yHSba5OokiAeA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B6+EIasyXJJdZa7TiGzgfVtvYNy5mWHZxexKgL/G7rY=; b=CTUPc/m1Yzbn5GU9njk0XoiOpy/RRPEyeNf03qoi0UI2gYOkUcKUqdAb5CSoLyB+xp aATexGvI2DThi5Xpwn0549P4X3ro0K38uVeBcO940asXy9a1XfEgrhFoFNQnEgAwOp5D rc0E/OdkED9rZOsdHUYL8x5JgtcI6uZhefUuyPif3RDq4t4Ulm7PgF0Wm5nzS1+Zy6sJ WS/sECCjYxMztnz+sqVo9WKepJ2kruo73LJ7jnHk+9c4BAGAh1v6K0Yqidf/7sdvdvdR pGlFSePcGL+TaCPyIvg9GexPbiNVNwWi0xptXRDc+JHAAXWvrlgvV/vVXZfYzUoCmYlB VH/w== X-Gm-Message-State: AFeK/H3UfDhK/9GQKtJP8ffPPtoy875cQj+gAEbDS2L9MNHSsVIuRM9XYGyDJfG7oyM2rsqhCuyRNLLUEvYip/mb X-Received: by 10.176.5.199 with SMTP id e65mr11000228uae.23.1491458803753; Wed, 05 Apr 2017 23:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.43.3 with HTTP; Wed, 5 Apr 2017 23:06:42 -0700 (PDT) In-Reply-To: <20170406051837.5902420.12766.23772@gmail.com> References: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> <20170406051837.5902420.12766.23772@gmail.com> From: Jim Thompson Date: Thu, 6 Apr 2017 01:06:42 -0500 Message-ID: Subject: Re: SoC with multiple ethernet ports To: Russell Haley Cc: Norman Gray , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 06:06:45 -0000 On Thu, Apr 6, 2017 at 12:18 AM, Russell Haley wrote= : > Sorry for the top post. > > We got a Solid Run clear fog at work and put openwrt on it. =E2=80=8BMarvell provides an OpenWRT port for the board, yes. =E2=80=8B > I was personally lamenting that I wouldn't be able to put freebsd on it s= o > this is fantastic news. The mavell switching chip is FAST (the engineers > response when I asked for details). > We've created a 14 port switch (2x1gbps or 12x100mbps=E2=80=8E I think he= said?) > by lashing two of the switching chips and a single armada cpu. =E2=80=8BOne of the things we did on the Netgate hardware (but for my post = here, it's otherwise unannounced) is to connect a Marvell 88E6141 switch at 2.5Gbps to the SERDES that can do 2.5Gbps Ethernet. We use the other two MACs on the SoC at 1Gbps each. This creates a system with a 4-port 1Gbps switch for "LAN" and 2 "WAN" ports, but, with some luck, we can forward at 2 Gbps, either between 2 pairs of the 4 port LAN (running through the SoC) or 2 ports on the LAN and both WAN ports. We're planning netmap support for the ethernets on this platform as well. netmap-fwd is still a thing, and Suricata has an inline mode that works via netmap. The expressoBIN board uses the same 88E6141 switch attached to the Armada 3700 SoC to make the device a '3 port' platform. The 3700 is otherwise a 2 MAC part. ClearFog Pro and Turris Omnia use an 88E6176, which has no 2.5Gbps SERDES. The Turris board does connect two of the 38x MACs to this switch. ClearFog Pro connects one, and leaves other two for WAN, where one port is on SFP, and the other on RJ45.=E2=80=8B > Sorry I don't have the model info of the chips handy. If I understand > correctly all the layer 2 stuff happens in hardware and only packet > filtering and advanced rules/inspection are sent to the cpu? > =E2=80=8BThe switch can do a lot, but a lot of the details are under NDA. =E2=80=8B > Great news. Looking forward to hearing when you have something going Jim. > =E2=80=8BSure thing. Jim =E2=80=8B > Russ > > Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. > Original Message > From: Jim Thompson > Sent: Wednesday, April 5, 2017 2:49 PM > To: Norman Gray; freebsd-arm@freebsd.org > Subject: Re: SoC with multiple ethernet ports > > On Wed, Apr 5, 2017 at 10:26 AM, Norman Gray > wrote: > > > > > Greetings. > > > > I'm looking for a SoC (or other small) machine to act as a gateway > between > > two physical networks (in fact, an ordinary one and an IPMI). Thus I'm > > looking for such a device which has at least two ethernet interfaces, a= nd > > can run FreeBSD. > > > > We (at Netgate) do a lot of work with ADI Engineering (now a division of > Silicom). We sell tens of thousands of Intel-based systems per year, all > with pfSense on them. > > Around 18 months ago, Steve Yates (the President of ADI) and I were > bemoaning the lack of a truly open source (hw and sw) BMC solution in the > industry. The ASpeed stuff you find on so many boards is fragile, > expensive, and ... linux. > > So, for the BCC platform, we decided to embark on an ambitious project, > which became known as 'microBMC' or uBMC. > http://www.adiengineering.com/products/bcc-ve-board/ > http://www.adiengineering.com/products/microbmc/ > > One of the ideas for uBMC was that it would leverage the on-die 3 port > switch on the TI AM335x SoC. We picked the TI SoC *because* it already ha= d > decent support for FreeBSD (because of the Beaglebone series of boards.) > That said, the support for that SoC wasn't as good as you might imagine. > It wasn't "product" grade. We did quite a bit of work to what existed in > FreeBSD, to get to a releasable product, then upstreamed it all. > > The whole point of the story up to this point is: "uBMC was desided to do > exactly what you asked for: to sit between an IPMI port and another > network." > > pfSense gets frequently deployed on small hardware (e.g. PC Engines) for > this use case, and, of course, pfSense is based on FreeBSD. > =E2=80=8B > With this in-mind, and knowing that the software was coming together, one > day, about a year ago, I asked Steve how difficult it would be to put the > PHYs, magnetics and RJ45s on uBMC. > There's more to it than that, of course, but that was the high-level > concept. The result is uFW: > http://www.adiengineering.com/products/micro-firewall/ > which we sell as the "sg-1000": > https://www.netgate.com/products/sg-1000.html > > If your volumes are high enough, you can purchase directly from ADI. If > you want one, they'll send you to us. > > Full support for uBMC and uFW is upstreamed in the FreeBSD tree, mostly d= ue > to the efforts of Luiz Otavio O Souza (loos@). In particular, a lot of > work was done to the cspw(4) driver to make it both more reliable and > better performing. > Case in-point, with *just* FreeBSD on the board, no packet fitlering, (an= d > thus no NAT, etc), and using ptkg-en for source and sink, you can forward > IPv4 traffic between the two ports at over 500Mbps. > > pkt-gen no firewall is ~580Mb/s: > 313.994151 main_thread [2019] 45.851 Kpps (48.763 Kpkts 585.156 Mbps in > 1063505 usec) 5.47 avg_batch 1015 min_space > 315.057147 main_thread [2019] 45.838 Kpps (48.726 Kpkts 584.712 Mbps in > 1062996 usec) 5.45 avg_batch 1015 min_space > 316.092160 main_thread [2019] 45.854 Kpps (47.459 Kpkts 569.508 Mbps in > 1035013 usec) 5.47 avg_batch 1015 min_space > 317.116221 main_thread [2019] 45.838 Kpps (46.941 Kpkts 563.292 Mbps in > 1024062 usec) 5.48 avg_batch 1015 min_space > 318.140208 main_thread [2019] 45.846 Kpps (46.946 Kpkts 563.352 Mbps in > 1023987 usec) 5.44 avg_batch 1015 min_space > 319.203146 main_thread [2019] 45.831 Kpps (48.715 Kpkts 584.580 Mbps in > 1062937 usec) 5.45 avg_batch 1015 min_space > 320.266145 main_thread [2019] 45.827 Kpps (48.714 Kpkts 584.568 Mbps in > 1063000 usec) 5.47 avg_batch 1015 min_space > 321.329146 main_thread [2019] 45.842 Kpps (48.730 Kpkts 584.760 Mbps in > 1063001 usec) 5.43 avg_batch 1015 min_space > 322.392147 main_thread [2019] 45.845 Kpps (48.733 Kpkts 584.796 Mbps in > 1063000 usec) 5.48 avg_batch 1015 min_space > 323.455147 main_thread [2019] 45.850 Kpps (48.739 Kpkts 584.868 Mbps in > 1063000 usec) 5.46 avg_batch 1015 min_space > 324.509646 main_thread [2019] 45.850 Kpps (48.349 Kpkts 580.188 Mbps in > 1054500 usec) 5.45 avg_batch 1015 min_space > > with pf: (one rule, basically "pass all") > 498.389631 main_thread [2019] 27.494 Kpps (27.549 Kpkts 330.588 Mbps in > 1002000 usec) 3.42 avg_batch 1019 min_space > 499.391631 main_thread [2019] 27.513 Kpps (27.568 Kpkts 330.816 Mbps in > 1002000 usec) 3.45 avg_batch 1019 min_space > 500.393640 main_thread [2019] 27.503 Kpps (27.558 Kpkts 330.696 Mbps in > 1002008 usec) 3.46 avg_batch 1019 min_space > 501.419083 main_thread [2019] 27.502 Kpps (28.202 Kpkts 338.424 Mbps in > 1025443 usec) 3.44 avg_batch 1019 min_space > 502.419632 main_thread [2019] 27.509 Kpps (27.524 Kpkts 330.288 Mbps in > 1000549 usec) 3.44 avg_batch 1019 min_space > 503.420638 main_thread [2019] 27.545 Kpps (27.573 Kpkts 330.876 Mbps in > 1001006 usec) 3.45 avg_batch 1019 min_space > 504.430635 main_thread [2019] 27.530 Kpps (27.805 Kpkts 333.660 Mbps in > 1009998 usec) 3.44 avg_batch 1019 min_space > > and with ipfw: (one rule, basically "pass all") > 597.124126 main_thread [2019] 37.585 Kpps (39.953 Kpkts 479.436 Mbps in > 1062999 usec) 4.61 avg_batch 1017 min_space > 598.186628 main_thread [2019] 37.587 Kpps (39.936 Kpkts 479.232 Mbps in > 1062502 usec) 4.60 avg_batch 1017 min_space > 599.250127 main_thread [2019] 37.589 Kpps (39.976 Kpkts 479.712 Mbps in > 1063500 usec) 4.60 avg_batch 1017 min_space > 600.251626 main_thread [2019] 37.583 Kpps (37.639 Kpkts 451.668 Mbps in > 1001498 usec) 4.62 avg_batch 1017 min_space > 601.313294 main_thread [2019] 37.573 Kpps (39.890 Kpkts 478.680 Mbps in > 1061669 usec) 4.60 avg_batch 1017 min_space > 602.359629 main_thread [2019] 37.600 Kpps (39.342 Kpkts 472.104 Mbps in > 1046334 usec) 4.63 avg_batch 1017 min_space > > Using iperf3, TCP, no firewall: > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-30.00 sec 1.19 GBytes 341 Mbits/sec 500 sender > [ 4] 0.00-30.00 sec 1.19 GBytes 341 Mbits/sec > receiver > > ipfw: (one rule) > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-30.00 sec 1.01 GBytes 291 Mbits/sec 381 sender > [ 4] 0.00-30.00 sec 1.01 GBytes 290 Mbits/sec > receiver > > and pf: (one rule) > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-30.00 sec 731 MBytes 204 Mbits/sec 361 sender > [ 4] 0.00-30.00 sec 730 MBytes 204 Mbits/sec > receiver > > I think this is pretty remarkable on a single core 550-600MHz ARM7 SoC. > The performance of *pfSense* on the board isn't this high, because pfSens= e > ships with a much more complex default ruleset. (If you configure pfSense > to be the same "no filtering", then the performance is, indeed, as above.= ) > > So there is one solution that you can get today. > > =E2=80=8BSince the Marvell Armada 38x was also mentioned (both in this th= read and > in the previous thread on the same subject), I'll let you know that, due > largely to the efforts of Semihalf and Stormshield, > with only tiny contributions from Netgate, full support for the Solid-Run > boards should appear in FreeBSD soon. > > Stormshield and Netgate each have products coming that are somewhat > different than the Solid-Run ClearFog boards, but the Solid-Run ClearFog > boards are a target as well. > > A bootlog of -HEAD booting on a Solid-Run ClearFog Pro last week can be > found here: > https://gist.github.com/gonzopancho/2b0fb7c91eca140638b9953709b4dc4b > > =E2=80=8BAll of the above is 32-bit ARM. The future is 64-bit ARM.=E2=80= =8B > > =E2=80=8BWe're pretty engaged with both Marvell and NXP for their arm64 e= fforts. > There are several interesting, low-cost boards based on SoCs from both NX= P > and Marvell. > > Marvell has the "expressoBIN" board, which is just under $50. It runs an > Armada 3700 and a small Marvell switch to turn the two 1Gbps MACs on the > 3700 into 3 1Gbps ports. > > NXP has the "FreedomFRDM-LS1012A: QorIQ " board, which is typically price= d > online just above $50. It runs a single-core LS1012A SoC, and has 2 x > 1Gbps Ethernets. > =E2=80=8B > http://www.nxp.com/products/software-and-tools/hardware- > development-tools/freedom-development-boards/qoriq-frdm- > ls1012a-board:FRDM-LS1012A > > =E2=80=8BWhile neither of these run FreeBSD today, =E2=80=8B =E2=80=8BI h= ave several examples of > both in my office, You decide what that might mean.=E2=80=8B > > =E2=80=8BAll that said, I would like to add this: =E2=80=8B > > The efforts undertaken to get pfSense out of the pit of being years behin= d > FreeBSD -HEAD are finally paying off in two ways: > > - First, we can generate releases of pfSense that closely follow releases > of FreeBSD, rather than the situation that had degraded to a point where > pfSense was lagging as much as three years behind FreeBSD. > - Second, being able to track -HEAD and the latest -RELEASE of FreeBSD in > pfSense allows us to easily contribute back to FreeBSD (both ports and > src). > > Both are important. > > =E2=80=8BJim > =E2=80=8B > > > > > There are multiple boards listed at FreeBSD/arm>, > > but the boards under the 'Well supported boards' headings appear only t= o > > have single interfaces (though I wouldn't claim an exhaustive search). > > > > I can see what appear to be nice multiple-interface boards at < > > https://www.solid-run.com/marvell-armada-family/>, but they're listed > > under 'unknown support'. I can see some notes on some Marvell boards at= < > > https://wiki.freebsd.org/FreeBSDMarvell>, but these refer to FreeBSD 8.= x > > and 9-CURRENT, so are clearly not up-to-date. > > > > Searching the list archives, I find > ermail/freebsd-arm/2015-February/010300.html> that at least some people > > are using 11.0-CURRENT on an Armada/Marvell board, but (given that > that's a > > bug report) I'm not sure if that usage counts as ...Brave or not. > > > > There's clearly a lot of hardware possibilities here, but I surely can'= t > > be the first person to want such a device. Does anyone on this list hav= e > > any advice? > > > > Best wishes, > > > > Norman > > > > > > -- > > Norman Gray : https://nxg.me.uk > > SUPA School of Physics and Astronomy, University of Glasgow, UK > > _______________________________________________ > > 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" > > > _______________________________________________ > 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" > From owner-freebsd-arm@freebsd.org Thu Apr 6 09:41:44 2017 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 265E2D2F393 for ; Thu, 6 Apr 2017 09:41:44 +0000 (UTC) (envelope-from norman@astro.gla.ac.uk) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (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 05585BE8 for ; Thu, 6 Apr 2017 09:41:43 +0000 (UTC) (envelope-from norman@astro.gla.ac.uk) Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CB7DC5B36; Thu, 6 Apr 2017 05:34:17 -0400 (EDT) X-Auth-ID: astro@nxg.name Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: astro-AT-nxg.name) with ESMTPSA id 55D595B24; Thu, 6 Apr 2017 05:34:17 -0400 (EDT) X-Sender-Id: astro@nxg.name Received: from [192.168.1.2] (164.70.2.81.in-addr.arpa [81.2.70.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 06 Apr 2017 05:34:17 -0400 From: "Norman Gray" To: "Jim Thompson" Cc: "freebsd-arm@freebsd.org" Subject: Re: SoC with multiple ethernet ports Date: Thu, 06 Apr 2017 10:34:15 +0100 Message-ID: <3642FDBE-C29F-4076-93D1-9FA697E1FCB8@astro.gla.ac.uk> In-Reply-To: References: <12078642-77BD-4B96-87F0-4B777EABA252@astro.gla.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:41:44 -0000 Jim, hello. On 5 Apr 2017, at 22:49, Jim Thompson wrote: > With this in-mind, and knowing that the software was coming together, > one > day, about a year ago, I asked Steve how difficult it would be to put > the > PHYs, magnetics and RJ45s on uBMC. > There's more to it than that, of course, but that was the high-level > concept. The result is uFW: > http://www.adiengineering.com/products/micro-firewall/ > which we sell as the "sg-1000": > https://www.netgate.com/products/sg-1000.html This is wonderful -- all that, and a pretty box, too! (the only downside of this conversation is that I now have to wrangle with our requisitions system -- the UI the 90s forgot) Thanks also to Mori and Russell for suggestions. The Solid Run hardware looked very nice, and it's good news that FreeBSD will be running on those, too, before long. Best wishes, Norman -- Norman Gray : https://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From owner-freebsd-arm@freebsd.org Fri Apr 7 08:22:55 2017 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 DD3CCD32B0A for ; Fri, 7 Apr 2017 08:22:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 98882A8D for ; Fri, 7 Apr 2017 08:22:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10850 invoked from network); 7 Apr 2017 08:16:13 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Apr 2017 08:16:13 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 07 Apr 2017 04:16:13 -0400 (EDT) Received: (qmail 14788 invoked from network); 7 Apr 2017 08:16:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Apr 2017 08:16:13 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7D2D1EC8937; Fri, 7 Apr 2017 01:16:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> Date: Fri, 7 Apr 2017 01:16:12 -0700 Cc: andrew@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:22:56 -0000 [I now can: (A) crudely control the number of allocated pages that get zeros (that should not). (B) Watch a "top -PCwaopid" display and predict if the test-architecture will fail or not before the fork() or swap-out happens.] On 2017-Apr-4, at 8:00 PM, Mark Millard wrote: > Uncommenting/commenting parts of the below program allows > exploring the problems with fork-then-swap-out-then-in on > arm64. >=20 > Note: By swap-out I mean that zero RES(ident memory) results, > for the process(s) of interest, as shown by > "top -PCwaopid" . >=20 > I discovered recently that swapping-out just before the > fork() prevents the failure from the swapping after the > fork(). >=20 > Note: > Without the fork() no problem happens. Without the later > swap-out no problem happens. Both are required. But some > activities before the fork() or between fork() and the > swap-out prevent the failures. >=20 > Some of the comments are based on a pine64+ 2GB context. > I use stress to force swap-outs during some sleeps in > the program. See also Buzilla 217239 and 217138. (I now > expect that they have the same cause.) >=20 > In my environment I've seen the fork-then-swap-out/swap-in > failures on a pine64+ 2GB and a rpi3. They are repeatable > on both. I do not have access to server-class machines, or > any other arm64 machines. >=20 >=20 > // swap_testing5.c >=20 > // Built via (cc was clang 4.0 in my case): > // > // cc -g -std=3Dc11 -Wpedantic -o swaptesting5 swap_testing5.c > // -O0 and -O2 also gets the problem. >=20 > // Note: jemalloc's tcache needs to be enabled to get the failure. > // But FreeBSD can get into a state were /etc/malloc.conf > // -> 'tcache:false' is ineffective. Also: the allocation > // size needs to by sufficiently small (<=3D SMALL_MAXCLASS) > // to see the problem. Other comments are based on a specific > // context (pine64+ 2GB). >=20 > #include // for raise(.), SIGABRT (induce core dump) > #include // for fork(), sleep(.) > #include // for pid_t > #include // for wait(.) >=20 > extern void test_setup(void); // Sets up the memory byte = patterns. > extern void test_check(void); // Tests the memory byte = patterns. > extern void memory_willneed(void); // For seeing if > // = posix_madvise(.,.,POSIX_MADV_WILLNEED) > // makes a difference. >=20 > int main(void) { > sleep(30); // Potentialy force swap-out here. > // [Swap-out here does not avoid later failures.] >=20 > test_setup(); > test_check(); // Before potential sleep(.)/swap-out or fork(.) = [passes] >=20 > sleep(30); // Potentialy force swap-out here. > // [Everything below passes if swapped-out here, > // no matter if there are later swap-outs > // or not.] >=20 > pid_t pid =3D fork(); // To test no-fork use: =3D 0; no-fork does = not fail. > int wait_status =3D 0; >=20 > // HERE: After fork; before sleep/swap-out/wait. >=20 > // if (0 < pid) memory_willneed(); // Does not prevent either = parent or > // child failure if enabled. >=20 > // if (0 =3D=3D pid) memory_willneed(); // Prevents both the parent = and the > // child failure. Disable to see > // failure of both parent and = child. > // [Presuming no prior swap-out: = that > // would make everything pass.] >=20 > // During sleep/wait: manually force this process to > // swap out. I use something like: > // stress -m 1 --vm-bytes 1800M > // in another shell and ^C'ing it after top shows the > // swapped status desired. 1800M just happened to work > // on the Pine64+ 2GB that I was using. I watch with > // top -PCwaopid [checking for zero RES(ident memory)]. >=20 > if (0 < pid) { > sleep(30); // Intend to swap-out during sleep. > // test_check(); // Test in parent before child runs (longer = sleep). > // This test fails if run for a failing = region_size > // unless earlier preventing-activity happened. > wait(&wait_status); // Only if test_check above passes or is > // disabled above. > } > if (-1 !=3D wait_status && 0 <=3D pid) { > if (0 =3D=3D pid) { sleep(90); } // Intend to swap-out during = sleep. > test_check(); // Fails for small-enough region_size, both > // parent and child processes, unless earlier > // preventing-activty happened. > } > } >=20 > // The memory and test code follows. >=20 > #include // for size_t, NULL > #include // for malloc(.), free(.) > #include // for POSIX_MADV_WILLNEED, = posix_madvise(.,.,.) >=20 > #define region_size (14u*1024u) > // Bad dyn_region pattern, parent and child processes examples: > // 256u, 2u*1024u, 4u*1024u, 8u*1024u, 9u*1024u, 12u*1024u, = 14u*1024u > // No failure examples: > // 14u*1024u+1u, 15u*1024u, 16u*1024u, 32u*1024u, = 256u*1024u*1024u > #define num_regions (256u*1024u*1024u/region_size) >=20 > typedef volatile unsigned char value_type; > struct region_struct { value_type array[region_size]; }; > typedef struct region_struct region; > static region * volatile dyn_regions[num_regions] =3D {NULL,}; >=20 > static value_type value(size_t v) { return = (value_type)((v&0xFEu)|0x1u); } > // value avoids zero values: the bad values are = zeros. >=20 > void test_setup(void) { > for(size_t i=3D0u; i dyn_regions[i] =3D malloc(sizeof(region)); > if (!dyn_regions[i]) raise(SIGABRT); >=20 > for(size_t j=3D0u; j (*dyn_regions[i]).array[j] =3D value(j); > } > } > } >=20 > void memory_willneed(void) { > for(size_t i=3D0u; i (void) posix_madvise(dyn_regions[i], region_size, = POSIX_MADV_WILLNEED); > } > } >=20 > static volatile size_t first_failure_idx =3D 0u; // dyn_regions index > static volatile size_t first_failure_pos =3D 0u; // sub-array index > static volatile size_t after_bad_idx =3D 0u; // dyn_regions index > static volatile size_t after_bad_pos =3D 0u; // sub-array index > static volatile size_t after_good_idx =3D 0u; // dyn_regions index > static volatile size_t after_good_pos =3D 0u; // sub-array index >=20 > // Note: Some failing cases get (conjunctive notation): > // > // 0 =3D=3D first_failure_idx < after_bad_idx < after_good_idx =3D=3D= num_regions > // && 0 =3D=3D first_failure_pos && 0<=3Dafter_bad_pos<=3Dregion_size = && after_good_idx=3D=3D0 > // && (after_bad_pos is a multiple of the page size in Bytes, here: > // after_bad_pos=3D=3DN*4096 for some non-negative integral value = N) > // > // other failing cases instead fail with: > // > // 0 =3D=3D first_failure && num_regions =3D=3D after_bad_idx =3D=3D = after_good_idx > // && 0 =3D=3D first_failure_pos =3D=3D after_bad_pos =3D=3D = after_good_idx > // > // after_bad_idx strongly tends to vary from failing run to failing = run > // as does after_bad_pos. >=20 > // Note: The working cases get: > // > // num_regions =3D=3D first_failure =3D=3D after_bad_idx =3D=3D = after_good_idx > // && 0 =3D=3D first_failure_pos =3D=3D after_bad_pos =3D=3D = after_good_idx >=20 > void test_check(void) { > first_failure_idx =3D first_failure_pos =3D 0u; >=20 > while (first_failure_idx < num_regions) { > while ( first_failure_pos < region_size > && ( value(first_failure_pos) > =3D=3D = (*dyn_regions[first_failure_idx]).array[first_failure_pos] > ) > ) { > first_failure_pos++; > } >=20 > if (region_size !=3D first_failure_pos) break; >=20 > first_failure_idx++; > first_failure_pos =3D 0u; > } >=20 > after_bad_idx =3D first_failure_idx; > after_bad_pos =3D first_failure_pos; >=20 > while (after_bad_idx < num_regions) { > while ( after_bad_pos < region_size > && ( value(after_bad_pos) > !=3D = (*dyn_regions[after_bad_idx]).array[after_bad_pos] > ) > ) { > after_bad_pos++; > } >=20 > if(region_size !=3D after_bad_pos) break; >=20 > after_bad_idx++; > after_bad_pos =3D 0u; > } >=20 > after_good_idx =3D after_bad_idx; > after_good_pos =3D after_bad_pos; >=20 > while (after_good_idx < num_regions) { > while ( after_good_pos < region_size > && ( value(after_good_pos) > =3D=3D = (*dyn_regions[after_good_idx]).array[after_good_pos] > ) > ) { > after_good_pos++; > } >=20 > if(region_size !=3D after_good_pos) break; >=20 > after_good_idx++; > after_good_pos =3D 0u; > } >=20 > if (num_regions !=3D first_failure_idx) raise(SIGABRT); > } I've found that for the above swap_testing5.c I can make variations that change how much of the allocated region prefix ends up zero vs. stays good. I vary the sleep time between testing the initialized allocations and doing the fork. The longer the sleep the more zero pages show up (be sure to read the comments): # diff swap_testing[56].c = = 1c1 < // swap_testing5.c --- > // swap_testing6.c 5c5 < // cc -g -std=3Dc11 -Wpedantic -o swaptesting5 swap_testing5.c --- > // cc -g -std=3Dc11 -Wpedantic -o swaptesting5 swap_testing6.c 33c33 < sleep(30); // Potentialy force swap-out here. --- > sleep(150); // Potentialy force swap-out here. 37a38,48 > // For no-swap-out here cases: > // > // The longer the sleep here the more allocations > // that end up as zero. > // > // top's Mem Active, Inact, Wired, Bug, Free and > // Swap Total, Used, and Free stay unchanged. > // What does change is the process RES decreases > // while the process SIZE and SWAP stay unchanged > // during this sleep. >=20 NOTE: On other architectures that I've tried (such as armv6/v7) RES does not decrease during the sleep --and the problem does not happen even for as long of sleeps as I've tried. (I use "stress -m 2 --vm-bytes 900M" on armv6/v7 instead of -m 1 --vm-bytes 1800M because that large in one process is not allowed.) So watching top's RES during the sleep (longer than a few seconds) just before the fork() predicts the later fails-vs.-not status: If RES decreases (while other things associated with the process status stay the same) then there will be a failure. At this point I've no clue why the sleeping process has a decreasing RES(ident memory) size. I infer that without the sleep there still is a small amount of loss of RES but on too short of a timescale to observe in a "top -PCwaopid" or other such: in other words that the same behavior is causing the failure then as well, possibly for a loss of only one page of RES. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Apr 7 14:25:35 2017 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 53931D320F6 for ; Fri, 7 Apr 2017 14:25:35 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 19760CCF for ; Fri, 7 Apr 2017 14:25:34 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x233.google.com with SMTP id i34so62124649qtc.0 for ; Fri, 07 Apr 2017 07:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=7FaO9ZTAVI9T2dqaLKJqgZ/C4gj8YcHnhtHIBpcWrYw=; b=PyhesY3cqzGZfytu+BOBtQBj8HnyS02l7K9s6/i9ildc1VNstwvRW6r3+xRwmZhg+q ibQXN8KKVB8KjpQE8faWjXKyY64OZb1SYh/dAL1ce7HMAlxE5ukoa+DJiuq5OMKl4Vb2 rk3ROErahdRmDMhvELORwlz0AMaZonuO6rpZI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=7FaO9ZTAVI9T2dqaLKJqgZ/C4gj8YcHnhtHIBpcWrYw=; b=p37nZIbTH+o6Wi+MiASWuijXX1gP19R3zpvVm4/mxhtrZxpGJ1RUTXbaUOP7rZWjlM IXmjeXLZKrjCiq71kXfFXl9E3b9sUpT8r9ZJOh1ixYOCqTFGnIfA1zfhIw4u5kR7+fQP 0YKj/Dbfih7vOeSeDSsB/dPqlyC9WaQsdrYVxlC+ggxbvCK2bPgc9k6PGEQgnNdKRuYr QLN/es6sxJXwsFmdGvf1rqAwfr5SfcIa07CyanondupS9v1K4IdliZGGDPZ1XaPa4ET6 4QBJqmdAE3UxuLrBuQqwsEZgMeRPS1pktZAekl1b9DdQgQb7W2nhYOa0INEIPCY1fQ+7 Hp8g== X-Gm-Message-State: AFeK/H2GfesnwJXQuBkdvYi1LMtusQ3U1uIt2vJeWQWu0A9CHh4uJIByeZg1aO+387SW9A== X-Received: by 10.200.45.137 with SMTP id p9mr41147715qta.201.1491575133686; Fri, 07 Apr 2017 07:25:33 -0700 (PDT) Received: from [192.168.43.219] (179-240-135-20.3g.claro.net.br. [179.240.135.20]) by smtp.googlemail.com with ESMTPSA id h6sm3122637qkd.56.2017.04.07.07.25.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:25:33 -0700 (PDT) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: top shows more than 100% of CPU usage Message-ID: Date: Fri, 7 Apr 2017 11:25:22 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:25:35 -0000 Dears Why top on arm sometimes shows more than 100% of CPU usage? regards -Otacilio From owner-freebsd-arm@freebsd.org Fri Apr 7 14:28:24 2017 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 503DCD322A5 for ; Fri, 7 Apr 2017 14:28:24 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "0x20.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1762EFB4 for ; Fri, 7 Apr 2017 14:28:23 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 40F5D6E0082; Fri, 7 Apr 2017 16:28:20 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id v37ESJV0048659; Fri, 7 Apr 2017 16:28:19 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id v37ESINN047507; Fri, 7 Apr 2017 16:28:18 +0200 (CEST) (envelope-from lars) Date: Fri, 7 Apr 2017 16:28:18 +0200 From: Lars Engels To: =?utf-8?B?T3RhY8OtbGlv?= Cc: "freebsd-arm@freebsd.org" Subject: Re: top shows more than 100% of CPU usage Message-ID: <20170407142818.GJ59737@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="labRHRsS1QiI3Q7R" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:28:24 -0000 --labRHRsS1QiI3Q7R Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 07, 2017 at 11:25:22AM -0300, Otac=C3=ADlio wrote: > Dears >=20 > Why top on arm sometimes shows more than 100% of CPU usage? >=20 That's because 100% means 100% utilization for one CPU / CPU core. If you have 4 cores, then utilization can go up to 400%. --labRHRsS1QiI3Q7R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJY56H+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tLugH/2xGMIZl7wHZ/2ffD4sV+Nz/ hRqeJrC8KV8KaGv2z5jjXgFuqK5w5Hp8AOus6En058U0AGhUH19MR8jb964FDbZ6 NkLOwtdc7N1pUuYAHyIObhCcArvI4yYOn2JmyM7JanXOU6uf9V3gQRTM/CZ8D8Y5 2INxsk7/pjTynz5vpFhqBGYjAK+aSJ99/cMWKzQP6bteL1ZT210Lufa69L63PNDF MN/Uy0Vt89DjoXmjhOisTHof8ILmufdJYiWdaGpv/xQYerTw+SaahpdMB9xoCJDD uBpekbM5pEz9KZcCGgV/U/PHCnlbcYgrfGOlCtF27cnGRY6OC+96bPUMa2a787g= =Elhz -----END PGP SIGNATURE----- --labRHRsS1QiI3Q7R-- From owner-freebsd-arm@freebsd.org Fri Apr 7 14:30:50 2017 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 42C68D3237F for ; Fri, 7 Apr 2017 14:30:50 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 F04892A5 for ; Fri, 7 Apr 2017 14:30:49 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22b.google.com with SMTP id f133so46993039qke.2 for ; Fri, 07 Apr 2017 07:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=+PEShM8VYXJ25XA8t3Na08pqnBfMK6RfVzl1FAfi8ds=; b=DuaHZaD9CQRJUdZbxSbENcdqFGm5Tz1p2SWeuZrzkstJtAp06W9u5E9h4Ncc78Cc5y N8WUb6t6vTz4EYPut/bwnIxSk6R8i5wfTN/b4XonF9bYISWmUTRbEzv5d3Z8oOfJOqBs R5wwqns5T0y6id4WIvugrBWDFTvZ2qqfqw+Sg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=+PEShM8VYXJ25XA8t3Na08pqnBfMK6RfVzl1FAfi8ds=; b=OT8D5k7UXKAySzvB5JvRlFus1oGrIgTwFC0ytaaUqRcMrxpUyLNjfY6xTwTXGmB+aA iZQGh+LArDM7muLDcqLZEk5XXyyF/3gBC9c3uJ/PdkIge77HSyPq4LmPr8R549z7sLa3 3rpYNrtAAVs/pkIjnEn5Kz5Scuzv/d0d0ulAkKGJsY+U7gc5R1nU52p3ynDrfyDGUiVk eyZkiVZKN7G5dxh+AkvgX2skK3U7mkOxBTkUJuh8gE7FcbLahQWGNl3kcBMdEJWzTcXe tY0Cc8ZltyrVArLPSQXAjDbVNSbyxsf26z+kc4p1jSkuH5bjM0mDPV/e/vgqo2ZBxrO0 E14A== X-Gm-Message-State: AN3rC/4UOEIAXPSJVcAV0GG8K6d+61hioixF9FJSnBOza6noVsLXKrbvnOdszeXnoeyDzQ== X-Received: by 10.55.99.69 with SMTP id x66mr8294471qkb.129.1491575449058; Fri, 07 Apr 2017 07:30:49 -0700 (PDT) Received: from [192.168.43.219] (179-240-135-20.3g.claro.net.br. [179.240.135.20]) by smtp.googlemail.com with ESMTPSA id x67sm2974453qkd.67.2017.04.07.07.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:30:48 -0700 (PDT) Subject: Re: top shows more than 100% of CPU usage To: Lars Engels References: <20170407142818.GJ59737@e-new.0x20.net> Cc: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <984dd842-5673-3a13-ce53-db27465bc39b@bsd.com.br> Date: Fri, 7 Apr 2017 11:30:37 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170407142818.GJ59737@e-new.0x20.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:30:50 -0000 Em 07/04/2017 11:28, Lars Engels escreveu: > On Fri, Apr 07, 2017 at 11:25:22AM -0300, OtacĂ­lio wrote: >> Dears >> >> Why top on arm sometimes shows more than 100% of CPU usage? >> > That's because 100% means 100% utilization for one CPU / CPU core. > If you have 4 cores, then utilization can go up to 400%. But I'm getting these results in a beaglebone and as far as I know it only has one core. regards -Otacilio From owner-freebsd-arm@freebsd.org Fri Apr 7 17:26:57 2017 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 166BBD33C35 for ; Fri, 7 Apr 2017 17:26:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 C1C5A105 for ; Fri, 7 Apr 2017 17:26:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22d.google.com with SMTP id p77so37526469ywg.1 for ; Fri, 07 Apr 2017 10:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=0XyT45q8wGdlIGhtukHCZPx8vsNfbTLT/+mlJQnF8Ps=; b=q3pIO68ze1ArdMTqkNrCd38Wm3ECY9IDgPmHlA9UZp0yMyaBufanP+/PfjQ19in/zP +w1TtRCx/XibeZ+JmBchhBB+JZKZEr1YcIIcbhhkeAHQ6pTzRF8YVHVzaeAsk/H4Z51H a6T4ihY2eAI6oJq5833MUFmvlSuFotcVIJugy/AJYZOuxFcqe42x2R4lYxNl17tcyZbA LVFfaade/o5P3GCS4db3QdKK/JekCXfxNeTCXWzfPt4NOyVnPplcR404/YthpK/vM13Z qewgE0vKITI//iQ7uIzJVCrQqcsJy3o0P9ujRTDwUDIcAsMYxVGe9GNRotYsghSyVly9 lYBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=0XyT45q8wGdlIGhtukHCZPx8vsNfbTLT/+mlJQnF8Ps=; b=Y4U2B6T4RW7Si6ChZPOC0GJX2ldk1fXnH5BLGvZC9oTR4ZVBdWl8ZaMCxc978UZd/7 04xGX9iJRjvuFP/hcLAJ8qOLB2wAYpAjiF0I6C5L5rsFzEJPfxJBGwa8Y0QWR8FDTJ6S 1DpnxT8kwsmsxPaWWd4qEOjWzWDaPRJWv9bt6SC+/xZlS/ZGQlbKIXtVOadsD4qBq44X VxLo6lEbANH28iADPXu5BfawIG/IA1FQ6fdWNGIz9bOuWMe3Z1UxXXyIkzV22mw0oQr7 rsQH4be7eIoQkFw4Fvr4sXkibI8psGUu+bv7yjwSW6LLD5sgxXuMaFSWMmkdbNYInWKK dQ7Q== X-Gm-Message-State: AFeK/H3P0hbT23z26Jfo+YLb1Oi7Dvecg7v/Iu6eoNf0G2FT8gLaSLs7ojWcKtYY5df8lPGpedo+Rr3x4UTC6Q== X-Received: by 10.129.108.1 with SMTP id h1mr29489838ywc.302.1491586015570; Fri, 07 Apr 2017 10:26:55 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Fri, 7 Apr 2017 10:26:55 -0700 (PDT) From: Alan Somers Date: Fri, 7 Apr 2017 11:26:55 -0600 X-Google-Sender-Auth: C7VO-Peipyz8FaeslskiZaVX_-s Message-ID: Subject: OT: 96-core 1U ARM server To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:26:57 -0000 System76 is selling a 1U server with 96 Cavium ARMv8 cores and builtin 40GbE. It starts at about $6,000, which isn't bad for something this unusual. Does anybody have any idea what kinds of applications would be good for a system like this? Do any of those applications involve FreeBSD? https://system76.com/servers/starling From owner-freebsd-arm@freebsd.org Fri Apr 7 17:35:55 2017 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 E456DD33F2E for ; Fri, 7 Apr 2017 17:35:55 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 9F0FF9BD for ; Fri, 7 Apr 2017 17:35:55 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-vk0-x230.google.com with SMTP id d188so82107937vka.0 for ; Fri, 07 Apr 2017 10:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7QjdpZw/Qe4iJDRlnRXNB0XeCDIAfprH7ozYd49XGu4=; b=NUavk0fWi/4s54e8HpnNbxtMkug/46csnslspPPLzG7gTESBxw+69yKlrX/ph2gUT6 dfUJEtaqaGvOvfY5qRavgimyoquGRPGiObgpbZrhY1tOgZTYMS0IZ0TSbaTNQek2FJ5d I9U3uc31EzDI8rNy8n4Jyaza4SE3bqSWaxW9s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7QjdpZw/Qe4iJDRlnRXNB0XeCDIAfprH7ozYd49XGu4=; b=Zvt6mCr084+7NUuwuASoahj5l0OKaE7xU+bBtKaS/JvboleXrAJI+PNIB4aOOi7DeU b45wOQ0fdUQB7C3xsg9awRm1Q6jM5I0+1vXB8A3p+Z4Aduax7eujuUaQttohM/RuKD6I uSTZ2HaGaqKl9jIObv4zSBU/CaYngtbdpDj+5vqz5HzbOhAhhXjXDAhTP9q76Sf+4soS zQzUwmhsnlCYGeUAjiz/v34Qa2SSstC19MHN0D9CxdbrsLxyo4xi5CXOU4XZxR0xpbTv 2lgWthmoVLKWhjyRzxWSsBhs94be0GI/QkWYTYTvP8Ukpybytk1Tr9u9unTk1mmtBW2U L/8Q== X-Gm-Message-State: AFeK/H1pv+Pej1+8WTZxm+QMOEIz+zzkVlUChQnF1B9zjzcsCtgFef+m7S7ofYJjlp0vaDIExSvrbEypFGIdfx+i X-Received: by 10.31.13.200 with SMTP id 191mr16492529vkn.28.1491586554516; Fri, 07 Apr 2017 10:35:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.43.3 with HTTP; Fri, 7 Apr 2017 10:35:54 -0700 (PDT) In-Reply-To: References: From: Jim Thompson Date: Fri, 7 Apr 2017 12:35:54 -0500 Message-ID: Subject: Re: OT: 96-core 1U ARM server To: Alan Somers Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:35:56 -0000 ThunderX, best application right now is "scale out" web loads. They start at a single socket for under $3,000 http://www.nextwarehouse.com/item/?2465022_g10e You could try to buy it directly from Gigabyte: http://b2b.gigabyte.com/Rack-Server/ARM-SoC If you can't get inside, lmk, and I'll put you in touch with our mfg rep for them. Jim On Fri, Apr 7, 2017 at 12:26 PM, Alan Somers wrote: > System76 is selling a 1U server with 96 Cavium ARMv8 cores and builtin > 40GbE. It starts at about $6,000, which isn't bad for something this > unusual. Does anybody have any idea what kinds of applications would > be good for a system like this? Do any of those applications involve > FreeBSD? > > https://system76.com/servers/starling > _______________________________________________ > 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" > From owner-freebsd-arm@freebsd.org Fri Apr 7 17:45:33 2017 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 97479D32310 for ; Fri, 7 Apr 2017 17:45:33 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (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 80AF58E for ; Fri, 7 Apr 2017 17:45:33 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.135.229] (nat-192-187-90-114.nat.tribpub.com [192.187.90.114]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 9402075f TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 7 Apr 2017 10:45:32 -0700 (PDT) Subject: Re: OT: 96-core 1U ARM server To: freebsd-arm@freebsd.org References: From: Pete Wright Message-ID: <6c554671-cefc-59bc-97b8-5b653e9e3e39@nomadlogic.org> Date: Fri, 7 Apr 2017 10:45:31 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:45:33 -0000 On 04/07/2017 10:35, Jim Thompson wrote: > ThunderX, best application right now is "scale out" web loads. > They start at a single socket for under $3,000 > http://www.nextwarehouse.com/item/?2465022_g10e > > You could try to buy it directly from Gigabyte: > http://b2b.gigabyte.com/Rack-Server/ARM-SoC > > If you can't get inside, lmk, and I'll put you in touch with our mfg rep > for them. I was pretty impressed with my R&D thunderx system. def agree on the worklaod type - using it for compilation or other cpu intensive tasks it was a bit slower than comparable intel CPU's (Xeon E5-xxxx class). but we had a heavily multi-threaded, network intensive workload that it did a pretty good job handling. the embedded 40Gig NIC on our R&D unit was pretty impressive as well, as was power draw in our lab. sadly i left that gig before i had a chance to advocate to get it into prod - kinda wish i still worked at that job for all the fun hardware i had access to :) -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA