From owner-freebsd-arm@freebsd.org Sun Mar 19 00:30:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E72B3D086D4 for ; Sun, 19 Mar 2017 00:30:49 +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::7]) (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 851C3155B for ; Sun, 19 Mar 2017 00:30:49 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489883447; l=6691; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=hH3zZ838uijtay2W+6m8aIckD5KQsxXJl0HwegnJQtk=; b=h+wTEhfd5q+hi8QR94KXnq5deo9mP4BXLoo/ZvVLImiO/rCYoIoG6PhtCbCloTGM6f 4Wr+TS6/py51Opp85D0W9k7lTrBcSBR2TlBxsCuvQXbOqjRrOYDoctDsraegOoB0MbEM Ls3//SFNK/dw2EHg5KD1qfYEDpLSeUvvc8/mE= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.3 DYNA|AUTH) with ESMTPSA id 40bc89t2J0UkCA2 (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) for ; Sun, 19 Mar 2017 01:30:46 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 4D9247506DAD for ; Sat, 18 Mar 2017 21:30:43 -0300 (BRT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: "Dr. Rolf Jansen" In-Reply-To: <1489864043.40576.219.camel@freebsd.org> Date: Sat, 18 Mar 2017 21:30:41 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) 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, 19 Mar 2017 00:30:50 -0000 Am 18.03.2017 um 16:07 schrieb Ian Lepore : > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >> Am 18.03.2017 um 12:30 schrieb Warner Losh : >>>=20 >>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen >>> wrote: >>>>=20 >>>> I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write >>>> speed for use with my Beaglebone Black. >>>>=20 >>>> The internal flash offers practical write speeds in the range of >>>> 2 to 3 MB/s when copying data to it from a NFSv4 volume depending >>>> on the size of the files being copied. Executing the same copy >>>> operation with said microSDHC card as the target I see only 0.1 >>>> to 0.2 MB/s (less than 1/10). >>>>=20 >>>> I suspect now that I got a counterfeited card. Before I dump it, >>>> I would like to run a definitive non-destructive test, preferably >>>> on the Beaglebone Black, and I would like to ask you for >>>> suggestions. >>>>=20 >>>> Also, it would be nice to see some speed values as a reference >>>> for microSDHC card write speeds on: >>>>=20 >>>> FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 >>>>=20 >>>> Many thanks in advance for any help. >>> Copy a huge file from /dev/zero. Smaller files in the filesystem >>> generate a lot of overhead and 'wait points' that slow down overall >>> performance. >>>=20 >>> Or better yet, dd to the raw device. /dev/random should generate >>> data >>> faster than the card can handle. Depends on what you mean by >>> 'non-destructive' >>>=20 >>> And all NAND sucks. It's a pig with lipstick on it. So you won't >>> get >>> even performance if the FTL in the SD card sucks. Garbage >>> collection, >>> internal house keeping, etc all can steal performance from the user >>> application. These cards are generally designed to take a burst of >>> writes when the camera or video is taken, then have it read back >>> later. A mixed workload was never optimized for on most of these >>> cards, so it can also significantly degrade performance even at low >>> percentage mixtures. >>>=20 >>> So all those things could be going on w/o it being a counterfeit. >>> :(. >>> Of course, it could have all those things going on and also be a >>> counterfeit. Hard to say for sure unless the performance is wildly >>> different. But 4MB/s write performance is pretty pathetic for a >>> card >>> of that size, so it's on the low end, which suffers most from >>> uneven >>> performance and "down hill with the wind" spec numbers. >> Warner, thank you very much for taking your time responding. >>=20 >> It is a Class 4 card, i.e. guaranteed minimum write speed should be 4 >> MB/s, and I know the difference between advertised and practical >> speed, I would have expected at lest 50 % of the advertised speed, >> i.e. something in the range that can be achieved with the internal >> flash of the BBB. I would even be happy if it would come close to 1 >> MB/s. But 0.1 MB/s that is a quit huge difference -- 40 times less >> than the advertised speed. >>=20 >> You said, that 4 MB/s is "pretty pathetic". Therefore let me ask a >> different question. What is the best write speed that can be achieved >> with what model of a microSD card on a Beaglebone Black running >> FreeBSD 12-Current? >>=20 >> Many thanks and best regards >>=20 >> Rolf >=20 > First we've got to keep in mind that BBB has a wimpy processor, and = the > sdhci driver for beaglebone uses PIO, not DMA. If we try a naive test > of writing 100mb of random data to the sdcard... >=20 > root@bb:~ # dd if=3D/dev/random of=3D/dev/mmcsd0s2 bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 14.559020 secs (7202243 bytes/sec) >=20 > It comes in at 7mb/sec, but were we really measuring card performance? >=20 > root@bb:~ # dd if=3D/dev/random of=3D/dev/null bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 6.888693 secs (15221698 bytes/sec) >=20 > So ~15mb/sec just generating and writing random numbers to /dev/null, > that's not very good, in theory an sdcard can write faster than that. >=20 > So let's take the random generation cpu cycles out of the picture by > caching some random data... >=20 > root@bb:~ # dd if=3D/dev/random of=3D/tmp/rand bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 8.566184 secs (12240876 bytes/sec) > root@bb:~ # dd if=3D/tmp/rand of=3D/dev/null bs=3D1m > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 0.625300 secs (167691590 bytes/sec) >=20 > That's more like it, now we're not measuring processor performance = when > we use dd. Now let's see what a raw write to that same sdcard does > using the cached random data... >=20 > root@bb:~ # dd if=3D/tmp/rand of=3D/dev/mmcsd0s2 bs=3D1m > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 7.777464 secs (13482236 bytes/sec) >=20 > So that's about twice as fast as our first naive attempt to test > writing 100mb of random data, and probably represents something pretty > close to the actual BBB raw write speed under best-case conditions for > an sdcard: large sequential writes. >=20 > Now using that command to get actual numbers for some cards I have > laying around: >=20 > Apacer 8gb class 10: 14226229 bytes/sec (industrial temp range) > Kingston 8gb class 4: 7008571 bytes/sec > Kingston 8gb class 10: 9715391 bytes/sec > Lexar 8gb class 6: 8821627 bytes/sec > Sandisk 2gb class n/a: 6163704 bytes/sec (predates speed classes) > Samsung 32gb class 6: 13482236 bytes/sec >=20 > So the cards that perform best are the two I have which cost more than > twice as much as any of the others. Not surprising, I suppose. >=20 > Remember all of these 'dd' tests are for an sdcard's best-case > condition. Real-world UFS accesses are anything but best-case. The > thing an sdcard is worst at is small writes (anything from single- > sector to 16k is very small compared to the typical 4mb erase-block > size on a modern sdcard). Writing ufs metadata is lots and lots of > small writes. You can reduce the writes quite a bit by using > softupdates without journaling. Ian, many thanks for your research. The maximum write speed that I could = achieve was 1 MByte/s with dd'ing cached random data, and the test = results varied quite a bit when repeating the same dd command, the worst = speed was 500 kByte/s. I will buy a new card, and hopefully I will come with that one more = close to the range of rates that you reported for your various cards. Best regards Rolf= From owner-freebsd-arm@freebsd.org Sun Mar 19 00:53: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 3455DD08273 for ; Sun, 19 Mar 2017 00:53:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-175.reflexion.net [208.70.211.175]) (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 D473F1C99 for ; Sun, 19 Mar 2017 00:53:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22904 invoked from network); 19 Mar 2017 00:53:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2017 00:53:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sat, 18 Mar 2017 20:53:42 -0400 (EDT) Received: (qmail 27325 invoked from network); 19 Mar 2017 00:53:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Mar 2017 00:53:41 -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 4149CEC7ED1; Sat, 18 Mar 2017 17:53:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> Date: Sat, 18 Mar 2017 17:53:40 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> To: Andrew Turner 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, 19 Mar 2017 00:53:50 -0000 A new, significant discovery follows. . . While checking out use of procstat -v I ran into the following common property for the 3 programs that I looked at: A) My small test program that fails for a dynamically allocated space. B) sh reporting Failed assertion: "tsd_booted". C) su reporting Failed assertion: "tsd_booted". Here are example addresses from the area of incorrectly zeroed memory (A then B then C): (lldb) print dyn_region (region *volatile) $0 = 0x0000000040616000 (lldb) print &__je_tsd_booted (bool *) $0 = 0x0000000040618520 (lldb) print &__je_tsd_booted (bool *) $0 = 0x0000000040618520 The first is from dynamic allocation ending up in the area. The other two are from libc.so.7 globals/statics ending up in the general area. It looks like something is trashing a specific memory area for some reason, rather independently of what the program specifics are. Other notes: At least for my small program showing failure: Being explicit about the combined conditions for failure for my test program. . . Both tcache enabled and allocations fitting in SMALL_MAXCLASS are required in order to make the program fail. Note: lldb) print __je_tcache_maxclass (size_t) $0 = 32768 which is larger than SMALL_MAXCLASS. I've not observed failures for sizes above SMALL_MAXCLASS but not exceeding __je_tcache_maxclass. Thus tcache use by itself does not seen sufficient for my program to get corruption of its dynamically allocated memory: the small allocation size also matters. Be warned that I can not eliminate the possibility that the trashing changed what region of memory it trashed for larger allocations or when tcache is disabled. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Mar 19 04:10:43 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 570D4D134F7 for ; Sun, 19 Mar 2017 04:10:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-182.reflexion.net [208.70.211.182]) (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 00228BBA for ; Sun, 19 Mar 2017 04:10:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30908 invoked from network); 19 Mar 2017 04:10:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Mar 2017 04:10:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 19 Mar 2017 00:10:36 -0400 (EDT) Received: (qmail 2340 invoked from network); 19 Mar 2017 04:10:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Mar 2017 04:10:36 -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 70116EC894B; Sat, 18 Mar 2017 21:10:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> Date: Sat, 18 Mar 2017 21:10:34 -0700 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> To: Andrew Turner , 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: Sun, 19 Mar 2017 04:10:43 -0000 On 2017-Mar-18, at 5:53 PM, Mark Millard wrote: > A new, significant discovery follows. . . > > While checking out use of procstat -v I ran > into the following common property for the 3 > programs that I looked at: > > A) My small test program that fails for > a dynamically allocated space. > > B) sh reporting Failed assertion: "tsd_booted". > > C) su reporting Failed assertion: "tsd_booted". > > Here are example addresses from the area of > incorrectly zeroed memory (A then B then C): > > (lldb) print dyn_region > (region *volatile) $0 = 0x0000000040616000 > > (lldb) print &__je_tsd_booted > (bool *) $0 = 0x0000000040618520 > > (lldb) print &__je_tsd_booted > (bool *) $0 = 0x0000000040618520 That last above was a copy/paste error. Correction: (lldb) print &__je_tsd_booted (bool *) $0 = 0x000000004061d520 > The first is from dynamic allocation ending up > in the area. The other two are from libc.so.7 > globals/statics ending up in the general area. > > It looks like something is trashing a specific > memory area for some reason, rather independently > of what the program specifics are. > > > Other notes: > > At least for my small program showing failure: > > Being explicit about the combined conditions for failure > for my test program. . . > > Both tcache enabled and allocations fitting in SMALL_MAXCLASS > are required in order to make the program fail. > > Note: > > lldb) print __je_tcache_maxclass > (size_t) $0 = 32768 > > which is larger than SMALL_MAXCLASS. I've not observed > failures for sizes above SMALL_MAXCLASS but not exceeding > __je_tcache_maxclass. > > Thus tcache use by itself does not seen sufficient for > my program to get corruption of its dynamically allocated > memory: the small allocation size also matters. > > > Be warned that I can not eliminate the possibility that > the trashing changed what region of memory it trashed > for larger allocations or when tcache is disabled. The pine64+ 2GB eventually got into a state where: /etc/malloc.conf -> tcache:false made no difference and the failure kept occurring with that symbolic link in place. But after a reboot of the pin46+ 2GB /etc/malloc.conf -> tcache:false was again effective for my test program. (It was still present from before the reboot.) I checked the .core files and the allocated address assigned to dyn_region was the same in the tries before and after the reboot. (I had put in an additional raise(SIGABRT) so I'd always have a core file to look at.) Apparently /etc/malloc.conf -> tcache:false was being ignored before the reboot for some reason? === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Mar 19 13:59: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 010C0D13116 for ; Sun, 19 Mar 2017 13:59:48 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E3A79EE for ; Sun, 19 Mar 2017 13:59:46 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 19 Mar 2017 14:59:38 +0100 id 00F4BDE2.58CE8ECA.000179C4 Date: Sun, 19 Mar 2017 14:59:37 +0100 From: Milan Obuch To: freebsd-arm@FreeBSD.org Subject: Another Allwinner board - Orange Pi Zero Message-ID: <20170319145937.658e7ba7@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) 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: Sun, 19 Mar 2017 13:59:48 -0000 Hi, this is just a note to let you know this board appears to work just fine with the same SD as used for H3 based Orange Pi boards (I have working PC plus, did not check One for a while). It is H2+ based, which is similar to H3, I just read there is some video related feature reduced, but I can't say for sure. This device is smaller with less pins, but I think it is ideal for some IoT device. I started buildworld already as kind of stress and stability test. It has 12-CURRENT built on Dec 1st, svn revision not known 'cause of svn over nfs problem, currently solved with nolockd mount option, so if system rrebuild succeeds, revision should be in uname. As I have cheaper 256 MB version, I expect the whole process take long time. Regards, Milan From owner-freebsd-arm@freebsd.org Sun Mar 19 14:18: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 1EEB6D13846 for ; Sun, 19 Mar 2017 14:18:27 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 D4FAA1ADF for ; Sun, 19 Mar 2017 14:18:26 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x22a.google.com with SMTP id x35so91064555qtc.2 for ; Sun, 19 Mar 2017 07:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=jfOnfT72aRznkZEfZDJ12N6sLVea77FdGWDYoUSn4yo=; b=Dz3av2c+FbU8pEblWImjRXNN+hZWF4PleHEyGiVEpvkoF10l9nIm7N5fWWWMdvbewE C07QskqDZXZ22ydRR+orYrhunBmrB7ylD9c/qAV1pHKbA55SW0xTrrG4zMgB+/duDdRc tMs9BG9xV+1w0dQj0v3s3Eehiu9cLoTNQMzQY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jfOnfT72aRznkZEfZDJ12N6sLVea77FdGWDYoUSn4yo=; b=FVBLWfCCFAVxzuX6QQDkz5jFyOu8YerFRWvM+z6WRTxY9A8Kh5hs28548HH15/TmbG +IYhBLsA29jsb6cKByE+o083YNd4K422Ak4xKLpP9gsWxmTkZlF/nZ7iACpeiF/URs67 ioF8Adkm4Rwjm9z4bEAncxL4fEiMkRB8ce4YMm/wLuqT/vaDBpi5M7sqMllUmlPyvNkj jZgRjJPE105mGggfayPlzuBvFYy0le6Ep/O7nO+8kjw7tHXzxSXaxMmBxUGtZ3Yo+KY3 4heS+LApxelirOpT7rjknC9Zevi/AaVrlHyufpoKckuF1U8kFqfdsZADp6onTwmlum0u T7Uw== X-Gm-Message-State: AFeK/H3k41qW/b4v6QmjmVxGIXB78umYlJS5HhkF4lb/EyYeLNo9swbVMRKD7AMt4ITeKQ== X-Received: by 10.200.54.46 with SMTP id m43mr25381289qtb.127.1489933105427; Sun, 19 Mar 2017 07:18:25 -0700 (PDT) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id y33sm10367959qta.27.2017.03.19.07.18.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 07:18:24 -0700 (PDT) Subject: Re: A potential fix for arm64's: sh`forkshell child-process path after fork sometimes has a bad stack pointer value To: freebsd-arm@freebsd.org References: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Sun, 19 Mar 2017 11:18:12 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 14:18:27 -0000 Em 14/02/2017 13:35, Mark Millard escreveu: > The following change has let my test run for 8.5 hours so far without a > fork-failure in sh`forkshell : > > # svnlite diff /usr/src/sys/arm64/arm64/swtch.S > Index: /usr/src/sys/arm64/arm64/swtch.S > =================================================================== > --- /usr/src/sys/arm64/arm64/swtch.S (revision 312982) > +++ /usr/src/sys/arm64/arm64/swtch.S (working copy) > @@ -241,6 +241,12 @@ > mov fp, #0 /* Stack traceback stops here. */ > bl _C_LABEL(fork_exit) > > + /* > + * Disable interrupts to avoid > + * overwriting sp_el0 and spsr_el1 by an IRQ exception. > + */ > + msr daifset, #2 > + > /* Restore sp and lr */ > ldp x0, x1, [sp] > msr sp_el0, x0 > @@ -263,12 +269,6 @@ > ldp x28, x29, [sp, #TF_X + 28 * 8] > /* Skip x30 as it was restored above as lr */ > > - /* > - * Disable interrupts to avoid > - * overwriting spsr_el1 by an IRQ exception. > - */ > - msr daifset, #2 > - > /* Restore elr and spsr */ > ldp x0, x1, [sp, #16] > msr elr_el1, x0 > > I'm going to switch to attempting a self-hosted buildworld > buildkernel again. > > === > 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" This patch or some other about this bug was committed to HEAD? []'s -Otacilio From owner-freebsd-arm@freebsd.org Sun Mar 19 14:29: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 AFA22D13B7E for ; Sun, 19 Mar 2017 14:29:45 +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 8BF9327A for ; Sun, 19 Mar 2017 14:29:45 +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 v2JETjCX088524 for ; Sun, 19 Mar 2017 14:29:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 209037] sdhci_ti0-slot0: Got data interrupt 0x00100000, but there is no active command. Date: Sun, 19 Mar 2017 14:29:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: otacilio.neto@bsd.com.br X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: 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: Sun, 19 Mar 2017 14:29:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209037 otacilio.neto@bsd.com.br changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Mar 19 18:46: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 34A81D1360E for ; Sun, 19 Mar 2017 18:46:37 +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 0F3431024 for ; Sun, 19 Mar 2017 18:46:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5a426461-0cd4-11e7-8c45-c35e37f62db1 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 5a426461-0cd4-11e7-8c45-c35e37f62db1; Sun, 19 Mar 2017 18:46:24 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2JIkQ52001872; Sun, 19 Mar 2017 12:46:26 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489949186.80839.2.camel@freebsd.org> Subject: Re: Making INTRNG a requirement on armv6 From: Ian Lepore To: Andrew Turner , freebsd-arm@freebsd.org Date: Sun, 19 Mar 2017 12:46:26 -0600 In-Reply-To: <1489685852.40576.165.camel@freebsd.org> References: <1489685852.40576.165.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-7" 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, 19 Mar 2017 18:46:37 -0000 On Thu, 2017-03-16 at 11:37 -0600, Ian Lepore wrote: > On Thu, 2017-03-16 at 17:08 +0000, Andrew Turner wrote: > > > > Hello arm, > > > > I would like to make INTRNG a requirement on armv6. This is to help > > with moving more armv6 kernel configurations into GENERIC. It also > > helps when we want a child interrupt controller, e.g. a GPIO > > driver. > > > > Most of the current armv6 kernel configurations already use INTRNG, > > so > > only a few places need to be updated.  > > > > I¢ve run a test build making it an error to not have INTRNG enabled > > and > > found the following armv6 configs fail: > > > > AML8726 > > ARMADAXP > > DIGI-CCWMX53 > > EFIKA_MX > > IMX53 > > IMX53-QSB > > VERSATILEPB > > YYHD18 > > > > I'm interested in people who have this hardware to try enabling > > INTRNG > > and testing. Note that this may require the interrupt controller > > driver > > the SoC uses to be ported to INTRNG. > > > > Andrew > I'll try to find time to convert the imx5x driver this weekend. > > -- Ian I took care of DIGI-CCWMX53 and IMX53-QSB by just deleting them (they were just standard IMX53 with a static dtb added), and converted the imx5 driver to intrng to handle EFIKA_MX and IMX53. -- Ian From owner-freebsd-arm@freebsd.org Sun Mar 19 19:40: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 531D1D1377E for ; Sun, 19 Mar 2017 19:40:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-174.reflexion.net [208.70.211.174]) (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 050D4CEF for ; Sun, 19 Mar 2017 19:40:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12301 invoked from network); 19 Mar 2017 19:40:18 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2017 19:40:18 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 19 Mar 2017 15:40:18 -0400 (EDT) Received: (qmail 20831 invoked from network); 19 Mar 2017 19:40:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Mar 2017 19:40:18 -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 8D0BEEC761E; Sun, 19 Mar 2017 12:40:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A potential fix for arm64's: sh`forkshell child-process path after fork sometimes has a bad stack pointer value From: Mark Millard In-Reply-To: Date: Sun, 19 Mar 2017 12:40:16 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <33D7B40E-9383-4C65-A212-A0F218CB3CFB@dsl-only.net> References: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> To: =?utf-8?B?T3RhY8OtbGlv?= 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, 19 Mar 2017 19:40:26 -0000 On 2017-Mar-19, at 7:18 AM, Otac=C3=ADlio = wrote: > Em 14/02/2017 13:35, Mark Millard escreveu: >> The following change has let my test run for 8.5 hours so far without = a >> fork-failure in sh`forkshell : >>=20 >> # svnlite diff /usr/src/sys/arm64/arm64/swtch.S >> Index: /usr/src/sys/arm64/arm64/swtch.S >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/arm64/arm64/swtch.S (revision 312982) >> +++ /usr/src/sys/arm64/arm64/swtch.S (working copy) >> @@ -241,6 +241,12 @@ >> mov fp, #0 /* Stack traceback stops here. */ >> bl _C_LABEL(fork_exit) >> + /* >> + * Disable interrupts to avoid >> + * overwriting sp_el0 and spsr_el1 by an IRQ exception. >> + */ >> + msr daifset, #2 >> + >> /* Restore sp and lr */ >> ldp x0, x1, [sp] >> msr sp_el0, x0 >> @@ -263,12 +269,6 @@ >> ldp x28, x29, [sp, #TF_X + 28 * 8] >> /* Skip x30 as it was restored above as lr */ >> - /* >> - * Disable interrupts to avoid >> - * overwriting spsr_el1 by an IRQ exception. >> - */ >> - msr daifset, #2 >> - >> /* Restore elr and spsr */ >> ldp x0, x1, [sp, #16] >> msr elr_el1, x0 >>=20 >> I'm going to switch to attempting a self-hosted buildworld >> buildkernel again. >=20 > This patch or some other about this bug was committed to HEAD? Yes, "some other" in -r313772 (2017-Feb-15). See: = https://lists.freebsd.org/pipermail/svn-src-head/2017-February/097004.html= which in part says: Author: andrew Date: Wed Feb 15 14:56:47 2017 New Revision: 313772 URL:=20 https://svnweb.freebsd.org/changeset/base/313772 Log: Load the new sp_el0 with interrupts disabled in fork_trampoline. If an interrupt arrives in fork_trampoline after sp_el0 was written we may = then switch to a new thread, enter userland so change this stack pointer, = then return to this code with the wrong value. This fixes this case by = moving the load of sp_el0 until after interrupts have been disabled. =20 Reported by: Mark Millard (markmi at dsl-only.net) Sponsored by: ABT Systems Ltd Differential Revision: https://reviews.freebsd.org/D9593 Modified: head/sys/arm64/arm64/swtch.S =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Mar 19 21:45: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 71E6ED139EB for ; Sun, 19 Mar 2017 21:45:20 +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::11]) (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 0C04439D for ; Sun, 19 Mar 2017 21:45:19 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489959915; l=8597; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=hooPLhMF3IDSj6Ns3YYVNtB6dU47eDK2w7dEQ/6X0Ek=; b=SANLOtEU6uxZhi8VQH2FEWG0BXikcNg7EsKfB1ohoozhFEdZMbMAhEAHP8NnTW1TBy 1YCr1zawBOb/WqHUMX1Fx3mWIAExOasg3dkBkNXwPeS5zZAI45nHjRz2IMx9lyIa6Ej9 qiHLR30iQIhMRhMs2Abk6Yl5Krndhts9mptxU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id L0a42dt2JLjEKYK (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) for ; Sun, 19 Mar 2017 22:45:14 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id EEC727506DAD for ; Sun, 19 Mar 2017 18:45:11 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: "Dr. Rolf Jansen" In-Reply-To: <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> Date: Sun, 19 Mar 2017 18:45:10 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) 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, 19 Mar 2017 21:45:20 -0000 Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen : > Am 18.03.2017 um 16:07 schrieb Ian Lepore : >> On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >>> Am 18.03.2017 um 12:30 schrieb Warner Losh : >>>>=20 >>>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen >>>> wrote: >>>>>=20 >>>>> I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write >>>>> speed for use with my Beaglebone Black. >>>>>=20 >>>>> The internal flash offers practical write speeds in the range of >>>>> 2 to 3 MB/s when copying data to it from a NFSv4 volume depending >>>>> on the size of the files being copied. Executing the same copy >>>>> operation with said microSDHC card as the target I see only 0.1 >>>>> to 0.2 MB/s (less than 1/10). >>>>>=20 >>>>> I suspect now that I got a counterfeited card. Before I dump it, >>>>> I would like to run a definitive non-destructive test, preferably >>>>> on the Beaglebone Black, and I would like to ask you for >>>>> suggestions. >>>>>=20 >>>>> Also, it would be nice to see some speed values as a reference >>>>> for microSDHC card write speeds on: >>>>>=20 >>>>> FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 >>>>>=20 >>>>> Many thanks in advance for any help. >>>> Copy a huge file from /dev/zero. Smaller files in the filesystem >>>> generate a lot of overhead and 'wait points' that slow down overall >>>> performance. >>>>=20 >>>> Or better yet, dd to the raw device. /dev/random should generate >>>> data >>>> faster than the card can handle. Depends on what you mean by >>>> 'non-destructive' >>>>=20 >>>> And all NAND sucks. It's a pig with lipstick on it. So you won't >>>> get >>>> even performance if the FTL in the SD card sucks. Garbage >>>> collection, >>>> internal house keeping, etc all can steal performance from the user >>>> application. These cards are generally designed to take a burst of >>>> writes when the camera or video is taken, then have it read back >>>> later. A mixed workload was never optimized for on most of these >>>> cards, so it can also significantly degrade performance even at low >>>> percentage mixtures. >>>>=20 >>>> So all those things could be going on w/o it being a counterfeit. >>>> :(. >>>> Of course, it could have all those things going on and also be a >>>> counterfeit. Hard to say for sure unless the performance is wildly >>>> different. But 4MB/s write performance is pretty pathetic for a >>>> card >>>> of that size, so it's on the low end, which suffers most from >>>> uneven >>>> performance and "down hill with the wind" spec numbers. >>> Warner, thank you very much for taking your time responding. >>>=20 >>> It is a Class 4 card, i.e. guaranteed minimum write speed should be = 4 >>> MB/s, and I know the difference between advertised and practical >>> speed, I would have expected at lest 50 % of the advertised speed, >>> i.e. something in the range that can be achieved with the internal >>> flash of the BBB. I would even be happy if it would come close to 1 >>> MB/s. But 0.1 MB/s that is a quit huge difference -- 40 times less >>> than the advertised speed. >>>=20 >>> You said, that 4 MB/s is "pretty pathetic". Therefore let me ask a >>> different question. What is the best write speed that can be = achieved >>> with what model of a microSD card on a Beaglebone Black running >>> FreeBSD 12-Current? >>>=20 >>> Many thanks and best regards >>>=20 >>> Rolf >>=20 >> First we've got to keep in mind that BBB has a wimpy processor, and = the >> sdhci driver for beaglebone uses PIO, not DMA. If we try a naive = test >> of writing 100mb of random data to the sdcard... >>=20 >> root@bb:~ # dd if=3D/dev/random of=3D/dev/mmcsd0s2 bs=3D1m count=3D100 >> 100+0 records in >> 100+0 records out >> 104857600 bytes transferred in 14.559020 secs (7202243 bytes/sec) >>=20 >> It comes in at 7mb/sec, but were we really measuring card = performance? >>=20 >> root@bb:~ # dd if=3D/dev/random of=3D/dev/null bs=3D1m count=3D100 >> 100+0 records in >> 100+0 records out >> 104857600 bytes transferred in 6.888693 secs (15221698 bytes/sec) >>=20 >> So ~15mb/sec just generating and writing random numbers to /dev/null, >> that's not very good, in theory an sdcard can write faster than that. >>=20 >> So let's take the random generation cpu cycles out of the picture by >> caching some random data... >>=20 >> root@bb:~ # dd if=3D/dev/random of=3D/tmp/rand bs=3D1m count=3D100 >> 100+0 records in >> 100+0 records out >> 104857600 bytes transferred in 8.566184 secs (12240876 bytes/sec) >> root@bb:~ # dd if=3D/tmp/rand of=3D/dev/null bs=3D1m >> 100+0 records in >> 100+0 records out >> 104857600 bytes transferred in 0.625300 secs (167691590 bytes/sec) >>=20 >> That's more like it, now we're not measuring processor performance = when >> we use dd. Now let's see what a raw write to that same sdcard does >> using the cached random data... >>=20 >> root@bb:~ # dd if=3D/tmp/rand of=3D/dev/mmcsd0s2 bs=3D1m >> 100+0 records in >> 100+0 records out >> 104857600 bytes transferred in 7.777464 secs (13482236 bytes/sec) >>=20 >> So that's about twice as fast as our first naive attempt to test >> writing 100mb of random data, and probably represents something = pretty >> close to the actual BBB raw write speed under best-case conditions = for >> an sdcard: large sequential writes. >>=20 >> Now using that command to get actual numbers for some cards I have >> laying around: >>=20 >> Apacer 8gb class 10: 14226229 bytes/sec (industrial temp range) >> Kingston 8gb class 4: 7008571 bytes/sec >> Kingston 8gb class 10: 9715391 bytes/sec >> Lexar 8gb class 6: 8821627 bytes/sec >> Sandisk 2gb class n/a: 6163704 bytes/sec (predates speed classes) >> Samsung 32gb class 6: 13482236 bytes/sec >>=20 >> So the cards that perform best are the two I have which cost more = than >> twice as much as any of the others. Not surprising, I suppose. >>=20 >> Remember all of these 'dd' tests are for an sdcard's best-case >> condition. Real-world UFS accesses are anything but best-case. The >> thing an sdcard is worst at is small writes (anything from single- >> sector to 16k is very small compared to the typical 4mb erase-block >> size on a modern sdcard). Writing ufs metadata is lots and lots of >> small writes. You can reduce the writes quite a bit by using >> softupdates without journaling. >=20 > Ian, many thanks for your research. The maximum write speed that I = could achieve was 1 MByte/s with dd'ing cached random data, and the test = results varied quite a bit when repeating the same dd command, the worst = speed was 500 kByte/s. >=20 > I will buy a new card, and hopefully I will come with that one more = close to the range of rates that you reported for your various cards. I found another (old) microSD card SanDisk 16 GB Class 10. After = partitioning but before formatting with newfs, I tested the sequential = writing speed be dd'ing directly to the device. I set apart only 50 MB = in my tmpfs, and therefore I ran the tests with 40 MB (everything is run = on FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 mounted from the = internal flash): # dd if=3D/dev/random of=3D/tmp/random.bin bs=3D1m count=3D40 # dd if=3D/tmp/random.bin of=3D/dev/mmcsd1s2 bs=3D1m count=3D40 The initial results were promising, namely rates in the range from 12 to = 14 MB/s. After formatting using: ... # newfs -ntUE -L SYSTEM /dev/mmcsd1s2a # mount -o noatime /dev/ufs/SYSTEM /mnt ... the results were eventually disappointing: # dd if=3D/tmp/random.bin of=3D/mnt/random1.bin bs=3D1m count=3D40 11565980 bytes/sec # dd if=3D/tmp/random.bin of=3D/mnt/random2.bin bs=3D1m count=3D40 8267796 bytes/sec # dd if=3D/tmp/random.bin of=3D/mnt/random3.bin bs=3D1m count=3D40 615993 bytes/sec In contrast to writing to the mounted root filesystem / on the internal = flash: # dd if=3D/tmp/random.bin of=3D/random1.bin bs=3D1m count=3D40 10798380 bytes/sec # dd if=3D/tmp/random.bin of=3D/random2.bin bs=3D1m count=3D40 10510983 bytes/sec # dd if=3D/tmp/random.bin of=3D/random3.bin bs=3D1m count=3D40 10740969 bytes/sec Might it be, that FreeBSD 12 treats the UFS on the internal flash = somehow different compared to UFS on the microSD? Perhaps trim works on = the internal flash but not on mounted SD cards? Anyway, I will buy a new card and we'll see whether this changes = something. Best regards Rolf From owner-freebsd-arm@freebsd.org Sun Mar 19 22:31:07 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 751D4D13B89 for ; Sun, 19 Mar 2017 22:31:07 +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 4D5D8338 for ; Sun, 19 Mar 2017 22:31:07 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b9ccff1f-0cf3-11e7-bfb5-0d159cd3c324 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id b9ccff1f-0cf3-11e7-bfb5-0d159cd3c324; Sun, 19 Mar 2017 22:30:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2JMUvk3002207; Sun, 19 Mar 2017 16:30:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489962657.80839.8.camel@freebsd.org> Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Sun, 19 Mar 2017 16:30:57 -0600 In-Reply-To: <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.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, 19 Mar 2017 22:31:07 -0000 On Sun, 2017-03-19 at 18:45 -0300, Dr. Rolf Jansen wrote: > Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen : > > > > Am 18.03.2017 um 16:07 schrieb Ian Lepore : > > > > > > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: > > > > > > > > Am 18.03.2017 um 12:30 schrieb Warner Losh : > > > > > > > > > > > > > > > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen > > > > com> > > > > > wrote: > > > > > > > > > > > > > > > > > > I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s > > > > > > write > > > > > > speed for use with my Beaglebone Black. > > > > > > > > > > > > The internal flash offers practical write speeds in the > > > > > > range of > > > > > > 2 to 3 MB/s when copying data to it from a NFSv4 volume > > > > > > depending > > > > > > on the size of the files being copied. Executing the same > > > > > > copy > > > > > > operation with said microSDHC card as the target I see only > > > > > > 0.1 > > > > > > to 0.2 MB/s (less than 1/10). > > > > > > > > > > > > I suspect now that I got a counterfeited card. Before I > > > > > > dump it, > > > > > > I would like to run a definitive non-destructive test, > > > > > > preferably > > > > > > on the Beaglebone Black, and I would like to ask you for > > > > > > suggestions. > > > > > > > > > > > > Also, it would be nice to see some speed values as a > > > > > > reference > > > > > > for microSDHC card write speeds on: > > > > > > > > > > > >   FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 > > > > > > > > > > > > Many thanks in advance for any help. > > > > > Copy a huge file from /dev/zero. Smaller files in the > > > > > filesystem > > > > > generate a lot of overhead and 'wait points' that slow down > > > > > overall > > > > > performance. > > > > > > > > > > Or better yet, dd to the raw device. /dev/random should > > > > > generate > > > > > data > > > > > faster than the card can handle. Depends on what you mean by > > > > > 'non-destructive' > > > > > > > > > > And all NAND sucks. It's a pig with lipstick on it. So you > > > > > won't > > > > > get > > > > > even performance if the FTL in the SD card sucks. Garbage > > > > > collection, > > > > > internal house keeping, etc all can steal performance from > > > > > the user > > > > > application. These cards are generally designed to take a > > > > > burst of > > > > > writes when the camera or video is taken, then have it read > > > > > back > > > > > later. A mixed workload was never optimized for on most of > > > > > these > > > > > cards, so it can also significantly degrade performance even > > > > > at low > > > > > percentage mixtures. > > > > > > > > > > So all those things could be going on w/o it being a > > > > > counterfeit. > > > > > :(. > > > > > Of course, it could have all those things going on and also > > > > > be a > > > > > counterfeit. Hard to say for sure unless the performance is > > > > > wildly > > > > > different. But 4MB/s write performance is pretty pathetic for > > > > > a > > > > > card > > > > > of that size, so it's on the low end, which suffers most from > > > > > uneven > > > > > performance and "down hill with the wind" spec numbers. > > > > Warner, thank you very much for taking your time responding. > > > > > > > > It is a Class 4 card, i.e. guaranteed minimum write speed > > > > should be 4 > > > > MB/s, and I know the difference between advertised and > > > > practical > > > > speed, I would have expected at lest 50 % of the advertised > > > > speed, > > > > i.e. something in the range that can be achieved with the > > > > internal > > > > flash of the BBB. I would even be happy if it would come close > > > > to 1 > > > > MB/s. But 0.1 MB/s that is a quit huge difference -- 40 times > > > > less > > > > than the advertised speed. > > > > > > > > You said, that 4 MB/s is "pretty pathetic". Therefore let me > > > > ask a > > > > different question. What is the best write speed that can be > > > > achieved > > > > with what model of a microSD card on a Beaglebone Black running > > > > FreeBSD 12-Current? > > > > > > > > Many thanks and best regards > > > > > > > > Rolf > > > First we've got to keep in mind that BBB has a wimpy processor, > > > and the > > > sdhci driver for beaglebone uses PIO, not DMA.  If we try a naive > > > test > > > of writing 100mb of random data to the sdcard... > > > > > > root@bb:~ # dd if=/dev/random of=/dev/mmcsd0s2 bs=1m count=100 > > > 100+0 records in > > > 100+0 records out > > > 104857600 bytes transferred in 14.559020 secs (7202243 bytes/sec) > > > > > > It comes in at 7mb/sec, but were we really measuring card > > > performance? > > > > > > root@bb:~ # dd if=/dev/random of=/dev/null bs=1m count=100 > > > 100+0 records in > > > 100+0 records out > > > 104857600 bytes transferred in 6.888693 secs (15221698 bytes/sec) > > > > > > So ~15mb/sec just generating and writing random numbers to > > > /dev/null, > > > that's not very good, in theory an sdcard can write faster than > > > that. > > > > > > So let's take the random generation cpu cycles out of the picture > > > by > > > caching some random data... > > > > > > root@bb:~ # dd if=/dev/random of=/tmp/rand bs=1m count=100 > > > 100+0 records in > > > 100+0 records out > > > 104857600 bytes transferred in 8.566184 secs (12240876 bytes/sec) > > > root@bb:~ # dd if=/tmp/rand of=/dev/null bs=1m > > > 100+0 records in > > > 100+0 records out > > > 104857600 bytes transferred in 0.625300 secs (167691590 > > > bytes/sec) > > > > > > That's more like it, now we're not measuring processor > > > performance when > > > we use dd.  Now let's see what a raw write to that same sdcard > > > does > > > using the cached random data... > > > > > > root@bb:~ # dd if=/tmp/rand of=/dev/mmcsd0s2 bs=1m > > > 100+0 records in > > > 100+0 records out > > > 104857600 bytes transferred in 7.777464 secs (13482236 bytes/sec) > > > > > > So that's about twice as fast as our first naive attempt to test > > > writing 100mb of random data, and probably represents something > > > pretty > > > close to the actual BBB raw write speed under best-case > > > conditions for > > > an sdcard: large sequential writes. > > > > > > Now using that command to get actual numbers for some cards I > > > have > > > laying around: > > > > > > Apacer   8gb class  10: 14226229 bytes/sec (industrial temp > > > range) > > > Kingston 8gb class   4:  7008571 bytes/sec > > > Kingston 8gb class  10:  9715391 bytes/sec > > > Lexar    8gb class   6:  8821627 bytes/sec > > > Sandisk  2gb class n/a:  6163704 bytes/sec (predates speed > > > classes) > > > Samsung 32gb class   6: 13482236 bytes/sec > > > > > > So the cards that perform best are the two I have which cost more > > > than > > > twice as much as any of the others.  Not surprising, I suppose. > > > > > > Remember all of these 'dd' tests are for an sdcard's best-case > > > condition.  Real-world UFS accesses are anything but best- > > > case.  The > > > thing an sdcard is worst at is small writes (anything from > > > single- > > > sector to 16k is very small compared to the typical 4mb erase- > > > block > > > size on a modern sdcard).  Writing ufs metadata is lots and lots > > > of > > > small writes.  You can reduce the writes quite a bit by using > > > softupdates without journaling. > > Ian, many thanks for your research. The maximum write speed that I > > could achieve was 1 MByte/s with dd'ing cached random data, and the > > test results varied quite a bit when repeating the same dd command, > > the worst speed was 500 kByte/s. > > > > I will buy a new card, and hopefully I will come with that one more > > close to the range of rates that you reported for your various > > cards. > I found another (old) microSD card SanDisk 16 GB Class 10. After > partitioning but before formatting with newfs, I tested the > sequential writing speed be dd'ing directly to the device. I set > apart only 50 MB in my tmpfs, and therefore I ran the tests with 40 > MB (everything is run on FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 > mounted from the internal flash): > >   # dd if=/dev/random of=/tmp/random.bin bs=1m count=40 >   # dd if=/tmp/random.bin of=/dev/mmcsd1s2 bs=1m count=40 > > The initial results were promising, namely rates in the range from 12 > to 14 MB/s. > > After formatting using: ... > >   # newfs -ntUE -L SYSTEM /dev/mmcsd1s2a >   # mount -o noatime /dev/ufs/SYSTEM /mnt > > ... the results were eventually disappointing: > >   # dd if=/tmp/random.bin of=/mnt/random1.bin bs=1m count=40 >   11565980 bytes/sec > >   # dd if=/tmp/random.bin of=/mnt/random2.bin bs=1m count=40 >    8267796 bytes/sec > >   # dd if=/tmp/random.bin of=/mnt/random3.bin bs=1m count=40 >     615993 bytes/sec > > > In contrast to writing to the mounted root filesystem / on the > internal flash: > >   # dd if=/tmp/random.bin of=/random1.bin bs=1m count=40 >   10798380 bytes/sec > >   # dd if=/tmp/random.bin of=/random2.bin bs=1m count=40 >   10510983 bytes/sec > >   # dd if=/tmp/random.bin of=/random3.bin bs=1m count=40 >   10740969 bytes/sec > > Might it be, that FreeBSD 12 treats the UFS on the internal flash > somehow different compared to UFS on the microSD? Perhaps trim works > on the internal flash but not on mounted SD cards? > > Anyway, I will buy a new card and we'll see whether this changes > something. > > Best regards > > Rolf I had a quick try of the same thing with a samsung and a kingston card and couldn't replicate your results. It might be interesting for you to try again but leave off the -t when formatting the filesystem.  The implementation of BIO_DELETE/trim for sdcard is particularly bad in freebsd (I'm not even sure it's correct, but if it's wrong it's in a harmless way, not a data-destroying way).  I've been meaning to investigate it further, just haven't found time yet. I do know that different sdcards react to delete/trim operations in different ways.  Good fast cards seem to do the delete just by manipulating metadata and the operation is almost instant.  Other cards do the lengthy flash-erase operations "while you wait" which usually ruins performance rather than enhancing it. -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 20 15:27:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC6C2D13586 for ; Mon, 20 Mar 2017 15:27:49 +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 9534B1D87 for ; Mon, 20 Mar 2017 15:27:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id w124so92197491itb.1 for ; Mon, 20 Mar 2017 08:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qU2pAMSSkPtIaJsCW6kW+EMRpzQs4sZEb1DJGHndpjQ=; b=Q7GobWYtjCyEDiRG5rpl7chXCzN9mwveuqCEZ5/DZFQ/B+6SbJNioj06vM4kyCLlmC oi7h+3P96MmaWlj+YutYtuCsuq6gu6li0DBG/+1x1ilfn8Bpa2wFIp2MPqyiI+bLmzji V53J7k0kQOCvtmJG+Lm6KcUbc10i7kG9/2cQw/UdxJ1jYio33qeAp/W1QcA2qkDFElLL 7OGPlfc4MQh26pu9LGFrI9RMvfyNkaa5ku00PJRij45+Q0oqOrb23K/e+pxDqVGRKUfP eOtApiuOX6LFOWdCpTmBU/sTATT5Ez3W2eRHnOIEYxPlCfYQEfAq9r1aU3ZbHvpVuzM9 TJIg== 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=qU2pAMSSkPtIaJsCW6kW+EMRpzQs4sZEb1DJGHndpjQ=; b=Q3W1NJay13/l7yNBsNOssPYz8LDh2MiGLVl72zbo92GDJJ6WWGKqnqp9h5mlxO6egi ctNop5VkBnY4nnvOlB2nhsA7QFgbWkw38pxzXNUjfxNoxlnetxhRBUdbF1Tl0sHJvfMe m1cBoCcEtuf/wQHyhkLmdUjacEXxOedZzLGOLNY8JM5qRzQa/CX+A8QdhJaZzmO+tYMt 2/i3fdIB/nO4KgEK/Ou7sApf9HDCc51zV4JQUNydcMqPmLzogje2I6t37uq77AtD3LGF HvXy3x7f++QItZObkisNgsDCP/vpdHjEN7ldZpaf16ytQ+Z12EH1ofsB0QPWa1Tdwkh+ eJ9g== X-Gm-Message-State: AFeK/H2vjWDrIYNgR4YMcxwXE230mcnU7hWBpW6M/06pgs/x5UcB8y4BExLmEJeNiC93nuVNvKkT+IbBpmIoqQ== X-Received: by 10.36.250.131 with SMTP id v125mr5044964ith.85.1490023605235; Mon, 20 Mar 2017 08:26:45 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Mon, 20 Mar 2017 08:26:44 -0700 (PDT) X-Originating-IP: [96.90.183.18] In-Reply-To: <1489962657.80839.8.camel@freebsd.org> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <1489962657.80839.8.camel@freebsd.org> From: Warner Losh Date: Mon, 20 Mar 2017 09:26:44 -0600 X-Google-Sender-Auth: TqAfSwf5IdZzxq0waTwVCRHZpyA Message-ID: Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black To: Ian Lepore Cc: "Dr. Rolf Jansen" , "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, 20 Mar 2017 15:27:50 -0000 On Sun, Mar 19, 2017 at 4:30 PM, Ian Lepore wrote: > On Sun, 2017-03-19 at 18:45 -0300, Dr. Rolf Jansen wrote: >> Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen : >> > >> > Am 18.03.2017 um 16:07 schrieb Ian Lepore : >> > > >> > > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >> > > > >> > > > Am 18.03.2017 um 12:30 schrieb Warner Losh : >> > > > > >> > > > > >> > > > > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen > > > > > com> >> > > > > wrote: >> > > > > > >> > > > > > >> > > > > > I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s >> > > > > > write >> > > > > > speed for use with my Beaglebone Black. >> > > > > > >> > > > > > The internal flash offers practical write speeds in the >> > > > > > range of >> > > > > > 2 to 3 MB/s when copying data to it from a NFSv4 volume >> > > > > > depending >> > > > > > on the size of the files being copied. Executing the same >> > > > > > copy >> > > > > > operation with said microSDHC card as the target I see only >> > > > > > 0.1 >> > > > > > to 0.2 MB/s (less than 1/10). >> > > > > > >> > > > > > I suspect now that I got a counterfeited card. Before I >> > > > > > dump it, >> > > > > > I would like to run a definitive non-destructive test, >> > > > > > preferably >> > > > > > on the Beaglebone Black, and I would like to ask you for >> > > > > > suggestions. >> > > > > > >> > > > > > Also, it would be nice to see some speed values as a >> > > > > > reference >> > > > > > for microSDHC card write speeds on: >> > > > > > >> > > > > > FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 >> > > > > > >> > > > > > Many thanks in advance for any help. >> > > > > Copy a huge file from /dev/zero. Smaller files in the >> > > > > filesystem >> > > > > generate a lot of overhead and 'wait points' that slow down >> > > > > overall >> > > > > performance. >> > > > > >> > > > > Or better yet, dd to the raw device. /dev/random should >> > > > > generate >> > > > > data >> > > > > faster than the card can handle. Depends on what you mean by >> > > > > 'non-destructive' >> > > > > >> > > > > And all NAND sucks. It's a pig with lipstick on it. So you >> > > > > won't >> > > > > get >> > > > > even performance if the FTL in the SD card sucks. Garbage >> > > > > collection, >> > > > > internal house keeping, etc all can steal performance from >> > > > > the user >> > > > > application. These cards are generally designed to take a >> > > > > burst of >> > > > > writes when the camera or video is taken, then have it read >> > > > > back >> > > > > later. A mixed workload was never optimized for on most of >> > > > > these >> > > > > cards, so it can also significantly degrade performance even >> > > > > at low >> > > > > percentage mixtures. >> > > > > >> > > > > So all those things could be going on w/o it being a >> > > > > counterfeit. >> > > > > :(. >> > > > > Of course, it could have all those things going on and also >> > > > > be a >> > > > > counterfeit. Hard to say for sure unless the performance is >> > > > > wildly >> > > > > different. But 4MB/s write performance is pretty pathetic for >> > > > > a >> > > > > card >> > > > > of that size, so it's on the low end, which suffers most from >> > > > > uneven >> > > > > performance and "down hill with the wind" spec numbers. >> > > > Warner, thank you very much for taking your time responding. >> > > > >> > > > It is a Class 4 card, i.e. guaranteed minimum write speed >> > > > should be 4 >> > > > MB/s, and I know the difference between advertised and >> > > > practical >> > > > speed, I would have expected at lest 50 % of the advertised >> > > > speed, >> > > > i.e. something in the range that can be achieved with the >> > > > internal >> > > > flash of the BBB. I would even be happy if it would come close >> > > > to 1 >> > > > MB/s. But 0.1 MB/s that is a quit huge difference -- 40 times >> > > > less >> > > > than the advertised speed. >> > > > >> > > > You said, that 4 MB/s is "pretty pathetic". Therefore let me >> > > > ask a >> > > > different question. What is the best write speed that can be >> > > > achieved >> > > > with what model of a microSD card on a Beaglebone Black running >> > > > FreeBSD 12-Current? >> > > > >> > > > Many thanks and best regards >> > > > >> > > > Rolf >> > > First we've got to keep in mind that BBB has a wimpy processor, >> > > and the >> > > sdhci driver for beaglebone uses PIO, not DMA. If we try a naive >> > > test >> > > of writing 100mb of random data to the sdcard... >> > > >> > > root@bb:~ # dd if=/dev/random of=/dev/mmcsd0s2 bs=1m count=100 >> > > 100+0 records in >> > > 100+0 records out >> > > 104857600 bytes transferred in 14.559020 secs (7202243 bytes/sec) >> > > >> > > It comes in at 7mb/sec, but were we really measuring card >> > > performance? >> > > >> > > root@bb:~ # dd if=/dev/random of=/dev/null bs=1m count=100 >> > > 100+0 records in >> > > 100+0 records out >> > > 104857600 bytes transferred in 6.888693 secs (15221698 bytes/sec) >> > > >> > > So ~15mb/sec just generating and writing random numbers to >> > > /dev/null, >> > > that's not very good, in theory an sdcard can write faster than >> > > that. >> > > >> > > So let's take the random generation cpu cycles out of the picture >> > > by >> > > caching some random data... >> > > >> > > root@bb:~ # dd if=/dev/random of=/tmp/rand bs=1m count=100 >> > > 100+0 records in >> > > 100+0 records out >> > > 104857600 bytes transferred in 8.566184 secs (12240876 bytes/sec) >> > > root@bb:~ # dd if=/tmp/rand of=/dev/null bs=1m >> > > 100+0 records in >> > > 100+0 records out >> > > 104857600 bytes transferred in 0.625300 secs (167691590 >> > > bytes/sec) >> > > >> > > That's more like it, now we're not measuring processor >> > > performance when >> > > we use dd. Now let's see what a raw write to that same sdcard >> > > does >> > > using the cached random data... >> > > >> > > root@bb:~ # dd if=/tmp/rand of=/dev/mmcsd0s2 bs=1m >> > > 100+0 records in >> > > 100+0 records out >> > > 104857600 bytes transferred in 7.777464 secs (13482236 bytes/sec) >> > > >> > > So that's about twice as fast as our first naive attempt to test >> > > writing 100mb of random data, and probably represents something >> > > pretty >> > > close to the actual BBB raw write speed under best-case >> > > conditions for >> > > an sdcard: large sequential writes. >> > > >> > > Now using that command to get actual numbers for some cards I >> > > have >> > > laying around: >> > > >> > > Apacer 8gb class 10: 14226229 bytes/sec (industrial temp >> > > range) >> > > Kingston 8gb class 4: 7008571 bytes/sec >> > > Kingston 8gb class 10: 9715391 bytes/sec >> > > Lexar 8gb class 6: 8821627 bytes/sec >> > > Sandisk 2gb class n/a: 6163704 bytes/sec (predates speed >> > > classes) >> > > Samsung 32gb class 6: 13482236 bytes/sec >> > > >> > > So the cards that perform best are the two I have which cost more >> > > than >> > > twice as much as any of the others. Not surprising, I suppose. >> > > >> > > Remember all of these 'dd' tests are for an sdcard's best-case >> > > condition. Real-world UFS accesses are anything but best- >> > > case. The >> > > thing an sdcard is worst at is small writes (anything from >> > > single- >> > > sector to 16k is very small compared to the typical 4mb erase- >> > > block >> > > size on a modern sdcard). Writing ufs metadata is lots and lots >> > > of >> > > small writes. You can reduce the writes quite a bit by using >> > > softupdates without journaling. >> > Ian, many thanks for your research. The maximum write speed that I >> > could achieve was 1 MByte/s with dd'ing cached random data, and the >> > test results varied quite a bit when repeating the same dd command, >> > the worst speed was 500 kByte/s. >> > >> > I will buy a new card, and hopefully I will come with that one more >> > close to the range of rates that you reported for your various >> > cards. >> I found another (old) microSD card SanDisk 16 GB Class 10. After >> partitioning but before formatting with newfs, I tested the >> sequential writing speed be dd'ing directly to the device. I set >> apart only 50 MB in my tmpfs, and therefore I ran the tests with 40 >> MB (everything is run on FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 >> mounted from the internal flash): >> >> # dd if=/dev/random of=/tmp/random.bin bs=1m count=40 >> # dd if=/tmp/random.bin of=/dev/mmcsd1s2 bs=1m count=40 >> >> The initial results were promising, namely rates in the range from 12 >> to 14 MB/s. >> >> After formatting using: ... >> >> # newfs -ntUE -L SYSTEM /dev/mmcsd1s2a >> # mount -o noatime /dev/ufs/SYSTEM /mnt >> >> ... the results were eventually disappointing: >> >> # dd if=/tmp/random.bin of=/mnt/random1.bin bs=1m count=40 >> 11565980 bytes/sec >> >> # dd if=/tmp/random.bin of=/mnt/random2.bin bs=1m count=40 >> 8267796 bytes/sec >> >> # dd if=/tmp/random.bin of=/mnt/random3.bin bs=1m count=40 >> 615993 bytes/sec >> >> >> In contrast to writing to the mounted root filesystem / on the >> internal flash: >> >> # dd if=/tmp/random.bin of=/random1.bin bs=1m count=40 >> 10798380 bytes/sec >> >> # dd if=/tmp/random.bin of=/random2.bin bs=1m count=40 >> 10510983 bytes/sec >> >> # dd if=/tmp/random.bin of=/random3.bin bs=1m count=40 >> 10740969 bytes/sec >> >> Might it be, that FreeBSD 12 treats the UFS on the internal flash >> somehow different compared to UFS on the microSD? Perhaps trim works >> on the internal flash but not on mounted SD cards? >> >> Anyway, I will buy a new card and we'll see whether this changes >> something. >> >> Best regards >> >> Rolf > > I had a quick try of the same thing with a samsung and a kingston card > and couldn't replicate your results. > > It might be interesting for you to try again but leave off the -t when > formatting the filesystem. The implementation of BIO_DELETE/trim for > sdcard is particularly bad in freebsd (I'm not even sure it's correct, > but if it's wrong it's in a harmless way, not a data-destroying way). > I've been meaning to investigate it further, just haven't found time > yet. I checked about a year or so ago. I'm pretty sure it's correct for SD cards. eMMC cards only use the older commands defined for them, and so may use a less efficient form of the command. There's a related 'predelete' command for when you know you are writing more than one block that can have a large positive effect on some SD cards, but it's a APP CMD, and the current setup of that makes it hard to use where we'd need to issue it.... Some tests I did resulted in inclusive results, so I never did it right... > I do know that different sdcards react to delete/trim operations in > different ways. Good fast cards seem to do the delete just by > manipulating metadata and the operation is almost instant. Other cards > do the lengthy flash-erase operations "while you wait" which usually > ruins performance rather than enhancing it. Yes. SD cards are even worse than SSDs when it comes to the effects of TRIM. Horrible performance across a broad range of technologies suggests some heuristic to disabling it if the performance sucks. Most people don't actually have work loads that require TRIM to get the full warrantee period out of their drives. Warner From owner-freebsd-arm@freebsd.org Tue Mar 21 16:25: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 4E952D1636E for ; Tue, 21 Mar 2017 16:25:17 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 E3F8C2E1 for ; Tue, 21 Mar 2017 16:25:16 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id u108so115267536wrb.3 for ; Tue, 21 Mar 2017 09:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0W+7RbBplCqBoFAT841WvL5HGA+qMitw09yHh1DJ140=; b=qRzT1Na6wRt4haPXb4Sn0oYP/x7m6KtSzSqLlcMvVsh2ObBlqI8yVJca8ot+24pH54 G/UHiRA8zho4kdl7xv6xFGH0rkW3m+FbNv1jZ5F/lXL2zA+iJeAVh+B+3kGpXs+jlFpx CgmLcBActvLlOR/VcTE6Ql+HcUvG9D978Zqx47w8N45Nnp4fuxoHfjSYOf2KGdARi7Bt heAFMFDmbN8hv+ozYarHtD9R5XsS1voZxyAT1/ZcWFDTGMnHlduVRAnaqVnf40E3WrJA SOyjeUevA7VrVtf3Eplf7BRiMh4kPW6eBSo6NDlb3jLU1RyrbmJJ2LaE6lzG8N6Rjcne lzTg== 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=0W+7RbBplCqBoFAT841WvL5HGA+qMitw09yHh1DJ140=; b=MEQag4kPgUt2dyd7xGDPw3k/H98FUzt9VG8pJv8lRIZB1nQNMQCXsKxghnZ44N7liC SbIJfKWG5iiBVq5t2iJ1epAVxdeb3m17Xqe1EgP4WHA8RD6F5svyoPw11KImqo4qb3Sl 25vp9npZaZCtfE+U0Q6FWo0TCAhIX6XwVUr/+9b1xSOYj6L6sqq6TRB0bFp74ONclUDC MpWQLzOOicky4qXEAo8RIqPouC0bttEjrUdLsAnT35V9M5S66JedTFC62jVVJ04hhUE2 ZQyMsu5C8c9R+INxXdTB+5VCcLo2Ms3mwy0YgsFy6gOKEBEJBb3moGUoDiWf8C0huXzK 3AaQ== X-Gm-Message-State: AFeK/H13j6iIToz6QkoAbbadRaTN5MB9IANOhjCCYzOu+cf2Q/NLH0tRvr95Je7cKLStqe5ZnNG5uKezT4YuGA== X-Received: by 10.223.160.17 with SMTP id k17mr27535973wrk.106.1490113514090; Tue, 21 Mar 2017 09:25:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.146.132 with HTTP; Tue, 21 Mar 2017 09:25:13 -0700 (PDT) In-Reply-To: <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> From: Luiz Otavio O Souza Date: Tue, 21 Mar 2017 13:25:13 -0300 Message-ID: Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black To: "Dr. Rolf Jansen" 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: Tue, 21 Mar 2017 16:25:17 -0000 On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: > Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen: >> Am 18.03.2017 um 16:07 schrieb Ian Lepore: >>> On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >>>> Am 18.03.2017 um 12:30 schrieb Warner Losh: >>>>> >>>>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen >>>>> wrote: >>>>>> >>>>>> I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write >>>>>> speed for use with my Beaglebone Black. >>>>>> >>>>>> The internal flash offers practical write speeds in the range of >>>>>> 2 to 3 MB/s when copying data to it from a NFSv4 volume depending >>>>>> on the size of the files being copied. Executing the same copy >>>>>> operation with said microSDHC card as the target I see only 0.1 >>>>>> to 0.2 MB/s (less than 1/10). >>>>>> >>>>>> I suspect now that I got a counterfeited card. Before I dump it, >>>>>> I would like to run a definitive non-destructive test, preferably >>>>>> on the Beaglebone Black, and I would like to ask you for >>>>>> suggestions. [picking a random message to reply] I just saw an email from SanDisk support (whatever this means) where they claim the only supported model for this kind of use is the high-endurance series: https://www.sandisk.com/home/memory-cards/microsd-cards/high-endurance-microsd This same email says that running any kind of OS in any of the other card models automatically breaks the warranty. HTH, Luiz From owner-freebsd-arm@freebsd.org Wed Mar 22 02:21: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 DEC81D17CAC for ; Wed, 22 Mar 2017 02:21:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-173.reflexion.net [208.70.211.173]) (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 9E8C81C28 for ; Wed, 22 Mar 2017 02:21:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5711 invoked from network); 22 Mar 2017 02:21:11 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2017 02:21:11 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 21 Mar 2017 22:21:11 -0400 (EDT) Received: (qmail 8016 invoked from network); 22 Mar 2017 02:21:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Mar 2017 02:21:11 -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 F217DEC8974; Tue, 21 Mar 2017 19:21:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: Date: Tue, 21 Mar 2017 19:21:08 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <1C595969-C6E0-44A2-9086-E48C237263BC@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> To: Andrew Turner 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, 22 Mar 2017 02:21:19 -0000 On 2017-Mar-18, at 9:10 PM, Mark Millard wrote: > > On 2017-Mar-18, at 5:53 PM, Mark Millard wrote: > >> A new, significant discovery follows. . . >> >> While checking out use of procstat -v I ran >> into the following common property for the 3 >> programs that I looked at: >> >> A) My small test program that fails for >> a dynamically allocated space. >> >> B) sh reporting Failed assertion: "tsd_booted". >> >> C) su reporting Failed assertion: "tsd_booted". >> >> Here are example addresses from the area of >> incorrectly zeroed memory (A then B then C): >> >> (lldb) print dyn_region >> (region *volatile) $0 = 0x0000000040616000 >> >> (lldb) print &__je_tsd_booted >> (bool *) $0 = 0x0000000040618520 >> >> (lldb) print &__je_tsd_booted >> (bool *) $0 = 0x0000000040618520 > > That last above was a copy/paste error. Correction: > > (lldb) print &__je_tsd_booted > (bool *) $0 = 0x000000004061d520 > >> The first is from dynamic allocation ending up >> in the area. The other two are from libc.so.7 >> globals/statics ending up in the general area. >> >> It looks like something is trashing a specific >> memory area for some reason, rather independently >> of what the program specifics are. I probably should have noted that the processes involved were: child/parent then grandparent and then great grandparent. The grandparent was sh and the great grandparent was su. The ancestors in the process tree are being damaged, not just the instances of the program that demonstrates the problem. >> Other notes: >> >> At least for my small program showing failure: >> >> Being explicit about the combined conditions for failure >> for my test program. . . >> >> Both tcache enabled and allocations fitting in SMALL_MAXCLASS >> are required in order to make the program fail. >> >> Note: >> >> lldb) print __je_tcache_maxclass >> (size_t) $0 = 32768 >> >> which is larger than SMALL_MAXCLASS. I've not observed >> failures for sizes above SMALL_MAXCLASS but not exceeding >> __je_tcache_maxclass. >> >> Thus tcache use by itself does not seen sufficient for >> my program to get corruption of its dynamically allocated >> memory: the small allocation size also matters. >> >> >> Be warned that I can not eliminate the possibility that >> the trashing changed what region of memory it trashed >> for larger allocations or when tcache is disabled. > > The pine64+ 2GB eventually got into a state where: > > /etc/malloc.conf -> tcache:false > > made no difference and the failure kept occurring > with that symbolic link in place. > > But after a reboot of the pin46+ 2GB > /etc/malloc.conf -> tcache:false was again effective > for my test program. (It was still present from > before the reboot.) > > I checked the .core files and the allocated address > assigned to dyn_region was the same in the tries > before and after the reboot. (I had put in an > additional raise(SIGABRT) so I'd always have > a core file to look at.) > > Apparently /etc/malloc.conf -> tcache:false was > being ignored before the reboot for some reason? I have also discovered that if the child process in an example like my program does a: (void) posix_madvise(dyn_region, region_size, POSIX_MADV_WILLNEED); after the fork but before the sleep/swap-out/wait then the problem does not happen. This is without any read or write access to the memory between the fork and sleep/swap-out/wait. By contrast such POSIX_MADV_WILLNEED use in the parent process does not change the failure behavior. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Mar 22 07:14: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 B243BD17156 for ; Wed, 22 Mar 2017 07:14:31 +0000 (UTC) (envelope-from b.16012506@edmmessage.com) Received: from mail28.wt1.edmmessage.com (mail28.wt1.edmmessage.com [101.78.203.28]) (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 F243810F for ; Wed, 22 Mar 2017 07:14:30 +0000 (UTC) (envelope-from b.16012506@edmmessage.com) Received: from 101.78.203.28 (mail28.wt1.edmmessage.com [101.78.203.28]) by mail28.wt1.edmmessage.com (Postfix) with ESMTP id 4C2FA211E58 for ; Wed, 22 Mar 2017 15:14:29 +0800 (HKT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; t=1490166869; s=default; d=edmmessage.com; h=Date:From:Reply-To:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=DOzGmctIqqHjELK+8w5t/LWOyKB8iiu2CMH05RXaGQE=; b=AXKRELrqkaYiMg5VdCs8R031MB2qP+8kL+SR0uNFiGfV0kjBuOayLriIXGh7hK2U mlKIxTS85icTnJ0Y6j54N3u3LCG/WpB4dPibLQUe81aDeeFzccdC2PP3hxWi1hUnFQb 7Z0M1rimpOo/Fpv8aKu60vRJEy1jeEF78XVSKh7s= Date: Wed, 22 Mar 2017 15:14:29 +0800 (HKT) From: "jhie.powermax" Reply-To: "jhie.powermax" To: JHIE-07-YMLP Message-ID: <1607340850.5917157.1490166869311.JavaMail.tomcat@wt2> Subject: Inventory Control and Management - April 20 Errors-To: b.16012506@edmmessage.com X-Content-ID: z35yBc1Y0Ew0ggLWz3CdoBSAw475zTPRcZAM17sTFQruDDlFOpcpETBcRS5SO+rC67hV7N25Yg+4App2OWCaYx0YL2pBNWdiI4cGq1ek3tQ866/fdikIBzzJ+TNbz7M0 Feedback-ID: 818157166346254:007248465502929:008494288642614:edmmessage.com MIME-Version: 1.0 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, 22 Mar 2017 07:14:31 -0000 From owner-freebsd-arm@freebsd.org Wed Mar 22 16:25: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 1391AD175BA for ; Wed, 22 Mar 2017 16:25:44 +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 C597A1423 for ; Wed, 22 Mar 2017 16:25:43 +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 5FC6720B467 for ; Wed, 22 Mar 2017 11:19:45 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Pi-series sound output options Message-ID: <025036c0-a5a7-33f2-58a7-55f31fbc6e41@denninger.net> Date: Wed, 22 Mar 2017 11:19:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050108080303080407050102" 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, 22 Mar 2017 16:25:44 -0000 This is a cryptographically signed message in MIME format. --------------ms050108080303080407050102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ugh. This morning I had a repeat of a problem I've run into before and it hosed me good -- a production Pi2 unit failed to restart after a power failure. It hung after the "UE0" ident line. This is related to the fact that I have to run updated bootcode (bootcode.bin and related files) on that device because the stock bootcode that FreeBSD-11 uses along with u-boot is severely-unstable for sound output. Specifically, after some period of time it will simply stop talking on the sound port and nothing fixes it other than a reset. With the updated bootcode and setting pwm_mode=3D2 sound is stable - IF i= t boots. The problem is that it doesn't /always /boot; the failures are lockups during some part of the device probe process, and are fatal. If you power cycle a few times it will eventually come up and once it does it's fine. Attempting to use even /later /versions of the bootcode and related files (like, for instance, the current stuff now out there) results in mmc not being seen and thus you can't mount root, so trying to roll forward isn't an option either as those are completely non-functional.=20 There appears to be a clash between the DTB file and the updated firmware in some fashion. Pulling over the newer DTB from the Linux side of the world associated with the newer bootcode results in a non-booting FreeBSD kernel. I'd go to the Pi3 (despite no integrated WiFi) in places where I need this capability except that on the Pi3 we have no sound *at all* at present in the code because the vchiq driver doesn't exist and won't compile "as-exists" today. This application NEEDS sound output capability. I don't care if it's on a plug-in via USB but it has to work in a "FreeBSD-like" manner (e.g. open up a PCM channel, etc.) Are there any options with this platform available at present or am I stuck with porting this app to Linux (yuck; among other things the "NanoBSD" option on FreeBSD is nice for reliability reasons!) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050108080303080407050102 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjIxNjE5MzVaME8GCSqGSIb3DQEJBDFCBEDnun9A 1kZO/8CaFRcbNQfG2Vp5fGfvpkC4ARrGwqI5ajHfYk7buQ6/WUtUU9croKzM86S8wkxWtmlQ nUXpvxJQMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIABtuxIgbTQ/ij smzTn+KPJ9h0RBKvB/1eCUsaJc5+dmqwLzL4iZGzvLWZG8tylETm9KxGeAw+JwyJpwVSdKIu V3fN8K4SO/Pr3NYbuCf69Pm4u/tAsi0dv74tK4HaKUWtU28xSNe4kBRaW3BahXr9A2T8TuB/ eWGUvSPYP4sxsM1tW+CdPy8ld8qrRm8HMH4+28xiZh+8ZbtTzIUx5fU3DnSx0nmHEHVTb4v/ 9K0RhxxVVgH+GD9A2gDNNIf1NChjjyinodUHRAvF7U1ZrOPEjN4o0ji1CpAaO3Kuhdj364VE hLyIFcyteMEfZ9Mt3CP7DRletUebkJpgVMfFhIn3vQXg6nXpt5S6e2R9JkUxWrD+5Pmb0Ixg aus/5sLe3BNnnKGF1WEQYDK6LZ6pqfyhC/tQGuWFpUMdBIbRb7vdvR9sJ2DcnmI8rwmBMPtm SkXuEtWzrZxkjxnNfz2M7HAvpnX+Fq9YalgV2R5t6eQVnvP3xevXvjH1eK8pie3P/xCmT/M/ W1i9En9SucHS9/MJfZf5jRq/UkheA2q3gTw7QNW94oZtD0HcHX/8zuZpdFGOVVVT66D6+Vhz Vw82de+wUyoWTI6SA4qQrJqgQcetx5i9jU7PgoRF2QZIAOMLFYlEeeKzC25+drzSvImTxpG+ PTai9v4T8Hrr8Nq97EriRNEAAAAAAAA= --------------ms050108080303080407050102-- From owner-freebsd-arm@freebsd.org Wed Mar 22 16:36: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 E3C3DD1784C for ; Wed, 22 Mar 2017 16:36:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 AE1B418F8 for ; Wed, 22 Mar 2017 16:36:35 +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 58D541FE087; Wed, 22 Mar 2017 17:35:28 +0100 (CET) Subject: Re: Pi-series sound output options To: Karl Denninger , "freebsd-arm@freebsd.org" References: <025036c0-a5a7-33f2-58a7-55f31fbc6e41@denninger.net> From: Hans Petter Selasky Message-ID: Date: Wed, 22 Mar 2017 17:35:33 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <025036c0-a5a7-33f2-58a7-55f31fbc6e41@denninger.net> 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: Wed, 22 Mar 2017 16:36:36 -0000 On 03/22/17 17:19, Karl Denninger wrote: > This application NEEDS sound output capability. I don't care if it's on > a plug-in via USB but it has to work in a "FreeBSD-like" manner (e.g. > open up a PCM channel, etc.) Hi, Do you need both playback and recording? How many channels, bitrate etc? USB audio 2x16-bit 48k over FULL or preferably HIGH-speed should work reliably. Your hang issue sounds like a GPIO / unhandled IRQ issue. --HPS From owner-freebsd-arm@freebsd.org Wed Mar 22 22:09: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 E255FD188EE for ; Wed, 22 Mar 2017 22:09:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-173.reflexion.net [208.70.211.173]) (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 A3412BF5 for ; Wed, 22 Mar 2017 22:09:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23139 invoked from network); 22 Mar 2017 22:10:19 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2017 22:10:19 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Wed, 22 Mar 2017 18:09:26 -0400 (EDT) Received: (qmail 2376 invoked from network); 22 Mar 2017 22:09:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Mar 2017 22:09:26 -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 55D83EC8974; Wed, 22 Mar 2017 15:09:25 -0700 (PDT) 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: fork-then-swap-out [zero RES(ident memory)] questions tied to arm64 failures (zeroed memory pages) Message-Id: <59C6BC12-1BC2-41D5-8B47-D0AD44D2CDF0@dsl-only.net> Date: Wed, 22 Mar 2017 15:09:23 -0700 Cc: freebsd-arm To: freebsd-hackers@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: Wed, 22 Mar 2017 22:09:29 -0000 The later questions are associated with: Bugzilla 217239 and 217138 (which I now expect have a common cause) https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015867.html (and its thread) These are tied to some process memory pages being trashed (to be zero) in particular types of arm64 contexts. This is reproducible in multiple arm64 contexts. The context is head but I believe there are reports in the lists tied to 11 as well. [Unfortunately the above all very much shows a learn-as-I-go property. Also the list has a sub-exchange on my testing other devices to check for device failures that is not directly relevant here.] These are tied to problems with fork-then-swap-out-then-swap-in contexts on arm64. (Even though I've occasionally typed amd64 accidentally in places in those materials.) Memory allocations from before the fork are involved, ones not yet accessed by the child side of the fork at the time of the fork. fork sets up copy-on-write so that the child process temporarily shares pages (those it does not write), or should. But what if the parent process or both parent and child are swapped-out just shortly after the fork (so, say, top -PCwaopid shows zero for RES(ident memory)? What is the handling of, say, the child swapping back in while the parent still is swapped out? I notice that the child can have a much smaller SWAP figure than the parent so it would appear that the parent swap-out has pages that the child does not. So what if the child needs some of those pages? What should happen? (Vs. what does happen on arm64 in specific types of contexts? More below.) I ask mostly to see if I can do more to give evidence of what is going on and what to test for any proposed fix. I'm not likely to find the underlying problem(s) for arm64 directly, unlike my investigation that lead to fork-trampoline being fixed in head's -r313772 (2017-Feb-15). [ https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015656.html and its thread, including when its title changed in: https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015678.html .] Part of that unlikely-to-solve status is because the context seems to be bound to a lot of special conditions and interesting behaviors simultaneously: A) Both my original reproductions of problem reports on the lists and the only (simple) programs for reproducing the probablems involve fork-then-swap-out [zero RES(ident memory)]. Neither fork by itself nor swap-out/in by itself have been sufficient. B) jemalloc's tcache being in use (__je_tcache_maxclass == 32*1024) is part of every example of reproduction of the problem. C) allocations <= SMALL_MAXCLASS (SMALL_MAXCLASS==14*1024) get the failure (but bigger ones work, both fitting inside __je_tcache_maxclass and not). Again: every example reproduction of the problem has this status. D) FreeBSD sometimes gets into a state where /etc/malloc.conf doing tcache:false does not seem to disable tcache. (Rebooting goes back to tcache:false working after such has been observed.) [Related or independent? I've no clue.] Usually tcache:false seems to work and so avoid the failures. E) Use of POSIX_MADV_WILLNEED on the problematical allocation(s) in the child process after the fork but before the swap-outs of the child and parent prevents the failures (no read or write access to the memory from the child until after the swap-in). Doing so just in the parent process does not prevent the failures. F) Similar to (E) but read-accessing a byte or more of one or more pages from the problematical allocations from the child process after the fork but before the swap-out makes those specific pages not fail. (The others still fail, if any.) Done from the parent process instead does not avoid the failures. G) In a sequence like: su creates a sh which then runs one of my test programs that then forks off a child it can be that all of the 4 processes show the zeroed memory area like the child process does. su and sh need to have swapped-out and back in for them to get failures. su and sh die once they hit an assert that fails due to the zeroed memory page(s). The asserts involve addresses also messed up in the test program processes (parent and child). In my reading I've not been able to determine what to expect for fork-then-swap-out-and-back-in for pages that the child process had not accessed yet but which might not be around for later activity because of the parent process's own swapped-out status at the time. Note: While I usually run a non-debug kernel I've tried a debug kernel and it provided no notices of problems. I got no additional information from the attempt. [My usual KERNCONF file includes GENERIC and then disables various debug items.] The bugzilla reports have example code for showing the problems and various behaviors. The two in 217239 are probably of more interest than the first one on 217138. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Mar 23 03:42: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 75FC2D1985E for ; Thu, 23 Mar 2017 03:42:53 +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::7]) (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 10015181E for ; Thu, 23 Mar 2017 03:42:52 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490240568; l=1750; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=BrlmRchvjpARR9CrOA9+ms9yK3Eb9dhBl13TF0pAZQA=; b=ksA4wo032CHbXen6Py+1i3UoaENP8jr8R3m1Lrt+tzVXUeZx4kJfhJ/v14Tflo13UG F/1E4JTKV2W+1o4XJx/ab0jaVHzcsTEsMjI23dpEiGWW+N9bZFoVt1Nwhe6kYKl5Bnpx 7jUczSbfGOXgZW4rCqfFcjnvUUxoFe2StO9NU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id c029b5t2N3glI6k (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) for ; Thu, 23 Mar 2017 04:42:47 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 15DB57506DAD for ; Thu, 23 Mar 2017 00:42:45 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: Dr. Rolf Jansen In-Reply-To: Date: Thu, 23 Mar 2017 00:42:44 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) 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, 23 Mar 2017 03:42:53 -0000 Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza : > On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: >> Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen: >>> Am 18.03.2017 um 16:07 schrieb Ian Lepore: >>>> On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >>>>> Am 18.03.2017 um 12:30 schrieb Warner Losh: >>>>>>=20 >>>>>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen >>>>>> wrote: >>>>>>>=20 >>>>>>> I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write >>>>>>> speed for use with my Beaglebone Black. >>>>>>>=20 >>>>>>> The internal flash offers practical write speeds in the range of >>>>>>> 2 to 3 MB/s when copying data to it from a NFSv4 volume = depending >>>>>>> on the size of the files being copied. Executing the same copy >>>>>>> operation with said microSDHC card as the target I see only 0.1 >>>>>>> to 0.2 MB/s (less than 1/10). >>>>>>>=20 >>>>>>> I suspect now that I got a counterfeited card. Before I dump it, >>>>>>> I would like to run a definitive non-destructive test, = preferably >>>>>>> on the Beaglebone Black, and I would like to ask you for >>>>>>> suggestions. >=20 > [picking a random message to reply] >=20 > I just saw an email from SanDisk support (whatever this means) where > they claim the only supported model for this kind of use is the > high-endurance series: > = https://www.sandisk.com/home/memory-cards/microsd-cards/high-endurance-mic= rosd >=20 > This same email says that running any kind of OS in any of the other > card models automatically breaks the warranty. Luiz, thank you very much for the note. Do you know, whether this high = endurance XC card is compatible with the Beaglebone Black? Best regards Rolf= From owner-freebsd-arm@freebsd.org Thu Mar 23 15:07: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 3EEC3D19022 for ; Thu, 23 Mar 2017 15:07:42 +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 219B41DBD for ; Thu, 23 Mar 2017 15:07:41 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 730135a2-0fda-11e7-bfb5-0d159cd3c324 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 730135a2-0fda-11e7-bfb5-0d159cd3c324; Thu, 23 Mar 2017 15:07:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2NF7WVG003985; Thu, 23 Mar 2017 09:07:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1490281652.58015.71.camel@freebsd.org> Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Thu, 23 Mar 2017 09:07:32 -0600 In-Reply-To: <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.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: Thu, 23 Mar 2017 15:07:42 -0000 On Thu, 2017-03-23 at 00:42 -0300, Dr. Rolf Jansen wrote: > Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza m>: > > > > On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: > > > > > > Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen: > > > > > > > > Am 18.03.2017 um 16:07 schrieb Ian Lepore: > > > > > > > > > > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: > > > > > > > > > > > > Am 18.03.2017 um 12:30 schrieb Warner Losh: > > > > > > > > > > > > > > > > > > > > > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s > > > > > > > > write > > > > > > > > speed for use with my Beaglebone Black. > > > > > > > > > > > > > > > > The internal flash offers practical write speeds in the > > > > > > > > range of > > > > > > > > 2 to 3 MB/s when copying data to it from a NFSv4 volume > > > > > > > > depending > > > > > > > > on the size of the files being copied. Executing the > > > > > > > > same copy > > > > > > > > operation with said microSDHC card as the target I see > > > > > > > > only 0.1 > > > > > > > > to 0.2 MB/s (less than 1/10). > > > > > > > > > > > > > > > > I suspect now that I got a counterfeited card. Before I > > > > > > > > dump it, > > > > > > > > I would like to run a definitive non-destructive test, > > > > > > > > preferably > > > > > > > > on the Beaglebone Black, and I would like to ask you > > > > > > > > for > > > > > > > > suggestions. > > [picking a random message to reply] > > > > I just saw an email from SanDisk support (whatever this means) > > where > > they claim the only supported model for this kind of use is the > > high-endurance series: > > https://www.sandisk.com/home/memory-cards/microsd-cards/high-endura > > nce-microsd > > > > This same email says that running any kind of OS in any of the > > other > > card models automatically breaks the warranty. > Luiz, thank you very much for the note. Do you know, whether this > high endurance XC card is compatible with the Beaglebone Black? > > Best regards > > Rolf I would assume that it is, they're typically just standard sd cards with flash arrays based on SLC technology and with a lot of extra space for reassigning bad blocks (a card that claims 8gb capacity could actually have 4x that many blocks or more available internally). But be aware that high-endurance or industrial-rated cards can be very expensive.  I think at work we pay around $40 each for industrial-rated 8gb cards.  (One of them was included in those test results I posted, and the performance was among the best, at least you get something for all that extra money.) -- Ian From owner-freebsd-arm@freebsd.org Thu Mar 23 17:04: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 0C858D1AF1A for ; Thu, 23 Mar 2017 17:04:23 +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 D4CB71F42 for ; Thu, 23 Mar 2017 17:04:22 +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 CFF42216819 for ; Thu, 23 Mar 2017 12:04:14 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: i2c on Pi3? Message-ID: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> Date: Thu, 23 Mar 2017 12:03:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040007080905070507090101" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:04:23 -0000 This is a cryptographically signed message in MIME format. --------------ms040007080905070507090101 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The Wiki shows it identifying, but I can't find a reference to a driver in the arm64 declarations, and a -CURRENT build just now doesn't find it.= Simple omission in the kernel config or something more? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040007080905070507090101 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjMxNzA0MDFaME8GCSqGSIb3DQEJBDFCBECq3mo7 uhK+/DTN3dyYsLkHCIYuSiKAYjVIgq0lV04RBZCOzDhrvvvHuwQwkH9jn7DplpHMN5Hb/E3v bVzutvdCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAuu3VHxFJRZ9Z IihjVefH9YyC/7BskSsGaGDbPMFvxBfgFRAyrdyk6/qT4jXER/hgiRjCcxmwiiY9dFE2bAEn wNRUlhRG45c47Ybja5pzJHnqBqJ3gsFqGA8kpS5/1PNwoRpmmp2ljOrlbfKuaBYmy9l91h4B xbb6idDA6hA67+2xY6/BqGVpCDAAwvVB5YcawVat0s7Sm3xWSFbyyg2xyEN4NMxuuew8QgHE hIZh21e9fdLzlhTDml4Ds0wFoyAFZc2HDVBcYQuxumYsLyFr+fszR02kysu3dFC2SxtFRvsR KKbxqvxs8cGgHO5BLGhNelAyqwWVzqwSJWomiGxcITai6KIyE6RO1Pht4qDJph1cs+q57Z2E mH+f2s2O68Hb3NhH/AZ7YTBXjTb2U+Ci7wHGyJrRjezc27GFH5A/Cxhq0mywF/7+PjKX5lkZ OBP3e3YGNVpXtDw3mbkL5p2xYO9KTxkthOVVDWaB5KNYofCSlHN5I4yzQaLgOEkW/VGbeJ5V u9isFtzE1Jy6lnzWdDpIvOduHatAR2U0vcQHpewTMdUTNEi0swV/T3RLNTthpEeK6XOgrq2M qsrtqeMHAlQKORz7QItoIIN0265FREJrayDE3tR3YaWVaLc7Xlzl1ckvWHhR9FMQWIPcwOmt BH9BDHnoxVAG87SOvj9JnYsAAAAAAAA= --------------ms040007080905070507090101-- From owner-freebsd-arm@freebsd.org Thu Mar 23 17:35: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 EC9A4D1A949 for ; Thu, 23 Mar 2017 17:35:11 +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 C0A8D1294 for ; Thu, 23 Mar 2017 17:35:11 +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 0E66321697D for ; Thu, 23 Mar 2017 12:35:10 -0500 (CDT) Subject: Re: i2c on Pi3? To: "freebsd-arm@freebsd.org" References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> From: Karl Denninger Message-ID: Date: Thu, 23 Mar 2017 12:34:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070807000106050900040207" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:35:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070807000106050900040207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/23/2017 12:34, John Howie wrote: > Hi Karl, > > I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. Fo= r an example how to use it from userland, check out a project I posted on= github eighteen months ago, that was for the PiFace RTC. > > https://github.com/jhowie/FreeBSDPiFaceRTC > > There are useful routines I created for working with devices on the I2C= bus, which you are free to use. They are not RPI2-specific, so they shou= ld work on other boards.=20 > > Regards, > > John > > > On 3/23/17, 10:03 AM, "Karl Denninger" wrote: > > The Wiki shows it identifying, but I can't find a reference to a dr= iver > in the arm64 declarations, and a -CURRENT build just now doesn't fi= nd it. > =20 > Simple omission in the kernel config or something more? > =20 > --=20 > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ > =20 > It works on the Pi2; I am using it in production. The driver appears to be /missing /in the Pi3 kernel. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070807000106050900040207 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjMxNzM0NTlaME8GCSqGSIb3DQEJBDFCBEA0BcGC KHFeTb9b2OIzdD0NQQJsqC6aHSwNa7AXQgT3FT9ABjphXkOWQX4hPqG/sLUB9I0H00vN6JNK eT4nEcX+MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAAOlxd23LQvya JU1tfNeQlZ3PZ4tMSOyfNIk9jHDFF8j/CPtqStVvGMeg5yIr9hAJcybcQY3viYXOkri2FUKl Yw5W6KGO9f8sZCXaZmcsZXhdvZrrHsL96v3hxLRZ292COOwTKnDEcVvCUSqAADyiuqyQ06Fb rB8ZVMUiE+SPby1w9kNG8raoqNfdhnstjx3OQVhn9r47f/2u5HXYw5fbamZN8f6W8veyhUTq rYFF29ggDx/irpGfaYF1rVfrUrnB3YhjjADk2yZtOSXSjaFMKAJ/NdL97T5+LRD0aNcJScvC cyulgWmZbhUSrFN21wusHP64viZAy5aYVapJxGSThqs6p6erL7Tpqi1iG7d/4SOcTzLGBzin uWYvIyLyZS9USObN+jzaie0xijaWvnTrXKSQwh4Xt4EVBhDTJX/yvyuNDHYQG++VdDa1DqWS SMMeRPbmZiTt3vyAvOmxiTP2BiKAkvRq9ywcVILTYrlDfmHJfOUDyyQGEhUgMOA2wwPWJzw1 qQDMgmHCTwbAgiNzEym+rZrVnihOnGwyxjdgXHFHNhEp51CtSPu+vQNllBFLHt5Vloj6JymY hHw8OHAfYNfVcOEDI2n1pxIeH7QGVU8LXH1pfYPyZBRuxYQpFJnQWpQ3Tx9ACpXeiO5NGX8D Z4K7Ixca6OrtLoNh7RHGdKQAAAAAAAA= --------------ms070807000106050900040207-- From owner-freebsd-arm@freebsd.org Thu Mar 23 17:35: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 A81E2D1A964 for ; Thu, 23 Mar 2017 17:35:20 +0000 (UTC) (envelope-from john@thehowies.com) Received: from remote.thehowies.com (remote.thehowies.com [50.197.91.218]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BA68131A for ; Thu, 23 Mar 2017 17:35:20 +0000 (UTC) (envelope-from john@thehowies.com) Received: from PRIMARY.thehowies.local ([fe80::6437:d031:7477:6451]) by PRIMARY.thehowies.local ([fe80::6437:d031:7477:6451%10]) with mapi id 14.03.0339.000; Thu, 23 Mar 2017 10:34:10 -0700 From: John Howie To: Karl Denninger , "freebsd-arm@freebsd.org" Subject: Re: i2c on Pi3? Thread-Topic: i2c on Pi3? Thread-Index: AQHSo/eI2P1/tBI6tU6+EbwLbpOyP6Gir66A Date: Thu, 23 Mar 2017 17:34:09 +0000 Message-ID: References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> In-Reply-To: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-originating-ip: [192.168.1.25] Content-Type: text/plain; charset="utf-8" Content-ID: <6B0F9284018C3A498485EFDF723B87E2@thehowies.local> Content-Transfer-Encoding: base64 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, 23 Mar 2017 17:35:20 -0000 SGkgS2FybCwNCg0KSSBjYW4gb25seSBzcGVhayB0byB0aGUgUmFzcGJlcnJ5IFBpIDIga2VybmVs LCBidXQgSTJDIGlzIHN1cHBvcnRlZC4gRm9yIGFuIGV4YW1wbGUgaG93IHRvIHVzZSBpdCBmcm9t IHVzZXJsYW5kLCBjaGVjayBvdXQgYSBwcm9qZWN0IEkgcG9zdGVkIG9uIGdpdGh1YiBlaWdodGVl biBtb250aHMgYWdvLCB0aGF0IHdhcyBmb3IgdGhlIFBpRmFjZSBSVEMuDQoNCmh0dHBzOi8vZ2l0 aHViLmNvbS9qaG93aWUvRnJlZUJTRFBpRmFjZVJUQw0KDQpUaGVyZSBhcmUgdXNlZnVsIHJvdXRp bmVzIEkgY3JlYXRlZCBmb3Igd29ya2luZyB3aXRoIGRldmljZXMgb24gdGhlIEkyQyBidXMsIHdo aWNoIHlvdSBhcmUgZnJlZSB0byB1c2UuIFRoZXkgYXJlIG5vdCBSUEkyLXNwZWNpZmljLCBzbyB0 aGV5IHNob3VsZCB3b3JrIG9uIG90aGVyIGJvYXJkcy4gDQoNClJlZ2FyZHMsDQoNCkpvaG4NCg0K DQpPbiAzLzIzLzE3LCAxMDowMyBBTSwgIkthcmwgRGVubmluZ2VyIiA8b3duZXItZnJlZWJzZC1h cm1AZnJlZWJzZC5vcmcgb24gYmVoYWxmIG9mIGthcmxAZGVubmluZ2VyLm5ldD4gd3JvdGU6DQoN CiAgICBUaGUgV2lraSBzaG93cyBpdCBpZGVudGlmeWluZywgYnV0IEkgY2FuJ3QgZmluZCBhIHJl ZmVyZW5jZSB0byBhIGRyaXZlcg0KICAgIGluIHRoZSBhcm02NCBkZWNsYXJhdGlvbnMsIGFuZCBh IC1DVVJSRU5UIGJ1aWxkIGp1c3Qgbm93IGRvZXNuJ3QgZmluZCBpdC4NCiAgICANCiAgICBTaW1w bGUgb21pc3Npb24gaW4gdGhlIGtlcm5lbCBjb25maWcgb3Igc29tZXRoaW5nIG1vcmU/DQogICAg DQogICAgLS0gDQogICAgS2FybCBEZW5uaW5nZXINCiAgICBrYXJsQGRlbm5pbmdlci5uZXQgPG1h aWx0bzprYXJsQGRlbm5pbmdlci5uZXQ+DQogICAgL1RoZSBNYXJrZXQgVGlja2VyLw0KICAgIC9b Uy9NSU1FIGVuY3J5cHRlZCBlbWFpbCBwcmVmZXJyZWRdLw0KICAgIA0KDQo= From owner-freebsd-arm@freebsd.org Thu Mar 23 17:53: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 43037D1AF9C for ; Thu, 23 Mar 2017 17:53:53 +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 1A8B11E51 for ; Thu, 23 Mar 2017 17:53:52 +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 1cr6vf-000EZK-D5; Thu, 23 Mar 2017 10:53:47 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v2NHrhkx056005; Thu, 23 Mar 2017 10:53:43 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Thu, 23 Mar 2017 10:53:42 -0700 From: Oleksandr Tymoshenko To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: i2c on Pi3? Message-ID: <20170323175342.GA55627@bluezbox.com> References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> 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: Karl Denninger (karl@denninger.net) wrote: > On 3/23/2017 12:34, John Howie wrote: > > > Hi Karl, > > > > I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. For an example how to use it from userland, check out a project I posted on github eighteen months ago, that was for the PiFace RTC. > > > > https://github.com/jhowie/FreeBSDPiFaceRTC > > > > There are useful routines I created for working with devices on the I2C bus, which you are free to use. They are not RPI2-specific, so they should work on other boards. .. skipped .. > It works on the Pi2; I am using it in production. > > The driver appears to be /missing /in the Pi3 kernel. [...] 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: github.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: Thu, 23 Mar 2017 17:53:53 -0000 Karl Denninger (karl@denninger.net) wrote: > On 3/23/2017 12:34, John Howie wrote: > > > Hi Karl, > > > > I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. For an example how to use it from userland, check out a project I posted on github eighteen months ago, that was for the PiFace RTC. > > > > https://github.com/jhowie/FreeBSDPiFaceRTC > > > > There are useful routines I created for working with devices on the I2C bus, which you are free to use. They are not RPI2-specific, so they should work on other boards. .. skipped .. > It works on the Pi2; I am using it in production. > > The driver appears to be /missing /in the Pi3 kernel. Probably it's not enabled in DTB. Try adding this line to config.txt: dtparam=i2c_arm=on,spi=on -- gonzo From owner-freebsd-arm@freebsd.org Thu Mar 23 18:01: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 A54B3D1A105 for ; Thu, 23 Mar 2017 18:01:32 +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 7A0A311AA for ; Thu, 23 Mar 2017 18:01:32 +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 A3850216AC3 for ; Thu, 23 Mar 2017 13:01:31 -0500 (CDT) Subject: Re: i2c on Pi3? References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> <20170323175342.GA55627@bluezbox.com> Cc: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <843bbe39-0b74-0d27-598d-ae16aea52a37@denninger.net> Date: Thu, 23 Mar 2017 13:01:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170323175342.GA55627@bluezbox.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060502090704070904060803" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:01:32 -0000 This is a cryptographically signed message in MIME format. --------------ms060502090704070904060803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: > Karl Denninger (karl@denninger.net) wrote: >> On 3/23/2017 12:34, John Howie wrote: >> >>> Hi Karl, >>> >>> I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. = For an example how to use it from userland, check out a project I posted = on github eighteen months ago, that was for the PiFace RTC. >>> >>> https://github.com/jhowie/FreeBSDPiFaceRTC >>> >>> There are useful routines I created for working with devices on the I= 2C bus, which you are free to use. They are not RPI2-specific, so they sh= ould work on other boards.=20 > .. skipped .. >> It works on the Pi2; I am using it in production. >> >> The driver appears to be /missing /in the Pi3 kernel. > Probably it's not enabled in DTB. Try adding this line to config.txt: > > dtparam=3Di2c_arm=3Don,spi=3Don > Nope, already in the base config.txt file: arm_control=3D0x200 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Dpi3-disable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060502090704070904060803 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjMxODAxMThaME8GCSqGSIb3DQEJBDFCBEDKKcxI YW8SaG5apGdKlw3XIuMHh6wV66JLrBttltIT6d0MIsnThixAnj56xKt+JiBltSaqzNW56J5U NuPkjlR6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAvw615dO/egn8 Qr4gTSlP+uq1jgKW9XLZBIlmCkM4xz5wBi05JDJ9tvUU0zoksFIYjm14e9JNz9wUKBgZZ71D 58Kv34RyBq7c0iIxGiN67RLA7OoRSsmQSX1n92GSKRz9yolTu5SRZXNTn1uqHcY247eFKOoJ PU7j6Hsi1ZzNUpxMt2nfz1XDgNRLoA5IWnI3JhdePedVkV/Ry5gyt9OtOfa9xmgFSLexsjic sgTls1cjSNr2JFOAS4k0eIbro+B7+xBbIM7yJjk/C2ePWcxg3x78bbTjN25Gg7Mxv3nJIiSc w/xWAgVObecxGBupEF04u1V8gkX5nyE39EYhIsWy2owtbo/3ylKZSyMU7OAEncLPx0W6P+fr m30xoSn/G8l0/XAmE37I3om6pm5blIy1oWRJ43HcfkBLY8OxVrNb0yC6tXl42GwafZXlnNtx W1d7aPyGtZRnOlvtbeeQJyLMXh9IKaSGtjwPRyxoBTnMCjxRg9dVYODTN7I5ZVeYKWwieLHz Ky9CL3KPYADd3vGwt4kphCq/Vtzi/gJRJ45KUE5ZM1ZbbCDVFE8sgG1wfv2FrLHBbdFDhRND w8DPY1jkRMynn/aELd+mm3k7omLLXmd+VI6o/Xmmr8P8IdfQ0RLonJuUzACaY8slvKqrtI3V n+ywBY8r5Dvw4V8SEQlTA8gAAAAAAAA= --------------ms060502090704070904060803-- From owner-freebsd-arm@freebsd.org Thu Mar 23 20:37: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 6A1A3CA1CC7 for ; Thu, 23 Mar 2017 20:37:59 +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 391791E26 for ; Thu, 23 Mar 2017 20:37:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id f84so5158572ioj.0 for ; Thu, 23 Mar 2017 13:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IqoxKjp/kNmlQSHJcgQ0JzQ1a5ZNcYrtRsgBatCsYkg=; b=i6ZgB6M1GKWQWntY9+JQJqqwc56yoymmcjqxwsCfEUGKsvaCILCCRBjS7bmc9FWUx0 hw4ni8MXkTt2ciATYX2kvBR6Ur9eq+gT4iHUQmGjQxY+YCiP2x3F0k49sH9K+fhXzrte ysKGSy9PBOcr9VydzxUfVMxFQCfkYdV27uGv6gU6wzC828f685L5WNI6v9yInmJ5rmP5 U1XrjimKDYhB6UtMD260sw4BSpAW9bSbFWAGuUssgaFH1xaQYFwR8RGTkFMih0vJK/cc +ZEDShPN54DXUfWu2Rt2XTUzvojD0AWGimyNZneLTLS6e89Ju3TppPPAjNrBK7HXHoIO tOhw== 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=IqoxKjp/kNmlQSHJcgQ0JzQ1a5ZNcYrtRsgBatCsYkg=; b=BU00N1wY0hOTp6vySxWtXx6Wz1lv433LJnvn90USoFJchEM8qBbnyV71pNqznl/XmS d83wjmQNxoQbngJ+GkXSMQC2lRCYNHiLZyUlcAaRrK+G+soB7erE1bCfHxQckwfnhdYj k0Ha0Vk85Kfr/XFQiUeYnXs5YmoWbD92j1nEHvUb5N7kY9+8iNEtgb/N55wuC878XgK+ Mxt4qYDV5z72QeyJUGg69wm0cwArIcFNp6H/39kT5HPeJK8eqNpDGDvC5+Bz+X8mFoY8 R+o0zVkcbqruYtt3AEyUdzBPZGW/EZsBIb23Gie9hWvLmPffSftBlExlNLFjEiPUFsEp MCMA== X-Gm-Message-State: AFeK/H2lbsAVOu6YX7ErbEDz2klJQ2iMb11qkVh1F3mNFiSWRJcsJyZOgx9wEyVDyFIxCA/KFiza2e1WVSMYJA== X-Received: by 10.107.198.193 with SMTP id w184mr4814758iof.19.1490301478377; Thu, 23 Mar 2017 13:37:58 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Thu, 23 Mar 2017 13:37:57 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1490281652.58015.71.camel@freebsd.org> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> <1490281652.58015.71.camel@freebsd.org> From: Warner Losh Date: Thu, 23 Mar 2017 13:37:57 -0700 X-Google-Sender-Auth: nmS9MdsLt27J_EVKGAHGUXCRElI Message-ID: Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black To: Ian Lepore Cc: "Dr. Rolf Jansen" , "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: Thu, 23 Mar 2017 20:37:59 -0000 On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore wrote: > On Thu, 2017-03-23 at 00:42 -0300, Dr. Rolf Jansen wrote: >> Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza > m>: >> > >> > On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: >> > > >> > > Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen: >> > > > >> > > > Am 18.03.2017 um 16:07 schrieb Ian Lepore: >> > > > > >> > > > > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >> > > > > > >> > > > > > Am 18.03.2017 um 12:30 schrieb Warner Losh: >> > > > > > > >> > > > > > > >> > > > > > > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > >> > > > > > > > I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s >> > > > > > > > write >> > > > > > > > speed for use with my Beaglebone Black. >> > > > > > > > >> > > > > > > > The internal flash offers practical write speeds in the >> > > > > > > > range of >> > > > > > > > 2 to 3 MB/s when copying data to it from a NFSv4 volume >> > > > > > > > depending >> > > > > > > > on the size of the files being copied. Executing the >> > > > > > > > same copy >> > > > > > > > operation with said microSDHC card as the target I see >> > > > > > > > only 0.1 >> > > > > > > > to 0.2 MB/s (less than 1/10). >> > > > > > > > >> > > > > > > > I suspect now that I got a counterfeited card. Before I >> > > > > > > > dump it, >> > > > > > > > I would like to run a definitive non-destructive test, >> > > > > > > > preferably >> > > > > > > > on the Beaglebone Black, and I would like to ask you >> > > > > > > > for >> > > > > > > > suggestions. >> > [picking a random message to reply] >> > >> > I just saw an email from SanDisk support (whatever this means) >> > where >> > they claim the only supported model for this kind of use is the >> > high-endurance series: >> > https://www.sandisk.com/home/memory-cards/microsd-cards/high-endura >> > nce-microsd >> > >> > This same email says that running any kind of OS in any of the >> > other >> > card models automatically breaks the warranty. >> Luiz, thank you very much for the note. Do you know, whether this >> high endurance XC card is compatible with the Beaglebone Black? >> >> Best regards >> >> Rolf > > I would assume that it is, they're typically just standard sd cards > with flash arrays based on SLC technology and with a lot of extra space > for reassigning bad blocks (a card that claims 8gb capacity could > actually have 4x that many blocks or more available internally). I don't think there's 4x over-provisioning. Where do you get that figure? When I was at Fusion I/O, the designs there were all in the 9-24% range, and our "intel" on what others were doing showed a range of 5% to 40% depending on the market segment and type of NAND use. If they are really using SLC NAND for these cards, the sparing is likely less because TLC NAND has about a 200-300 endurance rating (program erase cycles per erase block). MLC is between 3000-5000. SLC is like 30,000-100,000. SLC has also 10-100x better error rates than MLC which has 10-100x better than TLC due to how the charge nodes are programmed and the tolerances associated with that programming. There was constant pressure to come up with designs that needed less sparing, so I doubt things have changed to require 4x over provisioning.... What might be going on when people say that has to due with a feature of modern NAND chips: they can be programmed as SLC, MLC or TLC often on a per-erase block basis. In that case, a SLC configuration with a 33% over provisioning would have a 4x maximum theoretical raw capacity over the selected size for the drive (so a 8GB drive would have 8GB * 1.33 (over provisioning: spares and OOB) * 3 (TLC multiplier) or 32GB of raw capacity). > But be aware that high-endurance or industrial-rated cards can be very > expensive. I think at work we pay around $40 each for industrial-rated > 8gb cards. (One of them was included in those test results I posted, > and the performance was among the best, at least you get something for > all that extra money.) Part of the issue is that NAND chips these days can be SLC, MLC or TLC depending on how you program them (often on an erase-block level).[*] This means that the 8GB SLC card could also be a 16GB MLC card or a 24GB TLC card (well, due to sparing it likely wouldn't scale linearly). So from that perspective, I can see where a 4x number might come up (high number of bits possible for the die vs capacity configured for SLC + spares). At 33% sparing, the differences between the SD presented capacity point of 8GB would have close to 32GB of potential raw capacity were it run in TLC mode.... In addition, high endurance cards are often selected from the wafers at manufacturing time because they have the lowest error rate and other metrics so the NAND makers know that they will survive (the NAND manufacturing process isn't too uniform across the wafer due to micro variations in the wafer and other effects at the nano-scale). Often times these are also pulled from processes that typically yield better results but are more expensive. So the relative rarity of the raw dies plus the increased production cost plus running them in a faster, more reliable mode all lead to the cards being more expensive.... So that's why it's so expensive, especially on the high end: you are paying extra for quality. Warner [*] At least before 3d NAND, which I've not see as detailed a technical spec for. They likely do it as well, but I haven't seen the detailed datasheets for those like I have for generations prior... From owner-freebsd-arm@freebsd.org Fri Mar 24 02:46: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 7213BCA2FF7 for ; Fri, 24 Mar 2017 02:46:09 +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::4]) (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 0CB3BBD2 for ; Fri, 24 Mar 2017 02:46:08 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490323565; l=5497; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=mZkOw0STql0gCbJ+OM3GTnIJeU6ej2S6+dySA3Ofb0I=; b=a5+OcPDiBcxwxhds0ywsdoeSp51CrxR5hqs9JeULQLfq80wQixcbL6mROwThx89X46 DtPWliGCDK14bPFSsbvLXjcCM/bCZYkB5t/264FsOHWQpeugsuB2+HOrpvOqdwBuRgvg wuJR0ND0JEesu0PiVERNg4rsnh+qniTbdmq6s= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id j04813t2O2k4zMS (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) for ; Fri, 24 Mar 2017 03:46:04 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 7B5FB7506DAD for ; Thu, 23 Mar 2017 23:46:01 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: "Dr. Rolf Jansen" In-Reply-To: Date: Thu, 23 Mar 2017 23:46:00 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7E957E90-5579-4A7F-83DC-1B5522833EC2@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> <1490281652.58015.71.camel@freebsd.org> To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.1878.6) 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, 24 Mar 2017 02:46:09 -0000 Am 23.03.2017 um 17:37 schrieb Warner Losh : > On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore wrote: >> On Thu, 2017-03-23 at 00:42 -0300, Dr. Rolf Jansen wrote: >>> Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza = : >>>> On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: >>>>>>>>>>=20 >>>>>>>>>> ... ask you for suggestions. >>>> [picking a random message to reply] >>>>=20 >>>> I just saw an email from SanDisk support (whatever this means) >>>> where >>>> they claim the only supported model for this kind of use is the >>>> high-endurance series: >>>> https://www.sandisk.com/home/memory-cards/microsd-cards/high-endura >>>> nce-microsd >>>>=20 >>>> This same email says that running any kind of OS in any of the >>>> other >>>> card models automatically breaks the warranty. >>> Luiz, thank you very much for the note. Do you know, whether this >>> high endurance XC card is compatible with the Beaglebone Black? >>=20 >> I would assume that it is, they're typically just standard sd cards >> with flash arrays based on SLC technology and with a lot of extra = space >> for reassigning bad blocks (a card that claims 8gb capacity could >> actually have 4x that many blocks or more available internally). >=20 > I don't think there's 4x over-provisioning. Where do you get that = figure? >=20 > When I was at Fusion I/O, the designs there were all in the 9-24% > range, and our "intel" on what others were doing showed a range of 5% > to 40% depending on the market segment and type of NAND use. If they > are really using SLC NAND for these cards, the sparing is likely less > because TLC NAND has about a 200-300 endurance rating (program erase > cycles per erase block). MLC is between 3000-5000. SLC is like > 30,000-100,000. SLC has also 10-100x better error rates than MLC which > has 10-100x better than TLC due to how the charge nodes are programmed > and the tolerances associated with that programming. There was > constant pressure to come up with designs that needed less sparing, so > I doubt things have changed to require 4x over provisioning.... What > might be going on when people say that has to due with a feature of > modern NAND chips: they can be programmed as SLC, MLC or TLC often on > a per-erase block basis. In that case, a SLC configuration with a 33% > over provisioning would have a 4x maximum theoretical raw capacity > over the selected size for the drive (so a 8GB drive would have 8GB * > 1.33 (over provisioning: spares and OOB) * 3 (TLC multiplier) or 32GB > of raw capacity). >=20 >> But be aware that high-endurance or industrial-rated cards can be = very >> expensive. I think at work we pay around $40 each for = industrial-rated >> 8gb cards. (One of them was included in those test results I posted, >> and the performance was among the best, at least you get something = for >> all that extra money.) >=20 > Part of the issue is that NAND chips these days can be SLC, MLC or TLC > depending on how you program them (often on an erase-block level).[*] > This means that the 8GB SLC card could also be a 16GB MLC card or a > 24GB TLC card (well, due to sparing it likely wouldn't scale > linearly). So from that perspective, I can see where a 4x number might > come up (high number of bits possible for the die vs capacity > configured for SLC + spares). At 33% sparing, the differences between > the SD presented capacity point of 8GB would have close to 32GB of > potential raw capacity were it run in TLC mode.... In addition, high > endurance cards are often selected from the wafers at manufacturing > time because they have the lowest error rate and other metrics so the > NAND makers know that they will survive (the NAND manufacturing > process isn't too uniform across the wafer due to micro variations in > the wafer and other effects at the nano-scale). Often times these are > also pulled from processes that typically yield better results but are > more expensive. So the relative rarity of the raw dies plus the > increased production cost plus running them in a faster, more reliable > mode all lead to the cards being more expensive.... >=20 > So that's why it's so expensive, especially on the high end: you are > paying extra for quality. Warner and Ian, thank you very much for sharing your much deeper = insights on the matter. I am setting up a prototype for a mostly autonomous measurement device = for an industrial application using the BBB as the controller. For this = reason I am interested in the ti_adc driver, and I was glad that I got = it working. Once the device has been setup, writes to the SD card will be limited to = logging measurement data and activity events besides the normal FreeBSD = logging. The 4 GB internal flash of the BBB would be more than = sufficient to hold everything, however, I was thinking that using an = external SD card in order not to damage the BBB because of flash wear, = would be a good idea. Well, for this kind of application $40 is still in the budget, however, = it comes already close to the cost of the BBB itself. Perhaps, I simply = forget the SD cards and provide to my future customers spare BBB's. Anyway, I guess I need to do some lifetime simulation of the external = flash compared to the internal one, so I could take a more educated = decision based on these results. =20 Best regards Rolf =20= From owner-freebsd-arm@freebsd.org Fri Mar 24 02:52:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CF2FD1728D for ; Fri, 24 Mar 2017 02:52:53 +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 E0626F34 for ; Fri, 24 Mar 2017 02:52:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id l7so9416641ioe.3 for ; Thu, 23 Mar 2017 19:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=0Rgx60YW+9PLBOipS+649yqquMqZ5ff8O7zvriZ+Ke0=; b=mfYmUnPjUgpomjI8iV3JZcd+zawKe+eKEvZO3uXm6YkBbfK1zLAQOniv26er+Yt7b2 nankzSXb1olZb7gn0fA5FKfRcEfUXSpcSbKgqfnYuAYoMpoSiIkLNpp1DQ7KJNwiZnqo D3Hq4hN0lQZOA6BU8KJwmJzbD+zsf94dRA8KE7o2FIG3yx7k8xq/MxUqGlTOruxtlWMl i1ib4h6C7K9DxKF7OrRvlxZlX4MarNptv5xwfPFaFbsn73pAlE9RDblzQOnZMkuUmqQX ZKq+kpyrvOmyPb9vn/Il0mkbAhFU2IlQTH6PwN8mRActK7+iu+pxib9Vk0GuJqPfPmTw NaBg== 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=0Rgx60YW+9PLBOipS+649yqquMqZ5ff8O7zvriZ+Ke0=; b=tCdqJqCgjC+8uqoMg0yiFik/7RhIruPLH87KTqc85voY45x2xcBtec3MdeOHEI7F1+ qfh7NoGos6qBP/POxMCs1EDG7kAs0VrOI3G3KXWZ+va+Qbfk0SiE3EyedWCj4eO9JoZ2 X+2f1x9JTN+C9KN8kvTwjCPTK2ucIYBuIgPsx86OAv2wCUiWDEimLYJ6+Z1rAEgg/A9+ sykCRU1lZcfSptJfAlTgFSxWJ/toZtaIMmlwaJLGM0b6XiQ5J+ElRIdQUwJMMaEA6rkl LcgmRIwEy7OwfUsN2UOaw4m/ScajxHiLSivB++I57MNvukk9mNlZxM23BrRr5htDxHFK TZqA== X-Gm-Message-State: AFeK/H0Aueo29rpSnBjrmRpd+2MNRdjIC1ijyerfLoV7/tGFF1B32r12cHXFiT9cUg+auMHzpr+L5aHYfyfXjA== X-Received: by 10.107.198.193 with SMTP id w184mr6337615iof.19.1490323971982; Thu, 23 Mar 2017 19:52:51 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Thu, 23 Mar 2017 19:52:51 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::375c] In-Reply-To: <7E957E90-5579-4A7F-83DC-1B5522833EC2@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> <1490281652.58015.71.camel@freebsd.org> <7E957E90-5579-4A7F-83DC-1B5522833EC2@obsigna.com> From: Warner Losh Date: Thu, 23 Mar 2017 20:52:51 -0600 X-Google-Sender-Auth: qkQ5QjXuYobD1HITnWBNMKx1tdk Message-ID: Subject: Re: Identifying counterfeit microSD cards on a 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: Fri, 24 Mar 2017 02:52:53 -0000 On Thu, Mar 23, 2017 at 8:46 PM, Dr. Rolf Jansen wrote: > Am 23.03.2017 um 17:37 schrieb Warner Losh : >> On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore wrote: >>> On Thu, 2017-03-23 at 00:42 -0300, Dr. Rolf Jansen wrote: >>>> Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza : >>>>> On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: >>>>>>>>>>> >>>>>>>>>>> ... ask you for suggestions. >>>>> [picking a random message to reply] >>>>> >>>>> I just saw an email from SanDisk support (whatever this means) >>>>> where >>>>> they claim the only supported model for this kind of use is the >>>>> high-endurance series: >>>>> https://www.sandisk.com/home/memory-cards/microsd-cards/high-endura >>>>> nce-microsd >>>>> >>>>> This same email says that running any kind of OS in any of the >>>>> other >>>>> card models automatically breaks the warranty. >>>> Luiz, thank you very much for the note. Do you know, whether this >>>> high endurance XC card is compatible with the Beaglebone Black? >>> >>> I would assume that it is, they're typically just standard sd cards >>> with flash arrays based on SLC technology and with a lot of extra space >>> for reassigning bad blocks (a card that claims 8gb capacity could >>> actually have 4x that many blocks or more available internally). >> >> I don't think there's 4x over-provisioning. Where do you get that figure= ? >> >> When I was at Fusion I/O, the designs there were all in the 9-24% >> range, and our "intel" on what others were doing showed a range of 5% >> to 40% depending on the market segment and type of NAND use. If they >> are really using SLC NAND for these cards, the sparing is likely less >> because TLC NAND has about a 200-300 endurance rating (program erase >> cycles per erase block). MLC is between 3000-5000. SLC is like >> 30,000-100,000. SLC has also 10-100x better error rates than MLC which >> has 10-100x better than TLC due to how the charge nodes are programmed >> and the tolerances associated with that programming. There was >> constant pressure to come up with designs that needed less sparing, so >> I doubt things have changed to require 4x over provisioning.... What >> might be going on when people say that has to due with a feature of >> modern NAND chips: they can be programmed as SLC, MLC or TLC often on >> a per-erase block basis. In that case, a SLC configuration with a 33% >> over provisioning would have a 4x maximum theoretical raw capacity >> over the selected size for the drive (so a 8GB drive would have 8GB * >> 1.33 (over provisioning: spares and OOB) * 3 (TLC multiplier) or 32GB >> of raw capacity). >> >>> But be aware that high-endurance or industrial-rated cards can be very >>> expensive. I think at work we pay around $40 each for industrial-rated >>> 8gb cards. (One of them was included in those test results I posted, >>> and the performance was among the best, at least you get something for >>> all that extra money.) >> >> Part of the issue is that NAND chips these days can be SLC, MLC or TLC >> depending on how you program them (often on an erase-block level).[*] >> This means that the 8GB SLC card could also be a 16GB MLC card or a >> 24GB TLC card (well, due to sparing it likely wouldn't scale >> linearly). So from that perspective, I can see where a 4x number might >> come up (high number of bits possible for the die vs capacity >> configured for SLC + spares). At 33% sparing, the differences between >> the SD presented capacity point of 8GB would have close to 32GB of >> potential raw capacity were it run in TLC mode.... In addition, high >> endurance cards are often selected from the wafers at manufacturing >> time because they have the lowest error rate and other metrics so the >> NAND makers know that they will survive (the NAND manufacturing >> process isn't too uniform across the wafer due to micro variations in >> the wafer and other effects at the nano-scale). Often times these are >> also pulled from processes that typically yield better results but are >> more expensive. So the relative rarity of the raw dies plus the >> increased production cost plus running them in a faster, more reliable >> mode all lead to the cards being more expensive.... >> >> So that's why it's so expensive, especially on the high end: you are >> paying extra for quality. > > Warner and Ian, thank you very much for sharing your much deeper insights= on the matter. > > I am setting up a prototype for a mostly autonomous measurement device fo= r an industrial application using the BBB as the controller. For this reaso= n I am interested in the ti_adc driver, and I was glad that I got it workin= g. > > Once the device has been setup, writes to the SD card will be limited to = logging measurement data and activity events besides the normal FreeBSD log= ging. The 4 GB internal flash of the BBB would be more than sufficient to h= old everything, however, I was thinking that using an external SD card in o= rder not to damage the BBB because of flash wear, would be a good idea. > > Well, for this kind of application $40 is still in the budget, however, i= t comes already close to the cost of the BBB itself. Perhaps, I simply forg= et the SD cards and provide to my future customers spare BBB's. > > Anyway, I guess I need to do some lifetime simulation of the external fla= sh compared to the internal one, so I could take a more educated decision b= ased on these results. Lifetime / endurance is normally normalized to 'Drive Writes Per Day'. You should check to see what the endurance of the eMMC in the unit is. You may have enough headroom to just log there. SSDs always specify this, but SD cards seem to rarely do. Warner From owner-freebsd-arm@freebsd.org Fri Mar 24 03:31: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 3F147D17F93 for ; Fri, 24 Mar 2017 03:31:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-173.reflexion.net [208.70.211.173]) (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 EB472873 for ; Fri, 24 Mar 2017 03:31:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25008 invoked from network); 24 Mar 2017 03:31:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Mar 2017 03:31:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 23 Mar 2017 23:31:04 -0400 (EDT) Received: (qmail 13335 invoked from network); 24 Mar 2017 03:31:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Mar 2017 03:31:03 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 1F05BEC8173; Thu, 23 Mar 2017 20:31:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build) Message-Id: <906EDF27-C387-4188-978F-66B81E31093B@dsl-only.net> Date: Thu, 23 Mar 2017 20:31:02 -0700 To: Baptiste Daroussin , FreeBSD Toolchain , freebsd-arm , FreeBSD Ports 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: Fri, 24 Mar 2017 03:31:12 -0000 Building = /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full --- libc.so.7.full --- building shared library libc.so.7 /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): = R_AARCH64_ABS64 used with TLS symbol udb /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): = R_AARCH64_ABS64 used with TLS symbol uf /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): = R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_initialized /usr/local/aarch64-freebsd/bin/ld: = cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with = TLS symbol dtors /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): = R_AARCH64_ABS64 used with TLS symbol __thread_locale /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale cc: error: linker command failed with exit code 1 (use -v to see = invocation) # Meta data file = /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full.meta CMD @echo building shared library libc.so.7 CMD @rm -f libc.so.7 libc.so CMD cc -B/usr/local/aarch64-freebsd/bin/ -mcpu=3Dcortex-a53 -target = aarch64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/pine64_clang/arm64.aarch64/usr/src/tmp = -B/usr/local/aarch64-freebsd/bin/ -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'/usr/local/aarch64-freebsd/bin/nm' NMFLAGS=3D'' lorder = machdep_ldisQ.pico . . . wmemset.pico | tsort -q` -lcompiler_rt -lssp_nonshared CWD /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc TARGET libc.so.7.full -- command output -- building shared library libc.so.7 /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): = R_AARCH64_ABS64 used with TLS symbol udb /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): = R_AARCH64_ABS64 used with TLS symbol uf /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): = R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_initialized /usr/local/aarch64-freebsd/bin/ld: = cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with = TLS symbol dtors /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): = R_AARCH64_ABS64 used with TLS symbol __thread_locale /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale cc: error: linker command failed with exit code 1 (use -v to see = invocation) *** Error code 1 I had recently updated to: # svnlite info /usr/ports | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 436747 Last Changed Rev: 436747 (from -r434493) which picked up: Author: bapt Date: Wed Mar 22 21:10:39 2017 New Revision: 436732 URL:=20 https://svnweb.freebsd.org/changeset/ports/436732 Log: Update to binutils 2.28 =20 Mark the NLS options and the STATIC options as conflicting the binutils built system tries to statically link to the dynamic = version of libintl which obviously fails Modified: head/devel/aarch64-binutils/Makefile head/devel/aarch64-none-elf-binutils/pkg-plist head/devel/arm-gnueabi-binutils/pkg-plist head/devel/arm-none-eabi-binutils/pkg-plist and: Author: bapt Date: Wed Mar 22 21:12:23 2017 New Revision: 436733 URL:=20 https://svnweb.freebsd.org/changeset/ports/436733 Log: Actulally update binutils Deleted: head/devel/binutils/files/patch-gold_options.h Modified: head/devel/binutils/Makefile head/devel/binutils/distinfo But the likes of devel/aarch64-binutils is a slave from devel/binutils --so devel/binutils also needed to be reverted. So I did: # svnlite update -r436731 devel/binutils \ devel/aarch64 \ devel/aarch64-none-elf-binutils \ devel/arm-gnueabi-binutils \ devel/arm-none-eabi-binutil and then rebuilt them. This allowed the buildworld to complete. Context details: # uname -paKU FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT r315870M amd64 = amd64 1200027 1200027 # more = ~/sys_build_scripts.amd64-host/make_pine64_nodebug_clang_bootstrap-amd64-h= ost.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_pine64_nodebug_clang_bootstrap-amd64-hos= t-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.pine64-clang-bootstrap.amd64-ho= st" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/pine64_clang" \ make $* #WITH_META_MODE=3Dyes \ # # more ~/src.configs/src.conf.pine64-clang-bootstrap.amd64-host=20 TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_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 WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=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 # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ XCFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} XCXXFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # more ~/src.configs/make.conf CFLAGS.gcc+=3D -v (But gcc is not in use here.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Mar 24 09:16: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 A9097CA12EA for ; Fri, 24 Mar 2017 09:16:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 6D2031CEB for ; Fri, 24 Mar 2017 09:16:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1584 invoked from network); 24 Mar 2017 09:17:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Mar 2017 09:17:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Fri, 24 Mar 2017 05:16:13 -0400 (EDT) Received: (qmail 19409 invoked from network); 24 Mar 2017 09:16:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Mar 2017 09:16:13 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 5A30AEC8173; Fri, 24 Mar 2017 02:16:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: head -r315870 (e.g.): fork-then-swap-out [zero RES(ident memory)] questions tied to arm64 failures (zeroed memory pages) From: Mark Millard In-Reply-To: <59C6BC12-1BC2-41D5-8B47-D0AD44D2CDF0@dsl-only.net> Date: Fri, 24 Mar 2017 02:16:11 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <4D7B13F4-142E-4294-A6E7-11CCD4C92AC5@dsl-only.net> References: <59C6BC12-1BC2-41D5-8B47-D0AD44D2CDF0@dsl-only.net> To: freebsd-hackers@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: Fri, 24 Mar 2017 09:16:20 -0000 On 2017-Mar-22, at 3:09 PM, Mark Millard wrote: > The later questions are associated with: > > Bugzilla 217239 and 217138 (which I now expect have a common cause) > https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015867.html > (and its thread) > > These are tied to some process memory pages being trashed (to > be zero) in particular types of arm64 contexts. This is > reproducible in multiple arm64 contexts. The context is head > but I believe there are reports in the lists tied to 11 as > well. > > [Unfortunately the above all very much shows a learn-as-I-go > property. Also the list has a sub-exchange on my testing other > devices to check for device failures that is not directly > relevant here.] > > These are tied to problems with fork-then-swap-out-then-swap-in > contexts on arm64. (Even though I've occasionally typed amd64 > accidentally in places in those materials.) Memory allocations > from before the fork are involved, ones not yet accessed by > the child side of the fork at the time of the fork. > > fork sets up copy-on-write so that the child process temporarily > shares pages (those it does not write), or should. > > But what if the parent process or both parent and child are > swapped-out just shortly after the fork (so, say, top -PCwaopid > shows zero for RES(ident memory)? What is the handling of, say, > the child swapping back in while the parent still is swapped > out? > > I notice that the child can have a much smaller SWAP figure > than the parent so it would appear that the parent swap-out > has pages that the child does not. > > So what if the child needs some of those pages? What should > happen? (Vs. what does happen on arm64 in specific types > of contexts? More below.) > > I ask mostly to see if I can do more to give evidence of > what is going on and what to test for any proposed fix. > I'm not likely to find the underlying problem(s) for arm64 > directly, unlike my investigation that lead to > fork-trampoline being fixed in head's -r313772 > (2017-Feb-15). > > [ https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015656.html > and its thread, including when its title changed in: > https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015678.html > .] > > Part of that unlikely-to-solve status is because the > context seems to be bound to a lot of special conditions > and interesting behaviors simultaneously: > > A) Both my original reproductions of problem reports on the > lists and the only (simple) programs for reproducing the > probablems involve fork-then-swap-out [zero RES(ident > memory)]. Neither fork by itself nor swap-out/in by > itself have been sufficient. > > B) jemalloc's tcache being in use (__je_tcache_maxclass == 32*1024) > is part of every example of reproduction of the problem. > > C) allocations <= SMALL_MAXCLASS (SMALL_MAXCLASS==14*1024) get > the failure (but bigger ones work, both fitting inside > __je_tcache_maxclass and not). Again: every example > reproduction of the problem has this status. > > D) FreeBSD sometimes gets into a state where /etc/malloc.conf > doing tcache:false does not seem to disable tcache. (Rebooting > goes back to tcache:false working after such has been > observed.) [Related or independent? I've no clue.] Usually > tcache:false seems to work and so avoid the failures. > > E) Use of POSIX_MADV_WILLNEED on the problematical allocation(s) > in the child process after the fork but before the swap-outs > of the child and parent prevents the failures (no read or > write access to the memory from the child until after the > swap-in). Doing so just in the parent process does not prevent > the failures. > > F) Similar to (E) but read-accessing a byte or more of one or > more pages from the problematical allocations from the child > process after the fork but before the swap-out makes those > specific pages not fail. (The others still fail, if any.) > Done from the parent process instead does not avoid the > failures. > > G) In a sequence like: su creates a sh which then runs one > of my test programs that then forks off a child it can be > that all of the 4 processes show the zeroed memory area > like the child process does. su and sh need to have > swapped-out and back in for them to get failures. su and > sh die once they hit an assert that fails due to the zeroed > memory page(s). The asserts involve addresses also messed > up in the test program processes (parent and child). > > In my reading I've not been able to determine what to expect > for fork-then-swap-out-and-back-in for pages that the child > process had not accessed yet but which might not be around > for later activity because of the parent process's own > swapped-out status at the time. > > Note: While I usually run a non-debug kernel I've tried > a debug kernel and it provided no notices of problems. I > got no additional information from the attempt. > > [My usual KERNCONF file includes GENERIC and then disables > various debug items.] > > The bugzilla reports have example code for showing the > problems and various behaviors. The two in 217239 are > probably of more interest than the first one on 217138. I just updated the pine64+ 2GB to head -r315870 and it still gets the trashed-with-zeros pages from sequences such as: allocation(s) (tcache in use with fitting <= SMALL_MAXCLASS) initialize them (to non-zero bytes) fork sleep/wait then swap-out [zero RES(ident memory)] (both parent and child in my tests) (Note the lack of access so far on the child process side.) swap-in After swap-in both the Child and Parent see the indicated allocation(s) as having only zero bytes instead of the initialization values. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Mar 24 11:45:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F370DD1B7B3 for ; Fri, 24 Mar 2017 11:45:43 +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::10]) (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 7F8AD18BD for ; Fri, 24 Mar 2017 11:45:42 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490355938; l=6347; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=N//Fn1vcnD/8FYozOWLCG7kSuPjItwWeteDZN4GbKYI=; b=BPSGxF5lqQdoPWB+B7pO/H1Exm9oLalP/PklEKJVjt0Yaed4bDug4fsNdCKncUlYad rzHz5P5cAvkELx0VUGuFLFzxIrxCFxb6ppHE/s7QStZUEIoArdyqBQbLoEMX2R1IXTIS lL4X4oOqVafGQae1GIIgRmUrG2ZJOdB3ambts= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.3 DYNA|AUTH) with ESMTPSA id D05e64t2OBjcCSL (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) for ; Fri, 24 Mar 2017 12:45:38 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 043D87506DAD for ; Fri, 24 Mar 2017 08:45:34 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: "Dr. Rolf Jansen" In-Reply-To: Date: Fri, 24 Mar 2017 08:45:33 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <49570189-CEB5-47BE-966A-BCF7FC73A415@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> <1490281652.58015.71.camel@freebsd.org> <7E957E90-5579-4A7F-83DC-1B5522833EC2@obsigna.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) 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, 24 Mar 2017 11:45:44 -0000 Am 23.03.2017 um 23:52 schrieb Warner Losh : > On Thu, Mar 23, 2017 at 8:46 PM, Dr. Rolf Jansen = wrote: >> Am 23.03.2017 um 17:37 schrieb Warner Losh : >>> On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore wrote: >>>> On Thu, 2017-03-23 at 00:42 -0300, Dr. Rolf Jansen wrote: >>>>> Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza = : >>>>>> On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> ... ask you for suggestions. >>>>>> [picking a random message to reply] >>>>>>=20 >>>>>> I just saw an email from SanDisk support (whatever this means) >>>>>> where >>>>>> they claim the only supported model for this kind of use is the >>>>>> high-endurance series: >>>>>> = https://www.sandisk.com/home/memory-cards/microsd-cards/high-endura >>>>>> nce-microsd >>>>>>=20 >>>>>> This same email says that running any kind of OS in any of the >>>>>> other >>>>>> card models automatically breaks the warranty. >>>>> Luiz, thank you very much for the note. Do you know, whether this >>>>> high endurance XC card is compatible with the Beaglebone Black? >>>>=20 >>>> I would assume that it is, they're typically just standard sd cards >>>> with flash arrays based on SLC technology and with a lot of extra = space >>>> for reassigning bad blocks (a card that claims 8gb capacity could >>>> actually have 4x that many blocks or more available internally). >>>=20 >>> I don't think there's 4x over-provisioning. Where do you get that = figure? >>>=20 >>> When I was at Fusion I/O, the designs there were all in the 9-24% >>> range, and our "intel" on what others were doing showed a range of = 5% >>> to 40% depending on the market segment and type of NAND use. If they >>> are really using SLC NAND for these cards, the sparing is likely = less >>> because TLC NAND has about a 200-300 endurance rating (program erase >>> cycles per erase block). MLC is between 3000-5000. SLC is like >>> 30,000-100,000. SLC has also 10-100x better error rates than MLC = which >>> has 10-100x better than TLC due to how the charge nodes are = programmed >>> and the tolerances associated with that programming. There was >>> constant pressure to come up with designs that needed less sparing, = so >>> I doubt things have changed to require 4x over provisioning.... What >>> might be going on when people say that has to due with a feature of >>> modern NAND chips: they can be programmed as SLC, MLC or TLC often = on >>> a per-erase block basis. In that case, a SLC configuration with a = 33% >>> over provisioning would have a 4x maximum theoretical raw capacity >>> over the selected size for the drive (so a 8GB drive would have 8GB = * >>> 1.33 (over provisioning: spares and OOB) * 3 (TLC multiplier) or = 32GB >>> of raw capacity). >>>=20 >>>> But be aware that high-endurance or industrial-rated cards can be = very >>>> expensive. I think at work we pay around $40 each for = industrial-rated >>>> 8gb cards. (One of them was included in those test results I = posted, >>>> and the performance was among the best, at least you get something = for >>>> all that extra money.) >>>=20 >>> Part of the issue is that NAND chips these days can be SLC, MLC or = TLC >>> depending on how you program them (often on an erase-block = level).[*] >>> This means that the 8GB SLC card could also be a 16GB MLC card or a >>> 24GB TLC card (well, due to sparing it likely wouldn't scale >>> linearly). So from that perspective, I can see where a 4x number = might >>> come up (high number of bits possible for the die vs capacity >>> configured for SLC + spares). At 33% sparing, the differences = between >>> the SD presented capacity point of 8GB would have close to 32GB of >>> potential raw capacity were it run in TLC mode.... In addition, high >>> endurance cards are often selected from the wafers at manufacturing >>> time because they have the lowest error rate and other metrics so = the >>> NAND makers know that they will survive (the NAND manufacturing >>> process isn't too uniform across the wafer due to micro variations = in >>> the wafer and other effects at the nano-scale). Often times these = are >>> also pulled from processes that typically yield better results but = are >>> more expensive. So the relative rarity of the raw dies plus the >>> increased production cost plus running them in a faster, more = reliable >>> mode all lead to the cards being more expensive.... >>>=20 >>> So that's why it's so expensive, especially on the high end: you are >>> paying extra for quality. >>=20 >> Warner and Ian, thank you very much for sharing your much deeper = insights on the matter. >>=20 >> I am setting up a prototype for a mostly autonomous measurement = device for an industrial application using the BBB as the controller. = For this reason I am interested in the ti_adc driver, and I was glad = that I got it working. >>=20 >> Once the device has been setup, writes to the SD card will be limited = to logging measurement data and activity events besides the normal = FreeBSD logging. The 4 GB internal flash of the BBB would be more than = sufficient to hold everything, however, I was thinking that using an = external SD card in order not to damage the BBB because of flash wear, = would be a good idea. >>=20 >> Well, for this kind of application $40 is still in the budget, = however, it comes already close to the cost of the BBB itself. Perhaps, = I simply forget the SD cards and provide to my future customers spare = BBB's. >>=20 >> Anyway, I guess I need to do some lifetime simulation of the external = flash compared to the internal one, so I could take a more educated = decision based on these results. >=20 > Lifetime / endurance is normally normalized to 'Drive Writes Per Day'. > You should check to see what the endurance of the eMMC in the unit is. > You may have enough headroom to just log there. SSDs always specify > this, but SD cards seem to rarely do. I did a search on these figures for the BBB, although I did not found = the exact value, what I read was discouraging enough for me. So I = decided not to touch the internal flash too much. Many thanks again Rolf= From owner-freebsd-arm@freebsd.org Fri Mar 24 18:36: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 20522D1BA34 for ; Fri, 24 Mar 2017 18:36:59 +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 CE3B91D8E for ; Fri, 24 Mar 2017 18:36:58 +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 B86D75FAE0 for ; Fri, 24 Mar 2017 13:36:52 -0500 (CDT) Subject: Re: Pi-series sound output options To: "freebsd-arm@freebsd.org" References: <025036c0-a5a7-33f2-58a7-55f31fbc6e41@denninger.net> From: Karl Denninger Message-ID: Date: Fri, 24 Mar 2017 13:36:52 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030308060302050407070201" 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, 24 Mar 2017 18:36:59 -0000 This is a cryptographically signed message in MIME format. --------------ms030308060302050407070201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/22/2017 11:35, Hans Petter Selasky wrote: > On 03/22/17 17:19, Karl Denninger wrote: >> This application NEEDS sound output capability. I don't care if it's = on >> a plug-in via USB but it has to work in a "FreeBSD-like" manner (e.g. >> open up a PCM channel, etc.) > > Hi, > > Do you need both playback and recording? > > How many channels, bitrate etc? > > USB audio 2x16-bit 48k over FULL or preferably HIGH-speed should work > reliably. > > Your hang issue sounds like a GPIO / unhandled IRQ issue. > > --HPS The USB output option works.... even with a very cheap adapter. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030308060302050407070201 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjQxODM2NTJaME8GCSqGSIb3DQEJBDFCBECQeeAm OxKp0v3lRrEmbHBpgF4oI5DUlXAZ3HsDzzD+1sAX6YJjWyLYoWsW/9t5RLx3yhozA43EGsQy iq81rmVSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAMQHE1nX3I3Jp psyPw/qAYve9TyvNCR/dzRnQzRBz3xMZ1izweCNeDADs7J0zNu8lgvt+UlbT8VQ0SeePxS4e pYkxeFSBBul/yrzFujJOpycAr/YZz6pv5tmScB2UKbPZ10ViNxy5T1dFzov3Wtrg2UHVtKy0 wPaa3dHIgeuCPmuL1V+3Y+rdFXig9Mc+kJPl5gkeIAmxEzR5xmkcFgddLUzGah0McZaOUCUb /XLCz1z7ILQQPpZrns92QbRxw0txZzdZqai9RAXsMJUfFBy3cEPMMOIxSbEdY7FpussaEzz5 1RyKVzF3duMe5hRxMNxyfifu3JbmONsYy0CGk/SDDUlcb9CIJMjw71hlAZSS6QmWKyEWDlsZ sTwx7t6jGodFm3slvjsYz+XYtGjHNalwIqOqeR8n6UvqCC8t05gU6V/xZJhj//LpM5PKesZo 4284B+M4ytPco8qwtYjlBqYhvk9vjwU2uzdmAG08TfNQ9oWNxgU61mAHfk/k5+4V3kpf9bYN SXFXJVsEyjxDrryBknF4Gwe17YcS13FDOp3gphJ2ZTf9+I1a6GZ0p8nrPgk86J541m1j7mT+ DnB3kzdvyLqvpBhA9JalLlYPcJv8mo6FJ2AI1m1eojXZXIU1JhCWqqn7pcXMOZlJZzLFDvZe hT7Kx15jqw4JHR3AU8qsiysAAAAAAAA= --------------ms030308060302050407070201-- From owner-freebsd-arm@freebsd.org Fri Mar 24 18:57:04 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 27EABD1B255 for ; Fri, 24 Mar 2017 18:57:04 +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 EDEF9E0F for ; Fri, 24 Mar 2017 18:57:03 +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 1crUOL-000HA1-Hh; Fri, 24 Mar 2017 11:56:57 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v2OIuq3W065968; Fri, 24 Mar 2017 11:56:52 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 24 Mar 2017 11:56:52 -0700 From: Oleksandr Tymoshenko To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: i2c on Pi3? Message-ID: <20170324185652.GA65910@bluezbox.com> References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> <20170323175342.GA55627@bluezbox.com> <843bbe39-0b74-0d27-598d-ae16aea52a37@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <843bbe39-0b74-0d27-598d-ae16aea52a37@denninger.net> 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: Karl Denninger (karl@denninger.net) wrote: > > On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: > > Karl Denninger (karl@denninger.net) wrote: > >> On 3/23/2017 12:34, John Howie wrote: > >> > >>> Hi Karl, > >>> > >>> I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. For an example how to use it from userland, check out a project I posted on github eighteen months ago, that was for the PiFace RTC. > >>> > >>> https://github.com/jhowie/FreeBSDPiFaceRTC > >>> > >>> There are useful routines I created for working with devices on the I2C bus, which you are free to use. They are not RPI2-specific, so they should work on other boards. > > .. skipped .. > >> It works on the Pi2; I am using it in production. > >> > >> The driver appears to be /missing /in the Pi3 kernel. > > Probably it's not enabled in DTB. Try adding this line to config.txt: > > > > dtparam=i2c_arm=on,spi=on > > > Nope, already in the base config.txt file: > > arm_control=0x200 > dtparam=audio=on, i2c_arm=on, spi=on > dtoverlay=mmc > dtoverlay=pi3-disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin [...] 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: github.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, 24 Mar 2017 18:57:04 -0000 Karl Denninger (karl@denninger.net) wrote: > > On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: > > Karl Denninger (karl@denninger.net) wrote: > >> On 3/23/2017 12:34, John Howie wrote: > >> > >>> Hi Karl, > >>> > >>> I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. For an example how to use it from userland, check out a project I posted on github eighteen months ago, that was for the PiFace RTC. > >>> > >>> https://github.com/jhowie/FreeBSDPiFaceRTC > >>> > >>> There are useful routines I created for working with devices on the I2C bus, which you are free to use. They are not RPI2-specific, so they should work on other boards. > > .. skipped .. > >> It works on the Pi2; I am using it in production. > >> > >> The driver appears to be /missing /in the Pi3 kernel. > > Probably it's not enabled in DTB. Try adding this line to config.txt: > > > > dtparam=i2c_arm=on,spi=on > > > Nope, already in the base config.txt file: > > arm_control=0x200 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=pi3-disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin I just built latest HEAD, i2c driver is available in GENERIC kernel: # dmesg | grep iic iichb0: mem 0x7e804000-0x7e804fff irq 31 on simplebus0 iicbus0: on iichb0 random: harvesting attach, 8 bytes (4 bits) from iicbus0 random: harvesting attach, 8 bytes (4 bits) from iichb0 The driver itself is sys/arm/broadcom/bcm2835/bcm2835_bsc.c Could you run this command on your Pi3 and send output? Thanks sysctl -b hw.fdt.dtb | dtc -I dtb | grep -A 13 'i2c@.*{' -- gonzo From owner-freebsd-arm@freebsd.org Fri Mar 24 19:37: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 C0EA3D1C07F for ; Fri, 24 Mar 2017 19:37:15 +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 679509B3 for ; Fri, 24 Mar 2017 19:37:15 +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 3F94E5FBFF; Fri, 24 Mar 2017 14:37:14 -0500 (CDT) Subject: Re: i2c on Pi3? To: Oleksandr Tymoshenko References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> <20170323175342.GA55627@bluezbox.com> <843bbe39-0b74-0d27-598d-ae16aea52a37@denninger.net> <20170324185652.GA65910@bluezbox.com> Cc: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: Date: Fri, 24 Mar 2017 14:37:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170324185652.GA65910@bluezbox.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080901070107060608020301" 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, 24 Mar 2017 19:37:15 -0000 This is a cryptographically signed message in MIME format. --------------ms080901070107060608020301 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/24/2017 13:56, Oleksandr Tymoshenko wrote: > Karl Denninger (karl@denninger.net) wrote: >> On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: >>> Karl Denninger (karl@denninger.net) wrote: >>>> On 3/23/2017 12:34, John Howie wrote: >>>> >>>>> Hi Karl, >>>>> >>>>> I can only speak to the Raspberry Pi 2 kernel, but I2C is supported= =2E For an example how to use it from userland, check out a project I pos= ted on github eighteen months ago, that was for the PiFace RTC. >>>>> >>>>> https://github.com/jhowie/FreeBSDPiFaceRTC >>>>> >>>>> There are useful routines I created for working with devices on the= I2C bus, which you are free to use. They are not RPI2-specific, so they = should work on other boards.=20 >>> .. skipped .. >>>> It works on the Pi2; I am using it in production. >>>> >>>> The driver appears to be /missing /in the Pi3 kernel. >>> Probably it's not enabled in DTB. Try adding this line to config.txt:= >>> >>> dtparam=3Di2c_arm=3Don,spi=3Don >>> >> Nope, already in the base config.txt file: >> >> arm_control=3D0x200 >> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >> dtoverlay=3Dmmc >> dtoverlay=3Dpi3-disable-bt >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin > I just built latest HEAD, i2c driver is available in GENERIC kernel: > # dmesg | grep iic > iichb0: mem 0x7e804000-0x7e804fff irq 31 > on simplebus0 > iicbus0: on iichb0 > random: harvesting attach, 8 bytes (4 bits) from iicbus0 > random: harvesting attach, 8 bytes (4 bits) from iichb0 > > The driver itself is sys/arm/broadcom/bcm2835/bcm2835_bsc.c > > Could you run this command on your Pi3 and send output? Thanks > > sysctl -b hw.fdt.dtb | dtc -I dtb | grep -A 13 'i2c@.*{' > I have a copy of Generic with a couple of tweaks in it; I DO NOT get the iic identifiers. Here's what I have in the dtb; I will svn update and rebuild with GENERIC (don't see why the tweaks would change anything, but will try with GENERIC anyway and see if anything changes. root@rpi3:~ # sysctl -b hw.fdt.dtb | dtc -I dtb | grep -A 13 'i2c@.*{' : Warning (unit_address_vs_reg): Node /axi/vc_mem has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): Node /soc/gpiomem has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): Node /soc/vchiq has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): Node /soc/local_intc has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name : Warning (avoid_default_addr_size): Relying on default #address-cells value for /axi/vc_mem : Warning (avoid_default_addr_size): Relying on default #size-cells value for /axi/vc_mem i2c@7e205000 { compatible =3D "brcm,bcm2835-i2c"; reg =3D <0x7e205000 0x1000>; interrupts =3D <0x2 0x15>; clocks =3D <0x7 0x14>; #address-cells =3D <0x1>; #size-cells =3D <0x0>; status =3D "disabled"; pinctrl-names =3D "default"; pinctrl-0 =3D <0xf>; clock-frequency =3D <0x186a0>; phandle =3D <0x25>; }; -- i2c@7e804000 { compatible =3D "brcm,bcm2835-i2c"; reg =3D <0x7e804000 0x1000>; interrupts =3D <0x2 0x15>; clocks =3D <0x7 0x14>; #address-cells =3D <0x1>; #size-cells =3D <0x0>; status =3D "okay"; pinctrl-names =3D "default"; pinctrl-0 =3D <0x13>; clock-frequency =3D <0x186a0>; phandle =3D <0x26>; }; i2c@7e805000 { compatible =3D "brcm,bcm2835-i2c"; reg =3D <0x7e805000 0x1000>; interrupts =3D <0x2 0x15>; clocks =3D <0x7 0x14>; #address-cells =3D <0x1>; #size-cells =3D <0x0>; status =3D "disabled"; clock-frequency =3D <0x186a0>; phandle =3D <0x14>; }; vec@7e806000 { compatible =3D "brcm,bcm2835-vec"; --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080901070107060608020301 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjQxOTM3MTNaME8GCSqGSIb3DQEJBDFCBEC7+Z64 6wgpxkJn4itEtmX9BM/u0z9cWu3e2w1K030kHXbGAjk6JMENCKuOGR+7IHB6Sww2uPEQIxee jwz/M369MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIApWvVmiVDq/25 KqycKnbuzuIkg0YJz1IH834HoFv4gZXA3+op1AhNol8i6CQL8CZ5LQK8CKbPZWQBkGavw0bV NgoGzyghOdBokBQRlFNv35gLDfEi40TVY61vO4K0zrGv7bm7f0CL3BHEdjHiEuruRs7+FufG X9EUV13djOtOhuhT5njEiPDRgWj2b2K6f44FLtBi/hEekmIAKIKZUR5D/S6gLNmv33pMw9RG IXX4jeBXfu0a7c7IyTwSgm2TpmZC+V0Q/OxnptHDIs+biz/sFOnQCuv/g3nMYq5KejgxVHG6 F9Y/mtUPR7acYSSBt2vJ4FmBXomACvDj/cJ0iuQm1Zbsx7zXj6cnRi8aY2l/m6u83fEZAUyy GmTNypj31+mo3c+NML41Px31F5uaZV/fGaOmVGAyhgwI6RfAb7bQ3mJw9tDllvbLPoWV82K/ LcswVHJMq8SzdKvO9+/WVtAvwCbgdE3Ru0Gbnu0Jfh2nBv6sQnPHxCV8Iu2nbIqeE7hZ6F1W 9Gy9ThjQvyMkNQAJQci3EQMu4eupex4ucMeTS+JfZefpPBBv6Q2mb0t/Osm70CYGPdn0GvYL d5OJn6juU4HKdMNRvkZCyuziSa4cJ47wsD9A3sA0xWPc518jeudm/1B5Rfj4cQk3eMiCfJRQ r1IMZ4CbxhZSltnXKcLfTVgAAAAAAAA= --------------ms080901070107060608020301-- From owner-freebsd-arm@freebsd.org Fri Mar 24 19:44: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 3D99AD1C214 for ; Fri, 24 Mar 2017 19:44:33 +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 CF8C9CFB for ; Fri, 24 Mar 2017 19:44:32 +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 1crV8S-000HGQ-1h; Fri, 24 Mar 2017 12:44:32 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v2OJiVaN066365; Fri, 24 Mar 2017 12:44:31 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 24 Mar 2017 12:44:31 -0700 From: Oleksandr Tymoshenko To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: i2c on Pi3? Message-ID: <20170324194431.GA66320@bluezbox.com> References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> <20170323175342.GA55627@bluezbox.com> <843bbe39-0b74-0d27-598d-ae16aea52a37@denninger.net> <20170324185652.GA65910@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: Karl Denninger (karl@denninger.net) wrote: > On 3/24/2017 13:56, Oleksandr Tymoshenko wrote: > > Karl Denninger (karl@denninger.net) wrote: > >> On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: > >>> Karl Denninger (karl@denninger.net) wrote: > >>>> On 3/23/2017 12:34, John Howie wrote: > >>>> > >>>>> Hi Karl, > >>>>> > >>>>> I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. For an example how to use it from userland, check out a project I posted on github eighteen months ago, that was for the PiFace RTC. > >>>>> > >>>>> https://github.com/jhowie/FreeBSDPiFaceRTC > >>>>> > >>>>> There are useful routines I created for working with devices on the I2C bus, which you are free to use. They are not RPI2-specific, so they should work on other boards. > >>> .. skipped .. > >>>> It works on the Pi2; I am using it in production. > >>>> > >>>> The driver appears to be /missing /in the Pi3 kernel. > >>> Probably it's not enabled in DTB. Try adding this line to config.txt: > >>> > >>> dtparam=i2c_arm=on,spi=on > >>> > >> Nope, already in the base config.txt file: > >> > >> arm_control=0x200 > >> dtparam=audio=on, i2c_arm=on, spi=on > >> dtoverlay=mmc > >> dtoverlay=pi3-disable-bt > >> device_tree_address=0x4000 > >> kernel=u-boot.bin > > I just built latest HEAD, i2c driver is available in GENERIC kernel: > > # dmesg | grep iic > > iichb0: mem 0x7e804000-0x7e804fff irq 31 > > on simplebus0 > > iicbus0: on iichb0 > > random: harvesting attach, 8 bytes (4 bits) from iicbus0 > > random: harvesting attach, 8 bytes (4 bits) from iichb0 > > > > The driver itself is sys/arm/broadcom/bcm2835/bcm2835_bsc.c > > > > Could you run this command on your Pi3 and send output? Thanks > > > > sysctl -b hw.fdt.dtb | dtc -I dtb | grep -A 13 'i2c@.*{' > > > > I have a copy of Generic with a couple of tweaks in it; I DO NOT get the > iic identifiers. > > Here's what I have in the dtb; I will svn update and rebuild with > GENERIC (don't see why the tweaks would change anything, but will [...] 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: github.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, 24 Mar 2017 19:44:33 -0000 Karl Denninger (karl@denninger.net) wrote: > On 3/24/2017 13:56, Oleksandr Tymoshenko wrote: > > Karl Denninger (karl@denninger.net) wrote: > >> On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: > >>> Karl Denninger (karl@denninger.net) wrote: > >>>> On 3/23/2017 12:34, John Howie wrote: > >>>> > >>>>> Hi Karl, > >>>>> > >>>>> I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. For an example how to use it from userland, check out a project I posted on github eighteen months ago, that was for the PiFace RTC. > >>>>> > >>>>> https://github.com/jhowie/FreeBSDPiFaceRTC > >>>>> > >>>>> There are useful routines I created for working with devices on the I2C bus, which you are free to use. They are not RPI2-specific, so they should work on other boards. > >>> .. skipped .. > >>>> It works on the Pi2; I am using it in production. > >>>> > >>>> The driver appears to be /missing /in the Pi3 kernel. > >>> Probably it's not enabled in DTB. Try adding this line to config.txt: > >>> > >>> dtparam=i2c_arm=on,spi=on > >>> > >> Nope, already in the base config.txt file: > >> > >> arm_control=0x200 > >> dtparam=audio=on,i2c_arm=on,spi=on > >> dtoverlay=mmc > >> dtoverlay=pi3-disable-bt > >> device_tree_address=0x4000 > >> kernel=u-boot.bin > > I just built latest HEAD, i2c driver is available in GENERIC kernel: > > # dmesg | grep iic > > iichb0: mem 0x7e804000-0x7e804fff irq 31 > > on simplebus0 > > iicbus0: on iichb0 > > random: harvesting attach, 8 bytes (4 bits) from iicbus0 > > random: harvesting attach, 8 bytes (4 bits) from iichb0 > > > > The driver itself is sys/arm/broadcom/bcm2835/bcm2835_bsc.c > > > > Could you run this command on your Pi3 and send output? Thanks > > > > sysctl -b hw.fdt.dtb | dtc -I dtb | grep -A 13 'i2c@.*{' > > > > I have a copy of Generic with a couple of tweaks in it; I DO NOT get the > iic identifiers. > > Here's what I have in the dtb; I will svn update and rebuild with > GENERIC (don't see why the tweaks would change anything, but will try > with GENERIC anyway and see if anything changes. Looks like DTB in your firmware is different from what I have (my is relatively old). Try applying this patch to your kernel: https://people.freebsd.org/~gonzo/arm/patches/rpi3-bcm2835-i2c.diff -- gonzo From owner-freebsd-arm@freebsd.org Fri Mar 24 21:09:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80AAED1B722 for ; Fri, 24 Mar 2017 21:09:49 +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 2E49319BD for ; Fri, 24 Mar 2017 21:09:49 +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 5F1FD600FA for ; Fri, 24 Mar 2017 16:09:48 -0500 (CDT) Subject: Re: i2c on Pi3? References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> <20170323175342.GA55627@bluezbox.com> <843bbe39-0b74-0d27-598d-ae16aea52a37@denninger.net> <20170324185652.GA65910@bluezbox.com> <20170324194431.GA66320@bluezbox.com> Cc: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <1b44d729-eb76-782f-ba8b-d727e18dfd5a@denninger.net> Date: Fri, 24 Mar 2017 16:09:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170324194431.GA66320@bluezbox.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060501060006090109080803" 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, 24 Mar 2017 21:09:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060501060006090109080803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/24/2017 14:44, Oleksandr Tymoshenko wrote: > Karl Denninger (karl@denninger.net) wrote: >> On 3/24/2017 13:56, Oleksandr Tymoshenko wrote: >>> Karl Denninger (karl@denninger.net) wrote: >>>> On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: >>>>> Karl Denninger (karl@denninger.net) wrote: >>>>>> On 3/23/2017 12:34, John Howie wrote: >>>>>> >>>>>>> Hi Karl, >>>>>>> >>>>>>> I can only speak to the Raspberry Pi 2 kernel, but I2C is support= ed. For an example how to use it from userland, check out a project I pos= ted on github eighteen months ago, that was for the PiFace RTC. >>>>>>> >>>>>>> https://github.com/jhowie/FreeBSDPiFaceRTC >>>>>>> >>>>>>> There are useful routines I created for working with devices on t= he I2C bus, which you are free to use. They are not RPI2-specific, so the= y should work on other boards.=20 >>>>> .. skipped .. >>>>>> It works on the Pi2; I am using it in production. >>>>>> >>>>>> The driver appears to be /missing /in the Pi3 kernel. >>>>> Probably it's not enabled in DTB. Try adding this line to config.tx= t: >>>>> >>>>> dtparam=3Di2c_arm=3Don,spi=3Don >>>>> >>>> Nope, already in the base config.txt file: >>>> >>>> arm_control=3D0x200 >>>> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >>>> dtoverlay=3Dmmc >>>> dtoverlay=3Dpi3-disable-bt >>>> device_tree_address=3D0x4000 >>>> kernel=3Du-boot.bin >>> I just built latest HEAD, i2c driver is available in GENERIC kernel: >>> # dmesg | grep iic >>> iichb0: mem 0x7e804000-0x7e804fff irq 3= 1 >>> on simplebus0 >>> iicbus0: on iichb0 >>> random: harvesting attach, 8 bytes (4 bits) from iicbus0 >>> random: harvesting attach, 8 bytes (4 bits) from iichb0 >>> >>> The driver itself is sys/arm/broadcom/bcm2835/bcm2835_bsc.c >>> >>> Could you run this command on your Pi3 and send output? Thanks >>> >>> sysctl -b hw.fdt.dtb | dtc -I dtb | grep -A 13 'i2c@.*{' >>> >> I have a copy of Generic with a couple of tweaks in it; I DO NOT get t= he >> iic identifiers. >> >> Here's what I have in the dtb; I will svn update and rebuild with >> GENERIC (don't see why the tweaks would change anything, but will try >> with GENERIC anyway and see if anything changes. > Looks like DTB in your firmware is different from what I have (my is > relatively old). Try applying this patch to your kernel: > > https://people.freebsd.org/~gonzo/arm/patches/rpi3-bcm2835-i2c.diff > OK, that fixed it with "device iic" added to the kernel config (which is NOT in GENERIC) Can we get that one-liner committed in -HEAD and "device iic" added to GENERIC? (There's no particular reason for it not to be there I don't think.... without it the device nodes do not get set up and while the device might be recognized getting to it is a bit of a problem!) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060501060006090109080803 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjQyMTA5NDdaME8GCSqGSIb3DQEJBDFCBEBAdpd4 PZvCSOVwsxzP/LSGNzFV4Tw7U4+qj44H6aWfct6FrNquAqWazeqjLQxux8rT0XUw5pwRDC6B X1e6TMtiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAfcs5r3MS2Ak6 RZJ96JRGoaJOu42ozUU/LPHFGX+JsmU1zEnHafnj2bZXovfXCqWYRldEXpodNg1ViUCBzTfE aFeU0AvAltNUiIGyMp5OIubZ1SB5fOkYisFActT5uUfly2mLBVAWAilhEz5YLvT9gJljy+DL 4+cPdoq17AvI8rHURARSUMTV67ICfXuudwy21iaPDTPImQvHcwu9ogfDLGPpLbY13XdXeHRB DhBMlOjUpBCGZpR0vHIh472ptC3I/UNhngh4aTAODk2qG2RfZUqT7UN0V+syoR3HNSou0x4T VNFz35MjSTtPOol0WmeS29zVyFG3eTzQD7M7LGKWPYzIQ0Rr2Tmkshn7pforwv94b7XNc1qQ k0PrgfoaFRa6GK4bdkMrATq/gRlwDUsrFyJp+r35bhxyrV6CWXsVPOqiBnsOYvBQcG9aRw0N HSFR8c8mkDI4JHTYdK3eeAXJ7d542wmfKupCSik18AbvrozrwwfBOnW4wITZ5FUdQDBVQMF0 AdSOVNzkHuFwDsFqCd4rNNEJqhV11VE8okVCgm/kA3eRVoo/x/HoR0IJggfWuGHUYUtpr2wa YK6TaUpUOZ2m3LrYCvTl288Fu/gR02hM+T2u/nakRdNl58QHdii8tqLP3G5OrsaRYD1FBwjm N0cQJX7brek4zTIHTGQCQmUAAAAAAAA= --------------ms060501060006090109080803-- From owner-freebsd-arm@freebsd.org Fri Mar 24 22:03: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 7840BD18BB7 for ; Fri, 24 Mar 2017 22:03:46 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter04.peak.org (filter04.peak.org [69.59.194.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.peak.org", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51425193F for ; Fri, 24 Mar 2017 22:03:45 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter04.peak.org ({b5578ef9-c87c-4111-97f7-092309db775d}) via TCP (outbound) with ESMTPS id 20170324220027932_0000 for ; Fri, 24 Mar 2017 15:00:27 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id A00E66293A for ; Fri, 24 Mar 2017 15:00:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 844254D7A8 for ; Fri, 24 Mar 2017 15:00:22 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HDKvZXpeFQPO for ; Fri, 24 Mar 2017 15:00:22 -0700 (PDT) Received: from mailproxy-lb-06.peak.org (mailproxy-lb-06.peak.org [207.55.17.96]) by zmail-mta02.peak.org (Postfix) with ESMTP id 4C3106287D for ; Fri, 24 Mar 2017 15:00:22 -0700 (PDT) Received: from carlj by elm.localnet with local (Exim 4.88 (FreeBSD)) (envelope-from ) id 1crXFt-000M0w-0a for freebsd-arm@freebsd.org; Fri, 24 Mar 2017 15:00:21 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Why no 12.0-Current snapshots for RPi2? X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 24 Mar 2017 15:00:20 -0700 Message-ID: <8660iybaiz.fsf@elm.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 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, 24 Mar 2017 22:03:46 -0000 I just noticed for the third time in a row there are new snapshot images of 12.0-Current for armv6, but none for the RPi2. There are ones for the RPi-B and several others. Does anybody know if there is some problem with the RPi2, or has somebody just misplaced a command in a script somewhere? Thanks. -- Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Fri Mar 24 22:33:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 920A5D1B680 for ; Fri, 24 Mar 2017 22:33:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 61B1DA75 for ; Fri, 24 Mar 2017 22:33:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id 190so4171072itm.0 for ; Fri, 24 Mar 2017 15:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Jh+MYZQjf0e83Jtyiw4r5ase2kVUmn+zty2HEqTXRx0=; b=1LsTSZ82+4NatoAZnSGKoIdECfiBe4YfYIw+DBOwGF9K69MUlkE9pfYFl1mVQMtetx 1SSR5Ry95inRiY3hhEV/b/HLiayqhMokZ4eV/S0uGuugi3achVNhW+H1jcRw/93Wr3R6 vri8JsXc3v4QxMTWS0P1ppzphjrR9Vbp7lFSxNE9muPDjRrKJdOH4yc2cQjYyrx3GlQa hzlJvMbPTy3E5tFcSurhc6kEGUhkUTLKPOlPLa8f7m5A5Jv+IwYsCP1moer1Ka2+zWaP jezsN+AHSjftymiS1Pj9nLfxZWjKzxwjbbSTuMNs4Zcxy+tj80hjIxrpCxrkuM8gRwj4 teHQ== 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=Jh+MYZQjf0e83Jtyiw4r5ase2kVUmn+zty2HEqTXRx0=; b=umOr4xTiw5IF5YuvkWnY3bPLjYsj9LDS/qIUZ6Mk6p340fSlLjsEJ+VvSSNgaLAAJw niJCW+/5wYm7lg/fcTHaDtCbOd91AMvSpPYbE2tPtq7c0vTaUx0epL24KiEksLyOs/iG q9OOsI16cGqyMomNSFKTOv/0d/SxrLgCHHmOMz5HPB7A1f/QC8FpONTgyve5DBmOjR+B XSLmDz6aT0E96hGyd5woCS22v62sLymVC/O+p0AmTcBUUf9kx6cVhSEvYkMTWpQ1onua mgQGOCfD4JEwpoioYjifYpN18M4M/GfbDRx4CcLw8UV1F6XrASIPquFD4bWbYI6X12/j qMUw== X-Gm-Message-State: AFeK/H1UFDOuTrR3ftT+5EiLgOP4c6zwcgUpaJGFRlsoeBgALgchoKJv2RgL0siENx2Zof3tQDdF10ojVetpxQ== X-Received: by 10.36.116.71 with SMTP id o68mr5806705itc.60.1490394828495; Fri, 24 Mar 2017 15:33:48 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Fri, 24 Mar 2017 15:33:47 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::375c] In-Reply-To: <1b44d729-eb76-782f-ba8b-d727e18dfd5a@denninger.net> References: <0b83d41a-1a9e-28cc-6ecd-03e6a63a06a2@denninger.net> <20170323175342.GA55627@bluezbox.com> <843bbe39-0b74-0d27-598d-ae16aea52a37@denninger.net> <20170324185652.GA65910@bluezbox.com> <20170324194431.GA66320@bluezbox.com> <1b44d729-eb76-782f-ba8b-d727e18dfd5a@denninger.net> From: Warner Losh Date: Fri, 24 Mar 2017 16:33:47 -0600 X-Google-Sender-Auth: gDREa3A_LBe8z4IdbcmukmPm_dE Message-ID: Subject: Re: i2c on Pi3? 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: Fri, 24 Mar 2017 22:33:49 -0000 On Fri, Mar 24, 2017 at 3:09 PM, Karl Denninger wrote: > > > On 3/24/2017 14:44, Oleksandr Tymoshenko wrote: >> Karl Denninger (karl@denninger.net) wrote: >>> On 3/24/2017 13:56, Oleksandr Tymoshenko wrote: >>>> Karl Denninger (karl@denninger.net) wrote: >>>>> On 3/23/2017 12:53, Oleksandr Tymoshenko wrote: >>>>>> Karl Denninger (karl@denninger.net) wrote: >>>>>>> On 3/23/2017 12:34, John Howie wrote: >>>>>>> >>>>>>>> Hi Karl, >>>>>>>> >>>>>>>> I can only speak to the Raspberry Pi 2 kernel, but I2C is supported. For an example how to use it from userland, check out a project I posted on github eighteen months ago, that was for the PiFace RTC. >>>>>>>> >>>>>>>> https://github.com/jhowie/FreeBSDPiFaceRTC >>>>>>>> >>>>>>>> There are useful routines I created for working with devices on the I2C bus, which you are free to use. They are not RPI2-specific, so they should work on other boards. >>>>>> .. skipped .. >>>>>>> It works on the Pi2; I am using it in production. >>>>>>> >>>>>>> The driver appears to be /missing /in the Pi3 kernel. >>>>>> Probably it's not enabled in DTB. Try adding this line to config.txt: >>>>>> >>>>>> dtparam=i2c_arm=on,spi=on >>>>>> >>>>> Nope, already in the base config.txt file: >>>>> >>>>> arm_control=0x200 >>>>> dtparam=audio=on,i2c_arm=on,spi=on >>>>> dtoverlay=mmc >>>>> dtoverlay=pi3-disable-bt >>>>> device_tree_address=0x4000 >>>>> kernel=u-boot.bin >>>> I just built latest HEAD, i2c driver is available in GENERIC kernel: >>>> # dmesg | grep iic >>>> iichb0: mem 0x7e804000-0x7e804fff irq 31 >>>> on simplebus0 >>>> iicbus0: on iichb0 >>>> random: harvesting attach, 8 bytes (4 bits) from iicbus0 >>>> random: harvesting attach, 8 bytes (4 bits) from iichb0 >>>> >>>> The driver itself is sys/arm/broadcom/bcm2835/bcm2835_bsc.c >>>> >>>> Could you run this command on your Pi3 and send output? Thanks >>>> >>>> sysctl -b hw.fdt.dtb | dtc -I dtb | grep -A 13 'i2c@.*{' >>>> >>> I have a copy of Generic with a couple of tweaks in it; I DO NOT get the >>> iic identifiers. >>> >>> Here's what I have in the dtb; I will svn update and rebuild with >>> GENERIC (don't see why the tweaks would change anything, but will try >>> with GENERIC anyway and see if anything changes. >> Looks like DTB in your firmware is different from what I have (my is >> relatively old). Try applying this patch to your kernel: >> >> https://people.freebsd.org/~gonzo/arm/patches/rpi3-bcm2835-i2c.diff >> > > OK, that fixed it with "device iic" added to the kernel config (which is > NOT in GENERIC) > > Can we get that one-liner committed in -HEAD and "device iic" added to > GENERIC? (There's no particular reason for it not to be there I don't > think.... without it the device nodes do not get set up and while the > device might be recognized getting to it is a bit of a problem!) It's in the 'arm' GENERIC kernel, but not in arm64. Since you report it works, I've just added it in r315918. Warner From owner-freebsd-arm@freebsd.org Sat Mar 25 20:38: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 9538AD1D516 for ; Sat, 25 Mar 2017 20:38:56 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B65510B8 for ; Sat, 25 Mar 2017 20:38:55 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sat, 25 Mar 2017 21:38:45 +0100 id 00F574CC.58D6D555.0001844A Date: Sat, 25 Mar 2017 21:38:42 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Allwinner and USB working? Message-ID: <20170325213842.69500e9e@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) 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: Sat, 25 Mar 2017 20:38:56 -0000 Hi, has anybody with an Allwinner board working USB? On Orange Pi Zero I got just usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR messages repeating on console when trying to connect an USB HDD. I remember seeing similar or the same message when tested this with Orange Pi One or PC some time ago. As there is some activity after connecting USB device, it is not totally dead, however, something important is missing... My system is reasonably fresh, at svn revision 315652. Regards, Milan