From owner-freebsd-arm@freebsd.org Sun Jan 22 00:32: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 55806CB0B6E for ; Sun, 22 Jan 2017 00:32:36 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7479EA4 for ; Sun, 22 Jan 2017 00:32:35 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id B16E8406061; Sat, 21 Jan 2017 16:24:32 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Karl Denninger cc: freebsd-arm@freebsd.org, hmurray@megapathdsl.net From: Hal Murray Subject: Re: how to measure microsd wear In-Reply-To: Message from Karl Denninger of "Sat, 21 Jan 2017 17:40:10 CST." <7bb4a12d-9b5a-2a81-1ce4-5290e2639a9b@denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jan 2017 16:24:32 -0800 Message-Id: <20170122002432.B16E8406061@ip-64-139-1-69.sjc.megapath.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, 22 Jan 2017 00:32:36 -0000 karl@denninger.net said: > and this one is not a low-hour failure either, nor is it an off-brand -- > it's a Sandisk Ultra 32Gb and the machine has roughly a year of 24x7x365 > uptime on it. Any idea how many writes it did? Does anybody have a script that logs the disk activity, say every hour? -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Sun Jan 22 00:43:15 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 F2504CB0E9E for ; Sun, 22 Jan 2017 00:43:15 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from pv35p22im-ztdg05131101.me.com (pv35p22im-ztdg05131101.me.com [17.133.189.43]) (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 D521C794 for ; Sun, 22 Jan 2017 00:43:15 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from process-dkim-sign-daemon.pv35p22im-ztdg05131101.me.com by pv35p22im-ztdg05131101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OK500700OIAKS00@pv35p22im-ztdg05131101.me.com> for freebsd-arm@freebsd.org; Sun, 22 Jan 2017 00:43:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1485045794; bh=ouhO3VO6DM/cVBuQIvGLTQB09EO3ryqRGoM0KcWD/rA=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=L8qRulB/BxZ9pUNs4F597zXvR4//uT3dsculxomfv10P3Q4IJdN3GN1IfFt0mYUh4 qEHkCZJhFC8iN+BwO7YrbJai/VREyrT4LaQgkM3CsVDbG0IRsxnrj1GbxWTx0qU+/a wiZ0EJ+JfF+Al2G+uOAOBm8rUWgL/Wozdt4Y9WEzc1njEuJRA0oT3VDKSiL6VNRMNC SvJ/Ach7nri90O//CXJpw4WvjjLBcI7AQwtf95x/fAQCJiDqAXY7fhvZFObyPX6q51 8ywiIwWydHoefRNCS53uOYNUqyx++xw9jLCwaARHbk4EVn3sQD+q6qLCzKO44EJ+fT Wl9WtQHdDzisQ== Received: from [10.11.111.236] (50-250-239-90-static.hfc.comcastbusiness.net [50.250.239.90]) by pv35p22im-ztdg05131101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OK500LK6OO17M30@pv35p22im-ztdg05131101.me.com>; Sun, 22 Jan 2017 00:43:14 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-21_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1701220009 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: how to measure microsd wear From: Jordan Hubbard In-reply-to: <7bb4a12d-9b5a-2a81-1ce4-5290e2639a9b@denninger.net> Date: Sat, 21 Jan 2017 16:43:12 -0800 Cc: freebsd-arm@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <8C5C59C9-9AF3-4596-9B36-A792EDE05768@icloud.com> References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org> <7bb4a12d-9b5a-2a81-1ce4-5290e2639a9b@denninger.net> To: Karl Denninger 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: Sun, 22 Jan 2017 00:43:16 -0000 > On Jan 21, 2017, at 3:40 PM, Karl Denninger = wrote: > [ SD cards can fail ] I have to second the assertion that even the comparatively pricy SanDisk = Ultra SD cards can fail in production scenarios all the time, nor do = they even need to be used in a more advanced filesystem role. I go = through a lot of those cards just using them to shoot a lot of GoPro = footage (video and still photos) and I usually get a few weeks out of = each card, filling it almost entirely with footage several times a day, = before it write locks and is ready for the bin. This is why I also = shoot a lot of redundant footage with multiple GoPros, and anyone using = these cards extensively for digital photograph or video will tell you = the same. - Jordan From owner-freebsd-arm@freebsd.org Sun Jan 22 02:53: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 3933BCB0B2C for ; Sun, 22 Jan 2017 02:53:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF8FEC56 for ; Sun, 22 Jan 2017 02:53:54 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v0M2rknr095914; Sat, 21 Jan 2017 18:53:46 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v0M2rkrl095913; Sat, 21 Jan 2017 18:53:46 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201701220253.v0M2rkrl095913@pdx.rh.CN85.dnsmgr.net> Subject: Re: how to measure microsd wear In-Reply-To: <8C5C59C9-9AF3-4596-9B36-A792EDE05768@icloud.com> To: Jordan Hubbard Date: Sat, 21 Jan 2017 18:53:46 -0800 (PST) CC: Karl Denninger , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 22 Jan 2017 02:53:55 -0000 > > > On Jan 21, 2017, at 3:40 PM, Karl Denninger wrote: > > [ SD cards can fail ] > > I have to second the assertion that even the comparatively pricy SanDisk Ultra SD cards can fail in production scenarios all the time, nor do they even need to be used in a more advanced filesystem role. I go through a lot of those cards just using them to shoot a lot of GoPro footage (video and still photos) and I usually get a few weeks out of each card, filling it almost entirely with footage several times a day, before it write locks and is ready for the bin. This is why I also shoot a lot of redundant footage with multiple GoPros, and anyone using these cards extensively for digital photograph or video will tell you the same. > I think I can add some light as to the higher failure rate in your digital video photography usage of the SD cards, your actually likely to write every single block of the device at a pretty regular rate, where as a file system is going to have hot spots of data that gets updated often, but at no where near the over all block write rate your doing in digital photography. I suspect using one as a drive in a security DVR would make for a good write cycle life counter. Probably wearing them out at the rate Jordan is seeing in the GoPro's. In either case the manufactures of flash devices have made it very clear that these things DO have a write cycle life time, and that your going to see a failure eventually if you write enough data to them. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sun Jan 22 03:32: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 4A746CAE80B for ; Sun, 22 Jan 2017 03:32:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 131F5DC for ; Sun, 22 Jan 2017 03:32:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id l66so88767288ioi.1 for ; Sat, 21 Jan 2017 19:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8Jkgw5WLh18r7ET7E3VAd2ar4MGpZw7d3bJh6yS7BHQ=; b=EebyWo3W45p+jFIHUcfTMrsWAz9thTtS186hYOwnKZXMGjph6AiAWrg2ULsCRn8UDx sN4Gdt4rTyvWkSAdr16DMtvaiekS5CO6+XUq82vR/7vJQbgdM1JEZQg+x9qJiBYeP2tH MxKltwfIEeYvYF/BMPYmP950RnBB0R4L98SCsPiH9roExm5byNDMT7FE9QCPw8AV10Yn X+moOG34ApA88ODr0RneCRnq6t0j1TK4E6s2YIjrXXqDc539GQGDeweLjzQ13WGWxOku rqvNPFA+DS+uOoLU0g1izNrvPaYVfx9yuQyhlDaWpPzXryQ8tbpxM+G9EXWvxboyp1zV 8wrQ== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8Jkgw5WLh18r7ET7E3VAd2ar4MGpZw7d3bJh6yS7BHQ=; b=ecnakFGtf7vXqeUzek3Di7le15mcRJGh+E3v6G5LnEMUoHR4obIYqqpbHodAwH3hZW N+mISpgL9EsWxPfq0IHH+wXuVvgojuHCIMXPSVmi80JtEMqfK8b4Td71C+5X2WNGU0vG +XyWNN5QW0uvt7Vv83/gvatdkIppnur6qPGBj2PNw36nfY3fT38uybmSFsfheUydXuWU cu4HEehUas7tWsDCvFuUZK2UPziMiAQspOJpX7zMSAiySTW/pn+QytJL3W6g7BBqd//U jaU+2dBXikiokgaWbimQuyRGpH/nez5mZ3Dd/5RnWfxsIoPvpmU6Vc/NTXDCInu8YZUh oDAg== X-Gm-Message-State: AIkVDXLdpK/UViDrUIAk56WXlsL2+0i/PhK2k13a6E7/X13NMvIDfclHoT8qe3Ngy7pKESYwrFePCG4fUb/bVw== X-Received: by 10.107.139.131 with SMTP id n125mr21294482iod.166.1485055959016; Sat, 21 Jan 2017 19:32:39 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sat, 21 Jan 2017 19:32:38 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <1485025911.34897.199.camel@freebsd.org> References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org> From: Warner Losh Date: Sat, 21 Jan 2017 20:32:38 -0700 X-Google-Sender-Auth: BRFjIRjVMjQ_iVBdlAxXoGn2Mlw Message-ID: Subject: Re: how to measure microsd wear To: Ian Lepore Cc: Karl Denninger , "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, 22 Jan 2017 03:32:40 -0000 On Sat, Jan 21, 2017 at 12:11 PM, Ian Lepore wrote: > On Sat, 2017-01-21 at 12:12 -0600, Karl Denninger wrote: >> On 1/21/2017 11:58, Ian Lepore wrote: >> > >> > On Sat, 2017-01-21 at 15:46 +0000, tech-lists wrote: >> > > >> > > Hello list, >> > > >> > > How would one measure microsd wear? Is there a utility like >> > > smartmontools (I think this only works for regular hard drives) >> > > but >> > > for >> > > microsd? >> > > >> > > many thanks, >> > There is basically no way to see what's going on in the flash array >> > of >> > an sdcard. The microcontrollers in modern sd cards have complex >> > wear- >> > leveling algorithms which are completely transparent to the outside >> > world. >> This is true. >> > >> > On the plus side, most of what you see in the way of warnings and >> > scare >> > stories about wearing out sd cards is pure BS. I've got systems >> > here >> > that have been running for literally years on the same sdcard, and >> > that >> > card is being used for swap, and routine data storage like syslog >> > (on >> > an embedded system that logs status and progress pretty much >> > continuously 24x7 for years). I've seen a few sd cards die over >> > the >> > years, but I've never been able to say it was because of how much >> > was >> > written to them (indeed, the dead ones I've got weren't in service >> > long >> > before they died). >> > >> This, however, is total nonsense. >> > > Well, no, it's not total nonsense, it's my 10 years of experience > professionally working with sd cards in embedded systems sold as > commericial products, including extensive testing of the card trying to > *induce* failure. > > Next time think twice before implying I'm either a fool or a liar. > > I'm not even going to read the rest of the crap you wrote, since it's > completely invalidated by the stupid thing you said above. Yea. I've killed enough SD cards to say that extra writes are an issue. I've personally written flash reliability systems. I can tell you that saying "all SD cards do" is automatically wrong. Some SD cards are awesome: they are fast, reliable and rarely brake. Others are slow, unreliable and crap. Utter crap. Not worth the time it takes to order them. It all has to do with the type of NAND that's in the card. Some of it has been SLC which you can write 20k times without even breaking a sweat. Others is TLC which is doing good for 100-200 writes. There's a huge difference between these two polar extremes. On the latter it is super critical that one writes as little as possible because a 32GB card may only have 3.2TB written before they are in the danger zone, which is super easy to do. So maybe some people get lucky and don't have problems. I've never blinded myself by staring at the sun, but that sure doesn't make it a safe thing to do. Warner > > -- Ian > > >> I've had multiple SD card failures in build/test/high-volume write >> environments on the PI2 series over the last year and change. There >> are >> two general ways in which you will see failures: >> >> 1. The card write-locks itself. This is a defensive move by the >> controller when it determines that it cannot reallocate a failed >> block >> during a write (e.g. it's out of spares) OR it takes an unrecoverable >> read error. >> >> 2. The card loses its allocation map (in which case you're completely >> screwed; it will show up as zero size if you manage to get it mounted >> somewhere.) >> >> If you get a type 1 failure you can copy everything on the card off; >> provided you do not attempt to write it, you will not get >> errors. Prior >> to a fairly recent MFC if you had soft-updates on and took a Type 1 >> failure you'd get an instant panic; this has been (I believe >> entirely) >> fixed. >> >> In the event you get a Type 2 failure there's nothing you can do. In >> both cases the card is junk if it happens. >> > > _______________________________________________ > 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 Jan 22 04:29:37 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 59D20CBA885 for ; Sun, 22 Jan 2017 04:29:37 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id F299F98B for ; Sun, 22 Jan 2017 04:29:36 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id E192213381 for ; Sat, 21 Jan 2017 22:29:35 -0600 (CST) Subject: Re: how to measure microsd wear References: <20170122002432.B16E8406061@ip-64-139-1-69.sjc.megapath.net> To: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: Date: Sat, 21 Jan 2017 22:29:32 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170122002432.B16E8406061@ip-64-139-1-69.sjc.megapath.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070404060709020904080902" 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, 22 Jan 2017 04:29:37 -0000 This is a cryptographically signed message in MIME format. --------------ms070404060709020904080902 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/21/2017 18:24, Hal Murray wrote: > karl@denninger.net said: >> and this one is not a low-hour failure either, nor is it an off-brand = -- >> it's a Sandisk Ultra 32Gb and the machine has roughly a year of 24x7x3= 65 >> uptime on it. > Any idea how many writes it did? Offhand, no. I did not expect this particular device to have a problem given its workload, but it did. It could have been a completely random even (e.g. cosmic ray hits the "wrong" place in the controller's mapping tables, damages the data in it a critical way, and the controller throws up its hands and says "screw you, it's over.") There's no real way to know - the card is effectively junk as the controller has write-locked it, so all I can do (and did) is get the config files and application it runs under the OS off it and put them on the new one. The other failures were less-surprising; in particular the box on my desk, given that I compile on it frequently and that produces a lot of small write I/O activity, didn't shock me all that much when it failed. One of the big problems with NAND flash (in any form) is that it can only be written to "zeros." That is, a blank page is all "1s" at a bit level, and a write actually just writes the zeros. This leads to what is called "write amplification" because changing one byte in a page requires reading the page in and writing an entire new page out, then (usually later) erasing the former page; you cannot update in-place. If a page is 4k in size then writing a single byte results in an actual write of 4k bytes, or ~4,000 times as much as you think you wrote. This is also one of the reasons that random small-block write performance is much slower than big writes; if you write an even multiple of an on-card block the controller can simply lay down the new data onto pre-erased space, where if you write small pieces of data it cannot do that and winds up doing a lot of read/write cycling. It gets worse (by a lot) if there's file metadata to update with each write as well because that metadata almost-certainly winds up carrying a (large) amount of write amplification irrespective of the file data itself. All of this is a big part of why write I/O performance to these cards for actual filesystem use is stinky in the general case compared against pretty-much anything else. The controller's internal logic has much voodoo in it from a user's perspective; the manufacturers consider exactly how they do what they do to be proprietary and simply present to you an opaque block-level interface. There are rumors that some controllers "know" about certain filesystems (specifically exFAT) and are optimized for it, which implies they may behave less-well if you're using something else. How true this actually might be is unknown but a couple of years ago I had a card that appeared dead -- until it was reformatted with exFAT, at which point it started working again. I didn't trust it, needless to say. SSDs typically have a published endurance rating and a reasonable interface to get a handle on how much "wear" they have experienced.=20 I've never seen either in any meaningful form for SD cards of any sort.=20 In addition SSDs can (and do) "cheat" in that they all have RAM in them and thus can collate writes together before physically committing them in some instances, plus they typically will report that a write is "complete" when it is in RAM (and not actually in NAND!) Needless to say if there's no proper power protection sufficient to flush that RAM if the power fails unexpectedly very bad things will happen to your data, and very few SSDs have said proper power protection (Intel 7xx and 3xxx series are two that are known to do this correctly; I have a bunch of the 7xx series drives in service and have never had a problem with any of them even under intentional cord-yank scenarios intended to test their power-loss protection.) I'm unaware of SD cards that do any of this and I suspect their small size precludes it, never mind that they were not designed for a workload where this would be terribly useful.=20 The use envisioned for most SD cards, and their intent when designed, is the sequential writing of anywhere from large to huge files (video or still pictures) and the later sequential reading back of same, all under some form of a FAT filesystem (exFAT for the larger cards now available.)= IMHO the best you can do with these cards in this application is to minimize writes to the extent you can, especially small and frequent writes of little actual value (e.g. mount with noatime!) and make sure you can reasonably recover from failures in a rational fashion. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070404060709020904080902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjIwNDI5MzJaME8GCSqGSIb3DQEJBDFCBEDwYObI PCJD4wSASsw+8EO0w4ZGdFmPuJDKzUXCBSxOJ/8aQvvY1NHl2XW0tDiEMcCBSaAhI7Li77KB MQj5RTD0MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAgUo8F8FLpAWb EOFgiH3tCI5skGzmZNqPYaTO5T6hJ1xDKkzeR0P5krDtjR7zX8Bc1Pa6wvTZ5zHd39gWLkcG QZ3sj49hLGdt5pSO7s+Rf9AMcqY4x3DB85JBMQ2DC7gC5FjBCZOGx1OtNB+hnucd9zd8X4qO 3Dnoez8ZV0dSMzEV2kQMEaB3ctSR6Q1SRTWbhXi/ffV2BN7uLr6OJDOfCF8N2AfKYWiUxddI RiOYZGcuHZ3kKdNHq2HoHs0qSTkDCzB4ynnLSi1+sFtYlgCSzRQaT6SXV87ff5yVXCgzJ4yl 885u6PyCP8k1yXKy6zzjYuDsEF7d5x/JvtzYOMs8EKCqhYTl97ICdem2mmJkqKqMEwLJCPeo yde1jmvQrNA/+6G3zrYUiZdEMHTNtRzXD3rRSMLiaVbdVcyXZVVqLAa+YZl/vVXNqhUWeLEV LX7ncr8RaMHIysIcSMKeDvWhxtHwW+DnU2beJEou4DTIOc9gG0R9QlpW2wms6XszesGNAfcM t6B2zXQQ2WNfJ0Zf6Tx8qBZ6tQ0p+0JnT8YHdPeJBzrKpKzhcJOoWrJwnYpvX5rNeu6gjOUz PFP/hVIl4zs4kheQChHXpnUAxVujl+sjg3MwOlWkcMQRYpxQnm+zIX4HdJNrIcGUitiPKhKu FqeE/DBbs+PZcqY/q6dlRWwAAAAAAAA= --------------ms070404060709020904080902-- From owner-freebsd-arm@freebsd.org Sun Jan 22 04:33:22 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 CD397CBAAA3 for ; Sun, 22 Jan 2017 04:33:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ABBAFC58 for ; Sun, 22 Jan 2017 04:33:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id AB0C4CBAAA1; Sun, 22 Jan 2017 04:33:22 +0000 (UTC) Delivered-To: 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 AAB1DCBAAA0 for ; Sun, 22 Jan 2017 04:33:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 742ABC57 for ; Sun, 22 Jan 2017 04:33:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id l66so89198931ioi.1 for ; Sat, 21 Jan 2017 20:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5JOHyiRIGDONi4ZMA6yeqk3CBkBPhilozir4YojsaHc=; b=H8/5e+zp88T6EsskNBusRROO1xWqFEE6aYeFe2z52621Al6fE1nT1WDLGMYOM/CFxV oUacNf7PgmwHOoybcGJcN5pk+1C9LflL9Fbm3dsnFFqYRUyRpppiGHWNEW2eAkvsHyey Ad9SH9YaaG3Fh/1fg/jRUoETfYNHm8QXrbAduJBTtIR482hPCJtlpRGuTMIT3Y2l2+1U uQeifmheICUS1BJ9bQP4AXHLriqXswRBVIhjI6uPYfI+PYGM9eWM5kLFXOH5B18UguJk jdK3MsVrqUZVj4kardytepjdwQmdQdh7elM7Xi3/WP3kkG6rce86mxGpES6ypMhofG2D Z6Wg== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5JOHyiRIGDONi4ZMA6yeqk3CBkBPhilozir4YojsaHc=; b=PVmIW6BP/M+lMg5hpo8YEKGIQdrT0Dky/H4hN/LWdUA4xAtsQSEsMP3FHlnj5qW2b5 Y7alsTU4ohaix1/dQGUBts0pZM4VN0KD6mYiYTVPhpLrWVNCj64esUQamT4T2gE0BvmK eNMwe3Q+hNcLoW3zulovJttOqAgKx0636Hkmli6E03Ve5dtV48rMFQCsweikYyg+uDok Xi+DP3bozs1YzcBZoYH7ENfwb734+s8TdxV+LQuO4zZDily0D0ZoOdV/tezoH4cRGP0B gqneRr5ktpO04MJC26FgC91qKQuWnWvhwdJAeKdk3gT7Vt1QfDaFL75MTeWIv7//NmjW knIg== X-Gm-Message-State: AIkVDXK/fHRhBY5jVFKAi5HhJ7b4JXtvEboPaV+vSeh9fniuM5VG2oqlXhbsXqkAgjH4yj0YDjwO26byblKQ8A== X-Received: by 10.107.198.195 with SMTP id w186mr19733994iof.19.1485059601721; Sat, 21 Jan 2017 20:33:21 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sat, 21 Jan 2017 20:33:21 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <6DC50B90-AB89-41A6-9C0F-82872E2B9E99@cs.huji.ac.il> From: Warner Losh Date: Sat, 21 Jan 2017 21:33:21 -0700 X-Google-Sender-Auth: aefCN9_c_O9x-b0bPPgVUzd7O9A Message-ID: Subject: Re: usb on NanoPi NEO not working To: Ganbold Tsagaankhuu Cc: Daniel Braniss , "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, 22 Jan 2017 04:33:22 -0000 On Sat, Jan 21, 2017 at 6:41 AM, Ganbold Tsagaankhuu wrote: > On Sat, Jan 21, 2017 at 9:26 PM, Daniel Braniss wrote: > >> Hi, >> I managed to boot current on this board, but some things are not >> working, i.e., the stat led, >> but more important, the usb is unusable. >> >> does someone have a correct fdt for this board? >> > > First, are you using correct u-boot for it? > > https://github.com/jaredmcneill/freebsd-ports/tree/u-boot-nanopi-neo/sysutils/u-boot-nanopi-neo Any reason we can't roll this into the current u-boot master framework? Warner > I'm using attached dts in FreeBSD. > > Ganbold > > >> >> danny >> >> _______________________________________________ >> 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 Sun Jan 22 05:07:41 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 E0709CBAF92 for ; Sun, 22 Jan 2017 05:07:41 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 96B6E843 for ; Sun, 22 Jan 2017 05:07:41 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-yb0-x236.google.com with SMTP id w194so78878016ybe.0 for ; Sat, 21 Jan 2017 21:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FApYUkP+FJdIM62A/MGFrKiboabfARN1oPHnaCHIOSI=; b=PgHzGZ53mLihHAT9f63mT+vghX1fcE0cZfMckl5HocJ1xkLXtxLPpppMi+ZddwgwF6 SNW8Vmv1iBIcEToOUoYYfy8KlaJ6f0PWl7G26i8bR44ujutC96AZo8V/B/n4oA/ypjx5 68Ffu0GkDO3QLEjM/O3J1cKcA9yYUTj5UKdqbq1cFNJuehXfUxpYAOwftTfhGHt4CsLA yzUe94FOK+rjc/984/BVjmBVVSogErfwzSO3QFoLx6/OKz6eTcF7MeKmDcU9BqchuXx6 ODu+U3dqEUU5Mhbi5fFbCf3t8GRR5Rz4FlBwkuwnK4PYIHoGWTfhwlMomLBObqW11qqz Oihw== 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=FApYUkP+FJdIM62A/MGFrKiboabfARN1oPHnaCHIOSI=; b=iaZ40WXK2kW1Q+lOQtXUG9YuLmB9SDNF5/N0hyaAJg66V393rfDZkxN8dKQuK2kU6B N+gZ39KfINaFu3h9ZRW/AlK/xePjaNh6/W8XLVS9CO5XSwBfPiUl3/1t85lyrsaM+X+S QrGmzHVIdPODOnhZmiiod8RBe+VF3xI6yeGMl2FGQXVKMV3bgsYadi0t/Fo8JIuEkJqR cffquwZF7hV4uWSTsd+Xzzht2oSmKhO4BFC0JJEo9Eetwtq/0D+iNjFJF23rByHdCd3R dFJ4UbblYmdjChcIC4sA3yLmjAJcLkaR1mDRePxKzioONjghS/QTmXyZwrOtSwmrcSoZ VymA== X-Gm-Message-State: AIkVDXKfsoqG8tOa6ygsm8Q4RAUIJHzZWR++blC4sucWr5JY/tIjAVyaEXjMByNKrIwSwv2pWaCHHiJhiUpetA== X-Received: by 10.37.224.77 with SMTP id x74mr15622522ybg.80.1485061660673; Sat, 21 Jan 2017 21:07:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.231.135 with HTTP; Sat, 21 Jan 2017 21:07:40 -0800 (PST) From: Dustin Marquess Date: Sat, 21 Jan 2017 23:07:40 -0600 Message-ID: Subject: Getting the kernel to let go of my UART! To: 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, 22 Jan 2017 05:07:42 -0000 [Sorry if this is somewhat of a dupe, I have yet to find a solution] I've been running FreeBSD on my Pi 3s for a little over a month now, first using gonzo's SMP code + a home cross-compiled kernel, and then I moved to the HardenedBSD images. All of them work great except one issue that's driving me nuts... The downside to the Pi 3 vs some other boards is that there's really only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with a GPS board. 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and that's "fixed". 2nd issue: Even with a USB keyboard attached and HDMI output connected, FreeBSD still wants to steal the first uart (ttyu0) as a console port. I thought that would be fine as long as I use "-m -n -q" in the boot config to disable kernel output and then "conscontrol delete ttyu0". Well, that KIND of works. It seems to work fine when using 115200bps, but trying to change the baud rate to match the GPS unit doesn't seem to work at all, I'm guessing because it's still set as an available console? hint.uart.0.flags="0x0" doesn't work, as it still marks it as a console. console="efi" seems to be the only setting that works, "vidconsole" and "nullconsole" both don't work. Is there a way to stop the kernel from trying to claim the UART as a console? Thanks! -Dustin From owner-freebsd-arm@freebsd.org Sun Jan 22 05:16: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 69D44CBC180 for ; Sun, 22 Jan 2017 05:16:44 +0000 (UTC) (envelope-from wlosh@bsdimp.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 3341EB8B for ; Sun, 22 Jan 2017 05:16:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id l66so89505151ioi.1 for ; Sat, 21 Jan 2017 21:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hNQRuJSGuoavci/DUnlX8i4R7tQaeQ4Pi5+kGEv0xG4=; b=wjNLOMGR0Fcl7hdS0xbGPWnWcBVtasqbMlEWY9BTIN2hvoA33YjCeWcQ6PS/wJ4wBt bBIbLjKVyRxdXzpLheBioJgD4j+KR0GjavrxoMPYfxzuuiTPLwg9xHaczF8neMspWAJX hxav5Gu4bhUGaIQlA1il7JR03QX3a0ilhphAextFJtZoQnBIC4aR8wupDyL8Izwhnrqm mdgdOELJb8bzttTJtpANMH4bK8F7iwcEuoK6Y1L3n3aB0IM5HvwW523sDBrL4uDOMgVl vIC9sQrrBpGzA5aLL3b2gZsolHljlx8u65rZpKnOC7nWTUTZHMLI7QTnFiS5ulhofq4Y En1w== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hNQRuJSGuoavci/DUnlX8i4R7tQaeQ4Pi5+kGEv0xG4=; b=VLvqtj4D2BCIMTKts1xC5uP6Yw7qkBEoTLw8t29kUoVypTWWTY4iMVnNuM9z1cQm/k D9VCRDITzLzkOIBSDrlrHO6o1RN4sxA2DJqh8o4GeFAvBuSk0T7vywKKyN4dGeXrF+bA YRjDDXFttchOZVTGaLLaFUd0jwARC0wtH0NlYAdKVLeJdvE/sNyOzLBF4Uf6xBLmMqjz 9uU5J7HLaAE8fCsDCzONzOgGIDdkw/AMZ8lu9jo5qsUU8cn7LK06KTBSizxMQ8bjKZxA KcIik1almpVAvTU24qUiDteyFZSPoD1vyYUSXnMelUVg5NMQxBDxk7p2nN1BW6E4kuTl kkgw== X-Gm-Message-State: AIkVDXKodNgU1eLXbdD4yY2wWEigTOPdW0gjHMYfIkwVGVNlDWJuw9xSwIoKVQ8xAhAWlgGmQRVdb6wcSiHC9A== X-Received: by 10.107.198.195 with SMTP id w186mr19808184iof.19.1485062203407; Sat, 21 Jan 2017 21:16:43 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sat, 21 Jan 2017 21:16:42 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20170122002432.B16E8406061@ip-64-139-1-69.sjc.megapath.net> From: Warner Losh Date: Sat, 21 Jan 2017 22:16:42 -0700 X-Google-Sender-Auth: jbbdXtyMLBPERhX1HZ9l25n8cBw Message-ID: Subject: Re: how to measure microsd wear To: Karl Denninger 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, 22 Jan 2017 05:16:44 -0000 On Sat, Jan 21, 2017 at 9:29 PM, Karl Denninger wrote: > On 1/21/2017 18:24, Hal Murray wrote: >> karl@denninger.net said: >>> and this one is not a low-hour failure either, nor is it an off-brand -- >>> it's a Sandisk Ultra 32Gb and the machine has roughly a year of 24x7x365 >>> uptime on it. >> Any idea how many writes it did? > Offhand, no. I did not expect this particular device to have a problem > given its workload, but it did. It could have been a completely random > even (e.g. cosmic ray hits the "wrong" place in the controller's mapping > tables, damages the data in it a critical way, and the controller throws > up its hands and says "screw you, it's over.") There's no real way to > know - the card is effectively junk as the controller has write-locked > it, so all I can do (and did) is get the config files and application it > runs under the OS off it and put them on the new one. If you are lucky, the SD card will fail 'read only' rather than 'read never'. :) You're correct that once you go into that mode, however, you can't get out of it with standard interfaces. There are rumors of vendor specific ones that are used to diagnose failure modes, but I've never been able to find out more about them as they are firmware specific. The NAND chips, however, remain generally readable and you can do a hunt to see what's what. I say generally, though, because the list of failure modes for NAND chips is scary.... > The other failures were less-surprising; in particular the box on my > desk, given that I compile on it frequently and that produces a lot of > small write I/O activity, didn't shock me all that much when it failed. > > One of the big problems with NAND flash (in any form) is that it can > only be written to "zeros." That is, a blank page is all "1s" at a bit > level, and a write actually just writes the zeros. Yes and now. Erasing a page will set it to all 1's. Programming a page will move the charge nodes from the 'erased' state to the 'programmed' state. What this means varies a lot based on the type of NAND. SLC, sure, it goes from 1 to 0 (although the node for 1 still moves a bit). For MLC or TLC, it's a lot more complicated because you're encoding 2 or 3 bits into discrete voltage level. You have to do the proper dance and program the pages in the correct order with the correct 'randomizations' in the data (either inside the chip, or external to it) to make sure that the 'white balance' of bits is very close to 50/50. Also added in this pipeline is the ECC or LDPC error coding to ensure that the crappy NAND can recover from the inevitable bit errors that you know will happen. > This leads to what > is called "write amplification" because changing one byte in a page > requires reading the page in and writing an entire new page out, then > (usually later) erasing the former page; you cannot update in-place. The erase and program causes this, yes. But write amplification happens when the drive has to garbage collect blocks off its log to find blocks it can write new blocks. It is different than the effect you are talking about which seems to ignore the LBA to phyiscal translation layer that's in the drive that's hidden from the user. > If > a page is 4k in size then writing a single byte results in an actual > write of 4k bytes, or ~4,000 times as much as you think you wrote. No, that's not how it works. First off, there's no interface for writing one byte (just programming a page). Second, the OS will translate writing one byte to writing one block which will cause a new page to be written to the end of the log. Flash memory is erased BLOCKS at a time (usually a few hundred pages) and programmed a page at a time. When you write a new block, it gets appended to the end of the "log" with a note about the new LBA to physical mapping. Also, pages are usually larger than logical blocks, so you often wind up with multiple blocks living inside a single page. The cause of write amps are when LBAs are re-written creating "holes" in the map. The erase blocks that are most empty are usually selected to be garbage collected (the valid blocks written to the end of the log and the erase block erased to use for new writes). So write amp tends to trend as the inverse of the number of spare blocks in the system... > This > is also one of the reasons that random small-block write performance is > much slower than big writes; if you write an even multiple of an on-card > block the controller can simply lay down the new data onto pre-erased > space, where if you write small pieces of data it cannot do that and > winds up doing a lot of read/write cycling. Actually, that's crap too. The reason that small writes are lower performance is down to internal structures on SSDs that block the physical writes (say 512 or 4k) into a larger page (say 32k or 64k) to keep the metadata on the LBA to physical mapping down. So they do a read, modify write, which adds a tREAD and some buffering time and increases write amp. > It gets worse (by a lot) if > there's file metadata to update with each write as well because that > metadata almost-certainly winds up carrying a (large) amount of write > amplification irrespective of the file data itself. All of this is a > big part of why write I/O performance to these cards for actual > filesystem use is stinky in the general case compared against > pretty-much anything else. Blocks are blocks. Metadata doesn't matter. Blocks get appended to the device log, so when you write them, it doesn't matter where on the disk. > The controller's internal logic has much voodoo in it from a user's > perspective; the manufacturers consider exactly how they do what they do > to be proprietary and simply present to you an opaque block-level > interface. There are rumors that some controllers "know" about certain > filesystems (specifically exFAT) and are optimized for it, which implies > they may behave less-well if you're using something else. How true this > actually might be is unknown but a couple of years ago I had a card that > appeared dead -- until it was reformatted with exFAT, at which point it > started working again. I didn't trust it, needless to say. Different drives have different strategies. But the exFAT special case, when it is still used at all, is confined to SD cards, SSDs don't use it anymore. > SSDs typically have a published endurance rating and a reasonable > interface to get a handle on how much "wear" they have experienced. > I've never seen either in any meaningful form for SD cards of any sort. > In addition SSDs can (and do) "cheat" in that they all have RAM in them > and thus can collate writes together before physically committing them > in some instances, plus they typically will report that a write is > "complete" when it is in RAM (and not actually in NAND!) Needless to > say if there's no proper power protection sufficient to flush that RAM > if the power fails unexpectedly very bad things will happen to your > data, and very few SSDs have said proper power protection (Intel 7xx and > 3xxx series are two that are known to do this correctly; I have a bunch > of the 7xx series drives in service and have never had a problem with > any of them even under intentional cord-yank scenarios intended to test > their power-loss protection.) I'm unaware of SD cards that do any of > this and I suspect their small size precludes it, never mind that they > were not designed for a workload where this would be terribly useful. > The use envisioned for most SD cards, and their intent when designed, is > the sequential writing of anywhere from large to huge files (video or > still pictures) and the later sequential reading back of same, all under > some form of a FAT filesystem (exFAT for the larger cards now available.) That's kinda true. SD cards have no room for super caps. However, the black art that goes into the SD cards have allowed for this and they have reliability guarantees of their own, but they go slower for it. They generally don't have large DRAM buffers, and generally write throttle to NAND rate pretty quickly. If you aren't lying to the OS by saying the write is complete to win on IOPs benchmarks, the reliability issues go away. Where SD cards fall down is their firmware is usually rubbish at recovering from certain kinds of errors. The usual one of a camera that loses power while writes are going on generally work (basically a sequential workload) because the meta-data they need to keep book is usually written in a reliable way. Usually, but not always, which is why I usually rate them as rubbish. > IMHO the best you can do with these cards in this application is to > minimize writes to the extent you can, especially small and frequent > writes of little actual value (e.g. mount with noatime!) and make sure > you can reasonably recover from failures in a rational fashion. That's true, but for none of the reasons that you suggest. The reasons have more to do with the log structure the devices are forced to used coupled with newer NAND nodes that have lower and lower endurance. The good 3d NAND that gives back to endurance again are reserved for the NVMe and SSD drives, but it is starting to show up in high-performance SD cards as well, though they are still pricy. BTW, I worked at Fusion I/O for a few years writing their 'on load' driver that did all these things and learning about all the tricks that are used in the industry. My main area of focus was the NAND reliability models that were used to get better performance later in life out of crappy NAND and to ensure the drives could go 5x the manufacturer's stated endurance numbers with lots of clever tricks. Secondarily, I worked on garbage collection and radix tree design to help improve our drive's performance under a variety of work loads. Warner From owner-freebsd-arm@freebsd.org Sun Jan 22 05:24: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 6C25FCBC471 for ; Sun, 22 Jan 2017 05:24:35 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 EE9D6FE7 for ; Sun, 22 Jan 2017 05:24:34 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id d140so17421519wmd.2 for ; Sat, 21 Jan 2017 21:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version; bh=r6YvTh2kDJQFAMgc0IHNBT2q35tVkvf+xcPSeNLyHrM=; b=A91vKWNWFj03ctrC3LLS/HEmIVieukiVPktQ5/grvOMtgBes9VxQH8NKVe2IWKlIOB dPkY8chr3JctSC7b+nDIurxypvotMcmATJeQe4X0c/qc+CuLkgKmgZwPggPbFp7pVGS8 oB5oYFHKc2TW6JOUuDuAUuCStf58sY2/5xvwK1KNNOXcLKndVD8hN9tUTGEvDjiRvHjS HjnOgc3LeJlPJHpze3DgWS15JbkdemprJ7FGinaC+HudcZQ9/X6n5wBp0Ghx7wukKFz7 9WKaGERAtX1tEEMHIgtO7nyWKspAZljLXUcCXrY3r1AQVCMc4UtJoyAwRVmxjkilyMt4 C8nA== 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:in-reply-to :references:organization:mime-version; bh=r6YvTh2kDJQFAMgc0IHNBT2q35tVkvf+xcPSeNLyHrM=; b=WlcmwspzgphVO4pNZY9uFkbBpXBpEOtTFDAPo1jRkXQPlQiaqwpXz5AtOs15acnL9i 1OeGuwJKDanji4shtTS4rPGJtKcn4uI6YLDkAYsSZVYRT4ZTC8s+Y/Gk/K1oVPJOZIwf zuac2HBYdMpsQOIDdkIiUzecVOCnbn/aACMNEbFmK+IkThZ0I/jsf8+ikpu9iIQF+1fY wLS1qPVeXzq0sULGm2J36efhxhWkoD73G8sHdy7g7aTsMksfbjhIcfUvf/4U70aqg3El j5dZEcSogNyH3yUKibvBX/quOfMcgKGp2Cobysi5YCLFxXLs9wK4gZ3/w+9N9Wc2Fleu RbTA== X-Gm-Message-State: AIkVDXKDTZe7/d0swfiOJRa2O/PuDcdnFh57jRcUUH+z6kYV5LduTUzacINe+02RX1iJoQ== X-Received: by 10.28.143.5 with SMTP id r5mr9331096wmd.141.1485062672371; Sat, 21 Jan 2017 21:24:32 -0800 (PST) Received: from planb.netng.org (85-237-234-56.dynamic.orange.sk. [85.237.234.56]) by smtp.gmail.com with ESMTPSA id y30sm7595761wrc.23.2017.01.21.21.24.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2017 21:24:31 -0800 (PST) Date: Sun, 22 Jan 2017 06:24:20 +0100 From: Vladimir Botka To: Warner Losh Cc: "freebsd-arm@freebsd.org" Subject: Re: how to measure microsd wear Message-ID: <20170122062420.101cb9ea@planb.netng.org> In-Reply-To: References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org> Organization: na X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/jNnw=+27BJax..fAvGeNqOl"; protocol="application/pgp-signature" 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, 22 Jan 2017 05:24:35 -0000 --Sig_/jNnw=+27BJax..fAvGeNqOl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Warner, On Sat, 21 Jan 2017 20:32:38 -0700 Warner Losh wrote: ... > Some SD > cards are awesome: they are fast, reliable and rarely brake. Others > are slow, unreliable and crap. Utter crap. Not worth the time it takes > to order them. ... Would it be possible to share the brands? Thank you. -vlado --Sig_/jNnw=+27BJax..fAvGeNqOl Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYhEIHAAoJEJDRmRKO1E8BPsIH/RO4YRcPjN5SEmelU6XyrsUB 6FuT1O0R0VFtCujI4HzYxfQzZhcV+eiX2wWyPLFpieCf5VfoASxo3gnQ20lzOi0P GNCWecGi4/AmmC9CfN3SHBrWMs5y+KusrYCLFkfAZymahCMbent2fA3+IZ7xYhmi 8ID+b6NfPqrT7jSgeYxKg+STWrMGfiHBK1Ye7h4aB4j0U2u4uI5TFza4wGJ/V4SW /zRAYBHJiYiF9Ws7BLYgH4hq8VeihthOeoAdYvRE0kS+5uRJeijJQouCbYnP8z8X PRzY8+TBKvwcYd999CQOUtODXpth8sAr2aBvwei5bt/AqZmUIXHBYRAsVcaOBag= =rlTD -----END PGP SIGNATURE----- --Sig_/jNnw=+27BJax..fAvGeNqOl-- From owner-freebsd-arm@freebsd.org Sun Jan 22 06:03:54 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 489BACBCD70 for ; Sun, 22 Jan 2017 06:03:54 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 261EC8B7 for ; Sun, 22 Jan 2017 06:03:54 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2266BCBCD6F; Sun, 22 Jan 2017 06:03:54 +0000 (UTC) Delivered-To: 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 21FEFCBCD6E for ; Sun, 22 Jan 2017 06:03:54 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 DA35F8B6 for ; Sun, 22 Jan 2017 06:03:53 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ot0-x22b.google.com with SMTP id 65so82741928otq.2 for ; Sat, 21 Jan 2017 22:03:53 -0800 (PST) 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=PKQt1vLr+5bURtDi3ionIP0AP4aYqW0tC56kvon6s7c=; b=LMVZPO4dN3ECT0D3JE/aWZkf7TgPPlDxhzB3Yq44WlhVIelnGFtcQ4elp+HW83JPPt QM+9kn7auPpA1XpGUaBq1oGzEZIp6sQTWrC1vCPSpCx4UG0HUfuLSSvas2g80+ltqSNo Uq1kGA3rE4v8QEasBe7ANhD0ZiX8SJYTlYIyTXGuQQvm8WqkMCPXX4gP/Ura006t9c8j WH9VGgKOclc2Vg98hHrFUIF3HYvMP3sUR55MkmDbKcOVI7xLVjXUxMSpYRxhYch3EGIl 4GmpsbEQrSqytE/fqznO36d9UZDnWPJ0SyN+lf+5Z0njd7xCIVN+UXINbzv1ISoVR6jv /+Ug== 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=PKQt1vLr+5bURtDi3ionIP0AP4aYqW0tC56kvon6s7c=; b=tGEglWeWLl4M+qih6Jlxgu7LaJBzNPXEhkgp8sGUw5Eql66JQZadScgTsrUgKu4iiL WWUozfvT2mH6q2aA9wAhHGOcgIK7UfqSqqYW0qE6g2fMLDSHqVDuQPjXDX481h+k5QqQ 4A2d/OdfwobJxqvsRhTij8wSfm1ODtbeQs8uMokAbF/IMuc4Qn9aoS0HAM6HS3fCCAdD 2qhE+9XuCYbNew8tF4fv4An8J9jCN9zJ5LhOS7GETg3I2AUEftHuS/R0QE3MV6nSJDvh p8OCuHb0IBOOJpk3EVE+/7z+yR/9kjufH0XGpxxK25P/CPI17GYczzEU5l/TZQpixTBZ +pfA== X-Gm-Message-State: AIkVDXIVxT1azO6sU/4S82N0GnsdqF2bUN74Ckrth0GvHlO7VHWVpMwx4kECA3wjopKVe8BXCgNZXnrkspNfig== X-Received: by 10.157.47.234 with SMTP id b39mr10630871otd.0.1485065033176; Sat, 21 Jan 2017 22:03:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.221.71 with HTTP; Sat, 21 Jan 2017 22:03:52 -0800 (PST) In-Reply-To: References: <6DC50B90-AB89-41A6-9C0F-82872E2B9E99@cs.huji.ac.il> From: Ganbold Tsagaankhuu Date: Sun, 22 Jan 2017 14:03:52 +0800 Message-ID: Subject: Re: usb on NanoPi NEO not working To: Warner Losh Cc: Daniel Braniss , "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, 22 Jan 2017 06:03:54 -0000 On Sun, Jan 22, 2017 at 12:33 PM, Warner Losh wrote: > On Sat, Jan 21, 2017 at 6:41 AM, Ganbold Tsagaankhuu > wrote: > > On Sat, Jan 21, 2017 at 9:26 PM, Daniel Braniss > wrote: > > > >> Hi, > >> I managed to boot current on this board, but some things are not > >> working, i.e., the stat led, > >> but more important, the usb is unusable. > >> > >> does someone have a correct fdt for this board? > >> > > > > First, are you using correct u-boot for it? > > > > https://github.com/jaredmcneill/freebsd-ports/tree/u-boot-nanopi-neo/ > sysutils/u-boot-nanopi-neo > > Any reason we can't roll this into the current u-boot master framework? > Yeah, I think u-boot v2017.01 already includes config for NanoPI NEO. thanks, Ganbold > > Warner > > > I'm using attached dts in FreeBSD. > > > > Ganbold > > > > > >> > >> danny > >> > >> _______________________________________________ > >> 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 Sun Jan 22 09:33:15 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 BD5D5CBC6F5 for ; Sun, 22 Jan 2017 09:33:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::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 8A29DD46 for ; Sun, 22 Jan 2017 09:33:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2766B1FE100; Sun, 22 Jan 2017 10:32:49 +0100 (CET) Subject: Re: Getting the kernel to let go of my UART! To: Dustin Marquess , freebsd-arm@freebsd.org References: From: Hans Petter Selasky Message-ID: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> Date: Sun, 22 Jan 2017 10:32:39 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: 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: Sun, 22 Jan 2017 09:33:15 -0000 On 01/22/17 06:07, Dustin Marquess wrote: > [Sorry if this is somewhat of a dupe, I have yet to find a solution] > > I've been running FreeBSD on my Pi 3s for a little over a month now, > first using gonzo's SMP code + a home cross-compiled kernel, and then > I moved to the HardenedBSD images. All of them work great except one > issue that's driving me nuts... > > The downside to the Pi 3 vs some other boards is that there's really > only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with > a GPS board. > > 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and > that's "fixed". > > 2nd issue: Even with a USB keyboard attached and HDMI output > connected, FreeBSD still wants to steal the first uart (ttyu0) as a > console port. I thought that would be fine as long as I use "-m -n > -q" in the boot config to disable kernel output and then "conscontrol > delete ttyu0". Well, that KIND of works. It seems to work fine when > using 115200bps, but trying to change the baud rate to match the GPS > unit doesn't seem to work at all, I'm guessing because it's still set > as an available console? > > hint.uart.0.flags="0x0" doesn't work, as it still marks it as a > console. console="efi" seems to be the only setting that works, > "vidconsole" and "nullconsole" both don't work. > > Is there a way to stop the kernel from trying to claim the UART as a console? I think so, have a look in /etc/ttys and comment out the ttyu0 line. --HPS From owner-freebsd-arm@freebsd.org Sun Jan 22 10:26: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 034CFCBC276 for ; Sun, 22 Jan 2017 10:26:18 +0000 (UTC) (envelope-from florence44638@caliopea.com) Received: from antispam.calyopea.com (digi00817.digicube.fr [95.130.13.154]) (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 B8E89790 for ; Sun, 22 Jan 2017 10:26:17 +0000 (UTC) (envelope-from florence44638@caliopea.com) Received: from ssl.calyopea.com (ssl [95.130.13.154]) by antispam.calyopea.com (Postfix) with ESMTP id 580028928E for ; Sun, 22 Jan 2017 11:19:36 +0100 (CET) Received: from internal-ip (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) by Mailer-VIP-1.calyopea.fr (Postfix) with ESMTPSA id 23806759A5 for ; Sun, 22 Jan 2017 11:19:36 +0100 (CET) To: freebsd-arm@freebsd.org From: nowhere Subject: Durable/serious arm hardware ? Message-ID: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> Date: Sun, 22 Jan 2017 11:19:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.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, 22 Jan 2017 10:26:18 -0000 Hello I'd like to hear from the most skilled of you, if anybody knows serious arm based hardware or share this though : I'm becoming convinced that theses hardware (arm based) are just the consumable-smartphone fashion counterpart for kids and leisures or tests. Not really final and carefully finished products; abble to works for years or a decade; doing is job in a office corner, being forgotten by anyone, like some of my older freebsd servers wich are running for a decade now. Those past years, I've bought 3 arm based devices : 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: except with debian, it never booted on freebsd (I even tried netbsd): I just trashed it yesterday (bought in 2014 i think). 1 Beagleboneblack : works fine for weeks then freeze suddenly. And sometimes did not event reboot (*): had to loop-reset it until boot process go to the end. Seem the most "workable" product so far.. (bought in 2015) 1 olimex a20-lime2-emmc: my most recent buy. It did not event boot with network with it's own debian sd card... (I did not yet take time to make it's own freebsd sd card): (bought in 2016-07). My goals, for example, with theses boards were to give some of my nomads customers, a box with an autonomous dhcp/dns/vpn server on theyr networks, without the need to change anything else than disabling their dhcp servers for instance : I think a Quad xeon racked server is a bit too much for theses tasks; I was using pfsence on pcengines boards before to do this kind of things. Since my conclusions are based only on theses 3 boards, I'd like to hear from thoses of you who works daily with these boards, and thoses opinion are based on far more than my hand counted experiences. PM. (*) I work with a 5V/5A (25w) psu: that's not an overloaded psu problem; Not a damaged emmc/sd card problem too: all my systems are read-only-root based: seems to really be an hardware issue. From owner-freebsd-arm@freebsd.org Sun Jan 22 11:35:42 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 215F9CBC2D2 for ; Sun, 22 Jan 2017 11:35:42 +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 EAFE8A26 for ; Sun, 22 Jan 2017 11:35:41 +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 29F0C209C6 for ; Sun, 22 Jan 2017 06:35:40 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 22 Jan 2017 06:35:40 -0500 DKIM-Signature: v=1; a=rsa-sha1; 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=mesmtp; bh=Qr39jeuTIFtMch4 rUJIMMsIHveI=; b=aTjRDy92de5keVjU+ExXEx500L32XO9Jq+U80D5iOgRdTxM mVQ4/fFWd/5DaafUM51Mk/nxdkRqJc28AnPXHUqFJRTczQsfRl/eE0Cn0DE/cDNr PrSFqUNpOLzuGOPbPuFXo75ag7ksQfziwiDuo482rDaInUp0v24y5abllESM= DKIM-Signature: v=1; a=rsa-sha1; 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= smtpout; bh=Qr39jeuTIFtMch4rUJIMMsIHveI=; b=FzCgfPdzMW6LqctkFQAl x7dQgyAPPosmIilq/0WEZj6T7fTM1/B5U46Vgxzo+vC1vr////ebm9wzKk6JP7B+ 2jrF9VEvBDz0nkjDr01SYWZJzdhL5VRWYGTiEg2Nlz85xMSptcbyU71VlI46LqvY WQzmXRyRLpysLWTNeYX804I= X-ME-Sender: X-Sasl-enc: O24iUUN282hD5FIxJ5FzwxdWu7HZx4vUYowCHp3kKGtO 1485084939 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id B856924526 for ; Sun, 22 Jan 2017 06:35:39 -0500 (EST) Subject: Re: Durable/serious arm hardware ? To: freebsd-arm@freebsd.org References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> From: tech-lists Message-ID: <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> Date: Sun, 22 Jan 2017 11:35:32 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> Content-Type: text/plain; charset=windows-1252 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, 22 Jan 2017 11:35:42 -0000 On 22/01/2017 10:19, nowhere wrote: > 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: except > with debian, it never booted on freebsd (I even tried netbsd): I just > trashed it yesterday (bought in 2014 i think). I have 5 rpi boards: 1x rpi2+ 3x rpi2B 1x rpi3 The rpis I treat (mainly) as single-purpose devices and for that they are (in my experience) very stable. The exception being the rpi3 which will be a (hardened) freebsd server for the internal network. Most of these pis are on 24/7. The pi3 is better suited than the pi2x for a server role. It would be worthwhile attaching a usb hd to the pi3 for data. Although I've worn out a few microsd cards, I think that's been caused by my own ignorance in not allocating external media for a busy filesystem. All the pi hardware still works though, and I've had the pi2+ abd 2B since they came out. I've had one of the pi2Bs as a (32-bit) mail server running exim which failed because of my above mentioned ignorance. The pi3 runs hardenedBSD entirely in 64bit and seems very stable unless I thrash the microsd by installing ports and not exporting $WORKDIR to external (and easily replacable) media, like a usb stick. I haven't been able to get vanilla freebsd/aarch64 running on the rpi3 yet. -- J. From owner-freebsd-arm@freebsd.org Sun Jan 22 11:55:28 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 E736DCBC791 for ; Sun, 22 Jan 2017 11:55:28 +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 BCC0D2EF for ; Sun, 22 Jan 2017 11:55:28 +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 5F9D920967 for ; Sun, 22 Jan 2017 06:55:27 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 22 Jan 2017 06:55:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; 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=mesmtp; bh=mhiU5H0wf7ujUW6 g45pX63fIzSo=; b=yXv77v0miSImu3M9wodcGHOOaf+Hu2JYIG1ZmF+PqdCfIVD ogVPHJvRFZbXBMlE4+UMa/yqYBCISer6GIiP2gt9G7DY9Q6uS8HXU7BU1cLo+Izh 2XbuhvPJNDekLbdBrbJWAxu84haYnOewmCyzYcq0hHOtJmKdfet5oclOwK44= DKIM-Signature: v=1; a=rsa-sha1; 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= smtpout; bh=mhiU5H0wf7ujUW6g45pX63fIzSo=; b=Gd8O6TvlYTk6GWRMr+Zt j44jMXhL+31dHXicoTk+VnNtvbTVGqAr67REJySJyc18oL15+nXm/FkkYnQeFRz1 ZrUIkFflyvIsA6siOmQ8DauHgqfERIjaCnHWg4jhhsC7IbNP5An4ix6mxvYuIRd9 OzzjKVJKoTwItgb4G18+KxM= X-ME-Sender: X-Sasl-enc: dHl1Cs2XCnBbaKUG6Gj8sELxTVnrY/Bi/X3/Fb/1DcHj 1485086127 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A6DC24424 for ; Sun, 22 Jan 2017 06:55:26 -0500 (EST) Subject: Re: how to measure microsd wear To: freebsd-arm@freebsd.org References: <201701220253.v0M2rkrl095913@pdx.rh.CN85.dnsmgr.net> From: tech-lists Message-ID: Date: Sun, 22 Jan 2017 11:55:20 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <201701220253.v0M2rkrl095913@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 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, 22 Jan 2017 11:55:29 -0000 On 22/01/2017 02:53, Rodney W. Grimes wrote: > In either case the manufactures of flash devices have made it very > clear that these things DO have a write cycle life time, and that > your going to see a failure eventually if you write enough data to > them. Hi, Is there a way one can see how many (or an average) number of write cycles the cluster or device has had? In order to get a handle on when it's likely to fail. Or to see what's been remapped and how many more it can remap? If not on freebsd then on any OS? Maybe something that tests # remappable and warns when there's nothing left? I mean it's all fair and well the manufacturers saying it will fail on average after so many writes, but that uncontextualised information is useless if one cannot establish how many writes have already happened. -- J. From owner-freebsd-arm@freebsd.org Sun Jan 22 11:59:21 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 E1CD4CBC7E3 for ; Sun, 22 Jan 2017 11:59:21 +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 AEA53368 for ; Sun, 22 Jan 2017 11:59:21 +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 6BA7820724 for ; Sun, 22 Jan 2017 06:59:20 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 22 Jan 2017 06:59:20 -0500 DKIM-Signature: v=1; a=rsa-sha1; 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=mesmtp; bh=UZq7mvyITBA2Vth y+9dCMfp8ItE=; b=QgCQKnyvDGaBpDucDL6zlQpOTJkSnR2P81wKVSakBSn11Oj YdC/BIhoyUtu39VaapIi30sKlanKffAJ8HfR5BVVlq27thWo4gTsUaE1N/HjM01o cxY0m+D5HMnr/uWVgqcmaJRULr5GBm1RprdpYLS9yHwwBI6sXnW++lPfYhrc= DKIM-Signature: v=1; a=rsa-sha1; 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= smtpout; bh=UZq7mvyITBA2Vthy+9dCMfp8ItE=; b=nNhD5bX0NphYqmabrs20 UkwGS2+7XHrSoK/Nq8ffX4pDcCm8yjpW/Ywn3KITyeX6HxqM5ZTZSQweEjbpj95J muEYx3GIYvklxMl7JVTWE04oYeTkibaimayc1goMxRNGC5gIpybo+ju6n/73AcdX P4i1LYm/okcN2yHGCnImxr0= X-ME-Sender: X-Sasl-enc: L43gxxD4NRjrIx8iNmnieo+RHgVTjIQ3qnAqvrj9SDrv 1485086360 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 1185A244AE for ; Sun, 22 Jan 2017 06:59:19 -0500 (EST) Subject: Re: Durable/serious arm hardware ? To: freebsd-arm@freebsd.org References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> From: tech-lists Message-ID: Date: Sun, 22 Jan 2017 11:59:13 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> Content-Type: text/plain; charset=windows-1252 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, 22 Jan 2017 11:59:22 -0000 On 22/01/2017 11:35, tech-lists wrote: > The rpis I treat (mainly) as single-purpose devices and for that they > are (in my experience) very stable. The exception being the rpi3 which > will be a (hardened) freebsd server for the internal network. aaaagh...! The exception to being a *single-purpose device!!* In other words, the rpi3 is multi-purpose. The rpi3 is very stable. In that it's not crashed yet unless I do something stupid. -- J. From owner-freebsd-arm@freebsd.org Sun Jan 22 15:23: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 5B215CBCB30 for ; Sun, 22 Jan 2017 15:23:27 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F12D8DBD for ; Sun, 22 Jan 2017 15:23:26 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v0MFNOvg098410; Sun, 22 Jan 2017 07:23:24 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v0MFNHSb098409; Sun, 22 Jan 2017 07:23:17 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201701221523.v0MFNHSb098409@pdx.rh.CN85.dnsmgr.net> Subject: Re: how to measure microsd wear In-Reply-To: To: tech-lists Date: Sun, 22 Jan 2017 07:23:17 -0800 (PST) CC: freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UNKNOWN-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, 22 Jan 2017 15:23:27 -0000 > On 22/01/2017 02:53, Rodney W. Grimes wrote: > > In either case the manufactures of flash devices have made it very > > clear that these things DO have a write cycle life time, and that > > your going to see a failure eventually if you write enough data to > > them. > > Hi, > > Is there a way one can see how many (or an average) number of write > cycles the cluster or device has had? In order to get a handle on when > it's likely to fail. Or to see what's been remapped and how many more it > can remap? If not on freebsd then on any OS? > > Maybe something that tests # remappable and warns when there's nothing left? > > I mean it's all fair and well the manufacturers saying it will fail on > average after so many writes, but that uncontextualised information is > useless if one cannot establish how many writes have already happened. I can tell you that some vendors implement smart like stuff using sdio CMD56, such as Envoy who says this: Envoy Data Memory SD and µSD controllers implement CMD56 support and specialized firmware to provide S.M.A.R.T. like features to systems designers. One of the biggest concerns that system designers have with NAND Flash based storage and mobile, remotely deployed hardware systems is replacing worn out SD Cards or µSD Cards. Or worse, not knowing IF the SD Card or µSD Card even needs to be replaced based on endurance estimates. The use case for all Solid State Storage has a significant impact on the life of the product. If system designers implement Envoy Data Memory SD Cards or µSD Cards they can monitor card life as part of the systems background tasks. Hardware that is connected can notify users or administrators in the event that the card begins to reach an END OF LIFE condition. Envoy Data Memory supports this feature with a S.M.A.R.T. tool available to our customers. Other vendors have similiar stuff, down side is most of this is vendor specific and only comes with a Windows tool. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sun Jan 22 15:30:01 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 BE8F7CBCCE1 for ; Sun, 22 Jan 2017 15:30:01 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 93B50CB for ; Sun, 22 Jan 2017 15:30:01 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 395B913148 for ; Sun, 22 Jan 2017 09:29:59 -0600 (CST) Subject: Re: Durable/serious arm hardware ? To: freebsd-arm@freebsd.org References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> From: Karl Denninger Message-ID: <7900e188-88c3-74a1-09b1-628494b890be@denninger.net> Date: Sun, 22 Jan 2017 09:29:55 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010604000600030704040900" 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, 22 Jan 2017 15:30:01 -0000 This is a cryptographically signed message in MIME format. --------------ms010604000600030704040900 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/22/2017 05:59, tech-lists wrote: > On 22/01/2017 11:35, tech-lists wrote: >> The rpis I treat (mainly) as single-purpose devices and for that they >> are (in my experience) very stable. The exception being the rpi3 which= >> will be a (hardened) freebsd server for the internal network. > aaaagh...! The exception to being a *single-purpose device!!* In other > words, the rpi3 is multi-purpose. > > The rpi3 is very stable. In that it's not crashed yet unless I do > something stupid. > I have a number of RPI2 devices in production use running process-control type things and none of them has had stability problems. I *have* had SD card issues on occasion, but that's not the machine itself..... of the RPI2s I've got in use I've had zero failures and no stability problems at all. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010604000600030704040900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjIxNTI5NTVaME8GCSqGSIb3DQEJBDFCBEC80fET 4Sn9onW4B8TDHoABxEIu/65/ckqFMfuWOLUNt6lp86AasBb6eKZo6cu2og0zR89Ck2olg7Fs DMiAuMnvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIABcUcj2GNSR1h C1IJwT2y3hR/UwMoLouNAbowpBxdlav8qWxBr/eMTaVDxZ0rx6CFdthKuvvEX2M94ASqA0x2 P9/BnRE1xzHhSxZ34+F2o/P+x0OZq7yXQigEpn6btHmOibjl5Vb/CL5+HuVOvZoXFglXjuhY Lcr68tPKAQKMdv0JqrOY7Itpou8EkinwTcXwg/eoL3LKNvMo8siyhN5sIZHt2QohUGBX9ZgV +Xa6NYkJ368zvrEfdFXmLXnhKZ05anRUa4lAkPPrwaD5mPSaJi0dBevA9wgGiFXIxjmErrDL 1gB697+I1YzqGHgstKwkR2AuHSF0p7JYP3QPYbaQYTMG+cHHNdwULJLQGiCdsPPuUL3L2135 bwW00TBKXTPTzLHDC1uXwjfjX91wLpfzK7ugVPvsAAq3qndo1fph7pVxi3P8yM92OsQYHd8o m8MbgmaRZQ0VADtWVsvFCts9KBju16oItSyDhhrQyqEB5r54NF6MHS5nEon2dmDGb4HszgzM r7IPZHBdGvqhZmI8kLs7PVCC3jUrXFxF8WZxkrLY6TLoFkVOM0yFxYO2vLXlo4/0ht5+g0Uk jA3mRradc1cLMsK33dsSlta7tgavDVMIsOxMjh0Eu2p4cpOWk4fPeuByIkmIf9DZImrN6gTL dhogP/A6Xr+Nz+lh2pfn73sAAAAAAAA= --------------ms010604000600030704040900-- From owner-freebsd-arm@freebsd.org Sun Jan 22 15:35: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 C6FAFCBCF62 for ; Sun, 22 Jan 2017 15:35:40 +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 9238A909 for ; Sun, 22 Jan 2017 15:35:40 +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 1cVKB1-0001dc-2G for freebsd-arm@freebsd.org; Sun, 22 Jan 2017 16:35:31 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Durable/serious arm hardware ? References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> Date: Sun, 22 Jan 2017 16:35:29 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> 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: 4b95630a2805109a2fafe329e7ec4fd6 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, 22 Jan 2017 15:35:40 -0000 On Sun, 22 Jan 2017 12:35:32 +0100, tech-lists wrote: > On 22/01/2017 10:19, nowhere wrote: >> 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: except >> with debian, it never booted on freebsd (I even tried netbsd): I just >> trashed it yesterday (bought in 2014 i think). > > I have 5 rpi boards: > > 1x rpi2+ > 3x rpi2B > 1x rpi3 > > The rpis I treat (mainly) as single-purpose devices and for that they > are (in my experience) very stable. The exception being the rpi3 which > will be a (hardened) freebsd server for the internal network. Most of > these pis are on 24/7. The pi3 is better suited than the pi2x for a > server role. It would be worthwhile attaching a usb hd to the pi3 for > data. > > Although I've worn out a few microsd cards, I think that's been caused > by my own ignorance in not allocating external media for a busy > filesystem. All the pi hardware still works though, and I've had the > pi2+ abd 2B since they came out. > > I've had one of the pi2Bs as a (32-bit) mail server running exim which > failed because of my above mentioned ignorance. The pi3 runs hardenedBSD > entirely in 64bit and seems very stable unless I thrash the microsd by > installing ports and not exporting $WORKDIR to external (and easily > replacable) media, like a usb stick. My solution to this is a tmpfs mounted dir. from /etc/fstab: tmpfs /tmp tmpfs rw,size=64M 0 0 tmpfs /var/tmp/ports-build tmpfs rw,size=512m 0 0 from /etc/make.conf WRKDIRPREFIX?=/var/tmp/ports-build Most ports build within a couple of MBs, so there isn't anything written to disk during the build stage. Chances are high on my system something else which is unused is swapped out when needed (which is on an USB-stick). Ronald. > > I haven't been able to get vanilla freebsd/aarch64 running on the rpi3 > yet. From owner-freebsd-arm@freebsd.org Sun Jan 22 16:18:16 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 EAEDDCBCBA4 for ; Sun, 22 Jan 2017 16:18:16 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 911C0DCF; Sun, 22 Jan 2017 16:18:16 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id v0MG0WkK080988; Mon, 23 Jan 2017 01:00:32 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201701221600.v0MG0WkK080988@sana.init-main.com> To: brd@freebsd.org, freebsd-arm@freebsd.org Subject: RPi 3 without pi3-disable-bt Date: Mon, 23 Jan 2017 01:00:32 +0900 From: Takanori Watanabe 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, 22 Jan 2017 16:18:17 -0000 Hi. I succeeded to boot my RPi3 with raspbsd.org boot image, though it can be accessed by ssh login only. (Some HDMI data seems to be generated, but my TV will not interpret it.) And I want to hack bluetooth module on RPI3. So I removed "dtoverlay=pi3-disable-bt" line from config.txt . But It seems that the boot process of my RPi3 did not reached to userland. The filesystem of my RPi3 stay clean. Are there any information about this? Yes, I know the BT module is connected to main UART and forced to use freaky UART for serial console if BT module is enabled. === uname -a FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308109M: Sun Oct 30 13:07:04 MDT 2016 brd@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC-UP arm64 == From owner-freebsd-arm@freebsd.org Sun Jan 22 16:49: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 6D3A8CBD2AB for ; Sun, 22 Jan 2017 16:49:46 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5B9BFB for ; Sun, 22 Jan 2017 16:49:46 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 22D74566; Sun, 22 Jan 2017 11:49:37 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Durable/serious arm hardware ? From: Paul Mather In-Reply-To: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> Date: Sun, 22 Jan 2017 11:49:37 -0500 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> To: nowhere X-Mailer: Apple Mail (2.3124) 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, 22 Jan 2017 16:49:46 -0000 On Jan 22, 2017, at 5:19 AM, nowhere wrote: > Hello >=20 > I'd like to hear from the most skilled of you, if anybody knows = serious arm based hardware or share this though : I'm becoming convinced = that theses hardware (arm based) are just the consumable-smartphone = fashion counterpart for kids and leisures or tests. Not really final and = carefully finished products; abble to works for years or a decade; doing = is job in a office corner, being forgotten by anyone, like some of my = older freebsd servers wich are running for a decade now. >=20 >=20 > Those past years, I've bought 3 arm based devices : >=20 > 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: = except with debian, it never booted on freebsd (I even tried netbsd): I = just trashed it yesterday (bought in 2014 i think). >=20 > 1 Beagleboneblack : works fine for weeks then freeze suddenly. And = sometimes did not event reboot (*): had to loop-reset it until boot = process go to the end. Seem the most "workable" product so far.. (bought = in 2015) I am not the most skilled of us, but, FWIW, you can get an "industrial" = version of the BeagleBone Black. That might be more rugged for your = intended deployments. See, e.g., = http://www.mcmelectronics.com/product/ELEMENT14-BBONE-BLACK-IND-4G-/83-170= 07 Cheers, Paul.= From owner-freebsd-arm@freebsd.org Sun Jan 22 17:02: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 6064ACBDAEF for ; Sun, 22 Jan 2017 17:02:50 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F3AC2D8 for ; Sun, 22 Jan 2017 17:02:50 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 04FF056A; Sun, 22 Jan 2017 12:02:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Durable/serious arm hardware ? From: Paul Mather In-Reply-To: <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> Date: Sun, 22 Jan 2017 12:02:48 -0500 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9AAE3A31-8EAE-4512-957C-40790C9D351B@gromit.dlib.vt.edu> References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> To: tech-lists X-Mailer: Apple Mail (2.3124) 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, 22 Jan 2017 17:02:50 -0000 On Jan 22, 2017, at 6:35 AM, tech-lists wrote: > On 22/01/2017 10:19, nowhere wrote: >> 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: = except >> with debian, it never booted on freebsd (I even tried netbsd): I just >> trashed it yesterday (bought in 2014 i think). >=20 > I have 5 rpi boards: >=20 > 1x rpi2+ > 3x rpi2B > 1x rpi3 >=20 [[...]] > I've had one of the pi2Bs as a (32-bit) mail server running exim which > failed because of my above mentioned ignorance. The pi3 runs = hardenedBSD > entirely in 64bit and seems very stable unless I thrash the microsd by > installing ports and not exporting $WORKDIR to external (and easily > replacable) media, like a usb stick. >=20 > I haven't been able to get vanilla freebsd/aarch64 running on the rpi3 = yet. I'm just curious, but with the RPi 3 having only 1 GB of RAM, what is = the compelling advantage in running it in 64-bit mode? (I've heard that = 64-bit applications can induce higher memory pressure.) Is it a matter = of providing a wide testing base for FreeBSD/arm64? Cheers, Paul. From owner-freebsd-arm@freebsd.org Sun Jan 22 18:01:41 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 50A71CBC254 for ; Sun, 22 Jan 2017 18:01:41 +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 E2DD4F35 for ; Sun, 22 Jan 2017 18:01:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: d25eec7a-e0cc-11e6-9357-bffcd86bd944 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 d25eec7a-e0cc-11e6-9357-bffcd86bd944; Sun, 22 Jan 2017 18:01:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0MI1SBX001551; Sun, 22 Jan 2017 11:01:28 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485108088.42643.5.camel@freebsd.org> Subject: Re: Durable/serious arm hardware ? From: Ian Lepore To: nowhere , freebsd-arm@freebsd.org Date: Sun, 22 Jan 2017 11:01:28 -0700 In-Reply-To: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> 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, 22 Jan 2017 18:01:41 -0000 On Sun, 2017-01-22 at 11:19 +0100, nowhere wrote: > Hello > > I'd like to hear from the most skilled of you, if anybody knows > serious  > arm based hardware or share this though : I'm becoming convinced > that  > theses hardware (arm based) are just the consumable-smartphone > fashion  > counterpart for kids and leisures or tests. Not really final and  > carefully finished products; abble to works for years or a decade; > doing  > is job in a office corner, being forgotten  by anyone, like some of > my  > older freebsd servers wich are running for a decade now. > > > Those past years, I've bought 3 arm based devices : > > 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: > except  > with debian, it never booted on freebsd (I even tried netbsd): I > just  > trashed it yesterday (bought in 2014 i think). > > 1 Beagleboneblack : works fine for weeks then freeze suddenly. And  > sometimes did not event reboot (*): had to loop-reset it until boot  > process go to the end. Seem the most "workable" product so far.. > (bought  > in 2015) > > 1 olimex a20-lime2-emmc: my most recent buy. It did not event boot > with  > network with it's own debian sd card... (I did not yet take time to > make  > it's own freebsd sd card): (bought in 2016-07). > > My goals, for example, with theses boards were to give some of my > nomads  > customers, a box with an autonomous dhcp/dns/vpn server on theyr  > networks, without the need to change anything else than disabling > their  > dhcp servers for instance : I think a Quad xeon racked server is a > bit  > too much for theses tasks; I was using pfsence on pcengines boards  > before to do this kind of things. > > Since my conclusions are based only on theses 3 boards, I'd like to > hear  > from thoses of you who works daily with these boards, and thoses > opinion  > are based on far more than my hand counted experiences. > > > PM. > > > > (*) I work with a 5V/5A (25w) psu: that's not an overloaded psu > problem;  > Not a damaged emmc/sd card problem too: all my systems are  > read-only-root based: seems to really be an hardware issue. > At $work we create commercial products running freebsd that have a 10 to 20 year (depending on the product) g'teed lifespan in the field.  We used to use Atmel arm chips on custom-designed mainboards.  Now we use primarily imx6 SOM modules from Technexion, SolidRun, and soon Boundary Devices, along with our own custom-designed carrier boards.  The imx6 SOM modules are a bit higher-end than rpi or beaglebone boards. I would say that basically you have to shop around a bit.  If you buy ultra-cheap hobbyist hardware such as an rpi, you're going to get what you pay for.  If you buy the higher-end hardware you can expect the same kind of quality and lifespan you'd get from x86 hardware (which doesn't tend to target the hobbyist market so much). -- Ian From owner-freebsd-arm@freebsd.org Sun Jan 22 18:54: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 D1E11CBD23F for ; Sun, 22 Jan 2017 18:54:18 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85BB8D7 for ; Sun, 22 Jan 2017 18:54:18 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-yb0-x232.google.com with SMTP id l23so81575275ybj.2 for ; Sun, 22 Jan 2017 10:54:18 -0800 (PST) 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=HEzL6mdYKs7bAhoRikCBR4TF23oeCadpt+On7ISKZpc=; b=K9FKEYHWIQalQsVjJThl7VGjsee9ZFu0dmSPdhydLVWEN9oqLeTlQYsOBx5yikmfDa wkQF/5fT/Z0t7et2By/IKY5gs+4olEBnc4cMmWpptGukX3XmNYtEOs+w8paX+TsdE4z9 vYkzxxmHuEZFPnV55g2rio89dsuw+H/oB9uq31eRxH+vRZuitFuD9Onv6UhbPCZ9a06F jQD6oRrbf4Jx0+wsYn0wZnfs8ch3JxkQOiqx4KinhlYYSA2nZHGAjjZsV+uj8zsycbno qnKK+wWE6MSDbCbjztFZ7usz1/Btj+NPIPN3N/8yF6XIxrD/QWZDDtMgqkUchcRXvMZZ uyQQ== 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=HEzL6mdYKs7bAhoRikCBR4TF23oeCadpt+On7ISKZpc=; b=K2jAv1l8LIS5wlFFJD7EpSsJq+PBiSospbRKOoX5XwSNROzaA+Xk0nrPQ/IidIwqj5 GKBsBXIs7wiLvfjhv4sVNrLlBauVysDZAbdNFGVSsTrJwGEK4hkLtC07d+Jor7iuKzlU 4/tVbgfLX5puU35b7GjeR+RdMdOw+nuZXd0uMEGUvAoTW+sgkcceWEoX4PrP7h6O36P6 gvyy9X5T+NUcFcW+pxCLiLbjKOa20j9P/tRBB4aAuIEMTdT9nDsDiXwj5Bjrx/ZWj0I8 k/9yu72XDqhJCk4voWtIZal0ytNr5cRgf1QiYEnQHcEZwqUkK51cpF1hF3pV4KMKL7fp aVYg== X-Gm-Message-State: AIkVDXJyYFqSqZI/YBfyRTzBW7VgRU1NTNWs9K5MPKrC36c1VdhL1A5cj8Nc8twMOk9CWt5AeVqGYs1Bs11G6g== X-Received: by 10.37.224.77 with SMTP id x74mr17172237ybg.80.1485111257587; Sun, 22 Jan 2017 10:54:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.231.135 with HTTP; Sun, 22 Jan 2017 10:54:17 -0800 (PST) In-Reply-To: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> From: Dustin Marquess Date: Sun, 22 Jan 2017 12:54:17 -0600 Message-ID: Subject: Re: Getting the kernel to let go of my UART! To: Hans Petter Selasky 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, 22 Jan 2017 18:54:18 -0000 On Sunday, January 22, 2017, Hans Petter Selasky wrote: > On 01/22/17 06:07, Dustin Marquess wrote: > >> [Sorry if this is somewhat of a dupe, I have yet to find a solution] >> >> I've been running FreeBSD on my Pi 3s for a little over a month now, >> first using gonzo's SMP code + a home cross-compiled kernel, and then >> I moved to the HardenedBSD images. All of them work great except one >> issue that's driving me nuts... >> >> The downside to the Pi 3 vs some other boards is that there's really >> only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with >> a GPS board. >> >> 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and >> that's "fixed". >> >> 2nd issue: Even with a USB keyboard attached and HDMI output >> connected, FreeBSD still wants to steal the first uart (ttyu0) as a >> console port. I thought that would be fine as long as I use "-m -n >> -q" in the boot config to disable kernel output and then "conscontrol >> delete ttyu0". Well, that KIND of works. It seems to work fine when >> using 115200bps, but trying to change the baud rate to match the GPS >> unit doesn't seem to work at all, I'm guessing because it's still set >> as an available console? >> >> hint.uart.0.flags="0x0" doesn't work, as it still marks it as a >> console. console="efi" seems to be the only setting that works, >> "vidconsole" and "nullconsole" both don't work. >> >> Is there a way to stop the kernel from trying to claim the UART as a >> console? >> > > I think so, have a look in /etc/ttys and comment out the ttyu0 line. > > Sadly, I already did that. There's no getty running, but dmesg still shows the kernel marking it as a console. -Dustin From owner-freebsd-arm@freebsd.org Sun Jan 22 18:57: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 34177CBD353 for ; Sun, 22 Jan 2017 18:57:27 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05A1938E for ; Sun, 22 Jan 2017 18:57:27 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pg0-x243.google.com with SMTP id 204so11685633pge.2 for ; Sun, 22 Jan 2017 10:57:27 -0800 (PST) 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=W1GLpIlSl2piXqp9ly1wcqqaoNPmiWWYCZ/1pTEYXgM=; b=MpOxYY0y7XFoHWnPAOPsDtez8Q+uEOQ0pw2xy8vqWNdU+bLbzuXsDluayQqbR+nhT4 6rrkk/AlYgb0rvtIIffhfCmozy6Kx5KFk0JPS1ak8ZZlu1mNaeL17C24Pnmz2uasq5Ca uz6nZ5u3aARToBeRvaHeQtoSt01cO7roZNNRrM4nuda8RDIhBSYrJ1PF6mvICoBLImGc V50HX+iz6EAp63oFRPDABETpyiIY3351AxAHJweHAT4p8zoG7y4T2HjOh1lnBQDV94NY dhSF9+7RrwrmbNuDNUOlxu5Lxy0ZMKh7BRRXo4qLKadVnO3IUlJhRpM+3n9IhKrZ+9iv qlWA== 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=W1GLpIlSl2piXqp9ly1wcqqaoNPmiWWYCZ/1pTEYXgM=; b=PjzDAlYK2V+zsQoOZvYmg841AJ4L+XdGnaxwIDARWat7b/g28XopN/1iZRAmK71wnT 3w+Yi4rez29+frK8QpXGn5m06Z7a3yiuWmBUk8n50Muxc4H6sSuZt4meKP1fv2+/Ey+5 a1Ih+IbmA7Lr2T9VOMx1ljdx8WRED0tQnCUuWs2Bu3g+Lrk3l1JWVU3s/jQtVIzTprBX L4JcYlyR5kPS6yG6TqmFqE/+iC03obfuEDpE/laF7AxyDgSyap/uSA3ntQhafvg1cUYn HvpymJewc5uaIUzpqn+ySeUzdyXB89f3M87/Zp6jG2Qd3Gln70LEEORmrIZ9t4c1F9Vg OJmQ== X-Gm-Message-State: AIkVDXISczCsAAXyZxFjk4iAJThiJkWJ0hUrEyN+MghAySd/6JlWMNX+UJJGSwAhywdv0g== X-Received: by 10.99.67.6 with SMTP id q6mr9279607pga.156.1485111446619; Sun, 22 Jan 2017 10:57:26 -0800 (PST) Received: from [127.0.0.1] ([184.151.231.181]) by smtp.gmail.com with ESMTPSA id y23sm31065181pfi.66.2017.01.22.10.57.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Jan 2017 10:57:25 -0800 (PST) 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: <20170122185725.5791826.41144.19181@gmail.com> Date: Sun, 22 Jan 2017 10:57:25 -0800 Subject: Re: Durable/serious arm hardware ? From: Russell Haley In-Reply-To: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> To: nowhere , 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: Sun, 22 Jan 2017 18:57:27 -0000 Sorry about the top post, my computer is in a box.=C2=A0 Have you looked at the products from Netgate?=E2=80=8E They are the sponsor= for PFSense and Jim Thompson is somewhat regular on this list. They have n= ew product based on an arm board, but also have some nice SOHO stuff based = on low power x86 boards. =E2=80=8E As Ian pointed out there are dozens of manufacturers and many SOMs/SBC are = not for consumers, but you need to be able to specify the hardware you want= and order in bulk. Many have dev boards but good luck getting complete har= dware support without some effort.=C2=A0 That said, =C2=A0I've had good luck with my solid run hummingboard (dev bas= e board) and their SOM but there is much unsupported hardware still. They u= sed to sell a case for it too.=C2=A0 If this is for work, Netgate may be your best option because it will come w= ith a warranty and all the rest.=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: nowhere Sent: Sunday, January 22, 2017 2:26 AM To: freebsd-arm@freebsd.org Subject: Durable/serious arm hardware ? Hello I'd like to hear from the most skilled of you, if anybody knows serious=20 arm based hardware or share this though : I'm becoming convinced that=20 theses hardware (arm based) are just the consumable-smartphone fashion=20 counterpart for kids and leisures or tests. Not really final and=20 carefully finished products; abble to works for years or a decade; doing=20 is job in a office corner, being forgotten by anyone, like some of my=20 older freebsd servers wich are running for a decade now. Those past years, I've bought 3 arm based devices : 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: except=20 with debian, it never booted on freebsd (I even tried netbsd): I just=20 trashed it yesterday (bought in 2014 i think). 1 Beagleboneblack : works fine for weeks then freeze suddenly. And=20 sometimes did not event reboot (*): had to loop-reset it until boot=20 process go to the end. Seem the most "workable" product so far.. (bought=20 in 2015) 1 olimex a20-lime2-emmc: my most recent buy. It did not event boot with=20 network with it's own debian sd card... (I did not yet take time to make=20 it's own freebsd sd card): (bought in 2016-07). My goals, for example, with theses boards were to give some of my nomads=20 customers, a box with an autonomous dhcp/dns/vpn server on theyr=20 networks, without the need to change anything else than disabling their=20 dhcp servers for instance : I think a Quad xeon racked server is a bit=20 too much for theses tasks; I was using pfsence on pcengines boards=20 before to do this kind of things. Since my conclusions are based only on theses 3 boards, I'd like to hear=20 from thoses of you who works daily with these boards, and thoses opinion=20 are based on far more than my hand counted experiences. PM. (*) I work with a 5V/5A (25w) psu: that's not an overloaded psu problem;=20 Not a damaged emmc/sd card problem too: all my systems are=20 read-only-root based: seems to really be an hardware issue. _______________________________________________ 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 Jan 22 19:07: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 D7C0ECBD658 for ; Sun, 22 Jan 2017 19:07:06 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 A9B50ABF for ; Sun, 22 Jan 2017 19:07:06 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cVNTg-000GLe-CP; Sun, 22 Jan 2017 11:07:01 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0MJ6xGG062845; Sun, 22 Jan 2017 11:06:59 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 22 Jan 2017 11:06:59 -0800 From: Oleksandr Tymoshenko To: Dustin Marquess Cc: Hans Petter Selasky , "freebsd-arm@freebsd.org" Subject: Re: Getting the kernel to let go of my UART! Message-ID: <20170122190659.GA62786@bluezbox.com> References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Dustin Marquess (dmarquess@gmail.com) wrote: > On Sunday, January 22, 2017, Hans Petter Selasky wrote: > > > On 01/22/17 06:07, Dustin Marquess wrote: > > > >> [Sorry if this is somewhat of a dupe, I have yet to find a solution] > >> > >> I've been running FreeBSD on my Pi 3s for a little over a month now, > >> first using gonzo's SMP code + a home cross-compiled kernel, and then > >> I moved to the HardenedBSD images. All of them work great except one > >> issue that's driving me nuts... > >> > >> The downside to the Pi 3 vs some other boards is that there's really > >> only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with > >> a GPS board. > >> > >> 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and > >> that's "fixed". > >> > >> 2nd issue: Even with a USB keyboard attached and HDMI output > >> connected, FreeBSD still wants to steal the first uart (ttyu0) as a > >> console port. I thought that would be fine as long as I use "-m -n > >> -q" in the boot config to disable kernel output and then "conscontrol > >> delete ttyu0". Well, that KIND of works. It seems to work fine when > >> using 115200bps, but trying to change the baud rate to match the GPS > >> unit doesn't seem to work at all, I'm guessing because it's still set > >> as an available console? > >> > >> hint.uart.0.flags="0x0" doesn't work, as it still marks it as a > >> console. console="efi" seems to be the only setting that works, > >> "vidconsole" and "nullconsole" both don't work. > >> > >> Is there a way to stop the kernel from trying to claim the UART as a > >> console? > >> > > > > I think so, have a look in /etc/ttys and comment out the ttyu0 line. > > > > Sadly, I already did that. There's no getty running, but dmesg still shows > the kernel marking it as a console. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: selasky.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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, 22 Jan 2017 19:07:06 -0000 Dustin Marquess (dmarquess@gmail.com) wrote: > On Sunday, January 22, 2017, Hans Petter Selasky wrote: > > > On 01/22/17 06:07, Dustin Marquess wrote: > > > >> [Sorry if this is somewhat of a dupe, I have yet to find a solution] > >> > >> I've been running FreeBSD on my Pi 3s for a little over a month now, > >> first using gonzo's SMP code + a home cross-compiled kernel, and then > >> I moved to the HardenedBSD images. All of them work great except one > >> issue that's driving me nuts... > >> > >> The downside to the Pi 3 vs some other boards is that there's really > >> only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with > >> a GPS board. > >> > >> 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and > >> that's "fixed". > >> > >> 2nd issue: Even with a USB keyboard attached and HDMI output > >> connected, FreeBSD still wants to steal the first uart (ttyu0) as a > >> console port. I thought that would be fine as long as I use "-m -n > >> -q" in the boot config to disable kernel output and then "conscontrol > >> delete ttyu0". Well, that KIND of works. It seems to work fine when > >> using 115200bps, but trying to change the baud rate to match the GPS > >> unit doesn't seem to work at all, I'm guessing because it's still set > >> as an available console? > >> > >> hint.uart.0.flags="0x0" doesn't work, as it still marks it as a > >> console. console="efi" seems to be the only setting that works, > >> "vidconsole" and "nullconsole" both don't work. > >> > >> Is there a way to stop the kernel from trying to claim the UART as a > >> console? > >> > > > > I think so, have a look in /etc/ttys and comment out the ttyu0 line. > > > > Sadly, I already did that. There's no getty running, but dmesg still shows > the kernel marking it as a console. Just a random idea, try adding hw.fdt.console=foo0 to /boot/loader.conf This should force uart_cpu_fdt_probe to fail. -- gonzo From owner-freebsd-arm@freebsd.org Mon Jan 23 00: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 C133DCBA11F for ; Mon, 23 Jan 2017 00:11:12 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 976993BC for ; Mon, 23 Jan 2017 00:11:12 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id E454A406061; Sun, 22 Jan 2017 16:11:10 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-arm@freebsd.org From: Hal Murray Subject: Re: Durable/serious arm hardware ? In-Reply-To: Message from Karl Denninger of "Sun, 22 Jan 2017 09:29:55 CST." <7900e188-88c3-74a1-09b1-628494b890be@denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Jan 2017 16:11:10 -0800 Message-Id: <20170123001110.E454A406061@ip-64-139-1-69.sjc.megapath.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: Mon, 23 Jan 2017 00:11:12 -0000 karl@denninger.net said: > I have a number of RPI2 devices in production use running process-control > type things and none of them has had stability problems. I *have* had SD > card issues on occasion, but that's not the machine itself..... of the RPI2s > I've got in use I've had zero failures and no stability problems at all. You can get in trouble if your power isn't solid. Basically, using a micro USB connector for power is a kludge. The Adafruit wall warts are speced at 5.1 V for a little extra. You can get USB cables with heavier gauge wire. If you steal power from a PC, the spec limit is 500 ma, and that only after you negotiate. Default is 100 ma. So basically, all bets are off. If you use one of the little USB inline power meters, that drops another 0.1 volt or so. I had troubles with a cheap power cube. It had 2 USB sockets. I thought I was going to save on outlets, but it was fat enough so that you couldn't put 2 of them next to each other in a power strip. It worked at first, then it aged or the software changed or ... Then the first Pi would die when I plugged in the second one. Drove me nuts for a while. ------- Other than that, they work OK for me. It I was planning to install one for production, I'd pay a lot of attention to SD card life time. For light load, the limiting factor on the uptime is updating the kernel. (or wall power, or ...) -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Mon Jan 23 06:24:19 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 3E96BCBD7A1 for ; Mon, 23 Jan 2017 06:24:19 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 066338E9 for ; Mon, 23 Jan 2017 06:24:18 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-yw0-x22c.google.com with SMTP id u68so90345421ywg.0 for ; Sun, 22 Jan 2017 22:24:18 -0800 (PST) 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=qRbefxMreaKZvyan4RY+dSYn/aa0G5umzYr+/v4U0/E=; b=Ij/bHncqb6iz6yFB8V5uDs69Bh54lzz6hIhv9X6p5qA0fA37KUxGRb93HE+JL2b+0t 1KMGzTlFqMW5DTfEcQUewuAYPGjiKbNt8N1pEaduNRu6P/s2YtbBzctRpiGpPETCcbfv 1mh/s/CTCwJ0bwLaHg7E17nVyjK8tSCUVFPpTMr+yMhABekvxQkelbnufGQnvCbEgFNs HeU5Km4Ao0WLp/E/rXew0gQjJXtfB6+gKRFpwGKAFi+d8TRA3L8DbuDDSOV9Ub3i9510 JV1bnmNfykB8ScXg0MZNQaYr4O3aEsgEYeOukOC/pzBxpFhJUN8obYiYh48jSeaGlm1Q FjGQ== 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=qRbefxMreaKZvyan4RY+dSYn/aa0G5umzYr+/v4U0/E=; b=UGXUXbhjVjtK2UcVwcUsHNeR0e6NWAS63JJk69qOtNfBhi09o6TfOxFJMZJBvPCLkC tN9RmN/6x58klCGYPFspnSDnbusC3xvRggJMyPoeQxL3aX8efE3m9hYGx8K4E7TqtN9q MjEkGszImRCUb3LCQipfdLU9S4mfDjkU6ETxmXf40MYM2P1FHq6jWQ3S8rqlcnO9no3B k0Rn0dQzlP5tRlOmM8fL7zNy1WDpqXQ6uNVBmFcRpztWmziVTu8vfwo8ctm2mxOTueM0 JfuayJARwIdlNXerMrfRWSW1WxPtMkQ3Wtzap1i2WtwnQe+cBcKmADzb0+eDG+wvWzLU I5wg== X-Gm-Message-State: AIkVDXJs5rbTnjibHRtzNfNQq5OT+xj5ZtKl3ziCsVOFk9+qAuBVkvNvna6D3gn3Cy+i0lzTWHWi7SCUqW6Wiw== X-Received: by 10.129.75.147 with SMTP id y141mr19970814ywa.86.1485152658147; Sun, 22 Jan 2017 22:24:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.231.135 with HTTP; Sun, 22 Jan 2017 22:24:17 -0800 (PST) In-Reply-To: <20170122190659.GA62786@bluezbox.com> References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> <20170122190659.GA62786@bluezbox.com> From: Dustin Marquess Date: Mon, 23 Jan 2017 00:24:17 -0600 Message-ID: Subject: Re: Getting the kernel to let go of my UART! To: Oleksandr Tymoshenko Cc: Hans Petter Selasky , "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, 23 Jan 2017 06:24:19 -0000 On Sun, Jan 22, 2017 at 1:06 PM, Oleksandr Tymoshenko wrote: > Dustin Marquess (dmarquess@gmail.com) wrote: >> On Sunday, January 22, 2017, Hans Petter Selasky wrote: >> >> > On 01/22/17 06:07, Dustin Marquess wrote: >> > >> >> [Sorry if this is somewhat of a dupe, I have yet to find a solution] >> >> >> >> I've been running FreeBSD on my Pi 3s for a little over a month now, >> >> first using gonzo's SMP code + a home cross-compiled kernel, and then >> >> I moved to the HardenedBSD images. All of them work great except one >> >> issue that's driving me nuts... >> >> >> >> The downside to the Pi 3 vs some other boards is that there's really >> >> only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with >> >> a GPS board. >> >> >> >> 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and >> >> that's "fixed". >> >> >> >> 2nd issue: Even with a USB keyboard attached and HDMI output >> >> connected, FreeBSD still wants to steal the first uart (ttyu0) as a >> >> console port. I thought that would be fine as long as I use "-m -n >> >> -q" in the boot config to disable kernel output and then "conscontrol >> >> delete ttyu0". Well, that KIND of works. It seems to work fine when >> >> using 115200bps, but trying to change the baud rate to match the GPS >> >> unit doesn't seem to work at all, I'm guessing because it's still set >> >> as an available console? >> >> >> >> hint.uart.0.flags="0x0" doesn't work, as it still marks it as a >> >> console. console="efi" seems to be the only setting that works, >> >> "vidconsole" and "nullconsole" both don't work. >> >> >> >> Is there a way to stop the kernel from trying to claim the UART as a >> >> console? >> >> >> > >> > I think so, have a look in /etc/ttys and comment out the ttyu0 line. >> > >> > Sadly, I already did that. There's no getty running, but dmesg still shows >> the kernel marking it as a console. > > Just a random idea, try adding hw.fdt.console=foo0 to /boot/loader.conf > This should force uart_cpu_fdt_probe to fail. Wow, I think that actually did the trick! Thank you so very much, I've been pulling my hair out of this for probably 2 weeks now! -Dustin From owner-freebsd-arm@freebsd.org Mon Jan 23 07:07: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 1671ACBD510 for ; Mon, 23 Jan 2017 07:07:39 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB38310E1 for ; Mon, 23 Jan 2017 07:07:38 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-io0-x22a.google.com with SMTP id j18so103930455ioe.2 for ; Sun, 22 Jan 2017 23:07:38 -0800 (PST) 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=ghBD7SLAQSfUjEIuq/UVN+rS5eRvylhllOsvJn72KTY=; b=J1Ku8jQxjf+iwX2VoVB+cVWprj/YeaWbXraCYYQa1WJYJ/pZZo6PNzHfGiriN/6Rtd BdYw74XM1iJkbWkr5sQA7vXFfs3GdpCfr/18KrzgJOqjO6D/PtKNhlBhnZgZRyoH5B2m WjLzj2UZnd6kOl++lSJOeUjnhId8SwDiPgLb8= 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=ghBD7SLAQSfUjEIuq/UVN+rS5eRvylhllOsvJn72KTY=; b=FySG+xl+2J7sdD4OD8f25oz5Q1xoOPbWYo0DpzlIv1I2RWswohmSNhNefT7bhgaut6 C5M5btT79eOMgQ90W91MxmhHC87Z5qkYS8P78HXndNSbbUGv9e6ssUuQPikaQYJtbcaS X7VefLTKo6KtoPXfsaT67d6nCxC/vCrzJ4F/OfXCmNk/k62BoMy3AGsVSE8W8/w1xH7u aJeteacPioo6wGnRzjcNaEdqtcxL/oSiedbFiHlWt7Efl3gk82pISllIk3X48YfMRkDM Sm7BtiEdhZSzhBtjM6N3gu7/jcYcB3jmk0bS4uVLrgSsLD7YJX4HDz80sGxuE0q63cKK Uc8g== X-Gm-Message-State: AIkVDXLSBIAfC7idi80o2nMDE7mxPcgG2ALaRVpGgWEDhE+OzOwWElT943DIKsDso3zMiT8htDzU7KQR1p8F7f55 X-Received: by 10.107.53.13 with SMTP id c13mr23910379ioa.55.1485155258046; Sun, 22 Jan 2017 23:07:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.132.65 with HTTP; Sun, 22 Jan 2017 23:07:37 -0800 (PST) In-Reply-To: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> From: Jim Thompson Date: Mon, 23 Jan 2017 01:07:37 -0600 Message-ID: Subject: Re: Durable/serious arm hardware ? To: nowhere 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: Mon, 23 Jan 2017 07:07:39 -0000 We have a little two port router based on the same SoC as the BBB. I selected that platform as one of the better supported platforms on FreeBSD. It still took a lot of (months of) work to make the freebsd (and subsequently pfSense) for it into something that could be a "product". All the FreeBSD work is in the tree. Most vendors don't do that. That's not a humble brag, it's a statement of truth. We're currently in discussions with a vendor to get the Ethernet driver for our next ARM product, since, ..., it's not in the tree. The SoC vendors all have Linux on the brain. They see a much larger market there. Convincing them to dedicate resources to FreeBSD can be challenging. One of the things we've been able to do with pfSense is to show real volume for a FreeBSD based application. I can go to a SoC vendor (TI, Marvell, etc) and talk about committing to, say, N x 10K+ unit volumes. That tends to help get their attention. The Foundation helps a lot here, too, which is why I won't take "donations" for pfsense and instead direct people to donate to the FreeBSD Foundation. In closing, the board you name are all "developer / hobbyist" boards, and may not have the level of engineering in them that it takes to make into a product. At least two of them are price-supported, where a non-profit gets some portion of the BoM discounted, which makes for a very low-price board, but also brings some short-cutting (try to get a warranty claim on a BBB or RPi). Jim On Sunday, January 22, 2017, nowhere wrote: > > Hello > > I'd like to hear from the most skilled of you, if anybody knows serious > arm based hardware or share this though : I'm becoming convinced that > theses hardware (arm based) are just the consumable-smartphone fashion > counterpart for kids and leisures or tests. Not really final and carefully > finished products; abble to works for years or a decade; doing is job in a > office corner, being forgotten by anyone, like some of my older freebsd > servers wich are running for a decade now. > > > Those past years, I've bought 3 arm based devices : > > 1 raspberry-pi , which was affected by the "micron-ram-chip" bug: except > with debian, it never booted on freebsd (I even tried netbsd): I just > trashed it yesterday (bought in 2014 i think). > > 1 Beagleboneblack : works fine for weeks then freeze suddenly. And > sometimes did not event reboot (*): had to loop-reset it until boot process > go to the end. Seem the most "workable" product so far.. (bought in 2015) > > 1 olimex a20-lime2-emmc: my most recent buy. It did not event boot with > network with it's own debian sd card... (I did not yet take time to make > it's own freebsd sd card): (bought in 2016-07). > > My goals, for example, with theses boards were to give some of my nomads > customers, a box with an autonomous dhcp/dns/vpn server on theyr networks, > without the need to change anything else than disabling their dhcp servers > for instance : I think a Quad xeon racked server is a bit too much for > theses tasks; I was using pfsence on pcengines boards before to do this > kind of things. > > Since my conclusions are based only on theses 3 boards, I'd like to hear > from thoses of you who works daily with these boards, and thoses opinion > are based on far more than my hand counted experiences. > > > PM. > > > > (*) I work with a 5V/5A (25w) psu: that's not an overloaded psu problem; > Not a damaged emmc/sd card problem too: all my systems are read-only-root > based: seems to really be an hardware issue. > > > > > _______________________________________________ > 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 Jan 23 07:38: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 D1330CBDE92 for ; Mon, 23 Jan 2017 07:38:57 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 A2D5C341 for ; Mon, 23 Jan 2017 07:38:57 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id 189so39323015pfu.3 for ; Sun, 22 Jan 2017 23:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=pQHWatfj90EH+EB/wbUp5jOQDaJ738fgDbEfw0EBsQE=; b=aJEAByzBEUGmiEC7hrlRlX0Z6NWBhyfDIViaG2sBgeQkYhNcyz7diLlz7BKNYnIvX9 AiC8gct7oo4XS6DMnNmlgh63W1/zUbF5C/D28UfXAgOrbbxT+6sVFUjubZx9aWRtYKmW FKxE2aMLfWs5Mv9qkFWWqZ9sESEOyHWyHBa70ce/Asjsqt1+/nrkBlReVMvFje1+ULlL tRLf9w5qR9eeNq4dcUY9Aofi7ZpbJjINtTjqlNgtpcMfBPcIuA0kisbnsGcaRPVzpxGC +h6beYowbZs7RUBQOfPpLRe/aWXji7w/Sm8p4IVbAwjwelOb4KJY7L0dBGbkdgk26unb jjRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=pQHWatfj90EH+EB/wbUp5jOQDaJ738fgDbEfw0EBsQE=; b=t9JH9KF/Gh9bm/lSk7zdM0U6m1LjYwpjxlgHeH7Vy+RAIYOOHv/gik775Klz8qXP00 ChFg27QJo/8WtnU2tXcTva1onSsdIOwOSgsu5er+8Tej1nZgEDFg5WxZKZY/LirBMLAz w635qJOlsYFOn5EbsT3ms952X7UhkHJNW5jLPetfynIkqn1V9WbrkG84e/uj8kbgVHzq p2ZfsIsJWX7qu5ozOI/9yupLIcVXCL3Qzv+Hr7Vmq7wjUHqlnowwiA3PGjy6O+xQx168 ceQMgYqShiu2AV0yX3rsSpYUd2nl9xNV+IvkmAMvdYMr9O94Ecss3vNoLBkqWrxgXqiW YO9g== X-Gm-Message-State: AIkVDXLVElfAcUTrx2DE0r2FPtoeBuCvzoXft8mEq5N8IttraKVCJpy7UG9z+bb0x6Qrqg== X-Received: by 10.98.29.195 with SMTP id d186mr30327254pfd.144.1485157137020; Sun, 22 Jan 2017 23:38:57 -0800 (PST) Received: from ?IPv6:2600:8801:2a04:2200:9219:b518:c758:ea36? ([2600:8801:2a04:2200:9219:b518:c758:ea36]) by smtp.gmail.com with ESMTPSA id f188sm26144812pfa.35.2017.01.22.23.38.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jan 2017 23:38:56 -0800 (PST) From: jungle boogie Subject: arm board purchase for 2017 To: freebsd-arm@freebsd.org Message-ID: <16d6ab8d-94fb-38d3-e8ad-1b1daa591355@gmail.com> Date: Sun, 22 Jan 2017 23:38:54 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 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: Mon, 23 Jan 2017 07:38:57 -0000 Hi All, I'd like to purchase a SoC arm system and run FreeBSD on it and possibly openbsd, if it's supported. My go to purchase I was thinking of was a raspberry pi3 because of the great support coming along with it in FreeBSD. At the moment I don't plan on doing any hardware hacking, mostly software stuff like seeing how freeswitch would run/build on freebsd ARM, postgres building, possibly tinc and dn42 VPN stuff, etc. Is the raspberry pi the preferred board for software hacking, or is there something a bit better but still under $100US that's preferred? Contenders I'm aware of: banana pi cubieboard odroid pandaboard parallela raspberry pi I own a beaglebone black right now and it runs -current. I also own a pine64, which is running Debian. I haven't yet tried out freeBSD on it. I know (and thankful for) Brad makes images for it. Does anyone know how it's performing? Outside the arm world, has anyone tried freeBSD on a MinnowBoard? https://www.minnowboard.org/ Thanks for any input! I did read through this thread but I'm not looking for industrial usage: https://lists.freebsd.org/pipermail/freebsd-arm/2017-January/015443.html Best! From owner-freebsd-arm@freebsd.org Mon Jan 23 07:46: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 5E74CCBC0BD for ; Mon, 23 Jan 2017 07:46:14 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BEC895F for ; Mon, 23 Jan 2017 07:46:14 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-io0-x22b.google.com with SMTP id l66so104427203ioi.1 for ; Sun, 22 Jan 2017 23:46:14 -0800 (PST) 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=5SEiXoPmbQ4GsW0WBPFXrIHPuzZ/4yP8//gKykuHZLY=; b=ERbIRDH7NUvvwd1UrWiIw6ZZ7c5hVGdJOMxAP7YvBcQ6rbOc3V+MNGZr7VbpbAOUdN UxoIfNveVT+CUFb8UbH3lTehKBiDWTjCMV40tSWMuwJ+CVmtLG8Hh27s03l/KyjIHT2h uRXNnwhcpdDyCVeaOTZmc5RZNdVYPKlD0Ikc4= 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=5SEiXoPmbQ4GsW0WBPFXrIHPuzZ/4yP8//gKykuHZLY=; b=k7zYsI08INmbpGXBK6mN+V3+9MdvI9101A1biq1ctWHspHJaJLqwxOOtajI4lnrh1W FK4+O2IexFZ0ssc8P01ci130hCyBilXYG5F7FS0t2hm57iO2yB1poXE38MqGfjielN5o 0qxEVS4u4PQPCWfxPcZtBekDSoW61mTAtkzH+hCf510jXS4n0u3wi38V6AcPqmkxwOCU CwvlzP8KbKMCyhJ0Bj66Fcw13HeJU4R7FBcm5+CXErVFEqp5V44GBwJfdGMfRnEzU5Dk v3zj8K/hcReQJ4515C0Y/nJgN1LhCTq5vBHH4m+g/oGxQTgaXxvL1OeIP2d6UnMOx18K 9vyg== X-Gm-Message-State: AIkVDXLsJBGDRwD7w8y1MG5yjPhGfZRQMVI7JGOEBFUVRMW+tL+JWPZuabkpdfxTlTrtSPUp2mQZol/Ty0jUpVlo X-Received: by 10.107.53.13 with SMTP id c13mr23992765ioa.55.1485157573674; Sun, 22 Jan 2017 23:46:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.132.65 with HTTP; Sun, 22 Jan 2017 23:46:13 -0800 (PST) In-Reply-To: <16d6ab8d-94fb-38d3-e8ad-1b1daa591355@gmail.com> References: <16d6ab8d-94fb-38d3-e8ad-1b1daa591355@gmail.com> From: Jim Thompson Date: Mon, 23 Jan 2017 01:46:13 -0600 Message-ID: Subject: Re: arm board purchase for 2017 To: jungle boogie 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, 23 Jan 2017 07:46:14 -0000 On Mon, Jan 23, 2017 at 1:38 AM, jungle boogie wrote: > Outside the arm world, has anyone tried freeBSD on a MinnowBoard? > https://www.minnowboard.org/ No. Never. Why do you ask? ;-) /s (Somewhat less sarcastically, we're the largest supplier of MB in the world, and we're ... FreeBSD friendly.) Jim From owner-freebsd-arm@freebsd.org Mon Jan 23 08:00:15 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 2B6C9CBC97A for ; Mon, 23 Jan 2017 08:00:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001: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 ED5461A5 for ; Mon, 23 Jan 2017 08:00:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id j18so104613376ioe.2 for ; Mon, 23 Jan 2017 00:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=F4TKgv51Bx/9yOQOf5KDX/9QmeLFmufD6wdpfZnnodo=; b=xH3FCj90eUJiSClxQ1JT7FUR3QsFpy/ZE1zsvgAeoKdlGpJCXlJ1hcnxx8+oztUR+/ /9rT3OlyUWTwrVY4QJirBcbZUGGCUMcUWOvRB0XZ+LqODGt9f0sHPuvhfor877IQ/yln JAQBL2Lbf1YZhqRg+EfvhdJQEseV/QII4oiyOXb5XpxCkk+Bkcw27dI+pyrI6U0eH507 AQ27Gij7YnZhPHobzIQtxwKvVfvjZkjJAd59J+Y6yrcQQHR4Sf5R0NrX0iMnKynqNp/h FVgW4K1HjaGOKTGybFdzWGLkjPKUQ8XFzArnUK2b7EazPpKBFygDdhnMNtfSQVK1NPId WMZw== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=F4TKgv51Bx/9yOQOf5KDX/9QmeLFmufD6wdpfZnnodo=; b=RT6Eot/Lw8oOKsRdmxlpRShyg96c9GFKHhG1E9N7IY8n3yCIhOn8lZRBU7pxvaISYL N1eSkvUSWdcgGvIb3N8fJr2sujuSzQWIs6c4+jlpTAF3Ez547kqFwdBwLrlpTHbnimxS 8tJdfTrRIMNvvzLBknCLt2Leyrx39c6RtvPyFlcf3zqCbQJQ3ebpTBt6pjp1/RU9iG74 1o+xrxXdiJtt/KYGIs1DPbr78n3fPoutwqQC097y8y8HuRTCENCzNpy8zCwFI/udNzCt 72fLsaR2mdYIVxQ6MWKC935lOOJML/nVLyiMW87Zj9nc51N4wqDekyGlRWqu53ebtrEw nQIw== X-Gm-Message-State: AIkVDXJoUcsjPURvRXcB82a6XgtM26XfTESFAuha9QsX9XTaXyWaTrp11w5zYYwCcpVb/KQq2yCXhgKAIDrjdg== X-Received: by 10.107.20.13 with SMTP id 13mr22769654iou.0.1485158414165; Mon, 23 Jan 2017 00:00:14 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Mon, 23 Jan 2017 00:00:13 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <20170122062420.101cb9ea@planb.netng.org> References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org> <20170122062420.101cb9ea@planb.netng.org> From: Warner Losh Date: Mon, 23 Jan 2017 01:00:13 -0700 X-Google-Sender-Auth: wI7QSiIBJ_OsvIWvDiJer8lOxAA Message-ID: Subject: Re: how to measure microsd wear To: Vladimir Botka 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, 23 Jan 2017 08:00:15 -0000 On Sat, Jan 21, 2017 at 10:24 PM, Vladimir Botka wrote: > Hi Warner, > > On Sat, 21 Jan 2017 20:32:38 -0700 > Warner Losh wrote: > ... >> Some SD >> cards are awesome: they are fast, reliable and rarely brake. Others >> are slow, unreliable and crap. Utter crap. Not worth the time it takes >> to order them. > ... > > Would it be possible to share the brands? Thank you. > > -vlado From owner-freebsd-arm@freebsd.org Mon Jan 23 08:01: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 82DE6CBCAC5 for ; Mon, 23 Jan 2017 08:01:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 4B4C92C9 for ; Mon, 23 Jan 2017 08:01:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id k200so22221616itb.1 for ; Mon, 23 Jan 2017 00:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IJi098Nm+S0hDo+yt2VEA9gmyQZMuV0cIOIaO5CyyQ8=; b=mchewM78XEpKWmfy56OnR6+5wKr2hzPP1URv0hGyiLAf6HwO2r3OTqb0FR4dfGEnJR s6VPKk/xu2UM8VAxfV1WKYTyUamojD6h1TMXs/34NbAXNln4YqfRp/HP67YEUiIZcOpm 8PMcLtmyjx349feZMoXgneKJWZogc4bQdGHnxkBQTC5MELxTfreJ1xUt4PWIAoUSzXU1 EsSKqNyAZG+7SVcdwoe0VT2hxsHZCN2wFDrImjX+goI2s3k1hrL9X13DU6D95TnjLNtO tiUaAdiCdnbKieZ5BgGEsq2zBA+lGLOL5iKfWSZdbOHlB/T4W++bASasWxeRufdS4Vhi 2ivw== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IJi098Nm+S0hDo+yt2VEA9gmyQZMuV0cIOIaO5CyyQ8=; b=eu1WkesHhzdTZ2LRpaEl6Hz1py/t1bFEeDAg+O3KXSXNsX3efVVnTyF2VMut0OeVYT D+x+/z+YCPY4PwMwxmv4E5TQpFzYCA/oSQE8jMHD234Du8Pum7bG3nlxE/8rZOsDJ2Vt lQaf+Q6RtrthPf5BWpk60byY34V6Yvb8Q8MmR7GlNQvj0Mxqts6xO9+sETnmU9sS2xmC HQFiC3QXaB7uLtjAWHBLA6L5zF4pbMJFteC+J/8Wj8yQ2xv6G25s1NSkCGwUWM0iHw1o w3fE1CCnjd60lYRcP9joiBFJJR3IL7eW9DuCgh3nM845BDKxNO2pkrJXeHiuhUpH1dhS Ef2A== X-Gm-Message-State: AIkVDXJNDopZZzBNI/0BC8DjyRR8ddnqPFB3jTkwrivFWzq84z5hWuBhc2uR8c/BFcDY6PbhKsbdrz2CX/Y5Aw== X-Received: by 10.36.116.71 with SMTP id o68mr14818433itc.60.1485158471507; Mon, 23 Jan 2017 00:01:11 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Mon, 23 Jan 2017 00:01:10 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <20170122062420.101cb9ea@planb.netng.org> References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org> <20170122062420.101cb9ea@planb.netng.org> From: Warner Losh Date: Mon, 23 Jan 2017 01:01:10 -0700 X-Google-Sender-Auth: JuoL1NM7B_bRCMiEwY8th0AMISs Message-ID: Subject: Re: how to measure microsd wear To: Vladimir Botka 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, 23 Jan 2017 08:01:13 -0000 On Sat, Jan 21, 2017 at 10:24 PM, Vladimir Botka wrote: > Hi Warner, > > On Sat, 21 Jan 2017 20:32:38 -0700 > Warner Losh wrote: > ... >> Some SD >> cards are awesome: they are fast, reliable and rarely brake. Others >> are slow, unreliable and crap. Utter crap. Not worth the time it takes >> to order them. > ... > > Would it be possible to share the brands? Thank you. Nope. All brands do this. They have different lines and different branding and at different times they all have issues. Warner From owner-freebsd-arm@freebsd.org Mon Jan 23 08:02: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 A137CCBCCCE for ; Mon, 23 Jan 2017 08:02:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 6B38F7D9 for ; Mon, 23 Jan 2017 08:02:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id l66so104650762ioi.1 for ; Mon, 23 Jan 2017 00:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R1ZiBVhAub02oqo/+JI4A1uXv160hG0pcOEVuDr3oFc=; b=tnAEfJKEqtUExvi7mA9+up3hwNZBEysDrtcPSuq0o9BOU9Ub3bctlZBeLu7QU3p7wF W/RP+pNY9oZotZpvCxyxB6zN84mUM0CHAwTS1IPTYN792lYb+qrfnD6ljS/GPlWcxFDp s342bwAoLVHx8qdVyhwO0x407ZaamJaMJ/GqaiICX9YvBnSA/ttUpIHiGJz4Y4gWjggV 126a3qfRNqh57dobAXbhQ39ugvMawB5qgXH2QWiDIKyOhSlg///yFR2spmxbrxVuaYtC 6x3hHr7uCCu5Fkhtklg1L7G5z6rYeYK+r7pJXLQdhuGbDHhU8l3A6PjoIjYyg6MmbMnJ 4y8Q== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R1ZiBVhAub02oqo/+JI4A1uXv160hG0pcOEVuDr3oFc=; b=PB4xGQAXgJkdCJzfR8/xwfOOtaRmVVVYarB+sChbIMDmIFQclHQanb/Q+u2YE43su+ 1b8Pnu2Wu70PDOdje1/nu9f+gg+YyWFXvyp8QMRxShtbYcZtqSLReq2MzoG3NWnhQByh mdiw1H2BwGDe0QKmykmm86nCLt+0PpFCIOH1ZWmfybWaHDdE3q0mg3PqCXxa9HhaGXSW zo9KZxH/PxD29xKAyn43SYoVmD+GP/2f3wY+CPrToeuGJVCrqo3XN/wF6W7TqsnGuYGx hgq9pC5TGDyGuYNGl+OPcrKRcNEf7ZLifZckju9mnrZaniF8x6RbMwsg1wnsK0fODETr vkUA== X-Gm-Message-State: AIkVDXKDB+fHxWcRsum/lsqn/i0p6/twNb3CLZms8gDYTaWZ6VPRVuZr9WnypAIKTxokG0Z0mshf8/1zB5ozSw== X-Received: by 10.107.139.131 with SMTP id n125mr25509754iod.166.1485158566778; Mon, 23 Jan 2017 00:02:46 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Mon, 23 Jan 2017 00:02:46 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <201701220253.v0M2rkrl095913@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Mon, 23 Jan 2017 01:02:46 -0700 X-Google-Sender-Auth: T8orVe8R0hNqchMKL19L8bjYB98 Message-ID: Subject: Re: how to measure microsd wear To: tech-lists 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, 23 Jan 2017 08:02:47 -0000 On Sun, Jan 22, 2017 at 4:55 AM, tech-lists wrote: > On 22/01/2017 02:53, Rodney W. Grimes wrote: >> In either case the manufactures of flash devices have made it very >> clear that these things DO have a write cycle life time, and that >> your going to see a failure eventually if you write enough data to >> them. > > Hi, > > Is there a way one can see how many (or an average) number of write > cycles the cluster or device has had? In order to get a handle on when > it's likely to fail. Or to see what's been remapped and how many more it > can remap? If not on freebsd then on any OS? > > Maybe something that tests # remappable and warns when there's nothing left? > > I mean it's all fair and well the manufacturers saying it will fail on > average after so many writes, but that uncontextualised information is > useless if one cannot establish how many writes have already happened. There's no standard way to get this data. There's several ways to get this data, but it's a terribly gerrymandered, poorly documented landscape at best. Warner From owner-freebsd-arm@freebsd.org Mon Jan 23 08:19: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 AD09BCBD2BF for ; Mon, 23 Jan 2017 08:19:57 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 8F284F46 for ; Mon, 23 Jan 2017 08:19:57 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cVZqy-000Hd9-CC; Mon, 23 Jan 2017 00:19:57 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0N8JpWU067774; Mon, 23 Jan 2017 00:19:51 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 23 Jan 2017 00:19:51 -0800 From: Oleksandr Tymoshenko To: jungle boogie Cc: freebsd-arm@freebsd.org Subject: Re: arm board purchase for 2017 Message-ID: <20170123081951.GA67692@bluezbox.com> References: <16d6ab8d-94fb-38d3-e8ad-1b1daa591355@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16d6ab8d-94fb-38d3-e8ad-1b1daa591355@gmail.com> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: jungle boogie (jungleboogie0@gmail.com) wrote: > Hi All, > Outside the arm world, has anyone tried freeBSD on a MinnowBoard? > https://www.minnowboard.org/ I have. It boots FreeBSD just fine. Network, USB, HDMI work. snd_hda recognizes PCI audio device but I haven't actually tried it. Also haven't tried SATA interface yet. I did some work on GPIO, I2C, SPI, and SDHCI support for this board and wrote up summary few weeks back: https://kernelnomicon.org/?p=767 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: kernelnomicon.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: Mon, 23 Jan 2017 08:19:57 -0000 jungle boogie (jungleboogie0@gmail.com) wrote: > Hi All, > Outside the arm world, has anyone tried freeBSD on a MinnowBoard? > https://www.minnowboard.org/ I have. It boots FreeBSD just fine. Network, USB, HDMI work. snd_hda recognizes PCI audio device but I haven't actually tried it. Also haven't tried SATA interface yet. I did some work on GPIO, I2C, SPI, and SDHCI support for this board and wrote up summary few weeks back: https://kernelnomicon.org/?p=767 Haven't put it to heavy use but it seems to be fairly solid board. -- gonzo From owner-freebsd-arm@freebsd.org Mon Jan 23 08:35: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 6BC2FCBD6CB for ; Mon, 23 Jan 2017 08:35:18 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3180D36 for ; Mon, 23 Jan 2017 08:35:17 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id r144so24639184wme.0 for ; Mon, 23 Jan 2017 00:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version; bh=U/Q9YTNyDDS95TUWgrbrTfa4r65UHUE3n5MJalWzu2k=; b=dA2Gsh8Q36bhqWJF6/3memtrJcCjk0qVZmQtKa6JDWrkbPXxWZgSwCRyNDurvhI+ep 9uwA9k4WAetKcQZgrYlbDWuVCeGp6RytHsWi8ecHtbKbmPhQ9kA6Azww3MgMrlycq1en NXDWFFdxdnWWvDgfOxjj43ihNywHzP1uMFVmxZ/HmLA85U7fm8Q3Pm4I9EQwZDE3IYSr izjVmqiM3KVkJeDnGMzHCNVDsud3DTBK1HjDYugnqJBBjzz3J20n0z4SgIZazejyqLV1 B4yMg3FBqkxtxnkSpXPMJdg6Cda/ulz8v9OS7ZW+dQC7L2OOV/8+H0s1zqJfMn+3gvGb ae1Q== 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:in-reply-to :references:organization:mime-version; bh=U/Q9YTNyDDS95TUWgrbrTfa4r65UHUE3n5MJalWzu2k=; b=c9Zr+Br0LqTjL/PA4lXe1eC5jDuOlEgCp8IUY2bT5DVKOHSjh5a0DQvxefafKMZFIw I9/kIzXnCXDKdIL6gzwX43FJRE2Vu4fUZqUo5MEu2aKa2joxEtoKX8+cRJSAupKu3GKh IicYqr3sFQiM1xlD3wyn1OHUHJWRCVVxVycGQUT98Kz+41knVUeX8ECwMtYVKVFtbW3X CKMZTXBlLYfAgIO+3X3Y+xjzGAYMBBPMowPUPBgynDU935uorRSPl196NtaC6F2gpSSq 95mir44FEIlA9tRsWVC04CQjE5GyTtRLH9HARjO5VKZOtHExMEVxVs5rfkEtkx6XRz9p WvSA== X-Gm-Message-State: AIkVDXIb5I+7HZ+a8/oxeZ4BOoPEDpALQtc8JAgzdMoWuovgBw1fYmNpUlTYnv8H1do4hw== X-Received: by 10.28.174.14 with SMTP id x14mr11986577wme.75.1485160516198; Mon, 23 Jan 2017 00:35:16 -0800 (PST) Received: from planb.netng.org (85-237-234-40.dynamic.orange.sk. [85.237.234.40]) by smtp.gmail.com with ESMTPSA id 61sm13350434wrs.29.2017.01.23.00.35.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 00:35:15 -0800 (PST) Date: Mon, 23 Jan 2017 09:35:08 +0100 From: Vladimir Botka To: Warner Losh Cc: "freebsd-arm@freebsd.org" Subject: Re: how to measure microsd wear Message-ID: <20170123093508.3cf2a311@planb.netng.org> In-Reply-To: References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org> <20170122062420.101cb9ea@planb.netng.org> Organization: na X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/PJa2Y7hNbbiH4=C2A5Dk78A"; protocol="application/pgp-signature" 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, 23 Jan 2017 08:35:18 -0000 --Sig_/PJa2Y7hNbbiH4=C2A5Dk78A Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Warner, On Mon, 23 Jan 2017 01:01:10 -0700 Warner Losh wrote: > On Sat, Jan 21, 2017 at 10:24 PM, Vladimir Botka wrote: > > On Sat, 21 Jan 2017 20:32:38 -0700 > > Warner Losh wrote: > > ... =20 > >> Some SD > >> cards are awesome: they are fast, reliable and rarely brake. Others > >> are slow, unreliable and crap. Utter crap. Not worth the time it takes > >> to order them. =20 > > ... > > > > Would it be possible to share the brands? Thank you. =20 >=20 > Nope. All brands do this. They have different lines and different > branding and at different times they all have issues. > Warner Then, would it be possible to share at least one that is awesome? Thank you. -vlado --Sig_/PJa2Y7hNbbiH4=C2A5Dk78A Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYhcA8AAoJEJDRmRKO1E8BwVUIAJmmsGmYhSrv7hrS4saVNnWu M5DDW01mjH3rtGazLq8gEphpXwziR1V8nQEcKRa1UKGGJ6iZp+lCY5arY54vcS60 AJ4AVd3ZYzO4yanSBhm71kov0wlRsF69mdvHMmQ3j+nAM3aj5NRGmAPw87Vlj8gg 88xlsJsKR4FENrOaCEWMrWb6dqZx02Dr3PEf8llIo5PpMphT63cfJflEVg3ZlREx FRgX52hzzCRtNgGLoYC/FS21S1kvljY82FQHohmTdqViDiYlN78WfJ3p8ebD7qAQ CHBeSUFsVwUsioBx1A5uR8UHjz8gZ4o0X6MfgK/cGlEFyJH34SgI8xoIQ9MeXww= =xVYy -----END PGP SIGNATURE----- --Sig_/PJa2Y7hNbbiH4=C2A5Dk78A-- From owner-freebsd-arm@freebsd.org Mon Jan 23 10:11:34 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 550ECCBC7EC for ; Mon, 23 Jan 2017 10:11:34 +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 2ADF164A for ; Mon, 23 Jan 2017 10:11:33 +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 D00AB22235 for ; Mon, 23 Jan 2017 05:11:31 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 23 Jan 2017 05:11:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; 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=mesmtp; bh=o3D2thvcuohMJsu 8VjMc99P6oMY=; b=PiRBA/a1MdzoPpaY/lkoqxaGPZB51Nda8h3dw7JWKLTZy2w 6YntFVZRURmh1qW5xLVcnj6e3OOBN9z0YespkR9zDx1KW8tkvawOhUd+b0EL+RKw vp4SMyf6isNMPHfIUSR0JqmWRYN5/sX+XmawAn5woZPJVvZo6uZ1MQ20VQQs= DKIM-Signature: v=1; a=rsa-sha1; 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= smtpout; bh=o3D2thvcuohMJsu8VjMc99P6oMY=; b=Bfcg1I0EBO7GhgFQ1aAf U/WARN25hNKWDz0VCBdYjZBFIOmGF8OFlTtOY7VLOl21Ig0lLzU6pmQah5al3/W9 cQ05XprhoOMf09ziEcfbHzFpXxtjRJzNxrT0L39Lw/CgWj4N7LJsnFEfshQuFlSc YchwTku6DtRycDB8TLQ3Ojg= X-ME-Sender: X-Sasl-enc: XbpjS9PAJeWIpJRBTXiRkVC/jPeLbFkVYWlOJhgBkzLN 1485166291 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C2577E2B2 for ; Mon, 23 Jan 2017 05:11:31 -0500 (EST) Subject: Re: how to measure microsd wear To: freebsd-arm@freebsd.org References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> From: tech-lists Message-ID: <58bb7c17-5ebf-9efa-cf3a-9d4472ebb8fa@zyxst.net> Date: Mon, 23 Jan 2017 10:11:23 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> Content-Type: text/plain; charset=windows-1252 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: Mon, 23 Jan 2017 10:11:34 -0000 On 21/01/2017 15:46, tech-lists wrote: > How would one measure microsd wear? Is there a utility like > smartmontools (I think this only works for regular hard drives) but for > microsd? Thanks everyone for your explanations. -- J. From owner-freebsd-arm@freebsd.org Mon Jan 23 10:30: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 BB427CBD06E for ; Mon, 23 Jan 2017 10:30:40 +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 826E4D5B for ; Mon, 23 Jan 2017 10:30:39 +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 B828C20554 for ; Mon, 23 Jan 2017 05:30:38 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 23 Jan 2017 05:30:38 -0500 DKIM-Signature: v=1; a=rsa-sha1; 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=mesmtp; bh=+/SE7+hBEEYikOg IhpTVzWcf9QY=; b=LGOfU4WoDzt8XUWJ9ViaAx22MuUmFiH6vyUUDSQnVen27Zw bDazpXXwzAfKgCf8BXF+QANzSxj9ECID87taz27BW5jN1KiNXcKE+/LhENC4pi+Y 1DWbQsRvIrjXjAOrR+MgX8CToxBJHi6r3036Bgcd+m87Lg5WQ0XeJUTpMjIE= DKIM-Signature: v=1; a=rsa-sha1; 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= smtpout; bh=+/SE7+hBEEYikOgIhpTVzWcf9QY=; b=cwu5ytjEzZxtpK8vupJz wqwQwvuCZ6FTjI/CLqnONPfPi3+IFErIBlzzw/FwqdkCiGdxpv+KmjGL+BuZDFtE AvGJEVlofqS0XbVYWRKZuO1px2wTtxZ9yzhdamsRAdv8IPb9BfGaI1L5NuZWyp+9 TAYW368wdhBDrmya3nLL8tE= X-ME-Sender: X-Sasl-enc: B/X7z9iU1yMrSHEK3oIvl4wP2toYtPVoQXecI7taLmmH 1485167438 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D0562450D for ; Mon, 23 Jan 2017 05:30:38 -0500 (EST) Subject: Re: Durable/serious arm hardware ? References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <185dbbb3-15eb-b63a-799f-d209858257b9@zyxst.net> <9AAE3A31-8EAE-4512-957C-40790C9D351B@gromit.dlib.vt.edu> To: freebsd-arm@freebsd.org From: tech-lists Message-ID: <2ec431c9-6c86-8be2-26e4-a94e2b38a66d@zyxst.net> Date: Mon, 23 Jan 2017 10:30:30 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <9AAE3A31-8EAE-4512-957C-40790C9D351B@gromit.dlib.vt.edu> Content-Type: text/plain; charset=windows-1252 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: Mon, 23 Jan 2017 10:30:40 -0000 On 22/01/2017 17:02, Paul Mather wrote: > I'm just curious, but with the RPi 3 having only 1 GB of RAM, what is > the compelling advantage in running it in 64-bit mode? (I've heard > that 64-bit applications can induce higher memory pressure.) Is it a > matter of providing a wide testing base for FreeBSD/arm64? Sort of. I've started saving ports as packages if they successfully build. It's still way faster than the rpi2B, even with only 1GB. TBH, I've not 100% decided what eventual role it will have. If it had 4GB it'd be pressed into a server role and run 24/7 -- J. From owner-freebsd-arm@freebsd.org Mon Jan 23 16:08:17 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 5A06BCBEA9C for ; Mon, 23 Jan 2017 16:08:17 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 452F19E8 for ; Mon, 23 Jan 2017 16:08:16 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 719D730FD8; Mon, 23 Jan 2017 09:08:15 -0700 (MST) Date: Mon, 23 Jan 2017 09:08:15 -0700 From: Brad Davis To: jungle boogie Cc: freebsd-arm@freebsd.org Subject: Re: arm board purchase for 2017 Message-ID: <20170123160815.GO70816@corpmail.liquidneon.com> References: <16d6ab8d-94fb-38d3-e8ad-1b1daa591355@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16d6ab8d-94fb-38d3-e8ad-1b1daa591355@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 23 Jan 2017 16:08:17 -0000 On Sun, Jan 22, 2017 at 11:38:54PM -0800, jungle boogie wrote: > Hi All, > > I'd like to purchase a SoC arm system and run FreeBSD on it and possibly > openbsd, if it's supported. My go to purchase I was thinking of was a > raspberry pi3 because of the great support coming along with it in FreeBSD. > > At the moment I don't plan on doing any hardware hacking, mostly > software stuff like seeing how freeswitch would run/build on freebsd > ARM, postgres building, possibly tinc and dn42 VPN stuff, etc. > > Is the raspberry pi the preferred board for software hacking, or is > there something a bit better but still under $100US that's preferred? > > Contenders I'm aware of: > banana pi > cubieboard > odroid > pandaboard > parallela > raspberry pi > > I own a beaglebone black right now and it runs -current. I also own a > pine64, which is running Debian. I haven't yet tried out freeBSD on it. > I know (and thankful for) Brad makes images for it. Does anyone know how > it's performing? I have not run Debian on a Pine64, so I have no idea how it runs, but I am very happy with the FreeBSD performance on it. The only downside currently is the lack of HDMI support. Regards, Brad Davis From owner-freebsd-arm@freebsd.org Mon Jan 23 17:36:32 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 11DA1CBE87A for ; Mon, 23 Jan 2017 17:36:32 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 CE1531BC0 for ; Mon, 23 Jan 2017 17:36:31 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id v96so52351901ioi.0 for ; Mon, 23 Jan 2017 09:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=0ZFIuSPHlT7GKJ+BkLKvV/wwl+GyihA1VLp+I0Q76CU=; b=YDJKKbElbm3RvUpUsV9JKKx586ZyC+KnLwlvmxgvZk+HenlkXDOgYfm9LsuT5sWhg0 s10no7qIUjo8+7m3NLwiIo88GYBQoM5GYEwZ6W7a0JpUCVoR8FLxpCMBrwZ6wMpO1+ar q+ZTjs6TfLqVQThe1QQ6murXHdJHAtDBeQho5feylD6iAOVjSlh0Dp/E1VJULar5weni Ty0Ga81FyM8Bu48pdzy1APXlBWhm3GaooWK8VdK/xPpWoizyOFw1sAR+h4nUUdD+nG70 q9DzzwI/OXDLwuhoW/Yq9JvU3ZSG/5/R/YkA1xgS+dGz4wc2ZEYm4cqr9QZ7zoTc2nzu OCVw== 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=0ZFIuSPHlT7GKJ+BkLKvV/wwl+GyihA1VLp+I0Q76CU=; b=p81rpKa+tCk5w3dynYf9Lx5D0WEyAlCvn2x5wlbCwVueOWWqGBYV8wwRk6h4PVwPmT W0e9KpeNWo+UpCMl+xeL38pAjLIOSHjyeEGrkNzZuGhXKVM3Mql/JXO+G5l/tfMrIznT sUcnZayHpnE32FhemG28TtBzBeSlOm74i2y8cwzUutH5BVu90Rbga5LVnAoOhjrn+9d5 Q2gGE49LGMJJhNBnWidqGP4URIOA7Uav8p8at6aLZSZhmg/Eflj6PJU7i5ZHEsOunTMA 2sJx3zh2gblSXIpwe/tcIyi7kCBsP/I31YPqmGhPfJsFqJgE1Gjh2h17arkrnbuX0veh ihFw== X-Gm-Message-State: AIkVDXIWSsdNIp+OnGsliQq6YwFoLyQrhuEDA5V1CB8LuIuHo2i0mVSz27cj99wLyQy6c41fCmtqaBovgstICw== X-Received: by 10.107.18.12 with SMTP id a12mr29199933ioj.155.1485192991133; Mon, 23 Jan 2017 09:36:31 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.175.159 with HTTP; Mon, 23 Jan 2017 09:36:10 -0800 (PST) In-Reply-To: <06672183-F0A6-47C9-AC53-091515CBEBC3@obsigna.com> References: <3DA2368D-AE7B-4D69-A634-2861D2EFA9AE@obsigna.com> <8FDE5FCC-9BA8-4601-A32E-04FBAB5FFBEA@obsigna.com> <0ee18ae6-7588-97c9-bc04-3ad83b0c33b3@freebsd.org> <34EB351A-3BA9-4D38-AF1C-96B065564C42@obsigna.com> <06672183-F0A6-47C9-AC53-091515CBEBC3@obsigna.com> From: Ed Maste Date: Mon, 23 Jan 2017 12:36:10 -0500 X-Google-Sender-Auth: OzJfx2mJABdHQL1DcZ3MmDgDHwM Message-ID: Subject: Re: lldb on BeagleBone Black To: "Dr. Rolf Jansen" Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 23 Jan 2017 17:36:32 -0000 On 16 January 2017 at 09:20, Dr. Rolf Jansen wrote: > > Building and installation of devel/llvm37 from the ports went well withou= t problems, however, lldb37 is only of minor usefulness since stepping-into= /over lines of code does not work. I can set breakpoint, and execution stop= s fine on breakpoints, however, when I hit 'n' or 's', the program simply c= ontinues execution in a normal fashion until end. Yes. Single-stepping on ARM requires special support in the debugger, which does not yet exist in LLDB for FreeBSD. The good news is that there is a patch in review to add this support. I'm hoping to review, test and commit it this week to the upstream LLDB repository, and I'll see about merging it into the LLDB in the FreeBSD base system from there. -Ed From owner-freebsd-arm@freebsd.org Mon Jan 23 18:45: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 3B4AFCBE194 for ; Mon, 23 Jan 2017 18:45:46 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 992792EB; Mon, 23 Jan 2017 18:45:45 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1485197141; l=1392; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=9iMw1hoOQFxODxl0OhFaxZZ6b0/PmH0ewQ2zWipNv1M=; b=ymIdsR/c5p3l4ccGmeg5X+7nrFASx5XYSlMhuZvh0VtCcl4qSj7JJSwWfwJ20hT0/J Mhhr3Dm/YFDiHSzMH6MikfyEE5OU6B//dyGdCFch/Vvx5K20RT3T538qeZI5xR6H5tmy LKMT0jUmim81QSmppDaplNu3uAzQdEawkbFzc= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 39.11 DYNA|AUTH) with ESMTPSA id R0968at0NIje62v (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 23 Jan 2017 19:45:40 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 370DE7506D97; Mon, 23 Jan 2017 16:45:37 -0200 (BRST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: lldb on BeagleBone Black From: "Dr. Rolf Jansen" In-Reply-To: Date: Mon, 23 Jan 2017 16:45:35 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28AA6259-BCB6-4527-B292-81531D758F8E@obsigna.com> References: <3DA2368D-AE7B-4D69-A634-2861D2EFA9AE@obsigna.com> <8FDE5FCC-9BA8-4601-A32E-04FBAB5FFBEA@obsigna.com> <0ee18ae6-7588-97c9-bc04-3ad83b0c33b3@freebsd.org> <34EB351A-3BA9-4D38-AF1C-96B065564C42@obsigna.com> <06672183-F0A6-47C9-AC53-091515CBEBC3@obsigna.com> To: "freebsd-arm@freebsd.org" 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, 23 Jan 2017 18:45:46 -0000 > Am 23.01.2017 um 15:36 schrieb Ed Maste : >=20 > On 16 January 2017 at 09:20, Dr. Rolf Jansen wrote: >>=20 >> Building and installation of devel/llvm37 from the ports went well = without problems, however, lldb37 is only of minor usefulness since = stepping-into/over lines of code does not work. I can set breakpoint, = and execution stops fine on breakpoints, however, when I hit 'n' or 's', = the program simply continues execution in a normal fashion until end. >=20 > Yes. Single-stepping on ARM requires special support in the debugger, > which does not yet exist in LLDB for FreeBSD. The good news is that > there is a patch in review to add this support. I'm hoping to review, > test and commit it this week to the upstream LLDB repository, and I'll > see about merging it into the LLDB in the FreeBSD base system from > there. >=20 > -Ed In the moment, I am building/installing LLDB from the SVN-trunk (r292723 = -- 5.0.0 branch) on my BeagleBone Black. Installation is in progress = now, and I guess in a 2 or 3 hours this will be finished. Please let me know, once the patch made it into the SVN repository. Then = I will run 'svn update' and 'ninja lldb install' once again, and I hope = that ninja is smart enough to compile only the changes. Thank you very much for looking into it. Best regards Rolf= From owner-freebsd-arm@freebsd.org Mon Jan 23 20:18:16 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 3F171CBEC09 for ; Mon, 23 Jan 2017 20:18:16 +0000 (UTC) (envelope-from dmarquess@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 F39CFA0 for ; Mon, 23 Jan 2017 20:18:15 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-yw0-x22d.google.com with SMTP id v200so147385656ywc.3 for ; Mon, 23 Jan 2017 12:18:15 -0800 (PST) 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=UX3xz0ZvQvTH8FiZh61/xR33dmEeOrcoAonpCygN9vg=; b=hP6JE2qz4AFGNfIyCNXd6Y2GRMBJrqiHXhc+L4kA+SRpl6zKZyrWeU+A7kzK+uNOfU g7JJoTRfIkTM0W7KcpN7iyxnl59ZRWqzGkWSEqhsv9sBt8UWfyHCdSrKy0t2n6WJLC4M Zi1VxhzGR41DmdMh1DGtV1OjXLAJHrDvgsklyPwoL4w5/Vy70/W9Cm8G/20BlydU2Onv nyjLGljdR1NmQqQnhBXrNbIc3Flp6TZkXv/PkNFfLcL3FzuyVUaP3H1OeF/TuyxnVAje SEQUfFppTjRKlO5cBLZ9YyJxtQVGZYvaai5046tQ1FLNtT1NO2HcUnLhW4493qL7ycli V/Mg== 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=UX3xz0ZvQvTH8FiZh61/xR33dmEeOrcoAonpCygN9vg=; b=MM1RND9WP/kqSWgcarQznTgx1Jz/JA6Vfr8Pfjjwp7+AiqTAebCDUPtXQu+dGfG0Xp 49b9C5k2IF9rsbHbRZRwNgQRjETqWIfEN7A4sKS+8MyO7ZmTBLhe6JKafDxVngNfEpty jZWbVvEz9CJipIzpjHgfB/AkFRNNh1SLu68ertpWeTtxpaXTO9sjosme6JDywGHbXJDJ PgA1GlL0G4u1euwSZOkvmycYbqaGJffNBGls6Ef/HadjfzZQlmQ8Yo/EBHXuLBAKqaGr odXSiG5oUvX18/8CNwGdA/ESQ8zDN3MBNUqxRrsXzG6nznFNU1R598UHmM1+jK/ZAHDN 4MNw== X-Gm-Message-State: AIkVDXJfTFy7YUDmz9NEnwe06KA2RLG2CUe1//nCZuVav1OFfP9Qj1s19rmS25/M4J52IXO4c73KjboZpBAl7A== X-Received: by 10.129.52.6 with SMTP id b6mr23174063ywa.113.1485202695210; Mon, 23 Jan 2017 12:18:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.231.135 with HTTP; Mon, 23 Jan 2017 12:18:14 -0800 (PST) In-Reply-To: References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> <20170122190659.GA62786@bluezbox.com> From: Dustin Marquess Date: Mon, 23 Jan 2017 14:18:14 -0600 Message-ID: Subject: Re: Getting the kernel to let go of my UART! To: Oleksandr Tymoshenko Cc: Hans Petter Selasky , "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, 23 Jan 2017 20:18:16 -0000 Okay, maybe the console thing was a red herring then. It's not marking it as a console at all anymore, but something is still locking the baud rate to 115200. Even though stty and minicom are both set to 9600, anything set/received at 9600 doesn't work/is garbled. If I set it to 115200, it works fine. I had wrongly assumed it was because of it marking it as a console (since the console line in dmesg said 115200). Device map? enable_uart=1 aka core_freq= maybe? I'll try tinkering.. -Dustin On Mon, Jan 23, 2017 at 12:24 AM, Dustin Marquess wrote: > On Sun, Jan 22, 2017 at 1:06 PM, Oleksandr Tymoshenko > wrote: >> Dustin Marquess (dmarquess@gmail.com) wrote: >>> On Sunday, January 22, 2017, Hans Petter Selasky wrote: >>> >>> > On 01/22/17 06:07, Dustin Marquess wrote: >>> > >>> >> [Sorry if this is somewhat of a dupe, I have yet to find a solution] >>> >> >>> >> I've been running FreeBSD on my Pi 3s for a little over a month now, >>> >> first using gonzo's SMP code + a home cross-compiled kernel, and then >>> >> I moved to the HardenedBSD images. All of them work great except one >>> >> issue that's driving me nuts... >>> >> >>> >> The downside to the Pi 3 vs some other boards is that there's really >>> >> only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with >>> >> a GPS board. >>> >> >>> >> 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and >>> >> that's "fixed". >>> >> >>> >> 2nd issue: Even with a USB keyboard attached and HDMI output >>> >> connected, FreeBSD still wants to steal the first uart (ttyu0) as a >>> >> console port. I thought that would be fine as long as I use "-m -n >>> >> -q" in the boot config to disable kernel output and then "conscontrol >>> >> delete ttyu0". Well, that KIND of works. It seems to work fine when >>> >> using 115200bps, but trying to change the baud rate to match the GPS >>> >> unit doesn't seem to work at all, I'm guessing because it's still set >>> >> as an available console? >>> >> >>> >> hint.uart.0.flags="0x0" doesn't work, as it still marks it as a >>> >> console. console="efi" seems to be the only setting that works, >>> >> "vidconsole" and "nullconsole" both don't work. >>> >> >>> >> Is there a way to stop the kernel from trying to claim the UART as a >>> >> console? >>> >> >>> > >>> > I think so, have a look in /etc/ttys and comment out the ttyu0 line. >>> > >>> > Sadly, I already did that. There's no getty running, but dmesg still shows >>> the kernel marking it as a console. >> >> Just a random idea, try adding hw.fdt.console=foo0 to /boot/loader.conf >> This should force uart_cpu_fdt_probe to fail. > > Wow, I think that actually did the trick! > > Thank you so very much, I've been pulling my hair out of this for > probably 2 weeks now! > > -Dustin From owner-freebsd-arm@freebsd.org Mon Jan 23 20:35: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 2725BCBE099 for ; Mon, 23 Jan 2017 20:35:44 +0000 (UTC) (envelope-from hagen@nornagest.de) Received: from euve10633.vserver.de (euve10633.vserver.de [62.75.145.58]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6B89D75 for ; Mon, 23 Jan 2017 20:35:43 +0000 (UTC) (envelope-from hagen@nornagest.de) Received: from [185.44.151.110] (helo=kvoth.localdomain) by euve10633.vserver.de with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1cVkyI-0000e6-Am; Mon, 23 Jan 2017 21:12:25 +0100 Date: Mon, 23 Jan 2017 21:12:01 +0100 From: Hagen =?UTF-8?B?S8O8aGw=?= To: Jim Thompson Cc: "freebsd-arm@freebsd.org" Message-ID: <20170123211201.58eb947e@kvoth.localdomain> In-Reply-To: References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> Organization: Scientia est potentia! X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 185.44.151.110 X-SA-Exim-Mail-From: hagen@nornagest.de X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on euve10633.vserver.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham version=3.3.1 Subject: Re: Durable/serious arm hardware ? X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000) X-SA-Exim-Scanned: Yes (on euve10633.vserver.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, 23 Jan 2017 20:35:44 -0000 On Mon, 23 Jan 2017 01:07:37 -0600 Jim Thompson wrote: > We have a little two port router based on the same SoC as the BBB. I > selected that platform as one of the better supported platforms on > FreeBSD. It still took a lot of (months of) work to make the freebsd > (and subsequently pfSense) for it into something that could be a > "product". All the FreeBSD work is in the tree. Most vendors don't > do that. That's not a humble brag, it's a statement of truth. > > We're currently in discussions with a vendor to get the Ethernet > driver for our next ARM product, since, ..., it's not in the tree. It's great that you're doing this work, especially committing it back into the tree. What I would also be interested in, is a solution for an ARM based wireless access point running FreeBSD. Right now I have one of my Raspberry Pis set up to do it, but the wireless performance leaves something to be desired. Do you have any tips on what to use for that? > The SoC vendors all have Linux on the brain. They see a much larger > market there. Convincing them to dedicate resources to FreeBSD can be > challenging. One of the things we've been able to do with pfSense is > to show real volume for a FreeBSD based application. I can go to a > SoC vendor (TI, Marvell, etc) and talk about committing to, say, N x > 10K+ unit volumes. That tends to help get their attention. The > Foundation helps a lot here, too, which is why I won't take > "donations" for pfsense and instead direct people to donate to the > FreeBSD Foundation. > > In closing, the board you name are all "developer / hobbyist" boards, > and may not have the level of engineering in them that it takes to > make into a product. At least two of them are price-supported, where > a non-profit gets some portion of the BoM discounted, which makes for > a very low-price board, but also brings some short-cutting (try to > get a warranty claim on a BBB or RPi). > > Jim From owner-freebsd-arm@freebsd.org Mon Jan 23 20:42: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 006A4CBE22C for ; Mon, 23 Jan 2017 20:42:14 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 D27B2682 for ; Mon, 23 Jan 2017 20:42:13 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cVlRH-000JDs-Bq; Mon, 23 Jan 2017 12:42:08 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0NKg63p073895; Mon, 23 Jan 2017 12:42:06 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 23 Jan 2017 12:42:06 -0800 From: Oleksandr Tymoshenko To: Dustin Marquess Cc: Hans Petter Selasky , "freebsd-arm@freebsd.org" Subject: Re: Getting the kernel to let go of my UART! Message-ID: <20170123204206.GA73799@bluezbox.com> References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> <20170122190659.GA62786@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Dustin Marquess (dmarquess@gmail.com) wrote: > Okay, maybe the console thing was a red herring then. > > It's not marking it as a console at all anymore, but something is > still locking the baud rate to 115200. Even though stty and minicom > are both set to 9600, anything set/received at 9600 doesn't work/is > garbled. If I set it to 115200, it works fine. I had wrongly assumed > it was because of it marking it as a console (since the console line > in dmesg said 115200). > > Device map? enable_uart=1 aka core_freq= maybe? I'll try tinkering.. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: elinux.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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, 23 Jan 2017 20:42:14 -0000 Dustin Marquess (dmarquess@gmail.com) wrote: > Okay, maybe the console thing was a red herring then. > > It's not marking it as a console at all anymore, but something is > still locking the baud rate to 115200. Even though stty and minicom > are both set to 9600, anything set/received at 9600 doesn't work/is > garbled. If I set it to 115200, it works fine. I had wrongly assumed > it was because of it marking it as a console (since the console line > in dmesg said 115200). > > Device map? enable_uart=1 aka core_freq= maybe? I'll try tinkering.. It might be a problem with the driver itself. From a quick glance, PL011 driver sets baudrate only if it has reference clock frequency which doesn't seem to be the case for RPi. If reference clock frequency is unknown divider register is left untouched. According to this document: http://elinux.org/RPiconfig you can set initial baudrate in config.txt using init_uart_baud variable -- gonzo From owner-freebsd-arm@freebsd.org Mon Jan 23 20:44: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 2E46ACBE47D for ; Mon, 23 Jan 2017 20:44:05 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 07EF595C for ; Mon, 23 Jan 2017 20:44:04 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cVlT6-000JEg-Je; Mon, 23 Jan 2017 12:44:04 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0NKi08b073945; Mon, 23 Jan 2017 12:44:00 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 23 Jan 2017 12:44:00 -0800 From: Oleksandr Tymoshenko To: Dustin Marquess Cc: "freebsd-arm@freebsd.org" Subject: Re: Getting the kernel to let go of my UART! Message-ID: <20170123204400.GA73924@bluezbox.com> References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> <20170122190659.GA62786@bluezbox.com> <20170123204206.GA73799@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170123204206.GA73799@bluezbox.com> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: > Dustin Marquess (dmarquess@gmail.com) wrote: > > Okay, maybe the console thing was a red herring then. > > > > It's not marking it as a console at all anymore, but something is > > still locking the baud rate to 115200. Even though stty and minicom > > are both set to 9600, anything set/received at 9600 doesn't work/is > > garbled. If I set it to 115200, it works fine. I had wrongly assumed > > it was because of it marking it as a console (since the console line > > in dmesg said 115200). > > > > Device map? enable_uart=1 aka core_freq= maybe? I'll try tinkering.. > > It might be a problem with the driver itself. From a quick glance, > PL011 driver sets baudrate only if it has reference clock frequency > which doesn't seem to be the case for RPi. If reference clock > frequency is unknown divider register is left untouched. > > According to this document: http://elinux.org/RPiconfig you can > set initial baudrate in config.txt using init_uart_baud variable [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: elinux.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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, 23 Jan 2017 20:44:05 -0000 Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: > Dustin Marquess (dmarquess@gmail.com) wrote: > > Okay, maybe the console thing was a red herring then. > > > > It's not marking it as a console at all anymore, but something is > > still locking the baud rate to 115200. Even though stty and minicom > > are both set to 9600, anything set/received at 9600 doesn't work/is > > garbled. If I set it to 115200, it works fine. I had wrongly assumed > > it was because of it marking it as a console (since the console line > > in dmesg said 115200). > > > > Device map? enable_uart=1 aka core_freq= maybe? I'll try tinkering.. > > It might be a problem with the driver itself. From a quick glance, > PL011 driver sets baudrate only if it has reference clock frequency > which doesn't seem to be the case for RPi. If reference clock > frequency is unknown divider register is left untouched. > > According to this document: http://elinux.org/RPiconfig you can > set initial baudrate in config.txt using init_uart_baud variable Also if you use u-boot divider register can be overridden by U-Boot intialization routine. -- gonzo From owner-freebsd-arm@freebsd.org Mon Jan 23 20:53:17 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 6D1E4CBE9BD for ; Mon, 23 Jan 2017 20:53:17 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A497F92 for ; Mon, 23 Jan 2017 20:53:17 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-yw0-x232.google.com with SMTP id v200so148115277ywc.3 for ; Mon, 23 Jan 2017 12:53:17 -0800 (PST) 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=SPpQEj6s4+/DZ8gwRc0zEEAgQSVlDz+mvL+9ZSKQ82A=; b=Bp5rOo6kgeGv1/qpjTn3kSIO8e4nYsdrSri6tx5Ytt0ZutT+5DhYNoe9F9SYMRNiRO j4Ta/LxqerHC8aG8w8ZIBVdiNQuvFYTdCK/3KDCWOQvEeDc4lPXKqf77cziWCqGI4jMh XQXDi3G5puXMR9MS1s32/xEL6oN610zhtoNjCW6wVoJuddY1GQlp/00dMLyWHlByg1Ee Dl2bxRNmhIUBkgsrF6covvdqYOf+TJ5RMqsVrQBVoENPSp6zZRbsByQRJcWH3rqdSWon KC8Zh/PzmfaVb8QZn+mDbZ1SdHNf8K6sGXfiVCb19b+o5uq0HgyTZvh/Hddh9EkixWWY /0Qw== 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=SPpQEj6s4+/DZ8gwRc0zEEAgQSVlDz+mvL+9ZSKQ82A=; b=Hg8FK0fuLF24Q8/N+jY0HC4g678GoSV0KElMCJZ3hE2XlfS27mNH1aFTR0Z5ONsDuz CYznoXBxPFU/YLg8L9Isy/Q2Be366YkGxG1fPifIfAvEdUT6RXbc9QUrqLygZC2KBu8z 1Nr8KRiK617iPsilSJJqtbOE5pRR4/4uhC46Q1VVRG//pPoSNaLsJs3Z0T/v8kjcCVFw hdY48eiD0GbKorM/wxnbQlGedBWSsZ9aiX0Iu38YLiSJwovBK0JoCthUWMvzooC9n8K2 8bum+umxmx/UgJG74zLcME23b8UyXhNfbn4/aMekzIGmNLaaVha0luZt7ItJerwQfjEL 558A== X-Gm-Message-State: AIkVDXKYGa5oNP7Bpd612AnE4M8dQgXEXj2q+BSMhIHWwNyMgJsKBfARNvUz5BIcTHebxoUdcHvUn9qa8k53JA== X-Received: by 10.129.141.68 with SMTP id w4mr23395652ywj.269.1485204796379; Mon, 23 Jan 2017 12:53:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.231.135 with HTTP; Mon, 23 Jan 2017 12:53:15 -0800 (PST) In-Reply-To: <20170123204400.GA73924@bluezbox.com> References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> <20170122190659.GA62786@bluezbox.com> <20170123204206.GA73799@bluezbox.com> <20170123204400.GA73924@bluezbox.com> From: Dustin Marquess Date: Mon, 23 Jan 2017 14:53:15 -0600 Message-ID: Subject: Re: Getting the kernel to let go of my UART! To: Oleksandr Tymoshenko 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, 23 Jan 2017 20:53:17 -0000 On Mon, Jan 23, 2017 at 2:44 PM, Oleksandr Tymoshenko wrote: > Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: >> Dustin Marquess (dmarquess@gmail.com) wrote: >> > Okay, maybe the console thing was a red herring then. >> > >> > It's not marking it as a console at all anymore, but something is >> > still locking the baud rate to 115200. Even though stty and minicom >> > are both set to 9600, anything set/received at 9600 doesn't work/is >> > garbled. If I set it to 115200, it works fine. I had wrongly assumed >> > it was because of it marking it as a console (since the console line >> > in dmesg said 115200). >> > >> > Device map? enable_uart=1 aka core_freq= maybe? I'll try tinkering.. >> >> It might be a problem with the driver itself. From a quick glance, >> PL011 driver sets baudrate only if it has reference clock frequency >> which doesn't seem to be the case for RPi. If reference clock >> frequency is unknown divider register is left untouched. >> >> According to this document: http://elinux.org/RPiconfig you can >> set initial baudrate in config.txt using init_uart_baud variable > > Also if you use u-boot divider register can be overridden by U-Boot > intialization routine. Okay, you're completely amazing and I definitely owe you some alcoholic drinks! init_uart_baud=9600 did the trick completely. I had completely removed #define CONFIG_BCM283X_MU_SERIAL & #define CONFIG_PL01X_SERIAL in U-boot to keep it from even touching the UART, and for good measure I even commented-out the "puts("\r\nRPi3 PSCI monitor installed\r\n");" in your PSCI monitor code (which probably wasn't needed, but I wanted to keep the GPS module happy).. and sure enough, after adding that config.txt setting, it works like a charm! Thanks again! -Dustin From owner-freebsd-arm@freebsd.org Mon Jan 23 20:57: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 6D9AECBEA27 for ; Mon, 23 Jan 2017 20:57:57 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EAC329C for ; Mon, 23 Jan 2017 20:57:57 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-io0-x231.google.com with SMTP id j18so120007933ioe.2 for ; Mon, 23 Jan 2017 12:57:57 -0800 (PST) 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:content-transfer-encoding; bh=1/Db91hW4alFEHcao1LTUSKah2j0O+aL1JSemU0ahng=; b=OsL1uoC2DqkrRjohNQVI4w556I9ca1e1rG1zjOzFWgS5yNu0GxsqpGvdwQUCQ0mAqc txOjazMCyegtfN8Bjx3en+tljiliNo+Vw4HYTv3PFhjpqHnshDyNv9kwi7m2XAjs1gUG q625IJChPW5i+XJ1HWn7nurxeP7pSDiyfltks= 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:content-transfer-encoding; bh=1/Db91hW4alFEHcao1LTUSKah2j0O+aL1JSemU0ahng=; b=FAvxA3NEYRPc5pSS/ltJOBA4a3B9xB5s2j7kOfSmMHB/lUd5yIaUFZzc5lAL9L8Fjr bRXAcRwahtlxaPyBNI5mI0NZHBnZcL1n7erB5drs7314tNMHbZapTijlUnD6rDeXBoLN M15Fzr9WcfPXyzTs7rbCptJm5Yn5jY6rgb98vGMIJ06iwtn7tCbfAANwSvCnbAIUFKbP d7aHl57VAQxSKsZfAx8rGEEhyuEj2Tof5q9pr//v7nQ7Ua5kS3MrVy0Wmiu0gnp4yMcY cKCpJsxdH3uD1MKBUKcRxwKDu3bXOemGkfwglfF3ISOa6M9gc1S6hEthTKH5QKB+Ewui opqg== X-Gm-Message-State: AIkVDXKyP+7eNebbZ2i6BROOc9+f+XBsulwtm0NfhTcX9qGomaMCbFIfoGYyL0q8yOckBd4cnRl++luvwSGjOVxj X-Received: by 10.107.53.13 with SMTP id c13mr26841507ioa.55.1485205076614; Mon, 23 Jan 2017 12:57:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.132.65 with HTTP; Mon, 23 Jan 2017 12:57:56 -0800 (PST) In-Reply-To: <20170123211201.58eb947e@kvoth.localdomain> References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <20170123211201.58eb947e@kvoth.localdomain> From: Jim Thompson Date: Mon, 23 Jan 2017 14:57:56 -0600 Message-ID: Subject: Re: Durable/serious arm hardware ? To: =?UTF-8?Q?Hagen_K=C3=BChl?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 23 Jan 2017 20:57:57 -0000 On Mon, Jan 23, 2017 at 2:12 PM, Hagen K=C3=BChl wrote= : > On Mon, 23 Jan 2017 01:07:37 -0600 > Do you have any tips on what to use for that? This isn't -vendors. Think: summer. From owner-freebsd-arm@freebsd.org Tue Jan 24 02:03:42 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 E01AACBED45 for ; Tue, 24 Jan 2017 02:03:42 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 A63A6A14 for ; Tue, 24 Jan 2017 02:03:42 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x22e.google.com with SMTP id x49so156810947qtc.2 for ; Mon, 23 Jan 2017 18:03:42 -0800 (PST) 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=1W3x+oyp9iGRobA6Wu1FOG1pQrtuj3MeKfaSKlnaRZE=; b=QO+WI/jwsb6RQh55dmEEmXHguD6mD3JBOSRzPOVG8XV909CYiFwEhaakiaMWxgtQye UO/qwGpGHrYvLZIqz75G/NxFBbWDuU+FqfS859DqRVVjuXP+V6bPEaRAVAW8guMt+dMc vRO1R/nK+IHnnv9tNlzXLr/11V4gTBxN2zCZE= 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=1W3x+oyp9iGRobA6Wu1FOG1pQrtuj3MeKfaSKlnaRZE=; b=IMPFABSSlWsx5UPw6PH2e8fhboExu2hVCq4ZzCh1Bcx/n0OrgpqCKOUy0WAbDXf+F2 MIY9ygtDTbY+KzIBIEScPt+t7fu5ncUtrB0Y7GGIwGFM+QgSerSKllBbHWLzaM8XyEAA iOETuu//CQsFTEWsFpNtkIUuGzb2fRVMnuzgoSZYA5R9znssPEkf6mnU1HpCK0vqlcQB AJ45PIoPlG+GpxmC6I38QXhpPS/ThTyLd/bsJTWzCTd+EkPpbkEorzF9fJ0GE8IRFByl vimu/wQTuRsRJomRkldiyI1B9gL5HMu5wbDL6gRzCc4NpjsgbgxYJMUdOlIIYJ3xHyAZ q/8g== X-Gm-Message-State: AIkVDXIlbMO2BN1zTqqNzYVOniouMqk391G/z5gbwqGniy0tRwvOPRI+gxqmuGzMhp98XQ== X-Received: by 10.55.168.137 with SMTP id r131mr27294966qke.177.1485223421231; Mon, 23 Jan 2017 18:03:41 -0800 (PST) Received: from [192.168.0.11] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id t67sm14763049qkd.41.2017.01.23.18.03.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 18:03:40 -0800 (PST) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: FreeBSD 12 r312227 dont boots on Beaglebone black Message-ID: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> Date: Mon, 23 Jan 2017 23:03:34 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.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: Tue, 24 Jan 2017 02:03:43 -0000 Dears I'm trying boot a FreeBSD12-armv6-r312227 (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I downloaded from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ works fine, but when I try boot the image that I build on my machine using crouchet I get: U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) Trying to boot from MMC1MMC partition switch failed *** Warning - MMC partition switch failed, using default environment reading u-boot.img reading u-boot.img And boot stops. Someone can confirm that the revision 312227 is working fine? Thanks a lot! From owner-freebsd-arm@freebsd.org Tue Jan 24 03:43: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 8A465CBF9C3 for ; Tue, 24 Jan 2017 03:43:39 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::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 1B7ECAD5 for ; Tue, 24 Jan 2017 03:43:39 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id d140so31430758wmd.2 for ; Mon, 23 Jan 2017 19:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:reply-to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=cOUs8MlM0ieZFEs1cJmEAQWaCf9sC51g1E74Z98LMVQ=; b=Z0psUQ+a2SAVXtHa0pqi8wvLalIbVHSeXsZBI2QOzn7UDepED7Jq8iGjeDHfEgBZJa VdIRlhwZ1mf1qWEKkSyt8EASLLyR1BB3Vg2u4JnKc3yKpbr27Ww3l5hATh0SBmNoWlNU s5caMItr75diYL7JFQf0MRKszzxcXIZNujhtxY/T+9FKtFqh24MWZf9j4Ux6B3rjRqDT qcS+xGiPhaiJD54Af9f6fTJF+xNAJXiqha5n38NxKux8oaBzsF47bcdq7cDdxwURc0+a IwMgltHLfe9kFLwbG397ZPvdSaVxfQkvivbUOSpi/A/2iw2rfO8zV13Wf+BYPVv2oi1H 71+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:reply-to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cOUs8MlM0ieZFEs1cJmEAQWaCf9sC51g1E74Z98LMVQ=; b=DgwDyydEH8tPYEoWfCtXjYpgeykcndx4nqjdob3vv+R2kUMq0fWFyX7NqWn9eG/of+ VnyvfEFH27Jte/gzTpP+jwlw1i7q/pXLpTGYOWS9UPLpLMKOHcWaLFyWK7IFRgrCtNu0 VusYc4jJA3l8F81kWG9CVTSayxrWqeT4n3CoR8YyZGX9y1fU8cfdMBXvLSXqxpBCkSaI RRU0zeRgNeht+n6JEwHluwd8k/fSGBysn7o0sDWj6jw9K/S/aYTALaDc8a1KUqw0YsBS j6sSTMBz4gKLO+tmta+6mc0Sy59DfPNERQN+WJ/JmwBBHZpsMlUi7vBagbjKkmyVS4yt hijg== X-Gm-Message-State: AIkVDXLXD5vAVkf2vkFtbxKprBYcP/rAEJig3g75OK378ArpCrfV13H8pkWBcAlY4y7B0Q== X-Received: by 10.223.129.196 with SMTP id 62mr28958714wra.43.1485229417327; Mon, 23 Jan 2017 19:43:37 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id z134sm23972202wmc.20.2017.01.23.19.43.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 19:43:36 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Subject: Re: lldb on BeagleBone Black References: <3DA2368D-AE7B-4D69-A634-2861D2EFA9AE@obsigna.com> <8FDE5FCC-9BA8-4601-A32E-04FBAB5FFBEA@obsigna.com> <0ee18ae6-7588-97c9-bc04-3ad83b0c33b3@freebsd.org> <34EB351A-3BA9-4D38-AF1C-96B065564C42@obsigna.com> <06672183-F0A6-47C9-AC53-091515CBEBC3@obsigna.com> To: freebsd-arm@freebsd.org Reply-To: mmel@freebsd.org Message-ID: <82b64b54-d9cc-8cb6-6b6d-8817f1fbb4cc@freebsd.org> Date: Tue, 24 Jan 2017 04:43:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 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, 24 Jan 2017 03:43:39 -0000 On 23.01.2017 18:36, Ed Maste wrote: > On 16 January 2017 at 09:20, Dr. Rolf Jansen wrote: >> >> Building and installation of devel/llvm37 from the ports went well without problems, however, lldb37 is only of minor usefulness since stepping-into/over lines of code does not work. I can set breakpoint, and execution stops fine on breakpoints, however, when I hit 'n' or 's', the program simply continues execution in a normal fashion until end. > > Yes. Single-stepping on ARM requires special support in the debugger, > which does not yet exist in LLDB for FreeBSD. The good news is that > there is a patch in review to add this support. I'm hoping to review, > test and commit it this week to the upstream LLDB repository, and I'll > see about merging it into the LLDB in the FreeBSD base system from > there. > > -Ed There are more problems with LLDB. 1) Full LLVM suite, newer that 37, cannot be linked. The resultant size of shared library is bigger that 32MB, and our very old linker doesn't implements big jump/call stubs. For now, cmake .. -DLLVM_TARGETS_TO_BUILD="ARM" works but I think that this is also very close to 32MB limit. 2) LLDB uses UDF instruction as breakpoint, but FreeBSD kernel expects BKPT (see g_arm_breakpoint_opcode in ProcessFreeBSD.cpp). That's why you get invalid opcode for single step (and/or breakpoint). My quick attempt to replace this with right BKPT opcode also failed, and I think that this code also have problem with endianes. Unfortunately, I have no free time for this Michal From owner-freebsd-arm@freebsd.org Tue Jan 24 19:21:31 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 BB4E7CBFC9D for ; Tue, 24 Jan 2017 19:21:31 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 5805F18F0 for ; Tue, 24 Jan 2017 19:21:31 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-144.nat-2.net.cam.ac.uk [131.111.5.144]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 49D5CD8561; Tue, 24 Jan 2017 19:09:26 +0000 (UTC) Date: Tue, 24 Jan 2017 19:13:57 +0000 From: Andrew Turner To: Tom Vijlbrief Cc: Mark Millard , freebsd-arm Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Message-ID: <20170124191357.0ec0abfd@zapp> In-Reply-To: References: X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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, 24 Jan 2017 19:21:31 -0000 Can you try with r312703 and without the malloc.conf change? I think the issue was because errno was stored just before some internal jemalloc state in the bss and there was a bug where the setting of errno where it would overwrite 32 bits of this state. Andrew On Fri, 20 Jan 2017 08:39:15 +0000 Tom Vijlbrief wrote: > I'm using the image from > > http://www.raspbsd.org/pine64.html (thanks Brad) > > After applying the jemalloc work around at the bottom of: > > https://wiki.freebsd.org/arm64/rpi3 > > and the dynamic linker fix: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214971 > > I could build most ports but not world because it does not use the > /etc/malloc.conf setting. > > Using: > > MALLOC_CONF=tcache:false script bw.log make buildworld NO_CLEAN=YES > -j2 > > I can do a build world but what is more interesting is that without > the MALLOC_CONF setting I get a lot of: > > gic0: Spurious interrupt detected: last irq: 27 on CPU3 > > These errors disappear when disabling tcache. > > The jemalloc tcache allocates on the stack so this hints at a bad > interaction between the interrupt stack frames and the application > stack. > > Op 17:35 ZO 2 Okt 2016 schreef Mark Millard : > > [Adding a clarification.] > > On 2016-Oct-2, at 8:20 AM, Mark Millard wrote: > > > Thanks for the notes. > > > > On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief > ]gmail.com> > wrote: > >> > >> No change (at least in my tree) since my last report on this list > somewhere in May or June. > >> > >> The kernel boots with 4 cpus and working usb. I use an usb > >> ethernet > device and usb disk with the root filesysteem. Compiling and running > ports works, but a build world fails randomly with a memory access > error eg after running 15 minutes. > > > > Sounds possibly similar to TARGET_ARCH=powerpc 's stack-handling > > SVR4 ABI > violation when world is built by clang 3.8.0 (bad clang code > generation). To get to the point of buildworld going through I had to > change the kernel to provide a so-called "red-zone" on the stack > during signal handling to protect the stack from being trashed. > buildworld gets extensive signals (SIGCHLD) and so without the > "red-zone" it would eventually get trashed addresses, far before > getting near completion. > > I see my wording was poor for indicating the staging: I was already > running a powerpc world built with clang 3.8.0's bad powerpc code > generation when I tried to buildworld and had the signal handling > problems (stack usage conflicts). The "red-zone" kernel hack allowed > such buildworld activity to reliably work despite the clang 3.8.0 > based bad code that was in use. > > > [Context: buildkernel via gcc 4.2.1 but buildworld via clang > > 3.8.0 .] > > > > [Side note: I've tried aarch64 releng/11.0 (first RELEASE's raw) > > under > qemu on Ubuntu 16.04.1 on the ODroid-C2 but it gots periodic illegal > instructions in very basic operation, no builds active.] > > > >> I don't think it makes sense to work on this until a freebsd rpi3 > >> arm64 > port is officially supported... > > > > [FYI: http://ameridroid.com/products/raspberry-pi-2-model-b-1gb-ram > > lists > the RPi2B as both "out of stock" and "discontinued" and has for some > time.] > > > >> Op zo 2 okt. 2016 15:04 schreef Mark Millard >> ]dsl-only.net>: . . . > >> Anything worth reporting on the ODroid-C2 details for FreeBSD: > >> what > works, what does not, what needs to be done to boot FreeBSD, and so > on? (I assume head [CURRENT-12 these days].) > >> > >> > >> Looking around. . . > >> > >> > >> https://github.com/tomtor/image-freebsd-c2 > >> > >> seems to have last been updated on May 7 (vs. > https://github.com/tomtor/image-freebsd-pine64 's April 17). > >> > >> > >> https://github.com/tomtor/freebsd/tree/tc2 > >> > >> seems to have last been updated on June 17. > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > 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 Tue Jan 24 20:16: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 450ABCC0F5E for ; Tue, 24 Jan 2017 20:16:03 +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 D8651B1B for ; Tue, 24 Jan 2017 20:16:02 +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 v0OJklw4060476 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Jan 2017 20:46:47 +0100 (CET) (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 v0OJki5B033323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jan 2017 20:46:44 +0100 (CET) (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 v0OJkhaM004760; Tue, 24 Jan 2017 20:46:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v0OJkgqb004759; Tue, 24 Jan 2017 20:46:42 +0100 (CET) (envelope-from ticso) Date: Tue, 24 Jan 2017 20:46:42 +0100 From: Bernd Walter To: Hagen =?iso-8859-1?Q?K=FChl?= Cc: Jim Thompson , "freebsd-arm@freebsd.org" Subject: Re: Durable/serious arm hardware ? Message-ID: <20170124194641.GH85666@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <20170123211201.58eb947e@kvoth.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170123211201.58eb947e@kvoth.localdomain> 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, 24 Jan 2017 20:16:03 -0000 On Mon, Jan 23, 2017 at 09:12:01PM +0100, Hagen Kühl wrote: > On Mon, 23 Jan 2017 01:07:37 -0600 > Jim Thompson wrote: > > > We have a little two port router based on the same SoC as the BBB. I > > selected that platform as one of the better supported platforms on > > FreeBSD. It still took a lot of (months of) work to make the freebsd > > (and subsequently pfSense) for it into something that could be a > > "product". All the FreeBSD work is in the tree. Most vendors don't > > do that. That's not a humble brag, it's a statement of truth. > > > > We're currently in discussions with a vendor to get the Ethernet > > driver for our next ARM product, since, ..., it's not in the tree. > > It's great that you're doing this work, especially committing it back > into the tree. > > What I would also be interested in, is a solution for an ARM based > wireless access point running FreeBSD. Right now I have one of my > Raspberry Pis set up to do it, but the wireless performance leaves > something to be desired. > > Do you have any tips on what to use for that? I wished we had PCI-Express support for the iMX6. A Novena Board (probably not easy to source in the long run), or a Technexion board have Mini-PCIe slots in which you can fit WiFi cards. SDIO-WiFi (unsupported right now) and USB-WiFi are not the best solutions for various reasons. On the other hand, if you can live with the mass storage constrained MIPS based Atheros SoCs you end up with many good options. The only downside is that running / on USB stick turned out to be unrelyable for unknown reasons on any Atheros SoC based board I've tested. > > The SoC vendors all have Linux on the brain. They see a much larger > > market there. Convincing them to dedicate resources to FreeBSD can be > > challenging. One of the things we've been able to do with pfSense is > > to show real volume for a FreeBSD based application. I can go to a > > SoC vendor (TI, Marvell, etc) and talk about committing to, say, N x > > 10K+ unit volumes. That tends to help get their attention. The > > Foundation helps a lot here, too, which is why I won't take > > "donations" for pfsense and instead direct people to donate to the > > FreeBSD Foundation. > > > > In closing, the board you name are all "developer / hobbyist" boards, > > and may not have the level of engineering in them that it takes to > > make into a product. At least two of them are price-supported, where > > a non-profit gets some portion of the BoM discounted, which makes for > > a very low-price board, but also brings some short-cutting (try to > > get a warranty claim on a BBB or RPi). > > > > Jim > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Tue Jan 24 23:03: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 83AC9CC0B23 for ; Tue, 24 Jan 2017 23:03:12 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 3C9EF18AF for ; Tue, 24 Jan 2017 23:03:12 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x22b.google.com with SMTP id 96so146496314uaq.3 for ; Tue, 24 Jan 2017 15:03:12 -0800 (PST) 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:content-transfer-encoding; bh=aHxcZckXWOzXemb2IoSM3Z0OXQ+Coztj1cIvp7FH2cY=; b=s28ygudVXwkt3Oq3lX6q8B6x7DNT2++p30z/Cxe6vLxH3VWXzUAJ4WCggs2Uwx9STN bkfOcnO2BXuz4Cb3xso04yEebXXBezHa1Nqp/TBtFFGU3SJyupBWgD1SBJQz9NuYjm4Z c4gkOk3HAQwHe/GiSIjv6TFYyZ5sdwCJVoVfdMbxOeVXm8418TejUOco5ADRC0cWnhvE dv2terLdOYY4BOp81vXdFV5ABC3wgYu7EWxIL5s0aZrUwxutCDCx0JhIcT1jtvboO7nC VdpAFgfZnYy2o9LFsYyxg1D9+lGyPgSE9P5lC9a+vmGYrhRfcN0jtV4VDODOz6DVrIVt Iujg== 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:content-transfer-encoding; bh=aHxcZckXWOzXemb2IoSM3Z0OXQ+Coztj1cIvp7FH2cY=; b=KYUGg5bKyQ+GJko0PpsRR1jsYgirArFcZccIGS5oYwCZFlr0v1eriV4lVqnNBWLQ6q roMmfAkWSyiq9damfq8U4ApI2pj182h419ToiBNyKCLBe9VHlQQJQIHu21zre6XE8/0V /qEI6TUQSxeEm+JdBlzCTiHq+bsZXYIa/nHb8w0zEAwOtRx2OY9anJih9YaaXZFeWXPL J728zDU7dkAYNd+9b81tFDcOitP30/sidQDqoPXcydDaDMVKsUpBvIGOlW6hVlleZmlK pCiZ167DrE8PMmaV0NqiZbeJpHvQCpJ9k1UUrwgUM0dTElXmkn3JDcur/IRO2mfQ0uqY 7SmQ== X-Gm-Message-State: AIkVDXJJJnGCoPlOGZO9tSoR3s2fkBatQbCHFFfxbLbzpG4MTHoguZreZ1CrT+ywQRLO3eDZpg4nHJbA8upelA== X-Received: by 10.176.2.86 with SMTP id 80mr19559322uas.11.1485298991260; Tue, 24 Jan 2017 15:03:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.44.77 with HTTP; Tue, 24 Jan 2017 15:03:10 -0800 (PST) In-Reply-To: <20170124194641.GH85666@cicely7.cicely.de> References: <45d41ec7-3004-ea6c-560e-50bdff9b997a@caliopea.com> <20170123211201.58eb947e@kvoth.localdomain> <20170124194641.GH85666@cicely7.cicely.de> From: Russell Haley Date: Tue, 24 Jan 2017 15:03:10 -0800 Message-ID: Subject: Re: Durable/serious arm hardware ? To: ticso@cicely.de Cc: =?UTF-8?Q?Hagen_K=C3=BChl?= , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 24 Jan 2017 23:03:12 -0000 On Tue, Jan 24, 2017 at 11:46 AM, Bernd Walter wr= ote: > On Mon, Jan 23, 2017 at 09:12:01PM +0100, Hagen K=C3=BChl wrote: >> On Mon, 23 Jan 2017 01:07:37 -0600 >> Jim Thompson wrote: >> >> > We have a little two port router based on the same SoC as the BBB. I >> > selected that platform as one of the better supported platforms on >> > FreeBSD. It still took a lot of (months of) work to make the freebsd >> > (and subsequently pfSense) for it into something that could be a >> > "product". All the FreeBSD work is in the tree. Most vendors don't >> > do that. That's not a humble brag, it's a statement of truth. >> > >> > We're currently in discussions with a vendor to get the Ethernet >> > driver for our next ARM product, since, ..., it's not in the tree. >> >> It's great that you're doing this work, especially committing it back >> into the tree. >> >> What I would also be interested in, is a solution for an ARM based >> wireless access point running FreeBSD. Right now I have one of my >> Raspberry Pis set up to do it, but the wireless performance leaves >> something to be desired. >> >> Do you have any tips on what to use for that? > > I wished we had PCI-Express support for the iMX6. > A Novena Board (probably not easy to source in the long run), or a > Technexion board have Mini-PCIe slots in which you can fit WiFi cards. > SDIO-WiFi (unsupported right now) and USB-WiFi are not the best > solutions for various reasons. There are a few good iMX6 boards out there. There are quite a few things not supported unfortunately. SDIO wifi seems to be very common now, with quite a few chip vendors using it (But Mr. Chadd would be a better person to verify that). Using SDIO saves a PCIe or USB slot and can more than support 802.11n for throughput (from my understanding). The SDIO driver is in the dev tree, but Mr. Losh seems to be working on the arguably higher priority u-boot fragmentation. On a personal note, I just moved into a house and may soon have a spare room for a lab and some time to try and help out with SDIO or iMX6 stuff. Here's to wishful thinking! ;) Russ > On the other hand, if you can live with the mass storage constrained > MIPS based Atheros SoCs you end up with many good options. > The only downside is that running / on USB stick turned out to be > unrelyable for unknown reasons on any Atheros SoC based board I've tested= . > >> > The SoC vendors all have Linux on the brain. They see a much larger >> > market there. Convincing them to dedicate resources to FreeBSD can be >> > challenging. One of the things we've been able to do with pfSense is >> > to show real volume for a FreeBSD based application. I can go to a >> > SoC vendor (TI, Marvell, etc) and talk about committing to, say, N x >> > 10K+ unit volumes. That tends to help get their attention. The >> > Foundation helps a lot here, too, which is why I won't take >> > "donations" for pfsense and instead direct people to donate to the >> > FreeBSD Foundation. >> > >> > In closing, the board you name are all "developer / hobbyist" boards, >> > and may not have the level of engineering in them that it takes to >> > make into a product. At least two of them are price-supported, where >> > a non-profit gets some portion of the BoM discounted, which makes for >> > a very low-price board, but also brings some short-cutting (try to >> > get a warranty claim on a BBB or RPi). >> > >> > Jim >> _______________________________________________ >> 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" > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > 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 Wed Jan 25 04:24: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 D4462CB212E; Wed, 25 Jan 2017 04:24:26 +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 5E9421989; Wed, 25 Jan 2017 04:24:25 +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 v0P4OHIN073921 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 05:24:17 +0100 (CET) (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 v0P4OEbr045963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2017 05:24:14 +0100 (CET) (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 v0P4OEoA006974; Wed, 25 Jan 2017 05:24:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v0P4ODcP006971; Wed, 25 Jan 2017 05:24:13 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Jan 2017 05:24:13 +0100 From: Bernd Walter To: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Cc: Bernd Walter Subject: 11.0-RC1 unsupported by ports? Message-ID: <20170125042413.GK85666@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Wed, 25 Jan 2017 04:24:26 -0000 [61]cnc# make install /!\ ERROR: /!\ Ports Collection support for your FreeBSD version has ended, and no ports are guaranteed to build on this system. Please upgrade to a supported release. No support will be provided if you silence this message by defining ALLOW_UNSUPPORTED_SYSTEM. *** Error code 1 Stop. make[1]: stopped in /usr/ports/misc/raspberrypi-userland *** Error code 1 Stop. make: stopped in /usr/ports/misc/raspberrypi-userland Exit 1 [62]cnc# uname -a FreeBSD cnc.cicely.de 11.0-RC1 FreeBSD 11.0-RC1 #0 r303979: Fri Aug 12 17:12:13 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Jan 25 06:20: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 44D66CBE43C; Wed, 25 Jan 2017 06:20:47 +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 0BA47FAD; Wed, 25 Jan 2017 06:20:47 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cWGwn-0007Fi-DQ; Wed, 25 Jan 2017 07:20:45 +0100 Date: Wed, 25 Jan 2017 07:20:45 +0100 From: Kurt Jaeger To: ticso@cicely.de Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org, Bernd Walter Subject: Re: 11.0-RC1 unsupported by ports? Message-ID: <20170125062045.GS13006@home.opsec.eu> References: <20170125042413.GK85666@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125042413.GK85666@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, 25 Jan 2017 06:20:47 -0000 Hi! > [61]cnc# make install > /!\ ERROR: /!\ > > Ports Collection support for your FreeBSD version has ended, and no ports are > guaranteed to build on this system. Please upgrade to a supported release. > > No support will be provided if you silence this message by defining > ALLOW_UNSUPPORTED_SYSTEM. 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit drastic, there's a point to it. -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-arm@freebsd.org Wed Jan 25 07:55: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 D40BBCC0D88; Wed, 25 Jan 2017 07:55:09 +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 5178DED4; Wed, 25 Jan 2017 07:55:08 +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 v0P7t3Q3079496 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 08:55:04 +0100 (CET) (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 v0P7t1Gb048702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2017 08:55:01 +0100 (CET) (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 v0P7t0Lx007549; Wed, 25 Jan 2017 08:55:00 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v0P7t0K4007548; Wed, 25 Jan 2017 08:55:00 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Jan 2017 08:55:00 +0100 From: Bernd Walter To: Kurt Jaeger Cc: ticso@cicely.de, freebsd-arm@freebsd.org, freebsd-ports@freebsd.org, Bernd Walter Subject: Re: 11.0-RC1 unsupported by ports? Message-ID: <20170125075459.GL85666@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125062045.GS13006@home.opsec.eu> 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: Wed, 25 Jan 2017 07:55:09 -0000 On Wed, Jan 25, 2017 at 07:20:45AM +0100, Kurt Jaeger wrote: > Hi! > > > [61]cnc# make install > > /!\ ERROR: /!\ > > > > Ports Collection support for your FreeBSD version has ended, and no ports are > > guaranteed to build on this system. Please upgrade to a supported release. > > > > No support will be provided if you silence this message by defining > > ALLOW_UNSUPPORTED_SYSTEM. > > 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit > drastic, there's a point to it. With that argument only the latest version would be supported. That said, it is a release candidate and as such one could argue that there never had been any official support at all. In that case however the message is wrong, because when a support has ended it implies that there was support. The check in the code is this one: .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 1100000 && ${OSVERSION} < 1100122))) || \ (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400) It is not about RC as such, it is explicitly about 11.0-RC. My OSVERSION is 1100121. So obviously support starts with the first release. Fair enough, but then the message is still wrong unless it was supported. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Jan 25 08:13:20 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 66317CC04BA; Wed, 25 Jan 2017 08:13:20 +0000 (UTC) (envelope-from pi@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 2A4FEA7A; Wed, 25 Jan 2017 08:13:20 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cWIhi-0007Q7-74; Wed, 25 Jan 2017 09:13:18 +0100 Date: Wed, 25 Jan 2017 09:13:18 +0100 From: Kurt Jaeger To: ticso@cicely.de Cc: Kurt Jaeger , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org, Bernd Walter Subject: Re: 11.0-RC1 unsupported by ports? Message-ID: <20170125081318.GT13006@home.opsec.eu> References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125075459.GL85666@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, 25 Jan 2017 08:13:20 -0000 Hi! > > 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit > > drastic, there's a point to it. > > With that argument only the latest version would be supported. https://www.freebsd.org/releases/ lists the supported releases. There are no release candidates listed. > That said, it is a release candidate and as such one could argue that > there never had been any official support at all. > In that case however the message is wrong, because when a support has > ended it implies that there was support. > > The check in the code is this one: > .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 1100000 && ${OSVERSION} < 1100122))) || \ > (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400) > > It is not about RC as such, it is explicitly about 11.0-RC. > My OSVERSION is 1100121. > So obviously support starts with the first release. > Fair enough, but then the message is still wrong unless it was supported. What's stopping you from upgrading to -REL ? -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-arm@freebsd.org Wed Jan 25 08:26: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 B7579CC0941 for ; Wed, 25 Jan 2017 08:26:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 7B17EF55 for ; Wed, 25 Jan 2017 08:26:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28123 invoked from network); 25 Jan 2017 08:26:29 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Jan 2017 08:26:29 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 25 Jan 2017 03:25:59 -0500 (EST) Received: (qmail 2011 invoked from network); 25 Jan 2017 08:25:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Jan 2017 08:25:59 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A4C3DEC867E; Wed, 25 Jan 2017 00:25:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: 11.0-RC1 unsupported by ports? From: Mark Millard In-Reply-To: <20170125075459.GL85666@cicely7.cicely.de> Date: Wed, 25 Jan 2017 00:25:57 -0800 Cc: Kurt Jaeger , freebsd-arm , Bernd Walter , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <87BFEE93-7617-4131-832B-BE697D352E0D@dsl-only.net> References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> To: ticso@cicely.de 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: Wed, 25 Jan 2017 08:26:06 -0000 On 2017-Jan-24, at 11:55 PM, Bernd Walter = wrote: On Wed, Jan 25, 2017 at 07:20:45AM +0100, Kurt Jaeger wrote: > Hi! >=20 >>> [61]cnc# make install >>> /!\ ERROR: /!\ >>>=20 >>> Ports Collection support for your FreeBSD version has ended, and no = ports are >>> guaranteed to build on this system. Please upgrade to a supported = release. >>>=20 >>> No support will be provided if you silence this message by defining >>> ALLOW_UNSUPPORTED_SYSTEM. >>=20 >> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit >> drastic, there's a point to it. >=20 > With that argument only the latest version would be supported. > That said, it is a release candidate and as such one could argue that > there never had been any official support at all. > In that case however the message is wrong, because when a support has > ended it implies that there was support. >=20 > The check in the code is this one: > .if (${OPSYS} =3D=3D FreeBSD && (${OSVERSION} < 1003000 || = (${OSVERSION} >=3D 1100000 && ${OSVERSION} < 1100122))) || \ > (${OPSYS} =3D=3D DragonFly && ${DFLYVERSION} < 400400) >=20 > It is not about RC as such, it is explicitly about 11.0-RC. > My OSVERSION is 1100121. > So obviously support starts with the first release. > Fair enough, but then the message is still wrong unless it was = supported. >=20 > --=20 > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. This is a new check as of -r431746 (Jan 17). The wording is simply not explicit about prior history from before the check was added. For as "as if the check had been in place for a long time" interpretation I'd guess: A) 11.0-RC1 would be considered supported when first created. https://www.freebsd.org/security/security.html#sup says: In the run-up to a release, a number of -BETA and -RC releases may be = published for testing purposes. These releases are only supported for a = few weeks, as resources permit, and will not be listed as supported on = this page. Users are strongly discouraged from running these releases on = production systems. B) 11.0-RELEASE would have made 11.0-RC1 not be supported (if 11.0-RC1 was even supported for that long). C) stable/11 is supported D) head is "supported" (no complaint anyway). That last (head) is despite: https://www.freebsd.org/security/security.html#sup reporting as currently supported: stable/10 releng/10.3 (10.3-RELEASE) stable/11 releng/11.0 (11.0-RELEASE) (head is not mentioned.) Quoting https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?view=3Dlog . . . Revision 431746 - (view) (download) (annotate) - [select for diffs]=20 Modified Tue Jan 17 15:49:16 2017 UTC (7 days, 16 hours ago) by amdmi3=20= File length: 181933 byte(s)=20 Diff to previous 431681 - Refuse (overridable) to build ports on unsupported system version Unfortunately, it's not uncommon for FreeBSD users to not update their systems timely and thus end up using unsupported FreeBSD release. These users continue to update ports tree as usual and expect it to work, either unaware of the release EoL, or not clearly understanding the consequences, which results in unexpected build failures, bogus bug reports, attempts to bring back removed legacy support bits and general discontent. This change introduces system version check which makes ports refuse to build anything on unsupported system. This makes users aware of EoL of their system and makes it clear that no port is guaranteed to build. The error message tells how to override the check (by defining ALLOW_UNSUPPORTED_SYSTEM, in which case it's turned into a simple warning), additionally stressing that this configurartion is not supported. Currently outdated are OSVERSION < 1003000 (pre 10.3-RELEASE) and 1100000 <=3D OSVERSION < 1100122 (from 11-CURRENT'2013 to = 11.0-PRERELEASE) I expect these to be kept up to date with base system lifetimes, be updated BEFORE removing any support for outdated release from the tree and also serve as a reference of which OSVERSION checks may be removed. Approved by: portmgr (swills, mat) Differential Revision: D9210 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Jan 25 08:33: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 4EA65CC0D09; Wed, 25 Jan 2017 08:33:47 +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 12BF414AF; Wed, 25 Jan 2017 08:33:47 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cWJ1W-0007T8-BB; Wed, 25 Jan 2017 09:33:46 +0100 Date: Wed, 25 Jan 2017 09:33:46 +0100 From: Kurt Jaeger To: Mark Millard Cc: freebsd-arm , Bernd Walter , freebsd-ports@freebsd.org Subject: Re: 11.0-RC1 unsupported by ports? Message-ID: <20170125083346.GU13006@home.opsec.eu> References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <87BFEE93-7617-4131-832B-BE697D352E0D@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87BFEE93-7617-4131-832B-BE697D352E0D@dsl-only.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: Wed, 25 Jan 2017 08:33:47 -0000 Hi!! Mark wrote: > In the run-up to a release, a number of -BETA and -RC releases may be published for testing purposes. These releases are only supported for a few weeks, as resources permit, and will not be listed as supported on this page. Users are strongly discouraged from running these releases on production systems. > > B) 11.0-RELEASE would have made 11.0-RC1 not be supported > (if 11.0-RC1 was even supported for that long). > > C) stable/11 is supported > > D) head is "supported" (no complaint anyway). HEAD is for testing, it's not supported in the word-smithing kind of way 8-} -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-arm@freebsd.org Wed Jan 25 08:47: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 AA081CC1004; Wed, 25 Jan 2017 08:47:45 +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 340C919DE; Wed, 25 Jan 2017 08:47:44 +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 v0P8lgoR080318 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 09:47:43 +0100 (CET) (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 v0P8ld4g049437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2017 09:47:40 +0100 (CET) (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 v0P8ldZG007685; Wed, 25 Jan 2017 09:47:39 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v0P8ldKR007684; Wed, 25 Jan 2017 09:47:39 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Jan 2017 09:47:39 +0100 From: Bernd Walter To: Kurt Jaeger Cc: ticso@cicely.de, Kurt Jaeger , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org, Bernd Walter Subject: Re: 11.0-RC1 unsupported by ports? Message-ID: <20170125084738.GM85666@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125081318.GT13006@home.opsec.eu> 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: Wed, 25 Jan 2017 08:47:45 -0000 On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote: > Hi! > > > > 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit > > > drastic, there's a point to it. > > > > With that argument only the latest version would be supported. > > https://www.freebsd.org/releases/ lists the supported releases. > There are no release candidates listed. > > > That said, it is a release candidate and as such one could argue that > > there never had been any official support at all. > > In that case however the message is wrong, because when a support has > > ended it implies that there was support. > > > > The check in the code is this one: > > .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 1100000 && ${OSVERSION} < 1100122))) || \ > > (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400) > > > > It is not about RC as such, it is explicitly about 11.0-RC. > > My OSVERSION is 1100121. > > So obviously support starts with the first release. > > Fair enough, but then the message is still wrong unless it was supported. > > What's stopping you from upgrading to -REL ? Buildworld on a raspberry isn't fun - if it works at all. Even if you crossbuild and just copy the binaries, the wear of MicroSD cards isn't something you want to test unless you really have to. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Jan 25 09:48: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 33CE3CC1E5F; Wed, 25 Jan 2017 09:48:33 +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 A59D3922; Wed, 25 Jan 2017 09:48:32 +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 v0P9mNAX081920 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 10:48:23 +0100 (CET) (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 v0P9mKsH050327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2017 10:48:20 +0100 (CET) (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 v0P9mKbv007864; Wed, 25 Jan 2017 10:48:20 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v0P9mKUf007863; Wed, 25 Jan 2017 10:48:20 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Jan 2017 10:48:20 +0100 From: Bernd Walter To: Kurt Jaeger Cc: Mark Millard , freebsd-arm , Bernd Walter , freebsd-ports@freebsd.org Subject: Re: 11.0-RC1 unsupported by ports? Message-ID: <20170125094820.GB7817@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <87BFEE93-7617-4131-832B-BE697D352E0D@dsl-only.net> <20170125083346.GU13006@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125083346.GU13006@home.opsec.eu> 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: Wed, 25 Jan 2017 09:48:33 -0000 On Wed, Jan 25, 2017 at 09:33:46AM +0100, Kurt Jaeger wrote: > Hi!! > > Mark wrote: > > In the run-up to a release, a number of -BETA and -RC releases may be published for testing purposes. These releases are only supported for a few weeks, as resources permit, and will not be listed as supported on this page. Users are strongly discouraged from running these releases on production systems. > > > > B) 11.0-RELEASE would have made 11.0-RC1 not be supported > > (if 11.0-RC1 was even supported for that long). > > > > C) stable/11 is supported > > > > D) head is "supported" (no complaint anyway). > > HEAD is for testing, it's not supported in the word-smithing kind of way 8-} Well, the main cause for confusion was the wording and I didn't know what exactly it triggers, plus it first happened to me on an arm based system and wasn't sure if that unsupported was related to arm. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Jan 25 09:52: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 EF1D0CB505C; Wed, 25 Jan 2017 09:52:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85B1FCBC; Wed, 25 Jan 2017 09:52:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from sgi-2.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cWKFP-0004cs-4b; Wed, 25 Jan 2017 11:52:11 +0200 From: Daniel Braniss Message-Id: <41DFEC72-FA4B-4065-B057-D29EF43BD494@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: 11.0-RC1 unsupported by ports? Date: Wed, 25 Jan 2017 11:52:10 +0200 In-Reply-To: <20170125084738.GM85666@cicely7.cicely.de> Cc: Kurt Jaeger , Bernd Walter , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org To: ticso@cicely.de References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> <20170125084738.GM85666@cicely7.cicely.de> 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: Wed, 25 Jan 2017 09:52:24 -0000 > On 25 Jan 2017, at 10:47, Bernd Walter = wrote: >=20 > On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote: >> Hi! >>=20 >>>> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit >>>> drastic, there's a point to it. >>>=20 >>> With that argument only the latest version would be supported. >>=20 >> https://www.freebsd.org/releases/ lists the supported releases. >> There are no release candidates listed. >>=20 >>> That said, it is a release candidate and as such one could argue = that >>> there never had been any official support at all. >>> In that case however the message is wrong, because when a support = has >>> ended it implies that there was support. >>>=20 >>> The check in the code is this one: >>> .if (${OPSYS} =3D=3D FreeBSD && (${OSVERSION} < 1003000 || = (${OSVERSION} >=3D 1100000 && ${OSVERSION} < 1100122))) || \ >>> (${OPSYS} =3D=3D DragonFly && ${DFLYVERSION} < 400400) >>>=20 >>> It is not about RC as such, it is explicitly about 11.0-RC. >>> My OSVERSION is 1100121. >>> So obviously support starts with the first release. >>> Fair enough, but then the message is still wrong unless it was = supported. >>=20 >> What's stopping you from upgrading to -REL ? >=20 > Buildworld on a raspberry isn't fun - if it works at all. > Even if you crossbuild and just copy the binaries, the wear of > MicroSD cards isn't something you want to test unless you really > have to. most of the time this works for me: mount host:/export-to-rpi/local /usr/local echo =E2=80=98WRKDIRPREFIX=3D/var/tmp=E2=80=99 >> /etc/make.conf mount via nfs /var/tmp, i.e. mount host:/export-to-rpi/tmp /var/tmp also add swap via nfs: mount host:/export-to-rpi/swap /mnt-swap swapon /mnt-swap >=20 > --=20 > B.Walter > http://www.bwct.de = > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > 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 Wed Jan 25 10:27: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 CB2A7CBF48C for ; Wed, 25 Jan 2017 10:27:50 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9160A1CC7 for ; Wed, 25 Jan 2017 10:27:50 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1cWKns-00HFqo-EM; Wed, 25 Jan 2017 11:27:48 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: Bernd Walter cc: freebsd-arm@freebsd.org Subject: Re: 11.0-RC1 unsupported by ports? In-reply-to: <20170125084738.GM85666@cicely7.cicely.de> References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> <20170125084738.GM85666@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jan 2017 11:27:48 +0100 Message-Id: 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, 25 Jan 2017 10:27:50 -0000 On Wed, 25 Jan 2017 09:47:39 +0100, Bernd Walter wrote: > Buildworld on a raspberry isn't fun - if it works at all. > Even if you crossbuild and just copy the binaries, the wear of > MicroSD cards isn't something you want to test unless you really > have to. Just for the records: It works and takes about 4.5 days on a raspberry B using an USB stick. The last stick survived almost 7 month with approximately two buildworld a month. In my experience using NFS was slower. I did not try buildworld on a SD card. Ralf From owner-freebsd-arm@freebsd.org Wed Jan 25 10:38: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 BD862CBFAE6; Wed, 25 Jan 2017 10:38:12 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (prod2.absolight.net [79.143.243.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 58CEAD81; Wed, 25 Jan 2017 10:38:12 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 721F3BDC91; Wed, 25 Jan 2017 11:38:10 +0100 (CET) Received: from atuin.in.mat.cc (atuin.in.mat.cc [79.143.241.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by prod2.absolight.net (Postfix) with ESMTPSA id 47623BDC89; Wed, 25 Jan 2017 11:38:10 +0100 (CET) Subject: Re: 11.0-RC1 unsupported by ports? To: ticso@cicely.de, Kurt Jaeger References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> Cc: freebsd-arm@freebsd.org, Bernd Walter , freebsd-ports@freebsd.org From: Mathieu Arnold Organization: Absolight / The FreeBSD Foundation Message-ID: Date: Wed, 25 Jan 2017 11:38:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170125075459.GL85666@cicely7.cicely.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uj5DmU2vlBFBjbe4700N3XrX5nGlxQLaK" 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, 25 Jan 2017 10:38:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uj5DmU2vlBFBjbe4700N3XrX5nGlxQLaK Content-Type: multipart/mixed; boundary="bs34AvGifN1t4I6dllVAivXMTvlrTAOlj"; protected-headers="v1" From: Mathieu Arnold To: ticso@cicely.de, Kurt Jaeger Cc: freebsd-arm@freebsd.org, Bernd Walter , freebsd-ports@freebsd.org Message-ID: Subject: Re: 11.0-RC1 unsupported by ports? References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> In-Reply-To: <20170125075459.GL85666@cicely7.cicely.de> --bs34AvGifN1t4I6dllVAivXMTvlrTAOlj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 25/01/2017 =C3=A0 08:55, Bernd Walter a =C3=A9crit : > On Wed, Jan 25, 2017 at 07:20:45AM +0100, Kurt Jaeger wrote: >> Hi! >> >>> [61]cnc# make install >>> /!\ ERROR: /!\ >>> >>> Ports Collection support for your FreeBSD version has ended, and no p= orts are >>> guaranteed to build on this system. Please upgrade to a supported rel= ease. >>> >>> No support will be provided if you silence this message by defining >>> ALLOW_UNSUPPORTED_SYSTEM. >> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit >> drastic, there's a point to it. > With that argument only the latest version would be supported. > That said, it is a release candidate and as such one could argue that > there never had been any official support at all. > In that case however the message is wrong, because when a support has > ended it implies that there was support. > > The check in the code is this one: > .if (${OPSYS} =3D=3D FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION= } >=3D 1100000 && ${OSVERSION} < 1100122))) || \ > (${OPSYS} =3D=3D DragonFly && ${DFLYVERSION} < 400400) > > It is not about RC as such, it is explicitly about 11.0-RC. > My OSVERSION is 1100121. > So obviously support starts with the first release. > Fair enough, but then the message is still wrong unless it was supporte= d. The alpha/beta/rc versions preceding a release are never supported after the next alpha/beta/rc is released (meaning beta3 stops being supported when rc1 goes out, and the last rc stops being supported when the release goes out.) Like the message says, you can define ALLOW_UNSUPPORTED_SYSTEM to continue using the non supported version you are running. --=20 Mathieu Arnold --bs34AvGifN1t4I6dllVAivXMTvlrTAOlj-- --uj5DmU2vlBFBjbe4700N3XrX5nGlxQLaK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYiIARXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQUI2OTc4OUQyRUQxMjEwNjQ0MEJBNUIz QTQ1MTZGMzUxODNDRTQ4AAoJEDpFFvNRg85IuBgQAI9phKDsvQ7OVPwa1k379fGW EdneEJh1BjR2S+huUCU6PI3vzG9g/FRIi7+lkAZ2ZN3I4/S40v9kL5n+gQDd88Do Vi3B9dk+VrSSrVSXxP/W95vKjx8SF7o9WSfEBSnO/jCD/V46TzzysUgo0+AyQEVV XspKofP3yLrMHYYZaFAsDWO0sfLjW0/ctOcJpazKG7m70j4cVzECtxwxLQgxDp5G baGqGUCzgtKTDw0BhFtcWOQF+Iunm3JnG8sPYVzwJP4ToKUxIpEaD1RAs9N8MvPa WH5USgcQ1JxZoZ5wJjeNJtShw+hLLQwNVYU9KbamoOCk5pasKtgBxZ3gfAtq57YC k/P0k48SoZtEP5qFX7X0k3131/IoTBJmFtNsYxplSaLewQfgiJh5RVBvAt12V27Q oKnDALuLyNttXkdYIeA9j2Ew8F7pTteKX2DMuI5NHQZ1O+LKPoaBifpcHvkqt6RS zlQ1NCvXl5OK4TH7/GSbCcTQnK3fI2wOBE2SGVKAt3vGfgVWBjf/MfiiooiFfSUx bz9zcdX9kWWySATA1W6creU6BCLBhjQVcocGGLNLZ5UEJnbbO5TlEfv8ZumyCs95 70z4n+cRrJAdSf231cmpDszZ7E0sClKZWMkmex1E7VElatuouRsQJ9qsi6WvzLeN Cu112jTOXnuGbssD9s/i =Y4sZ -----END PGP SIGNATURE----- --uj5DmU2vlBFBjbe4700N3XrX5nGlxQLaK-- From owner-freebsd-arm@freebsd.org Wed Jan 25 10:39:29 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 00AF3CBFC2F; Wed, 25 Jan 2017 10:39:29 +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 A133EE92; Wed, 25 Jan 2017 10:39:28 +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 v0PAdIY1085143 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 11:39:18 +0100 (CET) (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 v0PAdFC6051060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2017 11:39:15 +0100 (CET) (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 v0PAdFSc008013; Wed, 25 Jan 2017 11:39:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v0PAdFo0008012; Wed, 25 Jan 2017 11:39:15 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Jan 2017 11:39:15 +0100 From: Bernd Walter To: Daniel Braniss Cc: ticso@cicely.de, Kurt Jaeger , Bernd Walter , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 11.0-RC1 unsupported by ports? Message-ID: <20170125103914.GD7817@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> <20170125084738.GM85666@cicely7.cicely.de> <41DFEC72-FA4B-4065-B057-D29EF43BD494@cs.huji.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DFEC72-FA4B-4065-B057-D29EF43BD494@cs.huji.ac.il> 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: Wed, 25 Jan 2017 10:39:29 -0000 On Wed, Jan 25, 2017 at 11:52:10AM +0200, Daniel Braniss wrote: > > > On 25 Jan 2017, at 10:47, Bernd Walter wrote: > > > > On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote: > >> Hi! > >> > >>>> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit > >>>> drastic, there's a point to it. > >>> > >>> With that argument only the latest version would be supported. > >> > >> https://www.freebsd.org/releases/ lists the supported releases. > >> There are no release candidates listed. > >> > >>> That said, it is a release candidate and as such one could argue that > >>> there never had been any official support at all. > >>> In that case however the message is wrong, because when a support has > >>> ended it implies that there was support. > >>> > >>> The check in the code is this one: > >>> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 1100000 && ${OSVERSION} < 1100122))) || \ > >>> (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400) > >>> > >>> It is not about RC as such, it is explicitly about 11.0-RC. > >>> My OSVERSION is 1100121. > >>> So obviously support starts with the first release. > >>> Fair enough, but then the message is still wrong unless it was supported. > >> > >> What's stopping you from upgrading to -REL ? > > > > Buildworld on a raspberry isn't fun - if it works at all. > > Even if you crossbuild and just copy the binaries, the wear of > > MicroSD cards isn't something you want to test unless you really > > have to. > > most of the time this works for me: > mount host:/export-to-rpi/local /usr/local > echo ???WRKDIRPREFIX=/var/tmp??? >> /etc/make.conf > mount via nfs /var/tmp, i.e. > mount host:/export-to-rpi/tmp /var/tmp > also add swap via nfs: > mount host:/export-to-rpi/swap /mnt-swap > swapon /mnt-swap This has nothing to do with updating the OS itself. That said, I assume host:/export-to-rpi/local is only used by a single host. It gets tricky with shared /usr/local, since the package registration is in a different path and ports/packages may also touch /etc - e.g. /etc/shells, or add service users for a specific software. It is possible to do, but unless you are very carefull things can easily get messy. Same goes for /tmp. Needless to say that swap isn't to be shared at all... But I'm not sure if swap on NFS is completely deadlock free. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Jan 25 10:39: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 757B2CBFC8E; Wed, 25 Jan 2017 10:39:52 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (prod2.absolight.net [79.143.243.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11024F77; Wed, 25 Jan 2017 10:39:52 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 88362BDC9B; Wed, 25 Jan 2017 11:39:50 +0100 (CET) Received: from atuin.in.mat.cc (atuin.in.mat.cc [79.143.241.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by prod2.absolight.net (Postfix) with ESMTPSA id 113E5BDCA4; Wed, 25 Jan 2017 11:39:50 +0100 (CET) Subject: Re: 11.0-RC1 unsupported by ports? To: ticso@cicely.de, Kurt Jaeger References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> <20170125084738.GM85666@cicely7.cicely.de> Cc: Bernd Walter , freebsd-arm@freebsd.org, Kurt Jaeger , freebsd-ports@freebsd.org From: Mathieu Arnold Organization: Absolight / The FreeBSD Foundation Message-ID: <9fa67c9b-0cee-3986-2226-e7e0f687cba5@FreeBSD.org> Date: Wed, 25 Jan 2017 11:39:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170125084738.GM85666@cicely7.cicely.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="skIu9WrRwkr27hqO6URSPMUDxDlc5jJAj" 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, 25 Jan 2017 10:39:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --skIu9WrRwkr27hqO6URSPMUDxDlc5jJAj Content-Type: multipart/mixed; boundary="n1deLMIXMe9S9FDmrj2QItx1IiTLQheNI"; protected-headers="v1" From: Mathieu Arnold To: ticso@cicely.de, Kurt Jaeger Cc: Bernd Walter , freebsd-arm@freebsd.org, Kurt Jaeger , freebsd-ports@freebsd.org Message-ID: <9fa67c9b-0cee-3986-2226-e7e0f687cba5@FreeBSD.org> Subject: Re: 11.0-RC1 unsupported by ports? References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> <20170125084738.GM85666@cicely7.cicely.de> In-Reply-To: <20170125084738.GM85666@cicely7.cicely.de> --n1deLMIXMe9S9FDmrj2QItx1IiTLQheNI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 25/01/2017 =C3=A0 09:47, Bernd Walter a =C3=A9crit : > On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote: >> Hi! >> >>>> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit >>>> drastic, there's a point to it. >>> With that argument only the latest version would be supported. >> https://www.freebsd.org/releases/ lists the supported releases. >> There are no release candidates listed. >> >>> That said, it is a release candidate and as such one could argue that= >>> there never had been any official support at all. >>> In that case however the message is wrong, because when a support has= >>> ended it implies that there was support. >>> >>> The check in the code is this one: >>> .if (${OPSYS} =3D=3D FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSI= ON} >=3D 1100000 && ${OSVERSION} < 1100122))) || \ >>> (${OPSYS} =3D=3D DragonFly && ${DFLYVERSION} < 400400) >>> >>> It is not about RC as such, it is explicitly about 11.0-RC. >>> My OSVERSION is 1100121. >>> So obviously support starts with the first release. >>> Fair enough, but then the message is still wrong unless it was suppor= ted. >> What's stopping you from upgrading to -REL ? > Buildworld on a raspberry isn't fun - if it works at all. > Even if you crossbuild and just copy the binaries, the wear of > MicroSD cards isn't something you want to test unless you really > have to. If you have other computers running FreeBSD, you can build /usr/obj on the other box (using make buildworld TARGET_ARCH=3Dfoo (you may have to check the exact incantation)) copy the /usr/obj, and only run make installworld. --=20 Mathieu Arnold --n1deLMIXMe9S9FDmrj2QItx1IiTLQheNI-- --skIu9WrRwkr27hqO6URSPMUDxDlc5jJAj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYiIB1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQUI2OTc4OUQyRUQxMjEwNjQ0MEJBNUIz QTQ1MTZGMzUxODNDRTQ4AAoJEDpFFvNRg85IqmkQAKv4517qLbH3l7x+/XcWt73J F1MRabCWYW/Zp+6B8+pPFoMftnR1S8qAEU3BAJVnai2O/5uwJofbxO3xdGeoY0em LBdqo81VIYglQiSsDxC21VMbyMxQaJ4HO5ByI0UHiJHDnljJayjqKjhWfFcTI08H 4W7uODxXSO/ZysH+sBxvpSz2Gu1czMQbtq78KTw8ayRAsCc92n9vX+8lSm9YQcLm G4uuAMQqbV1xalzTkQZOM9R0k7THMzTOYBM24yfSHYS2oXAwqJZsxVMMTtkxAlf9 bCz/CcRJGWOK1P22Vjr9Cr/Q2oplTdu/V4SlKShNFhxELvM2/cdD253JNf3F7w4x /ahcFDD/lz2SG7f8b9q7wtVz1Cx/J9RNIIM9kMy+dBp3+Tp9yYkYqKOeUKUy490e TKlzITRK9gbGe+i+0tMRSSl8yg9EIRMFgVI+Sybdixqxj8PBKMLq1FM7s90t5tnJ Vb0TvNVCpcwaJsG5AYmfdRxtgBvn4OyqsB41F287/HZTYzmxucnEYggFqupLJeRN 91i4GjXgAnnKhSHLIQgWA9z9V9DKb0Kt89FTYsQtzZeOvqoX/VYUrCINGebaT5tF Uazj0W2gbG9tOTDXgr6cEZnMO2gC7SnZew0IKBi8mvQOzePjwmyThTmRhDukES/D uhi8jNhEcQ/prA2RnLdS =xnu/ -----END PGP SIGNATURE----- --skIu9WrRwkr27hqO6URSPMUDxDlc5jJAj-- From owner-freebsd-arm@freebsd.org Wed Jan 25 11:28: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 18D74CC0AB4; Wed, 25 Jan 2017 11:28:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA2F266E; Wed, 25 Jan 2017 11:28:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from sgi-2.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cWLkC-0006rh-0P; Wed, 25 Jan 2017 13:28:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: 11.0-RC1 unsupported by ports? From: Daniel Braniss In-Reply-To: <20170125103914.GD7817@cicely7.cicely.de> Date: Wed, 25 Jan 2017 13:28:03 +0200 Cc: Kurt Jaeger , Bernd Walter , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4FF1A4D2-0A95-4416-B3EB-CFB2290A307E@cs.huji.ac.il> References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> <20170125084738.GM85666@cicely7.cicely.de> <41DFEC72-FA4B-4065-B057-D29EF43BD494@cs.huji.ac.il> <20170125103914.GD7817@cicely7.cicely.de> To: ticso@cicely.de 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: Wed, 25 Jan 2017 11:28:09 -0000 > On 25 Jan 2017, at 12:39, Bernd Walter = wrote: >=20 > On Wed, Jan 25, 2017 at 11:52:10AM +0200, Daniel Braniss wrote: >>=20 >>> On 25 Jan 2017, at 10:47, Bernd Walter = wrote: >>>=20 >>> On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote: >>>> Hi! >>>>=20 >>>>>> 11.0-RC1 was superseded by 11.0-REL, so while that message is a = bit >>>>>> drastic, there's a point to it. >>>>>=20 >>>>> With that argument only the latest version would be supported. >>>>=20 >>>> https://www.freebsd.org/releases/ lists the supported releases. >>>> There are no release candidates listed. >>>>=20 >>>>> That said, it is a release candidate and as such one could argue = that >>>>> there never had been any official support at all. >>>>> In that case however the message is wrong, because when a support = has >>>>> ended it implies that there was support. >>>>>=20 >>>>> The check in the code is this one: >>>>> .if (${OPSYS} =3D=3D FreeBSD && (${OSVERSION} < 1003000 || = (${OSVERSION} >=3D 1100000 && ${OSVERSION} < 1100122))) || \ >>>>> (${OPSYS} =3D=3D DragonFly && ${DFLYVERSION} < 400400) >>>>>=20 >>>>> It is not about RC as such, it is explicitly about 11.0-RC. >>>>> My OSVERSION is 1100121. >>>>> So obviously support starts with the first release. >>>>> Fair enough, but then the message is still wrong unless it was = supported. >>>>=20 >>>> What's stopping you from upgrading to -REL ? >>>=20 >>> Buildworld on a raspberry isn't fun - if it works at all. >>> Even if you crossbuild and just copy the binaries, the wear of >>> MicroSD cards isn't something you want to test unless you really >>> have to. >>=20 >> most of the time this works for me: >> mount host:/export-to-rpi/local /usr/local >> echo ???WRKDIRPREFIX=3D/var/tmp??? >> /etc/make.conf >> mount via nfs /var/tmp, i.e. >> mount host:/export-to-rpi/tmp /var/tmp >> also add swap via nfs: >> mount host:/export-to-rpi/swap /mnt-swap >> swapon /mnt-swap >=20 > This has nothing to do with updating the OS itself. somehow the subject was =E2=80=98compiling ports=E2=80=99 to build the = os I cross compile and that works fine. >=20 > That said, I assume host:/export-to-rpi/local is only used by a > single host. no, if you take care, we have been sharing /usr/local since way back. btw, it=E2=80=99s read only for the clients. > It gets tricky with shared /usr/local, since the package registration > is in a different path and ports/packages may also touch /etc - e.g. > /etc/shells, or add service users for a specific software. > It is possible to do, but unless you are very carefull things can > easily get messy. the ports compilation keep things in /var/db, and that tends to cause = problems with pkg - since it insists in locking the sqlite db, so I see that on = the SD, and copy it to more secure location when I=E2=80=99m done (I keep losing track of = those small sd cards, there is hardly any place to put a label on them :-) > Same goes for /tmp. > Needless to say that swap isn't to be shared at all=E2=80=A6 that would certainly be foolish :-) > But I'm not sure if swap on NFS is completely deadlock free. so far It=E2=80=99s been just fine, e.g., compiling pkg takes up a lot = of resources and this was the only way it worked, not to mention gcc. I compiled all of the X11!=20 >=20 > --=20 > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Jan 25 14:53:38 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 D3BFCCC186B for ; Wed, 25 Jan 2017 14:53:38 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 8AB96260; Wed, 25 Jan 2017 14:53:38 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id j126so55088676qkf.1; Wed, 25 Jan 2017 06:53:38 -0800 (PST) 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=xgI8g3SR8EGSoAND2Ogc5w/j+eTp4TjuJeK2S3VY1Z8=; b=E/DCgMXxuJ4zgtxmiXgGnGa1RtF5YR+KIFwhKcVMsA6KK5xlSQPkrRk1NC+1TBlSID 82wXgCdXYxCbGfoBE8oijDlNZWvKU0XysMCleJwGTGzMhSNIO4/jliJGXgDDe73etYb9 71CtgD0M/gk6Na4OeLbq3MdB4/RVI2Rc78UigdCCclXacRyt1CsLa9LSNtbcKK2d8i/r lSfzL1PROTwHrL2xrNSNWKDnl3vQZmyjhMUo58g5p8KKUmr3y6dynkQ/PJpkWYak3lR9 aGs8xjcuSycMf1fxIrlBWER4eLkfByT6isTsKV1gthwrSCSeSDqIsq+BG18zoVKOfnPk 2khQ== 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=xgI8g3SR8EGSoAND2Ogc5w/j+eTp4TjuJeK2S3VY1Z8=; b=WGqU25DkPwCc7OVknKzQIr5j/sNAR6p38iC42fgdxYVHhdU48/g8tyBClWabMAGpL0 Z4jhp89MywhW6vq3sYSPl/nr9akt1miwFwyCeKIcVxBcmbaIHrkL3R8S1yF60lqNqH3Y 4Yklk3oCVDL330XnqeuZD0ihkqkXOuOfr3dN8qbSQFAbm8jYv1fld1IsB4Yj0gyPTLSB HiwCGE3Lo9ITS2Zc66T1SOKNJzpKW+GXca3UnVd8aV1o+CKs3PlLf6cOivofIER36S/u xbD87C7C4wzK3Fkuf3TnKUqF9hN+9iL5tfzIRA8lgBPQAzv1gmayeo8CJDtJmHev+IDG sxSg== X-Gm-Message-State: AIkVDXLd1XQYE+hHCzQVghrCtVuq9gwgJgEK8yp+6rGuOTYvWbIeZ57NQVJVOfOa2nXxui4biKTSxnU8ykpjVw== X-Received: by 10.55.121.134 with SMTP id u128mr36093025qkc.12.1485356017659; Wed, 25 Jan 2017 06:53:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.177.18 with HTTP; Wed, 25 Jan 2017 06:53:37 -0800 (PST) In-Reply-To: References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> From: Mihai Carabas Date: Wed, 25 Jan 2017 16:53:37 +0200 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Ian Lepore Cc: Emmanuel Vadot , Nicolae-Alexandru Ivan , 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: Wed, 25 Jan 2017 14:53:39 -0000 Hello again, We have some trouble with writing in memory in locore-v6.S. We added the following sequence: mov r0, 1 ldr r1, =hypmode_enabled str r0, [r1] mov r0, 123 ldr r0, [r1] cmp r0, #123 beq _C_LABEL(panic) ............ _C_LABEL(hypmode_enabled): .word 0 The problem is that the flow doesn't enter on the last beq. Full code is in https://svn.grid.pub.ro/svn/bhyve-ARM/src/sys/arm/arm/locore-v6.S Does anyone have any insight about this problem? Caches could be a problem? Thank you, Mihai On Mon, Jan 9, 2017 at 4:07 PM, Mihai Carabas wrote: > Hello everyone, > > We managed to boot the Cubie2 with a custom bootloader, but we are still > having trouble in executing "hvc" instruction (it ends up with undefined > instruction in kernel). At this point I think is an SMP related issue. The > bhyvearm code was only tested on an emulated platform with one core. For > SMP there is still work that need to be done. We tried to disable the SMP > for Cubie2 but without luck. > We disabled the following options > options SMP > options PLATFORM_SMP > > But is still compiling with SMP. Do you have any insights for this? > > Thank you, > Mihai > > On Thu, Dec 15, 2016 at 6:03 PM, Ian Lepore wrote: > >> On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: >> > On Thu, 15 Dec 2016 14:26:48 +0200 >> > Nicolae-Alexandru Ivan wrote: >> > >> > > >> > > > >> > > > For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 >> > > > import >> > > > (well only ubldr.bin for me ...) >> > > > For 3 and 4 I've never tested booting kernel directly, I'll try >> > > > that. >> > > > Does your kernel have a static dtb compiled in ? >> > > Yes, we included the device tree in the kernel binary. >> > > The options below are included in our conf. >> > > >> > > #FDT >> > > options FDT >> > > options FDT_DTB_STATIC >> > > makeoptions FDT_DTS_FILE=cubieboard2.dts >> > Oh I might now, my patches introduce a FreeBSD option for uboot that >> > disable the dcache while it's strictly disable in the ports. >> > Do a gmake menuconfig in uboot before compiling but after gmake >> > cubieboard2_defconfig to enable this. >> > >> >> It shouldn't be necessary to disable dcache, but it does need to be >> flushed before launching ubldr or the kernel; especially, it needs the >> icache sync'd. The stock uboot does the needed cache work only in the >> path that launches linux that has been packaged as an image file (and >> before launching vxworks I think). For freebsd the needed cache ops >> must be patched into two places, the bootelf path and the go path. >> >> -- Ian >> >> _______________________________________________ >> 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 Wed Jan 25 15:16: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 61B2ECC1E70 for ; Wed, 25 Jan 2017 15:16:44 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EFEDFCB for ; Wed, 25 Jan 2017 15:16:44 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 3B9D41B6; Wed, 25 Jan 2017 10:16:37 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-RC1 unsupported by ports? From: Paul Mather In-Reply-To: Date: Wed, 25 Jan 2017 10:16:36 -0500 Cc: Bernd Walter , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170125042413.GK85666@cicely7.cicely.de> <20170125062045.GS13006@home.opsec.eu> <20170125075459.GL85666@cicely7.cicely.de> <20170125081318.GT13006@home.opsec.eu> <20170125084738.GM85666@cicely7.cicely.de> To: Ralf Wenk X-Mailer: Apple Mail (2.3124) 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, 25 Jan 2017 15:16:44 -0000 On Jan 25, 2017, at 5:27 AM, Ralf Wenk wrote: > On Wed, 25 Jan 2017 09:47:39 +0100, Bernd Walter wrote: >> Buildworld on a raspberry isn't fun - if it works at all. >> Even if you crossbuild and just copy the binaries, the wear of >> MicroSD cards isn't something you want to test unless you really >> have to. >=20 > Just for the records: It works and takes about 4.5 days on a raspberry = B > using an USB stick. The last stick survived almost 7 month with > approximately two buildworld a month. > In my experience using NFS was slower. I did not try buildworld on a = SD > card. FWIW, it takes my Raspberry Pi 2 Model B about 15 hours to complete a = fresh buildworld with /usr/src and /usr/obj mounted via NFS. (Times = will vary for subsequent builds when WITH_META_MODE is set.) I've successfully completed {build,install}{world,kernel} on a SD card, = too. My standard method, though, is to cross-build on another system = and then upgrade via pkg. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Wed Jan 25 20:27:30 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 1B196CC1A22 for ; Wed, 25 Jan 2017 20:27:30 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 EE94B1652 for ; Wed, 25 Jan 2017 20:27:29 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-248-244.albq.qwest.net [67.0.248.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 738C61928BA for ; Wed, 25 Jan 2017 20:27:28 +0000 (UTC) Subject: Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes To: freebsd-arm@freebsd.org References: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> From: Sean Bruno Message-ID: <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> Date: Wed, 25 Jan 2017 13:27:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f" 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, 25 Jan 2017 20:27:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f Content-Type: multipart/mixed; boundary="9jrvaednJqI38xx228eR02VkUCXWhQdOo"; protected-headers="v1" From: Sean Bruno To: freebsd-arm@freebsd.org Message-ID: <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> Subject: Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes References: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> In-Reply-To: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> --9jrvaednJqI38xx228eR02VkUCXWhQdOo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mark: There was a recent update this week that was submitted and accepted to qemu-user-static. Want to give it a spin again and see if you are able to make progress? sean "top poster for maximum effect" bruno On 01/15/17 07:09, Mark Millard wrote: > On 2017-Jan-14, at 10:53 PM, Mark Millard wrot= e: >=20 >> [Context: head (12) -r312009 and ports head -r431413.] >> >> I've been experimenting on amd64 with poudriere-devel with -x >> for -a arm.armv6 and I ran into: >> >>> TCG temporary leak before 00021826 >>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >> >> in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 >> attempted. The 00021826 is the same number in all the examples >> so far (whatever its base). >> >> These seem to be the only TCG messages and each failure starts with >> one and then reports the qemu message. (Also true for the below.) >> As far as I can tell the TCG notice is the report of an internal >> qemu problem that is then translated into an Illegal instruction. >> >> This was with ALLOW_MAKE_JOBS=3Dyes but -J 1 for poudriere. >> >> For 2 of the problem ports retries worked, still using >> ALLOW_MAKE_JOBS=3Dyes and -J 1 . >> >> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=3Dyes >> --but in a different step each time. >> >> In all failure cases it was gmake that got the "illegal instruction". >> >> But disabling ALLOW_MAKE_JOBS=3Dyes appears (so far) to avoid the >> issue. For example, that 3rd failing port built fine. (I've >> been doing more ports since, with ALLOW_MAKE_JOBS=3Dyes repeatedly >> failing and lack of it working.) >> >> My guess is SIGCHLD delivery sometimes touches something (or a timing)= >> that is not handled well in qemu-arm-static. I've had not problems >> on an rpi2 or bpim3 in the past. >> >> (I have seen some analogous "soemtimes" issues on powerpc under >> and version of lang that mishandled the stack part of the ABI >> FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time >> for the messed up code generation, leading to stack corruption. Code >> not getting signals had no problems.) >> >> Note: The amd64 context is FreeBSD under VirtualBox under macOS >> and it has had no problem for native builds of world, kernel, >> or ports. >=20 > Avoiding ALLOW_MAKE_JOBS=3Dyes is not sufficient to guarantee builds > will work. Here is one that got near the end before failing the > same way: >=20 > . . . > install -m 0644 /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3= =2E0/gcc/cp/type-utils.h /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/= stage/usr/local/lib/gcc/arm-none-eabi/6.3.0/plugin/include/cp/type-utils.= h > install: DONTSTRIP set - will not strip installed binaries > TCG temporary leak before 00021826 > qemu: uncaught target signal 4 (Illegal instruction) - core dumped > gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction > gmake[1]: Leaving directory '/wrkdirs/usr/ports/devel/arm-none-eabi-gcc= /work/.build' > *** Error code 2 >=20 > Stop. > make: stopped in /usr/ports/devel/arm-none-eabi-gcc > =3D=3D=3D=3D>> Cleaning up wrkdir > =3D=3D=3D> Cleaning for arm-none-eabi-gcc-6.3.0 > build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST 2017 > build time: 02:52:28 > !!! build failure encountered !!! >=20 >=20 > Going back to the earlier initial problem (that I happen to have the > material for handy): expanding the .tbz of the failed build and finding= > the core showed: >=20 > # find . -name "*.core" -exec file {} \; = = = ./work/binutils-2.27/ld/qemu_g= make.core: ELF 32-bit LSB core file ARM, version 1 (FreeBSD), FreeBSD-sty= le, from 'ke' >=20 > [I've not figured out what I can do with that --or how.] >=20 >=20 > One thing unusual on my part is that I use -mcpu=3Dcortex-a7 . That > matches how I historically buildworld buildkernel for installation > on the rpi2 and bpim3. I've never had problems like this with > builds on the rpi2 or the bpim3 (buildworld, buildkernel, port > builds). It might be that qemu-arm-static has a problem with > -mcpu=3Dcortex-a7 code that is generated --but not always. >=20 > Using the make.conf as an example: >=20 > # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf > WANT_QT_VERBOSE_CONFIGURE=3D1 > # > DEFAULT_VERSIONS+=3Dperl5=3D5.24 > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > MALLOC_PRODUCTION=3D > # > #system clang 3.8+ (gcc6 rejects -march=3Darmv7a): > #CFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > #CXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > #CPPFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # > #lang/gcc6's xgcc stage considers the above conflicting so use just: > CFLAGS+=3D -mcpu=3Dcortex-a7 > CXXFLAGS+=3D -mcpu=3Dcortex-a7 > CPPFLAGS+=3D -mcpu=3Dcortex-a7 >=20 >=20 > For my context poudriere with -x for -a arm.armv6 and the use of > qemu-arm-static does not look reliable enough to depend on. It is > not obvious that the -x use contributes to the problem: it may well > not. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 --9jrvaednJqI38xx228eR02VkUCXWhQdOo-- --iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAliJCi1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y fmSaJQf/f22OiPSKJZz84kuwRC192MdBh96yAS6RKLUvGBFxnpPEY131Jjcl3++q lakNHiJigrH/2zdDpVaeUtnd4Wui3Zo5c5D5HB8vRgPCo9iXVkACleR202JmpSnV Wn/mY69zhXsRnJySROzOh1cuFw57ZEzCovNvZXp7I1qVX+wchDhqzgvJUPNobknr NUEyPaL3x5NY5+oFKjICTL2D4L2jvg3Ovv2h9YqOF2Lfl3O54dtnffQMrvWSXpU2 sjx4yCZxpdEEAkQC9cm5IF7OFzBdvInXiBOxDRR0JstlC8Wqe6eKZeWyePcRcvBs 2ei4jKnbYxEKvZCHuuyUynEvjpwmOw== =cDyU -----END PGP SIGNATURE----- --iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f-- From owner-freebsd-arm@freebsd.org Wed Jan 25 22:13: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 02930CC1DB5 for ; Wed, 25 Jan 2017 22:13:58 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 CFF6C1185 for ; Wed, 25 Jan 2017 22:13:58 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cWVp9-000O5s-QI; Wed, 25 Jan 2017 14:13:52 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0PMDogc092619; Wed, 25 Jan 2017 14:13:50 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Wed, 25 Jan 2017 14:13:50 -0800 From: Oleksandr Tymoshenko To: =?iso-8859-1?Q?Otac=EDlio?= Cc: "freebsd-arm@freebsd.org" Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black Message-ID: <20170125221350.GA92571@bluezbox.com> References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Otacílio (otacilio.neto@bsd.com.br) wrote: > Dears > > I'm trying boot a FreeBSD12-armv6-r312227 > (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > downloaded from > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > works fine, but when I try boot the image that I build on my machine > using crouchet I get: > > U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > Trying to boot from MMC1MMC partition switch failed > *** Warning - MMC partition switch failed, using default environment > > reading u-boot.img > reading u-boot.img > > And boot stops. Someone can confirm that the revision 312227 is working > fine? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bsd.com.br] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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, 25 Jan 2017 22:13:59 -0000 Otacílio (otacilio.neto@bsd.com.br) wrote: > Dears > > I'm trying boot a FreeBSD12-armv6-r312227 > (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > downloaded from > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > works fine, but when I try boot the image that I build on my machine > using crouchet I get: > > U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > Trying to boot from MMC1MMC partition switch failed > *** Warning - MMC partition switch failed, using default environment > > reading u-boot.img > reading u-boot.img > > And boot stops. Someone can confirm that the revision 312227 is working > fine? I did some digging at the breakage is caused by this commit in U-Boot: https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes the problem. Try applying this patch to crochet and re-build image: https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff -- gonzo From owner-freebsd-arm@freebsd.org Thu Jan 26 00:54: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 27021CBEAD0 for ; Thu, 26 Jan 2017 00:54:53 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB08279F for ; Thu, 26 Jan 2017 00:54:52 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:To:From; bh=0f4h5ofZuVZCFcpW7zYlwKM9IIZwZYI07+CAEQai/Rw=; b=ArAGMS8+X4y/5xdwjg3IlstKmN2WlC90D7xkacNwINdlPwRKuMPzc1zfdOCXqxEEY+HVm5j5+PXKQaUy03z9JOJc8cGP8hvplqB+NAGJUIEw4jizUgIfXbUTFEptJtNZHXW2yTrBujzY7SuR3askoKvhDmkqp/Euug0/Hzf7Doax8qgP; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cWYKr-000FQN-OK for freebsd-arm@freebsd.org; Wed, 25 Jan 2017 16:54:51 -0800 From: "Tony Hain" To: Date: Wed, 25 Jan 2017 16:54:48 -0800 Message-ID: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJ3YXBFiq1xMhQzQ1G3SmFfYn+hWQ== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Thu, 26 Jan 2017 00:54:53 -0000 Hi, First, thanks to all that have worked on getting FreeBSD on ARM. I tried it on a Rpi B awhile back, and gave up due to lack of time to work it through. I now have 11 running on a BBB with poudriere/Qemu cross-compiled ports, and also built NTPsec for it. The problem is figuring out the DTS mess. I am not getting the PPS signal on P8-7 as per Ian's note about /dev/dmtpps: https://lists.freebsd.org/pipermail/freebsd-arm/2015-August/012077.html I seriously suspect that is due to the default DTS, as gpioctl -lv only shows pins 0-31, and the scope shows P8-7 is pulling the signal to ground when I plug into the pin, suggesting it is in output mode. While the thread at: https://forums.freebsd.org/threads/56920/ suggests there is a way to expand to the full set of gpio pins, I couldn't figure out how from the references there. I would guess there needs to be another pinmux@ besides the one @800, but there is nothing I can find that suggests what that should be. I tried to use Gonzo's Overlay method referenced at: https://kernelnomicon.org/?p=498 but the dtc version in /usr/bin doesn't support the -@ option to deal with unreferenced variables as suggested by Adafruit and Rpi sites for Linux builds. I don't see dtc in the ports tree, so short of chasing down the current linux version and trying to port that, I am stuck with embedding everything in the primary dts. I figured it would be simpler to start debugging with the serial port first since there was an example for the working console port. My original intent was to use uart5 since it was also on P8, but given gpioctl is only listing the first 32 I switched to uart1 (P9-26). Simply changing the "disabled" to "okay" for the uart was sufficient to make it show up as /dev/ttyu1, but not enough to make it work. Taking hints from various dts files for uart1, I have: uart1_pins: pinmux_uart1_pins { pinctrl-single,pins = <0x180 0x020 0x184 0x0>; linux,phandle = <0x1>; phandle = <0x1>; }; ... serial@48022000 { compatible = "ti,am3352-uart", "ti,omap3-uart"; ti,hwmods = "uart2"; clock-frequency = <0x2dc6c00>; reg = <0x48022000 0x2000>; interrupts = <0x49>; // status = "disabled"; status = "okay"; dmas = <0x29 0x1c 0x0 0x29 0x1d 0x0>; dma-names = "tx", "rx"; pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>; }; I am getting a duplication error for the phandle lines. I realize the existing devices have unique hex values for those, but the only references search is turning up and downloadable dtb files I can find have the phandle for that uart as 0x1. Is there a reason that all the uarts are not listed with the correct values & commented out in the default DTS? In addition, uart4 & 5 don't have the dma lines that the others have ... and those lines don't appear in the reference linux dts files so I can't tell what they are for. Comments in the dts hinting at where to look for references for other values would make it easier to clone a working device for another one. Is there a plan to have a wiki for the dts/dtb/dtbo mechanism as implemented for FreeBSD? Finally, adding beaglebone-green to my dts will be simple enough when I get ready to put FreeBSD on that, but that should be part of the stock dts since the hdmi itself is already marked as disabled in this dts, and removal of that hardware is the primary difference between black & green as I understand it. Tony From owner-freebsd-arm@freebsd.org Thu Jan 26 03:21: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 104F8CC255D for ; Thu, 26 Jan 2017 03:21:56 +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 EA8F0BB0 for ; Thu, 26 Jan 2017 03:21:55 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a572c769-e376-11e6-8c8a-112185c90658 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 a572c769-e376-11e6-8c8a-112185c90658; Thu, 26 Jan 2017 03:22:20 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0Q3LkT6002411; Wed, 25 Jan 2017 20:21:46 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485400906.30533.54.camel@freebsd.org> Subject: Re: BBB uarts & pps dts definitions From: Ian Lepore To: Tony Hain , freebsd-arm@freebsd.org Date: Wed, 25 Jan 2017 20:21:46 -0700 In-Reply-To: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> 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: Thu, 26 Jan 2017 03:21:56 -0000 On Wed, 2017-01-25 at 16:54 -0800, Tony Hain wrote: > Hi, > > First, thanks to all that have worked on getting FreeBSD on ARM. I tried it > on a Rpi B awhile back, and gave up due to lack of time to work it through. > I now have 11 running on a BBB with poudriere/Qemu cross-compiled ports, and > also built NTPsec for it. The problem is figuring out the DTS mess. > > I am not getting the PPS signal on P8-7 as per Ian's note about /dev/dmtpps: > https://lists.freebsd.org/pipermail/freebsd-arm/2015-August/012077.html  > I seriously suspect that is due to the default DTS, as gpioctl -lv only > shows pins 0-31, and the scope shows P8-7 is pulling the signal to ground > when I plug into the pin, suggesting it is in output mode.  > While the thread at: > https://forums.freebsd.org/threads/56920/ > suggests there is a way to expand to the full set of gpio pins, I couldn't > figure out how from the references there.  I would guess there needs to be > another pinmux@ besides the one @800, but there is nothing I can find that > suggests what that should be. > > I tried to use Gonzo's Overlay method referenced at: > https://kernelnomicon.org/?p=498 > but the dtc version in /usr/bin doesn't support the -@ option to deal with > unreferenced variables as suggested by Adafruit and Rpi sites for Linux > builds. I don't see dtc in the ports tree, so short of chasing down the > current linux version and trying to port that, I am stuck with embedding > everything in the primary dts. > > I figured it would be simpler to start debugging with the serial port first > since there was an example for the working console port. My original intent > was to use uart5 since it was also on P8, but given gpioctl is only listing > the first 32 I switched to uart1  (P9-26). Simply changing the "disabled" to > "okay" for the uart was sufficient to make it show up as /dev/ttyu1, but not > enough to make it work. Taking hints from various dts files for uart1, I > have: >       uart1_pins:  pinmux_uart1_pins { >                 pinctrl-single,pins = <0x180 0x020 0x184 0x0>; >                  linux,phandle = <0x1>; >                  phandle = <0x1>; >         }; > ... >                 serial@48022000 { >                         compatible = "ti,am3352-uart", "ti,omap3-uart"; >                         ti,hwmods = "uart2"; >                         clock-frequency = <0x2dc6c00>; >                         reg = <0x48022000 0x2000>; >                         interrupts = <0x49>; > //                    status = "disabled"; >                         status = "okay"; >                         dmas = <0x29 0x1c 0x0 0x29 0x1d 0x0>; >                         dma-names = "tx", "rx"; > >                         pinctrl-names = "default"; >                         pinctrl-0 = <&uart1_pins>; >                 }; > I am getting a duplication error for the phandle lines. I realize the > existing devices have unique hex values for those, but the only references > search is turning up and downloadable dtb files I can find have the phandle > for that uart as 0x1. Is there a reason that all the uarts are not listed > with the correct values & commented out in the default DTS? In addition, > uart4 & 5 don't have the dma lines that the others have ...  and those lines > don't appear in the reference linux dts files so I can't tell what they are > for. Comments in the dts hinting at where to look for references for other > values would make it easier to clone a working device for another one.  > > Is there a plan to have a wiki for the dts/dtb/dtbo mechanism as implemented > for FreeBSD?  > > Finally, adding beaglebone-green to my dts will be simple enough when I get > ready to put FreeBSD on that, but that should be part of the stock dts since > the hdmi itself is already marked as disabled in this dts, and removal of > that hardware is the primary difference between black & green as I > understand it.  > > Tony When I first read this I figured some change over the past few months must have broken the driver.  But I just built a fresh world and kernel for beaglebone and fired up my BB and hooked a PPS signal to P8-7 and it all still works fine. You don't need to do anything with the dts, the dmtpps driver will reconfigure the pin to be a PPS input, overriding whatever the FDT data might have set up.  All you need to do is set a couple lines in /boot/loader.conf:   hw.am335x_dmtpps.input="P8-7"   am335x_dmtpps_load=YES You can even do it all interactively without any config, even just booting from a downloaded weekly snapshot, then do this:   kenv hw.am335x_dmtpps.input="p8-7"   kldload am335x_dmtpps You should see something like this (some of this is extra bootverbose output, so you may not see all these lines)...   root@bb:~ # kldload am335x_dmtpps   ti_pinmux0: setting internal 2a for timer4   am335x_dmtpps: configured pin p8-7 as input for timer4   am335x_dmtpps0: mem 0x48044000- 0x480443ff irq 30 on simplebus0   Timecounter "DMTimer4" frequency 24000000 Hz quality 1000   am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps If you have full source code on the BB, do:   cd /usr/src/tools/test/ppsapi   make ppsapitest   ./ppsapitest /dev/dmtpps You should get something like:   1485400775 .009578536 204 0 .000000000 0   1485400776 .009621995 205 0 .000000000 0   1485400777 .009665453 206 0 .000000000 0   1485400778 .009708869 207 0 .000000000 0 -- Ian From owner-freebsd-arm@freebsd.org Thu Jan 26 03:29:58 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 87FF9CC287B for ; Thu, 26 Jan 2017 03:29:58 +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 25179EC0 for ; Thu, 26 Jan 2017 03:29:57 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b52faeff-e377-11e6-9357-bffcd86bd944 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 b52faeff-e377-11e6-9357-bffcd86bd944; Thu, 26 Jan 2017 03:29:57 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0Q3TjiY002419; Wed, 25 Jan 2017 20:29:45 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485401385.30533.59.camel@freebsd.org> Subject: Re: BBB uarts & pps dts definitions From: Ian Lepore To: Tony Hain , freebsd-arm@freebsd.org Date: Wed, 25 Jan 2017 20:29:45 -0700 In-Reply-To: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> Content-Type: multipart/mixed; boundary="=-rrWnCRfX9mAl0WmUVWjm" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port 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: Thu, 26 Jan 2017 03:29:58 -0000 --=-rrWnCRfX9mAl0WmUVWjm Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Wed, 2017-01-25 at 16:54 -0800, Tony Hain wrote: > Hi, > > [...] > > I figured it would be simpler to start debugging with the serial port first > since there was an example for the working console port. My original intent > was to use uart5 since it was also on P8, but given gpioctl is only listing > the first 32 I switched to uart1  (P9-26). Simply changing the "disabled" to > "okay" for the uart was sufficient to make it show up as /dev/ttyu1, but not > enough to make it work. Taking hints from various dts files for uart1, I > have: >       uart1_pins:  pinmux_uart1_pins { >                 pinctrl-single,pins = <0x180 0x020 0x184 0x0>; >                  linux,phandle = <0x1>; >                  phandle = <0x1>; >         }; > ... >                 serial@48022000 { >                         compatible = "ti,am3352-uart", "ti,omap3-uart"; >                         ti,hwmods = "uart2"; >                         clock-frequency = <0x2dc6c00>; >                         reg = <0x48022000 0x2000>; >                         interrupts = <0x49>; > //                    status = "disabled"; >                         status = "okay"; >                         dmas = <0x29 0x1c 0x0 0x29 0x1d 0x0>; >                         dma-names = "tx", "rx"; > >                         pinctrl-names = "default"; >                         pinctrl-0 = <&uart1_pins>; >                 }; > I am getting a duplication error for the phandle lines. I realize the > existing devices have unique hex values for those, but the only references > search is turning up and downloadable dtb files I can find have the phandle > for that uart as 0x1. Is there a reason that all the uarts are not listed > with the correct values & commented out in the default DTS? In addition, > uart4 & 5 don't have the dma lines that the others have ...  and those lines > don't appear in the reference linux dts files so I can't tell what they are > for. Comments in the dts hinting at where to look for references for other > values would make it easier to clone a working device for another one.  > I don't know anything about the dts overlay stuff, I haven't had time to learn about it yet. Back when I was first working on the dmtpps driver, before I made it configure the timer input pin for itself, I was just modifying the main dts source in sys/gnu/dts/arm/am335x-boneblack.dts to enable uart1 and timer4 for testing.  I'll attach the patch I used to enable them and configure the pins. -- Ian --=-rrWnCRfX9mAl0WmUVWjm Content-Disposition: inline; filename="am335x-boneblack.dts_uart1_timer4.diff" Content-Type: text/x-patch; name="am335x-boneblack.dts_uart1_timer4.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/gnu/dts/arm/am335x-boneblack.dts =================================================================== --- sys/gnu/dts/arm/am335x-boneblack.dts (revision 312786) +++ sys/gnu/dts/arm/am335x-boneblack.dts (working copy) @@ -64,8 +64,33 @@ AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr0 */ >; }; + uart1_pins: uart1_pins { + pinctrl-single,pins = < + AM33XX_IOPAD(0x978, PIN_INPUT | MUX_MODE0) /* cts */ + AM33XX_IOPAD(0x97C, PIN_OUTPUT | MUX_MODE0) /* rts */ + AM33XX_IOPAD(0x980, PIN_INPUT_PULLUP | MUX_MODE0) /* rxd */ + AM33XX_IOPAD(0x984, PIN_OUTPUT | MUX_MODE0) /* txd */ + >; + }; + timer4_pins: timer4_pins { + pinctrl-single,pins = < + AM33XX_IOPAD(0x890, (PIN_INPUT | MUX_MODE2)) /* timer4 */ + >; + }; }; +&uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&uart1_pins>; + status = "okay"; +}; + +&timer4 { + pinctrl-names = "default"; + pinctrl-0 = <&timer4_pins>; + status = "okay"; +}; + &lcdc { status = "okay"; port { --=-rrWnCRfX9mAl0WmUVWjm-- From owner-freebsd-arm@freebsd.org Thu Jan 26 04:26:19 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 B48E9CC2109 for ; Thu, 26 Jan 2017 04:26:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-17.reflexion.net [208.70.210.17]) (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 796B7F1C for ; Thu, 26 Jan 2017 04:26:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 378 invoked from network); 26 Jan 2017 04:26:42 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Jan 2017 04:26:42 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 25 Jan 2017 23:26:12 -0500 (EST) Received: (qmail 28096 invoked from network); 26 Jan 2017 04:26:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jan 2017 04:26:12 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 7FC2FEC8BF3; Wed, 25 Jan 2017 20:26:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes From: Mark Millard In-Reply-To: <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> Date: Wed, 25 Jan 2017 20:26:10 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4399212D-B4DD-460F-AD1B-9250FB412B38@dsl-only.net> References: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> To: Sean Bruno 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: Thu, 26 Jan 2017 04:26:19 -0000 On 2017-Jan-25, at 12:27 PM, Sean Bruno wrote: > Mark: >=20 > There was a recent update this week that was submitted and accepted to > qemu-user-static. >=20 > Want to give it a spin again and see if you are able to make progress? >=20 > sean "top poster for maximum effect" bruno I updated my /usr/ports to -r432460 (from today) and rebuilt. I the tried doing some poudriere -x -a arm.armv6 port builds again, with ALLOW_MAKE_JOBS=3Dyes and -J 1 in use. Unfortunately the qemu-user-static update did not fix the problem I've been seeing. An example extracted from a print/texinfo log still shows "TCG temporary leak before 00021826": . . . rm -f sys/types.h-t sys/types.h && \ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ sed -e 's|@''GUARD_PREFIX''@|GL|g' \ -e 's|@''INCLUDE_NEXT''@|include_next|g' \ -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ -e 's|@''PRAGMA_COLUMNS''@||g' \ -e 's|@''NEXT_SYS_TYPES_H''@||g' \ -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ < ./sys_types.in.h; \ } > sys/types.h-t && \ mv sys/types.h-t sys/types.h TCG temporary leak before 00021826 qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction gmake[2]: *** [Makefile:1174: all-recursive] Error 1 gmake[2]: Leaving directory = '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' gmake[1]: *** [Makefile:1113: all] Error 2 gmake[1]: Leaving directory = '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/print/texinfo =3D=3D=3D=3D>> Cleaning up wrkdir =3D=3D=3D> Cleaning for texinfo-6.1.20160425,1 build of print/texinfo ended at Wed Jan 25 20:08:32 PST 2017 build time: 00:06:57 !!! build failure encountered !!! =3D=3D=3D Mark Millard markmi at dsl-only.net On 01/15/17 07:09, Mark Millard wrote: > On 2017-Jan-14, at 10:53 PM, Mark Millard = wrote: >=20 >> [Context: head (12) -r312009 and ports head -r431413.] >>=20 >> I've been experimenting on amd64 with poudriere-devel with -x >> for -a arm.armv6 and I ran into: >>=20 >>> TCG temporary leak before 00021826 >>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >>=20 >> in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 >> attempted. The 00021826 is the same number in all the examples >> so far (whatever its base). >>=20 >> These seem to be the only TCG messages and each failure starts with >> one and then reports the qemu message. (Also true for the below.) >> As far as I can tell the TCG notice is the report of an internal >> qemu problem that is then translated into an Illegal instruction. >>=20 >> This was with ALLOW_MAKE_JOBS=3Dyes but -J 1 for poudriere. >>=20 >> For 2 of the problem ports retries worked, still using >> ALLOW_MAKE_JOBS=3Dyes and -J 1 . >>=20 >> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=3Dyes >> --but in a different step each time. >>=20 >> In all failure cases it was gmake that got the "illegal instruction". >>=20 >> But disabling ALLOW_MAKE_JOBS=3Dyes appears (so far) to avoid the >> issue. For example, that 3rd failing port built fine. (I've >> been doing more ports since, with ALLOW_MAKE_JOBS=3Dyes repeatedly >> failing and lack of it working.) >>=20 >> My guess is SIGCHLD delivery sometimes touches something (or a = timing) >> that is not handled well in qemu-arm-static. I've had not problems >> on an rpi2 or bpim3 in the past. >>=20 >> (I have seen some analogous "soemtimes" issues on powerpc under >> and version of lang that mishandled the stack part of the ABI >> FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time >> for the messed up code generation, leading to stack corruption. Code >> not getting signals had no problems.) >>=20 >> Note: The amd64 context is FreeBSD under VirtualBox under macOS >> and it has had no problem for native builds of world, kernel, >> or ports. >=20 > Avoiding ALLOW_MAKE_JOBS=3Dyes is not sufficient to guarantee builds > will work. Here is one that got near the end before failing the > same way: >=20 > . . . > install -m 0644 = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/cp/type-util= s.h = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/stage/usr/local/lib/gcc/ar= m-none-eabi/6.3.0/plugin/include/cp/type-utils.h > install: DONTSTRIP set - will not strip installed binaries > TCG temporary leak before 00021826 > qemu: uncaught target signal 4 (Illegal instruction) - core dumped > gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction > gmake[1]: Leaving directory = '/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/.build' > *** Error code 2 >=20 > Stop. > make: stopped in /usr/ports/devel/arm-none-eabi-gcc > =3D=3D=3D=3D>> Cleaning up wrkdir > =3D=3D=3D> Cleaning for arm-none-eabi-gcc-6.3.0 > build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST 2017 > build time: 02:52:28 > !!! build failure encountered !!! >=20 >=20 > Going back to the earlier initial problem (that I happen to have the > material for handy): expanding the .tbz of the failed build and = finding > the core showed: >=20 > # find . -name "*.core" -exec file {} \; = = = = ./work/binutils-2.27/ld/qemu_gmake.core: ELF 32-bit LSB core file ARM, = version 1 (FreeBSD), FreeBSD-style, from 'ke' >=20 > [I've not figured out what I can do with that --or how.] >=20 >=20 > One thing unusual on my part is that I use -mcpu=3Dcortex-a7 . That > matches how I historically buildworld buildkernel for installation > on the rpi2 and bpim3. I've never had problems like this with > builds on the rpi2 or the bpim3 (buildworld, buildkernel, port > builds). It might be that qemu-arm-static has a problem with > -mcpu=3Dcortex-a7 code that is generated --but not always. >=20 > Using the make.conf as an example: >=20 > # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf > WANT_QT_VERBOSE_CONFIGURE=3D1 > # > DEFAULT_VERSIONS+=3Dperl5=3D5.24 > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > MALLOC_PRODUCTION=3D > # > #system clang 3.8+ (gcc6 rejects -march=3Darmv7a): > #CFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > #CXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > #CPPFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # > #lang/gcc6's xgcc stage considers the above conflicting so use just: > CFLAGS+=3D -mcpu=3Dcortex-a7 > CXXFLAGS+=3D -mcpu=3Dcortex-a7 > CPPFLAGS+=3D -mcpu=3Dcortex-a7 >=20 >=20 > For my context poudriere with -x for -a arm.armv6 and the use of > qemu-arm-static does not look reliable enough to depend on. It is > not obvious that the -x use contributes to the problem: it may well > not. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@freebsd.org Thu Jan 26 06:27: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 C0C86CC2E65 for ; Thu, 26 Jan 2017 06:27:44 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CF78A1C; Thu, 26 Jan 2017 06:27:44 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=mDdjJHCcHkbv/dyEx6I85Yz5Qsr5nsJxGzg4JszLx+I=; b=AwxbGX+BYKHL//oM2fnrh3BUtBWGpusUUr5mWO0P57evnbJ06EiivBapoRxpJ/EMOHElnJMdz0Eg0DWr/8dCrmNS5zVcseQ/Po0jAbKSXlcLdK9MCxgZjjTZdHPi9Xj0rOm9z2pCLpBqNSlzITTfrPYrLjLWDy0OYtqK7ib0FfvlrpOG; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cWdWq-000L71-Dx; Wed, 25 Jan 2017 22:27:43 -0800 From: "Tony Hain" To: "'Ian Lepore'" , References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> In-Reply-To: <1485400906.30533.54.camel@freebsd.org> Date: Wed, 25 Jan 2017 22:27:30 -0800 Message-ID: <03bb01d2779d$45d6edd0$d184c970$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEImxvIZ6VEPYS1CTeMHuF4SjTdHgFGeuiPotPEM5A= Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Thu, 26 Jan 2017 06:27:44 -0000 Ian Lepore wrote: Thanks for the quick reply. Sorry I should have been clear about which build. FreeBSD 11.0-STABLE #0 r310359: Wed Dec 21 16:47:56 UTC 2016 I commented out the phandle lines, and uart1 is working. >=20 > When I first read this I figured some change over the past few months = must > have broken the driver. =A0But I just built a fresh world and kernel = for > beaglebone and fired up my BB and hooked a PPS signal to P8-7 and it = all still > works fine. >=20 > You don't need to do anything with the dts, the dmtpps driver will > reconfigure the pin to be a PPS input, overriding whatever the FDT = data > might have set up. =A0All you need to do is set a couple lines in > /boot/loader.conf: >=20 > =A0 hw.am335x_dmtpps.input=3D"P8-7" > =A0 am335x_dmtpps_load=3DYES I had done that: # cat /boot/loader.conf am335x_dmtpps_load=3D"YES" hw.am335x_dmtpps.input=3D"P8-7" does order matter? The device showed up: # ls -l /dev|grep dmtpps crw------- 1 root wheel 0x35 Jan 25 20:13 dmtpps lrwxr-xr-x 1 root wheel 6 Jan 25 20:13 pps0 -> dmtpps # dmesg|grep pps am335x_dmtpps0: mem 0x48044000-0x480443ff = irq 30 on simplebus0 =20 >=20 > You can even do it all interactively without any config, even just = booting from > a downloaded weekly snapshot, then do this: >=20 > =A0=A0kenv hw.am335x_dmtpps.input=3D"p8-7" > =A0 kldload am335x_dmtpps >=20 > You should see something like this (some of this is extra bootverbose output, > so you may not see all these lines)... >=20 > =A0=A0root@bb:~ # kldload am335x_dmtpps > =A0 ti_pinmux0: setting internal 2a for timer4 > =A0 am335x_dmtpps: configured pin p8-7 as input for timer4 > =A0 am335x_dmtpps0: mem 0x48044000- > 0x480443ff irq 30 on simplebus0 > =A0 Timecounter "DMTimer4" frequency 24000000 Hz quality 1000 > =A0 am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps >=20 > If you have full source code on the BB, do: Didn't really want to put full source on the BBB.=20 >=20 > =A0=A0cd /usr/src/tools/test/ppsapi > =A0 make ppsapitest I had full source on a 10.1 system, so I copied the files in that = directory and tried to make, but it is complaining about the last line needing an operator. make: "src/ppsapitest/Makefile" line 13: Need an operator make: Fatal errors encountered -- cannot continue make: stopped in src/ppsapitest # $FreeBSD: releng/10.1/tools/test/ppsapi/Makefile 264485 2014-04-15 02:17:46Z gnn $ PROG=3D ppsapitest MK_MAN=3Dno WARNS?=3D 5 .include CFLAGS+=3D-Wno-format-security test: ${PROG} ./${PROG} /dev/cuau0 Even when it gets built though, the scope shows that the signal is being pulled to ground as soon as the wire is connected to P8-7, so I don't = expect it to work. Is there a way to check the state of the gpio? I would = expect something like # gpioctl -N gpio_66 Can't find pin named "gpio_66" # gpioctl -l pin 00: 0 gpio_0<> pin 01: 0 gpio_1<> ... pin 30: 1 gpio_30 pin 31: 1 gpio_31 # How do the 3 additional pinmux controllers get enabled? > =A0 ./ppsapitest /dev/dmtpps >=20 > You should get something like: >=20 > =A0 1485400775 .009578536 204 0 .000000000 0 > =A0 1485400776 .009621995 205 0 .000000000 0 > =A0 1485400777 .009665453 206 0 .000000000 0 > =A0 1485400778 .009708869 207 0 .000000000 0 >=20 > -- Ian From owner-freebsd-arm@freebsd.org Thu Jan 26 06:53:19 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 59C22CC266B for ; Thu, 26 Jan 2017 06:53:19 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3029F17CF; Thu, 26 Jan 2017 06:53:19 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=rvHrvzjWj8pqq9j+wbCsMR1/+EWEq+sKMpwJDuPIl7M=; b=Ao8sTLvmgqA4rQpJEA8EHrVbYRvOpZDkOjH10lNWDLDzKgHFz1i+JTq55ltEdcGODWGBNPVHN647wbyCxvXiDV5+3/Ha6cFGdJ7CcdpiKoC4gPSpgTVfx5NG9qe9xUx8Fu0+ar2ywE/qirUIDk7cVh/a9yn10OHf0XWvvcEr3xFDWDgN; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cWdvk-000LZv-SA; Wed, 25 Jan 2017 22:53:18 -0800 From: "Tony Hain" To: "'Ian Lepore'" , References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485401385.30533.59.camel@freebsd.org> In-Reply-To: <1485401385.30533.59.camel@freebsd.org> Date: Wed, 25 Jan 2017 22:53:15 -0800 Message-ID: <03bc01d277a0$de6bdfd0$9b439f70$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEImxvIZ6VEPYS1CTeMHuF4SjTdHgIIM1HJos3HkBA= Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Thu, 26 Jan 2017 06:53:19 -0000 Ian Lepore wrote: > On Wed, 2017-01-25 at 16:54 -0800, Tony Hain wrote: > > Hi, > > > > [...] > > > > I figured it would be simpler to start debugging with the serial = port > > first since there was an example for the working console port. My > > original intent was to use uart5 since it was also on P8, but given > > gpioctl is only listing the first 32 I switched to = uart1=A0=A0(P9-26). > > Simply changing the "disabled" to "okay" for the uart was sufficient > > to make it show up as /dev/ttyu1, but not enough to make it work. > > Taking hints from various dts files for uart1, I > > have: > > =A0=A0=A0=A0=A0=A0uart1_pins:=A0=A0pinmux_uart1_pins { > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pinctrl-single,pins = =3D <0x180 0x020 0x184 0x0>; > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0linux,phandle =3D = <0x1>; > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0phandle =3D = <0x1>; > > =A0=A0=A0=A0=A0=A0=A0=A0}; > > ... > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0serial@48022000 { > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0c= ompatible =3D "ti,am3352-uart", > > "ti,omap3-uart"; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0t= i,hwmods =3D "uart2"; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0c= lock-frequency =3D <0x2dc6c00>; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0r= eg =3D <0x48022000 0x2000>; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0i= nterrupts =3D <0x49>; // > > status =3D "disabled"; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0s= tatus =3D "okay"; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0d= mas =3D <0x29 0x1c 0x0 0x29 0x1d 0x0>; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0d= ma-names =3D "tx", "rx"; > > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0p= inctrl-names =3D "default"; > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0p= inctrl-0 =3D <&uart1_pins>; > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}; > > I am getting a duplication error for the phandle lines. I realize = the > > existing devices have unique hex values for those, but the only > > references search is turning up and downloadable dtb files I can = find > > have the phandle for that uart as 0x1. Is there a reason that all = the > > uarts are not listed with the correct values & commented out in the > > default DTS? In addition, > > uart4 & 5 don't have the dma lines that the others have ...=A0=A0and = those > > lines don't appear in the reference linux dts files so I can't tell > > what they are for. Comments in the dts hinting at where to look for > > references for other values would make it easier to clone a working device > for another one. > > >=20 > I don't know anything about the dts overlay stuff, I haven't had time = to learn > about it yet. >=20 > Back when I was first working on the dmtpps driver, before I made it > configure the timer input pin for itself, I was just modifying the = main dts > source in=A0sys/gnu/dts/arm/am335x-boneblack.dts to enable uart1 and > timer4 for testing. =A0I'll attach the patch I used to enable them and configure > the pins. >=20 > -- Ian The diff is helpful, but clearly I am going to have to pull down full = source to get the complete definitions. This uses variable names that are not defined anywhere I can find using search, and they don't appear to be = used in the dtb distributed in /boot/dtb, but that could simply be that = backing the dtb to dts is using the resolved contents of those variables.=20 Tony From owner-freebsd-arm@freebsd.org Thu Jan 26 08:30: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 38DCDCC2DD3 for ; Thu, 26 Jan 2017 08:30:40 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C8DA64F; Thu, 26 Jan 2017 08:30:39 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=dQ3F+9H/5lcNqWVt+B0oMS5i/WQs625Pxqnl7sTXP3I=; b=AjLtwjpBYp3ZBpTzlOgRQidNfF3xZIz3bww9MdTZI0jVbYPDwOReg0cPp6KaOHTuf7j7WRVKqgoU4sCTX2F/37yNbFpGWIr9ClEk1q457bllviFlc8pVuD4kc9GwUe2P0SPs+CrN9drC7/FAooRNPscH3kRSObJGnXiyQE6QI/Azq5/S; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cWfRm-000N4i-1I; Thu, 26 Jan 2017 00:30:38 -0800 From: "Tony Hain" To: "'Ian Lepore'" , References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> In-Reply-To: <03bb01d2779d$45d6edd0$d184c970$@tndh.net> Date: Thu, 26 Jan 2017 00:30:08 -0800 Message-ID: <03c101d277ae$70f142c0$52d3c840$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEImxvIZ6VEPYS1CTeMHuF4SjTdHgFGeuiPAfagOS+ixDy7QA== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Thu, 26 Jan 2017 08:30:40 -0000 > -----Original Message----- > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd- > arm@freebsd.org] On Behalf Of Tony Hain > Sent: Wednesday, January 25, 2017 10:28 PM > To: 'Ian Lepore'; freebsd-arm@freebsd.org > Subject: RE: BBB uarts & pps dts definitions >=20 FOLLOWUP ........... > > If you have full source code on the BB, do: >=20 > Didn't really want to put full source on the BBB. >=20 > > > > =A0=A0cd /usr/src/tools/test/ppsapi > > =A0 make ppsapitest >=20 > I had full source on a 10.1 system, so I copied the files in that directory and > tried to make, but it is complaining about the last line needing an operator. >=20 > make: "src/ppsapitest/Makefile" line 13: Need an operator > make: Fatal errors encountered -- cannot continue > make: stopped in src/ppsapitest >=20 >=20 > # $FreeBSD: releng/10.1/tools/test/ppsapi/Makefile 264485 2014-04-15 > 02:17:46Z gnn $ >=20 > PROG=3D ppsapitest > MK_MAN=3Dno >=20 > WARNS?=3D 5 >=20 > .include >=20 > CFLAGS+=3D-Wno-format-security >=20 > test: ${PROG} > ./${PROG} /dev/cuau0 >=20 Removed the Makefile and it built fine. As I suspected it didn't show anything due to the pulse being squashed when connected to that pin. # ./ppsapitest -v /dev/dmtpps Supported modebits: CAPTUREASSERT OFFSETASSERT CANWAIT TSPEC ^C >=20 >=20 > Even when it gets built though, the scope shows that the signal is = being > pulled to ground as soon as the wire is connected to P8-7, so I don't expect it > to work. Is there a way to check the state of the gpio? I would expect > something like # gpioctl -N gpio_66 Can't find pin named "gpio_66" >=20 > # gpioctl -l > pin 00: 0 gpio_0<> > pin 01: 0 gpio_1<> > ... > pin 30: 1 gpio_30 > pin 31: 1 gpio_31 > # >=20 > How do the 3 additional pinmux controllers get enabled? >=20 >=20 > > =A0 ./ppsapitest /dev/dmtpps > > > > You should get something like: > > > > =A0 1485400775 .009578536 204 0 .000000000 0 > > =A0 1485400776 .009621995 205 0 .000000000 0 > > =A0 1485400777 .009665453 206 0 .000000000 0 > > =A0 1485400778 .009708869 207 0 .000000000 0 > > > > -- Ian >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Jan 26 10:10:15 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 3BDF1CC0475 for ; Thu, 26 Jan 2017 10:10:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 BDFCE2A5 for ; Thu, 26 Jan 2017 10:10:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26658 invoked from network); 26 Jan 2017 10:11:47 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Jan 2017 10:11:47 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 26 Jan 2017 05:10:07 -0500 (EST) Received: (qmail 21198 invoked from network); 26 Jan 2017 10:10:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jan 2017 10:10:07 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id DD618EC7D56; Thu, 26 Jan 2017 02:10:05 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: =mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg Message-Id: <15C25780-588B-43EF-8DAC-000C301018BE@dsl-only.net> Date: Thu, 26 Jan 2017 02:10:05 -0800 To: FreeBSD Toolchain , freebsd-arm 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: Thu, 26 Jan 2017 10:10:15 -0000 If I buildworld buildkernel for arm.armv6 with the likes of: CFLAGS+= =mcpu=cortex-a7 CXXFLAGS+= =mcpu=cortex-a7 CPPFLAGS+= =mcpu=cortex-a7 (say for targeting a bpim3 or rpi2) then what package installs for that context tends to report: Undefined symbol "__aeabi_uidiv" In other words __aeabi_uidiv is only implemented for armv6 buildworld, not if one explicitly targets armv7. (armv7 has instruction support but that does not make software built to support other processor variants that are without instruction support also work unless the routine is still provided.) Note: I normally build ports from source anyway so this is just an FYI in case the lack of __aeabi_uidiv was not deliberate. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 26 13: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 7AA71CC1922 for ; Thu, 26 Jan 2017 13:54:14 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wj0-x241.google.com (mail-wj0-x241.google.com [IPv6:2a00:1450:400c:c01::241]) (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 F386A240; Thu, 26 Jan 2017 13:54:13 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wj0-x241.google.com with SMTP id kq3so4678111wjc.3; Thu, 26 Jan 2017 05:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:references:to:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dweYhMuA3kHdqKvGb4697yXZSEiv0Dib73zAQzcvGOw=; b=KmerscTNuFRe/AKHsu8eTPvDqGDhLES9OSqz6rdv5/rzpguqzJun88fxrmAN3Gcfjd dHCIblLb2A4fwgKs/3DURhk/ozx+1+EydksU6cZ9MqEkwoFM5TxCAp9R0RnHvnDibBRQ 3/MRWS6fH4ROeD0/3MNbNainT9D1qbhGXPUqb1V48uK1FrwszwzQ6WtlJbPWBxxzPwGk xPfsewpHJg3aomRAad1SuL0+FUcSmbBtPzTLyivKVHhTeREr8L0Mm1MphmrhvnHia9zB 7v6ifaYeMu0aZflaTs7jdrr4mhF1s/pE67PUA5vwIec9YGXw9aZAbPwZjzfyVAe9LIOc gAvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:references:to:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=dweYhMuA3kHdqKvGb4697yXZSEiv0Dib73zAQzcvGOw=; b=anotj1Sf+gtbwO0IBCDX9eVgCBBm37UAGy2eeEIam6CbmvR/m++juq+tJmNDQ4CxCS UqQkHjKZWFKtEG2Io/6tO5tCRQIxZa/7wrWa2L27X9T1mUUVwbQz9P0ii13QGS4KZUDO cHGzRnkFjKW3Ksm/gaMZ6OgSiXPWkT+oCl3ELVfCxEvNyYrMeqjcBR/TznbNuFA3imcW 9gDHOjT+9uEIhZgaA+XZ11NpMkK/yCEfco7qi0c0zO0Wuj5kg49Mwj4bWccYqWuYBiXV pkJE8lYCgE3BP3J0fIbPPgzeRzqfD/vYAx21k89uDcHQeIgAjj1Evrb0GW/PZUFf5RLC y6VQ== X-Gm-Message-State: AIkVDXIHy0VTTzWKiIKi9bYXAdCJaWuYSH7BgSTzRh/e2KY1WtiEDIdsCLJIbAgZRhm4/A== X-Received: by 10.223.146.39 with SMTP id 36mr2832201wrj.85.1485438850546; Thu, 26 Jan 2017 05:54:10 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id g75sm3829755wme.5.2017.01.26.05.54.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 05:54:10 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: meloun.michal@gmail.com Subject: Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes References: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> <4399212D-B4DD-460F-AD1B-9250FB412B38@dsl-only.net> To: Mark Millard , Sean Bruno Cc: freebsd-arm@freebsd.org Message-ID: <049fd4e6-209b-4385-48ed-f3413ab27e52@gmail.com> Date: Thu, 26 Jan 2017 14:54:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4399212D-B4DD-460F-AD1B-9250FB412B38@dsl-only.net> Content-Type: text/plain; charset=windows-1252 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: Thu, 26 Jan 2017 13:54:14 -0000 On 26.01.2017 5:26, Mark Millard wrote: > On 2017-Jan-25, at 12:27 PM, Sean Bruno wrote: > >> Mark: >> >> There was a recent update this week that was submitted and accepted to >> qemu-user-static. >> >> Want to give it a spin again and see if you are able to make progress? >> >> sean "top poster for maximum effect" bruno > > I updated my /usr/ports to -r432460 (from today) and rebuilt. > I the tried doing some poudriere -x -a arm.armv6 port builds > again, with ALLOW_MAKE_JOBS=yes and -J 1 in use. > > Unfortunately the qemu-user-static update did not fix the > problem I've been seeing. > > An example extracted from a print/texinfo log still shows > "TCG temporary leak before 00021826": I just rebuild print/texinfo without single problem. Well, with slightly different CFLAGS CFLAGS+= -O2 -munaligned-access -mcpu=cortex-a15 -fno-builtin-sin -fno-builtin-cos Michal .... mv warn-on-use.h-t warn-on-use.h /bin/mkdir -p sys rm -f sys/types.h-t sys/types.h && \ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ sed -e 's|@''GUARD_PREFIX''@|GL|g' \ -e 's|@''INCLUDE_NEXT''@|include_next|g' \ -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ -e 's|@''PRAGMA_COLUMNS''@||g' \ -e 's|@''NEXT_SYS_TYPES_H''@||g' \ -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ < ./sys_types.in.h; \ } > sys/types.h-t && \ mv sys/types.h-t sys/types.h rm -f unistd.h-t unistd.h && \ .. > > . . . > rm -f sys/types.h-t sys/types.h && \ > { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ > sed -e 's|@''GUARD_PREFIX''@|GL|g' \ > -e 's|@''INCLUDE_NEXT''@|include_next|g' \ > -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ > -e 's|@''PRAGMA_COLUMNS''@||g' \ > -e 's|@''NEXT_SYS_TYPES_H''@||g' \ > -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ > < ./sys_types.in.h; \ > } > sys/types.h-t && \ > mv sys/types.h-t sys/types.h > TCG temporary leak before 00021826 > qemu: uncaught target signal 4 (Illegal instruction) - core dumped > Illegal instruction > gmake[2]: *** [Makefile:1174: all-recursive] Error 1 > gmake[2]: Leaving directory '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' > gmake[1]: *** [Makefile:1113: all] Error 2 > gmake[1]: Leaving directory '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make: stopped in /usr/ports/print/texinfo > ====>> Cleaning up wrkdir > ===> Cleaning for texinfo-6.1.20160425,1 > build of print/texinfo ended at Wed Jan 25 20:08:32 PST 2017 > build time: 00:06:57 > !!! build failure encountered !!! > > > === > Mark Millard > markmi at dsl-only.net > > On 01/15/17 07:09, Mark Millard wrote: >> On 2017-Jan-14, at 10:53 PM, Mark Millard wrote: >> >>> [Context: head (12) -r312009 and ports head -r431413.] >>> >>> I've been experimenting on amd64 with poudriere-devel with -x >>> for -a arm.armv6 and I ran into: >>> >>>> TCG temporary leak before 00021826 >>>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >>> >>> in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 >>> attempted. The 00021826 is the same number in all the examples >>> so far (whatever its base). >>> >>> These seem to be the only TCG messages and each failure starts with >>> one and then reports the qemu message. (Also true for the below.) >>> As far as I can tell the TCG notice is the report of an internal >>> qemu problem that is then translated into an Illegal instruction. >>> >>> This was with ALLOW_MAKE_JOBS=yes but -J 1 for poudriere. >>> >>> For 2 of the problem ports retries worked, still using >>> ALLOW_MAKE_JOBS=yes and -J 1 . >>> >>> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=yes >>> --but in a different step each time. >>> >>> In all failure cases it was gmake that got the "illegal instruction". >>> >>> But disabling ALLOW_MAKE_JOBS=yes appears (so far) to avoid the >>> issue. For example, that 3rd failing port built fine. (I've >>> been doing more ports since, with ALLOW_MAKE_JOBS=yes repeatedly >>> failing and lack of it working.) >>> >>> My guess is SIGCHLD delivery sometimes touches something (or a timing) >>> that is not handled well in qemu-arm-static. I've had not problems >>> on an rpi2 or bpim3 in the past. >>> >>> (I have seen some analogous "soemtimes" issues on powerpc under >>> and version of lang that mishandled the stack part of the ABI >>> FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time >>> for the messed up code generation, leading to stack corruption. Code >>> not getting signals had no problems.) >>> >>> Note: The amd64 context is FreeBSD under VirtualBox under macOS >>> and it has had no problem for native builds of world, kernel, >>> or ports. >> >> Avoiding ALLOW_MAKE_JOBS=yes is not sufficient to guarantee builds >> will work. Here is one that got near the end before failing the >> same way: >> >> . . . >> install -m 0644 /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/cp/type-utils.h /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/stage/usr/local/lib/gcc/arm-none-eabi/6.3.0/plugin/include/cp/type-utils.h >> install: DONTSTRIP set - will not strip installed binaries >> TCG temporary leak before 00021826 >> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >> gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction >> gmake[1]: Leaving directory '/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/.build' >> *** Error code 2 >> >> Stop. >> make: stopped in /usr/ports/devel/arm-none-eabi-gcc >> ====>> Cleaning up wrkdir >> ===> Cleaning for arm-none-eabi-gcc-6.3.0 >> build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST 2017 >> build time: 02:52:28 >> !!! build failure encountered !!! >> >> >> Going back to the earlier initial problem (that I happen to have the >> material for handy): expanding the .tbz of the failed build and finding >> the core showed: >> >> # find . -name "*.core" -exec file {} \; ./work/binutils-2.27/ld/qemu_gmake.core: ELF 32-bit LSB core file ARM, version 1 (FreeBSD), FreeBSD-style, from 'ke' >> >> [I've not figured out what I can do with that --or how.] >> >> >> One thing unusual on my part is that I use -mcpu=cortex-a7 . That >> matches how I historically buildworld buildkernel for installation >> on the rpi2 and bpim3. I've never had problems like this with >> builds on the rpi2 or the bpim3 (buildworld, buildkernel, port >> builds). It might be that qemu-arm-static has a problem with >> -mcpu=cortex-a7 code that is generated --but not always. >> >> Using the make.conf as an example: >> >> # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf >> WANT_QT_VERBOSE_CONFIGURE=1 >> # >> DEFAULT_VERSIONS+=perl5=5.24 >> WITH_DEBUG= >> WITH_DEBUG_FILES= >> MALLOC_PRODUCTION= >> # >> #system clang 3.8+ (gcc6 rejects -march=armv7a): >> #CFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> #CXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> #CPPFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> # >> #lang/gcc6's xgcc stage considers the above conflicting so use just: >> CFLAGS+= -mcpu=cortex-a7 >> CXXFLAGS+= -mcpu=cortex-a7 >> CPPFLAGS+= -mcpu=cortex-a7 >> >> >> For my context poudriere with -x for -a arm.armv6 and the use of >> qemu-arm-static does not look reliable enough to depend on. It is >> not obvious that the -x use contributes to the problem: it may well >> not. >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> >> _______________________________________________ >> 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 Jan 26 15:49: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 DFABCCC2389 for ; Thu, 26 Jan 2017 15:49:35 +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 6E793FB for ; Thu, 26 Jan 2017 15:49:35 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 08587a9b-e3df-11e6-95b5-6dfd7dbb0ee5 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 08587a9b-e3df-11e6-95b5-6dfd7dbb0ee5; Thu, 26 Jan 2017 15:49:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0QFnSpf003808; Thu, 26 Jan 2017 08:49:28 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485445768.30533.68.camel@freebsd.org> Subject: Re: BBB uarts & pps dts definitions From: Ian Lepore To: Tony Hain , freebsd-arm@freebsd.org Date: Thu, 26 Jan 2017 08:49:28 -0700 In-Reply-To: <03c101d277ae$70f142c0$52d3c840$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> 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: Thu, 26 Jan 2017 15:49:36 -0000 On Thu, 2017-01-26 at 00:30 -0800, Tony Hain wrote: > > > > -----Original Message----- > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd- > > arm@freebsd.org] On Behalf Of Tony Hain > > Sent: Wednesday, January 25, 2017 10:28 PM > > To: 'Ian Lepore'; freebsd-arm@freebsd.org > > Subject: RE: BBB uarts & pps dts definitions > > > FOLLOWUP ........... > > > > > > > > > If you have full source code on the BB, do: > > Didn't really want to put full source on the BBB. > > > > > > > > > > >   cd /usr/src/tools/test/ppsapi > > >   make ppsapitest > > I had full source on a 10.1 system, so I copied the files in that > directory and > > > > tried to make, but it is complaining about the last line needing an > operator. > > > > > > make: "src/ppsapitest/Makefile" line 13: Need an operator > > make: Fatal errors encountered -- cannot continue > > make: stopped in src/ppsapitest > > > > > > # $FreeBSD: releng/10.1/tools/test/ppsapi/Makefile 264485 2014-04- > > 15 > > 02:17:46Z gnn $ > > > > PROG=   ppsapitest > > MK_MAN=no > > > > WARNS?= 5 > > > > .include > > > > CFLAGS+=-Wno-format-security > > > > test:   ${PROG} > >         ./${PROG} /dev/cuau0 > > > Removed the Makefile and it built fine. As I suspected it didn't show > anything due to the pulse being squashed when connected to that pin. > # ./ppsapitest -v /dev/dmtpps > Supported modebits: CAPTUREASSERT OFFSETASSERT CANWAIT TSPEC > ^C > > > > > > > > > Even when it gets built though, the scope shows that the signal is > > being > > pulled to ground as soon as the wire is connected to P8-7, so I > > don't > expect it > > > > to work. Is there a way to check the state of the gpio? I would > > expect > > something like # gpioctl -N gpio_66 Can't find pin named "gpio_66" > > > > # gpioctl -l > > pin 00: 0       gpio_0<> > > pin 01: 0       gpio_1<> > > ... > > pin 30: 1       gpio_30 > > pin 31: 1       gpio_31 > > # > > > > How do the 3 additional pinmux controllers get enabled? > > > > > > > > > >   ./ppsapitest /dev/dmtpps > > > > > > You should get something like: > > > > > >   1485400775 .009578536 204 0 .000000000 0 > > >   1485400776 .009621995 205 0 .000000000 0 > > >   1485400777 .009665453 206 0 .000000000 0 > > >   1485400778 .009708869 207 0 .000000000 0 > > > > > > -- Ian > > Everything I'm doing is with 12-current, but things shouldn't be very different in 11-stable. Pin P8-7 is pin 2 on controller 2, so   gpioctl -f /dev/gpcio2 -l when it's configured correctly it should look like:   pin 02: 0       gpio_2<> If you do a verbose boot (in loader, at the prompt do boot -v) do you see these two lines right before the am335x_dmtimer0: line?   ti_pinmux0: setting internal 2a for timer4   am335x_dmtpps: configured pin P8-7 as input for timer4 -- Ian From owner-freebsd-arm@freebsd.org Thu Jan 26 15: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 EA4DBCC2739 for ; Thu, 26 Jan 2017 15:59:12 +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 83D6E867 for ; Thu, 26 Jan 2017 15:59:12 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5f73f5e4-e3e0-11e6-95b5-6dfd7dbb0ee5 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 5f73f5e4-e3e0-11e6-95b5-6dfd7dbb0ee5; Thu, 26 Jan 2017 15:59:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0QFx4eE003821; Thu, 26 Jan 2017 08:59:04 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485446344.30533.72.camel@freebsd.org> Subject: Re: =mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg From: Ian Lepore To: Mark Millard , FreeBSD Toolchain , freebsd-arm Date: Thu, 26 Jan 2017 08:59:04 -0700 In-Reply-To: <15C25780-588B-43EF-8DAC-000C301018BE@dsl-only.net> References: <15C25780-588B-43EF-8DAC-000C301018BE@dsl-only.net> 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: Thu, 26 Jan 2017 15:59:13 -0000 On Thu, 2017-01-26 at 02:10 -0800, Mark Millard wrote: > If I buildworld buildkernel for arm.armv6 with the likes of: > > CFLAGS+= =mcpu=cortex-a7 > CXXFLAGS+= =mcpu=cortex-a7 > CPPFLAGS+= =mcpu=cortex-a7 > > (say for targeting a bpim3 or rpi2) then what package > installs for that context tends to report: > > Undefined symbol "__aeabi_uidiv" > > In other words __aeabi_uidiv is only implemented > for armv6 buildworld, not if one explicitly targets > armv7. (armv7 has instruction support but that does > not make software built to support other processor > variants that are without instruction support also > work unless the routine is still provided.) > > Note: I normally build ports from source anyway > so this is just an FYI in case the lack of > __aeabi_uidiv was not deliberate. > > === > Mark Millard > markmi at dsl-only.net I believe problems like this will not go away unless we stop trying to pretend that armv6 and armv7 are the same thing, and actually start treating armv7 as its own arch, especially for the purpose of packages and ports. I've said/suggested this more than once, and every time it gets shot down by the people who actually understand what it takes to create a new arch (if I knew how to do it, I would have, long ago).  As near as I can tell, the argument against doing it is essentially "because it's hard". So I guess... don't expect it to get better any time soon. -- Ian From owner-freebsd-arm@freebsd.org Thu Jan 26 16:15:17 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 BEB9FCC2C66 for ; Thu, 26 Jan 2017 16:15:17 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c: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 412302D1 for ; Thu, 26 Jan 2017 16:15:17 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id c206so92482576wme.0 for ; Thu, 26 Jan 2017 08:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:reply-to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XZSh3AsGaxSFSOUSMAVOLJZ9izvPRjJGtKfd2qYyEoA=; b=dzWciB0uCLGlDV+kDkjK2wfuOaGJBGPN8Ofb4Iy1PbAfQ1fuWGD/IKiGyLV0MD8QMl S6ewSgP2fuzunZFzz35n6ztonH8Zx5XJ7xwVxpDsp/HHRmF/OZsczcuDfhFaqv/Rkhh/ BkSqefO4aRft6f8iDgV9okv5MRDFZ3k6979N22jx3I12umNNpHc6HX2tFixPFnwIpk6q bQfLFiIBN/IH3WQmOnm2YpEQkm6kRB0Pj4MymC/nzdQwBck7GfepnXU6R4to0XSuyaJi +3a2jkrUvh5V1e+Up5Hju1m+akhANn4bGd5j2cUucnWdmVoLh6IrIEBBGfVZeaOx3HRs j5Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:reply-to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XZSh3AsGaxSFSOUSMAVOLJZ9izvPRjJGtKfd2qYyEoA=; b=nbBUHM0Ljoqyf5HcKvIqgm1tEywpL9qqtSiOHnBLQ5yt43BQtNyLx8sHPmAsJ7XxJD Ei/9bmdMzfm7QLV3jMf8xEAfEbHY4rj0tV9P26beuOn9lwETUhxwI2Fgmczw0wVkNFPb IDp70WFsLn6xtZcYRx6OnZGNihheHWlqfZD9z3o+uS4dvNkORBD4Qc40L4c2L65+osJB GVqinulUlgJITVY3IcGHTrC7ZimAQXnXy4jrWa1Tbkr5oJ0oBnf0BA3AFgBXAqytF/eK K9GdTMSapezvWJZhYANcIoVqNFbhbbg49cXshcmdKAMQJHstQFumLSsYQdMItKfYlvrx Qwdw== X-Gm-Message-State: AIkVDXILkz0/wAJ/Y9r68rcxjHZIdtJv1pMGiUPhm44liBj4CZg7nW6jBazyYvzupQfhQg== X-Received: by 10.28.148.76 with SMTP id w73mr28435700wmd.74.1485447314587; Thu, 26 Jan 2017 08:15:14 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id q4sm3286816wrc.35.2017.01.26.08.15.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 08:15:14 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Subject: Re: =mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg References: <15C25780-588B-43EF-8DAC-000C301018BE@dsl-only.net> <1485446344.30533.72.camel@freebsd.org> To: freebsd-arm@freebsd.org Reply-To: mmel@freebsd.org Message-ID: Date: Thu, 26 Jan 2017 17:15:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1485446344.30533.72.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 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: Thu, 26 Jan 2017 16:15:17 -0000 On 26.01.2017 16:59, Ian Lepore wrote: > On Thu, 2017-01-26 at 02:10 -0800, Mark Millard wrote: >> If I buildworld buildkernel for arm.armv6 with the likes of: >> >> CFLAGS+= =mcpu=cortex-a7 >> CXXFLAGS+= =mcpu=cortex-a7 >> CPPFLAGS+= =mcpu=cortex-a7 >> >> (say for targeting a bpim3 or rpi2) then what package >> installs for that context tends to report: >> >> Undefined symbol "__aeabi_uidiv" >> >> In other words __aeabi_uidiv is only implemented >> for armv6 buildworld, not if one explicitly targets >> armv7. (armv7 has instruction support but that does >> not make software built to support other processor >> variants that are without instruction support also >> work unless the routine is still provided.) >> >> Note: I normally build ports from source anyway >> so this is just an FYI in case the lack of >> __aeabi_uidiv was not deliberate. >> >> === >> Mark Millard >> markmi at dsl-only.net > > I believe problems like this will not go away unless we stop trying to > pretend that armv6 and armv7 are the same thing, and actually start > treating armv7 as its own arch, especially for the purpose of packages > and ports. > > I've said/suggested this more than once, and every time it gets shot > down by the people who actually understand what it takes to create a > new arch (if I knew how to do it, I would have, long ago). As near as > I can tell, the argument against doing it is essentially "because it's > hard". > > So I guess... don't expect it to get better any time soon. > > -- Ian > The problems in more serious and is not related to armv6/armv7 but to specific CPU type (Cortex-A8 have not hw divide instruction). Currently, ARM libc (and few others libraries) accidentally exports some __aeabi builtins originated by compiler_rt library. All functions defined by DEFINE_AEABI_FUNCTION_ALIAS() macro have this problem. The fix is (probably) not a hard, but all precomplied packages currently depends on these symbols. I don't see any way how we can solve this problem without braking all precompiled packages :( Michal From owner-freebsd-arm@freebsd.org Thu Jan 26 18:25: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 AB96CCC338A for ; Thu, 26 Jan 2017 18:25:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-74.reflexion.net [208.70.210.74]) (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 5B8FF786 for ; Thu, 26 Jan 2017 18:25:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5397 invoked from network); 26 Jan 2017 18:25:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Jan 2017 18:25:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 26 Jan 2017 13:25:03 -0500 (EST) Received: (qmail 31661 invoked from network); 26 Jan 2017 18:25:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jan 2017 18:25:03 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B22D3EC90A8; Thu, 26 Jan 2017 10:25:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: =mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg From: Mark Millard In-Reply-To: Date: Thu, 26 Jan 2017 10:25:02 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <15C25780-588B-43EF-8DAC-000C301018BE@dsl-only.net> <1485446344.30533.72.camel@freebsd.org> To: mmel@freebsd.org 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: Thu, 26 Jan 2017 18:25:05 -0000 On 2017-Jan-26, at 8:15 AM, Michal Meloun wrote: > On 26.01.2017 16:59, Ian Lepore wrote: >> On Thu, 2017-01-26 at 02:10 -0800, Mark Millard wrote: >>> If I buildworld buildkernel for arm.armv6 with the likes of: >>> >>> CFLAGS+= =mcpu=cortex-a7 >>> CXXFLAGS+= =mcpu=cortex-a7 >>> CPPFLAGS+= =mcpu=cortex-a7 >>> >>> (say for targeting a bpim3 or rpi2) then what package >>> installs for that context tends to report: >>> >>> Undefined symbol "__aeabi_uidiv" >>> >>> In other words __aeabi_uidiv is only implemented >>> for armv6 buildworld, not if one explicitly targets >>> armv7. (armv7 has instruction support but that does >>> not make software built to support other processor >>> variants that are without instruction support also >>> work unless the routine is still provided.) >>> >>> Note: I normally build ports from source anyway >>> so this is just an FYI in case the lack of >>> __aeabi_uidiv was not deliberate. >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >> >> I believe problems like this will not go away unless we stop trying to >> pretend that armv6 and armv7 are the same thing, and actually start >> treating armv7 as its own arch, especially for the purpose of packages >> and ports. >> >> I've said/suggested this more than once, and every time it gets shot >> down by the people who actually understand what it takes to create a >> new arch (if I knew how to do it, I would have, long ago). As near as >> I can tell, the argument against doing it is essentially "because it's >> hard". >> >> So I guess... don't expect it to get better any time soon. >> >> -- Ian >> > > > The problems in more serious and is not related to armv6/armv7 but to > specific CPU type (Cortex-A8 have not hw divide instruction). Agreed that it is only some armv7's that have the optional instructions in question. In one of my cases/contexts: CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, PXN, LPAE, Coherent Walk Optional instructions: SDIV/UDIV, UMULL, SMULL, SIMD(ext) Sorry for my earlier poor wording on this that implied all armv7's would be this way. > Currently, ARM libc (and few others libraries) accidentally exports some > __aeabi builtins originated by compiler_rt library. All functions > defined by DEFINE_AEABI_FUNCTION_ALIAS() macro have this problem. > > The fix is (probably) not a hard, but all precomplied packages currently > depends on these symbols. I don't see any way how we can solve this > problem without braking all precompiled packages :( Providing a exported definition of each such routine even when the compiler is told of the optional instructions being present for the target of the buildworld would enable code that needs the routines. The compiler need not generate code to bind to those routines when it is told that the optional instructions will be available. It is the lack of generating the definitions for the likes of -mcpu=cortex-a7 that is the source of the incompatibility status from what I can tell: it ignores that some programs might target a smaller instruction set subset. Instead it requires that the optional instructions be used in all code by not providing the alterntiave. (I'm not claiming this is the only way to have compatibility.) > Michal === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 26 18:31: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 F16CDCC358C for ; Thu, 26 Jan 2017 18:31:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net [208.70.210.72]) (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 B2647A8C for ; Thu, 26 Jan 2017 18:31:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13566 invoked from network); 26 Jan 2017 18:05:24 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Jan 2017 18:05:24 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 26 Jan 2017 13:04:53 -0500 (EST) Received: (qmail 7898 invoked from network); 26 Jan 2017 18:04:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jan 2017 18:04:53 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id C020AEC90C8; Thu, 26 Jan 2017 10:04:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes From: Mark Millard In-Reply-To: <049fd4e6-209b-4385-48ed-f3413ab27e52@gmail.com> Date: Thu, 26 Jan 2017 10:04:52 -0800 Cc: Sean Bruno , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5AB92372-6862-4F60-84B2-9B3E7B7FF3C9@dsl-only.net> References: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> <4399212D-B4DD-460F-AD1B-9250FB412B38@dsl-only.net> <049fd4e6-209b-4385-48ed-f3413ab27e52@gmail.com> To: meloun.michal@gmail.com 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: Thu, 26 Jan 2017 18:31:36 -0000 On 2017-Jan-26, at 5:54 AM, Michal Meloun = wrote: > On 26.01.2017 5:26, Mark Millard wrote: >> On 2017-Jan-25, at 12:27 PM, Sean Bruno = wrote: >>=20 >>> Mark: >>>=20 >>> There was a recent update this week that was submitted and accepted = to >>> qemu-user-static. >>>=20 >>> Want to give it a spin again and see if you are able to make = progress? >>>=20 >>> sean "top poster for maximum effect" bruno >>=20 >> I updated my /usr/ports to -r432460 (from today) and rebuilt. >> I the tried doing some poudriere -x -a arm.armv6 port builds >> again, with ALLOW_MAKE_JOBS=3Dyes and -J 1 in use. >>=20 >> Unfortunately the qemu-user-static update did not fix the >> problem I've been seeing. >>=20 >> An example extracted from a print/texinfo log still shows >> "TCG temporary leak before 00021826": >=20 > I just rebuild print/texinfo without single problem. > Well, with slightly different CFLAGS > CFLAGS+=3D -O2 -munaligned-access -mcpu=3Dcortex-a15 -fno-builtin-sin > -fno-builtin-cos >=20 > Michal I had already reported that on retries the failure point in the overall sequence for the port either changes or the build completes for whatever I was trying to build that initially failed. (I did not repeat that in the new report.) When I retried print/texinfo built okay. I've never gotten anything large like lang/gcc6 with a full bootstrap to complete with ALLOW_MAKE_JOBS=3Dyes and -J 1 in use --no where near doing so. (In my context ALLOW_MAKE_JOBS means what portmaster would do for -j 4. Poudriere seem to give no control of this [-J is a different issue].) I've also not been able to use gdb on the .core produced: a qemu_gmake.core file extracted from the compressed tar archive of the failed work directory. file on it reports. . . # file /root/poudriere_failure/work/.build/qemu_gmake.core /root/poudriere_failure/work/.build/qemu_gmake.core: ELF 32-bit LSB core = file ARM, version 1 (FreeBSD), FreeBSD-style, from 'ke' (I suspect that "version 1 (FreebSD)" is not really intended to be supported as stands.) I submitted bugzilla 216132 as a segmentation fault report against devel/gdb but the patch that was tried just allowed gdb to get farther but show other problems and still fail overall on handling qemu_gmake.core. See 216132. =3D=3D=3D Mark Millard markmi at dsl-only.net > .... > mv warn-on-use.h-t warn-on-use.h > /bin/mkdir -p sys > rm -f sys/types.h-t sys/types.h && \ > { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ > sed -e 's|@''GUARD_PREFIX''@|GL|g' \ > -e 's|@''INCLUDE_NEXT''@|include_next|g' \ > -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ > -e 's|@''PRAGMA_COLUMNS''@||g' \ > -e 's|@''NEXT_SYS_TYPES_H''@||g' \ > -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ > < ./sys_types.in.h; \ > } > sys/types.h-t && \ > mv sys/types.h-t sys/types.h > rm -f unistd.h-t unistd.h && \ > .. >=20 >=20 >>=20 >> . . . >> rm -f sys/types.h-t sys/types.h && \ >> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ >> sed -e 's|@''GUARD_PREFIX''@|GL|g' \ >> -e 's|@''INCLUDE_NEXT''@|include_next|g' \ >> -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ >> -e 's|@''PRAGMA_COLUMNS''@||g' \ >> -e 's|@''NEXT_SYS_TYPES_H''@||g' \ >> -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ >> < ./sys_types.in.h; \ >> } > sys/types.h-t && \ >> mv sys/types.h-t sys/types.h >> TCG temporary leak before 00021826 >> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >> Illegal instruction >> gmake[2]: *** [Makefile:1174: all-recursive] Error 1 >> gmake[2]: Leaving directory = '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' >> gmake[1]: *** [Makefile:1113: all] Error 2 >> gmake[1]: Leaving directory = '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' >> =3D=3D=3D> Compilation failed unexpectedly. >> Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to >> the maintainer. >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/ports/print/texinfo >> =3D=3D=3D=3D>> Cleaning up wrkdir >> =3D=3D=3D> Cleaning for texinfo-6.1.20160425,1 >> build of print/texinfo ended at Wed Jan 25 20:08:32 PST 2017 >> build time: 00:06:57 >> !!! build failure encountered !!! >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 01/15/17 07:09, Mark Millard wrote: >>> On 2017-Jan-14, at 10:53 PM, Mark Millard = wrote: >>>=20 >>>> [Context: head (12) -r312009 and ports head -r431413.] >>>>=20 >>>> I've been experimenting on amd64 with poudriere-devel with -x >>>> for -a arm.armv6 and I ran into: >>>>=20 >>>>> TCG temporary leak before 00021826 >>>>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >>>>=20 >>>> in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 >>>> attempted. The 00021826 is the same number in all the examples >>>> so far (whatever its base). >>>>=20 >>>> These seem to be the only TCG messages and each failure starts with >>>> one and then reports the qemu message. (Also true for the below.) >>>> As far as I can tell the TCG notice is the report of an internal >>>> qemu problem that is then translated into an Illegal instruction. >>>>=20 >>>> This was with ALLOW_MAKE_JOBS=3Dyes but -J 1 for poudriere. >>>>=20 >>>> For 2 of the problem ports retries worked, still using >>>> ALLOW_MAKE_JOBS=3Dyes and -J 1 . >>>>=20 >>>> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=3Dyes >>>> --but in a different step each time. >>>>=20 >>>> In all failure cases it was gmake that got the "illegal = instruction". >>>>=20 >>>> But disabling ALLOW_MAKE_JOBS=3Dyes appears (so far) to avoid the >>>> issue. For example, that 3rd failing port built fine. (I've >>>> been doing more ports since, with ALLOW_MAKE_JOBS=3Dyes repeatedly >>>> failing and lack of it working.) >>>>=20 >>>> My guess is SIGCHLD delivery sometimes touches something (or a = timing) >>>> that is not handled well in qemu-arm-static. I've had not problems >>>> on an rpi2 or bpim3 in the past. >>>>=20 >>>> (I have seen some analogous "soemtimes" issues on powerpc under >>>> and version of lang that mishandled the stack part of the ABI >>>> FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time >>>> for the messed up code generation, leading to stack corruption. = Code >>>> not getting signals had no problems.) >>>>=20 >>>> Note: The amd64 context is FreeBSD under VirtualBox under macOS >>>> and it has had no problem for native builds of world, kernel, >>>> or ports. >>>=20 >>> Avoiding ALLOW_MAKE_JOBS=3Dyes is not sufficient to guarantee builds >>> will work. Here is one that got near the end before failing the >>> same way: >>>=20 >>> . . . >>> install -m 0644 = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/cp/type-util= s.h = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/stage/usr/local/lib/gcc/ar= m-none-eabi/6.3.0/plugin/include/cp/type-utils.h >>> install: DONTSTRIP set - will not strip installed binaries >>> TCG temporary leak before 00021826 >>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >>> gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction >>> gmake[1]: Leaving directory = '/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/.build' >>> *** Error code 2 >>>=20 >>> Stop. >>> make: stopped in /usr/ports/devel/arm-none-eabi-gcc >>> =3D=3D=3D=3D>> Cleaning up wrkdir >>> =3D=3D=3D> Cleaning for arm-none-eabi-gcc-6.3.0 >>> build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST = 2017 >>> build time: 02:52:28 >>> !!! build failure encountered !!! >>>=20 >>>=20 >>> Going back to the earlier initial problem (that I happen to have the >>> material for handy): expanding the .tbz of the failed build and = finding >>> the core showed: >>>=20 >>> # find . -name "*.core" -exec file {} \; = = ./work/binutils-2.27/ld/qemu_gmake.core: ELF 32-bit LSB core file ARM, = version 1 (FreeBSD), FreeBSD-style, from 'ke' >>>=20 >>> [I've not figured out what I can do with that --or how.] >>>=20 >>>=20 >>> One thing unusual on my part is that I use -mcpu=3Dcortex-a7 . That >>> matches how I historically buildworld buildkernel for installation >>> on the rpi2 and bpim3. I've never had problems like this with >>> builds on the rpi2 or the bpim3 (buildworld, buildkernel, port >>> builds). It might be that qemu-arm-static has a problem with >>> -mcpu=3Dcortex-a7 code that is generated --but not always. >>>=20 >>> Using the make.conf as an example: >>>=20 >>> # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf >>> WANT_QT_VERBOSE_CONFIGURE=3D1 >>> # >>> DEFAULT_VERSIONS+=3Dperl5=3D5.24 >>> WITH_DEBUG=3D >>> WITH_DEBUG_FILES=3D >>> MALLOC_PRODUCTION=3D >>> # >>> #system clang 3.8+ (gcc6 rejects -march=3Darmv7a): >>> #CFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>> #CXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>> #CPPFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>> # >>> #lang/gcc6's xgcc stage considers the above conflicting so use just: >>> CFLAGS+=3D -mcpu=3Dcortex-a7 >>> CXXFLAGS+=3D -mcpu=3Dcortex-a7 >>> CPPFLAGS+=3D -mcpu=3Dcortex-a7 >>>=20 >>>=20 >>> For my context poudriere with -x for -a arm.armv6 and the use of >>> qemu-arm-static does not look reliable enough to depend on. It is >>> not obvious that the -x use contributes to the problem: it may well >>> not. >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 26 20:23:11 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 A26D0CC3639 for ; Thu, 26 Jan 2017 20:23:11 +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 8F38A183D for ; Thu, 26 Jan 2017 20:23:11 +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 v0QKNB3Y043755 for ; Thu, 26 Jan 2017 20:23:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 216504] RPI-B-20170105-r311441 image causes continuous reboot Date: Thu, 26 Jan 2017 20:23:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: michael.cress@cress.us 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: Thu, 26 Jan 2017 20:23:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216504 Bug ID: 216504 Summary: RPI-B-20170105-r311441 image causes continuous reboot Product: Base System Version: 11.0-STABLE Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: michael.cress@cress.us FreeBSD-11.0-STABLE-arm-armv6-RPI-B-20170105-r311441.img.xz causes a contin= uous reboot immediately after power-on of my Raspberry Pi Model B (original). Th= is appears after the messages about uBoot/uEnv.txt. This did not occur with FreeBSD-11.0-STABLE-arm-armv6-RPI-B-20161209-r309771.img.xz. Unfortunately,= the reboot happens so fast that I am unable to read the contents of the screen = but cant tell that it dumps data in a somewhat tabular formatted fashion. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Jan 26 20:53: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 5B382CC13E5 for ; Thu, 26 Jan 2017 20:53:36 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36960144D; Thu, 26 Jan 2017 20:53:36 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=5v1NaExdic24PHueCa2L4oXGF7JHvgiSp+kiJCtjGxg=; b=AKpiwNmA1LfwIhgLQjAkaCNZ3qTIddzirrvaJk3IEy08D0yEYGbr04Ka4jIbYCwVgXFppGo3UnJdErRx6bEDzrWBMIxusu2lav949SMeL8VhjEH18mtJFffyGhgxqOWSpZXfOeM56P/0TYPrbttsUjg8pTjUG1pA0gzkvGj8m2rJ7nhL; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cWr2v-0009wm-Bw; Thu, 26 Jan 2017 12:53:35 -0800 From: "Tony Hain" To: "'Ian Lepore'" , References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> In-Reply-To: <1485445768.30533.68.camel@freebsd.org> Date: Thu, 26 Jan 2017 12:53:29 -0800 Message-ID: <040101d27816$3f7547b0$be5fd710$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEImxvIZ6VEPYS1CTeMHuF4SjTdHgFGeuiPAfagOS8BXCmlWAJOLTryoqeN/5A= Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Thu, 26 Jan 2017 20:53:36 -0000 Ian Lepore wrote: >>>>>>>> snip > > > > > > Even when it gets built though, the scope shows that the signal is > > > being pulled to ground as soon as the wire is connected to P8-7, = so > > > I don't > > expect it > > > > > > to work. Is there a way to check the state of the gpio? I would > > > expect something like # gpioctl -N gpio_66 Can't find pin named > > > "gpio_66" > > > > > > # gpioctl -l > > > pin 00: 0=A0=A0=A0=A0=A0=A0=A0gpio_0<> > > > pin 01: 0=A0=A0=A0=A0=A0=A0=A0gpio_1<> > > > ... > > > pin 30: 1=A0=A0=A0=A0=A0=A0=A0gpio_30 > > > pin 31: 1=A0=A0=A0=A0=A0=A0=A0gpio_31 > > > # > > > > > > How do the 3 additional pinmux controllers get enabled? > > > > > > > > > > > > > > =A0 ./ppsapitest /dev/dmtpps > > > > > > > > You should get something like: > > > > > > > > =A0 1485400775 .009578536 204 0 .000000000 0 > > > > =A0 1485400776 .009621995 205 0 .000000000 0 > > > > =A0 1485400777 .009665453 206 0 .000000000 0 > > > > =A0 1485400778 .009708869 207 0 .000000000 0 > > > > > > > > -- Ian > > > >=20 > Everything I'm doing is with 12-current, but things shouldn't be very different > in 11-stable. >=20 > Pin P8-7 is pin 2 on controller 2, so >=20 > =A0 gpioctl -f /dev/gpcio2 -l >=20 > when it's configured correctly it should look like: >=20 > =A0 pin 02: 0=A0=A0=A0=A0=A0=A0=A0gpio_2<> # gpioctl -lv -f /dev/gpioc2 pin 00: 1 gpio_0, caps: pin 01: 0 gpio_1, caps: pin 02: 0 gpio_2<>, caps: ... So it looks like gpioctl defaults to the first controller if none are listed, since gpioctl -lv only shows the first 32. Nothing in gpioctl = -h indicates that would be the case, though the framework wiki does mention = a restriction at 32 in the hint files discussion. Nothing in -h, the man = page, or the wiki indicates what -t -c or -n do, so I am reluctant to try = them. I would guess toggle, capabilities, and name, but the help and = documentation should really be clear about that, and how to set direction. >=20 > If you do a verbose boot (in loader, at the prompt do boot -v) do you = see > these two lines right before the=A0am335x_dmtimer0: line? >=20 > =A0 ti_pinmux0: setting internal 2a for timer4 > =A0 am335x_dmtpps: configured pin P8-7 as input for timer4 Booting from disk0s2a: /boot/kernel/kernel data=3D0x6d6564+0x145a9c = syms=3D[0x4+0x7eb30+0x4+0x922fa] /boot/kernel/am335x_dmtpps.ko text=3D0x1c60 data=3D0x224+0x8 syms=3D[0x4+0x820+0x4+0x742] loader> boot -v # dmesg | grep er4 ti_pinmux0: setting internal 2a for timer4 am335x_dmtpps: configured pin P8-7 as input for timer4 am335x_dmtpps0: mem 0x48044000-0x480443ff = irq 30 on simplebus0 Timecounter "DMTimer4" frequency 24000000 Hz quality 1000 am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps So all that looks as you indicated it should, though I am troubled that = pin 2 is not restricted to IN on the gpioctl listing. It does say configured = as input in dmesg, so it should be doing the right thing.=20 The only thing that comes to mind at this point is some electrical restriction about the BBB input, where a 5/3 resistive divider = (2.2k/3.3k) is inadequate, but the fact that the uart is working would tend to rule = that out. Electrically it is acting as though the pin is set to Output at 0. ...... As I typed that it occurred to me I should really check that it = is 0, and found that there actually is a correct pulse at 60mv. This would = imply that the input impedance of the pin is 26 ohms. The system reference = manual doesn't discuss input impedance that I can find, and search isn't = turning up anything either. Why would the timer pin be different than the uart pin = on the same soc? What are you using to drive your pps? This is so close, there must be something really trivial that I am overlooking... Tony From owner-freebsd-arm@freebsd.org Thu Jan 26 21:33:28 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 1FC2CCC266C for ; Thu, 26 Jan 2017 21:33:28 +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 F2A96C67 for ; Thu, 26 Jan 2017 21:33:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 14df60b5-e40f-11e6-ba57-8bc134ee460a 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 14df60b5-e40f-11e6-ba57-8bc134ee460a; Thu, 26 Jan 2017 21:33:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0QLXPuN004382; Thu, 26 Jan 2017 14:33:25 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485466405.30533.96.camel@freebsd.org> Subject: Re: BBB uarts & pps dts definitions From: Ian Lepore To: Tony Hain , freebsd-arm@freebsd.org Date: Thu, 26 Jan 2017 14:33:25 -0700 In-Reply-To: <040101d27816$3f7547b0$be5fd710$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> <040101d27816$3f7547b0$be5fd710$@tndh.net> 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: Thu, 26 Jan 2017 21:33:28 -0000 On Thu, 2017-01-26 at 12:53 -0800, Tony Hain wrote: > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > snip > > > > > > > > > > > > > > > > > Even when it gets built though, the scope shows that the signal > > > > is > > > > being pulled to ground as soon as the wire is connected to P8- > > > > 7, so > > > > I don't > > > expect it > > > > > > > > > > > > to work. Is there a way to check the state of the gpio? I would > > > > expect something like # gpioctl -N gpio_66 Can't find pin named > > > > "gpio_66" > > > > > > > > # gpioctl -l > > > > pin 00: 0       gpio_0<> > > > > pin 01: 0       gpio_1<> > > > > ... > > > > pin 30: 1       gpio_30 > > > > pin 31: 1       gpio_31 > > > > # > > > > > > > > How do the 3 additional pinmux controllers get enabled? > > > > > > > > > > > > > > > > > > > > > > >   ./ppsapitest /dev/dmtpps > > > > > > > > > > You should get something like: > > > > > > > > > >   1485400775 .009578536 204 0 .000000000 0 > > > > >   1485400776 .009621995 205 0 .000000000 0 > > > > >   1485400777 .009665453 206 0 .000000000 0 > > > > >   1485400778 .009708869 207 0 .000000000 0 > > > > > > > > > > -- Ian > > Everything I'm doing is with 12-current, but things shouldn't be > > very > different > > > > in 11-stable. > > > > Pin P8-7 is pin 2 on controller 2, so > > > >   gpioctl -f /dev/gpcio2 -l > > > > when it's configured correctly it should look like: > > > >   pin 02: 0       gpio_2<> > # gpioctl -lv -f /dev/gpioc2 > pin 00: 1       gpio_0, > caps: > pin 01: 0       gpio_1, > caps: > pin 02: 0       gpio_2<>, > caps: > ... > > So it looks like gpioctl defaults to the first controller if none are > listed, since  gpioctl -lv only shows the first 32. Nothing in > gpioctl -h > indicates that would be the case, though the framework wiki does > mention a > restriction at 32 in the hint files discussion. Nothing in -h, the > man page, > or the wiki indicates what -t -c or -n do, so I am reluctant to try > them. I > would guess toggle, capabilities, and name, but the help and > documentation > should really be clear about that, and how to set direction. > All good points, but really, gpio has nothing to do with this stuff. > > > > > > If you do a verbose boot (in loader, at the prompt do boot -v) do > > you see > > these two lines right before the am335x_dmtimer0: line? > > > >   ti_pinmux0: setting internal 2a for timer4 > >   am335x_dmtpps: configured pin P8-7 as input for timer4 > Booting from disk0s2a: > /boot/kernel/kernel data=0x6d6564+0x145a9c > syms=[0x4+0x7eb30+0x4+0x922fa] > /boot/kernel/am335x_dmtpps.ko text=0x1c60 data=0x224+0x8 > syms=[0x4+0x820+0x4+0x742] > > loader> boot -v > > # dmesg | grep er4 > ti_pinmux0: setting internal 2a for timer4 > am335x_dmtpps: configured pin P8-7 as input for timer4 Yep, this indicates the config is right, so the problem must be electrical. > am335x_dmtpps0: mem 0x48044000- > 0x480443ff irq > 30 on simplebus0 > Timecounter "DMTimer4" frequency 24000000 Hz quality 1000 > am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps > > So all that looks as you indicated it should, though I am troubled > that pin > 2 is not restricted to IN on the gpioctl listing. It does say > configured as > input in dmesg, so it should be doing the right thing.  > Pin 2 is not listed as because it's not a gpio pin anymore after being reconfigured as TIMER4 input.  The empty brackets indicate that it has been configured as a device pin, not gpio. > The only thing that comes to mind at this point is some electrical > restriction about the BBB input, where a 5/3 resistive divider > (2.2k/3.3k) > is inadequate, but the fact that the uart is working would tend to > rule that > out. Electrically it is acting as though the pin is set to Output at > 0. > ...... As I typed that it occurred to me I should really check that > it is 0, > and found that there actually is a correct pulse at 60mv. This would > imply > that the input impedance of the pin is 26 ohms. The system reference > manual > doesn't discuss input impedance that I can find, and search isn't > turning up > anything either. Why would the timer pin be different than the uart > pin on > the same soc? What are you using to drive your pps? > > This is so close, there must be something really trivial that I am > overlooking... > > Tony I'm using a 5v->3.3v level shifter right now, but I have in the past succesfully used resistive dividers.  My PPS output device is designed to drive 5v into a 50 ohm load, so when using a divider I just try various values I have handy until my scope says the voltage high level is somewhere in the 2.8-3.3v range.  Usually I use resistance that adds up to somewhere between 40-100 ohms when I do that (depends on what resistors pop out first when I reach into the bag of loosies).   -- Ian From owner-freebsd-arm@freebsd.org Thu Jan 26 22:17:32 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 6F0F2CC372D for ; Thu, 26 Jan 2017 22:17:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-70.reflexion.net [208.70.210.70]) (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 30652D30 for ; Thu, 26 Jan 2017 22:17:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3366 invoked from network); 26 Jan 2017 22:18:00 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Jan 2017 22:18:00 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 26 Jan 2017 17:17:30 -0500 (EST) Received: (qmail 23698 invoked from network); 26 Jan 2017 22:17:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jan 2017 22:17:30 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A0355EC901D; Thu, 26 Jan 2017 14:17:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes From: Mark Millard In-Reply-To: <5AB92372-6862-4F60-84B2-9B3E7B7FF3C9@dsl-only.net> Date: Thu, 26 Jan 2017 14:17:29 -0800 Cc: Michal Meloun Content-Transfer-Encoding: quoted-printable Message-Id: <9D8010B2-02A7-4B01-86F1-358329E3DB1A@dsl-only.net> References: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> <4399212D-B4DD-460F-AD1B-9250FB412B38@dsl-only.net> <049fd4e6-209b-4385-48ed-f3413ab27e52@gmail.com> <5AB92372-6862-4F60-84B2-9B3E7B7FF3C9@dsl-only.net> To: Sean Bruno , freebsd-arm 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: Thu, 26 Jan 2017 22:17:32 -0000 [Top post of new information confirming SIGCHLD handling.] lldb on an arm (bpim3) is able to interpret the qemu_gmake.core file in a useful way when also given a copy of the gmake! For "TCG temporary leak before 00021826" the symbol dump in addresses order shows: Dumping symbol table for 4 modules. Symtab, file =3D /usr/local/bin/gmake, num_symbols =3D 957 (sorted by = address): Debug symbol |Synthetic symbol ||Externally Visible ||| Index UserID DSX Type File Address/Value Load Address = Size Flags Name ------- ------ --- --------------- ------------------ ------------------ = ------------------ ---------- ---------------------------------- . . . [ 538] 6121 X Code 0x0000000000021820 0x00029820 = 0x0000000000000038 0x00000012 child_handler [ 592] 6175 X Code 0x0000000000021858 0x00029858 = 0x0000000000000d7c 0x00000012 reap_children . . . This looks like it tends to confirm the SIGCHLD handling is involved. And objdump on gmake shows: 00021820 push {fp, lr} 00021824 mov fp, sp 00021828 sub sp, sp, #8 0002182c mov r1, r0 00021830 str r0, [sp, #4] 00021834 movw r0, #36636 ; 0x8f1c 00021838 movt r0, #5 0002183c ldr r2, [r0] 00021840 add r2, r2, #1 00021844 str r2, [r0] 00021848 str r1, [sp] 0002184c bl 0002e9f0 00021850 mov sp, fp 00021854 pop {fp, pc} Interestingly 00021826 is between instructions and lldb reported for the registers: (lldb) register read General Purpose Registers: r0 =3D 0x9fffc0f8 r1 =3D 0x9fffc138 r2 =3D 0x000a18c0 r3 =3D 0xf4fde858 r4 =3D 0x9fffc138 r5 =3D 0xf4a00000 r6 =3D 0xb6db6db7 r7 =3D 0x00000012 r8 =3D 0xf4a0c000 r9 =3D 0xf4aa18c0 r10 =3D 0x9fffc260 r11 =3D 0x00000004 r12 =3D 0x9fffc0f8 sp =3D 0x9fffc0f8 lr =3D 0x9fffffcc pc =3D 0x00021822 cpsr =3D 0x80000030 i.e., the pc being 0x00021822 . That would be in the middle of the "push {fp, lr}" instruction and 4 bytes before the 00021826 figure. If it really tried to fetch an instruction at 0x00021822 that likely would also explain getting a SIGILL classification for the 4 bytes starting there. I have no clue how the odd-multiple-of-2 address is getting involved. But it does appear that sometimes signal delivery is messed up under qemu. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-26, at 10:04 AM, Mark Millard = wrote: > On 2017-Jan-26, at 5:54 AM, Michal Meloun = wrote: >=20 >> On 26.01.2017 5:26, Mark Millard wrote: >>> On 2017-Jan-25, at 12:27 PM, Sean Bruno = wrote: >>>=20 >>>> Mark: >>>>=20 >>>> There was a recent update this week that was submitted and accepted = to >>>> qemu-user-static. >>>>=20 >>>> Want to give it a spin again and see if you are able to make = progress? >>>>=20 >>>> sean "top poster for maximum effect" bruno >>>=20 >>> I updated my /usr/ports to -r432460 (from today) and rebuilt. >>> I the tried doing some poudriere -x -a arm.armv6 port builds >>> again, with ALLOW_MAKE_JOBS=3Dyes and -J 1 in use. >>>=20 >>> Unfortunately the qemu-user-static update did not fix the >>> problem I've been seeing. >>>=20 >>> An example extracted from a print/texinfo log still shows >>> "TCG temporary leak before 00021826": >>=20 >> I just rebuild print/texinfo without single problem. >> Well, with slightly different CFLAGS >> CFLAGS+=3D -O2 -munaligned-access -mcpu=3Dcortex-a15 -fno-builtin-sin >> -fno-builtin-cos >>=20 >> Michal >=20 > I had already reported that on retries the failure point in > the overall sequence for the port either changes or the build > completes for whatever I was trying to build that initially > failed. (I did not repeat that in the new report.) >=20 > When I retried print/texinfo built okay. >=20 > I've never gotten anything large like lang/gcc6 with a full > bootstrap to complete with ALLOW_MAKE_JOBS=3Dyes and -J 1 in use > --no where near doing so. (In my context ALLOW_MAKE_JOBS means > what portmaster would do for -j 4. Poudriere seem to give no > control of this [-J is a different issue].) >=20 > I've also not been able to use gdb on the .core produced: > a qemu_gmake.core file extracted from the compressed tar > archive of the failed work directory. file on it reports. . . >=20 > # file /root/poudriere_failure/work/.build/qemu_gmake.core > /root/poudriere_failure/work/.build/qemu_gmake.core: ELF 32-bit LSB = core file ARM, version 1 (FreeBSD), FreeBSD-style, from 'ke' >=20 > (I suspect that "version 1 (FreebSD)" is not really > intended to be supported as stands.) >=20 > I submitted bugzilla 216132 as a segmentation fault report > against devel/gdb but the patch that was tried just allowed > gdb to get farther but show other problems and still fail > overall on handling qemu_gmake.core. See 216132. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >> .... >> mv warn-on-use.h-t warn-on-use.h >> /bin/mkdir -p sys >> rm -f sys/types.h-t sys/types.h && \ >> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ >> sed -e 's|@''GUARD_PREFIX''@|GL|g' \ >> -e 's|@''INCLUDE_NEXT''@|include_next|g' \ >> -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ >> -e 's|@''PRAGMA_COLUMNS''@||g' \ >> -e 's|@''NEXT_SYS_TYPES_H''@||g' \ >> -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ >> < ./sys_types.in.h; \ >> } > sys/types.h-t && \ >> mv sys/types.h-t sys/types.h >> rm -f unistd.h-t unistd.h && \ >> .. >>=20 >>=20 >>>=20 >>> . . . >>> rm -f sys/types.h-t sys/types.h && \ >>> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ >>> sed -e 's|@''GUARD_PREFIX''@|GL|g' \ >>> -e 's|@''INCLUDE_NEXT''@|include_next|g' \ >>> -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ >>> -e 's|@''PRAGMA_COLUMNS''@||g' \ >>> -e 's|@''NEXT_SYS_TYPES_H''@||g' \ >>> -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ >>> < ./sys_types.in.h; \ >>> } > sys/types.h-t && \ >>> mv sys/types.h-t sys/types.h >>> TCG temporary leak before 00021826 >>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >>> Illegal instruction >>> gmake[2]: *** [Makefile:1174: all-recursive] Error 1 >>> gmake[2]: Leaving directory = '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' >>> gmake[1]: *** [Makefile:1113: all] Error 2 >>> gmake[1]: Leaving directory = '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' >>> =3D=3D=3D> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to >>> the maintainer. >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/ports/print/texinfo >>> =3D=3D=3D=3D>> Cleaning up wrkdir >>> =3D=3D=3D> Cleaning for texinfo-6.1.20160425,1 >>> build of print/texinfo ended at Wed Jan 25 20:08:32 PST 2017 >>> build time: 00:06:57 >>> !!! build failure encountered !!! >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>> On 01/15/17 07:09, Mark Millard wrote: >>>> On 2017-Jan-14, at 10:53 PM, Mark Millard = wrote: >>>>=20 >>>>> [Context: head (12) -r312009 and ports head -r431413.] >>>>>=20 >>>>> I've been experimenting on amd64 with poudriere-devel with -x >>>>> for -a arm.armv6 and I ran into: >>>>>=20 >>>>>> TCG temporary leak before 00021826 >>>>>> qemu: uncaught target signal 4 (Illegal instruction) - core = dumped >>>>>=20 >>>>> in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 >>>>> attempted. The 00021826 is the same number in all the examples >>>>> so far (whatever its base). >>>>>=20 >>>>> These seem to be the only TCG messages and each failure starts = with >>>>> one and then reports the qemu message. (Also true for the below.) >>>>> As far as I can tell the TCG notice is the report of an internal >>>>> qemu problem that is then translated into an Illegal instruction. >>>>>=20 >>>>> This was with ALLOW_MAKE_JOBS=3Dyes but -J 1 for poudriere. >>>>>=20 >>>>> For 2 of the problem ports retries worked, still using >>>>> ALLOW_MAKE_JOBS=3Dyes and -J 1 . >>>>>=20 >>>>> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=3Dyes >>>>> --but in a different step each time. >>>>>=20 >>>>> In all failure cases it was gmake that got the "illegal = instruction". >>>>>=20 >>>>> But disabling ALLOW_MAKE_JOBS=3Dyes appears (so far) to avoid the >>>>> issue. For example, that 3rd failing port built fine. (I've >>>>> been doing more ports since, with ALLOW_MAKE_JOBS=3Dyes repeatedly >>>>> failing and lack of it working.) >>>>>=20 >>>>> My guess is SIGCHLD delivery sometimes touches something (or a = timing) >>>>> that is not handled well in qemu-arm-static. I've had not problems >>>>> on an rpi2 or bpim3 in the past. >>>>>=20 >>>>> (I have seen some analogous "soemtimes" issues on powerpc under >>>>> and version of lang that mishandled the stack part of the ABI >>>>> FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time >>>>> for the messed up code generation, leading to stack corruption. = Code >>>>> not getting signals had no problems.) >>>>>=20 >>>>> Note: The amd64 context is FreeBSD under VirtualBox under macOS >>>>> and it has had no problem for native builds of world, kernel, >>>>> or ports. >>>>=20 >>>> Avoiding ALLOW_MAKE_JOBS=3Dyes is not sufficient to guarantee = builds >>>> will work. Here is one that got near the end before failing the >>>> same way: >>>>=20 >>>> . . . >>>> install -m 0644 = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/cp/type-util= s.h = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/stage/usr/local/lib/gcc/ar= m-none-eabi/6.3.0/plugin/include/cp/type-utils.h >>>> install: DONTSTRIP set - will not strip installed binaries >>>> TCG temporary leak before 00021826 >>>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >>>> gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction >>>> gmake[1]: Leaving directory = '/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/.build' >>>> *** Error code 2 >>>>=20 >>>> Stop. >>>> make: stopped in /usr/ports/devel/arm-none-eabi-gcc >>>> =3D=3D=3D=3D>> Cleaning up wrkdir >>>> =3D=3D=3D> Cleaning for arm-none-eabi-gcc-6.3.0 >>>> build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST = 2017 >>>> build time: 02:52:28 >>>> !!! build failure encountered !!! >>>>=20 >>>>=20 >>>> Going back to the earlier initial problem (that I happen to have = the >>>> material for handy): expanding the .tbz of the failed build and = finding >>>> the core showed: >>>>=20 >>>> # find . -name "*.core" -exec file {} \; = = ./work/binutils-2.27/ld/qemu_gmake.core: ELF 32-bit LSB core file ARM, = version 1 (FreeBSD), FreeBSD-style, from 'ke' >>>>=20 >>>> [I've not figured out what I can do with that --or how.] >>>>=20 >>>>=20 >>>> One thing unusual on my part is that I use -mcpu=3Dcortex-a7 . That >>>> matches how I historically buildworld buildkernel for installation >>>> on the rpi2 and bpim3. I've never had problems like this with >>>> builds on the rpi2 or the bpim3 (buildworld, buildkernel, port >>>> builds). It might be that qemu-arm-static has a problem with >>>> -mcpu=3Dcortex-a7 code that is generated --but not always. >>>>=20 >>>> Using the make.conf as an example: >>>>=20 >>>> # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf >>>> WANT_QT_VERBOSE_CONFIGURE=3D1 >>>> # >>>> DEFAULT_VERSIONS+=3Dperl5=3D5.24 >>>> WITH_DEBUG=3D >>>> WITH_DEBUG_FILES=3D >>>> MALLOC_PRODUCTION=3D >>>> # >>>> #system clang 3.8+ (gcc6 rejects -march=3Darmv7a): >>>> #CFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>>> #CXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>>> #CPPFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>>> # >>>> #lang/gcc6's xgcc stage considers the above conflicting so use = just: >>>> CFLAGS+=3D -mcpu=3Dcortex-a7 >>>> CXXFLAGS+=3D -mcpu=3Dcortex-a7 >>>> CPPFLAGS+=3D -mcpu=3Dcortex-a7 >>>>=20 >>>>=20 >>>> For my context poudriere with -x for -a arm.armv6 and the use of >>>> qemu-arm-static does not look reliable enough to depend on. It is >>>> not obvious that the -x use contributes to the problem: it may well >>>> not. >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 26 23:41:48 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 CFF5DCC3D8A for ; Thu, 26 Jan 2017 23:41:48 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA06D129F; Thu, 26 Jan 2017 23:41:48 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=VIgjBSyFaMJOTO80EZ4gW4cZneV5NC0slp0Ft1wPq/M=; b=AXg6kOmEOLJ6ckZHbpIwCo2Z26gA09CF5eNxYkqVQbviVIh1N6/iMU3gSFVoHg5cEucHtTklMjfcWgQ3mbhGEo1wTjMQ+oTqwxGyHs3eLCiwEq+TakdSw8gUKN+7Ts1u1DPgCUe+O/B/OZf8g0Xfau4fP73FvtKTbdl4UcxemnEKZDsQ; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cWtfh-000Ccf-CC; Thu, 26 Jan 2017 15:41:47 -0800 From: "Tony Hain" To: "'Ian Lepore'" , References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> <040101d27816$3f7547b0$be5fd710$@tndh.net> <1485466405.30533.96.camel@freebsd.org> In-Reply-To: <1485466405.30533.96.camel@freebsd.org> Date: Thu, 26 Jan 2017 15:41:41 -0800 Message-ID: <041a01d2782d$bee11850$3ca348f0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEImxvIZ6VEPYS1CTeMHuF4SjTdHgFGeuiPAfagOS8BXCmlWAJOLTryAjf7KeUBQ5O/qKKL7BpQ Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Thu, 26 Jan 2017 23:41:48 -0000 > -----Original Message----- > From: Ian Lepore [mailto:ian@freebsd.org] > Sent: Thursday, January 26, 2017 1:33 PM > To: Tony Hain; freebsd-arm@freebsd.org > Subject: Re: BBB uarts & pps dts definitions >=20 > On Thu, 2017-01-26 at 12:53 -0800, Tony Hain wrote: > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > snip > > > > > > > > > > > > > > > > > > > > > > Even when it gets built though, the scope shows that the = signal > > > > > is being pulled to ground as soon as the wire is connected to > > > > > P8- 7, so I don't > > > > expect it > > > > > > > > > > > > > > > to work. Is there a way to check the state of the gpio? I = would > > > > > expect something like # gpioctl -N gpio_66 Can't find pin = named > > > > > "gpio_66" > > > > > > > > > > # gpioctl -l > > > > > pin 00: 0=A0=A0=A0=A0=A0=A0=A0gpio_0<> > > > > > pin 01: 0=A0=A0=A0=A0=A0=A0=A0gpio_1<> > > > > > ... > > > > > pin 30: 1=A0=A0=A0=A0=A0=A0=A0gpio_30 > > > > > pin 31: 1=A0=A0=A0=A0=A0=A0=A0gpio_31 > > > > > # > > > > > > > > > > How do the 3 additional pinmux controllers get enabled? > > > > > > > > > > > > > > > > > > > > > > > > > > > > =A0 ./ppsapitest /dev/dmtpps > > > > > > > > > > > > You should get something like: > > > > > > > > > > > > =A0 1485400775 .009578536 204 0 .000000000 0 > > > > > > =A0 1485400776 .009621995 205 0 .000000000 0 > > > > > > =A0 1485400777 .009665453 206 0 .000000000 0 > > > > > > =A0 1485400778 .009708869 207 0 .000000000 0 > > > > > > > > > > > > -- Ian > > > Everything I'm doing is with 12-current, but things shouldn't be > > > very > > different > > > > > > in 11-stable. > > > > > > Pin P8-7 is pin 2 on controller 2, so > > > > > > =A0 gpioctl -f /dev/gpcio2 -l > > > > > > when it's configured correctly it should look like: > > > > > > =A0 pin 02: 0=A0=A0=A0=A0=A0=A0=A0gpio_2<> > > # gpioctl -lv -f /dev/gpioc2 > > pin 00: 1=A0=A0=A0=A0=A0=A0=A0gpio_0, > > > caps: OWN> > > pin 01: 0=A0=A0=A0=A0=A0=A0=A0gpio_1, > > > caps: OWN> > > pin 02: 0=A0=A0=A0=A0=A0=A0=A0gpio_2<>, > > > caps: OWN> > > ... > > > > So it looks like gpioctl defaults to the first controller if none = are > > listed, since=A0=A0gpioctl -lv only shows the first 32. Nothing in = gpioctl > > -h indicates that would be the case, though the framework wiki does > > mention a restriction at 32 in the hint files discussion. Nothing in > > -h, the man page, or the wiki indicates what -t -c or -n do, so I am > > reluctant to try them. I would guess toggle, capabilities, and name, > > but the help and documentation should really be clear about that, = and > > how to set direction. > > >=20 > All good points, but really, gpio has nothing to do with this stuff. Simply trying to figure out how to diagnose the gpio pin, and the ctl = tool is not clear about how to use it. >=20 > > > > > > > > > If you do a verbose boot (in loader, at the prompt do boot -v) do > > > you see > > > these two lines right before the=A0am335x_dmtimer0: line? > > > > > > =A0 ti_pinmux0: setting internal 2a for timer4 > > > =A0 am335x_dmtpps: configured pin P8-7 as input for timer4 > > Booting from disk0s2a: > > /boot/kernel/kernel data=3D0x6d6564+0x145a9c > > syms=3D[0x4+0x7eb30+0x4+0x922fa] > > /boot/kernel/am335x_dmtpps.ko text=3D0x1c60 data=3D0x224+0x8 > > syms=3D[0x4+0x820+0x4+0x742] > > > > loader> boot -v > > > > # dmesg | grep er4 > > ti_pinmux0: setting internal 2a for timer4 > > am335x_dmtpps: configured pin P8-7 as input for timer4 >=20 > Yep, this indicates the config is right, so the problem must be > electrical. >=20 > > am335x_dmtpps0: mem 0x48044000- > > 0x480443ff irq > > 30 on simplebus0 > > Timecounter "DMTimer4" frequency 24000000 Hz quality 1000 > > am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps > > > > So all that looks as you indicated it should, though I am troubled > > that pin > > 2 is not restricted to IN on the gpioctl listing. It does say > > configured as > > input in dmesg, so it should be doing the right thing. > > >=20 > Pin 2 is not listed as because it's not a gpio pin anymore after > being reconfigured as TIMER4 input. =A0The empty brackets indicate = that > it has been configured as a device pin, not gpio. Ok. That is another point that would be helpful if it were on the wiki. >=20 > > The only thing that comes to mind at this point is some electrical > > restriction about the BBB input, where a 5/3 resistive divider > > (2.2k/3.3k) > > is inadequate, but the fact that the uart is working would tend to > > rule that > > out. Electrically it is acting as though the pin is set to Output at > > 0. > > ...... As I typed that it occurred to me I should really check that > > it is 0, > > and found that there actually is a correct pulse at 60mv. This would > > imply > > that the input impedance of the pin is 26 ohms. The system reference > > manual > > doesn't discuss input impedance that I can find, and search isn't > > turning up > > anything either. Why would the timer pin be different than the uart > > pin on > > the same soc? What are you using to drive your pps? > > > > This is so close, there must be something really trivial that I am > > overlooking... > > > > Tony >=20 > I'm using a 5v->3.3v level shifter right now, but I have in the past > succesfully used resistive dividers. =A0My PPS output device is = designed > to drive 5v into a 50 ohm load, so when using a divider I just try > various values I have handy until my scope says the voltage high level > is somewhere in the 2.8-3.3v range. =A0Usually I use resistance that = adds > up to somewhere between 40-100 ohms when I do that (depends on what > resistors pop out first when I reach into the bag of loosies). >=20 > -- Ian That makes some degree of sense based on what I am seeing, though that = is a very low input impedance on the BBB. I was expecting ~100k. My source is = a 555 on an ancient ttl/RS232 board I built because the 20 us pulse from = the GPS was too fast (between the slew rate of the 3232 and the DCD = detection window on the com port) to go with a simple level conversion. Sounds = like it might be best to do an active 3.3v driver at this point. Tony From owner-freebsd-arm@freebsd.org Fri Jan 27 01:01: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 1AF7DCC3AD2 for ; Fri, 27 Jan 2017 01:01:05 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 D32D01EFE for ; Fri, 27 Jan 2017 01:01:04 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x230.google.com with SMTP id k15so107542765qtg.3 for ; Thu, 26 Jan 2017 17:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=31eOOFY9ORi2rPRHZMcLXRwf10zpk41X76HzSb5a/Cc=; b=csrDPMgSm5OYWmlKmQao09DfNXYErcbbjb9rsgGgzLiLgTdFC4shjiBHCsuMaYtK41 R89Ke/RQcE85wNndfVv6LSeaei+Sk9D0UBfsAo1nY21AzWFb/+RnnnezszjVreVCOOXh zAa96yB961ziMoXXiVvYA99KsKrTXpomH7LUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=31eOOFY9ORi2rPRHZMcLXRwf10zpk41X76HzSb5a/Cc=; b=I6JqtCx/3r/v/jJRDBmk5sll/tMk3poaJeOGPZmdBpsmPbprFrU2ZPm5DdNZdyKlyd cFd0QOH+ToUxgIfQoXtSm2jP4wS+1urEAiw5L8J4PlLN/Rq4cbQU4hUqWqQBCtb1DMGO nDUlU00urSGvZFj/z7XsG6xHzwrB56gvS2eSn0VpCSYzOPTF4pZGNK87sSvq9dCg7AD9 dI+67QXmxgpmV/hMVlMaVoxAwH1scgMf+pnGRtf9fUmjQkD+qQiH8qcsvnHHJNKTO/lQ AhoW2Ux+/fKj9rxP1I82uyyA0fHZrm6WCyd2HwzZ1/mFHh1yqwdwzTY0xUqho0YTe6dv ORQg== X-Gm-Message-State: AIkVDXJ6V3EcWFu/Owby+Xd3lGBYVrLr26loeCIlyCdsyHvFYYSSZPQc2f1Bj/eyec44Gw== X-Received: by 10.237.36.12 with SMTP id r12mr5242450qtc.32.1485478862612; Thu, 26 Jan 2017 17:01:02 -0800 (PST) Received: from [192.168.0.11] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id k19sm2698973qtf.37.2017.01.26.17.01.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 17:01:02 -0800 (PST) Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> Date: Thu, 26 Jan 2017 22:00:48 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170125221350.GA92571@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 27 Jan 2017 01:01:05 -0000 Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > Otacílio (otacilio.neto@bsd.com.br) wrote: >> Dears >> >> I'm trying boot a FreeBSD12-armv6-r312227 >> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot >> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I >> downloaded from >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ >> works fine, but when I try boot the image that I build on my machine >> using crouchet I get: >> >> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) >> Trying to boot from MMC1MMC partition switch failed >> *** Warning - MMC partition switch failed, using default environment >> >> reading u-boot.img >> reading u-boot.img >> >> And boot stops. Someone can confirm that the revision 312227 is working >> fine? > I did some digging at the breakage is caused by this commit in U-Boot: > https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html > > Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > the problem. Try applying this patch to crochet and re-build image: > > https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff > I have applied the patch and now I'm getting this error. Some hints? []'s -Otacílio U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) Trying to boot from MMC1MMC partition switch failed *** Warning - MMC partition switch failed, using default environment reading u-boot.img reading u-boot.img U-Boot 2017.01-rc3 (Jan 22 2017 - 23:17:18 -0300) CPU : AM335X-GP rev 2.0 I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - bad CRC, using default environment not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt 0 bytes read in 4 ms (0 Bytes/s) Loaded env from uEnv.txt Importing environment from mmc0 ... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 230992 bytes read in 22 ms (10 MiB/s) ## Starting application at 0x82000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x9df30c58 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Thu Jan 26 16:55:20 BRT 2017 ota@squitch) DRAM: 512MB Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x609624+0x1a29dc syms=[0x4+0x89070+0x4+0x9d363] /boot/kernel/geom_label.ko text=0x4de8 data=0x870+0x4 syms=[0x4+0x12c0+0x4+0x1061] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! Type '?' for a list of commands, 'help' for more detailed help. loader> From owner-freebsd-arm@freebsd.org Fri Jan 27 01:31: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 E995BCC353B for ; Fri, 27 Jan 2017 01:31:51 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 C189D3EC for ; Fri, 27 Jan 2017 01:31:51 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cWvOB-0000m0-BL; Thu, 26 Jan 2017 17:31:46 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0R1Vgdv002975; Thu, 26 Jan 2017 17:31:42 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Thu, 26 Jan 2017 17:31:42 -0800 From: Oleksandr Tymoshenko To: =?iso-8859-1?Q?Otac=EDlio?= Cc: "freebsd-arm@freebsd.org" Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black Message-ID: <20170127013142.GA2921@bluezbox.com> References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Otacílio (otacilio.neto@bsd.com.br) wrote: > Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > > Otacílio (otacilio.neto@bsd.com.br) wrote: > >> Dears > >> > >> I'm trying boot a FreeBSD12-armv6-r312227 > >> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > >> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > >> downloaded from > >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > >> works fine, but when I try boot the image that I build on my machine > >> using crouchet I get: > >> > >> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > >> Trying to boot from MMC1MMC partition switch failed > >> *** Warning - MMC partition switch failed, using default environment > >> > >> reading u-boot.img > >> reading u-boot.img > >> > >> And boot stops. Someone can confirm that the revision 312227 is working > >> fine? > > I did some digging at the breakage is caused by this commit in U-Boot: > > https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html > > > > Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > > the problem. Try applying this patch to crochet and re-build image: > > > > https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff > > > I have applied the patch and now I'm getting this error. Some hints? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bsd.com.br] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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, 27 Jan 2017 01:31:52 -0000 Otacílio (otacilio.neto@bsd.com.br) wrote: > Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > > Otacílio (otacilio.neto@bsd.com.br) wrote: > >> Dears > >> > >> I'm trying boot a FreeBSD12-armv6-r312227 > >> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > >> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > >> downloaded from > >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > >> works fine, but when I try boot the image that I build on my machine > >> using crouchet I get: > >> > >> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > >> Trying to boot from MMC1MMC partition switch failed > >> *** Warning - MMC partition switch failed, using default environment > >> > >> reading u-boot.img > >> reading u-boot.img > >> > >> And boot stops. Someone can confirm that the revision 312227 is working > >> fine? > > I did some digging at the breakage is caused by this commit in U-Boot: > > https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html > > > > Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > > the problem. Try applying this patch to crochet and re-build image: > > > > https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff > > > I have applied the patch and now I'm getting this error. Some hints? FreeBSD uses dtb names that do not match upstream ones. After updating to 2017.01 that change was lost in progress. Possible workaround (HACK ALERT!!!) would be to do something like this: => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' => saveenv Copy-paste to U-Boot serial console does not work for me on BBB, so you'll have have to enter these commands I will submit update to u-boot ports so all these workarounds will not be required. -- gonzo From owner-freebsd-arm@freebsd.org Fri Jan 27 01:56: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 4AE18CC3994 for ; Fri, 27 Jan 2017 01:56:13 +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 EB5E3E94 for ; Fri, 27 Jan 2017 01:56:12 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x233.google.com with SMTP id x49so108366446qtc.2 for ; Thu, 26 Jan 2017 17:56:12 -0800 (PST) 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:content-transfer-encoding; bh=Qwzdjc1rpTyKz/pn1vEYKXY4hcxrHh/3mq7JaagQIcc=; b=SXJ2nUFOYPmhvYU8tu2xmeu5qvLfdmaBjAZTO9+7oeTfb0YL5/RHNGOsRKSq/q+Ccs mhb3S+1a7Rqo+ZEDyIcDrDl6HmQeF3raLcybTfQlk+Lz6ReQMwEuHBCL9x3quTpgMD6R XFmhsMrggJBw+wEO9uBQ3tpiRCUDDExJxhGos= 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:content-transfer-encoding; bh=Qwzdjc1rpTyKz/pn1vEYKXY4hcxrHh/3mq7JaagQIcc=; b=PyYthr3iHoyeLqCyqC597bFSPezPdIBX2WfdysL6pvuz7DG2E9EeYfBifIETCSDeth f2q/9uBcJAJiqrzvbvuo53ioGUj/wDuR7PxnYK39Av5GJGt6yt4FjZvCMGRfVu4AAdfP KU4QYr/Pb3NhrPdIfKmbJuxVTLraeyxryQDBXmhmvEneeKb+ymg7iCk0PpVjaKQJsQdy ONnlxwUnoDFpftkAcGtc9fSfUILDEXsf/+32aI1+xAa+ulHDlUHq/IFTagGvbtrfDZNH Xi8RgTLRLei5ea9dzKcvS8OOVkULtZ0DMOf8zt8KfczEpVToRgTmJzOAW1Ycb3Jb+lPa m8sg== X-Gm-Message-State: AIkVDXIdy4VIuB+x+nzOeVdDIbvN9jcV+hMb/RT8s4BLROKgyepKc8S3JoM4kVYpfeWJng== X-Received: by 10.200.57.27 with SMTP id s27mr5423369qtb.230.1485482171915; Thu, 26 Jan 2017 17:56:11 -0800 (PST) Received: from [192.168.0.11] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id m27sm2845248qtf.19.2017.01.26.17.56.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 17:56:11 -0800 (PST) Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black To: Oleksandr Tymoshenko References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> <20170127013142.GA2921@bluezbox.com> Cc: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <13aa921f-b65f-8bf6-f298-ccb286c7ed6e@bsd.com.br> Date: Thu, 26 Jan 2017 22:55:59 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170127013142.GA2921@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 27 Jan 2017 01:56:13 -0000 Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > Otacílio (otacilio.neto@bsd.com.br) wrote: >> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: >>> Otacílio (otacilio.neto@bsd.com.br) wrote: >>>> Dears >>>> >>>> I'm trying boot a FreeBSD12-armv6-r312227 >>>> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot >>>> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I >>>> downloaded from >>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ >>>> works fine, but when I try boot the image that I build on my machine >>>> using crouchet I get: >>>> >>>> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) >>>> Trying to boot from MMC1MMC partition switch failed >>>> *** Warning - MMC partition switch failed, using default environment >>>> >>>> reading u-boot.img >>>> reading u-boot.img >>>> >>>> And boot stops. Someone can confirm that the revision 312227 is working >>>> fine? >>> I did some digging at the breakage is caused by this commit in U-Boot: >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html >>> >>> Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes >>> the problem. Try applying this patch to crochet and re-build image: >>> >>> https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff >>> >> I have applied the patch and now I'm getting this error. Some hints? > FreeBSD uses dtb names that do not match upstream ones. After updating > to 2017.01 that change was lost in progress. Possible workaround (HACK > ALERT!!!) would be to do something like this: > > => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > => saveenv > > Copy-paste to U-Boot serial console does not work for me on BBB, so > you'll have have to enter these commands > > I will submit update to u-boot ports so all these workarounds will > not be required. > I'm getting this: Type '?' for a list of commands, 'help' for more detailed help. loader> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' Error: stack underflow loader> []'s -Otacilio From owner-freebsd-arm@freebsd.org Fri Jan 27 02:00:38 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 9E569CC3A7F for ; Fri, 27 Jan 2017 02:00:38 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 6E4C2DF for ; Fri, 27 Jan 2017 02:00:38 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cWvq8-0000qG-EZ; Thu, 26 Jan 2017 18:00:38 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0R20Zu0003239; Thu, 26 Jan 2017 18:00:35 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Thu, 26 Jan 2017 18:00:35 -0800 From: Oleksandr Tymoshenko To: =?iso-8859-1?Q?Otac=EDlio?= Cc: "freebsd-arm@freebsd.org" Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black Message-ID: <20170127020035.GA3187@bluezbox.com> References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> <20170127013142.GA2921@bluezbox.com> <13aa921f-b65f-8bf6-f298-ccb286c7ed6e@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13aa921f-b65f-8bf6-f298-ccb286c7ed6e@bsd.com.br> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Otacílio (otacilio.neto@bsd.com.br) wrote: > Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > > Otacílio (otacilio.neto@bsd.com.br) wrote: > >> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > >>> Otacílio (otacilio.neto@bsd.com.br) wrote: > >>>> Dears > >>>> > >>>> I'm trying boot a FreeBSD12-armv6-r312227 > >>>> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > >>>> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > >>>> downloaded from > >>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > >>>> works fine, but when I try boot the image that I build on my machine > >>>> using crouchet I get: > >>>> > >>>> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > >>>> Trying to boot from MMC1MMC partition switch failed > >>>> *** Warning - MMC partition switch failed, using default environment > >>>> > >>>> reading u-boot.img > >>>> reading u-boot.img > >>>> > >>>> And boot stops. Someone can confirm that the revision 312227 is working > >>>> fine? > >>> I did some digging at the breakage is caused by this commit in U-Boot: > >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html > >>> > >>> Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > >>> the problem. Try applying this patch to crochet and re-build image: > >>> > >>> https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff > >>> > >> I have applied the patch and now I'm getting this error. Some hints? > > FreeBSD uses dtb names that do not match upstream ones. After updating > > to 2017.01 that change was lost in progress. Possible workaround (HACK > > ALERT!!!) would be to do something like this: > > > > => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > > => saveenv > > > > Copy-paste to U-Boot serial console does not work for me on BBB, so > > you'll have have to enter these commands > > > > I will submit update to u-boot ports so all these workarounds will > > not be required. > > > I'm getting this: > > Type '?' for a list of [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: mail-archive.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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, 27 Jan 2017 02:00:38 -0000 Otacílio (otacilio.neto@bsd.com.br) wrote: > Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > > Otacílio (otacilio.neto@bsd.com.br) wrote: > >> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > >>> Otacílio (otacilio.neto@bsd.com.br) wrote: > >>>> Dears > >>>> > >>>> I'm trying boot a FreeBSD12-armv6-r312227 > >>>> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > >>>> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > >>>> downloaded from > >>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > >>>> works fine, but when I try boot the image that I build on my machine > >>>> using crouchet I get: > >>>> > >>>> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > >>>> Trying to boot from MMC1MMC partition switch failed > >>>> *** Warning - MMC partition switch failed, using default environment > >>>> > >>>> reading u-boot.img > >>>> reading u-boot.img > >>>> > >>>> And boot stops. Someone can confirm that the revision 312227 is working > >>>> fine? > >>> I did some digging at the breakage is caused by this commit in U-Boot: > >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html > >>> > >>> Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > >>> the problem. Try applying this patch to crochet and re-build image: > >>> > >>> https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff > >>> > >> I have applied the patch and now I'm getting this error. Some hints? > > FreeBSD uses dtb names that do not match upstream ones. After updating > > to 2017.01 that change was lost in progress. Possible workaround (HACK > > ALERT!!!) would be to do something like this: > > > > => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > > => saveenv > > > > Copy-paste to U-Boot serial console does not work for me on BBB, so > > you'll have have to enter these commands > > > > I will submit update to u-boot ports so all these workarounds will > > not be required. > > > I'm getting this: > > Type '?' for a list of commands, 'help' for more detailed help. > loader> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > Error: stack underflow > loader> No, setenv/saveenv should be done in u-boot. But this gave me an idea. You can also mount root partition on SD card and add following line to /boot/loader.conf: fdt_file="beaglebone-black.dtb" That should do the trick as well -- gonzo From owner-freebsd-arm@freebsd.org Fri Jan 27 02:21: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 81E53CC3DC3 for ; Fri, 27 Jan 2017 02:21:47 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 444C3C1C for ; Fri, 27 Jan 2017 02:21:47 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x22f.google.com with SMTP id v23so109780776qtb.0 for ; Thu, 26 Jan 2017 18:21:47 -0800 (PST) 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:content-transfer-encoding; bh=j7EV4Xq9uBmCLxay1yutavr7V3+6JPdwYWaD+jat9Vo=; b=SCobGfeVSQqGD3R0Cip3TODq+8i7ohfoieyqObuBfbWjI5MtIv44tXfk/EsGyqNoVU jcg41AGpZBOh6BM/KdxYg+ektt/g6jPEo4P0q9t09LLZu8grWSB2UHHO5gW8SOeXup3T 5FNpUCw6OQPW5m2W2ot8OtsoXS5dxSKj2Vv84= 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:content-transfer-encoding; bh=j7EV4Xq9uBmCLxay1yutavr7V3+6JPdwYWaD+jat9Vo=; b=ij6yaatMu7z7o9Vmba9q7z/ORApMCP0fOIvAse1pjSun2ov2KcSmoiMDXs/QNhkd/i 63bYEkrEdttd6x97rf3GKN7KhUpikmf6W/LmRV1Kq7GEYVAqqtsUKoH63YXSFMVc6uUa 4GoVVtSi3TlC31csdHzkHCSJ1iKUknoOGmFA0KHG69QdfVeT54ec2FenFqRfP+dni5Ow aXDBu5r39YCZOSXaqnTSC9C5naCTHbbyK6itrBxB1TawgaFKn5pE3KeWWCNwll68ElZh P8gxAWb+HI6pYJZf+3n38niojM05+aaCAiqHj1k5urgP89HPURsl+L4bHL45wWBUDKsP eNpg== X-Gm-Message-State: AIkVDXKyOvGX3KF7MQcgVEHgEzTfY7Bjw6Jg0fYvEP7nBato5Wze5ua7X0/nQcz2uXK6EQ== X-Received: by 10.55.19.66 with SMTP id d63mr5723174qkh.73.1485483705962; Thu, 26 Jan 2017 18:21:45 -0800 (PST) Received: from [192.168.0.11] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id t7sm2901319qtb.11.2017.01.26.18.21.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 18:21:45 -0800 (PST) Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black To: Oleksandr Tymoshenko References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> <20170127013142.GA2921@bluezbox.com> <13aa921f-b65f-8bf6-f298-ccb286c7ed6e@bsd.com.br> <20170127020035.GA3187@bluezbox.com> Cc: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <55637733-f4f5-6bcc-1d00-4c4b7d1b1b3d@bsd.com.br> Date: Thu, 26 Jan 2017 23:21:33 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170127020035.GA3187@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 27 Jan 2017 02:21:47 -0000 Em 26/01/2017 23:00, Oleksandr Tymoshenko escreveu: > Otacílio (otacilio.neto@bsd.com.br) wrote: >> Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: >>> Otacílio (otacilio.neto@bsd.com.br) wrote: >>>> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: >>>>> Otacílio (otacilio.neto@bsd.com.br) wrote: >>>>>> Dears >>>>>> >>>>>> I'm trying boot a FreeBSD12-armv6-r312227 >>>>>> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot >>>>>> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I >>>>>> downloaded from >>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ >>>>>> works fine, but when I try boot the image that I build on my machine >>>>>> using crouchet I get: >>>>>> >>>>>> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) >>>>>> Trying to boot from MMC1MMC partition switch failed >>>>>> *** Warning - MMC partition switch failed, using default environment >>>>>> >>>>>> reading u-boot.img >>>>>> reading u-boot.img >>>>>> >>>>>> And boot stops. Someone can confirm that the revision 312227 is working >>>>>> fine? >>>>> I did some digging at the breakage is caused by this commit in U-Boot: >>>>> https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html >>>>> >>>>> Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes >>>>> the problem. Try applying this patch to crochet and re-build image: >>>>> >>>>> https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff >>>>> >>>> I have applied the patch and now I'm getting this error. Some hints? >>> FreeBSD uses dtb names that do not match upstream ones. After updating >>> to 2017.01 that change was lost in progress. Possible workaround (HACK >>> ALERT!!!) would be to do something like this: >>> >>> => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' >>> => saveenv >>> >>> Copy-paste to U-Boot serial console does not work for me on BBB, so >>> you'll have have to enter these commands >>> >>> I will submit update to u-boot ports so all these workarounds will >>> not be required. >>> >> I'm getting this: >> >> Type '?' for a list of commands, 'help' for more detailed help. >> loader> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' >> Error: stack underflow >> loader> > No, setenv/saveenv should be done in u-boot. But this gave me > an idea. You can also mount root partition on SD card and > add following line to /boot/loader.conf: > > fdt_file="beaglebone-black.dtb" > > That should do the trick as well > I have added fdt_file="bboneblk.dtb" (because this is the name that I found on fat partition) to /boot/loader.conf but still getting DRAM: 512MB Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x609624+0x1a29dc syms=[0x4+0x89070+0x4+0x9d363] /boot/kernel/geom_label.ko text=0x4de8 data=0x870+0x4 syms=[0x4+0x12c0+0x4+0x1061] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! Type '?' for a list of commands, 'help' for more detailed help. loader> From owner-freebsd-arm@freebsd.org Fri Jan 27 02:27:48 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 B94AFCC3290 for ; Fri, 27 Jan 2017 02:27:48 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 88034F7B for ; Fri, 27 Jan 2017 02:27:47 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cWwGQ-0000tt-My; Thu, 26 Jan 2017 18:27:47 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0R2Rk6u003464; Thu, 26 Jan 2017 18:27:46 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Thu, 26 Jan 2017 18:27:46 -0800 From: Oleksandr Tymoshenko To: =?iso-8859-1?Q?Otac=EDlio?= Cc: "freebsd-arm@freebsd.org" Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black Message-ID: <20170127022746.GA3433@bluezbox.com> References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> <20170127013142.GA2921@bluezbox.com> <13aa921f-b65f-8bf6-f298-ccb286c7ed6e@bsd.com.br> <20170127020035.GA3187@bluezbox.com> <55637733-f4f5-6bcc-1d00-4c4b7d1b1b3d@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55637733-f4f5-6bcc-1d00-4c4b7d1b1b3d@bsd.com.br> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Otacílio (otacilio.neto@bsd.com.br) wrote: > Em 26/01/2017 23:00, Oleksandr Tymoshenko escreveu: > > Otacílio (otacilio.neto@bsd.com.br) wrote: > >> Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > >>> Otacílio (otacilio.neto@bsd.com.br) wrote: > >>>> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > >>>>> Otacílio (otacilio.neto@bsd.com.br) wrote: > >>>>>> Dears > >>>>>> > >>>>>> I'm trying boot a FreeBSD12-armv6-r312227 > >>>>>> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > >>>>>> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > >>>>>> downloaded from > >>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > >>>>>> works fine, but when I try boot the image that I build on my machine > >>>>>> using crouchet I get: > >>>>>> > >>>>>> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > >>>>>> Trying to boot from MMC1MMC partition switch failed > >>>>>> *** Warning - MMC partition switch failed, using default environment > >>>>>> > >>>>>> reading u-boot.img > >>>>>> reading u-boot.img > >>>>>> > >>>>>> And boot stops. Someone can confirm that the revision 312227 is working > >>>>>> fine? > >>>>> I did some digging at the breakage is caused by this commit in U-Boot: > >>>>> https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html > >>>>> > >>>>> Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > >>>>> the problem. Try applying this patch to crochet and re-build image: > >>>>> > >>>>> https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff > >>>>> > >>>> I have applied the patch and now I'm getting this error. Some hints? > >>> FreeBSD uses dtb names that do not match upstream ones. After updating > >>> to 2017.01 that change was lost in progress. Possible workaround (HACK > >>> ALERT!!!) would be to do something like this: > >>> > >>> => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > >>> => saveenv > >>> > >>> Copy-paste to U-Boot serial console does not work for me on BBB, so > >>> you'll have [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: mail-archive.com] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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, 27 Jan 2017 02:27:48 -0000 Otacílio (otacilio.neto@bsd.com.br) wrote: > Em 26/01/2017 23:00, Oleksandr Tymoshenko escreveu: > > Otacílio (otacilio.neto@bsd.com.br) wrote: > >> Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > >>> Otacílio (otacilio.neto@bsd.com.br) wrote: > >>>> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > >>>>> Otacílio (otacilio.neto@bsd.com.br) wrote: > >>>>>> Dears > >>>>>> > >>>>>> I'm trying boot a FreeBSD12-armv6-r312227 > >>>>>> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot > >>>>>> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I > >>>>>> downloaded from > >>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/ > >>>>>> works fine, but when I try boot the image that I build on my machine > >>>>>> using crouchet I get: > >>>>>> > >>>>>> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) > >>>>>> Trying to boot from MMC1MMC partition switch failed > >>>>>> *** Warning - MMC partition switch failed, using default environment > >>>>>> > >>>>>> reading u-boot.img > >>>>>> reading u-boot.img > >>>>>> > >>>>>> And boot stops. Someone can confirm that the revision 312227 is working > >>>>>> fine? > >>>>> I did some digging at the breakage is caused by this commit in U-Boot: > >>>>> https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html > >>>>> > >>>>> Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > >>>>> the problem. Try applying this patch to crochet and re-build image: > >>>>> > >>>>> https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff > >>>>> > >>>> I have applied the patch and now I'm getting this error. Some hints? > >>> FreeBSD uses dtb names that do not match upstream ones. After updating > >>> to 2017.01 that change was lost in progress. Possible workaround (HACK > >>> ALERT!!!) would be to do something like this: > >>> > >>> => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > >>> => saveenv > >>> > >>> Copy-paste to U-Boot serial console does not work for me on BBB, so > >>> you'll have have to enter these commands > >>> > >>> I will submit update to u-boot ports so all these workarounds will > >>> not be required. > >>> > >> I'm getting this: > >> > >> Type '?' for a list of commands, 'help' for more detailed help. > >> loader> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > >> Error: stack underflow > >> loader> > > No, setenv/saveenv should be done in u-boot. But this gave me > > an idea. You can also mount root partition on SD card and > > add following line to /boot/loader.conf: > > > > fdt_file="beaglebone-black.dtb" > > > > That should do the trick as well > > > I have added > > fdt_file="bboneblk.dtb" > > (because this is the name that I found on fat partition) to > /boot/loader.conf but still getting No, in this case it's not about what's on FAT it's what in /boot/dtb/ on root partition. That's where loader looks for DTB files. I don't have crochet setup handy right now so can't check end-to-end procedure, but I'll do it tomorrow. > > DRAM: 512MB > Number of U-Boot devices: 3 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=... good. > Booting from disk0s2a: > /boot/kernel/kernel data=0x609624+0x1a29dc syms=[0x4+0x89070+0x4+0x9d363] > /boot/kernel/geom_label.ko text=0x4de8 data=0x870+0x4 > syms=[0x4+0x12c0+0x4+0x1061] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > No valid device tree blob found! -- gonzo From owner-freebsd-arm@freebsd.org Fri Jan 27 02:28: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 29936CC32C7 for ; Fri, 27 Jan 2017 02:28:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 0D48CFD7 for ; Fri, 27 Jan 2017 02:28:11 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 18e7ad05-e438-11e6-b3c1-c9f38144898e 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 outbound2.ore.mailhop.org (Halon) with ESMTPSA id 18e7ad05-e438-11e6-b3c1-c9f38144898e; Fri, 27 Jan 2017 02:27:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0R2R3kg004814; Thu, 26 Jan 2017 19:27:03 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485484023.30533.102.camel@freebsd.org> Subject: Re: BBB uarts & pps dts definitions From: Ian Lepore To: Tony Hain , freebsd-arm@freebsd.org Date: Thu, 26 Jan 2017 19:27:03 -0700 In-Reply-To: <041a01d2782d$bee11850$3ca348f0$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> <040101d27816$3f7547b0$be5fd710$@tndh.net> <1485466405.30533.96.camel@freebsd.org> <041a01d2782d$bee11850$3ca348f0$@tndh.net> 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: Fri, 27 Jan 2017 02:28:12 -0000 On Thu, 2017-01-26 at 15:41 -0800, Tony Hain wrote: > > > > > -----Original Message----- > > From: Ian Lepore [mailto:ian@freebsd.org] > > Sent: Thursday, January 26, 2017 1:33 PM > > To: Tony Hain; freebsd-arm@freebsd.org > > Subject: Re: BBB uarts & pps dts definitions > > > > On Thu, 2017-01-26 at 12:53 -0800, Tony Hain wrote: > > > > > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > snip > > > > > > > > > > [even more snip] > That makes some degree of sense based on what I am seeing, though that is a > very low input impedance on the BBB. I was expecting ~100k. My source is a > 555 on an ancient ttl/RS232 board I built because the 20 us pulse from the > GPS was too fast (between the slew rate of the 3232 and the DCD detection > window on the com port) to go with a simple level conversion. Sounds like it > might be best to do an active 3.3v driver at this point. > > Tony BTW, not related to the BB stuff... a while back I added "narrow pulse capture" support to uart(4) for CTS/DCD PPS capture, you can use it with pulses as narrow as 1uS, maybe even less on some hardware.  The tradeoff is that you can only capture assert edges, not clear.  The support goes back to 10.3 or so, details are in the uart(4) manpage. -- Ian From owner-freebsd-arm@freebsd.org Fri Jan 27 04:17: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 80297CC3110 for ; Fri, 27 Jan 2017 04:17:40 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 6358F6F for ; Fri, 27 Jan 2017 04:17:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8b176ffb-e447-11e6-b3c1-c9f38144898e 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 outbound2.ore.mailhop.org (Halon) with ESMTPSA id 8b176ffb-e447-11e6-b3c1-c9f38144898e; Fri, 27 Jan 2017 04:17:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0R4HalE004954; Thu, 26 Jan 2017 21:17:36 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485490656.30533.111.camel@freebsd.org> Subject: Re: BBB uarts & pps dts definitions From: Ian Lepore To: Tony Hain , freebsd-arm@freebsd.org Date: Thu, 26 Jan 2017 21:17:36 -0700 In-Reply-To: <041a01d2782d$bee11850$3ca348f0$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> <040101d27816$3f7547b0$be5fd710$@tndh.net> <1485466405.30533.96.camel@freebsd.org> <041a01d2782d$bee11850$3ca348f0$@tndh.net> 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: Fri, 27 Jan 2017 04:17:40 -0000 On Thu, 2017-01-26 at 15:41 -0800, Tony Hain wrote: > > > > > -----Original Message----- > > From: Ian Lepore [mailto:ian@freebsd.org] > > Sent: Thursday, January 26, 2017 1:33 PM > > To: Tony Hain; freebsd-arm@freebsd.org > > Subject: Re: BBB uarts & pps dts definitions > > > > On Thu, 2017-01-26 at 12:53 -0800, Tony Hain wrote: > > > > > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > snip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Even when it gets built though, the scope shows that the > > > > > > signal > > > > > > is being pulled to ground as soon as the wire is connected > > > > > > to > > > > > > P8- 7, so I don't > > > > > expect it > > > > > > > > > > > > > > > > > > > > > > > > to work. Is there a way to check the state of the gpio? I > > > > > > would > > > > > > expect something like # gpioctl -N gpio_66 Can't find pin > > > > > > named > > > > > > "gpio_66" > > > > > > > > > > > > # gpioctl -l > > > > > > pin 00: 0       gpio_0<> > > > > > > pin 01: 0       gpio_1<> > > > > > > ... > > > > > > pin 30: 1       gpio_30 > > > > > > pin 31: 1       gpio_31 > > > > > > # > > > > > > > > > > > > How do the 3 additional pinmux controllers get enabled? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   ./ppsapitest /dev/dmtpps > > > > > > > > > > > > > > You should get something like: > > > > > > > > > > > > > >   1485400775 .009578536 204 0 .000000000 0 > > > > > > >   1485400776 .009621995 205 0 .000000000 0 > > > > > > >   1485400777 .009665453 206 0 .000000000 0 > > > > > > >   1485400778 .009708869 207 0 .000000000 0 > > > > > > > > > > > > > > -- Ian > > > > Everything I'm doing is with 12-current, but things shouldn't > > > > be > > > > very > > > different > > > > > > > > > > > > in 11-stable. > > > > > > > > Pin P8-7 is pin 2 on controller 2, so > > > > > > > >   gpioctl -f /dev/gpcio2 -l > > > > > > > > when it's configured correctly it should look like: > > > > > > > >   pin 02: 0       gpio_2<> > > > # gpioctl -lv -f /dev/gpioc2 > > > pin 00: 1       gpio_0, > > > > > caps: > OWN> > > > > > > pin 01: 0       gpio_1, > > > > > caps: > OWN> > > > > > > pin 02: 0       gpio_2<>, > > > > > caps: > OWN> > > > > > > ... > > > > > > So it looks like gpioctl defaults to the first controller if none > > > are > > > listed, since  gpioctl -lv only shows the first 32. Nothing in > > > gpioctl > > > -h indicates that would be the case, though the framework wiki > > > does > > > mention a restriction at 32 in the hint files discussion. Nothing > > > in > > > -h, the man page, or the wiki indicates what -t -c or -n do, so I > > > am > > > reluctant to try them. I would guess toggle, capabilities, and > > > name, > > > but the help and documentation should really be clear about that, > > > and > > > how to set direction. > > > > > All good points, but really, gpio has nothing to do with this > > stuff. > Simply trying to figure out how to diagnose the gpio pin, and the ctl > tool > is not clear about how to use it. > > > > > > > > > > > > > > > > > > > > > > > > If you do a verbose boot (in loader, at the prompt do boot -v) > > > > do > > > > you see > > > > these two lines right before the am335x_dmtimer0: line? > > > > > > > >   ti_pinmux0: setting internal 2a for timer4 > > > >   am335x_dmtpps: configured pin P8-7 as input for timer4 > > > Booting from disk0s2a: > > > /boot/kernel/kernel data=0x6d6564+0x145a9c > > > syms=[0x4+0x7eb30+0x4+0x922fa] > > > /boot/kernel/am335x_dmtpps.ko text=0x1c60 data=0x224+0x8 > > > syms=[0x4+0x820+0x4+0x742] > > > > > > loader> boot -v > > > > > > # dmesg | grep er4 > > > ti_pinmux0: setting internal 2a for timer4 > > > am335x_dmtpps: configured pin P8-7 as input for timer4 > > Yep, this indicates the config is right, so the problem must be > > electrical. > > > > > > > > am335x_dmtpps0: mem 0x48044000- > > > 0x480443ff irq > > > 30 on simplebus0 > > > Timecounter "DMTimer4" frequency 24000000 Hz quality 1000 > > > am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps > > > > > > So all that looks as you indicated it should, though I am > > > troubled > > > that pin > > > 2 is not restricted to IN on the gpioctl listing. It does say > > > configured as > > > input in dmesg, so it should be doing the right thing. > > > > > Pin 2 is not listed as because it's not a gpio pin anymore > > after > > being reconfigured as TIMER4 input.  The empty brackets indicate > > that > > it has been configured as a device pin, not gpio. > Ok. That is another point that would be helpful if it were on the > wiki. > > > > > > > > > > > The only thing that comes to mind at this point is some > > > electrical > > > restriction about the BBB input, where a 5/3 resistive divider > > > (2.2k/3.3k) > > > is inadequate, but the fact that the uart is working would tend > > > to > > > rule that > > > out. Electrically it is acting as though the pin is set to Output > > > at > > > 0. > > > ...... As I typed that it occurred to me I should really check > > > that > > > it is 0, > > > and found that there actually is a correct pulse at 60mv. This > > > would > > > imply > > > that the input impedance of the pin is 26 ohms. The system > > > reference > > > manual > > > doesn't discuss input impedance that I can find, and search isn't > > > turning up > > > anything either. Why would the timer pin be different than the > > > uart > > > pin on > > > the same soc? What are you using to drive your pps? > > > > > > This is so close, there must be something really trivial that I > > > am > > > overlooking... > > > > > > Tony > > I'm using a 5v->3.3v level shifter right now, but I have in the > > past > > succesfully used resistive dividers.  My PPS output device is > > designed > > to drive 5v into a 50 ohm load, so when using a divider I just try > > various values I have handy until my scope says the voltage high > > level > > is somewhere in the 2.8-3.3v range.  Usually I use resistance that > > adds > > up to somewhere between 40-100 ohms when I do that (depends on what > > resistors pop out first when I reach into the bag of loosies). > > > > -- Ian > That makes some degree of sense based on what I am seeing, though > that is a > very low input impedance on the BBB. I was expecting ~100k. My source > is a > 555 on an ancient ttl/RS232 board I built because the 20 us pulse > from the > GPS was too fast (between the slew rate of the 3232 and the DCD > detection > window on the com port) to go with a simple level conversion. Sounds > like it > might be best to do an active 3.3v driver at this point. > > Tony > Well you were right, it all boiled down to electrical trouble, but it was caused by software, and I just committed a fix as r312859.  I'll MFC the fix to 11 in a few days (you could just grab the patch/source from -current and build a new kernel now). Even though the code was asking the pinmux driver to configure the pin as an input, there is also a bit in the timer control register that configures the pin as input or output for capture vs. pulse mode.  That setting apparently overrides the pinmux choice, so the timer block was driving a signal onto that pad.  (The code had a comment next to one bit in the control register defines "no description in datasheet".  That goes back to the original timer driver from years ago.  A newer copy of the manual is where I discovered that the bit is now described as input/output config.) I think my testing was working because my level-shifter was able to out-muscle the weaker drive in the TI chip.  As soon as I switched to a passive voltage divider it stopped working.  Now with the pin configured correctly it works fine for me, and probably will for you too. I find that it captures pulses as narrow as 100nS perfectly now.  A 10nS pulse it captures maybe 35% of the time.  (My timing hardware has no choices between 10nS and 100nS to try.) -- Ian From owner-freebsd-arm@freebsd.org Fri Jan 27 06:23: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 908E1CC3D58 for ; Fri, 27 Jan 2017 06:23:53 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CA74A63; Fri, 27 Jan 2017 06:23:53 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=Xg/PdRBAQQXZ/7gbStmfEmAsKpx5mTJ46wyJUvBsp2c=; b=A2vTtcID56wPWM4NoTpA7iSrYKMtoEHS+js/IkJ6xIZA1qdxif66kKhXcbHf89foT40uxf9RYL5EMQSF2TxatstFC0898otj6zfI1KzVEfZR1dKTfIUjWaEjaDXHCByv0BnP0hi5D9jE4D3SXb1ZiwULTqTy9HXISjK6LREAi2DsSyaQ; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cWzwe-000IoS-8c; Thu, 26 Jan 2017 22:23:51 -0800 From: "Tony Hain" To: "'Ian Lepore'" , References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> <040101d27816$3f7547b0$be5fd710$@tndh.net> <1485466405.30533.96.camel@freebsd.org> <041a01d2782d$bee11850$3ca348f0$@tndh.net> <1485490656.30533.111.camel@freebsd.org> In-Reply-To: <1485490656.30533.111.camel@freebsd.org> Date: Thu, 26 Jan 2017 22:23:36 -0800 Message-ID: <041b01d27865$e4c54810$ae4fd830$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEImxvIZ6VEPYS1CTeMHuF4SjTdHgFGeuiPAfagOS8BXCmlWAJOLTryAjf7KeUBQ5O/qAF4PpfTARF4btuieCtE4A== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Fri, 27 Jan 2017 06:23:53 -0000 Ian Lepore wrote: > > > > snip > > > > This is so close, there must be something really trivial that I = am > > > > overlooking... > > > > > > > > Tony > > > I'm using a 5v->3.3v level shifter right now, but I have in the = past > > > succesfully used resistive dividers. =A0My PPS output device is > > > designed to drive 5v into a 50 ohm load, so when using a divider I > > > just try various values I have handy until my scope says the = voltage > > > high level is somewhere in the 2.8-3.3v range. =A0Usually I use > > > resistance that adds up to somewhere between 40-100 ohms when I do > > > that (depends on what resistors pop out first when I reach into = the > > > bag of loosies). > > > > > > -- Ian > > That makes some degree of sense based on what I am seeing, though = that > > is a very low input impedance on the BBB. I was expecting ~100k. My > > source is a > > 555 on an ancient ttl/RS232 board I built because the 20 us pulse = from > > the GPS was too fast (between the slew rate of the 3232 and the DCD > > detection window on the com port) to go with a simple level > > conversion. Sounds like it might be best to do an active 3.3v driver > > at this point. > > > > Tony > > >=20 > Well you were right, it all boiled down to electrical trouble, but it = was caused > by software, and I just committed a fix as r312859. =A0I'll MFC the = fix to 11 in a > few days (you could just grab the patch/source from -current and build = a > new kernel now). >=20 > Even though the code was asking the pinmux driver to configure the pin = as > an input, there is also a bit in the timer control register that configures the pin > as input or output for capture vs. pulse mode. =A0That setting = apparently > overrides the pinmux choice, so the timer block was driving a signal = onto that > pad. =A0(The code had a comment next to one bit in the control = register defines > "no description in datasheet". > =A0That goes back to the original timer driver from years ago. =A0A = newer copy of > the manual is where I discovered that the bit is now described as > input/output config.) >=20 > I think my testing was working because my level-shifter was able to = out- > muscle the weaker drive in the TI chip. =A0As soon as I switched to a passive > voltage divider it stopped working. =A0Now with the pin configured = correctly it > works fine for me, and probably will for you too. >=20 > I find that it captures pulses as narrow as 100nS perfectly now. =A0A = 10nS pulse > it captures maybe 35% of the time. =A0(My timing hardware has no = choices > between 10nS and 100nS to try.) Glad to hear. I have been investigating alternatives for a driver, and = the mosfet approach I was gravitating toward would likely not have made any difference if the BBB was driving the signal because it is active low = with an even higher resistance pull-up. I will look into building a kernel, = I know there are instructions for the cross-compile tools, so it should be straight forward.=20 Last item, do you know if the DTS src includes the Beaglebone-Green? If = not, what can I do to help make that happen. Once I get the Black running, I = have a Green to build as its ~twin. Tony =20 From owner-freebsd-arm@freebsd.org Fri Jan 27 06:28: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 A2BEECC3DD2 for ; Fri, 27 Jan 2017 06:28:39 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72E67B24; Fri, 27 Jan 2017 06:28:39 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=cEBnUDl8wmr3yCZYPngCvS0m/PB+uWIMJ8aDOXVJc80=; b=AdGJeAbjtzBynbzL1TtQDs+zS+DFuHeDVV3+FhctaqaBtdCMiLTCYVWSQJtV90MYvyccqspbhgpEbNoRRdBfrDhdBe6IkLQDstsbMxnm5VL51is0r7E4m1nXeEjfJOM43oOL4ZlRa43HK3qILAQ3emi6/z0verb7AYvC4vFaQCy4j77D; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1cX01R-000It9-0N; Thu, 26 Jan 2017 22:28:38 -0800 From: "Tony Hain" To: "'Ian Lepore'" , References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> <040101d27816$3f7547b0$be5fd710$@tndh.net> <1485466405.30533.96.camel@freebsd.org> <041a01d2782d$bee11850$3ca348f0$@tndh.net> <1485484023.30533.102.camel@freebsd.org> In-Reply-To: <1485484023.30533.102.camel@freebsd.org> Date: Thu, 26 Jan 2017 22:28:23 -0800 Message-ID: <041c01d27866$95a6ce60$c0f46b20$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEImxvIZ6VEPYS1CTeMHuF4SjTdHgFGeuiPAfagOS8BXCmlWAJOLTryAjf7KeUBQ5O/qAF4PpfTAZ9+yj+ic7+uAA== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: BBB uarts & pps dts definitions X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.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: Fri, 27 Jan 2017 06:28:39 -0000 Ian Lepore wrote: =20 > On Thu, 2017-01-26 at 15:41 -0800, Tony Hain wrote: > > > > > > > > -----Original Message----- > > > From: Ian Lepore [mailto:ian@freebsd.org] > > > Sent: Thursday, January 26, 2017 1:33 PM > > > To: Tony Hain; freebsd-arm@freebsd.org > > > Subject: Re: BBB uarts & pps dts definitions > > > > > > On Thu, 2017-01-26 at 12:53 -0800, Tony Hain wrote: > > > > > > > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > snip > > > > > > > > > > > > [even more snip] > > That makes some degree of sense based on what I am seeing, though = that > > is a very low input impedance on the BBB. I was expecting ~100k. My > > source is a > > 555 on an ancient ttl/RS232 board I built because the 20 us pulse = from > > the GPS was too fast (between the slew rate of the 3232 and the DCD > > detection window on the com port) to go with a simple level > > conversion. Sounds like it might be best to do an active 3.3v driver = at this > point. > > > > Tony >=20 > BTW, not related to the BB stuff... a while back I added "narrow pulse > capture" support to uart(4) for CTS/DCD PPS capture, you can use it = with > pulses as narrow as 1uS, maybe even less on some hardware. =A0The = tradeoff is > that you can only capture assert edges, not clear. =A0The support goes = back to > 10.3 or so, details are in the uart(4) manpage. I saw references to that and was going to go looking for them again if = the timer pin approach failed. I was not overly hopeful though because it = was not clear to me how that would mesh with using NTPsec which would be expecting a DCD transition. Let's hope the fix in the other note = resolves this so I never have to worry about that. Tony =20 From owner-freebsd-arm@freebsd.org Fri Jan 27 06:58:31 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 B4347CC3512 for ; Fri, 27 Jan 2017 06:58:31 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 9E47295C for ; Fri, 27 Jan 2017 06:58:31 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 7502B406061; Thu, 26 Jan 2017 22:58:24 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: "Tony Hain" cc: freebsd-arm@freebsd.org, hmurray@megapathdsl.net From: Hal Murray Subject: Re: BBB uarts & pps dts definitions In-Reply-To: Message from "Tony Hain" of "Thu, 26 Jan 2017 22:28:23 PST." <041c01d27866$95a6ce60$c0f46b20$@tndh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Jan 2017 22:58:24 -0800 Message-Id: <20170127065824.7502B406061@ip-64-139-1-69.sjc.megapath.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: Fri, 27 Jan 2017 06:58:31 -0000 tony@tndh.net said: > I was not overly hopeful though because it was not clear to me how that > would mesh with using NTPsec which would be expecting a DCD transition. There is nothing magic about DCD as far as NTPsec is concerned. What it needs is a file name that can be turned into a file handle to pass to time_pps_create() I don't have PPS working on a BBB, but Linux works with PPS on GPIO on Raspberry Pi. -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Fri Jan 27 08:22:00 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 6F3A6CC2810 for ; Fri, 27 Jan 2017 08:22:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 2CFD5DFC for ; Fri, 27 Jan 2017 08:22:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id c7so51231405itd.1 for ; Fri, 27 Jan 2017 00:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=yNnPfNQIcl7r3FovHoh39jXgpGyqNIa0IrlD82/dZqE=; b=P4zgC9d4CO5a6AQ0524BHVI3CICad1kKF0OflWzHnRZ0L+ssbSUusMIp93Hqa2Kcaf rrBuGYWep8zTsoT434CmZXeiX+CuyZkXkFHPbngkFJkgvhY9mq/GXukVtRNUMzfUfXSO D64wU0PlE7/6RkrmfD+WE/ipu+8TpZlUKvIu0NHmiPWa+tGvkuMmyuewyDM53GFY1IeU RYhIRN+pq19g/pzWnGjCmkSU6deSD5I2m/JLamSIesw8OofOQtSsOyb/dV5hN4RI5x43 9Ec6BF5Ac8nYax3BeINthI0Nsct3eYb73yKHmDQTQ9O+Pdn/E3vD3nPgCTrJ3vNOqDa/ G7/A== 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=yNnPfNQIcl7r3FovHoh39jXgpGyqNIa0IrlD82/dZqE=; b=BMbWJx9quOQFZLKnqMvQdNG2fWkMx9J98+JJpCgahJLRltH7uzL48uu0k4Wa1JVZc5 J0NXLyM70ipVeZPbDbKZtV6zLjm6A6hplj0qk89Uo7CMt1YY3GbgHAx9e3M8wW/uOFu7 zwxWukecWf1A5BPODWm1mLTOhb4fWdEHk2NgHXqZVtH8tXMvgqIegwRduhTT/Yfm1KzW QQvuxpJKpz33fueYO3qF2qj4OEn402syGX8yBS5ujgWrDWsGyExDsV5/G4twsLVvJ+pm i5pXz1g4eW4VIz/U5xwxRutxBAzr6oUx8kUY9vUotDiQHkLeb9wxciFfrzreQolGIJI7 Yt4Q== X-Gm-Message-State: AIkVDXKzln+a0er0Vud0/BJGngC3PChkIGYQDEMrQYuOaqEftkV0V18VD2lu2Dr2debGmzSBW7tPD1KKAS1L+g== X-Received: by 10.36.178.21 with SMTP id u21mr2055751ite.103.1485505319332; Fri, 27 Jan 2017 00:21:59 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Fri, 27 Jan 2017 00:21:58 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <20170127013142.GA2921@bluezbox.com> References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> <20170127013142.GA2921@bluezbox.com> From: Warner Losh Date: Fri, 27 Jan 2017 01:21:58 -0700 X-Google-Sender-Auth: okhPCVUWPR36T1p37jPKANXqAkw Message-ID: Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black To: Oleksandr Tymoshenko Cc: =?UTF-8?B?T3RhY8OtbGlv?= , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Fri, 27 Jan 2017 08:22:00 -0000 On Thu, Jan 26, 2017 at 6:31 PM, Oleksandr Tymoshenko wrote: > Otac=C3=ADlio (otacilio.neto@bsd.com.br) wrote: >> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: >> > Otac=C3=ADlio (otacilio.neto@bsd.com.br) wrote: >> >> Dears >> >> >> >> I'm trying boot a FreeBSD12-armv6-r312227 >> >> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot >> >> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I >> >> downloaded from >> >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0= / >> >> works fine, but when I try boot the image that I build on my machine >> >> using crouchet I get: >> >> >> >> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) >> >> Trying to boot from MMC1MMC partition switch failed >> >> *** Warning - MMC partition switch failed, using default environment >> >> >> >> reading u-boot.img >> >> reading u-boot.img >> >> >> >> And boot stops. Someone can confirm that the revision 312227 is worki= ng >> >> fine? >> > I did some digging at the breakage is caused by this commit in U-Boot: >> > https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html >> > >> > Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes >> > the problem. Try applying this patch to crochet and re-build image: >> > >> > https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff >> > >> I have applied the patch and now I'm getting this error. Some hints? > > FreeBSD uses dtb names that do not match upstream ones. After updating > to 2017.01 that change was lost in progress. Possible workaround (HACK > ALERT!!!) would be to do something like this: > > =3D> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > =3D> saveenv > > Copy-paste to U-Boot serial console does not work for me on BBB, so > you'll have have to enter these commands > > I will submit update to u-boot ports so all these workarounds will > not be required. I half-way expected we'd have issues here. My notion was that we'd continue to use the upstream names and migrate our tools to create the proper links / copies as a transition. We'll have to migrate someday and might as well get started... Warner From owner-freebsd-arm@freebsd.org Fri Jan 27 10:19: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 CF50DCC40FB for ; Fri, 27 Jan 2017 10:19:50 +0000 (UTC) (envelope-from admin@ufa-help.ru) Received: from mail.ufa-help.ru (unknown [IPv6:2a01:4f8:161:32d1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82BEF19BC for ; Fri, 27 Jan 2017 10:19:50 +0000 (UTC) (envelope-from admin@ufa-help.ru) Received: from 46.191.135.224.dynamic.ufanet.ru (unknown [46.191.135.224]) by mail.ufa-help.ru (Postfix) with ESMTPA id CC12C72860C4 for ; Fri, 27 Jan 2017 12:53:21 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ufa-help.ru; s=default; t=1485510802; bh=mJKzzkJoS+B3yx6h2EFUvaUz1IjOTbZp5TsajHuLcWs=; h=From:To:Subject:Date:From; b=XTI62P/fwO4bHCKCWqHQMgRUxrpHFjMBgplhHHaKNwBSc1D6s0tDFBxicSxTegZLh LkjIxX+EHz1USI93uFj+HBl41JUNrQlT9C8Q2cxHPYALxxpiIpjueTSxLlaOOJLOz/ 6FTPiEkR0c7iJWZ4Li+lX+UD5Uu7++XXEl8mU+8g= Message-ID: <5B10E1C7E63B44669A00FC92DF852BF3@SERVER> From: =?utf-8?B?0JXQstCz0LXQvdC40Lk=?= To: Subject: =?utf-8?B?0J7QsdGB0LvRg9C20LjQstCw0L3QuNC1IDFDLCDRgdC10YLQtdC5LCDRgdC10YDQstC10YDQvtCyINC4INC60L7QvNC/0YzRjtGC0LXRgNC+0LIg0L3QsCDQv9C+0YHRgtC+0Y/QvdC90L7QuSDQvtGB0L3QvtCy0LUu?= Date: Fri, 27 Jan 2017 14:53:16 +0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 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: Fri, 27 Jan 2017 10:19:50 -0000 =D0=97=D0=B4=D1=80=D0=B0=D0=B2=D1=81=D1=82=D0=B2=D1=83=D0=B9=D1=82=D0=B5.= =D0=9C=D0=B5=D0=BD=D1=8F =D0=B7=D0=BE=D0=B2=D1=83=D1=82 =D0=95=D0=B2=D0=B3= =D0=B5=D0=BD=D0=B8=D0=B9. =D0=AF =D1=81=D0=B8=D1=81=D1=82=D0=B5=D0=BC=D0=BD= =D1=8B=D0=B9 =D0=B0=D0=B4=D0=BC=D0=B8=D0=BD=D0=B8=D1=81=D1=82=D1=80=D0=B0= =D1=82=D0=BE=D1=80 =D1=81 =D0=BE=D0=BF=D1=8B=D1=82=D0=BE=D0=BC =D1=80=D0=B0= =D0=B1=D0=BE=D1=82=D1=8B =D0=B1=D0=BE=D0=BB=D0=B5=D0=B5 12 =D0=BB=D0=B5=D1= =82. =D0=97=D0=B0=D0=BD=D0=B8=D0=BC=D0=B0=D1=8E=D1=81=D1=8C =D0=BE=D0=B1=D1= =81=D0=BB=D1=83=D0=B6=D0=B8=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5=D0=BC =D1=81=D0= =B5=D1=82=D0=B5=D0=B9, =D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1=80=D0=BE=D0=B2 =D0= =B8 =D0=BA=D0=BE=D0=BC=D0=BF=D1=8C=D1=8E=D1=82=D0=B5=D1=80=D0=BE=D0=B2 =D0= =BD=D0=B0 =D0=BF=D0=BE=D1=81=D1=82=D0=BE=D1=8F=D0=BD=D0=BD=D0=BE=D0=B9 =D0= =BE=D1=81=D0=BD=D0=BE=D0=B2=D0=B5 =D0=B2 =D0=BA=D0=BE=D0=BC=D0=BF=D0=B0=D0= =BD=D0=B8=D1=8F=D1=85 =D0=9C=D0=BE=D1=81=D0=BA=D0=B2=D1=8B =D0=B8 =D0=9F=D0= =BE=D0=B4=D0=BC=D0=BE=D1=81=D0=BA=D0=BE=D0=B2=D1=8C=D1=8F. =D0=92=D0=BE=D0= =B7=D0=BC=D0=BE=D0=B6=D0=BD=D0=BE=D1=81=D1=82=D1=8C =D0=BE=D0=BF=D0=BB=D0= =B0=D1=82=D1=8B =D0=B2 =D0=B1=D0=B5=D0=B7=D0=BD=D0=B0=D0=BB=D0=B8=D1=87=D0= =BD=D0=BE=D0=B9 =D1=84=D0=BE=D1=80=D0=BC=D0=B5. =20 =D0=9F=D1=80=D0=B5=D0=B4=D0=BB=D0=B0=D0=B3=D0=B0=D1=8E =D0=92=D0=B0=D0=BC= =D1=81=D0=B2=D0=BE=D0=B8 =D1=83=D1=81=D0=BB=D1=83=D0=B3=D0=B8: 1) =D0=9F=D1=80=D0=BE=D0=B3=D1=80=D0=B0=D0=BC=D0=BC=D1=8B =D1=81=D0=B5=D0= =BC=D0=B5=D0=B9=D1=81=D1=82=D0=B2=D0=B0 1=D1=81: =D0=A3=D1=81=D1=82=D0=B0=D0=BD=D0=BE=D0=B2=D0=BA=D0=B0 =D0=B8 =D0=BE=D0=B1= =D0=BD=D0=BE=D0=B2=D0=BB=D0=B5=D0=BD=D0=B8=D0=B5 =D0=BF=D0=BB=D0=B0=D1=82= =D1=84=D0=BE=D1=80=D0=BC=D1=8B =D0=B8 =D0=BA=D0=BE=D0=BD=D1=84=D0=B8=D0=B3= =D1=83=D1=80=D0=B0=D1=86=D0=B8=D1=8F.=20 =D0=90=D0=B2=D1=82=D0=BE=D0=BC=D0=B0=D1=82=D0=B8=D1=87=D0=B5=D1=81=D0=BA=D0= =BE=D0=B5 =D1=80=D0=B5=D0=B7=D0=B5=D1=80=D0=B2=D0=BD=D0=BE=D0=B5 =D0=BA=D0= =BE=D0=BF=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B1=D0=B0=D0= =B7 1=D1=81 =D0=BD=D0=B0 =D1=81=D1=8A=D1=91=D0=BC=D0=BD=D1=8B=D0=B5 =D0=BD= =D0=BE=D1=81=D0=B8=D1=82=D0=B5=D0=BB=D0=B8 =D0=BB=D0=B8=D0=B1=D0=BE =D0=B2= =D0=BE=D0=B1=D0=BB=D0=B0=D0=BA=D0=BE. =D0=A3=D0=B2=D0=B5=D0=BB=D0=B8=D1=87=D0=B5=D0=BD=D0=B8=D0=B5 =D1=81=D0=BA= =D0=BE=D1=80=D0=BE=D1=81=D1=82=D0=B8 =D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=8B= 1=D1=81 =D0=B2 =D0=A0=D0=90=D0=97=D0=AB =D0=BF=D0=BE=D1=81=D1=80=D0=B5=D0= =B4=D1=81=D1=82=D0=B2=D0=BE=D0=BC =D0=BE=D0=BF=D1=82=D0=B8=D0=BC=D0=B8=D0= =B7=D0=B0=D1=86=D0=B8=D0=B8 =D0=B1=D0=B0=D0=B7 =D0=B4=D0=B0=D0=BD=D0=BD=D1= =8B=D1=85, =D0=BF=D0=B5=D1=80=D0=B5=D0=B2=D0=BE=D0=B4=D0=BE=D0=BC =D1=80=D0= =B0=D0=B1=D0=BE=D1=82=D1=8B =D0=BD=D0=B0 =D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1= =80 =D0=B8 =D0=BD=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B9=D0=BA=D0=B8 =D1=81=D0= =B5=D1=80=D0=B2=D0=B5=D1=80=D0=B0 1=D1=81+SQL (=D0=BF=D1=80=D0=B8 =D1=8D=D1=82=D0=BE=D0=BC =D1=81=D0=BA=D0=BE=D1=80=D0=BE= =D1=81=D1=82=D1=8C =D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=8B =D0=B2=D0=BE=D0=B7= =D1=80=D0=B0=D1=81=D1=82=D0=B0=D0=B5=D1=82, =D0=BF=D0=BE=D1=8F=D0=B2=D0=BB= =D1=8F=D0=B5=D1=82=D1=81=D1=8F =D0=B2=D0=BE=D0=B7=D0=BC=D0=BE=D0=B6=D0=BD= =D0=BE=D1=81=D1=82=D1=8C =D0=B7=D0=B0=D0=B1=D0=BB=D0=BE=D0=BA=D0=B8=D1=80= =D0=BE=D0=B2=D0=B0=D1=82=D1=8C =D0=B2=D0=BE=D0=B7=D0=BC=D0=BE=D0=B6=D0=BD= =D0=BE=D1=81=D1=82=D1=8C =D0=BA=D0=BE=D0=BF=D0=B8=D1=80=D0=BE=D0=B2=D0=B0= =D0=BD=D0=B8=D0=B5 =D0=B1=D0=B0=D0=B7 =D1=81=D0=BE=D1=82=D1=80=D1=83=D0=B4= =D0=BD=D0=B8=D0=BA=D0=B0=D0=BC=D0=B8). 2) =D0=90=D1=83=D0=B4=D0=B8=D1=82 =D0=92=D0=B0=D1=88=D0=B5=D0=B9 =D1=81=D0= =B5=D1=82=D0=B8, =D0=BA=D0=BE=D0=BC=D0=BF=D1=8C=D1=8E=D1=82=D0=B5=D1=80=D0= =BE=D0=B2 =D0=B8 =D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1=80=D0=BE=D0=B2: =D0=9A=D0=B0=D0=BA =D0=BF=D1=80=D0=B0=D0=B2=D0=B8=D0=BB=D0=BE =D1=81=D0=BE= =D0=B1=D1=81=D1=82=D0=B2=D0=B5=D0=BD=D0=BD=D0=B8=D0=BA=D0=B8 =D0=B1=D0=B8= =D0=B7=D0=BD=D0=B5=D1=81=D0=B0 =D0=BB=D0=B8=D1=88=D1=8C =D0=BF=D0=BE=D0=B2= =D0=B5=D1=80=D1=85=D0=BD=D0=BE=D1=81=D1=82=D0=BD=D0=BE =D0=B7=D0=BD=D0=B0= =D1=8E=D1=82 =D0=BE =D1=81=D0=BE=D1=81=D1=82=D0=BE=D1=8F=D0=BD=D0=B8=D0=B8= =D0=BA=D0=BE=D0=BC=D0=BF=D1=8C=D1=8E=D1=82=D0=B5=D1=80=D0=BD=D0=BE=D0=B9= =D1=81=D0=B5=D1=82=D0=B8 =D1=81=D0=B2=D0=BE=D0=B5=D0=B9 =D0=BE=D1=80=D0=B3= =D0=B0=D0=BD=D0=B8=D0=B7=D0=B0=D1=86=D0=B8=D0=B8. =D0=90 =D0=B2=D1=81=D0=B5= =D1=87=D1=82=D0=BE =D0=BA=D0=B0=D1=81=D0=B0=D0=B5=D1=82=D1=81=D1=8F =D0=B4= =D0=BE=D1=81=D1=82=D1=83=D0=BF=D0=B0 =D0=BA =D0=B4=D0=BE=D0=BA=D1=83=D0=BC= =D0=B5=D0=BD=D1=82=D0=B0=D0=BC, =D0=B1=D0=B0=D0=B7 =D0=B4=D0=B0=D0=BD=D0=BD= =D1=8B=D1=85 1=D1=81 (=D0=B1=D1=83=D1=85=D0=B3=D0=B0=D0=BB=D1=82=D0=B5=D1= =80=D0=B8=D1=8F =D0=B8 =D0=BF=D1=80=D0=BE=D1=87=D0=B5=D0=B5), =D1=80=D0=B5= =D0=B7=D0=B5=D1=80=D0=B2=D0=BD=D0=BE=D0=B5 =D0=BA=D0=BE=D0=BF=D0=B8=D1=80= =D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B8 =D0=A2.=D0=94 - =D0=B2=D1=80=D0=BE=D0=B4=D0=B5 =D0=B5=D1=81=D1=82=D1=8C - =D0=B0 =D0=BF= =D0=BE =D1=84=D0=B0=D0=BA=D1=82=D1=83 =D0=9D=D0=95=D0=A2 (=D0=B8=D0=BB=D0= =B8 =D0=BA=D0=B0=D0=BA =D0=BC=D0=B8=D0=BD=D0=B8=D0=BC=D1=83=D0=BC =D0=BD=D0= =B5 =D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5=D0=BD=D1=82=D0=B8=D1=80=D0=BE=D0= =B2=D0=B0=D0=BD=D0=BE). 3) =D0=9A=D0=BE=D0=BD=D1=82=D1=80=D0=BE=D0=BB=D1=8C =D0=B7=D0=B0 =D1=81=D0= =BE=D1=82=D1=80=D1=83=D0=B4=D0=BD=D0=B8=D0=BA=D0=B0=D0=BC=D0=B8: =D0=9E=D0=B3=D1=80=D0=B0=D0=BD=D0=B8=D1=87=D0=B5=D0=BD=D0=B8=D0=B5 =D0=B4= =D0=BE=D1=81=D1=82=D1=83=D0=BF=D0=B0 =D0=BA =D1=81=D0=B0=D0=B9=D1=82=D0=B0= =D0=BC (=D1=81=D0=BE=D1=86. =D0=A1=D0=B5=D1=82=D0=B8, =D0=B8 =D0=BF=D1=80= =D0=BE=D1=87=D0=B8=D0=B5 =D0=BF=D0=BE=D0=B6=D0=B8=D1=80=D0=B0=D1=82=D0=B5= =D0=BB=D0=B8 =D0=B2=D1=80=D0=B5=D0=BC=D0=B5=D0=BD=D0=B8), =D0=B4=D0=B5=D1= =82=D0=B0=D0=BB=D1=8C=D0=BD=D0=BE=D0=B5 =D0=BF=D1=80=D0=BE=D0=B3=D1=80=D0= =B0=D0=BC=D0=BC=D0=BD=D0=BE=D0=B5 =D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5=D0= =BD=D1=82=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B4=D0=B5=D0= =B9=D1=81=D1=82=D0=B2=D0=B8=D0=B9 =D1=81=D0=BE=D1=82=D1=80=D1=83=D0=B4=D0= =BD=D0=B8=D0=BA=D0=BE=D0=B2 (=D1=83 =D1=80=D1=83=D0=BA=D0=BE=D0=B2=D0=BE=D0= =B4=D1=81=D1=82=D0=B2=D0=B0 =D0=B2 =D1=8D=D1=82=D0=BE=D0=BC =D1=81=D0=BB=D1= =83=D1=87=D0=B0=D0=B5 =D0=B5=D1=81=D1=82=D1=8C =D0=B2=D0=BE=D0=B7=D0=BC=D0= =BE=D0=B6=D0=BD=D0=BE=D1=81=D1=82=D1=8C =D0=9F=D0=9E=D0=9B=D0=9D=D0=9E=D0= =A1=D0=A2=D0=AC=D0=AE =D0=BF=D0=BE=D0=BD=D0=B8=D0=BC=D0=B0=D1=82=D1=8C, =D1= =87=D1=82=D0=BE =D0=B4=D0=B5=D0=BB=D0=B0=D0=BB =D1=81=D0=BE=D1=82=D1=80=D1= =83=D0=B4=D0=BD=D0=B8=D0=BA =D0=BD=D0=B0 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D1= =80=D0=B0=D0=B1=D0=BE=D1=87=D0=B5=D0=BC =D0=BC=D0=B5=D1=81=D1=82=D0=B5). 4) =D0=90=D0=BD=D1=82=D0=B8=D0=B2=D0=B8=D1=80=D1=83=D1=81=D0=BD=D0=B0=D1=8F= =D0=B1=D0=B5=D0=B7=D0=BE=D0=BF=D0=B0=D1=81=D0=BD=D0=BE=D1=81=D1=82=D1=8C= =D0=BA=D0=BE=D0=BC=D0=BF=D0=B0=D0=BD=D0=B8=D0=B8: =D0=9F=D0=BE=D0=BB=D0=BD=D0=B0=D1=8F =D0=BF=D1=80=D0=BE=D0=B2=D0=B5=D1=80= =D0=BA=D0=B0 =D0=BA=D0=BE=D0=BC=D0=BF=D1=8C=D1=8E=D1=82=D0=B5=D1=80=D0=BE= =D0=B2, =D0=BD=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B9=D0=BA=D0=B0 =D0=BC=D0=BE= =D0=BD=D0=B8=D1=82=D0=BE=D1=80=D0=B8=D0=BD=D0=B3=D0=B0 =D1=81 =D0=BE=D0=BF= =D0=BE=D0=B2=D0=B5=D1=89=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC =D0=BE =D0=B7=D0=B0= =D1=80=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B8 =D0=BA=D0=BE=D0=BC=D0=BF=D1=8C= =D1=8E=D1=82=D0=B5=D1=80=D0=BE=D0=B2 =D0=B8 =D1=81=D0=B5=D1=80=D0=B2=D0=B5= =D1=80=D0=BE=D0=B2 =D0=BE=D1=80=D0=B3=D0=B0=D0=BD=D0=B8=D0=B7=D0=B0=D1=86= =D0=B8=D0=B8 =D0=B7=D0=BB=D0=BE=D0=B2=D1=80=D0=B5=D0=B4=D0=BD=D1=8B=D0=BC= =D0=9F=D0=9E 5) =D0=A0=D0=B5=D0=B7=D0=B5=D1=80=D0=B2=D0=BD=D0=BE=D0=B5 =D0=BA=D0=BE=D0= =BF=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B4=D0=B0=D0=BD=D0= =BD=D1=8B=D1=85: =D0=98=D0=BD=D1=84=D0=BE=D1=80=D0=BC=D0=B0=D1=86=D0=B8=D1=8F =D1=8D=D1=82= =D0=BE =D0=A1=D0=90=D0=9C=D0=9E=D0=95 =D0=A6=D0=95=D0=9D=D0=9D=D0=9E=D0=95= =D1=87=D1=82=D0=BE =D0=B5=D1=81=D1=82=D1=8C =D1=83 =D0=BA=D0=BE=D0=BC=D0= =BF=D0=B0=D0=BD=D0=B8=D0=B8. =D0=9A =D1=81=D0=BE=D0=B6=D0=B0=D0=BB=D0=B5=D0= =BD=D0=B8=D1=8E, =D0=BA=D0=B0=D0=BA =D0=BF=D1=80=D0=B0=D0=B2=D0=B8=D0=BB=D0= =BE =D1=80=D0=B5=D0=B7=D0=B5=D1=80=D0=B2=D0=BD=D0=BE=D0=BC=D1=83 =D0=BA=D0= =BE=D0=BF=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D1=8E =D0=B2 =D0=BE=D1= =80=D0=B3=D0=B0=D0=BD=D0=B8=D0=B7=D0=B0=D1=86=D0=B8=D1=8F=D1=85 =D0=BC=D1= =8F=D0=B3=D0=BA=D0=BE =D0=B3=D0=BE=D0=B2=D0=BE=D1=80=D1=8F =D0=BD=D0=B5 =D1= =83=D0=B4=D0=B5=D0=BB=D1=8F=D1=8E=D1=82 =D0=B4=D0=BE=D0=BB=D0=B6=D0=BD=D0= =BE=D0=B3=D0=BE =D0=B2=D0=BD=D0=B8=D0=BC=D0=B0=D0=BD=D0=B8=D1=8F! 6) =D0=9F=D0=BE=D0=BC=D0=BE=D1=89=D1=8C =D0=B2 =D0=B7=D0=B0=D0=BA=D1=83=D0= =BF=D0=BA=D0=B5 =D0=BE=D0=B1=D0=BE=D1=80=D1=83=D0=B4=D0=BE=D0=B2=D0=B0=D0= =BD=D0=B8=D1=8F: =D0=9E=D0=BF=D1=82=D0=B8=D0=BC=D0=B0=D0=BB=D1=8C=D0=BD=D0=BE =D0=BF=D0=BE= =D0=B4=D0=BE=D0=B1=D1=80=D0=B0=D1=82=D1=8C =D0=BE=D0=B1=D0=BE=D1=80=D1=83= =D0=B4=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B2 =D0=BA=D0=BE=D0=BC=D0=BF= =D0=B0=D0=BD=D0=B8=D1=8E =D0=BF=D0=BE =D1=84=D0=BE=D1=80=D0=BC=D1=83=D0=BB= =D0=B5 =D0=A6=D0=95=D0=9D=D0=90-=D0=9A=D0=90=D0=A7=D0=95=D0=A1=D0=A2=D0=92= =D0=9E - =D0=B7=D0=BD=D0=B0=D1=87=D0=B8=D1=82 =D1=81=D1=8D=D0=BA=D0=BE=D0= =BD=D0=BE=D0=BC=D0=B8=D1=82=D1=8C =D1=81=D1=80=D0=B5=D0=B4=D1=81=D1=82=D0= =B2=D0=B0. 7) =D0=9D=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B9=D0=BA=D0=B0 =D1=83=D0=B4=D0= =B0=D0=BB=D1=91=D0=BD=D0=BD=D1=8B=D1=85 =D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1= =80=D0=BE=D0=B2: =D0=9D=D0=B0=D1=81=D1=82=D1=80=D0=BE=D1=8E =D0=92=D0=B0=D1=88 =D1=81=D0=B5= =D1=80=D0=B2=D0=B5=D1=80 =D0=B4=D0=BB=D1=8F =D1=83=D0=B4=D0=B0=D0=BB=D1=91= =D0=BD=D0=BD=D0=BE=D0=B9 =D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=8B =D0=BD=D0=B0= =D0=BD=D1=91=D0=BC =D1=81 1=D1=81 =D0=B1=D1=83=D1=85=D0=B3=D0=B0=D0=BB=D1= =82=D0=B5=D1=80=D0=B8=D0=B5=D0=B9, =D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5=D0= =BD=D1=82=D0=B0=D0=BC=D0=B8 =D0=B8 =D0=A2.=D0=94 =D0=9D=D0=B0 =D0=B4=D0=B0=D0=BD=D0=BD=D1=8B=D0=B9 =D0=BC=D0=BE=D0=BC=D0=B5= =D0=BD=D1=82 =D0=B0=D0=B4=D0=BC=D0=B8=D0=BD=D0=B8=D1=81=D1=82=D1=80=D0=B8= =D1=80=D1=83=D1=8E =D0=BD=D0=B0 =D1=83=D0=B4=D0=B0=D0=BB=D1=91=D0=BD=D0=BD= =D1=8B=D1=85 =D0=BF=D0=BB=D0=BE=D1=89=D0=B0=D0=B4=D0=BA=D0=B0=D1=85 =D0=B1= =D0=BE=D0=BB=D0=B5=D0=B5 25 =D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1=80=D0=BE=D0= =B2. =D0=A1=D0=B5=D1=80=D0=B2=D0=B5=D1=80=D0=B0 =D0=BD=D0=B0=D1=85=D0=BE=D0= =B4=D1=8F=D1=82=D1=81=D1=8F =D0=B7=D0=B0 =D1=80=D1=83=D0=B1=D0=B5=D0=B6=D0= =BE=D0=BC (=D0=B3=D0=B5=D1=80=D0=BC=D0=B0=D0=BD=D0=B8=D1=8F, =D0=A4=D1=80= =D0=B0=D0=BD=D1=86=D0=B8=D1=8F). =D0=A2=D0=BE =D0=B5=D1=81=D1=82=D1=8C =D0= =B0=D1=80=D0=B5=D0=BD=D0=B4=D0=BE=D0=B2=D0=B0=D0=B2 =D1=81=D0=B5=D1=80=D0= =B2=D0=B5=D1=80 =D0=B7=D0=B0 =D0=B3=D1=80=D0=B0=D0=BD=D0=B8=D1=86=D0=B5=D0= =B9 =D0=92=D1=8B =D0=93=D0=90=D0=A0=D0=90=D0=9D=D0=A2=D0=98=D0=A0=D0=A3=D0= =95=D0=A2=D0=95 =D1=81=D0=B5=D0=B1=D1=8F =D0=BE=D1=82 =D0=B8=D0=B7=D1=8A=D1= =8F=D1=82=D0=B8=D1=8F =D0=B4=D0=B0=D0=BD=D0=BD=D1=8B=D1=85 =D0=BF=D1=80=D0= =B8 =D0=BF=D1=80=D0=BE=D0=B2=D0=B5=D1=80=D0=BA=D0=B5 =D0=BF=D1=80=D0=B0=D0= =B2=D0=BE=D0=BE=D1=85=D1=80=D0=B0=D0=BD=D0=B8=D1=82=D0=B5=D0=BB=D1=8C=D0=BD= =D1=8B=D0=BC=D0=B8 =D0=BE=D1=80=D0=B3=D0=B0=D0=BD=D0=B0=D0=BC=D0=B8. =D0=9F= =D0=BE=D0=BC=D0=BE=D0=B3=D1=83 =D0=B2 =D0=B0=D1=80=D0=B5=D0=BD=D0=B4=D0=B5= =D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1=80=D0=BE=D0=BC. =D0=9F=D0=BE =D1=86=D0= =B5=D0=BD=D0=B5 =D0=B4=D0=B5=D1=88=D0=B5=D0=B2=D0=BB=D0=B5 =D1=87=D0=B5=D0= =BC =D0=B2 =D0=A0=D0=BE=D1=81=D1=81=D0=B8=D0=B8. 8) =D0=9D=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B9=D0=BA=D0=B0 =D0=BF=D0=BE=D1= =87=D1=82=D0=BE=D0=B2=D1=8B=D1=85 =D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1=80=D0= =BE=D0=B2: =D0=9A=D0=BE=D1=80=D0=BF=D0=BE=D1=80=D0=B0=D1=82=D0=B8=D0=B2=D0=BD=D0=B0=D1= =8F =D0=BF=D0=BE=D1=87=D1=82=D0=B0. =D0=9E=D0=B1=D1=8A=D0=B5=D0=BA=D1=82=D0=B8=D0=B2=D0=BD=D0=BE =D1=81=D0=BE= =D0=BA=D1=80=D0=B0=D1=89=D1=83 =D0=B2=D0=BE =D0=BC=D0=BD=D0=BE=D0=B3=D0=BE= =D1=80=D0=B0=D0=B7 =D0=BA=D0=BE=D0=BB-=D0=B2=D0=B0 =D1=81=D0=BF=D0=B0=D0= =BC=D0=B0. =20 =D0=9E=D0=B1=D1=8F=D0=B7=D0=B0=D1=82=D0=B5=D0=BB=D1=8C=D0=BD=D0=BE=D1=81=D1= =82=D1=8C, =D0=BF=D1=80=D0=BE=D1=84=D0=B5=D1=81=D1=81=D0=B8=D0=BE=D0=BD=D0= =B0=D0=BB=D1=8C=D0=BD=D1=8B=D0=B9 =D0=B8 =D0=BE=D1=81=D0=BD=D0=BE=D0=B2=D0= =B0=D1=82=D0=B5=D0=BB=D1=8C=D0=BD=D1=8B=D0=B9 =D0=BF=D0=BE=D0=B4=D1=85=D0= =BE=D0=B4. =D0=92=D0=BE=D1=82 =D1=84=D0=B8=D0=BB=D0=BE=D1=81=D0=BE=D1=84=D0= =B8=D1=8F =D0=BC=D0=BE=D0=B5=D0=B9 =D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=8B. = =D0=93=D0=90=D0=A0=D0=90=D0=9D=D0=A2=D0=98=D0=A0=D0=9E=D0=92=D0=90=D0=9D=D0= =9D=D0=9E =D0=B5=D1=81=D0=BB=D0=B8 =D0=B1=D0=B5=D1=80=D1=83=D1=81=D1=8C =D0= =B7=D0=B0 =D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=83 - =D0=92=D0=AB=D0=9F=D0=9E= =D0=9B=D0=9D=D0=AF=D0=AE =D0=95=D0=81! =20 Mail: b=D0=BEss@m=D0=B0il365.=D1=80r=D0=BE =D0=9C=D0=BE=D0=B9 =D1=82=D0=B5=D0=BB. +7 ( 495)72- 15-265 =D0=95=D0=B2=D0= =B3=D0=B5=D0=BD=D0=B8=D0=B9 =D0=BF=D0=BE=D0=B4=D1=80=D0=BE=D0=B1=D0=BD=D0=B5=D0=B5 =D0=BD=D0=B0 =D1=81= =D0=B0=D0=B9=D1=82=D0=B5 www.it=D0=B0riff.ru =20 =20 =D0=92=D1=8B =D0=BF=D0=BE=D0=BB=D1=83=D1=87=D0=B8=D0=BB=D0=B8 =D0=BF=D0=B8= =D1=81=D1=8C=D0=BC=D0=BE =D0=B2 =D1=81=D0=BE=D0=BE=D1=82=D0=B2=D0=B5=D1=82= =D1=81=D1=82=D0=B2=D0=B8=D0=B8 =D1=81 =D0=BF=D1=80=D0=B0=D0=B2=D0=B8=D0=BB= =D0=B0=D0=BC=D0=B8 =D0=BD=D0=B0=D1=88=D0=B5=D0=B3=D0=BE =D1=81=D0=B0=D0=B9= =D1=82=D0=B0, =D0=BA=D0=BE=D1=82=D0=BE=D1=80=D1=8B=D0=B5 =D0=92=D1=8B =D0= =BF=D1=80=D0=B8=D0=BD=D1=8F=D0=BB=D0=B8 =D0=BF=D1=80=D0=B8 =D1=80=D0=B5=D0= =B3=D0=B8=D1=81=D1=82=D1=80=D0=B0=D1=86=D0=B8=D0=B8, =D0=92=D1=8B =D0=B2=D1= =81=D0=B5=D0=B3=D0=B4=D0=B0 =D0=BC=D0=BE=D0=B6=D0=B5=D1=82=D0=B5 =D0=BE=D1= =82=D0=BF=D0=B8=D1=81=D0=B0=D1=82=D1=8C=D1=81=D1=8F =20 From owner-freebsd-arm@freebsd.org Fri Jan 27 10:28:29 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 5E6BDCC45C4 for ; Fri, 27 Jan 2017 10:28:29 +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 436B73ED for ; Fri, 27 Jan 2017 10:28:29 +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 v0RASTZt032827 for ; Fri, 27 Jan 2017 10:28:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 216523] FreeBSD router throughput 1/3 of total available Date: Fri, 27 Jan 2017 10:28:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: michael.cress@cress.us 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: Fri, 27 Jan 2017 10:28:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216523 Bug ID: 216523 Summary: FreeBSD router throughput 1/3 of total available Product: Base System Version: 11.0-STABLE Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: michael.cress@cress.us On an original Model B Raspberry pi running the FreeBSD-11.0-STABLE-arm-armv6-RPI-B-20161209-r309771.img with an additional D-Link 10/100 USB NIC, my Internet speed test results are 1/3 of what they = are going through my cheap Linksys wireless router via a wired connection throu= gh a 10/100 switch. Although IPFW is configured to provided NAT services, no oth= er QoS settings were set. Test A setup (Results: 8-9 Mb/s down, 2 Mb/s up): Computer -> (ue1 interface...DLink USB NIC) -> RPi/FreeBSD router/firewall= -> (ue0 interface...RPi native)-> cable modem Test B setup (Results: 27-29 Mb/s down, 2.7-3 Mb/s up): Computer -> 10/100 switch -> Linksys wireless router (via wired connection)= -> cable modem The CPU utilization of the RPi in Test A varies between 2-7% during the tes= t. netstat -i ue1: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Co= ll lo0 16384 44469 0 44469 0 = 0 lo0 16384 127 localhost 44469 - 44469 - = - lo0 16384 localhost ::1 44469 - 44469 - = - lo0 16384 fe80::1%lo0 fe80:1::1 44469 - 44469 - = - gif0* 1280 0 0 0 0 = 0 stf0* 1280 0 0 0 0 = 0 en0 1500 a8:20:66:4f:e3:7c 3615853 0 1647904 0 = 0 en0 1500 michaels-im fe80:4::a5:91b4:f 3615853 - 1647904 - = - en0 1500 192.168.4 192.168.4.20 3615853 - 1647904 - = - en0 1500 fd1d:61d4:a fd1d:61d4:a56d::c 3615853 - 1647904 - = - en0 1500 fd1d:61d4:a fd1d:61d4:a56d::8 3615853 - 1647904 - = - en1 1500 8c:2d:aa:41:4e:77 0 0 0 0 = 0 en2 1500 32:00:14:2c:25:e0 0 0 0 0 = 0 en3 1500 32:00:14:2c:25:e1 0 0 0 0 = 0 p2p0* 2304 0e:2d:aa:41:4e:77 0 0 0 0 = 0 awdl0 1484 82:ab:eb:d9:f7:5b 0 0 2 0 = 0 bridg 1500 32:00:14:2c:25:e0 0 0 1 0 = 0 utun0 2000 0 0 3 0 = 0 utun0 2000 fe80::c960: fe80:b::c960:3443 0 - 3 - = - netstat -i ue0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Co= ll lo0 16384 44474 0 44474 0 = 0 lo0 16384 127 localhost 44474 - 44474 - = - lo0 16384 localhost ::1 44474 - 44474 - = - lo0 16384 fe80::1%lo0 fe80:1::1 44474 - 44474 - = - gif0* 1280 0 0 0 0 = 0 stf0* 1280 0 0 0 0 = 0 en0 1500 a8:20:66:4f:e3:7c 3624424 0 1650780 0 = 0 en0 1500 michaels-im fe80:4::a5:91b4:f 3624424 - 1650780 - = - en0 1500 192.168.4 192.168.4.20 3624424 - 1650780 - = - en0 1500 fd1d:61d4:a fd1d:61d4:a56d::c 3624424 - 1650780 - = - en0 1500 fd1d:61d4:a fd1d:61d4:a56d::8 3624424 - 1650780 - = - en1 1500 8c:2d:aa:41:4e:77 0 0 0 0 = 0 en2 1500 32:00:14:2c:25:e0 0 0 0 0 = 0 en3 1500 32:00:14:2c:25:e1 0 0 0 0 = 0 p2p0* 2304 0e:2d:aa:41:4e:77 0 0 0 0 = 0 awdl0 1484 82:ab:eb:d9:f7:5b 0 0 2 0 = 0 bridg 1500 32:00:14:2c:25:e0 0 0 1 0 = 0 utun0 2000 0 0 3 0 = 0 utun0 2000 fe80::c960: fe80:b::c960:3443 0 - 3 - = - --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jan 28 01:01: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 7AF7BCC36C7 for ; Sat, 28 Jan 2017 01:01:40 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 337F6875 for ; Sat, 28 Jan 2017 01:01:40 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x236.google.com with SMTP id s140so80300451qke.0 for ; Fri, 27 Jan 2017 17:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ta0LdM9nK6vJc+lSAL2Wh8W2S2VEO5j9zf8HnKMZL9k=; b=Yen9q4ow5ea/nKO8e9oB6LpeeTzo0Fda98iWj7N8Y5xTQ4A27SfVRwsrmhjKRPlc/C j2wgZrAcwWk1D8neZtDce+8C+6CojXkGK2v4v/8cK/xbDZ0iEMPaueLR5SoqoRFV71lp LW76BTn/GGZ/c1f2Yf3gTf+VL4xDqvInDdo4lqBv5EhUU9H6c9JFIxLPnTmptj0lB1E0 LNDp8UW+rylR59fpN+spERt11Fr6H2kf/z4bVwaY/rtGhfZJFizL5q4L5m17hN1quJ09 pJJbetr9JkMUDX5iNwjhFdAhoVqLkp78x/1BCzvmC1jRFa37KHvMJF4cbAfVbSH7wRWi e/VA== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ta0LdM9nK6vJc+lSAL2Wh8W2S2VEO5j9zf8HnKMZL9k=; b=fRR4Sa4XrU7NwSGdcWxGpSoH73kLTKSuKlVx0wXNnAPdaFCtLutIi9NKjLe8OIkei/ 7yOLLVmC553UXytD3aDglPxXnBr/qVSVzEXR4KR6qPCQXmhJhEdI+MMn+9dFj0Ns6tgh 1BdOyA9WRjIBX4tSahdxn03w0GgDobY3pv9TAgrDrQUYQlOP6u38zoKPApETvJuUhAix lI+jayjepnbob8eRs2TOLRkKOAbv5HEtmNWj+aZMnTOccc/URubofzTGuwMg4qo1uveo HOp4gnP+iDjUymo6iSctj09HsHkKLOn7dOP3zT2xrz/DPWToCbcqfshYI5lpzq//y1ZZ 8dOw== X-Gm-Message-State: AIkVDXLxkJBKwsoHzROIpLcLFmEty6WPl0d711NnHqmHcrcz80QTlDY7So2w2oq5/+ya9qFU X-Received: by 10.55.195.138 with SMTP id r10mr11574216qkl.89.1485565299264; Fri, 27 Jan 2017 17:01:39 -0800 (PST) Received: from mutt-hardenedbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id a54sm5534119qta.48.2017.01.27.17.01.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Jan 2017 17:01:38 -0800 (PST) Date: Fri, 27 Jan 2017 20:01:38 -0500 From: Shawn Webb To: Andrew Turner Cc: Tom Vijlbrief , freebsd-arm Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Message-ID: <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> References: <20170124191357.0ec0abfd@zapp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bjqnaqnwumrlobje" Content-Disposition: inline In-Reply-To: <20170124191357.0ec0abfd@zapp> X-Operating-System: FreeBSD mutt-hardenedbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20161126 (1.7.1) 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: Sat, 28 Jan 2017 01:01:40 -0000 --bjqnaqnwumrlobje Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2017 at 07:13:57PM +0000, Andrew Turner wrote: > Can you try with r312703 and without the malloc.conf change? I think the > issue was because errno was stored just before some internal jemalloc > state in the bss and there was a bug where the setting of errno where > it would overwrite 32 bits of this state. I've just tested on an RPI3 and tcache still needs to be disabled with malloc.conf. --=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 --bjqnaqnwumrlobje Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAliL7W8ACgkQaoRlj1JF bu5x0A/8DaNEbJJX9QyjTBgcBLr+K5QnAX3riSQ7A8EYto7lk1iXwaAkvQ9a84/3 m9ewq9JQ+riyKvxsQNtZzB5v63tEqOT2ymvC1YE5ofv/I3l9fRBjvoPNeT9gBb1e I6/SVDs4ZnP4ElpowUnSogxHWfjAAdAnXMcSt0MlMx15bDxDODkI/iixggAyoXlz yWJ23NCBrSuB83TEdVO+EOczgv5HpqddKF/SDd0Nox3kp5hlz/zCP83W2/35nIOT uP7T7Q6CRfOJG03sVaWY4oAuKu0rJC04t9gvQkFbhPnmXETeM5fyZDcjfLnWyyZZ S+kZTGtAXVzybUrkgUbuM8g1dhkC5+6LxDW0Rujt6dy9eCjr3XNNYPdsV/VKdr9G D75oxpqlU5Y6dI/TFU8P6i+BXWRYatxuN/sJKYUn/YqZHfhOfipuUw1+Yy9OU+eW VpbZRvDLS5UXjm+NSWjzBqB7jxHdG3shWP0YY+uxzYorPzkfmQ5OIAURXb48gNdw +RrT4Pvz24qvwssmTnE6Z+TnuyQ5e7a1O98SLT+lwr0bQcCSlb6hW2giVpjh7op9 f3gpye853vXuQq6xz7saBb7geV7da+4KXxaZqe5vUC5p5QpC/8GgfA5rN0rlDptA bA0BRGBK6M1r19CDEsAAZKDtT3rqeuhaZoyMP7KkBAJ61uPyZbk= =VAjY -----END PGP SIGNATURE----- --bjqnaqnwumrlobje-- From owner-freebsd-arm@freebsd.org Sat Jan 28 01:02: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 ADBB7CC389F for ; Sat, 28 Jan 2017 01:02:26 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 631E19BE for ; Sat, 28 Jan 2017 01:02:26 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x232.google.com with SMTP id 11so79973002qkl.3 for ; Fri, 27 Jan 2017 17:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Wx2Mc1KY7TRbob2/bvZjg7pGbsttkFHahmU0ls3fO1U=; b=jzJZ7YIPu04xPfI2oPr3sHZ3ShggRki/AuDVJdMG2num34loxXfCQDWiYz1cjtX8N3 Fyle72qO8oMB6Pf6LMC8yknfibJEtEmqcMmVEgAktzUj7dVkA225CXbQFmlW0+NkWnzL m3QBigBejlR4rlxFtHa7VPPrr/NLlRmzAcy0lXMCuuMi/TGl6kdYovMyPhWABPQ80/71 +kLormo1zEmyX7wBQkGgyuRggMpqtTy8XJkkNSR7Nbnngst8vMHvlM+tLcYqs+8Ex7MY 9wOhPSxhXyVvrBAFE1oWPFdjyQhIrZ+wle/k2IHOMXPYtw3+g/1plI0t1m1aLAJ9BR70 0Uag== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Wx2Mc1KY7TRbob2/bvZjg7pGbsttkFHahmU0ls3fO1U=; b=AX1hAUD1233kuuYxH9HQM+MoAkW0fxFzKx5rVZFRtuDjGC7LZNNA29vLz4/yRmDkNK 9y0sQ19QXrXi/UvSVS2BW6ZEZGDMFWAdK10I7QiHdhbe6NPA4r7hA63xud4p+o7WwQS8 WCWRVWO5gD94pm/lV/d5LkrcpItd/7nhGH4eztWSVzssrSC0JzVdK/P1/HDJE5LXVdAH nz6xrcBX/uLQiH1jgafJ6YZHa7rsKJ/XdPhUnxt/D10IDRW8ceYEeIGZUADgMCCePkXe rtRE0w9TPqyy0EWbyJMuuLl4M08vPsFEgnkGm1lI/BsnnnVJkaHIpXmuauguDP79S2Oa 8yEg== X-Gm-Message-State: AIkVDXIkoYz8+D1wzG3A2MLC2dXHqvNHCMbwMMpxRvWzv746hBZ2HGg4aNfM+UYZN24M/YFm X-Received: by 10.55.19.66 with SMTP id d63mr10404629qkh.73.1485565345628; Fri, 27 Jan 2017 17:02:25 -0800 (PST) Received: from mutt-hardenedbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id c19sm5548677qtc.29.2017.01.27.17.02.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Jan 2017 17:02:25 -0800 (PST) Date: Fri, 27 Jan 2017 20:02:23 -0500 From: Shawn Webb To: Andrew Turner Cc: Tom Vijlbrief , freebsd-arm Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Message-ID: <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wuoppqus4d2xzmj5" Content-Disposition: inline In-Reply-To: <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> X-Operating-System: FreeBSD mutt-hardenedbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20161126 (1.7.1) 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: Sat, 28 Jan 2017 01:02:26 -0000 --wuoppqus4d2xzmj5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2017 at 08:01:38PM -0500, Shawn Webb wrote: > On Tue, Jan 24, 2017 at 07:13:57PM +0000, Andrew Turner wrote: > > Can you try with r312703 and without the malloc.conf change? I think the > > issue was because errno was stored just before some internal jemalloc > > state in the bss and there was a bug where the setting of errno where > > it would overwrite 32 bits of this state. >=20 > I've just tested on an RPI3 and tcache still needs to be disabled with > malloc.conf. I misspoke somewhat: the testing was done on a SoftIron Overdrive 1000. --=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 --wuoppqus4d2xzmj5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAliL7Z4ACgkQaoRlj1JF bu4oCg//coNGEF9vm2qmD5217np0sV8EdlTE+eapai/tSZ3xMUL3Mk5VHJb2m6wD jz8mfXX7wmS8gqz61DxcS4gn7dDLJmX61JDwGCZgwzwONMyfXzQjOTXh1jsB2Pa0 15a2Coc5mYVRc+WbEDgLKM3hBqr54F/f0d7s43KoOk0bKV+eDquDQxbC2YIF0NlZ KZ9WelRIOjBf1pq8nDTF7y9QLoS4VwWnwc2G1kyIrlp90Zq7kobpXEJhIpIO+sS5 SPMVMX82pCmHSy9pqZJbmDT1mjdRVDka6JmDHkuW0MFqur/AGOt8J1hamwFFPIsl VN0Ihrwx+SBmmjY6BfDEZC0PzwVhTF7/mfyKlzP07IPKthqCIDNUvorN0pZGxjG4 clUAjmwZgesutYJZW3dot4xuuhf+UodJ2++ZIfEQ/LDbq7oDu1U/waUJ8Rul2Vxp ewibkUx1QqolL4K8tQ/OBThwnzIAGaSqVmI2GkWfkHx3p5iqLG6JRbB5F90XpDd8 JhQDskJD1tF/Ael+UmRVgKs4p1TbxBfrGJdcdtpu68T8luszEloQRK/XR39Rolyb vwc0Gc5LfzWt1qqiaAnmUXv36L45ock/FJuekaGjEAbrqox5eWaekzr5Dfxhz7A8 6a45sdtQFFPS5MhGxHo5ZJfnNvwi63KxD/uA0yDZAxudItScoYY= =w5CB -----END PGP SIGNATURE----- --wuoppqus4d2xzmj5-- From owner-freebsd-arm@freebsd.org Sat Jan 28 03:54: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 2967CCC5C33 for ; Sat, 28 Jan 2017 03:54:46 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 F2C881566 for ; Sat, 28 Jan 2017 03:54:45 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cXK5w-0003Qx-V3; Fri, 27 Jan 2017 19:54:34 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0S3sVmR013202; Fri, 27 Jan 2017 19:54:31 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 27 Jan 2017 19:54:31 -0800 From: Oleksandr Tymoshenko To: =?iso-8859-1?Q?Otac=EDlio?= Cc: "freebsd-arm@freebsd.org" Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black Message-ID: <20170128035431.GA13176@bluezbox.com> References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> <20170127013142.GA2921@bluezbox.com> <13aa921f-b65f-8bf6-f298-ccb286c7ed6e@bsd.com.br> <20170127020035.GA3187@bluezbox.com> <55637733-f4f5-6bcc-1d00-4c4b7d1b1b3d@bsd.com.br> <20170127022746.GA3433@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170127022746.GA3433@bluezbox.com> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: > Otacílio (otacilio.neto@bsd.com.br) wrote: > > Em 26/01/2017 23:00, Oleksandr Tymoshenko escreveu: > > > Otacílio (otacilio.neto@bsd.com.br) wrote: > > >> Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > > >>> Otacílio (otacilio.neto@bsd.com.br) wrote: > > >>>> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > > >>>>> Otacílio (otacilio.neto@bsd.com.br) wrote: [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bsd.com.br] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: Sat, 28 Jan 2017 03:54:46 -0000 Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: > Otacílio (otacilio.neto@bsd.com.br) wrote: > > Em 26/01/2017 23:00, Oleksandr Tymoshenko escreveu: > > > Otacílio (otacilio.neto@bsd.com.br) wrote: > > >> Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > > >>> Otacílio (otacilio.neto@bsd.com.br) wrote: > > >>>> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > > >>>>> Otacílio (otacilio.neto@bsd.com.br) wrote: ... skipped ... > > >>>> I have applied the patch and now I'm getting this error. Some hints? > > >>> FreeBSD uses dtb names that do not match upstream ones. After updating > > >>> to 2017.01 that change was lost in progress. Possible workaround (HACK > > >>> ALERT!!!) would be to do something like this: > > >>> > > >>> => setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > > >>> => saveenv > > >>> > > >>> Copy-paste to U-Boot serial console does not work for me on BBB, so > > >>> you'll have have to enter these commands > > >>> > > >>> I will submit update to u-boot ports so all these workarounds will > > >>> not be required. > > >>> > > >> I'm getting this: > > >> > > >> Type '?' for a list of commands, 'help' for more detailed help. > > >> loader> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > > >> Error: stack underflow > > >> loader> > > > No, setenv/saveenv should be done in u-boot. But this gave me > > > an idea. You can also mount root partition on SD card and > > > add following line to /boot/loader.conf: > > > > > > fdt_file="beaglebone-black.dtb" > > > > > > That should do the trick as well > > > > > I have added > > > > fdt_file="bboneblk.dtb" > > > > (because this is the name that I found on fat partition) to > > /boot/loader.conf but still getting > > No, in this case it's not about what's on FAT it's what in > /boot/dtb/ on root partition. That's where loader looks for > DTB files. > > I don't have crochet setup handy right now so can't check > end-to-end procedure, but I'll do it tomorrow. I tried building crochet image from scratch and can confirm that adding fdt_file="beaglebone-black.dtb" to /boot/loader.conf works around this issue. Proper fix should be available soon. -- gonzo From owner-freebsd-arm@freebsd.org Sat Jan 28 05:14: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 55CCDCC44C5 for ; Sat, 28 Jan 2017 05:14:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001: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 1F7BB1F3C for ; Sat, 28 Jan 2017 05:14:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id j13so75428901iod.3 for ; Fri, 27 Jan 2017 21:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=FZQzQ65u7ncWVdX6MkXk+cPJaDcMXsoe3yy4cS6TKD0=; b=FL556lKLHuPL6H+iCmYUA1PbuiCL/487Ga0nYeKmxRK70EV+/Lyd40XoUBBSNZAdUL IQyeTRu0icP3eVeQCsBudIEO5QfqwemViSjU24Mhct266rNDtGmS9kUINOaZ1FXTcxhZ pc07zACeK/Q1xhwQxCe6Hes73YO6jRWu/T7RXVLeBzP9JNoXzEJp4OoG4SpWvVvSidYu um53C+0GkfEmyM5nmurEEE9OZG/sbqUcVWBvrosiRKCqsE7V43yqIN6Rl310hNiPHQLe q/dhQY7VTj0Bjw93OFFqs70G+vfr5WXuSEYSi9SNUlZbuGgWg9+yIZInyq0lgSMwEQo9 P8lg== 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:in-reply-to:references:from :date:message-id:subject:to; bh=FZQzQ65u7ncWVdX6MkXk+cPJaDcMXsoe3yy4cS6TKD0=; b=H/lbC2LXQwgw5JkQAOgv3910P3B/0M3G6bEx+wRiAVQtxM2PYnsdmO9imzrRYvB72C AMkcj4lxymR5CPngIcUlz3JW8PnOIb4fiEZH6q1Zsw9s6qqTjSXlU9/SDKz5qALQ+IXY gGlZuA5kUvh9E2Zng56iarjPoNbU9/50AVMCk42xBSJ7gK0l1isFBKeqcYqYVkZjpAsd 00/9Vshuw5hEoxE7J3+o+LYhu+DvMEiTffLuKddtaL4nDQOetDQESuExXDGgftpZyoZN dpKRZtBbFGb+5N6/q1V2mDGjm76KW0MgzX1i5dRmCI4j6v/WoEanesf7rL3BeHFFPc7H ccBw== X-Gm-Message-State: AIkVDXIqhYBrB0U7/LtEqGjQdhQzCjeEfU2wyD9T7c1L+2PINGccjPGAG8I+dairCW9UvCGRm9SMo2V7eqdb9w== X-Received: by 10.107.198.195 with SMTP id w186mr10696062iof.19.1485580495094; Fri, 27 Jan 2017 21:14:55 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Fri, 27 Jan 2017 21:14:54 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <201701280507.v0S57tOC088457@repo.freebsd.org> References: <201701280507.v0S57tOC088457@repo.freebsd.org> From: Warner Losh Date: Fri, 27 Jan 2017 22:14:54 -0700 X-Google-Sender-Auth: deEiZs5PZNKYkJbgDq2xHuzE6N4 Message-ID: Subject: Fwd: svn commit: r312915 - head/sys/modules/dtb/am335x To: "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: Sat, 28 Jan 2017 05:14:56 -0000 This switches up to the upstream dts files, as well as the upstream names, which the new u-boot ports need. I've only done the one for BeagleBone family. Please let me know if there's any issues. I fear we actually need the HDMI stuff for some reason... But if we do I'll fix it. Warner ---------- Forwarded message ---------- From: Warner Losh Date: Fri, Jan 27, 2017 at 10:07 PM Subject: svn commit: r312915 - head/sys/modules/dtb/am335x To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: imp Date: Sat Jan 28 05:07:55 2017 New Revision: 312915 URL: https://svnweb.freebsd.org/changeset/base/312915 Log: Switch to Linux / device tree upstream names. U-boot uses these by default, and the fewer changes relative to the upstream u-boot the better. Add compatibility links for the old names. Add dts file for BeagleBone Green while we're here. Modified: head/sys/modules/dtb/am335x/Makefile Modified: head/sys/modules/dtb/am335x/Makefile ============================================================================== --- head/sys/modules/dtb/am335x/Makefile Sat Jan 28 05:07:53 2017 (r312914) +++ head/sys/modules/dtb/am335x/Makefile Sat Jan 28 05:07:55 2017 (r312915) @@ -1,8 +1,13 @@ # $FreeBSD$ # All the dts files for am335x systems we support. DTS= \ - beaglebone.dts \ - beaglebone-black.dts \ + am335x-bone.dts \ + am335x-boneblack.dts \ + am335x-bonegreen.dts \ ufw.dts +LINKS= \ + ${DTBDIR}/am3335x-bone.dtb ${DTBDIR}/beaglebone.dtb \ + ${DTBDIR}/am3335x-boneblack.dtb ${DTBDIR}/beaglebone-black.dtb + .include From owner-freebsd-arm@freebsd.org Sat Jan 28 14:43: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 EDB8DCC58EB for ; Sat, 28 Jan 2017 14:43:27 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 AC4B912B3 for ; Sat, 28 Jan 2017 14:43:27 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-yw0-x236.google.com with SMTP id u68so33501599ywg.0 for ; Sat, 28 Jan 2017 06:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KGBXqFEqiFOkSqbJjf9T2ZYV7/TyBn4OKRn4bLl184I=; b=VyzzeRDmoXogK7SU8L8vDdU7HC1wbGOEfM4AhgtAI8Dipb4PCxc1Pt/5cI9mqPuWP6 6ZJkkr5nKnxVAjDBYrjlBVBOHiJvvgIQqK/+VShO1zkcT3qhdBTtowCC3N/i7RiCFvF5 Gkb5kncGi3esKAmMD2Jqh5dkCj3jD/wRWhQjeLQIQAHxuS4oZ3wBe50XmalGFDXtR3Wf 7xpOa7NulRzuvp/tSr9+PZr+eooVwk/CpmcKAeyAcpiW1U5phUXTYcdiiCuIieVxb+Cj o20TAG4v7IfGrO0ZKROKDliMErunWRT8iNuJiUFBsm5uNqjWjn/+ReMsIejFLIqv2pqZ omHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KGBXqFEqiFOkSqbJjf9T2ZYV7/TyBn4OKRn4bLl184I=; b=f3KHaq3t7R7OflO2RFwto9b+0AvPr2yQniQ3YwL8ByA12vQAyuDfKVKpJu5m4fcwQR pcF509hDrPQKpNBScT0SKyMAgnR+Gro7P+jl5JefKpoMaEz14OIrEeNqSa8ElDWiNv72 viN2x/iK2vMRNiMAQPmGcQjGw9MXKh+5vXSYqSZc2aN6XxiqxWqlnn8uKZ0r0gq+Ztjs 522Xpm3xjxGcnWT0JvW58HLAeopY8OodGGUXCEBQbwbvzzix0Ef+jPJGiuxzP90C23iD 7r0/MetyKuUlETEJF2198qhSXD2A2JNeAVvzRsisPCXNQwzGeLq8Pke5uJ0apf55V3oS 0jmw== X-Gm-Message-State: AIkVDXJSHrPtliOzbLsFdwG2u6lJWKVILJUaBhNqenwHZjEwLY+5lvdiiAJ74j6evSawZAN7aTo6qjGcr1W8/A== X-Received: by 10.129.75.147 with SMTP id y141mr8842097ywa.86.1485614606902; Sat, 28 Jan 2017 06:43:26 -0800 (PST) MIME-Version: 1.0 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> In-Reply-To: <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> From: Tom Vijlbrief Date: Sat, 28 Jan 2017 14:43:16 +0000 Message-ID: Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) To: Shawn Webb , Andrew Turner 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: Sat, 28 Jan 2017 14:43:28 -0000 Did a build/install world/kernel with r312916 and MALLOC_PRODUCTION=YES on a pine64, removed /etc/malloc.conf, rebooted and I am now rebuilding the python2 port without problems so far (except the "gic0: Spurious interrupt detected" messages which reappeared shortly after my previous post) Op za 28 jan. 2017 om 02:02 schreef Shawn Webb : > On Fri, Jan 27, 2017 at 08:01:38PM -0500, Shawn Webb wrote: > > On Tue, Jan 24, 2017 at 07:13:57PM +0000, Andrew Turner wrote: > > > Can you try with r312703 and without the malloc.conf change? I think > the > > > issue was because errno was stored just before some internal jemalloc > > > state in the bss and there was a bug where the setting of errno where > > > it would overwrite 32 bits of this state. > > > > I've just tested on an RPI3 and tcache still needs to be disabled with > > malloc.conf. > > I misspoke somewhat: the testing was done on a SoftIron Overdrive 1000. > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > From owner-freebsd-arm@freebsd.org Sat Jan 28 21:09: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 7C9D2CC67A5 for ; Sat, 28 Jan 2017 21:09:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-70.reflexion.net [208.70.210.70]) (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 41166169B for ; Sat, 28 Jan 2017 21:09:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2136 invoked from network); 28 Jan 2017 21:04:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Jan 2017 21:04:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 28 Jan 2017 16:03:07 -0500 (EST) Received: (qmail 10663 invoked from network); 28 Jan 2017 21:03:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Jan 2017 21:03:06 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id EF0A3EC7C1F; Sat, 28 Jan 2017 13:03:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) From: Mark Millard In-Reply-To: Date: Sat, 28 Jan 2017 13:03:05 -0800 Cc: Shawn Webb , Andrew Turner , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> To: Tom Vijlbrief 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: Sat, 28 Jan 2017 21:09:55 -0000 [About: "gic0: Spurious interrupt detected" on armv6 as well.] On 2017-Jan-28, at 6:43 AM, Tom Vijlbrief = wrote: > Did a build/install world/kernel with r312916 and = MALLOC_PRODUCTION=3DYES on > a pine64, removed /etc/malloc.conf, rebooted >=20 > and I am now rebuilding the python2 port without problems so far = (except > the "gic0: Spurious interrupt detected" messages which reappeared = shortly > after my previous post) While very rare, I have seen the gic0 notices on armv6 (e.g., a bpim3) during large builds (with -j 4). Recently I got a: gic0: Spurious interrupt detected: last irq: 29 on CPU1 on: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312726M: Tue Jan 24 = 20:57:48 PST 2017 = markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG = arm armv6 1200020 1200020 while building devel/gcc6 (via a full bootstrap) via -j 4 . This is from a non-debug buildworld buildkernel context and has = MALLOC_PRODUCTION=3D=20 in /etc/make.conf . No /etc/malloc.conf present. I do use = -mcpu=3Dcortex-a7 . Details if you care: # more /usr/src/sys/arm/conf/BPIM3-NODBG=20 # # BPIM3 -- Custom configuration for the Banana Pi M3 # include "GENERIC" ident BPIM3-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC It was a from cross build for buildworld buildkernel : (I've not checked on lldb builds linking recently.) # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host=20 TO_TYPE=3Darmv6 # KERNCONF=3DBPIM3-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. Used for buildworld buildkernel : # more ~/src.configs/make.conf #MALLOC_PRODUCTION=3D #NO_WERROR=3D #WERROR=3D CFLAGS.gcc+=3D -v Used for port builds: # more /etc/make.conf=20 WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/ofw/ofw_machdep.c The M's are generally tied to powerpc64 and powerpc explorations. I tend to use the same source for all the TARGET_ARCH's that I build. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Jan 28 22:18: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 89819CC6B8C for ; Sat, 28 Jan 2017 22:18:09 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (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 464361EC0 for ; Sat, 28 Jan 2017 22:18:09 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-yw0-x241.google.com with SMTP id q71so22117530ywg.3 for ; Sat, 28 Jan 2017 14:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ktvGOdSKKEhakOeeaAaRR1GwOtu31SSIxpYgay4AkAQ=; b=YIuTIZ6L2Fgxo8LUQA2QinnpaWoGty4OQk3ROO11TnR0xfDVKGrZISFilRQwa5nwM8 EtSOYGCiAc+uIXY6U59QEruG0qnJMuy73JqtwR9AvqWVocNJoDvIIcuxRp6DXIiCUJtm hhD9OTyzBnnKkkBcmSjACUuBm5IUU9RqYbz+WfRV9NPPsfZyWmLLTqDwLSiIXz78qJ2k ybVNi5/9NZ7Jk8kY9QGPEzrzIOedGW5VA/9Odkvw5BoO8SMgEHibO9LgVIHoBNwv7qDC Tz8gk+umb51OlcnEHQNZJ8AH1S22VyCGJ3DHAivgYMO0Z0piaZqVKeYDTBu4eUyR165s ChUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ktvGOdSKKEhakOeeaAaRR1GwOtu31SSIxpYgay4AkAQ=; b=Z+O6rQEkPxMg+Z+fB/1quDE6yZwlH0wSwF8RZ1z07Ch9k4m/L2WJQ3C1xywp6xxlk6 YdfFH58OqaMRElogAVzTj7NdtHma4yyTPKTp5a0jfI18X+gTSCxABy6id3mxO4LX87Jk vQJ+VCodgh4RnyKV2JETOgzSd6YLXEIw9gRQGzhZWsN/zxIfmTgRh5Mzd+HZeh3c4xB5 oT07hkvcITtV6Fp3lmX2NsblNz0wXX6go0mu91kg/tUXDD3H8/E2ATb6YqZzPMAcHOrj +YELn9KCExdwH2eslyJ7DNSf4TMBUQt8U0BECmeuyWUGmkWxURRsJY63dcNa94hYqVp8 J8WA== X-Gm-Message-State: AIkVDXL+dQ4MgcC9WYeUmdGEPQBE2XE/L1V+eANfqlb7vsFtj/RfHXibYQ/zdQJttzMtaBTi8IYcCB2VZauSng== X-Received: by 10.13.222.68 with SMTP id h65mr9741192ywe.197.1485641888429; Sat, 28 Jan 2017 14:18:08 -0800 (PST) MIME-Version: 1.0 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> In-Reply-To: <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> From: Tom Vijlbrief Date: Sat, 28 Jan 2017 22:17:58 +0000 Message-ID: Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) To: Mark Millard Cc: Shawn Webb , Andrew Turner , 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: Sat, 28 Jan 2017 22:18:09 -0000 Note that on the pine64 the network interface hangs from time to time and I get a core dump with very low frequency from long running processes, eg the shell that invokes "make world". Note that I had similar issues on the ODroid-C2. Currently rebuilding world without MALLOC_PRODUCTION. The arm64 port is getting close to working 100%, just a last few glitches. Op 22:03 ZA 28 Jan 2017 schreef Mark Millard : > [About: "gic0: Spurious interrupt detected" on armv6 as well.] > > On 2017-Jan-28, at 6:43 AM, Tom Vijlbrief wrote: > > > Did a build/install world/kernel with r312916 and MALLOC_PRODUCTION=YES > on > > a pine64, removed /etc/malloc.conf, rebooted > > > > and I am now rebuilding the python2 port without problems so far (except > > the "gic0: Spurious interrupt detected" messages which reappeared shortly > > after my previous post) > > While very rare, I have seen the gic0 notices on armv6 (e.g., a bpim3) > during large builds (with -j 4). Recently I got a: > > gic0: Spurious interrupt detected: last irq: 29 on CPU1 > > on: > > # uname -apKU > FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312726M: Tue Jan 24 > 20:57:48 PST 2017 markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG > arm armv6 1200020 1200020 > > while building devel/gcc6 (via a full bootstrap) via -j 4 . > > This is from a non-debug buildworld buildkernel context and has > MALLOC_PRODUCTION= > in /etc/make.conf . No /etc/malloc.conf present. I do use -mcpu=cortex-a7 . > > > > Details if you care: > > # more /usr/src/sys/arm/conf/BPIM3-NODBG > # > # BPIM3 -- Custom configuration for the Banana Pi M3 > # > > include "GENERIC" > > ident BPIM3-NODBG > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug > symbols > > options ALT_BREAK_TO_DEBUGGER > > options KDB # Enable kernel debugger support > > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a panic > options DDB # Enable the kernel debugger > > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit messages > #options BOOTVERBOSE=1 > #options BOOTHOWTO=RB_VERBOSE > #options KTR > #options KTR_MASK=KTR_TRAP > ##options KTR_CPUMASK=0xF > #options KTR_VERBOSE > > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity > checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of internal > structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect > deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks > for speed > nooptions DIAGNOSTIC > > > It was a from cross build for buildworld buildkernel : > (I've not checked on lldb builds linking recently.) > > # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host > TO_TYPE=armv6 > # > KERNCONF=BPIM3-NODBG > TARGET=arm > .if ${.MAKE.LEVEL} == 0 > TARGET_ARCH=${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER= > WITHOUT_SYSTEM_COMPILER= > # > #CPUTYPE=soft > WITH_LIBCPLUSPLUS= > WITH_BINUTILS_BOOTSTRAP= > WITH_CLANG_BOOTSTRAP= > WITH_CLANG= > WITH_CLANG_IS_CC= > WITH_CLANG_FULL= > WITH_CLANG_EXTRAS= > WITH_LLD= > # > # Linking lldb fails for armv6(/v7) > WITHOUT_LLDB= > # > WITH_BOOT= > WITHOUT_LIB32= > WITHOUT_LIBSOFT= > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP= > WITHOUT_GCC_BOOTSTRAP= > WITHOUT_GCC= > WITHOUT_GCC_IS_CC= > WITHOUT_GNUCXX= > # > NO_WERROR= > #WERROR= > MALLOC_PRODUCTION= > # > WITH_REPRODUCIBLE_BUILD= > WITH_DEBUG_FILES= > # > XCFLAGS+= -mcpu=cortex-a7 > XCXXFLAGS+= -mcpu=cortex-a7 > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. > > > Used for buildworld buildkernel : > > # more ~/src.configs/make.conf > #MALLOC_PRODUCTION= > #NO_WERROR= > #WERROR= > CFLAGS.gcc+= -v > > > Used for port builds: > > # more /etc/make.conf > WANT_QT_VERBOSE_CONFIGURE=1 > # > DEFAULT_VERSIONS+=perl5=5.24 > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > WITH_DEBUG_FILES= > MALLOC_PRODUCTION= > > > # svnlite status /usr/src/ | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/BPIM3-DBG > ? /usr/src/sys/arm/conf/BPIM3-NODBG > ? /usr/src/sys/arm/conf/RPI2-DBG > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp > M /usr/src/lib/csu/powerpc64/Makefile > M /usr/src/libexec/rtld-elf/Makefile > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/powerpc/kboot/Makefile > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > M /usr/src/sys/modules/zfs/Makefile > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > > The M's are generally tied to powerpc64 and powerpc > explorations. I tend to use the same source for all > the TARGET_ARCH's that I build. > > > === > Mark Millard > markmi at dsl-only.net > > >