From owner-freebsd-arm@freebsd.org Sun Aug 5 01:46:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 847F0105C24E for ; Sun, 5 Aug 2018 01:46:59 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16BD672A85; Sun, 5 Aug 2018 01:46:58 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w751jjfi094068 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Aug 2018 18:45:45 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w751jjwT094067; Sat, 4 Aug 2018 18:45:45 -0700 (PDT) (envelope-from jmg) Date: Sat, 4 Aug 2018 18:45:45 -0700 From: John-Mark Gurney To: Mark Millard Cc: Jamie Landeg-Jones , bob prohaska , freebsd-arm , markj@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180805014545.GK2884@funkthat.com> Mail-Followup-To: Mark Millard , Jamie Landeg-Jones , bob prohaska , freebsd-arm , markj@freebsd.org References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 04 Aug 2018 18:45:45 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 01:46:59 -0000 Mark Millard wrote this message on Sat, Aug 04, 2018 at 09:08 -0700: > On 2018-Aug-4, at 7:08 AM, John-Mark Gurney wrote: > > > Mark Millard via freebsd-arm wrote this message on Sat, Aug 04, 2018 at 00:14 -0700: > >> On 2018-Aug-3, at 8:55 PM, Jamie Landeg-Jones wrote: > >> > >>> Mark Millard wrote: > >>> > >>>> If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient > >>>> additional RAM, I'd would have guessed that some Active Real Memory > >>>> should then have been paged/swapped out and so RAM would be made > >>>> available. (This requires the system to have left itself sufficient > >>>> room in RAM for that guessed activity.) > >>>> > >>>> But I'm no expert at the intent or actual operation. > >>>> > >>>> Bob P.'s reports (for having sufficient swap space) > >>>> also indicate the likes of: > >>>> > >>>> v_free_count: 5439, v_inactive_count: 1 > >>>> > >>>> > >>>> So all the examples have: "v_inactive_count: 1". > >>>> (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt==1 ) > >>> > >>> Thanks for the feedback. I'll do a few more runs and other stress tests > >>> to see if that result is consistent. I'm open to any other idea too! > >>> > >> > >> The book "The Design and Implementation of the FreeBSD Operating System" > >> (2nd edition, 2014) states (page labeled 296): > >> > >> QUOTE: > >> The FreeBSD swap-out daemon will not select a runnable processes to swap > >> out. So, if the set of runnable processes do not fit in memory, the > >> machine will effectively deadlock. Current machines have enough memory > >> that this condition usually does not arise. If it does, FreeBSD avoids > >> deadlock by killing the largest process. If the condition begins to arise > >> in normal operation, the 4.4BSD algorithm will need to be restored. > >> END QUOTE. > >> > >> As near as I can tell, for the likes of rpi3's and rpi2's, the condition > >> is occurring during buildworld "normal operation" that tries to use the > >> available cores to advantage. (Your context does not have the I/O > >> problems that Bob P.'s have had in at least some of your OOM process > >> kill examples, if I understand right.) > >> > >> (4.4BSD used to swap out the runnable process that had been resident > >> the longest, followed by the processes taking turns being swapped out. > >> I'll not quote the exact text about such.) > >> > >> So I guess the question becomes, is there a reasonable way to enable > >> the 4.4BSD style of "Swapping" for "small" memory machines in order to > >> avoid having to figure out how to not end up with OOM process kills > >> while also not just wasting cores by using -j1 for buildworld? > >> > >> In other words: enable swapping out active RAM when it eats nearly > >> all the non-wired RAM. > >> > >> But it might be discovered that the performance is not better than > >> using fewer cores during buildworld. (Experiments needed and > >> possibly environment specific for the tradeoffs.) Avoiding having > >> to figure out the maximum -j? that avoids OOM process kills but > >> avoids just sticking to -j1 seems and advantage for some rpi3 and > >> rpi2 folks. > > > > Interesting observation, maybe playing w/: > > vm.swap_idle_threshold2: Time before a process will be swapped out > > vm.swap_idle_threshold1: Guaranteed swapped in time for a process > > > > will help thing... lowering 2 will likely make the processes available > > for swap sooner... > > Looking up related information: > > https://www.freebsd.org/doc/handbook/configtuning-disk.html > > says vm.swap_idle_enabled is also involved with those two. In fact > it indicates the two are not even used until vm.swap_idle_enabled=1 . > > QUOTE > 11.10.1.4. vm.swap_idle_enabled > The vm.swap_idle_enabled sysctl(8) variable is useful in large multi-user systems with many active login users and lots of idle processes. Such systems tend to generate continuous pressure on free memory reserves. Turning this feature on and tweaking the swapout hysteresis (in idle seconds) via vm.swap_idle_threshold1 and vm.swap_idle_threshold2 depresses the priority of memory pages associated with idle processes more quickly then the normal pageout algorithm. This gives a helping hand to the pageout daemon. Only turn this option on if needed, because the tradeoff is essentially pre-page memory sooner rather than later which eats more swap and disk bandwidth. In a small system this option will have a determinable effect, but in a large system that is already doing moderate paging, this option allows the VM system to stage whole processes into and out of memory easily. > END QUOTE > > The defaults seem to be: > > # sysctl vm.swap_idle_enabled vm.swap_idle_threshold1 vm.swap_idle_threshold2 > vm.swap_idle_enabled: 0 > vm.swap_idle_threshold1: 2 > vm.swap_idle_threshold2: 10 > > Quoting the book again: > > QUOTE > If the swapping of idle processes is enabled and the pageout daemon can find any > processes that have been sleeping for more than 10 seconds (swap_idle_threshold2, > the cutoff for considering the time sleeping to be "a long time"), it will swap > them all out. [. . .] if none of these processes are available, the pageout > daemon will swap out all processes that has been sleeping for as briefly as 2 > seconds (swap_idle_threshold1). > END QUOTE. > > I'd not normally expect a compile or link to sleep for such long periods > (unless I/O has long delays). Having, say, 4 such processes active at the > same time may be unlikely to have any of them swap out on the default scale. > (Clang is less I/O bound and more memory bound than GCC as I remember what > I've observed. That statement ignores paging/swapping by the system.) > > Such would likely be true on the scale of any positive integer seconds > figures? The point is to more aggressively swap out OTHER processes so that there is more memory available. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Sun Aug 5 05:56:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA56A106760C for ; Sun, 5 Aug 2018 05:56:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-21.consmr.mail.gq1.yahoo.com (sonic304-21.consmr.mail.gq1.yahoo.com [98.137.68.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C8967D281 for ; Sun, 5 Aug 2018 05:56:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ffrxtaoVM1lUrgJtezR23VNdNJ.NcWDvLIA88h_6nnUhQXelf3g6pCwSiAPfOwb TEqhWdwoxNo6PpU9qRIOU2BgeLIr6Xnb7tRsj0AW8sCz08rU74TvQKD.3DZZJxEegDSNOs83cxkR SVlaqUUagg9T2ZA1oGrFPLAogjYc97LM41m1rhfiRy7aZZm7MR5joHx2I1KK3WTAb9fLLyRguQhh lCHpFmaTmErAZ9umt4zTc.AdDmJ6qXn4WveBoOhbc1LBXLqOqVhXJsT9e113Xtjk_32XIIhOS_uY jUEQGxJMH1ELXEugaLdXX2o9RynYgkIRbsO_ueFTNZ.qDI3yvUq8a.TK1TQTO7t8DrIIbJ8gxFvG gSFn28C44LGDrOrwMkVjLGsMyAz1dAwNAKHJf8Nv1sMLDZcaznQ6W_t1JMxNrUfhkZfw1IoUl_HW ZycYf4GYmzMqGEGxWIpZV47vgGzwFZXsti8SLGcjC0163Btu96HtX76_IrkPiTWAML1lMNCLD.7B TKn35S_EkJcEWKa2aKZWPpLdowoearfjpVzmI3fAEAB6kc0aWAjPScdW_Vo0rpEeMs75UihSQ_lJ 9fvR40OC4WQReko2QzOcBLZEy0y5CVi3DI6Zuke_idECCBFYbGQA437wBLeeVva9GgZ6hQ55hfnq U4PICdcGo2aKvQfVTxkT9TKZITKUyX5Q6akI9eAAjheZo0hOB8nLAElIyRm6bpV81oKALM72fXqK upeUIa9FBR.Pz4gNiGe46qKo29YdeuDNVd8XvoHCOJi0to_2KCWNI5bAJe.8XGzdd068s5Ya0eie OxNbpMveLEPgVFPA7TpLhkt7TW0zfvQROV01KfbAhcuo4KdpMur2.VFkE4UKpo3O9pGP58w.FJVd kld.eHWNlbvIueyZoV7_ACzm_Ky8EtBXCoQVWvjqtANkw3TgJHIM9DVmWrZlnRrQfoibXjNKumPs 0gYK9q3PTKxakckf97kR0J5IV25h2cla6enuFg5h.aYFT650WuK4y.nh31JjVz6fTeVqw_tSuo3_ 3xEYbIWQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 5 Aug 2018 05:56:47 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f42172f39cd05764f7365aa87bbc5a86; Sun, 05 Aug 2018 05:56:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180805014545.GK2884@funkthat.com> Date: Sat, 4 Aug 2018 22:56:42 -0700 Cc: Jamie Landeg-Jones , bob prohaska , freebsd-arm , markj@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> <20180805014545.GK2884@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 05:56:56 -0000 On 2018-Aug-4, at 6:45 PM, John-Mark Gurney wrote: > Mark Millard wrote this message on Sat, Aug 04, 2018 at 09:08 -0700: >> On 2018-Aug-4, at 7:08 AM, John-Mark Gurney = wrote: >>=20 >>> Mark Millard via freebsd-arm wrote this message on Sat, Aug 04, 2018 = at 00:14 -0700: >>>> On 2018-Aug-3, at 8:55 PM, Jamie Landeg-Jones wrote: >>>>=20 >>>>> Mark Millard wrote: >>>>>=20 >>>>>> If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient >>>>>> additional RAM, I'd would have guessed that some Active Real = Memory >>>>>> should then have been paged/swapped out and so RAM would be made >>>>>> available. (This requires the system to have left itself = sufficient >>>>>> room in RAM for that guessed activity.) >>>>>>=20 >>>>>> But I'm no expert at the intent or actual operation. >>>>>>=20 >>>>>> Bob P.'s reports (for having sufficient swap space) >>>>>> also indicate the likes of: >>>>>>=20 >>>>>> v_free_count: 5439, v_inactive_count: 1 >>>>>>=20 >>>>>>=20 >>>>>> So all the examples have: "v_inactive_count: 1". >>>>>> (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt=3D=3D1 ) >>>>>=20 >>>>> Thanks for the feedback. I'll do a few more runs and other stress = tests >>>>> to see if that result is consistent. I'm open to any other idea = too! >>>>>=20 >>>>=20 >>>> The book "The Design and Implementation of the FreeBSD Operating = System" >>>> (2nd edition, 2014) states (page labeled 296): >>>>=20 >>>> QUOTE: >>>> The FreeBSD swap-out daemon will not select a runnable processes to = swap >>>> out. So, if the set of runnable processes do not fit in memory, the >>>> machine will effectively deadlock. Current machines have enough = memory >>>> that this condition usually does not arise. If it does, FreeBSD = avoids >>>> deadlock by killing the largest process. If the condition begins to = arise >>>> in normal operation, the 4.4BSD algorithm will need to be restored. >>>> END QUOTE. >>>>=20 >>>> As near as I can tell, for the likes of rpi3's and rpi2's, the = condition >>>> is occurring during buildworld "normal operation" that tries to use = the >>>> available cores to advantage. (Your context does not have the I/O >>>> problems that Bob P.'s have had in at least some of your OOM = process >>>> kill examples, if I understand right.) >>>>=20 >>>> (4.4BSD used to swap out the runnable process that had been = resident >>>> the longest, followed by the processes taking turns being swapped = out. >>>> I'll not quote the exact text about such.) >>>>=20 >>>> So I guess the question becomes, is there a reasonable way to = enable >>>> the 4.4BSD style of "Swapping" for "small" memory machines in order = to >>>> avoid having to figure out how to not end up with OOM process kills >>>> while also not just wasting cores by using -j1 for buildworld? >>>>=20 >>>> In other words: enable swapping out active RAM when it eats nearly >>>> all the non-wired RAM. >>>>=20 >>>> But it might be discovered that the performance is not better than >>>> using fewer cores during buildworld. (Experiments needed and >>>> possibly environment specific for the tradeoffs.) Avoiding having >>>> to figure out the maximum -j? that avoids OOM process kills but >>>> avoids just sticking to -j1 seems and advantage for some rpi3 and >>>> rpi2 folks. >>>=20 >>> Interesting observation, maybe playing w/: >>> vm.swap_idle_threshold2: Time before a process will be swapped out >>> vm.swap_idle_threshold1: Guaranteed swapped in time for a process >>>=20 >>> will help thing... lowering 2 will likely make the processes = available >>> for swap sooner... >>=20 >> Looking up related information: >>=20 >> https://www.freebsd.org/doc/handbook/configtuning-disk.html >>=20 >> says vm.swap_idle_enabled is also involved with those two. In fact >> it indicates the two are not even used until vm.swap_idle_enabled=3D1 = . >>=20 >> QUOTE >> 11.10.1.4. vm.swap_idle_enabled >> The vm.swap_idle_enabled sysctl(8) variable is useful in large = multi-user systems with many active login users and lots of idle = processes. Such systems tend to generate continuous pressure on free = memory reserves. Turning this feature on and tweaking the swapout = hysteresis (in idle seconds) via vm.swap_idle_threshold1 and = vm.swap_idle_threshold2 depresses the priority of memory pages = associated with idle processes more quickly then the normal pageout = algorithm. This gives a helping hand to the pageout daemon. Only turn = this option on if needed, because the tradeoff is essentially pre-page = memory sooner rather than later which eats more swap and disk bandwidth. = In a small system this option will have a determinable effect, but in a = large system that is already doing moderate paging, this option allows = the VM system to stage whole processes into and out of memory easily. >> END QUOTE >>=20 >> The defaults seem to be: >>=20 >> # sysctl vm.swap_idle_enabled vm.swap_idle_threshold1 = vm.swap_idle_threshold2 >> vm.swap_idle_enabled: 0 >> vm.swap_idle_threshold1: 2 >> vm.swap_idle_threshold2: 10 >>=20 >> Quoting the book again: >>=20 >> QUOTE >> If the swapping of idle processes is enabled and the pageout daemon = can find any >> processes that have been sleeping for more than 10 seconds = (swap_idle_threshold2, >> the cutoff for considering the time sleeping to be "a long time"), it = will swap >> them all out. [. . .] if none of these processes are available, the = pageout >> daemon will swap out all processes that has been sleeping for as = briefly as 2 >> seconds (swap_idle_threshold1). >> END QUOTE. >>=20 >> I'd not normally expect a compile or link to sleep for such long = periods >> (unless I/O has long delays). Having, say, 4 such processes active at = the >> same time may be unlikely to have any of them swap out on the default = scale. >> (Clang is less I/O bound and more memory bound than GCC as I remember = what >> I've observed. That statement ignores paging/swapping by the system.) >>=20 >> Such would likely be true on the scale of any positive integer = seconds >> figures? >=20 > The point is to more aggressively swap out OTHER processes so that > there is more memory available. I guess I'm relying on what I've seen in top to indicate that most all of the space from other processes has been paged out: not much of Active is for non-compiles/non-links during the problem times. For example, in = http://www.catflap.org/jamie/rpi3/rpi3-mmc-swap-failure-stats.txt it lists (last before the kill): last pid: 30806; load averages: 4.05, 4.04, 4.00 up 0+02:03:06 = 10:39:59 42 processes: 5 running, 37 sleeping CPU: 88.5% user, 0.0% nice, 6.1% system, 0.4% interrupt, 5.0% idle Mem: 564M Active, 2M Inact, 68M Laundry, 162M Wired, 97M Buf, 104M Free Swap: 4G Total, 76M Used, 4G Free, 1% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 30762 root 1 101 0 175M 119M CPU2 2 0:39 99.07% c++ 30613 root 1 101 0 342M 191M CPU0 0 2:02 95.17% c++ 30689 root 1 101 0 302M 226M CPU3 3 1:28 94.48% c++ 22226 root 1 20 0 19M 2M select 0 0:31 0.00% = make 1021 root 1 20 0 12M 340K wait 2 0:07 0.00% sh Rule of thumb figures: 564M Active vs. RES for the 3 c++'s: 119M+191M+226M =3D 536M for the 3 c++'s. So: 564M - 536M =3D 28M (approx. active for other processes) It appears to me that some c++ would likely need to swap out given that this context lead to OOM kills. (It might be that this rule of thumb is not good enough for such judgments.) [Personally I normally limit myself to -jN figures that have N*512 = MiBytes or more on the board. -j4 on a rpi3 or rpi2 has only 4*256 MiBytes.] =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Aug 5 06:16:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DC4B106826B for ; Sun, 5 Aug 2018 06:16:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 046767E310 for ; Sun, 5 Aug 2018 06:16:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: iPHivfsVM1k_VcYQ0BUKzuQOblfzVSsXIK6.sHyYZOMoW3zpEEJR1b3Wn1LYGI0 8t8A8iw_wRIKRrhV7CzbD0VdewQtj4Mu6pFmGfHhujpZUpJJ4k5ZkXy5PNtZ_F2A3cUKl4nv.Zy_ meoh8JfrPRCjSqEkjG80QduYxmfGU4TtLavjnD2ueGC2uCh3QEsREVjEs0BpXmQ0brewnnZtRciZ sAOlc8Wz6m2Fnz4G_QGwBXy.RqDkjCWw9M9BZ_u46HrMo0w7sQh3bWZrlBKWWBqXZERP7tcKNUgj NHwR3zrAdCd7gh3o_2KTfiIz_kW9ezLhqu_bjeDtzwPAd1r49uyyJm_7YeQd3LlhUzaDAt71RuHW OGqeTFbFAdhC4ugRal5lDHH1SJR6j6GkKztszefcBQLYai1OFPYL2MV4KHRO.reLV6jzpIpo5gr_ S8dm_RFrINgmCcrAAe0LirheFFL9z7IWMvKvx73XJz8LLTvt68YE.0nY.CHLql.OZFAJ.fW7ICNa vqc6eFSDOhZQaGa1H2jLQBKEiCqWICPK.uJ6nTVN5cNpTdIaw2GUCRGjW4aWqYYBlJ9avWcuFoQq 5b_Yj0XhdJDlpbNu.4pKZhtk_Llf83fLHnLsJVHTcGcpxrLiKgMhbmcjn1zQiqdLyQw9.d5H2SLl 0S6tylUkTfjE.ti74dYg2UOPL178kv6q0NVjVD08ulQjeAJsgM3_PF.PnWApmUkoDyaO4ZJsJZry pGUsadOXADyY05PiXVdfnNP_Inn5BkmR6BCVf_VZ2OhbW7vFqV7ufB8DhejQyKmhKRMieAQvpahX o05dRBQqF9C9vvBnrXe_kRrbXRYJiQgPuvooYOBKSs5UaJE.pCoEqiIFJgnwUmupzezpHmRPLk9x GUa.APBuabdIc18tXwP.QOCd6HmlR3OegZ3Ab5lpi0apbCqmfAoMyIpxvU.r9xR056UjQO3T8XkM 7fdyq0LOxb_HrUphSf9oxglMyZmroXFqSNKmzTrs8ZCgQNrAYWKQJ8UDhou4gwTtD25wiPkFXbpl IO1kXXDd7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 5 Aug 2018 06:16:39 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e503cd0bcc35bee329e975763429041f; Sun, 05 Aug 2018 06:06:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> Date: Sat, 4 Aug 2018 23:06:29 -0700 Cc: freebsd-arm , bob prohaska Content-Transfer-Encoding: 7bit Message-Id: <1860359E-38E8-4341-B7CD-31CCC01CFAFC@yahoo.com> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> To: Jamie Landeg-Jones X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 06:16:46 -0000 On 2018-Aug-3, at 8:55 PM, Jamie Landeg-Jones wrote: > Mark Millard wrote: > >> If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient >> additional RAM, I'd would have guessed that some Active Real Memory >> should then have been paged/swapped out and so RAM would be made >> available. (This requires the system to have left itself sufficient >> room in RAM for that guessed activity.) >> >> But I'm no expert at the intent or actual operation. >> >> Bob P.'s reports (for having sufficient swap space) >> also indicate the likes of: >> >> v_free_count: 5439, v_inactive_count: 1 >> >> >> So all the examples have: "v_inactive_count: 1". >> (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt==1 ) > > Thanks for the feedback. I'll do a few more runs and other stress tests > to see if that result is consistent. I'm open to any other idea too! You may want to have your top's sorted by RESident memory use and to list swap info (despite difficulty using the specific numbers shown in the column), including for system processes: -wSores being involved. This may help with judgments about how likely adjusting the following might be able to help make notably more memory available: vm.swap_idle_enabled: 0 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Aug 5 06:44:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6801106A1FE for ; Sun, 5 Aug 2018 06:44:00 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 26646807D5 for ; Sun, 5 Aug 2018 06:44:00 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w756ghKA090906 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Aug 2018 23:42:43 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w756ghFd090905 for freebsd-arm@freebsd.org; Sat, 4 Aug 2018 23:42:43 -0700 (PDT) (envelope-from warlock) Date: Sat, 4 Aug 2018 23:42:42 -0700 From: John Kennedy To: freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180805064242.GB30738@phouka1.phouka.net> References: <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> <20180805014545.GK2884@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 06:44:00 -0000 On Sat, Aug 04, 2018 at 10:56:42PM -0700, Mark Millard via freebsd-arm wrote: > Rule of thumb figures: > 564M Active > vs. RES for the 3 c++'s: > 119M+191M+226M = 536M for the 3 c++'s. > > So: 564M - 536M = 28M (approx. active for other processes) > > It appears to me that some c++ would likely need to swap out given that > this context lead to OOM kills. > > (It might be that this rule of thumb is not good enough > for such judgments.) > > [Personally I normally limit myself to -jN figures that have N*512 MiBytes > or more on the board. -j4 on a rpi3 or rpi2 has only 4*256 MiBytes.] For me, I generally pick a -j# initially based on the number of cores I have (sysctl -n hw.ncpu), scaling back a bit so the load is somewhere near that value. With virtual (hyperthreaded) cores, it'll probably be less. That appears to be about right for the RPI3B+ (4 real cores, so -j4, and my load average is ~4.15 over long periods of time). Typically less than 50M swapped out if top is to be believed. You'll either be CPU bound or I/O bound, which is what load is crudely trying to tell you. You don't want to be wasting time swapping when you could be writing out finished output. I'm not quite masochistic enough to spend all the time it would take to find out where the point of diminishing returns is for that. I think ZFS is doing nice things for me. I was concerned that it would be eating too much of my RAM, but I think that compression has been doing nice things for my I/O performance (particularly the SD card on the RPI3B+). From owner-freebsd-arm@freebsd.org Sun Aug 5 15:03:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D10210552EF for ; Sun, 5 Aug 2018 15:03:58 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DF8A92632 for ; Sun, 5 Aug 2018 15:03:57 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w75F2ZdZ092249 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Aug 2018 08:02:35 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w75F2Z4k092248 for freebsd-arm@freebsd.org; Sun, 5 Aug 2018 08:02:35 -0700 (PDT) (envelope-from warlock) Date: Sun, 5 Aug 2018 08:02:35 -0700 From: John Kennedy To: freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180805150235.GC30738@phouka1.phouka.net> References: <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804134015.GA30738@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180804134015.GA30738@phouka1.phouka.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 15:03:58 -0000 On Sat, Aug 04, 2018 at 06:40:15AM -0700, John Kennedy wrote: > For what it's worth, when I was first getting my rpi3 up and running, tuning > swap and rebuilding world+kernel it really seemed to favor killing off ntpd > and then usually a cc during the build (which resulted in a recoverable fail > as I had to restart the build process with NO_CLEAN=yes. > > This was using 12-current kernels. Bumping /tmp (tmpfs) up to 75M (from 50) > and having a proper freebsd-swap (vs swap-on-UFS-file) (and perhaps a V30 SD > card) fixed all of that. I still have to set TMPDIR=/var/tmp (disk, not > tmpfs) during installworld beacuse it tries to strip at least one really big > executable during the install and that'll break with <= 75M of /tmp. Hmm. Not perfect even now. Hit during buildworld with all sources/objects are local (vs NFS-mounted), intended to tweak out this experience for me. Aug 5 01:34:24 rpi3 kernel: pid 63223 (ld.lld), uid 0, was killed: out of swap space Aug 5 01:34:26 rpi3 kernel: pid 63360 (c++), uid 0, was killed: out of swap space Aug 5 01:34:26 rpi3 kernel: pid 846 (ntpd), uid 123, was killed: out of swap space In theory, I have lots of swap (via top) Swap: 7174M Total, 25M Used, 7149M Free, 16K In It varies a bit depending on the kernel, but I haven't adjusted for this particular warning: rpi3 kernel: warning: total configured swap (1946624 pages) exceeds maximum recommended amount (918256 pages). rpi3 kernel: warning: increase kern.maxswzone or reduce amount of swap. So far those have always been somewhere north of 3G: [kernel 12-CURRENT] r336739 -> maximum recommended amount (918488 pages). r336795 -> maximum recommended amount (918488 pages). r336962 -> maximum recommended amount (918256 pages). # gpart show mmcsd0s2 => 0 124624896 mmcsd0s2 BSD (59G) 0 83886080 1 freebsd-zfs (40G) 83886080 25165824 2 freebsd-ufs (12G) 109051904 15572992 4 freebsd-swap (7.4G) So 15572992 512-byte sectors -> 7604MiB -> ~7.42GiB, so that checks out. For swap, 15572992 512-byte sectors is 1946624 4K pages (presumably), so 918256 -> ~3.5GiB as a recommended swap value. Not sure why top shows 7174M. I know I can do a buildworld on my ~1GiB RAM/~2GiB swap amd64 droplet, so that should be excessive swap for the arm64. Of course, I'm not expecting any -j# buildworld to be exactly reproducible where swap comes into play. From owner-freebsd-arm@freebsd.org Sun Aug 5 16:16:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05FE01056DE1 for ; Sun, 5 Aug 2018 16:16:21 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9E7B7948BF for ; Sun, 5 Aug 2018 16:16:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 62ADF1056DE0; Sun, 5 Aug 2018 16:16:20 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 516C31056DDF for ; Sun, 5 Aug 2018 16:16:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF33D948BE for ; Sun, 5 Aug 2018 16:16:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1fmLhL-000637-TX for arm@freebsd.org; Sun, 05 Aug 2018 19:16:03 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: what boot stuff changed over the weekend? Message-Id: <591982C3-EDAF-4C38-8284-29373AF4C75E@cs.huji.ac.il> Date: Sun, 5 Aug 2018 19:16:03 +0300 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 16:16:21 -0000 hi, with last Friday=E2=80=99s update (sorry don=E2=80=99t have the = revision) I finally managed to compile an overlay for the nano-pi neo exposing the uarts and i2c=E2=80=99s, = they appeared in /dev ok, haven=E2=80=99t tested yet if they actually work. but today, after updating to rev 337349. the boot fails: [=E2=80=A6] Release APs mmc0: ACMD42 failed, RESULT: 4 mmc0: Card at relative address 7 failed to set bus width uhub1: 1 port with 1 removable, self powered Root mount waiting for: usbus5 usbus4 usbus3 usbus2 usbus0 uhub3: 1 port with 1 removable, self powered uhub5: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered uhub4: 1 port with 1 removable, self powered Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ? List of GEOM managed disk devices: diskid/DISK-004EDEF0s2a ufsid/5b644915c122eb94a diskid/DISK-004EDEF0s2 = diskid/DISK-004EDEF0s1 ufsid/5b644915c122eb94 mmcsd0s2a = msdosfs/MSDOSBOOT diskid/DISK-004EDEF0 mmcsd0s2 mmcsd0s1 mmcsd0 mountroot> ufs:mmcsd0s2a Trying to mount root from ufs:mmcsd0s2a []=E2=80=A6 and now it continues ok. I tried adding nfs.root.mountfrom=3Dufs:mmcsd0s2a to loader.conf but = that did not help so what=E2=80=99s going on? of course not loading the overlay works fine :-( cheers, danny From owner-freebsd-arm@freebsd.org Sun Aug 5 17:39:37 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E57CA1058ABC for ; Sun, 5 Aug 2018 17:39:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-4.consmr.mail.bf2.yahoo.com (sonic301-4.consmr.mail.bf2.yahoo.com [74.6.129.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72C8A96E32 for ; Sun, 5 Aug 2018 17:39:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 36haaoYVM1nr4uYulbk2fgBLlXm4bB6.vZEO0z9qMm_Eu5MQkmvSFhZRC53.H2Z EZrqBg3u9tcXmKL6R8Vh3N6cn6jEHgA.0We.FLGlRSb.2p8uWKkeq5evwpeYCeGnRQofafg1IZTa K91ghR4Ev7B_.Fy0_L9uLkdO6QsoKpz2r91UXMTSbb4TYB0qWaidK5ou5J2NOpAJzkIFNHaVINpy eVBj8IQL1pTa9W_Qkba3VIyduDT_2MKbZiAurVigQ.EIvOBDvyRZIoAHMqHbpiNTlzEfH9OVxTuz Dpvmq3gmjUUUkYyhDLoSpFiPU31nm0OdxopqezQ_jhdOMZZx7ogZ_5vcPDOcjorxTMeUilwLWIno nUIs8fDTcPnxHJ5lM3Z0eb0LaRfwrXXjhKzqLifVWTDjyXEWQOd6ehuUhQwnLsKj70XV_bSKrUoY UOKN2vgKg5iqqfPrrCcs6niXlbwUNYIj_540ZMkULeXLTfCHakZM53_qOLnwtlSxJNEqHml28nQD 1Mw2JjAghoqqGq1XwPreYI5PMGSLdxb5A1OdZDU568UqxxKITEiixGl16y5LpbndzwxBPWrTkV3y udtj3NF71lgk1RN0KziSHmhariGVoRWFTATLa7TSWsnhujS3.62fsgsT1PHV_ma2kfBBzIksZ3BA AgXzCkEA4gjtEMmqvCOENKPtH5I_Qj2wlQg9RR6KF3VQEg4aKsmLU.fwSus37B4bS8YNV93vQm60 m9BL7mFUX_T0r_9EelBgBcF.RZO1ue1svBcooM5ilnZk3.5PnITQX2Yx6HolVNJaEKf4IB9PacJn y0QqldQbso_L2RbI1mTxyX4oy0WhCaHNFoY8qUNu6D8vcFM_5xWW3X2GeGpKrefaLJMuVc84mp7q u7Oyb1bfKH7ptxW7y9ccAlFp1ewMMO6OqLogFbGLQDRtjCNCuE989ul2Yp2FLLK6tPbtq2aaT8ti TcDUUG_P8ugSqsAvBGYtVP7mtE.PmxV4LsjNmWtuZAS9Vy9kAAHCcSDZT_EyaD2e8YvXthW5zoKl ErSS8NiWgyBL6vJfMgA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Sun, 5 Aug 2018 17:39:30 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7cc95922125d14cbe2caa21358a1b71b; Sun, 05 Aug 2018 17:39:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180805014545.GK2884@funkthat.com> Date: Sun, 5 Aug 2018 10:39:27 -0700 Cc: Jamie Landeg-Jones , bob prohaska , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2C0383B0-3292-48BE-90BC-24FCF2A137D4@yahoo.com> References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> <20180805014545.GK2884@funkthat.com> To: John-Mark Gurney , markj@freebsd.org, Warner Losh X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 17:39:37 -0000 [I think the messages produced for OOM kills are misleading for the type of context in this message exchange. More bottom-posted.] On 2018-Aug-4, at 6:45 PM, John-Mark Gurney wrote: Mark Millard wrote this message on Sat, Aug 04, 2018 at 09:08 -0700: > On 2018-Aug-4, at 7:08 AM, John-Mark Gurney = wrote: >=20 >> Mark Millard via freebsd-arm wrote this message on Sat, Aug 04, 2018 = at 00:14 -0700: >>>> . . . >>>=20 >>> The book "The Design and Implementation of the FreeBSD Operating = System" >>> (2nd edition, 2014) states (page labeled 296): >>>=20 >>> QUOTE: >>> The FreeBSD swap-out daemon will not select a runnable processes to = swap >>> out. So, if the set of runnable processes do not fit in memory, the >>> machine will effectively deadlock. Current machines have enough = memory >>> that this condition usually does not arise. If it does, FreeBSD = avoids >>> deadlock by killing the largest process. If the condition begins to = arise >>> in normal operation, the 4.4BSD algorithm will need to be restored. >>> END QUOTE. >>>=20 >>> As near as I can tell, for the likes of rpi3's and rpi2's, the = condition >>> is occurring during buildworld "normal operation" that tries to use = the >>> available cores to advantage. (Your context does not have the I/O >>> problems that Bob P.'s have had in at least some of your OOM process >>> kill examples, if I understand right.) >>>=20 >>> (4.4BSD used to swap out the runnable process that had been resident >>> the longest, followed by the processes taking turns being swapped = out. >>> I'll not quote the exact text about such.) >>>=20 >>> So I guess the question becomes, is there a reasonable way to enable >>> the 4.4BSD style of "Swapping" for "small" memory machines in order = to >>> avoid having to figure out how to not end up with OOM process kills >>> while also not just wasting cores by using -j1 for buildworld? >>>=20 >>> In other words: enable swapping out active RAM when it eats nearly >>> all the non-wired RAM. >>>=20 >>> But it might be discovered that the performance is not better than >>> using fewer cores during buildworld. (Experiments needed and >>> possibly environment specific for the tradeoffs.) Avoiding having >>> to figure out the maximum -j? that avoids OOM process kills but >>> avoids just sticking to -j1 seems and advantage for some rpi3 and >>> rpi2 folks. The book's description makes the messages produced misleading: (copied from someone else's message) Aug 5 01:34:24 rpi3 kernel: pid 63223 (ld.lld), uid 0, was = killed: out of swap space Aug 5 01:34:26 rpi3 kernel: pid 63360 (c++), uid 0, was killed: = out of swap space Aug 5 01:34:26 rpi3 kernel: pid 846 (ntpd), uid 123, was = killed: out of swap space "out of swap space" would appear to apply to the 4.4BSD style of = swapping but not necessarily to more modern FreeBSD's context. "Total Active Working Set too large" (with lots of swap left) seems to = be what folks are running into in these rpi3/rpi2 examples. If the messages had indicated such, this message chain would likely have = been rather different: working out adjustments of the total active working = set size. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Aug 5 21:00:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E6F7105DE62 for ; Sun, 5 Aug 2018 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A15DE77A15 for ; Sun, 5 Aug 2018 21:00:33 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id C4FDAA425 for ; Sun, 5 Aug 2018 21:00:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w75L0W8I033424 for ; Sun, 5 Aug 2018 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w75L0WFg033419 for freebsd-arm@FreeBSD.org; Sun, 5 Aug 2018 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201808052100.w75L0WFg033419@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 5 Aug 2018 21:00:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 21:00:34 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 220297 | arch(7) rename arm64 to aarch64 respecting `uname 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Sun Aug 5 21:49:29 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C75DC105FC41 for ; Sun, 5 Aug 2018 21:49:29 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECBC779CFE for ; Sun, 5 Aug 2018 21:49:28 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w75LnIZr067214 for ; Mon, 6 Aug 2018 07:49:19 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: freebsd-arm References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> <20180805014545.GK2884@funkthat.com> <2C0383B0-3292-48BE-90BC-24FCF2A137D4@yahoo.com> From: Trev Message-ID: Date: Mon, 6 Aug 2018 07:49:18 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <2C0383B0-3292-48BE-90BC-24FCF2A137D4@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Mon, 06 Aug 2018 07:49:19 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 21:49:30 -0000 Mark Millard via freebsd-arm wrote on 08/06/18 03:39: > [I think the messages produced for OOM kills are misleading for > the type of context in this message exchange. More bottom-posted.] [CHOMP] > The book's description makes the messages produced misleading: > (copied from someone else's message) >=20 > Aug 5 01:34:24 rpi3 kernel: pid 63223 (ld.lld), uid 0, was killed: ou= t of swap space > Aug 5 01:34:26 rpi3 kernel: pid 63360 (c++), uid 0, was killed: out o= f swap space > Aug 5 01:34:26 rpi3 kernel: pid 846 (ntpd), uid 123, was killed: out = of swap space >=20 > "out of swap space" would appear to apply to the 4.4BSD style of swappi= ng but > not necessarily to more modern FreeBSD's context. >=20 > "Total Active Working Set too large" (with lots of swap left) seems to = be what folks > are running into in these rpi3/rpi2 examples. >=20 > If the messages had indicated such, this message chain would likely hav= e been > rather different: working out adjustments of the total active working s= et size. Indeed - I was running into "out of swap" on an amd64 VM with 512M=20 memory and 512M swap (source upgrade from 11.1R to 11.2R) just=20 yesterday, so I tried a few experiments which included a swap partition=20 of 256M and that produced lost of these "real" out of swap messages that = are never seen with the RPi3: Aug 5 17:54:01 sentinel kernel: swap_pager_getswapspace(32): failed Aug 5 17:54:02 sentinel last message repeated 4 times Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(25): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(20): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(18): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(17): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(18): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(15): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(32): failed Aug 5 17:54:01 sentinel kernel: swap_pager_getswapspace(32): failed Aug 5 17:54:02 sentinel last message repeated 4 times Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(25): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(20): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(18): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(17): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(18): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(15): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(32): failed Aug 5 17:54:01 sentinel kernel: swap_pager_getswapspace(32): failed Aug 5 17:54:02 sentinel last message repeated 4 times Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(25): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(20): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(18): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(17): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(18): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(15): failed Aug 5 17:54:03 sentinel kernel: swap_pager_getswapspace(32): failed =2E.. before finally: Aug 5 17:55:04 sentinel kernel: pid 81586 (llvm-tblgen), uid 0, was=20 killed: out of swap space Aug 5 17:55:37 sentinel kernel: pid 80923 (llvm-tblgen), uid 0, was=20 killed: out of swap space Aug 5 17:55:44 sentinel kernel: pid 79998 (make), uid 0, was killed:=20 out of swap space From owner-freebsd-arm@freebsd.org Sun Aug 5 22:26:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B62EC10609BE for ; Sun, 5 Aug 2018 22:26:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4863C7B06D for ; Sun, 5 Aug 2018 22:26:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 93D84B18E for ; Sun, 5 Aug 2018 22:26:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w75MQAmp091500 for ; Sun, 5 Aug 2018 22:26:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w75MQAIE091497 for freebsd-arm@FreeBSD.org; Sun, 5 Aug 2018 22:26:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220297] arch(7) rename arm64 to aarch64 respecting `uname -p` making room for more in future Date: Sun, 05 Aug 2018 22:26:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: cc bug_status resolution 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 22:26:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220297 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian@FreeBSD.org Status|New |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Aug 5 23:15:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AE141061A6C for ; Sun, 5 Aug 2018 23:15:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D567D7C904 for ; Sun, 5 Aug 2018 23:14:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w75NF9VI016711 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Aug 2018 16:15:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w75NF8W9016710; Sun, 5 Aug 2018 16:15:08 -0700 (PDT) (envelope-from fbsd) Date: Sun, 5 Aug 2018 16:15:08 -0700 From: bob prohaska To: Mark Millard Cc: John-Mark Gurney , markj@freebsd.org, Warner Losh , Jamie Landeg-Jones , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180805231508.GA12753@www.zefox.net> References: <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> <20180805014545.GK2884@funkthat.com> <2C0383B0-3292-48BE-90BC-24FCF2A137D4@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2C0383B0-3292-48BE-90BC-24FCF2A137D4@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 23:15:00 -0000 On Sun, Aug 05, 2018 at 10:39:27AM -0700, Mark Millard wrote: > > "Total Active Working Set too large" (with lots of swap left) seems to be what folks > are running into in these rpi3/rpi2 examples. > > Does the size of the working set vary with how the swap is apportioned between storage devices? In my observations, 1 GB plus 2 GB swap partitions both on microSD allows a -j4 buildworld to run to completion without OOMA intervention. It looks as if both partitions are burdened equally, so usable swap is actually 2 GB. A pair of 1 GB swap partitions, one on microSD and one on USB flash, invites OOMA to intervene prematurely. Stranger still, 1 GB of swap on microSD, which is insufficient (~1.4 GB required), does not trigger OOMA at all, resulting in a hung system. The RPi3 right now has three swap partitions; one of 1 GB on microSD, one of 2 GB on microSD and one of 1 GB on USB. Might it shed any light to try sysctl vm.swap_idle_enabled=1 just to see if anything changes? My guess is no, but it wouldn't be the first time if I'm wrong. 8-) Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Mon Aug 6 01:43:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F9441065BA2 for ; Mon, 6 Aug 2018 01:43:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.ne1.yahoo.com (sonic314-21.consmr.mail.ne1.yahoo.com [66.163.189.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94EC181470 for ; Mon, 6 Aug 2018 01:43:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VVlMsmAVM1k5YIsL4zmk_XoQXvQUUWCUkaBReByQfdoAktjmSDHDtwhzG1lZMrU QKBfvnjdY.i1Z1X.aPYcSszdp.6MOgRUT5kETzk_BfXgFlqvvc.uwD_7j41hzXNyPLPhPpM_pVfR GosDNysxAMLIyWoWW2_cdGzZqA3B2yHefJvxZRAlHfZKsf1mD27rlsbhfN8WrYF79CVra1tfXoGJ _.lCWsv5BiD3L7iQROT4NxhT2saO_sG3Uzsw88LVGEUsV.e3gEPDVdoS2mP8ZDEEB6Necl48jTu3 kguvTktWpg1Cp41c_F9zlW5YxOAfQhrhR1mh34Y50LBVdX4HIYkSfrnWjimK7K0T9TwN0MUCgv0f TagYLFzKfZ0ehYJu1Qhz5isR5fVGd37gsbugRk1sw_uUITJxT3ChvF9dzsMhmzagHolZZUh5zAVU 9OrQ6Vo68wzZ9XiaCJkUQHsNYo5LjictdXLqOpHSvzCbUgWhJrtF0im3s9lN8xFcbxC51hCIvf3w oa.FeB9hEjRYZXq3v_Am0zgarifSdtXqaizMTKfR52rBr_L7hUktnVYNzzj1ZWmNeFobVUMm4E5L E_6xL.22SoaD0UtOr21ua4pLULt7s3HQtmd3mdy4FumkrKPezT5BM0VxbuF8QN.aTEspZOq76arz 2USx.eOJtOsVhLg5oP0G4x77foKejjBr9GOiTbqY0oHw0ATY4NF66SZGwh0gkZrmAvgxg1OCF09Y c4RLrxXdNR0KkoeR06H4Q_cRVM5VCoKfWaTe1qhpLKM.qJE4PbDIBzgdkJP3BUhBU1u.bwcE24.v 2dYHc3XYd0cEmN.yxxaadsNV28knenpItTy9L3tTgS8GMTXJ1bRiK_z.YJqQYkbJc32CwuJD3e_m TQv4vOh8DA7oqvSrOl7O0ofFs9LfOGWPIuy38qhMvZobMksyYus1pBRIMVY6DTDhyVch417MXDqY vbpWm6wrpd6gv5v67eDSG4T7eZ_JZm43fu2vP0OvBIp04zgo2sWK1sX.1BoyMW.pDEwcgudL7no8 xx4nqFAtbbFbb Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Mon, 6 Aug 2018 01:43:49 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8d322980fb85c58131395b33268e8a82; Mon, 06 Aug 2018 01:43:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180805231508.GA12753@www.zefox.net> Date: Sun, 5 Aug 2018 18:43:46 -0700 Cc: John-Mark Gurney , markj@freebsd.org, Warner Losh , Jamie Landeg-Jones , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> <20180805014545.GK2884@funkthat.com> <2C0383B0-3292-48BE-90BC-24FCF2A137D4@yahoo.com> <20180805231508.GA12753@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 01:43:51 -0000 On 2018-Aug-5, at 4:15 PM, bob prohaska wrote: > On Sun, Aug 05, 2018 at 10:39:27AM -0700, Mark Millard wrote: >>=20 >> "Total Active Working Set too large" (with lots of swap left) seems = to be what folks >> are running into in these rpi3/rpi2 examples. >>=20 >>=20 > Does the size of the working set vary with how the swap is apportioned = between > storage devices? In my observations, 1 GB plus 2 GB swap partitions = both on microSD=20 > allows a -j4 buildworld to run to completion without OOMA = intervention. It looks as > if both partitions are burdened equally, so usable swap is actually 2 = GB. The less memory in use for other things (especially less wired memory), the more for the working set. The overallocation of swap beyond the maximum recommended might have some contribution to how much the working set can be. But I've no clue of any specific tradeoffs. Describing 2 or 3 in-use swap partitions instead of just one might. But, again, I've no clue of any specific tradeoffs. > A pair of 1 GB swap partitions, one on microSD and one on USB flash, = invites OOMA=20 > to intervene prematurely. As I remember you have examples that involve only one device and, separately, you have some problematic devices. Others seem to have avoided some of the complications: They got the problem in simpler contexts. > Stranger still, 1 GB of swap on microSD, which is insufficient (~1.4 = GB required),=20 > does not trigger OOMA at all, resulting in a hung system. Part of the problem is that messages like: (taken from a John Kennedy message) Aug 5 01:34:24 rpi3 kernel: pid 63223 (ld.lld), uid 0, was = killed: out of swap space Aug 5 01:34:26 rpi3 kernel: pid 63360 (c++), uid 0, was killed: = out of swap space Aug 5 01:34:26 rpi3 kernel: pid 846 (ntpd), uid 123, was = killed: out of swap space are misleading: the issue is not necessarily "out of swap space" but what the book described (when there is lots of swap around): QUOTE: The FreeBSD swap-out daemon will not select a runnable processes to swap out. So, if the set of runnable processes do not fit in memory, the machine will effectively deadlock. Current machines have enough memory that this condition usually does not arise. If it does, FreeBSD avoids deadlock by killing the largest process. If the condition begins to = arise in normal operation, the 4.4BSD algorithm will need to be restored. END QUOTE. (The 4.4BSD algorithm is not in use [or even present].) The truly "out of swap space" context is explicitly different code doing different things (to some extent). Trev has reported that a message that can (sometimes?) be produced for this is like: Aug 5 17:54:01 sentinel kernel: swap_pager_getswapspace(32): failed (at least if it does not hang up first). "was killed: out of swap space" without prior "swap_pager_getswapspace(??): failed" notices look to not be trusted for the "out of" wording or its implications. > The RPi3 right now has three swap partitions; one of 1 GB on microSD, = one > of 2 GB on microSD and one of 1 GB on USB. Might it shed any light to = try=20 > sysctl vm.swap_idle_enabled=3D1 > just to see if anything changes? My guess is no, but it wouldn't be = the first=20 > time if I'm wrong. While I have expectation based on my understanding of what I've read (including some code) and seen in top, I think you should do such experiments if you are interested in taking the time. (The same goes for others with simpler contexts.) Doing so even for the "single device" type of context that showed the problem likely would be good to do as well. You might even want to see how it goes for a context that worked. ("Does it then still work?" is also good to know.) I continue to encourage you to use total swap space figures that are somewhat under what that message happens to be listing as the maximum at the time (if you are getting such messages). (You might well be doing so. I've not been monitoring for this.) Being "over the maximum recommended" just seems to be a complication of the context that is fairly easily avoided. There is already a lot involved. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 6 03:42:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 634C110681A5 for ; Mon, 6 Aug 2018 03:42:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-22.consmr.mail.ne1.yahoo.com (sonic315-22.consmr.mail.ne1.yahoo.com [66.163.190.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED6DC85150 for ; Mon, 6 Aug 2018 03:42:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Zm8guYIVM1lVHhR81p.iSA6EWRheC3MGYMRLnMnI25l3r1bojBk7Wg.l_Ar32Ge qwfdvei.3hO6B.O0elVBLb9w.YboeLclIakq76Jdxp5Zcedba3g5B._JGY7S5fSmgKKoAIj9KqQE XYxJvcycOaWJq2o8SDRUOckGgMtvKNVjH3N4o93fg.YlH8GGW3ETz3MV653k_t8ZGq4fR6zexDAF XJ7fXuH.XhuASSsMEHvlmny55.5V1WRsezHunQgKotAzvMduTC3vwhbH2hTTTV7QwH2EUadlv_rF Tvlx8QKSGd3ZrbSYu8myt_p0Ea2ihJifWhD0BsunJk935azntE9YN82aNmvZsOX368hy5vf8azzs IxxzBbQWYnf2c759TqsziyMbMVqiuf5nyZ0LGQhhnds9RLbwOlQTs9km9Y8wP6ZUj47y5BY6elb5 hE5AUgoW1K_Ph5YpECCNTJoNEJaF_dST.do2HKuqjni2WILxfymeYRPyMr_KOhjXNFl7Z65udPB8 nR2VxXSa4fxLplywuz7_0mcaEMPN2DItHhm.aD6PtML8jjSN4DDxMddb_dtdcSUYAAYW.cy9lQ0k sFAMev92XfJk0smHcSsU1fK9ct78LmvkjtbCYrzJs6n4VpPDkRiIkfFahFHp5ALInYSf4baom5F6 TF3VtO.0kotHeXdPTjxupVLlV6.loZD6UFE_8KEi7K7IqD4khzPISrcll215nnsTwyGH9npEASUq MTvYciD.OO6xqhed52H1kwr22J0npjlI0w02JYC22JEzy5v85pFB960owrH7u7MUOCCew1NbJRdS _BtyCipiHLx0I.zJfMI9dIdsFIXXUFHj1cwIu10tT_sig8LZBIcEDaTQRTXulzGQEd3R8cFRmraw gg3YmDGW3DoYXfn2J_ZLe6NQvSeJ_xTPAJtNLyBJ7prQMguVu7Zs03Fk8bAtJ4MGmdMD8_dgZCYb VwCekMUV.tvOoEVHntUttmYSjaftThXshoaW5JvPIZWhBG0otKMt8qmT3JzYY7arrnAPc9QA3qwJ x.g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Mon, 6 Aug 2018 03:42:48 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7685c95d08a1468d8f7e294e2fafb6e1; Mon, 06 Aug 2018 03:42:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: Date: Sun, 5 Aug 2018 20:42:44 -0700 Cc: John-Mark Gurney , markj@freebsd.org, Warner Losh , Jamie Landeg-Jones , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <16CB7D93-F6A8-4631-8082-E931A5029D61@yahoo.com> References: <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> <20180805014545.GK2884@funkthat.com> <2C0383B0-3292-48BE-90BC-24FCF2A137D4@yahoo.com> <20180805231508.GA12753@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 03:42:55 -0000 [I'm going a different direction here.] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230402 is a report for a 1 GiByte, 3 "cpu" virtual machine getting the message during buildworld on 11.2-STABLE: pid 9870 (c++), uid 0, was killed: out of swap space (It is not clear the time frame of the top and swapinfo information, but probably after buildworld had stopped.) Reported was: # swapinfo -m Device 1M-blocks Used Avail Capacity /dev/gpt/swap-ada0 1024 93 930 9% /dev/zvol/zroot/swap 1536 84 1451 6% Total 2560 177 2382 7% (So 2.5 GiBytes of swap total.) # uname -a FreeBSD core.domain.com 11.2-STABLE FreeBSD 11.2-STABLE #0 r337132: Thu = Aug 2 17:54:09 UTC 2018 =20 root@releng2.nyi.freebsd.org :/usr/obj/usr/src/sys/GENERIC amd64 ZFS was in use, complicating things. Still, this does suggest another type of test that might isolate various issues: small virtual machine configurations of a tier-1 architecture, such as amd64. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 6 04:22:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3D6B1068E00 for ; Mon, 6 Aug 2018 04:22:40 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6201486436 for ; Mon, 6 Aug 2018 04:22:40 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w764LNTU093744 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Aug 2018 21:21:23 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w764LMkh093743 for freebsd-arm@freebsd.org; Sun, 5 Aug 2018 21:21:22 -0700 (PDT) (envelope-from warlock) Date: Sun, 5 Aug 2018 21:21:22 -0700 From: John Kennedy To: freebsd-arm@freebsd.org Subject: usb-only rpi 3b+ (+UART foo) Message-ID: <20180806042122.GD30738@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 04:22:41 -0000 I'm trying to boot using only USB (no SD card). Seems like it should be easy. Booted up via my SD card with the USB drive attached, I can see and use it easily: # usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) --> ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) The RPI doesn't get the green boot-light or the rainbow screen. So low-level stuff is obviously AWOL. I've put program_usb_boot_mode=1 into the config.txt, but can't verify it with vcgencmd since that won't compile on arm64 (I haven't tried burning raspbian and seeing if they have a working port to verify). As a real disk, it's power light comes up delayed. It seems like it should be lit before 5-seconds, but I don't know if that is enough for the RPI to try and enumerate it. Currently I'm trying to divide and conquer by putting the MSDOS boot partition on an SD card and then boot USB off of that, or at least try to figure out what is wrong from there. So my USB console cable finally arrived and I plugged it in: kernel: ugen0.4: at usbus0 kernel: uslcom0 on uhub0 kernel: uslcom0: on usbus0 Connecting via this from my amd64 FreeBSD box: screen /dev/cuaU0 115200 It's dropping some characters, so hopefully I won't add typos: [usb reset] U-Boot> usb reset resetting USB... USB0: scanning bus 0 for devices... 5 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found U-Boot> usb start If anybody has some suggestions on how to get that cable to not murder the serial output (from the RPI), that would be helpful. The input (to RPI) seems totally fine looking at the HDMI console output, but what comes back is very spotty (lots of dropped characters, don't see mangling). In any case: Murdered info from usb info: 1: Hub (u-boot root hub) 2: Hub (vendor 0x0424, product 0x2514) 3: Hub (vendor 0x0424, product 0x2514) 4: Human interface (boot keyboard, boot mouse, should be the logitech) 5: vendor specific (vendor 0x0424, product 0x7800) So u-boot isn't even seeing my Samsung drive? [version] aarch64-none-elf-gcc (FreeBSD Ports Collection for aarch64noneelf) 6.4.0 GNU ld (GNU Binutils) 2.30 That (and it's supporting partition of files) should be from: FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180726-r336739.img [cat /boot/msdos/config.txt] arm_control=0x200 dtparam=audio=on,i2c_arm=on,spi=on dtoverlay=mmc dtoverlay=pwm dtoverlay=pi3-disable-bt device_tree_address=0x4000 kernel=u-boot.bin program_usb_boot_mode=1 enable_uart=1 From owner-freebsd-arm@freebsd.org Mon Aug 6 07:00:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E678110709DC for ; Mon, 6 Aug 2018 07:00:29 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D4DF8BE28 for ; Mon, 6 Aug 2018 07:00:28 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w7670OpW084216 for ; Mon, 6 Aug 2018 17:00:24 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: usb-only rpi 3b+ (+UART foo) To: freebsd-arm@freebsd.org References: <20180806042122.GD30738@phouka1.phouka.net> From: Trev Message-ID: <74185d99-25d3-a7d3-3569-f7f917298612@sentry.org> Date: Mon, 6 Aug 2018 17:00:24 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20180806042122.GD30738@phouka1.phouka.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Mon, 06 Aug 2018 17:00:24 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 07:00:30 -0000 John Kennedy wrote on 08/06/18 14:21: > I'm trying to boot using only USB (no SD card). Seems like it should be easy. > > Booted up via my SD card with the USB drive attached, I can see and use it easily: > > # usbconfig > ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) > ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) > ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) > ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) > ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) > --> ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > > The RPI doesn't get the green boot-light or the rainbow screen. So low-level > stuff is obviously AWOL. I've put program_usb_boot_mode=1 into the config.txt, > but can't verify it with vcgencmd since that won't compile on arm64 (I haven't > tried burning raspbian and seeing if they have a working port to verify). I didn't need to add anything to the config.txt file for my RPi2 to attempt to boot from USB instead of the micro-SD card. The SD card kept being assigned as disk2, with the USB memory keys taking up disk0 and disk1, and then the system would unsuccessfully try booting from disk0 and finding no kernel file as that happened to be the /usr file system. After much google-fu, the workaround I found was to halt the boot at the uboot loader prompt (you have two seconds) and then: setenv loaderdev disk2 saveenv boot The above creates a persistent uboot.env file, so no manual intervention is needed again (unless the number of USB memory keys changes). This might help in your situation with appropriate disk number tweak. > As a real disk, it's power light comes up delayed. It seems like it should be > lit before 5-seconds, but I don't know if that is enough for the RPI to try > and enumerate it. Currently I'm trying to divide and conquer by putting the > MSDOS boot partition on an SD card and then boot USB off of that, or at least > try to figure out what is wrong from there. I recall adding a 15 second delay (kern.cam.boot_delay="15000") in bootloader.conf.local to avoid USB memory device enumeration issues. > So my USB console cable finally arrived and I plugged it in: > > kernel: ugen0.4: at usbus0 > kernel: uslcom0 on uhub0 > kernel: uslcom0: on usbus0 > > Connecting via this from my amd64 FreeBSD box: > > screen /dev/cuaU0 115200 > > It's dropping some characters, so hopefully I won't add typos: [chomp] > If anybody has some suggestions on how to get that cable to not murder the > serial output (from the RPI), that would be helpful. The input (to RPI) seems > totally fine looking at the HDMI console output, but what comes back is very > spotty (lots of dropped characters, don't see mangling). In any case: [chomp] > [cat /boot/msdos/config.txt] > arm_control=0x200 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=pwm > dtoverlay=pi3-disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > > program_usb_boot_mode=1 > enable_uart=1 Did you add the enable_uart=1 too? I made no change to config.txt to get console output (and I am also using a Silicon Labs CP2102 USB to UART Bridge Controller on my RPi3B+). I had no dropped characters, using screen on macOS. [Sorry I can't check - I'm currently interstate for a few more days] From owner-freebsd-arm@freebsd.org Mon Aug 6 09:49:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6651D1051C9B for ; Mon, 6 Aug 2018 09:49:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEBEF716D5 for ; Mon, 6 Aug 2018 09:49:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zvqG_3gVM1nUMmsemFa92oYIdfcyo9OJu2b5SCNnRaj4cw5Ykw.kwL0caU7P6Bo M4Pd5_ADg4ww7tQfqIc5FETYDE84fRC6NOu6IU31TrBm3roWHKtDgmsGbV8g8lEQfGPaLsIkRfTq Hy_nwDQCoZ0GIak5iv0ZlrgdATu.h3WjGvir58dlM1VQNhCXRAO8ropNFMEXwQkHnoRnlgxZNtzk yJYdNrA691s2_W3ZY4glEfNTWaFgiBQrVKqlrgqTQp9_WtRouQL4nBTuU6qbxoWn5ThJg2kLP0v6 7Cl_TLnuWlzzxfa83UWWXrlJ57.diKer2Kji9yOdL6xPhsmITStfLSHm44vBtYNl4cDXDBHmw_uO 0nMQuj6e0CkAeO1NoHo3Jt2HlfQRTIyNvNLnJwnhMvPpXjYQYSpW0pSYs2OFVyk7.TJdCduJGG9d XlsBCSnZPiXI0.0StWdowv1Wc1VJ8eEx2LqG6A6xBRCMBKhx_5bEW78IA.H3nq1vFz1of5otWv0z hoJWAicTb4HTmBXOqj.6tiB0fn.Ei.5L59KD9FAcR5HQPbuN9Dm7NKBk0agWBQFZ3YyhI9fF17T9 cxlIG9wknXoGPBEWgp9hgHqVH9bjUojXL5UJl1X1j_Yp0PyqAY_HulxuC03T0LjIWDAArLr4m3y9 agSjYtmnOXz6wmuRa5Ky.Lsnv96VqXTId.s.MmmOBJM1Lo1aJdin4dnubj1puXkjKwvCS4xvfbpY Es.Fve.i_jF7Rkecm6KUgeYAvWEQoNXf3rbbAUEdRenw1R6s5p86atwFhmybCOx4knHDWJPw5ENX p7dosUFphWmJbrljjV2ahh8HuRmEtZH2To9ViyzJpS9mlJiL51QHHpTNps5DtX_PuUx1DUWAClIg U9d2eXIRlTaGOX_EAJFnzMJwy42eJY7PGKha_yxE.YR5_ibQxNQXzu70ZvK9Yq7H3CAix8H6rvJb yomT6A2s4I9uSTb9wOhY7Uurr7mK.K62PJbtWX2.vnQm_y.lQ1xmJk8wBA_XWMezhNSm127s- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 6 Aug 2018 09:49:04 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f772dc024a1c07a20db40990f96d1819 for ; Mon, 06 Aug 2018 09:48:59 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted Message-Id: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> Date: Mon, 6 Aug 2018 02:48:57 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:49:05 -0000 I amd64 -> aarch64 cross built -r337347 and installed it (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as bootaa64.efi) as an update. My attempted synchronization of loader.conf and ttys and devd.conf may be incorrect. (Previous to this the Pine64+ 2GB seemed to be working okay but it was at a very old build.) The kernel config has GENERIC included but the various debug features disabled. (My typical operating environment.) For all I know what the below shows might be expected at this point. The kernel seems to have problems with the MMC (that the kernel was loaded from). No other media are attached. mmcsd0 is really an 128 GiByte emmc on an adapter. (This historically worked for me.) Still, the below may give other general hints about the status of things for Pine64+ 2GB's. The serial console shows . . . U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... *** Warning - bad CRC, using default = environment Failed (-5) In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 3 disks 477384 bytes read in 25 ms (18.2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 40080000 ... Consoles: EFI console =20 FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi EFI version: 2.70 EFI Firmware: Das U-Boot (rev 0.00) Console: efi (0) Load Path: /\efi\boot\bootaa64.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) Setting currdev to disk0p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24= 400,0xe600000) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x8ce84a data=3D0x148020+0x72caac = syms=3D[0x8+0x11d000+0x8+0x1108a8] /boot/entropy size=3D0x1000 /boot/kernel/umodem.ko text=3D0x2168 text=3D0x1410 data=3D0x102d0+0xfd40 = syms=3D[0x8+0xf30+0x8+0xb73] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x47ffc000. EHCI failed to shut down host controller. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT r337347M arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) VT: init without driver. KLD file umodem.ko is missing dependencies Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface MAP 47fff000 mode 2 pages 1 MAP 48003000 mode 2 pages 1 MAP b8f20000 mode 2 pages 1 MAP bdfb9000 mode 2 pages 2 kbd0 at kbdmux0 ofwbus0: clk_fixed0: on ofwbus0 clk_fixed1: on ofwbus0 clk_fixed2: on ofwbus0 simplebus0: on ofwbus0 ccu_a64ng0: mem = 0x1c20000-0x1c203ff on simplebus0 iichb0: mem = 0x1c2b000-0x1c2b3ff irq 21 on simplebus0 iicbus0: on iichb0 regfix0: on ofwbus0 ccu_sun8i_r0: mem = 0x1f01400-0x1f014ff on simplebus0 psci0: on ofwbus0 gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 23 on simplebus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 gpio0: mem 0x1c20800-0x1c20bff irq = 12,13,14 on simplebus0 gpiobus0: on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 26 = on simplebus0 gpiobus1: on gpio1 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 rtc0: registered as a time-of-day clock, resolution 1.000000s awusbphy0: mem = 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 mmc0: on aw_mmc0 ehci0: mem 0x1c1b000-0x1c1b0ff = irq 10 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on = simplebus0 usbus1 on ohci0 gpioc0: on gpio0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on = simplebus0 uart0: console (115384,n,8,1) iic0: on iicbus0 gpioc1: on gpio1 syscon_generic0: mem 0x1c00000-0x1c00fff on simplebus0 awg0: mem 0x1c30000-0x1c3ffff irq 27 on = simplebus0 miibus0: on awg0 rgephy0: PHY 0 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow rgephy1: PHY 1 on = miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow awg0: Ethernet address: 02:ba:b1:c5:93:b7 cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 AW_MMC_INT_RESP_TIMEOUT=20 ugen0.1: at usbus0 AW_MMC_INT_RESP_TIMEOUT=20 uhub0: on = usbus0 ugen1.1: at usbus1 uhub1: on = usbus1 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_DATA_END_BIT_ERR AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: Failed to set VCCQ for card at relative address 2 uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered aw_mmc0: controller timeout aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 mmcsd0: Error reading EXT_CSD Timeout device_attach: mmcsd0 attach returned 6 Release APs...done Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]... CPU 0: ARM Cortex-A53 r0p4mountroot: waiting for device = /dev/ufs/PINE64P2Grootfs... affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Memory Model Features 2 =3D <32b CCIDX,48b VA> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19. Loader variables: vfs.root.mountfrom=3Dufs:/dev/ufs/PINE64P2Grootfs vfs.root.mountfrom.options=3Drw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ? List of GEOM managed disk devices: =20 mountroot>=20 The "M" in -r337347M is mostly for code tied to powerpc family experiments. (I try to have a single /usr/src/ code base.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 6 10:44:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EDFC1052FED for ; Mon, 6 Aug 2018 10:44:30 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCD1072AF6 for ; Mon, 6 Aug 2018 10:44:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 7bafa1ba; Mon, 6 Aug 2018 12:44:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=GR5XQdtGK9mkdionqYsqKohdWko=; b=J7H+Jm+GqzN7I0QEF08F0sueg/yq qSnqrXXqBaOgIt84mrFQt2h13vWOaCRpyepvEhut05P+oKepx2UWxZxgBMJWwxiv vXWlyaB640sgGx3GTmsJ/9pVM65NQChj7ALsBpD3fmoWzKyHm7uwzPy0G93Eop9y dnB8KZxegp9f5Uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=b9VNw3tpeaHsVONTSKuvCR+d2JM5qCuc36KGlJhmcHOV67yGDZTgoprg kFiFRZR2DxmWDLZh3NCEOIjAMftQaaZQvg3fNSFp+jywbkMz0WGnvxpiOStBiKtL QTW9nMZXnRKj7Kc3L8V2BG4sakb4GNlFA94qCBdXpdEm+wwHST8= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 25d8e745 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 6 Aug 2018 12:44:22 +0200 (CEST) Date: Mon, 6 Aug 2018 12:44:21 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Mark Millard via freebsd-arm Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted Message-Id: <20180806124421.0b622761272370d2946cac29@bidouilliste.com> In-Reply-To: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 10:44:30 -0000 On Mon, 6 Aug 2018 02:48:57 -0700 Mark Millard via freebsd-arm wrote: > I amd64 -> aarch64 cross built -r337347 and installed it > (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as > bootaa64.efi) as an update. My attempted synchronization > of loader.conf and ttys and devd.conf may be incorrect. > (Previous to this the Pine64+ 2GB seemed to be working > okay but it was at a very old build.) > > The kernel config has GENERIC included but the various > debug features disabled. (My typical operating > environment.) > > For all I know what the below shows might be expected > at this point. The kernel seems to have problems with > the MMC (that the kernel was loaded from). No other > media are attached. mmcsd0 is really an 128 GiByte > emmc on an adapter. (This historically worked for me.) emmc to sd ? that's weird ... Can you boot -v and post the result please ? > Still, the below may give other general hints about the > status of things for Pine64+ 2GB's. > > The serial console shows . . . > > U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000) > DRAM: 2048 MiB > Trying to boot from MMC1 > > > U-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology > > CPU: Allwinner A64 (SUN50I) > Model: Pine64+ > DRAM: 2 GiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default environment > > Failed (-5) > In: serial > Out: serial > Err: serial > Net: phy interface7 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0(part 0) is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disks on usb... > Disk usb0 not ready > Disk usb1 not ready > Disk usb2 not ready > Disk usb3 not ready > Scanning disks on mmc... > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 3 disks > 477384 bytes read in 25 ms (18.2 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > ## Starting EFI application at 40080000 ... > Consoles: EFI console > FreeBSD/arm64 EFI loader, Revision 1.1 > > Command line arguments: loader.efi > EFI version: 2.70 > EFI Firmware: Das U-Boot (rev 0.00) > Console: efi (0) > Load Path: /\efi\boot\bootaa64.efi > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0) > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0) > Setting currdev to disk0p1: > Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000) > Setting currdev to disk0p2: > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8] > /boot/entropy size=0x1000 > /boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x47ffc000. > EHCI failed to shut down host controller. > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT r337347M arm64 > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) > VT: init without driver. > KLD file umodem.ko is missing dependencies > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > random: entropy device external interface > MAP 47fff000 mode 2 pages 1 > MAP 48003000 mode 2 pages 1 > MAP b8f20000 mode 2 pages 1 > MAP bdfb9000 mode 2 pages 2 > kbd0 at kbdmux0 > ofwbus0: > clk_fixed0: on ofwbus0 > clk_fixed1: on ofwbus0 > clk_fixed2: on ofwbus0 > simplebus0: on ofwbus0 > ccu_a64ng0: mem 0x1c20000-0x1c203ff on simplebus0 > iichb0: mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0 > iicbus0: on iichb0 > regfix0: on ofwbus0 > ccu_sun8i_r0: mem 0x1f01400-0x1f014ff on simplebus0 > psci0: on ofwbus0 > gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 > gpio0: mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0 > gpiobus0: on gpio0 > gpio1: mem 0x1f02c00-0x1f02fff irq 26 on simplebus0 > gpiobus1: on gpio1 > generic_timer0: irq 0,1,2,3 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 > rtc0: registered as a time-of-day clock, resolution 1.000000s > awusbphy0: mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > aw_mmc0: mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0 > mmc0: on aw_mmc0 > ehci0: mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0 > usbus1 on ohci0 > gpioc0: on gpio0 > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0 > uart0: console (115384,n,8,1) > iic0: on iicbus0 > gpioc1: on gpio1 > syscon_generic0: mem 0x1c00000-0x1c00fff on simplebus0 > awg0: mem 0x1c30000-0x1c3ffff irq 27 on simplebus0 > miibus0: on awg0 > rgephy0: PHY 0 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > rgephy1: PHY 1 on miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > awg0: Ethernet address: 02:ba:b1:c5:93:b7 > cryptosoft0: > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 12Mbps Full Speed USB v1.0 > AW_MMC_INT_RESP_TIMEOUT > ugen0.1: at usbus0 > AW_MMC_INT_RESP_TIMEOUT > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_DATA_END_BIT_ERR > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > AW_MMC_INT_RESP_TIMEOUT > mmc0: Failed to set VCCQ for card at relative address 2 > uhub1: 1 port with 1 removable, self powered > uhub0: 1 port with 1 removable, self powered > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 > > mmcsd0: Error reading EXT_CSD Timeout > device_attach: mmcsd0 attach returned 6 > Release APs...done > Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]... > CPU 0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs... > affinity: 0 > Instruction Set Attributes 0 = > Instruction Set Attributes 1 = <> > Processor Features 0 = > Processor Features 1 = <0> > Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 = <> > Memory Model Features 2 = <32b CCIDX,48b VA> > Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8> > Debug Features 1 = <0> > Auxiliary Features 0 = <0> > Auxiliary Features 1 = <0> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > CPU 2: ARM Cortex-A53 r0p4 affinity: 2 > CPU 3: ARM Cortex-A53 r0p4 affinity: 3 > Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs > vfs.root.mountfrom.options=rw,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > > > mountroot> > > > > > The "M" in -r337347M is mostly for code tied to powerpc > family experiments. (I try to have a single /usr/src/ > code base.) > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Aug 6 14:46:14 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F205105B020 for ; Mon, 6 Aug 2018 14:46:14 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 366CB7AEFE for ; Mon, 6 Aug 2018 14:46:14 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533566765; bh=vMo2M83mT6q35PVUv8xMqPXP0sOL8YY0KTeBidG1xDw=; h=Subject:To:References:From:Date:In-Reply-To; b=LHlCchUnXBNWc697CTs4rvP+/1OUmtBxgo84ybTSMkDdlfwSoCtpmkiFmQdk8XWYk 0eflHYRe32a8MoKmAddZu8NEnX0qGktTFnkfvbhVLBnTvFtb55jp6MBdN2qRiBybBA Ce2U8fQ9AlLdgA6mQjDNRoA4BQuvokUdLRzHYLps= Subject: Re: usb-only rpi 3b+ (+UART foo) To: John Kennedy , freebsd-arm@freebsd.org References: <20180806042122.GD30738@phouka1.phouka.net> From: Per olof Ljungmark Message-ID: <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> Date: Mon, 6 Aug 2018 16:46:03 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180806042122.GD30738@phouka1.phouka.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 14:46:14 -0000 On 8/6/18 6:21 AM, John Kennedy wrote: > I'm trying to boot using only USB (no SD card). Seems like it should be easy. > > Booted up via my SD card with the USB drive attached, I can see and use it easily: > > # usbconfig > ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) > ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) > ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) > ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) > ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) > --> ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > > The RPI doesn't get the green boot-light or the rainbow screen. So low-level > stuff is obviously AWOL. I've put program_usb_boot_mode=1 into the config.txt, > but can't verify it with vcgencmd since that won't compile on arm64 (I haven't > tried burning raspbian and seeing if they have a working port to verify). > > As a real disk, it's power light comes up delayed. It seems like it should be > lit before 5-seconds, but I don't know if that is enough for the RPI to try > and enumerate it. Currently I'm trying to divide and conquer by putting the > MSDOS boot partition on an SD card and then boot USB off of that, or at least > try to figure out what is wrong from there. > > So my USB console cable finally arrived and I plugged it in: > > kernel: ugen0.4: at usbus0 > kernel: uslcom0 on uhub0 > kernel: uslcom0: on usbus0 > > Connecting via this from my amd64 FreeBSD box: > > screen /dev/cuaU0 115200 > > It's dropping some characters, so hopefully I won't add typos: > > [usb reset] > U-Boot> usb reset > resetting USB... > USB0: scanning bus 0 for devices... 5 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > > U-Boot> usb start > > If anybody has some suggestions on how to get that cable to not murder the > serial output (from the RPI), that would be helpful. The input (to RPI) seems > totally fine looking at the HDMI console output, but what comes back is very > spotty (lots of dropped characters, don't see mangling). In any case: > > Murdered info from usb info: > 1: Hub (u-boot root hub) > 2: Hub (vendor 0x0424, product 0x2514) > 3: Hub (vendor 0x0424, product 0x2514) > 4: Human interface (boot keyboard, boot mouse, should be the logitech) > 5: vendor specific (vendor 0x0424, product 0x7800) > > So u-boot isn't even seeing my Samsung drive? > > [version] > aarch64-none-elf-gcc (FreeBSD Ports Collection for aarch64noneelf) 6.4.0 > GNU ld (GNU Binutils) 2.30 > > That (and it's supporting partition of files) should be from: > FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180726-r336739.img > > [cat /boot/msdos/config.txt] > arm_control=0x200 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=pwm > dtoverlay=pi3-disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > > program_usb_boot_mode=1 > enable_uart=1 Did you try FreeBSD 12.0-CURRENT #0 r336479: Thu Jul 19 14:52:02 UTC 2018 ? Neither my rpi3b or rpi3b+ will boot images made after that rev. //per From owner-freebsd-arm@freebsd.org Mon Aug 6 15:20:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A283105BFA8 for ; Mon, 6 Aug 2018 15:20:28 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B5E787BFB0 for ; Mon, 6 Aug 2018 15:20:27 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w76FJ4t0095378 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Aug 2018 08:19:04 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w76FJ3Bm095377; Mon, 6 Aug 2018 08:19:03 -0700 (PDT) (envelope-from warlock) Date: Mon, 6 Aug 2018 08:19:03 -0700 From: John Kennedy To: Per olof Ljungmark Cc: freebsd-arm@freebsd.org Subject: Re: usb-only rpi 3b+ (+UART foo) Message-ID: <20180806151903.GF30738@phouka1.phouka.net> References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 15:20:28 -0000 On Mon, Aug 06, 2018 at 04:46:03PM +0200, Per olof Ljungmark wrote: > Did you try FreeBSD 12.0-CURRENT #0 r336479: Thu Jul 19 14:52:02 UTC 2018 ? > > Neither my rpi3b or rpi3b+ will boot images made after that rev. Booting off of SD-card, I've used both 20180719-r336479 and 20180726-r336739 (from the RPI3 FreeBSD 12.0-CURRENT Development Snapshots). In addition, I'm pretty sure that I've booted off of USB via a USB memory card reader with the SD-card put in it, but I'll have to test that again. I haven't had a reason to try 20180802-r337160 yet. As for you: No booting at all? IE, rainbow screen -> u-boot, kernel + modules load, no kernel boot, or all the way into proper root-fs-mounted success? I've been a bit leery about messing with u-boot if I don't have to, since that has clearly burned some people. So yay, pretty stock there. For running my own compiled kernels, I've landed on these successfully: r336739, r336795, r336962, and r337273 Stable enough to compile the next kernel. From owner-freebsd-arm@freebsd.org Mon Aug 6 15:54:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA407105CAAF for ; Mon, 6 Aug 2018 15:54:23 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DD597D0D9 for ; Mon, 6 Aug 2018 15:54:23 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533570861; bh=JSY2DDseQT95RPg1GikFdg8JcdYoZTPq588YJp0zH4w=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=rY90LX3+TUcyLIDDEoO1v5WZCoEHN4K3KXZY1SXslIZ70QC+eNgGtq1jWuDcX48zH v5KJNYoMToKwhIYXk0Xavn7njIaT5yJte7+xbSPW34GHCs2qXj3D6bW09ImE2+vsmu VKQH8mNOSKlapsy+JHE8hCw4oA4r8YNB10/FfGPg= Subject: Re: usb-only rpi 3b+ (+UART foo) To: John Kennedy Cc: freebsd-arm@freebsd.org References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> From: Per olof Ljungmark Message-ID: <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> Date: Mon, 6 Aug 2018 17:54:19 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180806151903.GF30738@phouka1.phouka.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 15:54:23 -0000 On 8/6/18 5:19 PM, John Kennedy wrote: > On Mon, Aug 06, 2018 at 04:46:03PM +0200, Per olof Ljungmark wrote: >> Did you try FreeBSD 12.0-CURRENT #0 r336479: Thu Jul 19 14:52:02 UTC 2018 ? >> >> Neither my rpi3b or rpi3b+ will boot images made after that rev. > > Booting off of SD-card, I've used both 20180719-r336479 and 20180726-r336739 > (from the RPI3 FreeBSD 12.0-CURRENT Development Snapshots). > > In addition, I'm pretty sure that I've booted off of USB via a USB memory card > reader with the SD-card put in it, but I'll have to test that again. I haven't > had a reason to try 20180802-r337160 yet. > > As for you: No booting at all? IE, rainbow screen -> u-boot, kernel + modules > load, no kernel boot, or all the way into proper root-fs-mounted success? > Stops after loading kernel: Booting [/boot/kernel/kernel] Using DTB privided by EFI at 0x7ff8000. EFI frambuffer information: addr, size 0x3e330000, 0x8ca000 dimensions 1920 x 1200 stride 1920 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 and then nothing Happens for me with all stock images after July 19. From owner-freebsd-arm@freebsd.org Mon Aug 6 15:58:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05D01105D0FA for ; Mon, 6 Aug 2018 15:58:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73A6D7D514 for ; Mon, 6 Aug 2018 15:58:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x529.google.com with SMTP id h12-v6so6427759pgs.3 for ; Mon, 06 Aug 2018 08:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2TP0RVwqrN+z8JqXwPPSpHWwobUHO4CHzwZSx6Gq3MQ=; b=PWHwBmmxtP8rbzuZyK69ZCbGmAiStf9fohU2hMywg4mxLMSrjJ2Mxbdd0Zj/nJ3c3l gvB4XqgZYa+x5LrCF3YPH4RVf/C7n1vyvgoGxKqdyzy3+40qjbfSdzkfAlni8xvogpbe 8NG3YYwejtMGSgD3hnCPCEuT0iyPRvgSywrR1cs9/mZRO8kYmI1bc43hEdxvgNMKcQGD 2XsUMrd5WO60szTx7pzaFjeoQHv1hoRflN8E9dZoo4qSn4XWjbw6oDfpUOe8P1K52oaF wnoQSocgiwfDmETyB0wfyEDqNBaLfOOpMb5hV8BNfUIVw+ZsmDdbqldifDS3mW9iG/YW 4caQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=2TP0RVwqrN+z8JqXwPPSpHWwobUHO4CHzwZSx6Gq3MQ=; b=GySrDBW8jLbMGz98sVU2xNyUBMog6RM2Wv2fdsUB5oVyDjpBX4wfwFbbeVlimf+I4c M8Kr9tZ2Gf/XfRDS59S38ImPc1DIEUoF+OJNTYCk6HEbyuAb2uH84uSCRNitH3jYQNs+ lS/zkv19wibJF5xkFe8aJqGyWAI6NKZZrhq3fgXFHOc5l+Zrsx1aA0WAN1jKATYbrZDz /JkA8uTBqlEtB+m3+SLSg3X3GlOXleno/oiriWS9z44TX9tzgNYlBQZP8F8CnDC0/wOs 9H4K0cKtXvM6wu04xlLVGjq35gLmwsLG+NyK0K664FZ74I95ztW+syjdk+jrJDhfYT4G p1VA== X-Gm-Message-State: AOUpUlEgrhselk7XgD6MnrT5lyoE1pVq24XdZi8CIdLrRVbnERGEgo1g qFCC/d/Rx/ctsXnpBDiV5JE= X-Google-Smtp-Source: AAOMgpdp3F0xDy5ASvB6GZdu3EmmIzaIpaf4qSrsY11nN10t436EO36xtJgDzpsMcBaRuXuuXz3jpQ== X-Received: by 2002:a63:f45:: with SMTP id 5-v6mr15390566pgp.447.1533571123349; Mon, 06 Aug 2018 08:58:43 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id p17-v6sm12080955pgv.26.2018.08.06.08.58.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 08:58:42 -0700 (PDT) Sender: Mark Johnston Date: Mon, 6 Aug 2018 11:58:37 -0400 From: Mark Johnston To: Mark Millard Cc: bob prohaska , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180806155837.GA6277@raichu> References: <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 15:58:45 -0000 On Wed, Aug 01, 2018 at 09:27:31PM -0700, Mark Millard wrote: > [I have a top-posted introduction here in reply > to a message listed at the bottom.] > > Bob P. meet Mark J. Mark J. meet Bob P. I'm > hopinh you can help Bob P. use a patch that > you once published on the lists. This was from: > > https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html > > Bob P. has been having problems with an rpi3 > based buildworld ending up with "was killed: > out of swap space" but when the swap partitions > do not seem to be heavily used (seen via swapinfo > or watching top). > > > The patch to report OOMA information did its job, very tersely. The console reported > > v_free_count: 5439, v_inactive_count: 1 > > Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out of swap space > > > > The entire buildworld.log and gstat output are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r336877M/ > > > > It appears that at 18:08:21 a write to the USB swap device took 530.5 ms, > > next top was killed and ten seconds later c++ was killed, _after_ da0b > > was no longer busy. My suspicion, based on the high latency, is that this is a consequence of r329882, which lowered the period of time that the page daemon will sleep while waiting for dirty pages to be cleaned. If a certain number of consecutive wakeups and queue scans occur without making progress, the OOM killer is triggered. That number is vm.pageout_oom_seq - could you try increasing it by a factor of 10 and retry your test? > > This buildworld stopped a quite a bit earlier than usual; most of the time > > the buildworld.log file is close to 20 MB at the time OOMA acts. In this case > > it was around 13 MB. Not clear if that's of significance. > > > > If somebody would indicate whether this result is informative, and any possible > > improvements to the test, I'd be most grateful. If the above suggestion doesn't help, the next thing to try would be to revert the oom_seq value to the default, apply this patch, and see if the problem continues to occur. If this doesn't help, please try applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. diff --git a/sys/vm/vm_pagequeue.h b/sys/vm/vm_pagequeue.h index fb56bdf2fdfc..29a16060253f 100644 --- a/sys/vm/vm_pagequeue.h +++ b/sys/vm/vm_pagequeue.h @@ -74,7 +74,7 @@ struct vm_pagequeue { } __aligned(CACHE_LINE_SIZE); #ifndef VM_BATCHQUEUE_SIZE -#define VM_BATCHQUEUE_SIZE 7 +#define VM_BATCHQUEUE_SIZE 1 #endif struct vm_batchqueue { From owner-freebsd-arm@freebsd.org Mon Aug 6 16:01:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05F09105D243 for ; Mon, 6 Aug 2018 16:01:30 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7046D7D805 for ; Mon, 6 Aug 2018 16:01:28 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 67a90f7f; Mon, 6 Aug 2018 18:01:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=DGtmRP2QNMUqyJMGMd5irFhGhSU=; b=qixsy1zb/YCwKPPCtrLIoZk3dg+j SAXKKIbow7sAeKlk7Xl+a+h+ZAn5onIQkiHuTRoGReBr2tklFuhRrtDPxzUUUDvx 6VNPlIwlKFyhOFPM5TUWci+Utb6QysSvQ7ykPauce1Uuq6Mpt1QE1OTTCfNEcM43 IJaq14DXz8eMpZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=eFEJEEKcV8YHvgFgvv5UfRcltgi2Esev99N2ev3j/Cz3cayBUJ2g8HxI EuZwSLQMprDrnRi+Q2oPgDbs2XeAPZU4QKW6TRtza5KM4dXSIGgRBK+A0p5DqiXK TAffPO9em1KBYEniIgT9GOh0nV15sTI3ZzamGSKJOjdHKoqtTVg= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 10cd1441 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 6 Aug 2018 18:01:26 +0200 (CEST) Date: Mon, 6 Aug 2018 18:01:26 +0200 From: Emmanuel Vadot To: Per olof Ljungmark Cc: John Kennedy , freebsd-arm@freebsd.org Subject: Re: usb-only rpi 3b+ (+UART foo) Message-Id: <20180806180126.406c18546c949118f6245aad@bidouilliste.com> In-Reply-To: <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 16:01:30 -0000 On Mon, 6 Aug 2018 17:54:19 +0200 Per olof Ljungmark wrote: > On 8/6/18 5:19 PM, John Kennedy wrote: > > On Mon, Aug 06, 2018 at 04:46:03PM +0200, Per olof Ljungmark wrote: > >> Did you try FreeBSD 12.0-CURRENT #0 r336479: Thu Jul 19 14:52:02 UTC 2018 ? > >> > >> Neither my rpi3b or rpi3b+ will boot images made after that rev. > > > > Booting off of SD-card, I've used both 20180719-r336479 and 20180726-r336739 > > (from the RPI3 FreeBSD 12.0-CURRENT Development Snapshots). > > > > In addition, I'm pretty sure that I've booted off of USB via a USB memory card > > reader with the SD-card put in it, but I'll have to test that again. I haven't > > had a reason to try 20180802-r337160 yet. > > > > As for you: No booting at all? IE, rainbow screen -> u-boot, kernel + modules > > load, no kernel boot, or all the way into proper root-fs-mounted success? > > > > Stops after loading kernel: > > Booting [/boot/kernel/kernel] > Using DTB privided by EFI at 0x7ff8000. > EFI frambuffer information: > addr, size 0x3e330000, 0x8ca000 > dimensions 1920 x 1200 > stride 1920 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > and then nothing > > Happens for me with all stock images after July 19. Probably related to this : https://svnweb.freebsd.org/base?view=revision&revision=336999 Note that this was added in UPDATING : https://svnweb.freebsd.org/base?view=revision&revision=336844 Please let me know if this isn't the problem so I can fix quickly. > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Aug 6 16:28:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 414ED105DC03 for ; Mon, 6 Aug 2018 16:28:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AFFD37E4B6; Mon, 6 Aug 2018 16:27:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w76GSF0o019703 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Aug 2018 09:28:16 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w76GSFVr019702; Mon, 6 Aug 2018 09:28:15 -0700 (PDT) (envelope-from fbsd) Date: Mon, 6 Aug 2018 09:28:14 -0700 From: bob prohaska To: Mark Johnston Cc: Mark Millard , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180806162814.GA19673@www.zefox.net> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806155837.GA6277@raichu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 16:28:00 -0000 On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > the problem continues to occur. If this doesn't help, please try > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > > diff --git a/sys/vm/vm_pagequeue.h b/sys/vm/vm_pagequeue.h > index fb56bdf2fdfc..29a16060253f 100644 > --- a/sys/vm/vm_pagequeue.h > +++ b/sys/vm/vm_pagequeue.h > @@ -74,7 +74,7 @@ struct vm_pagequeue { > } __aligned(CACHE_LINE_SIZE); > > #ifndef VM_BATCHQUEUE_SIZE > -#define VM_BATCHQUEUE_SIZE 7 > +#define VM_BATCHQUEUE_SIZE 1 > #endif > > struct vm_batchqueue { The open bracket at the end looks odd, is that really the end of the patch? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Mon Aug 6 16:30:31 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 609CB105DCF9 for ; Mon, 6 Aug 2018 16:30:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C30EB7E56D for ; Mon, 6 Aug 2018 16:30:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl0-x236.google.com with SMTP id e11-v6so5880331plb.3 for ; Mon, 06 Aug 2018 09:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CnnOBqo+PPyHwDmKFM5+wZa6jicPCc0WSq0cKY4uVC0=; b=ZDa9Se/C5IwuQZExgkdijUQDvBu0/07bNUIG3F2371Q4IMiwOu9w2xbwBWA4kDprIt 2QWPdITIy6ec6Bs7zoT5acDI2t0PreGVm3VsJH9uwXIpLU4s20C7ehgcoOwG3YFzitzS 29vOctcoU8znViXDE7lhOH/kVmBq/eNFVdUvi0OrDbfaCT//Vmw5VxaZHLM/TEKo0bdt mwKnZOein/rTi1n5VPaAW0RqvyENub2r66rG+qpLPIXs6aRapO3rGlLcr+4onLBGJaKl rxhPP8J9+uxe3v0s7FIY1QldwCBmHhFBY7lmRU3+5sU6uiCTpy1GEBxwZA+D6lU1h+HR jS8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=CnnOBqo+PPyHwDmKFM5+wZa6jicPCc0WSq0cKY4uVC0=; b=byLhQmv8yphFfykY+kwc7k4BOQl6W7PqHwySODsKC8AVfsWAV3THNUoQ5CRkKkxFgp O8EjIkYZbT4pC3VJPEvr93Fo4HQg9yVjA8ktsIUYl/rucYXFRJwabgjKGYnb8cToNNeB sR/N4IxfqO6ZojIemrEhlLlyEghJC+TExP2Hd/C/CeP7I/9u8mwfZQo+imODSLIQJ68A Bf/xJIZiLE6mcCzGidJrlrKwAtL08K9u6ZKAspLi6vRGRUv6z1RQLn6jKcS+/zEiY6z8 tj7ArpZ/LEgaxDaZgjhkgeLsSsqATdAo/ItvqbBNzSGIxKxvkWjegtELT++BvbT/9lwl BqDw== X-Gm-Message-State: AOUpUlHkwHOewW640A+4q4FjYRf4ogZ4ufZlj+sNljHGW+g8hqbd9YjM ZFsp+36gfZ6CCTxZvdb9E20= X-Google-Smtp-Source: AAOMgpeZmi0Ykym0RBtRJzeJgoDxpR4CTzpT1WXEu+lgJBOl29n/rzJKw0jeKFeWWsvu/xoSAPJYCw== X-Received: by 2002:a17:902:c85:: with SMTP id 5-v6mr14737009plt.141.1533573029635; Mon, 06 Aug 2018 09:30:29 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id i192-v6sm6097990pfe.188.2018.08.06.09.30.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 09:30:28 -0700 (PDT) Sender: Mark Johnston Date: Mon, 6 Aug 2018 12:30:25 -0400 From: Mark Johnston To: bob prohaska Cc: Mark Millard , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180806163025.GB6277@raichu> References: <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180806162814.GA19673@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806162814.GA19673@www.zefox.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 16:30:31 -0000 On Mon, Aug 06, 2018 at 09:28:14AM -0700, bob prohaska wrote: > On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > > the problem continues to occur. If this doesn't help, please try > > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > > > > diff --git a/sys/vm/vm_pagequeue.h b/sys/vm/vm_pagequeue.h > > index fb56bdf2fdfc..29a16060253f 100644 > > --- a/sys/vm/vm_pagequeue.h > > +++ b/sys/vm/vm_pagequeue.h > > @@ -74,7 +74,7 @@ struct vm_pagequeue { > > } __aligned(CACHE_LINE_SIZE); > > > > #ifndef VM_BATCHQUEUE_SIZE > > -#define VM_BATCHQUEUE_SIZE 7 > > +#define VM_BATCHQUEUE_SIZE 1 > > #endif > > > > struct vm_batchqueue { > > The open bracket at the end looks odd, is that really the end of the patch? Yes, it's just the contents of the file surrounding the modified line (the VM_BATCHQUEUE_SIZE definition). From owner-freebsd-arm@freebsd.org Mon Aug 6 16:48:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 531E6105E3C1 for ; Mon, 6 Aug 2018 16:48:11 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4F097F3E3 for ; Mon, 6 Aug 2018 16:48:10 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533574089; bh=AxsxkaSkSmP0T/b5QNMzvHF0ZxB/GOwf4uiBshAYcFg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=U/WrdN9dWxZLp50swSApLL+wAWlnt+DTW9AXSyTZG3LShWHDXawlsSpRuQqeq0PEg j4n3J7ra4KDN4/ZXNNxvKYCBoR9qzyMdwAFYdSDvinPeeSQpCnzImwFOLCu0Z43pWU UcTl8e6TsaOU2nWO0ww65d5ZK8/gEdYZcZQtdMUw= Subject: Re: usb-only rpi 3b+ (+UART foo) To: Emmanuel Vadot Cc: John Kennedy , freebsd-arm@freebsd.org References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> <20180806180126.406c18546c949118f6245aad@bidouilliste.com> From: Per olof Ljungmark Message-ID: <63a5dacd-1bf4-1417-d776-343bf3be8cda@nethead.se> Date: Mon, 6 Aug 2018 18:48:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180806180126.406c18546c949118f6245aad@bidouilliste.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 16:48:11 -0000 On 8/6/18 6:01 PM, Emmanuel Vadot wrote: > On Mon, 6 Aug 2018 17:54:19 +0200 > Per olof Ljungmark wrote: > >> On 8/6/18 5:19 PM, John Kennedy wrote: >>> On Mon, Aug 06, 2018 at 04:46:03PM +0200, Per olof Ljungmark wrote: >>>> Did you try FreeBSD 12.0-CURRENT #0 r336479: Thu Jul 19 14:52:02 UTC 2018 ? >>>> >>>> Neither my rpi3b or rpi3b+ will boot images made after that rev. >>> >>> Booting off of SD-card, I've used both 20180719-r336479 and 20180726-r336739 >>> (from the RPI3 FreeBSD 12.0-CURRENT Development Snapshots). >>> >>> In addition, I'm pretty sure that I've booted off of USB via a USB memory card >>> reader with the SD-card put in it, but I'll have to test that again. I haven't >>> had a reason to try 20180802-r337160 yet. >>> >>> As for you: No booting at all? IE, rainbow screen -> u-boot, kernel + modules >>> load, no kernel boot, or all the way into proper root-fs-mounted success? >>> >> >> Stops after loading kernel: >> >> Booting [/boot/kernel/kernel] >> Using DTB privided by EFI at 0x7ff8000. >> EFI frambuffer information: >> addr, size 0x3e330000, 0x8ca000 >> dimensions 1920 x 1200 >> stride 1920 >> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 >> >> and then nothing >> >> Happens for me with all stock images after July 19. > > Probably related to this : > https://svnweb.freebsd.org/base?view=revision&revision=336999 > > Note that this was added in UPDATING : > https://svnweb.freebsd.org/base?view=revision&revision=336844 > > Please let me know if this isn't the problem so I can fix quickly. Yes, seems *very* likely. Unfortunately I do not have a build enviroment ready, will try to set up. From owner-freebsd-arm@freebsd.org Mon Aug 6 17:12:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 018E9105ED19 for ; Mon, 6 Aug 2018 17:12:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AC357FF76 for ; Mon, 6 Aug 2018 17:12:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: PVZD.PkVM1mmIrgxfG1FXbJq.vP6C0ct5P2bn.3dgiQMK6ykZJsjNZ0cx5x.wG3 YrDth0GjbNtKVKcrt8SmGke8N5tEDotfz0Vyb_C7vs696omBLXSKwi8RFZNDpiP40M.YlJtnE2k6 w17GO6BhVT4K2MGgXtqfI1IaumaJXGibU1pEs7nA1ThxI_ISZNPG.3YXX3lqBYBSmC1oGkkSgv6l eMJyHC0vWMPahFI6KB6O81Xdcrb0s.mPBox5u2wj2NrCOaITUhChGVXwsgcA2AlWrYQ2k4ChFrmd A1mRt7hUjDq3IbMy32i9BhUSsWSGQBvdtgYHcsnupy2wLvDoL5drm7PuDHg04nhsGzazymWsFSKS A9iumkmfpp.TsGvpq9IGigQbt6F9HdD8RNYF1NRXHttLzzPERe4P8FtJme7CZ6qZ_oOTDqHEGwji pE.mnId5a0YuRlXNfe7z6A2isQFW6dqvpa2cq3a0yW0hVllB7gWFK6zvG1dlioYUeK02L0CNZ1qF ao2Iya9jMAPJmfwikdWVoYCp0tjITym54GBIh2p7JK5Cs4uPMFJWFdqkj_FB1SEhaqKR_oWO2RA. a.9Q5WcyZEJHO6yD_M_FCapTK_7DcEInqfAFb.KwaL13inrzUid381YzWs.8kkAim_kWrsjmVQoM _gMR50Kz_4i3DyggLHtLeFVnfDLSZ8HYEPZBqDW23lT6AK3LuMooxCdUbxdlAr6_ctWXIU997k4G H4lF9sHxVuAAjKugUUE0vWbHL6JouHzaRSQPJkxj.hdMsyl8JuGg2h121dfJ5AZKy6smjZtAEZgi HDMF9wFxDrLm9hYATZpN9jBup3kP5zuFErBT1VeN6rEjOx.KzUo99PNBGSkR7Bx3tJ0IMFc1NDhr LSqr5fLyuvfoqXEQn1VqNWKqiy6LMww9n3iIOf9sn4XJzqQlOuaTpe5wqe1HcOzpdM.zfAnkAPXw KwrGFFjhSfsTjLV4tKRcJli3w8kD2Kwm0QN1kRG1gPOqoMGfV0EMwdF4tg8e1BI_KuIUYnp2wlWD QeqfFwORiNP39FcmtgJXe6pRdy2GltdEu2Tv4_dQ9mT..DzJRf2amjWUJ8LgI8b9U6CZ6ZttyFdH gF4ZoxFnDP7VdOUmW Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Mon, 6 Aug 2018 17:12:49 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 90911295c0f0b0eace4902af772a2017; Mon, 06 Aug 2018 17:12:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <20180806124421.0b622761272370d2946cac29@bidouilliste.com> Date: Mon, 6 Aug 2018 10:12:43 -0700 Cc: Mark Millard via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:12:56 -0000 On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot = wrote: > On Mon, 6 Aug 2018 02:48:57 -0700 > Mark Millard via freebsd-arm wrote: >=20 >> I amd64 -> aarch64 cross built -r337347 and installed it >> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as >> bootaa64.efi) as an update. My attempted synchronization >> of loader.conf and ttys and devd.conf may be incorrect. >> (Previous to this the Pine64+ 2GB seemed to be working >> okay but it was at a very old build.) >>=20 >> The kernel config has GENERIC included but the various >> debug features disabled. (My typical operating >> environment.) >>=20 >> For all I know what the below shows might be expected >> at this point. The kernel seems to have problems with >> the MMC (that the kernel was loaded from). No other >> media are attached. mmcsd0 is really an 128 GiByte >> emmc on an adapter. (This historically worked for me.) >=20 > emmc to sd ? that's weird ... An example of the adapter I've used for this is: = https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-= adapter emmc is multi-mode for its allowed modes of operation. Thus its ability to frequently be used this way, such as via HS200. emmc is commonly more robust as I understand. (I had to modify the case the pine64+ 2GB is in in order for the adapter/emmc combination to fit in all the way.) > Can you boot -v and post the result please ? Glad to . . . DRAM: 2048 MiB Trying to boot from MMC1 U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000) DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... *** Warning - bad CRC, using default = environment Failed (-5) In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 3 disks 477384 bytes read in 25 ms (18.2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 40080000 ... Consoles: EFI console =20 FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi EFI version: 2.70 EFI Firmware: Das U-Boot (rev 0.00) Console: efi (0) Load Path: /\efi\boot\bootaa64.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) Setting currdev to disk0p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24= 400,0xe600000) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x8ce84a data=3D0x148020+0x72caac = syms=3D[0x8+0x11d000+0x8+0x1108a8] /boot/entropy size=3D0x1000 /boot/kernel/umodem.ko text=3D0x2168 text=3D0x1410 data=3D0x102d0+0xfd40 = syms=3D[0x8+0xf30+0x8+0xb73] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. OK boot -v Booting... Using DTB provided by EFI at 0x47ffc000. EHCI failed to shut down host controller. KDB: debugger backends: ddb KDB: current backend: ddb Type Physical Virtual #Pages Attr ConventionalMemory 000040000000 40000000 00007ffc WB=20 Reserved 000047ffc000 47ffc000 00000003 WB=20 RuntimeServicesData 000047fff000 47fff000 00000001 WB RUNTIME Reserved 000048000000 48000000 00000003 WB=20 RuntimeServicesData 000048003000 48003000 00000001 WB RUNTIME ConventionalMemory 000048005000 40000000 00068ea1 WB=20 LoaderData 0000b0ea6000 b0ea6000 00000001 WB=20 Reserved 0000b0ea7000 b0ea7000 00000001 WB=20 Reserved 0000b0ea8000 b0ea8000 00000001 WB=20 LoaderData 0000b0ea9000 b0ea9000 00004000 WB=20 LoaderData 0000b4ea9000 b4ea9000 00004000 WB=20 LoaderCode 0000b8ea9000 b8ea9000 00000075 WB=20 Reserved 0000b8f1e000 b8f1e000 00000001 WB=20 Reserved 0000b8f1f000 b8f1f000 00000001 WB=20 RuntimeServicesData 0000b8f20000 b8f20000 00000001 WB RUNTIME Reserved 0000b8f21000 b8f21000 00000001 WB=20 Reserved 0000b8f22000 b8f22000 00000001 WB=20 Reserved 0000b8f23000 b8f23000 00000001 WB=20 Reserved 0000b8f24000 b8f24000 00000001 WB=20 LoaderData 0000b8f25000 b8f25000 00005094 WB=20 RuntimeServicesCode 0000bdfb9000 bdfb9000 00000002 WB RUNTIME LoaderData 0000bdfbb000 b8f25000 00002045 WB=20 Physical memory chunk(s): 0x40000000 - 0x47ffbfff, 127 MB ( 32764 pages) 0x47fff000 - 0x47ffffff, 0 MB ( 1 pages) 0x48003000 - 0x48003fff, 0 MB ( 1 pages) 0x48005000 - 0xb0ea6fff, 1678 MB ( 429730 pages) 0xb0ea9000 - 0xb8f1dfff, 128 MB ( 32885 pages) 0xb8f20000 - 0xb8f20fff, 0 MB ( 1 pages) 0xb8f25000 - 0xbdfb8fff, 80 MB ( 20628 pages) 0xbdfbb000 - 0xbfffffff, 32 MB ( 8261 pages) Excluded memory regions: 0x47ffc000 - 0x48003fff, 0 MB ( 8 pages) NoAlloc=20 0xb0ea7000 - 0xb0ea8fff, 0 MB ( 2 pages) NoAlloc=20 0xb1000000 - 0xb25e1fff, 21 MB ( 5602 pages) NoAlloc=20 0xb8f1e000 - 0xb8f24fff, 0 MB ( 7 pages) NoAlloc=20 0xbdfb9000 - 0xbdfbafff, 0 MB ( 2 pages) NoAlloc=20 Found 4 CPUs in the device tree Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT r337347M arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) VT: init without driver. Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000. Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020. Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078. KLD file umodem.ko is missing dependencies Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: read 3840 bytes from preloaded cache random: unblocking device. arc4random: read 32 bytes from preloaded cache VIMAGE (virtualized network stack) enabled ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 random: entropy device external interface MAP 47fff000 mode 2 pages 1 MAP 48003000 mode 2 pages 1 MAP b8f20000 mode 2 pages 1 MAP bdfb9000 mode 2 pages 2 nfslock: pseudo-device crypto: kbd0 at kbdmux0 mem: null: openfirm: random: harvesting attach, 8 bytes (4 bits) from nexus0 ofwbus0: clk_fixed0: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from clk_fixed0 clk_fixed1: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from clk_fixed1 clk_fixed2: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from clk_fixed2 simplebus0: on ofwbus0 ccu_a64ng0: mem = 0x1c20000-0x1c203ff on simplebus0 ccu_a64ng0: Setting pll_periph0 as parent for ahb1 ccu_a64ng0: Setting pll_periph0 as parent for ahb2 ccu_a64ng0: Setting pll_ddr0 as parent for dram Clock: pll_cpux, parent: osc24M(0), freq: 816000000 Clock: pll_audio, parent: osc24M(0), freq: 24571428 Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000 Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000 Clock: pll_ddr0, parent: osc24M(0), freq: 408000000 Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000 Clock: pll_video0, parent: osc24M(0), freq: 30303 Clock: pll_video1, parent: osc24M(0), freq: 30303 Clock: pll_ve, parent: osc24M(0), freq: 30303 Clock: pll_gpu, parent: osc24M(0), freq: 30303 Clock: pll_de, parent: osc24M(0), freq: 30303 Clock: pll_hsic, parent: osc24M(0), freq: 1200000 Clock: apb2, parent: osc24M(1), freq: 24000000 Clock: nand, parent: osc24M(0), freq: 24000000 Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000 Clock: mmc1, parent: osc24M(0), freq: 24000000 Clock: mmc2, parent: osc24M(0), freq: 24000000 Clock: ts, parent: osc24M(0), freq: 24000000 Clock: ce, parent: osc24M(0), freq: 24000000 Clock: spi0, parent: osc24M(0), freq: 24000000 Clock: spi1, parent: osc24M(0), freq: 24000000 Clock: spdif, parent: pll_audio(0), freq: 24571428 Clock: dram, parent: pll_ddr0(0), freq: 408000000 Clock: de, parent: pll_periph0_2x(0), freq: 600000000 Clock: deinterlace, parent: pll_periph0(0), freq: 300000000 Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000 Clock: csi-mclk, parent: osc24M(0), freq: 24000000 Clock: ve, parent: pll_ve(0), freq: 30303 Clock: hdmi, parent: pll_video0(0), freq: 30303 Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000 Clock: gpu, parent: pll_gpu(0), freq: 30303 Clock: ahb1, parent: pll_periph0(3), freq: 300000000 Clock: ahb2, parent: pll_periph0(1), freq: 150000000 Clock: cpux, parent: pll_cpux(2), freq: 816000000 Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424 Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424 Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424 Clock: axi, parent: cpux(0), freq: 204000000 Clock: apb1, parent: ahb1(0), freq: 75000000 Clock: apb, parent: cpux(0), freq: 272000000 Clock: thsdiv, parent: osc24M(0), freq: 12000000 Clock: osc12M, parent: osc24M(0), freq: 12000000 Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000 Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000 Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856 Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712 Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424 Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000 Clock: bus-ce, parent: ahb1(0), freq: 300000000 Clock: bus-dma, parent: ahb1(0), freq: 300000000 Clock: bus-mmc0, parent: ahb1(0), freq: 300000000 Clock: bus-mmc1, parent: ahb1(0), freq: 300000000 Clock: bus-mmc2, parent: ahb1(0), freq: 300000000 Clock: bus-nand, parent: ahb1(0), freq: 300000000 Clock: bus-dram, parent: ahb1(0), freq: 300000000 Clock: bus-emac, parent: ahb2(0), freq: 150000000 Clock: bus-ts, parent: ahb1(0), freq: 300000000 Clock: bus-hstimer, parent: ahb1(0), freq: 300000000 Clock: bus-spi0, parent: ahb1(0), freq: 300000000 Clock: bus-spi1, parent: ahb1(0), freq: 300000000 Clock: bus-otg, parent: ahb1(0), freq: 300000000 Clock: bus-ehci0, parent: ahb1(0), freq: 300000000 Clock: bus-ehci1, parent: ahb2(0), freq: 150000000 Clock: bus-ohci0, parent: ahb1(0), freq: 300000000 Clock: bus-ohci1, parent: ahb2(0), freq: 150000000 Clock: bus-ve, parent: ahb1(0), freq: 300000000 Clock: bus-tcon0, parent: ahb1(0), freq: 300000000 Clock: bus-tcon1, parent: ahb1(0), freq: 300000000 Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000 Clock: bus-csi, parent: ahb1(0), freq: 300000000 Clock: bus-hdmi, parent: ahb1(0), freq: 300000000 Clock: bus-de, parent: ahb1(0), freq: 300000000 Clock: bus-gpu, parent: ahb1(0), freq: 300000000 Clock: bus-msgbox, parent: ahb1(0), freq: 300000000 Clock: bus-spinlock, parent: ahb1(0), freq: 300000000 Clock: bus-codec, parent: apb1(0), freq: 75000000 Clock: bus-spdif, parent: apb1(0), freq: 75000000 Clock: bus-pio, parent: apb1(0), freq: 75000000 Clock: bus-ths, parent: apb1(0), freq: 75000000 Clock: bus-i2s0, parent: apb1(0), freq: 75000000 Clock: bus-i2s1, parent: apb1(0), freq: 75000000 Clock: bus-i2s2, parent: apb1(0), freq: 75000000 Clock: bus-i2c0, parent: apb2(0), freq: 24000000 Clock: bus-i2c1, parent: apb2(0), freq: 24000000 Clock: bus-i2c2, parent: apb2(0), freq: 24000000 Clock: bus-src, parent: apb2(0), freq: 24000000 Clock: bus-uart0, parent: apb2(0), freq: 24000000 Clock: bus-uart1, parent: apb2(0), freq: 24000000 Clock: bus-uart2, parent: apb2(0), freq: 24000000 Clock: bus-uart3, parent: apb2(0), freq: 24000000 Clock: bus-uart4, parent: apb2(0), freq: 24000000 Clock: bus-dbg, parent: ahb1(0), freq: 300000000 Clock: ths, parent: thsdiv(0), freq: 12000000 Clock: usb-phy0, parent: osc24M(0), freq: 24000000 Clock: usb-phy1, parent: osc24M(0), freq: 24000000 Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000 Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000 Clock: usb-ohci0, parent: osc12M(0), freq: 12000000 Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000 Clock: dram-ve, parent: dram(0), freq: 408000000 Clock: dram-csi, parent: dram(0), freq: 408000000 Clock: dram-deinterlace, parent: dram(0), freq: 408000000 Clock: dram-ts, parent: dram(0), freq: 408000000 Clock: csi-misc, parent: osc24M(0), freq: 24000000 Clock: ac-dig, parent: pll_audio(0), freq: 24571428 Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712 Clock: avs, parent: osc24M(0), freq: 24000000 Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000 random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0 iichb0: mem = 0x1c2b000-0x1c2b3ff irq 21 on simplebus0 iicbus0: on iichb0 random: harvesting attach, 8 bytes (4 bits) from iicbus0 random: harvesting attach, 8 bytes (4 bits) from iichb0 random: harvesting attach, 8 bytes (4 bits) from simplebus0 regfix0: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from regfix0 random: harvesting attach, 8 bytes (4 bits) from ofwbus0 ccu_sun8i_r0: mem = 0x1f01400-0x1f014ff on simplebus0 Clock: ar100, parent: osc32k(0), freq: 32768 Clock: apb0, parent: ahb0(0), freq: 32768 Clock: ahb0, parent: ar100(0), freq: 32768 Clock: ir, parent: osc32k(0), freq: 32768 Clock: apb0-pio, parent: apb0(0), freq: 32768 Clock: apb0-ir, parent: apb0(0), freq: 32768 Clock: apb0-timer, parent: apb0(0), freq: 32768 Clock: apb0-rsb, parent: apb0(0), freq: 32768 Clock: apb0-uart, parent: apb0(0), freq: 32768 Clock: apb0-i2c, parent: apb0(0), freq: 32768 Clock: apb0-twd, parent: apb0(0), freq: 32768 random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0 psci0: on ofwbus0 psci0: PSCI version 0.2 compatible random: harvesting attach, 8 bytes (4 bits) from psci0 gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 23 on simplebus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 random: harvesting attach, 8 bytes (4 bits) from gic0 gpio0: mem 0x1c20800-0x1c20bff irq = 12,13,14 on simplebus0 gpiobus0: on gpio0 random: harvesting attach, 8 bytes (4 bits) from gpiobus0 Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 random: harvesting attach, 8 bytes (4 bits) from gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 26 = on simplebus0 gpiobus1: on gpio1 random: harvesting attach, 8 bytes (4 bits) from gpiobus1 Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 random: harvesting attach, 8 bytes (4 bits) from gpio1 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 random: harvesting attach, 8 bytes (4 bits) from generic_timer0 rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 rtc0: Using external oscillator rtc0: registered as a time-of-day clock, resolution 1.000000s random: harvesting attach, 8 bytes (4 bits) from rtc0 awusbphy0: mem = 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 random: harvesting attach, 8 bytes (4 bits) from awusbphy0 efirtc0: cannot read EFI realtime clock cpulist0: on ofwbus0 cpu0: on cpulist0 cpu0: missing 'clock-frequency' property arm64_cpu0: register <0> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0 random: harvesting attach, 8 bytes (4 bits) from cpu0 cpu1: on cpulist0 cpu1: missing 'clock-frequency' property arm64_cpu1: register <1> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1 random: harvesting attach, 8 bytes (4 bits) from cpu1 cpu2: on cpulist0 cpu2: missing 'clock-frequency' property arm64_cpu2: register <2> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2 random: harvesting attach, 8 bytes (4 bits) from cpu2 cpu3: on cpulist0 cpu3: missing 'clock-frequency' property arm64_cpu3: register <3> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3 random: harvesting attach, 8 bytes (4 bits) from cpu3 random: harvesting attach, 8 bytes (4 bits) from cpulist0 aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 aw_mmc0: vmmc-supply regulator found mmc0: on aw_mmc0 random: harvesting attach, 8 bytes (4 bits) from mmc0 random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled compat = allwinner,sun50i-a64-mmc (no driver attached) simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled compat = allwinner,sun50i-a64-emmc (no driver attached) simplebus0: mem 0x1c19000-0x1c193ff irq 7 compat = allwinner,sun8i-a33-musb (no driver attached) simplebus0: mem 0x1c1a000-0x1c1a0ff irq 8 disabled compat = allwinner,sun50i-a64-ehci (no driver attached) simplebus0: mem 0x1c1a400-0x1c1a4ff irq 9 disabled compat = allwinner,sun50i-a64-ohci (no driver attached) ehci0: mem 0x1c1b000-0x1c1b0ff = irq 10 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached random: harvesting attach, 8 bytes (4 bits) from usbus0 random: harvesting attach, 8 bytes (4 bits) from ehci0 ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on = simplebus0 usbus1 on ohci0 ohci0: usbpf: Attached random: harvesting attach, 8 bytes (4 bits) from usbus1 random: harvesting attach, 8 bytes (4 bits) from ohci0 gpioc0: on gpio0 random: harvesting attach, 8 bytes (4 bits) from gpioc0 simplebus0: mem 0x1c21400-0x1c21407 disabled compat = allwinner,sun50i-a64-pwm (no driver attached) uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on = simplebus0 uart0: console (115384,n,8,1) uart0: fast interrupt uart0: PPS capture mode: DCD random: harvesting attach, 8 bytes (4 bits) from uart0 simplebus0: mem 0x1c28400-0x1c287ff irq 16 disabled = compat snps,dw-apb-uart (no driver attached) simplebus0: mem 0x1c28800-0x1c28bff irq 17 disabled = compat snps,dw-apb-uart (no driver attached) simplebus0: mem 0x1c28c00-0x1c28fff irq 18 disabled = compat snps,dw-apb-uart (no driver attached) simplebus0: mem 0x1c29000-0x1c293ff irq 19 disabled = compat snps,dw-apb-uart (no driver attached) simplebus0: mem 0x1c2ac00-0x1c2afff irq 20 disabled compat = allwinner,sun6i-a31-i2c (no driver attached) iic0: on iicbus0 random: harvesting attach, 8 bytes (4 bits) from iic0 simplebus0: mem 0x1c2b400-0x1c2b7ff irq 22 disabled compat = allwinner,sun6i-a31-i2c (no driver attached) gpioc1: on gpio1 random: harvesting attach, 8 bytes (4 bits) from gpioc1 syscon_generic0: mem 0x1c00000-0x1c00fff on simplebus0 random: harvesting attach, 8 bytes (4 bits) from syscon_generic0 awg0: mem 0x1c30000-0x1c3ffff irq 27 on = simplebus0 simplebus0: no default resources for rid =3D 1, type =3D 3 awg0: PHY type: rgmii, conf mode: reg awg0: EMAC clock: 0x00000006 awg0: AHB frequency 150000000 Hz, MDC div: 0x2 miibus0: on awg0 rgephy0: PHY 0 on = miibus0 rgephy0: OUI 0x00e04c, model 0x0011, rev. 5 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow random: harvesting attach, 8 bytes (4 bits) from rgephy0 rgephy1: PHY 1 on = miibus0 rgephy1: OUI 0x00e04c, model 0x0011, rev. 5 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow random: harvesting attach, 8 bytes (4 bits) from rgephy1 random: harvesting attach, 8 bytes (4 bits) from miibus0 awg0: bpf attached awg0: Ethernet address: 02:ba:b1:c5:93:b7 random: harvesting attach, 8 bytes (4 bits) from awg0 cryptosoft0: crypto: assign cryptosoft0 driver id 0, flags 0x6000000 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0 random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 Found SMCCC version 1.0 Device configuration finished. procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached arc4random: read 32 bytes from preloaded cache arc4random: read 32 bytes from preloaded cache arc4random: read 32 bytes from preloaded cache tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384 IPsec: Initialized Security Association Processing. usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 aw_mmc0: Powering up sd/mmc mmc0: Probing bus ugen0.1: at usbus0 uhub0: on = usbus0 ugen1.1: at usbus1 uhub1: on = usbus1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) aw_mmc0: error rint: 0x00008010 AW_MMC_INT_DATA_END_BIT_ERR mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 4bit, 200MHz (HS200 timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: setting transfer rate to 52.000MHz (dual data rate timing) mmc0: Failed to set VCCQ for card at relative address 2 uhub1: 1 port with 1 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub1 uhub0: 1 port with 1 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub0 aw_mmc0: controller timeout aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 mmcsd0: Error reading EXT_CSD Timeout device_attach: mmcsd0 attach returned 6 Release APs...done Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]... CPU 0: ARM Cortex-A53 r0p4mountroot: waiting for device = /dev/ufs/PINE64P2Grootfs... affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Memory Model Features 2 =3D <32b CCIDX,48b VA> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 regulator: shutting down vcc3v3 Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19. Loader variables: vfs.root.mountfrom=3Dufs:/dev/ufs/PINE64P2Grootfs vfs.root.mountfrom.options=3Drw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 6 17:22:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5C97105F1B3 for ; Mon, 6 Aug 2018 17:22:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 866A2804EE for ; Mon, 6 Aug 2018 17:22:20 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D4C36153CF for ; Mon, 6 Aug 2018 17:22:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w76HMJ95058068 for ; Mon, 6 Aug 2018 17:22:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w76HMJVV058067 for freebsd-arm@FreeBSD.org; Mon, 6 Aug 2018 17:22:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 230333] BANANAPI 20180802-r337160 panic on boot Date: Mon, 06 Aug 2018 17:22:20 +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: manu@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:22:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230333 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #3 from Emmanuel Vadot --- Fixed by 337383 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Aug 6 17:22:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 184C9105F225 for ; Mon, 6 Aug 2018 17:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82C6A80711 for ; Mon, 6 Aug 2018 17:22:47 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0456A153D5 for ; Mon, 6 Aug 2018 17:22:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w76HMjf2058530 for ; Mon, 6 Aug 2018 17:22:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w76HMjL0058529 for freebsd-arm@FreeBSD.org; Mon, 6 Aug 2018 17:22:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 230331] BEAGLEBONE-20180802-r337160 fails to boot on BBG Date: Mon, 06 Aug 2018 17:22:46 +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: manu@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:22:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230331 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #10 from Emmanuel Vadot --- Fixed by 337383 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Aug 6 17:37:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34BF6105F7DE for ; Mon, 6 Aug 2018 17:37:58 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC7B180E83 for ; Mon, 6 Aug 2018 17:37:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id f6016ba5; Mon, 6 Aug 2018 19:37:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=owWECaGkjigDzX7kk8XE+LSpMXs=; b=hBGumCjXPye1SpI76h06//TuMiyR awOkqAKm+W2JjjKZKAWMkJXVIKAqAL17nS6umag2O897OdcHkQky6/ob91F7vHlA DOJYFERof+FasyuUXZ96ktUpuUKpjW+PxF+n7iQl0P6p8Mf/1rGLRlzoHFFUPlE9 QugAB7t6FE6UH7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=qSlkx1D/R+Attq1S/SKZwE60q+zK9tI4L6cBP6gJwMFphvcTwyCuG8h8 ++36UlHsvN9LMlzQHpyZ07M5Cufse6P5Fgl3rMnWB4FVG++HH3FblNjpic1fcZPL /lblHGZxfMtYQ4+yCG/E5mdaIs1E/4IQ1d+4fkXFTS+AZ4Qb1zY= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 64bf2a6f TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 6 Aug 2018 19:37:55 +0200 (CEST) Date: Mon, 6 Aug 2018 19:37:55 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Mark Millard via freebsd-arm Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted Message-Id: <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> In-Reply-To: <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:37:58 -0000 On Mon, 6 Aug 2018 10:12:43 -0700 Mark Millard wrote: > On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot wrote: > > > On Mon, 6 Aug 2018 02:48:57 -0700 > > Mark Millard via freebsd-arm wrote: > > > >> I amd64 -> aarch64 cross built -r337347 and installed it > >> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as > >> bootaa64.efi) as an update. My attempted synchronization > >> of loader.conf and ttys and devd.conf may be incorrect. > >> (Previous to this the Pine64+ 2GB seemed to be working > >> okay but it was at a very old build.) > >> > >> The kernel config has GENERIC included but the various > >> debug features disabled. (My typical operating > >> environment.) > >> > >> For all I know what the below shows might be expected > >> at this point. The kernel seems to have problems with > >> the MMC (that the kernel was loaded from). No other > >> media are attached. mmcsd0 is really an 128 GiByte > >> emmc on an adapter. (This historically worked for me.) > > > > emmc to sd ? that's weird ... > > An example of the adapter I've used for this is: > > https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter So this is a passive adapter, maybe that's something that should work but it's definitly is something that calls for problems. > emmc is multi-mode for its allowed modes of operation. Thus > its ability to frequently be used this way, such as via HS200. > emmc is commonly more robust as I understand. I didn't understand a word. > > (I had to modify the case the pine64+ 2GB is in in order for > the adapter/emmc combination to fit in all the way.) > > > Can you boot -v and post the result please ? > > Glad to . . . > > DRAM: 2048 MiB > Trying to boot from MMC1 > > > U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000) > DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology > > CPU: Allwinner A64 (SUN50I) > Model: Pine64+ > DRAM: 2 GiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default environment > > Failed (-5) > In: serial > Out: serial > Err: serial > Net: phy interface7 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0(part 0) is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disks on usb... > Disk usb0 not ready > Disk usb1 not ready > Disk usb2 not ready > Disk usb3 not ready > Scanning disks on mmc... > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 3 disks > 477384 bytes read in 25 ms (18.2 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > ## Starting EFI application at 40080000 ... > Consoles: EFI console > FreeBSD/arm64 EFI loader, Revision 1.1 > > Command line arguments: loader.efi > EFI version: 2.70 > EFI Firmware: Das U-Boot (rev 0.00) > Console: efi (0) > Load Path: /\efi\boot\bootaa64.efi > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0) > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0) > Setting currdev to disk0p1: > Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000) > Setting currdev to disk0p2: > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8] > /boot/entropy size=0x1000 > /boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 9 seconds... > > Type '?' for a list of commands, 'help' for more detailed help. > OK boot -v > Booting... > Using DTB provided by EFI at 0x47ffc000. > EHCI failed to shut down host controller. > KDB: debugger backends: ddb > KDB: current backend: ddb > Type Physical Virtual #Pages Attr > ConventionalMemory 000040000000 40000000 00007ffc WB > Reserved 000047ffc000 47ffc000 00000003 WB > RuntimeServicesData 000047fff000 47fff000 00000001 WB RUNTIME > Reserved 000048000000 48000000 00000003 WB > RuntimeServicesData 000048003000 48003000 00000001 WB RUNTIME > ConventionalMemory 000048005000 40000000 00068ea1 WB > LoaderData 0000b0ea6000 b0ea6000 00000001 WB > Reserved 0000b0ea7000 b0ea7000 00000001 WB > Reserved 0000b0ea8000 b0ea8000 00000001 WB > LoaderData 0000b0ea9000 b0ea9000 00004000 WB > LoaderData 0000b4ea9000 b4ea9000 00004000 WB > LoaderCode 0000b8ea9000 b8ea9000 00000075 WB > Reserved 0000b8f1e000 b8f1e000 00000001 WB > Reserved 0000b8f1f000 b8f1f000 00000001 WB > RuntimeServicesData 0000b8f20000 b8f20000 00000001 WB RUNTIME > Reserved 0000b8f21000 b8f21000 00000001 WB > Reserved 0000b8f22000 b8f22000 00000001 WB > Reserved 0000b8f23000 b8f23000 00000001 WB > Reserved 0000b8f24000 b8f24000 00000001 WB > LoaderData 0000b8f25000 b8f25000 00005094 WB > RuntimeServicesCode 0000bdfb9000 bdfb9000 00000002 WB RUNTIME > LoaderData 0000bdfbb000 b8f25000 00002045 WB > Physical memory chunk(s): > 0x40000000 - 0x47ffbfff, 127 MB ( 32764 pages) > 0x47fff000 - 0x47ffffff, 0 MB ( 1 pages) > 0x48003000 - 0x48003fff, 0 MB ( 1 pages) > 0x48005000 - 0xb0ea6fff, 1678 MB ( 429730 pages) > 0xb0ea9000 - 0xb8f1dfff, 128 MB ( 32885 pages) > 0xb8f20000 - 0xb8f20fff, 0 MB ( 1 pages) > 0xb8f25000 - 0xbdfb8fff, 80 MB ( 20628 pages) > 0xbdfbb000 - 0xbfffffff, 32 MB ( 8261 pages) > Excluded memory regions: > 0x47ffc000 - 0x48003fff, 0 MB ( 8 pages) NoAlloc > 0xb0ea7000 - 0xb0ea8fff, 0 MB ( 2 pages) NoAlloc > 0xb1000000 - 0xb25e1fff, 21 MB ( 5602 pages) NoAlloc > 0xb8f1e000 - 0xb8f24fff, 0 MB ( 7 pages) NoAlloc > 0xbdfb9000 - 0xbdfbafff, 0 MB ( 2 pages) NoAlloc > Found 4 CPUs in the device tree > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT r337347M arm64 > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) > VT: init without driver. > Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000. > Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020. > Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078. > KLD file umodem.ko is missing dependencies > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: read 3840 bytes from preloaded cache > random: unblocking device. > arc4random: read 32 bytes from preloaded cache > VIMAGE (virtualized network stack) enabled > ULE: setup cpu 0 > ULE: setup cpu 1 > ULE: setup cpu 2 > ULE: setup cpu 3 > random: entropy device external interface > MAP 47fff000 mode 2 pages 1 > MAP 48003000 mode 2 pages 1 > MAP b8f20000 mode 2 pages 1 > MAP bdfb9000 mode 2 pages 2 > nfslock: pseudo-device > crypto: > kbd0 at kbdmux0 > mem: > null: > openfirm: > random: harvesting attach, 8 bytes (4 bits) from nexus0 > ofwbus0: > clk_fixed0: on ofwbus0 > random: harvesting attach, 8 bytes (4 bits) from clk_fixed0 > clk_fixed1: on ofwbus0 > random: harvesting attach, 8 bytes (4 bits) from clk_fixed1 > clk_fixed2: on ofwbus0 > random: harvesting attach, 8 bytes (4 bits) from clk_fixed2 > simplebus0: on ofwbus0 > ccu_a64ng0: mem 0x1c20000-0x1c203ff on simplebus0 > ccu_a64ng0: Setting pll_periph0 as parent for ahb1 > ccu_a64ng0: Setting pll_periph0 as parent for ahb2 > ccu_a64ng0: Setting pll_ddr0 as parent for dram > Clock: pll_cpux, parent: osc24M(0), freq: 816000000 > Clock: pll_audio, parent: osc24M(0), freq: 24571428 > Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000 > Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000 > Clock: pll_ddr0, parent: osc24M(0), freq: 408000000 > Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000 > Clock: pll_video0, parent: osc24M(0), freq: 30303 > Clock: pll_video1, parent: osc24M(0), freq: 30303 > Clock: pll_ve, parent: osc24M(0), freq: 30303 > Clock: pll_gpu, parent: osc24M(0), freq: 30303 > Clock: pll_de, parent: osc24M(0), freq: 30303 > Clock: pll_hsic, parent: osc24M(0), freq: 1200000 > Clock: apb2, parent: osc24M(1), freq: 24000000 > Clock: nand, parent: osc24M(0), freq: 24000000 > Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000 > Clock: mmc1, parent: osc24M(0), freq: 24000000 > Clock: mmc2, parent: osc24M(0), freq: 24000000 > Clock: ts, parent: osc24M(0), freq: 24000000 > Clock: ce, parent: osc24M(0), freq: 24000000 > Clock: spi0, parent: osc24M(0), freq: 24000000 > Clock: spi1, parent: osc24M(0), freq: 24000000 > Clock: spdif, parent: pll_audio(0), freq: 24571428 > Clock: dram, parent: pll_ddr0(0), freq: 408000000 > Clock: de, parent: pll_periph0_2x(0), freq: 600000000 > Clock: deinterlace, parent: pll_periph0(0), freq: 300000000 > Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000 > Clock: csi-mclk, parent: osc24M(0), freq: 24000000 > Clock: ve, parent: pll_ve(0), freq: 30303 > Clock: hdmi, parent: pll_video0(0), freq: 30303 > Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000 > Clock: gpu, parent: pll_gpu(0), freq: 30303 > Clock: ahb1, parent: pll_periph0(3), freq: 300000000 > Clock: ahb2, parent: pll_periph0(1), freq: 150000000 > Clock: cpux, parent: pll_cpux(2), freq: 816000000 > Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424 > Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424 > Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424 > Clock: axi, parent: cpux(0), freq: 204000000 > Clock: apb1, parent: ahb1(0), freq: 75000000 > Clock: apb, parent: cpux(0), freq: 272000000 > Clock: thsdiv, parent: osc24M(0), freq: 12000000 > Clock: osc12M, parent: osc24M(0), freq: 12000000 > Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000 > Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000 > Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856 > Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712 > Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424 > Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000 > Clock: bus-ce, parent: ahb1(0), freq: 300000000 > Clock: bus-dma, parent: ahb1(0), freq: 300000000 > Clock: bus-mmc0, parent: ahb1(0), freq: 300000000 > Clock: bus-mmc1, parent: ahb1(0), freq: 300000000 > Clock: bus-mmc2, parent: ahb1(0), freq: 300000000 > Clock: bus-nand, parent: ahb1(0), freq: 300000000 > Clock: bus-dram, parent: ahb1(0), freq: 300000000 > Clock: bus-emac, parent: ahb2(0), freq: 150000000 > Clock: bus-ts, parent: ahb1(0), freq: 300000000 > Clock: bus-hstimer, parent: ahb1(0), freq: 300000000 > Clock: bus-spi0, parent: ahb1(0), freq: 300000000 > Clock: bus-spi1, parent: ahb1(0), freq: 300000000 > Clock: bus-otg, parent: ahb1(0), freq: 300000000 > Clock: bus-ehci0, parent: ahb1(0), freq: 300000000 > Clock: bus-ehci1, parent: ahb2(0), freq: 150000000 > Clock: bus-ohci0, parent: ahb1(0), freq: 300000000 > Clock: bus-ohci1, parent: ahb2(0), freq: 150000000 > Clock: bus-ve, parent: ahb1(0), freq: 300000000 > Clock: bus-tcon0, parent: ahb1(0), freq: 300000000 > Clock: bus-tcon1, parent: ahb1(0), freq: 300000000 > Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000 > Clock: bus-csi, parent: ahb1(0), freq: 300000000 > Clock: bus-hdmi, parent: ahb1(0), freq: 300000000 > Clock: bus-de, parent: ahb1(0), freq: 300000000 > Clock: bus-gpu, parent: ahb1(0), freq: 300000000 > Clock: bus-msgbox, parent: ahb1(0), freq: 300000000 > Clock: bus-spinlock, parent: ahb1(0), freq: 300000000 > Clock: bus-codec, parent: apb1(0), freq: 75000000 > Clock: bus-spdif, parent: apb1(0), freq: 75000000 > Clock: bus-pio, parent: apb1(0), freq: 75000000 > Clock: bus-ths, parent: apb1(0), freq: 75000000 > Clock: bus-i2s0, parent: apb1(0), freq: 75000000 > Clock: bus-i2s1, parent: apb1(0), freq: 75000000 > Clock: bus-i2s2, parent: apb1(0), freq: 75000000 > Clock: bus-i2c0, parent: apb2(0), freq: 24000000 > Clock: bus-i2c1, parent: apb2(0), freq: 24000000 > Clock: bus-i2c2, parent: apb2(0), freq: 24000000 > Clock: bus-src, parent: apb2(0), freq: 24000000 > Clock: bus-uart0, parent: apb2(0), freq: 24000000 > Clock: bus-uart1, parent: apb2(0), freq: 24000000 > Clock: bus-uart2, parent: apb2(0), freq: 24000000 > Clock: bus-uart3, parent: apb2(0), freq: 24000000 > Clock: bus-uart4, parent: apb2(0), freq: 24000000 > Clock: bus-dbg, parent: ahb1(0), freq: 300000000 > Clock: ths, parent: thsdiv(0), freq: 12000000 > Clock: usb-phy0, parent: osc24M(0), freq: 24000000 > Clock: usb-phy1, parent: osc24M(0), freq: 24000000 > Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000 > Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000 > Clock: usb-ohci0, parent: osc12M(0), freq: 12000000 > Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000 > Clock: dram-ve, parent: dram(0), freq: 408000000 > Clock: dram-csi, parent: dram(0), freq: 408000000 > Clock: dram-deinterlace, parent: dram(0), freq: 408000000 > Clock: dram-ts, parent: dram(0), freq: 408000000 > Clock: csi-misc, parent: osc24M(0), freq: 24000000 > Clock: ac-dig, parent: pll_audio(0), freq: 24571428 > Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712 > Clock: avs, parent: osc24M(0), freq: 24000000 > Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000 > random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0 > iichb0: mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0 > iicbus0: on iichb0 > random: harvesting attach, 8 bytes (4 bits) from iicbus0 > random: harvesting attach, 8 bytes (4 bits) from iichb0 > random: harvesting attach, 8 bytes (4 bits) from simplebus0 > regfix0: on ofwbus0 > random: harvesting attach, 8 bytes (4 bits) from regfix0 > random: harvesting attach, 8 bytes (4 bits) from ofwbus0 > ccu_sun8i_r0: mem 0x1f01400-0x1f014ff on simplebus0 > Clock: ar100, parent: osc32k(0), freq: 32768 > Clock: apb0, parent: ahb0(0), freq: 32768 > Clock: ahb0, parent: ar100(0), freq: 32768 > Clock: ir, parent: osc32k(0), freq: 32768 > Clock: apb0-pio, parent: apb0(0), freq: 32768 > Clock: apb0-ir, parent: apb0(0), freq: 32768 > Clock: apb0-timer, parent: apb0(0), freq: 32768 > Clock: apb0-rsb, parent: apb0(0), freq: 32768 > Clock: apb0-uart, parent: apb0(0), freq: 32768 > Clock: apb0-i2c, parent: apb0(0), freq: 32768 > Clock: apb0-twd, parent: apb0(0), freq: 32768 > random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0 > psci0: on ofwbus0 > psci0: PSCI version 0.2 compatible > random: harvesting attach, 8 bytes (4 bits) from psci0 > gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 > random: harvesting attach, 8 bytes (4 bits) from gic0 > gpio0: mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0 > gpiobus0: on gpio0 > random: harvesting attach, 8 bytes (4 bits) from gpiobus0 > Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 > Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 > Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 > Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 > Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 > Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 > Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 > Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 > random: harvesting attach, 8 bytes (4 bits) from gpio0 > gpio1: mem 0x1f02c00-0x1f02fff irq 26 on simplebus0 > gpiobus1: on gpio1 > random: harvesting attach, 8 bytes (4 bits) from gpiobus1 > Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 > Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 > Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 > Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 > Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 > Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 > Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 > Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 > random: harvesting attach, 8 bytes (4 bits) from gpio1 > generic_timer0: irq 0,1,2,3 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > random: harvesting attach, 8 bytes (4 bits) from generic_timer0 > rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 > rtc0: Using external oscillator > rtc0: registered as a time-of-day clock, resolution 1.000000s > random: harvesting attach, 8 bytes (4 bits) from rtc0 > awusbphy0: mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 > random: harvesting attach, 8 bytes (4 bits) from awusbphy0 > efirtc0: cannot read EFI realtime clock > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu0: missing 'clock-frequency' property > arm64_cpu0: register <0> > random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0 > random: harvesting attach, 8 bytes (4 bits) from cpu0 > cpu1: on cpulist0 > cpu1: missing 'clock-frequency' property > arm64_cpu1: register <1> > random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1 > random: harvesting attach, 8 bytes (4 bits) from cpu1 > cpu2: on cpulist0 > cpu2: missing 'clock-frequency' property > arm64_cpu2: register <2> > random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2 > random: harvesting attach, 8 bytes (4 bits) from cpu2 > cpu3: on cpulist0 > cpu3: missing 'clock-frequency' property > arm64_cpu3: register <3> > random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3 > random: harvesting attach, 8 bytes (4 bits) from cpu3 > random: harvesting attach, 8 bytes (4 bits) from cpulist0 > aw_mmc0: mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0 > aw_mmc0: vmmc-supply regulator found > mmc0: on aw_mmc0 > random: harvesting attach, 8 bytes (4 bits) from mmc0 > random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 > simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached) > simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached) > simplebus0: mem 0x1c19000-0x1c193ff irq 7 compat allwinner,sun8i-a33-musb (no driver attached) > simplebus0: mem 0x1c1a000-0x1c1a0ff irq 8 disabled compat allwinner,sun50i-a64-ehci (no driver attached) > simplebus0: mem 0x1c1a400-0x1c1a4ff irq 9 disabled compat allwinner,sun50i-a64-ohci (no driver attached) > ehci0: mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ehci0: usbpf: Attached > random: harvesting attach, 8 bytes (4 bits) from usbus0 > random: harvesting attach, 8 bytes (4 bits) from ehci0 > ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0 > usbus1 on ohci0 > ohci0: usbpf: Attached > random: harvesting attach, 8 bytes (4 bits) from usbus1 > random: harvesting attach, 8 bytes (4 bits) from ohci0 > gpioc0: on gpio0 > random: harvesting attach, 8 bytes (4 bits) from gpioc0 > simplebus0: mem 0x1c21400-0x1c21407 disabled compat allwinner,sun50i-a64-pwm (no driver attached) > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0 > uart0: console (115384,n,8,1) > uart0: fast interrupt > uart0: PPS capture mode: DCD > random: harvesting attach, 8 bytes (4 bits) from uart0 > simplebus0: mem 0x1c28400-0x1c287ff irq 16 disabled compat snps,dw-apb-uart (no driver attached) > simplebus0: mem 0x1c28800-0x1c28bff irq 17 disabled compat snps,dw-apb-uart (no driver attached) > simplebus0: mem 0x1c28c00-0x1c28fff irq 18 disabled compat snps,dw-apb-uart (no driver attached) > simplebus0: mem 0x1c29000-0x1c293ff irq 19 disabled compat snps,dw-apb-uart (no driver attached) > simplebus0: mem 0x1c2ac00-0x1c2afff irq 20 disabled compat allwinner,sun6i-a31-i2c (no driver attached) > iic0: on iicbus0 > random: harvesting attach, 8 bytes (4 bits) from iic0 > simplebus0: mem 0x1c2b400-0x1c2b7ff irq 22 disabled compat allwinner,sun6i-a31-i2c (no driver attached) > gpioc1: on gpio1 > random: harvesting attach, 8 bytes (4 bits) from gpioc1 > syscon_generic0: mem 0x1c00000-0x1c00fff on simplebus0 > random: harvesting attach, 8 bytes (4 bits) from syscon_generic0 > awg0: mem 0x1c30000-0x1c3ffff irq 27 on simplebus0 > simplebus0: no default resources for rid = 1, type = 3 > awg0: PHY type: rgmii, conf mode: reg > awg0: EMAC clock: 0x00000006 > awg0: AHB frequency 150000000 Hz, MDC div: 0x2 > miibus0: on awg0 > rgephy0: PHY 0 on miibus0 > rgephy0: OUI 0x00e04c, model 0x0011, rev. 5 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > random: harvesting attach, 8 bytes (4 bits) from rgephy0 > rgephy1: PHY 1 on miibus0 > rgephy1: OUI 0x00e04c, model 0x0011, rev. 5 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > random: harvesting attach, 8 bytes (4 bits) from rgephy1 > random: harvesting attach, 8 bytes (4 bits) from miibus0 > awg0: bpf attached > awg0: Ethernet address: 02:ba:b1:c5:93:b7 > random: harvesting attach, 8 bytes (4 bits) from awg0 > cryptosoft0: > crypto: assign cryptosoft0 driver id 0, flags 0x6000000 > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0 > random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 > Found SMCCC version 1.0 > Device configuration finished. > procfs registered > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > lo0: bpf attached > arc4random: read 32 bytes from preloaded cache > arc4random: read 32 bytes from preloaded cache > arc4random: read 32 bytes from preloaded cache > tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384 > IPsec: Initialized Security Association Processing. > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 12Mbps Full Speed USB v1.0 > aw_mmc0: Powering up sd/mmc > mmc0: Probing bus > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > mmc0: SD probe: failed > mmc0: MMC probe: OK (OCR: 0x40ff8080) > mmc0: Current OCR: 0x00ff8080 > mmc0: Probing cards > mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f) > mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > aw_mmc0: error rint: 0x00008010 > AW_MMC_INT_DATA_END_BIT_ERR > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 > mmc0: quirks: 0 > mmc0: bus: 4bit, 200MHz (HS200 timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > aw_mmc0: error rint: 0x00000100 > AW_MMC_INT_RESP_TIMEOUT > mmc0: setting transfer rate to 52.000MHz (dual data rate timing) > mmc0: Failed to set VCCQ for card at relative address 2 So the driver is selecting DDR52 transfer rate but, of course, cannot switch the IO voltage to 1.8V as on this board the IO voltage for the SD card is tied to 3.3V > uhub1: 1 port with 1 removable, self powered > random: harvesting attach, 8 bytes (4 bits) from uhub1 > uhub0: 1 port with 1 removable, self powered > random: harvesting attach, 8 bytes (4 bits) from uhub0 > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 > > mmcsd0: Error reading EXT_CSD Timeout This seems weird, I have a board with an eMMC IO voltage tied to 3.3V (Olinuxino-A64), I'll try HEAD on this board. > device_attach: mmcsd0 attach returned 6 > Release APs...done > Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]... > CPU 0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs... > affinity: 0 > Instruction Set Attributes 0 = > Instruction Set Attributes 1 = <> > Processor Features 0 = > Processor Features 1 = <0> > Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 = <> > Memory Model Features 2 = <32b CCIDX,48b VA> > Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8> > Debug Features 1 = <0> > Auxiliary Features 0 = <0> > Auxiliary Features 1 = <0> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > CPU 2: ARM Cortex-A53 r0p4 affinity: 2 > CPU 3: ARM Cortex-A53 r0p4 affinity: 3 > regulator: shutting down vcc3v3 > Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs > vfs.root.mountfrom.options=rw,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> > > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Aug 6 17:48:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82FCC105FD3A for ; Mon, 6 Aug 2018 17:48:40 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B253816A2 for ; Mon, 6 Aug 2018 17:48:39 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:subject:to:message-id; s=default; bh=fAzwDr+zlkwf6vggjm9maiM2vwQlHAGJ0YItqTtOgm0=; b=jYgAZEg5gm5VvEXT/OxwkXNrEE3VTwA4752Q+X4pQI9OO2PVWB3d0MPy7B3bCd3QSHM+9eJ8ON5bqUTvIfhhEcAB3wRnnX8cgc5KonxUSpozvYaUP7Ay1qi7JhE2eGPEyxciN5MH5KAtgSor/juVEGQy99Iv3KewULIvPRV+5b4= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 9013a662 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Mon, 6 Aug 2018 17:48:28 +0000 (UTC) Date: Mon, 06 Aug 2018 20:48:28 +0300 From: Greg V Subject: Rockchip RK3399 (ROCKPro64) boots to multiuser To: freebsd-arm Message-Id: <1533577708.4175.0@hraggstad.unrelenting.technology> X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:48:40 -0000 Hi, I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64=20 board): https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 As with the ROCK64, boot is over the network. To boot, dd ayufan's=20 ubuntu image onto an sdcard and Ctrl-C the linux boot on the kernel=20 selection screen. U-Boot on SPI flash is not available yet. Unfortunately, performance is very disappointing =97 I think the big=20 cluster's default frequency is very low. (Everything runs faster if cpuset to the LITTLE cores.) Looks like we'll need a driver for the "rockchip,rk808" PMIC to make=20 cpufreq_dt work=85 Also my attempt at the clock driver is very incomplete ;) = From owner-freebsd-arm@freebsd.org Mon Aug 6 17:56:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 256051060272 for ; Mon, 6 Aug 2018 17:56:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85C0381E5D for ; Mon, 6 Aug 2018 17:56:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id b1690070; Mon, 6 Aug 2018 19:56:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=crJ1Lw9dGrswmD9sJ7FPj8MIu74=; b=lYuzRc9sAVVxX1FrsxSBIIU/zBLD +YVXVRwWmqFIKKFtxLGVNdgVOvgIS4+uycguw0aq7kw9Kor0K3COi+n9uIIcq+XH iZOl6WUeOS1viPu/VqzIiPdWPtfkyteyapKkavYTDH4x3zWWWoLzcLCl8hfgcreG 1LRSXzU4NUKEgC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=ZLt7OZLSXFrtWHkQgfnYPgfD6NCatVyk5FooLRpT/lU77KtGo8+3fPuV 13AQL0Vwy5PZmk3fcHcqt4tUHb7aZCEMnaMU+3G4qk7r3yVEdLaxnboOr5CxOL+N B3PvyPfe022WpdDxvJDkDLjqPJ9LltMmp8Uf3eOTPEqwbr87g60= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 40f712db TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 6 Aug 2018 19:56:06 +0200 (CEST) Date: Mon, 6 Aug 2018 19:56:05 +0200 From: Emmanuel Vadot To: Greg V Cc: freebsd-arm Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser Message-Id: <20180806195605.9cbece894695862ce11c717c@bidouilliste.com> In-Reply-To: <1533577708.4175.0@hraggstad.unrelenting.technology> References: <1533577708.4175.0@hraggstad.unrelenting.technology> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:56:08 -0000 On Mon, 06 Aug 2018 20:48:28 +0300 Greg V wrote: > Hi, >=20 > I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64=20 > board): >=20 > https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 Awesome :) > As with the ROCK64, boot is over the network. To boot, dd ayufan's=20 > ubuntu image onto an sdcard and Ctrl-C the linux boot on the kernel=20 > selection screen. U-Boot on SPI flash is not available yet. >=20 > Unfortunately, performance is very disappointing ? I think the big=20 > cluster's default frequency is very low. > (Everything runs faster if cpuset to the LITTLE cores.) >=20 > Looks like we'll need a driver for the "rockchip,rk808" PMIC to make=20 > cpufreq_dt work? > Also my attempt at the clock driver is very incomplete ;) I have one almost ready for the rk805 but it seems that my i2c driver is bad for writing, it's on my list to fix before FreeBSD 12.0 I should have my RockPro64 soon (hopefuly tomorow) and will try your patches. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Aug 6 18:26:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D8D910612CF for ; Mon, 6 Aug 2018 18:26:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.ne1.yahoo.com (sonic310-22.consmr.mail.ne1.yahoo.com [66.163.186.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABBF58325B for ; Mon, 6 Aug 2018 18:26:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: BDxZHzAVM1lnAh0pYe5RLgro91M1AkVzz5IwRlLoNxAMgqRmxnxlA6tgobNMNT2 aPKA.Kj3MxeMWslcgDtmIFnvr8jsKbrg3UMhRu03tCqu9yY6juuhyGc2lOWvPbuw9FuKM8iZX8x0 Rov9gHjMzBhwIrjLImm1wSt219KSogYdyoLQGjroswF16h_Ej4DmeicVGuzlRyblnnB81Ju4gDvL nknbTm0VcPZCfi0qJHYR7njmwp7jG9ulpjAE5cFHQSgfiHGgwDUHPEW12y_.xuc67Ol9mChB2yp2 4p5gGV34zSwBPkJ8l96zX0OXqfGnJ7QoPj51ShBWrp5vSW_xPK1oDH39SWKUOlRd2POopD7h9XSm jYz6QbtnH7RxHpHJR8YqN7l5PaFNL.qtFuV.rb5K_DW7ES749PdT4phtCiSZhVE49qZQyjI4irn3 CN4X3EbSOAbKroWdGbo_XZjETVMqIMYeJ.1no1X7qyl_xKSLbmqO1BpE3IHk2TvDsmrlVSa08Hnm 46jmiIAtLN29sShhJUDHWEcbSZj.sFDAEbUtPq3tXHSVh7vS4PIGAAlTL7DKj3DJpiXNBa_BcBYQ 5yuL22dhKad7ozV7CyKjRQGZGdEhtx8_blCYVhivxbBeAPYKwy_Sax2NF8VXHPuCTRN50hMqaRHV exUJ8y0_Q7.xFTvqoRc214F5OG7q1Q_3FYVDQGz90kGQlqj5BNpPTTJNZOGKolmqGwurMwi69MrS BxenkxPB8CwiWjiNeeHWdaQ4JMVNtfQH9wYH7jW4oYjG2fbn7wEomD07NbE21ipyhxqm1WMba9uo nYXVB.NT3aB5tPr2pkiUuYqwaGEfMx_nhQafGjQtHVgN8RVQS0USl_mjhRKdPfSb7DtGj84tin.T 2u3E8WGEb8XkKXu.d6Yrk5hjRLJwItBkClpUe1Mozc7HUdT5PxWAhvEvVgCg5QBlFrDgRmMd1Pss QXtuadcVwezJQUyAzqWv64Ip58dWaXXo9QmBUBqqyB9nH_szO_a23D0VKF0IfN5a5ezewZnsBatN xnLEX.aIzTzVuT8UffImoZXULj5Pe2zV9XSmhkB1f3ScDlASa_PkY9HpotzvBp27vt5Uwx31zfSg 37dzo9lCWrZIbhDFziASw Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Mon, 6 Aug 2018 18:26:57 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp410.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0b25c741c6a81430697edbd625edc851; Mon, 06 Aug 2018 18:26:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> Date: Mon, 6 Aug 2018 11:26:54 -0700 Cc: Mark Millard via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 18:26:59 -0000 On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot = wrote: > On Mon, 6 Aug 2018 10:12:43 -0700 > Mark Millard wrote: >=20 >> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot = wrote: >>=20 >>> On Mon, 6 Aug 2018 02:48:57 -0700 >>> Mark Millard via freebsd-arm wrote: >>>=20 >>>> I amd64 -> aarch64 cross built -r337347 and installed it >>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as >>>> bootaa64.efi) as an update. My attempted synchronization >>>> of loader.conf and ttys and devd.conf may be incorrect. >>>> (Previous to this the Pine64+ 2GB seemed to be working >>>> okay but it was at a very old build.) >>>>=20 >>>> The kernel config has GENERIC included but the various >>>> debug features disabled. (My typical operating >>>> environment.) >>>>=20 >>>> For all I know what the below shows might be expected >>>> at this point. The kernel seems to have problems with >>>> the MMC (that the kernel was loaded from). No other >>>> media are attached. mmcsd0 is really an 128 GiByte >>>> emmc on an adapter. (This historically worked for me.) >>>=20 >>> emmc to sd ? that's weird ... >>=20 >> An example of the adapter I've used for this is: >>=20 >> = https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-= adapter >=20 > So this is a passive adapter, maybe that's something that should work > but it's definitly is something that calls for problems. >=20 >> emmc is multi-mode for its allowed modes of operation. Thus >> its ability to frequently be used this way, such as via HS200. >> emmc is commonly more robust as I understand. >=20 > I didn't understand a word. I got the HS200 reference from the boot -v output. Such is currently = from the JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC members have free access, others do not.) The output reported: mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 4bit, 200MHz (HS200 timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks The e.MMC bus speed modes with I/O Voltage 3V allowed are: Backwards Compatibility with legacy MMC card, data rate single, 3V = allowed, bus widths 1,4,8, 0-26 MHz High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz (The last being the fastest for maximum transfer rate with 3V.) There is another 1.8V/1.2V mode: HS400 that is dual data rate and always = 8 bit, unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. = HS400 is optional and sufficiently old e.MMC standard vintages would likely = not even have it. So a slower 3.? V mode of use used to be selected (based on the = constraints on the board's voltages in some way, possibly hard coded). >>=20 >> (I had to modify the case the pine64+ 2GB is in in order for >> the adapter/emmc combination to fit in all the way.) >>=20 >>> Can you boot -v and post the result please ? >>=20 >> Glad to . . . >>=20 >> DRAM: 2048 MiB >> Trying to boot from MMC1 >>=20 >>=20 >> U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000) >> DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology >>=20 >> CPU: Allwinner A64 (SUN50I) >> Model: Pine64+ >> DRAM: 2 GiB >> MMC: SUNXI SD/MMC: 0 >> Loading Environment from FAT... *** Warning - bad CRC, using default = environment >>=20 >> Failed (-5) >> In: serial >> Out: serial >> Err: serial >> Net: phy interface7 >> eth0: ethernet@1c30000 >> starting USB... >> USB0: USB EHCI 1.00 >> USB1: USB OHCI 1.0 >> scanning bus 0 for devices... 1 USB Device(s) found >> scanning usb for storage devices... 0 Storage Device(s) found >> Hit any key to stop autoboot: 0=20 >> switch to partitions #0, OK >> mmc0(part 0) is current device >> Scanning mmc 0:1... >> Found EFI removable media binary efi/boot/bootaa64.efi >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> Scanning disks on usb... >> Disk usb0 not ready >> Disk usb1 not ready >> Disk usb2 not ready >> Disk usb3 not ready >> Scanning disks on mmc... >> MMC Device 1 not found >> MMC Device 2 not found >> MMC Device 3 not found >> Found 3 disks >> 477384 bytes read in 25 ms (18.2 MiB/s) >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> ## Starting EFI application at 40080000 ... >> Consoles: EFI console =20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >>=20 >> Command line arguments: loader.efi >> EFI version: 2.70 >> EFI Firmware: Das U-Boot (rev 0.00) >> Console: efi (0) >> Load Path: /\efi\boot\bootaa64.efi >> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) >> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) >> Setting currdev to disk0p1: >> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24= 400,0xe600000) >> Setting currdev to disk0p2: >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel text=3D0x8ce84a data=3D0x148020+0x72caac = syms=3D[0x8+0x11d000+0x8+0x1108a8] >> /boot/entropy size=3D0x1000 >> /boot/kernel/umodem.ko text=3D0x2168 text=3D0x1410 = data=3D0x102d0+0xfd40 syms=3D[0x8+0xf30+0x8+0xb73] >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel] in 9 seconds...=20 >>=20 >> Type '?' for a list of commands, 'help' for more detailed help. >> OK boot -v >> Booting... >> Using DTB provided by EFI at 0x47ffc000. >> EHCI failed to shut down host controller. >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Type Physical Virtual #Pages Attr >> ConventionalMemory 000040000000 40000000 00007ffc WB=20 >> Reserved 000047ffc000 47ffc000 00000003 WB=20 >> RuntimeServicesData 000047fff000 47fff000 00000001 WB RUNTIME >> Reserved 000048000000 48000000 00000003 WB=20 >> RuntimeServicesData 000048003000 48003000 00000001 WB RUNTIME >> ConventionalMemory 000048005000 40000000 00068ea1 WB=20 >> LoaderData 0000b0ea6000 b0ea6000 00000001 WB=20 >> Reserved 0000b0ea7000 b0ea7000 00000001 WB=20 >> Reserved 0000b0ea8000 b0ea8000 00000001 WB=20 >> LoaderData 0000b0ea9000 b0ea9000 00004000 WB=20 >> LoaderData 0000b4ea9000 b4ea9000 00004000 WB=20 >> LoaderCode 0000b8ea9000 b8ea9000 00000075 WB=20 >> Reserved 0000b8f1e000 b8f1e000 00000001 WB=20 >> Reserved 0000b8f1f000 b8f1f000 00000001 WB=20 >> RuntimeServicesData 0000b8f20000 b8f20000 00000001 WB RUNTIME >> Reserved 0000b8f21000 b8f21000 00000001 WB=20 >> Reserved 0000b8f22000 b8f22000 00000001 WB=20 >> Reserved 0000b8f23000 b8f23000 00000001 WB=20 >> Reserved 0000b8f24000 b8f24000 00000001 WB=20 >> LoaderData 0000b8f25000 b8f25000 00005094 WB=20 >> RuntimeServicesCode 0000bdfb9000 bdfb9000 00000002 WB RUNTIME >> LoaderData 0000bdfbb000 b8f25000 00002045 WB=20 >> Physical memory chunk(s): >> 0x40000000 - 0x47ffbfff, 127 MB ( 32764 pages) >> 0x47fff000 - 0x47ffffff, 0 MB ( 1 pages) >> 0x48003000 - 0x48003fff, 0 MB ( 1 pages) >> 0x48005000 - 0xb0ea6fff, 1678 MB ( 429730 pages) >> 0xb0ea9000 - 0xb8f1dfff, 128 MB ( 32885 pages) >> 0xb8f20000 - 0xb8f20fff, 0 MB ( 1 pages) >> 0xb8f25000 - 0xbdfb8fff, 80 MB ( 20628 pages) >> 0xbdfbb000 - 0xbfffffff, 32 MB ( 8261 pages) >> Excluded memory regions: >> 0x47ffc000 - 0x48003fff, 0 MB ( 8 pages) NoAlloc=20 >> 0xb0ea7000 - 0xb0ea8fff, 0 MB ( 2 pages) NoAlloc=20 >> 0xb1000000 - 0xb25e1fff, 21 MB ( 5602 pages) NoAlloc=20 >> 0xb8f1e000 - 0xb8f24fff, 0 MB ( 7 pages) NoAlloc=20 >> 0xbdfb9000 - 0xbdfbafff, 0 MB ( 2 pages) NoAlloc=20 >> Found 4 CPUs in the device tree >> Copyright (c) 1992-2018 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 12.0-CURRENT r337347M arm64 >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) >> VT: init without driver. >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000. >> Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020. >> Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078. >> KLD file umodem.ko is missing dependencies >> Starting CPU 1 (1) >> Starting CPU 2 (2) >> Starting CPU 3 (3) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: read 3840 bytes from preloaded cache >> random: unblocking device. >> arc4random: read 32 bytes from preloaded cache >> VIMAGE (virtualized network stack) enabled >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> ULE: setup cpu 2 >> ULE: setup cpu 3 >> random: entropy device external interface >> MAP 47fff000 mode 2 pages 1 >> MAP 48003000 mode 2 pages 1 >> MAP b8f20000 mode 2 pages 1 >> MAP bdfb9000 mode 2 pages 2 >> nfslock: pseudo-device >> crypto: >> kbd0 at kbdmux0 >> mem: >> null: >> openfirm: >> random: harvesting attach, 8 bytes (4 bits) from nexus0 >> ofwbus0: >> clk_fixed0: on ofwbus0 >> random: harvesting attach, 8 bytes (4 bits) from clk_fixed0 >> clk_fixed1: on ofwbus0 >> random: harvesting attach, 8 bytes (4 bits) from clk_fixed1 >> clk_fixed2: on ofwbus0 >> random: harvesting attach, 8 bytes (4 bits) from clk_fixed2 >> simplebus0: on ofwbus0 >> ccu_a64ng0: mem = 0x1c20000-0x1c203ff on simplebus0 >> ccu_a64ng0: Setting pll_periph0 as parent for ahb1 >> ccu_a64ng0: Setting pll_periph0 as parent for ahb2 >> ccu_a64ng0: Setting pll_ddr0 as parent for dram >> Clock: pll_cpux, parent: osc24M(0), freq: 816000000 >> Clock: pll_audio, parent: osc24M(0), freq: 24571428 >> Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000 >> Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000 >> Clock: pll_ddr0, parent: osc24M(0), freq: 408000000 >> Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000 >> Clock: pll_video0, parent: osc24M(0), freq: 30303 >> Clock: pll_video1, parent: osc24M(0), freq: 30303 >> Clock: pll_ve, parent: osc24M(0), freq: 30303 >> Clock: pll_gpu, parent: osc24M(0), freq: 30303 >> Clock: pll_de, parent: osc24M(0), freq: 30303 >> Clock: pll_hsic, parent: osc24M(0), freq: 1200000 >> Clock: apb2, parent: osc24M(1), freq: 24000000 >> Clock: nand, parent: osc24M(0), freq: 24000000 >> Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000 >> Clock: mmc1, parent: osc24M(0), freq: 24000000 >> Clock: mmc2, parent: osc24M(0), freq: 24000000 >> Clock: ts, parent: osc24M(0), freq: 24000000 >> Clock: ce, parent: osc24M(0), freq: 24000000 >> Clock: spi0, parent: osc24M(0), freq: 24000000 >> Clock: spi1, parent: osc24M(0), freq: 24000000 >> Clock: spdif, parent: pll_audio(0), freq: 24571428 >> Clock: dram, parent: pll_ddr0(0), freq: 408000000 >> Clock: de, parent: pll_periph0_2x(0), freq: 600000000 >> Clock: deinterlace, parent: pll_periph0(0), freq: 300000000 >> Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000 >> Clock: csi-mclk, parent: osc24M(0), freq: 24000000 >> Clock: ve, parent: pll_ve(0), freq: 30303 >> Clock: hdmi, parent: pll_video0(0), freq: 30303 >> Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000 >> Clock: gpu, parent: pll_gpu(0), freq: 30303 >> Clock: ahb1, parent: pll_periph0(3), freq: 300000000 >> Clock: ahb2, parent: pll_periph0(1), freq: 150000000 >> Clock: cpux, parent: pll_cpux(2), freq: 816000000 >> Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424 >> Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424 >> Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424 >> Clock: axi, parent: cpux(0), freq: 204000000 >> Clock: apb1, parent: ahb1(0), freq: 75000000 >> Clock: apb, parent: cpux(0), freq: 272000000 >> Clock: thsdiv, parent: osc24M(0), freq: 12000000 >> Clock: osc12M, parent: osc24M(0), freq: 12000000 >> Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000 >> Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000 >> Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856 >> Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712 >> Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424 >> Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000 >> Clock: bus-ce, parent: ahb1(0), freq: 300000000 >> Clock: bus-dma, parent: ahb1(0), freq: 300000000 >> Clock: bus-mmc0, parent: ahb1(0), freq: 300000000 >> Clock: bus-mmc1, parent: ahb1(0), freq: 300000000 >> Clock: bus-mmc2, parent: ahb1(0), freq: 300000000 >> Clock: bus-nand, parent: ahb1(0), freq: 300000000 >> Clock: bus-dram, parent: ahb1(0), freq: 300000000 >> Clock: bus-emac, parent: ahb2(0), freq: 150000000 >> Clock: bus-ts, parent: ahb1(0), freq: 300000000 >> Clock: bus-hstimer, parent: ahb1(0), freq: 300000000 >> Clock: bus-spi0, parent: ahb1(0), freq: 300000000 >> Clock: bus-spi1, parent: ahb1(0), freq: 300000000 >> Clock: bus-otg, parent: ahb1(0), freq: 300000000 >> Clock: bus-ehci0, parent: ahb1(0), freq: 300000000 >> Clock: bus-ehci1, parent: ahb2(0), freq: 150000000 >> Clock: bus-ohci0, parent: ahb1(0), freq: 300000000 >> Clock: bus-ohci1, parent: ahb2(0), freq: 150000000 >> Clock: bus-ve, parent: ahb1(0), freq: 300000000 >> Clock: bus-tcon0, parent: ahb1(0), freq: 300000000 >> Clock: bus-tcon1, parent: ahb1(0), freq: 300000000 >> Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000 >> Clock: bus-csi, parent: ahb1(0), freq: 300000000 >> Clock: bus-hdmi, parent: ahb1(0), freq: 300000000 >> Clock: bus-de, parent: ahb1(0), freq: 300000000 >> Clock: bus-gpu, parent: ahb1(0), freq: 300000000 >> Clock: bus-msgbox, parent: ahb1(0), freq: 300000000 >> Clock: bus-spinlock, parent: ahb1(0), freq: 300000000 >> Clock: bus-codec, parent: apb1(0), freq: 75000000 >> Clock: bus-spdif, parent: apb1(0), freq: 75000000 >> Clock: bus-pio, parent: apb1(0), freq: 75000000 >> Clock: bus-ths, parent: apb1(0), freq: 75000000 >> Clock: bus-i2s0, parent: apb1(0), freq: 75000000 >> Clock: bus-i2s1, parent: apb1(0), freq: 75000000 >> Clock: bus-i2s2, parent: apb1(0), freq: 75000000 >> Clock: bus-i2c0, parent: apb2(0), freq: 24000000 >> Clock: bus-i2c1, parent: apb2(0), freq: 24000000 >> Clock: bus-i2c2, parent: apb2(0), freq: 24000000 >> Clock: bus-src, parent: apb2(0), freq: 24000000 >> Clock: bus-uart0, parent: apb2(0), freq: 24000000 >> Clock: bus-uart1, parent: apb2(0), freq: 24000000 >> Clock: bus-uart2, parent: apb2(0), freq: 24000000 >> Clock: bus-uart3, parent: apb2(0), freq: 24000000 >> Clock: bus-uart4, parent: apb2(0), freq: 24000000 >> Clock: bus-dbg, parent: ahb1(0), freq: 300000000 >> Clock: ths, parent: thsdiv(0), freq: 12000000 >> Clock: usb-phy0, parent: osc24M(0), freq: 24000000 >> Clock: usb-phy1, parent: osc24M(0), freq: 24000000 >> Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000 >> Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000 >> Clock: usb-ohci0, parent: osc12M(0), freq: 12000000 >> Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000 >> Clock: dram-ve, parent: dram(0), freq: 408000000 >> Clock: dram-csi, parent: dram(0), freq: 408000000 >> Clock: dram-deinterlace, parent: dram(0), freq: 408000000 >> Clock: dram-ts, parent: dram(0), freq: 408000000 >> Clock: csi-misc, parent: osc24M(0), freq: 24000000 >> Clock: ac-dig, parent: pll_audio(0), freq: 24571428 >> Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712 >> Clock: avs, parent: osc24M(0), freq: 24000000 >> Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000 >> random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0 >> iichb0: mem = 0x1c2b000-0x1c2b3ff irq 21 on simplebus0 >> iicbus0: on iichb0 >> random: harvesting attach, 8 bytes (4 bits) from iicbus0 >> random: harvesting attach, 8 bytes (4 bits) from iichb0 >> random: harvesting attach, 8 bytes (4 bits) from simplebus0 >> regfix0: on ofwbus0 >> random: harvesting attach, 8 bytes (4 bits) from regfix0 >> random: harvesting attach, 8 bytes (4 bits) from ofwbus0 >> ccu_sun8i_r0: mem = 0x1f01400-0x1f014ff on simplebus0 >> Clock: ar100, parent: osc32k(0), freq: 32768 >> Clock: apb0, parent: ahb0(0), freq: 32768 >> Clock: ahb0, parent: ar100(0), freq: 32768 >> Clock: ir, parent: osc32k(0), freq: 32768 >> Clock: apb0-pio, parent: apb0(0), freq: 32768 >> Clock: apb0-ir, parent: apb0(0), freq: 32768 >> Clock: apb0-timer, parent: apb0(0), freq: 32768 >> Clock: apb0-rsb, parent: apb0(0), freq: 32768 >> Clock: apb0-uart, parent: apb0(0), freq: 32768 >> Clock: apb0-i2c, parent: apb0(0), freq: 32768 >> Clock: apb0-twd, parent: apb0(0), freq: 32768 >> random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0 >> psci0: on ofwbus0 >> psci0: PSCI version 0.2 compatible >> random: harvesting attach, 8 bytes (4 bits) from psci0 >> gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 23 on simplebus0 >> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 >> random: harvesting attach, 8 bytes (4 bits) from gic0 >> gpio0: mem 0x1c20800-0x1c20bff irq = 12,13,14 on simplebus0 >> gpiobus0: on gpio0 >> random: harvesting attach, 8 bytes (4 bits) from gpiobus0 >> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >> random: harvesting attach, 8 bytes (4 bits) from gpio0 >> gpio1: mem 0x1f02c00-0x1f02fff irq = 26 on simplebus0 >> gpiobus1: on gpio1 >> random: harvesting attach, 8 bytes (4 bits) from gpiobus1 >> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >> random: harvesting attach, 8 bytes (4 bits) from gpio1 >> generic_timer0: irq 0,1,2,3 on ofwbus0 >> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 >> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >> random: harvesting attach, 8 bytes (4 bits) from generic_timer0 >> rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 >> rtc0: Using external oscillator >> rtc0: registered as a time-of-day clock, resolution 1.000000s >> random: harvesting attach, 8 bytes (4 bits) from rtc0 >> awusbphy0: mem = 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 >> random: harvesting attach, 8 bytes (4 bits) from awusbphy0 >> efirtc0: cannot read EFI realtime clock >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpu0: missing 'clock-frequency' property >> arm64_cpu0: register <0> >> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0 >> random: harvesting attach, 8 bytes (4 bits) from cpu0 >> cpu1: on cpulist0 >> cpu1: missing 'clock-frequency' property >> arm64_cpu1: register <1> >> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1 >> random: harvesting attach, 8 bytes (4 bits) from cpu1 >> cpu2: on cpulist0 >> cpu2: missing 'clock-frequency' property >> arm64_cpu2: register <2> >> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2 >> random: harvesting attach, 8 bytes (4 bits) from cpu2 >> cpu3: on cpulist0 >> cpu3: missing 'clock-frequency' property >> arm64_cpu3: register <3> >> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3 >> random: harvesting attach, 8 bytes (4 bits) from cpu3 >> random: harvesting attach, 8 bytes (4 bits) from cpulist0 >> aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 >> aw_mmc0: vmmc-supply regulator found >> mmc0: on aw_mmc0 >> random: harvesting attach, 8 bytes (4 bits) from mmc0 >> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 >> simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled = compat allwinner,sun50i-a64-mmc (no driver attached) >> simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled = compat allwinner,sun50i-a64-emmc (no driver attached) >> simplebus0: mem 0x1c19000-0x1c193ff irq 7 compat = allwinner,sun8i-a33-musb (no driver attached) >> simplebus0: mem 0x1c1a000-0x1c1a0ff irq 8 disabled = compat allwinner,sun50i-a64-ehci (no driver attached) >> simplebus0: mem 0x1c1a400-0x1c1a4ff irq 9 disabled = compat allwinner,sun50i-a64-ohci (no driver attached) >> ehci0: mem = 0x1c1b000-0x1c1b0ff irq 10 on simplebus0 >> usbus0: EHCI version 1.0 >> usbus0 on ehci0 >> ehci0: usbpf: Attached >> random: harvesting attach, 8 bytes (4 bits) from usbus0 >> random: harvesting attach, 8 bytes (4 bits) from ehci0 >> ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on = simplebus0 >> usbus1 on ohci0 >> ohci0: usbpf: Attached >> random: harvesting attach, 8 bytes (4 bits) from usbus1 >> random: harvesting attach, 8 bytes (4 bits) from ohci0 >> gpioc0: on gpio0 >> random: harvesting attach, 8 bytes (4 bits) from gpioc0 >> simplebus0: mem 0x1c21400-0x1c21407 disabled compat = allwinner,sun50i-a64-pwm (no driver attached) >> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on = simplebus0 >> uart0: console (115384,n,8,1) >> uart0: fast interrupt >> uart0: PPS capture mode: DCD >> random: harvesting attach, 8 bytes (4 bits) from uart0 >> simplebus0: mem 0x1c28400-0x1c287ff irq 16 disabled = compat snps,dw-apb-uart (no driver attached) >> simplebus0: mem 0x1c28800-0x1c28bff irq 17 disabled = compat snps,dw-apb-uart (no driver attached) >> simplebus0: mem 0x1c28c00-0x1c28fff irq 18 disabled = compat snps,dw-apb-uart (no driver attached) >> simplebus0: mem 0x1c29000-0x1c293ff irq 19 disabled = compat snps,dw-apb-uart (no driver attached) >> simplebus0: mem 0x1c2ac00-0x1c2afff irq 20 disabled = compat allwinner,sun6i-a31-i2c (no driver attached) >> iic0: on iicbus0 >> random: harvesting attach, 8 bytes (4 bits) from iic0 >> simplebus0: mem 0x1c2b400-0x1c2b7ff irq 22 disabled = compat allwinner,sun6i-a31-i2c (no driver attached) >> gpioc1: on gpio1 >> random: harvesting attach, 8 bytes (4 bits) from gpioc1 >> syscon_generic0: mem 0x1c00000-0x1c00fff on simplebus0 >> random: harvesting attach, 8 bytes (4 bits) from syscon_generic0 >> awg0: mem 0x1c30000-0x1c3ffff irq 27 on = simplebus0 >> simplebus0: no default resources for rid =3D 1, type =3D 3 >> awg0: PHY type: rgmii, conf mode: reg >> awg0: EMAC clock: 0x00000006 >> awg0: AHB frequency 150000000 Hz, MDC div: 0x2 >> miibus0: on awg0 >> rgephy0: PHY 0 on = miibus0 >> rgephy0: OUI 0x00e04c, model 0x0011, rev. 5 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >> random: harvesting attach, 8 bytes (4 bits) from rgephy0 >> rgephy1: PHY 1 on = miibus0 >> rgephy1: OUI 0x00e04c, model 0x0011, rev. 5 >> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >> random: harvesting attach, 8 bytes (4 bits) from rgephy1 >> random: harvesting attach, 8 bytes (4 bits) from miibus0 >> awg0: bpf attached >> awg0: Ethernet address: 02:ba:b1:c5:93:b7 >> random: harvesting attach, 8 bytes (4 bits) from awg0 >> cryptosoft0: >> crypto: assign cryptosoft0 driver id 0, flags 0x6000000 >> crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0 >> random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 >> Found SMCCC version 1.0 >> Device configuration finished. >> procfs registered >> Timecounters tick every 1.000 msec >> vlan: initialized, using hash tables with chaining >> lo0: bpf attached >> arc4random: read 32 bytes from preloaded cache >> arc4random: read 32 bytes from preloaded cache >> arc4random: read 32 bytes from preloaded cache >> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384 >> IPsec: Initialized Security Association Processing. >> usbus0: 480Mbps High Speed USB v2.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> aw_mmc0: Powering up sd/mmc >> mmc0: Probing bus >> ugen0.1: at usbus0 >> uhub0: on = usbus0 >> ugen1.1: at usbus1 >> uhub1: on = usbus1 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> mmc0: SD probe: failed >> mmc0: MMC probe: OK (OCR: 0x40ff8080) >> mmc0: Current OCR: 0x00ff8080 >> mmc0: Probing cards >> mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f) >> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >> aw_mmc0: error rint: 0x00008010 >> AW_MMC_INT_DATA_END_BIT_ERR >> mmc0: Card at relative address 0x0002 added: >> mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 >> mmc0: quirks: 0 >> mmc0: bus: 4bit, 200MHz (HS200 timing) The above is where I got the HS200. (I had to look up the details for this note.) >> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> aw_mmc0: error rint: 0x00000100 >> AW_MMC_INT_RESP_TIMEOUT=20 >> mmc0: setting transfer rate to 52.000MHz (dual data rate timing) >> mmc0: Failed to set VCCQ for card at relative address 2 >=20 > So the driver is selecting DDR52 transfer rate but, of course, > cannot switch the IO voltage to 1.8V as on this board the IO voltage > for the SD card is tied to 3.3V As I understand the following is allowed for e.MMC in all/most vintages of the standard: High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz So no need for 1.8 V or 1.2 V for that much. This is not the HS200 mode that the output references. But the reference is probably just indicate what the e.MMC itself allows as the fastest speed, not indicating the limitations of the context of the connection. >> uhub1: 1 port with 1 removable, self powered >> random: harvesting attach, 8 bytes (4 bits) from uhub1 >> uhub0: 1 port with 1 removable, self powered >> random: harvesting attach, 8 bytes (4 bits) from uhub0 >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> aw_mmc0: controller timeout >> aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 >>=20 >> mmcsd0: Error reading EXT_CSD Timeout >=20 > This seems weird, I have a board with an eMMC IO voltage tied to 3.3V > (Olinuxino-A64), I'll try HEAD on this board. >=20 >> device_attach: mmcsd0 attach returned 6 >> Release APs...done >> Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs = [rw,noatime]... >> CPU 0: ARM Cortex-A53 r0p4mountroot: waiting for device = /dev/ufs/PINE64P2Grootfs... >> affinity: 0 >> Instruction Set Attributes 0 =3D >> Instruction Set Attributes 1 =3D <> >> Processor Features 0 =3D >> Processor Features 1 =3D <0> >> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> >> Memory Model Features 1 =3D <> >> Memory Model Features 2 =3D <32b CCIDX,48b VA> >> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> >> Debug Features 1 =3D <0> >> Auxiliary Features 0 =3D <0> >> Auxiliary Features 1 =3D <0> >> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 >> CPU 2: ARM Cortex-A53 r0p4 affinity: 2 >> CPU 3: ARM Cortex-A53 r0p4 affinity: 3 >> regulator: shutting down vcc3v3 >> Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19. >>=20 >> Loader variables: >> vfs.root.mountfrom=3Dufs:/dev/ufs/PINE64P2Grootfs >> vfs.root.mountfrom.options=3Drw,noatime >>=20 >> Manual root filesystem specification: >> : [options] >> Mount using filesystem >> and with the specified (optional) option list. >>=20 >> eg. ufs:/dev/da0s1a >> zfs:tank >> cd9660:/dev/cd0 ro >> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>=20 >> ? List valid disk boot devices >> . Yield 1 second (for background tasks) >> Abort manual input >>=20 >> mountroot>=20 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 6 18:40:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A38151061741 for ; Mon, 6 Aug 2018 18:40:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DDAD83917 for ; Mon, 6 Aug 2018 18:40:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: kUeegtEVM1lEnGe4iNDe1PPeu_k_5e1NGTLto133SFIclZbTjqXS4RzatsuNPYa b3jh8IzWcQiqzTqSSZkPkVNSFyYpdC9oHhuKx8dMW6Z0cZaOBR1HWi224l0T3EPq7wa6.sX0IctO FD6XKM_hX83rZKSK.mUQ_Osakk.UqtT5PnF5JQO8ocPjySop8.iYB51zrfuJam3VFixAw.2tFf1M 6TxqrUp9T3tdrBZ3fFAIGRPbRZCKTS6OO2V3D5y57.6_Jozk3vpdx1vDkvQFI0RxE8SXxeV.RXpK 1nRs0_pleyt_c5Q2pooIPZVWwta1FqEmlN1S59YYn1ZK1uuUjyT65mcj2TSELw3.o3kG5U8BXoQc 26kxIUhK1bl_AuzelLEnUcP0dITDHuwh1915kqzKDe_5OhrUZT9NLbcPLuJMH.zT5R9LPTHUdxuf X4jql0Yzh2nacGpinOkEtQjNpD2tpWUS1ZOvKNuA.NPxgYBIeytC0LXC3WWCEBTjy9xiv.eQFwJg 8jFHAyKTDMFs.s510jAC60gGr8QJsXQCtqsjzxj7UNZKKSZY6D087O0Fssblw86RIbBf6Ik3VRxu uXK_t0iRrw2fcSY9B3YKsVahnI9zFk1hkFVEkjU_gP6vJ20pWC4_uyE0Q69_U6ZMlyt50AmwVwgS mjEYlIPCp_ETvV22r5WVrM3Y9sATSeRmmOFRRIIdv2mP2QWqWzEJ2OtBFlMbGJlQFyn9GxqOJYxA SeDxo2tW1A1hsFFyVB1vvWzsquVM5_fPXewVXtdS2fhyqPM.Hjjm8DCpEvDHR3v7ZwiMSqOsjwGs SmMhOuPirYK4pKGv6mV7ZaaZAWlZDAwg8D0Ammuo.O5iPj8o4n.0q71AZF03Db2iUPYROr4M4TF7 anBRgalGGxPHnGoPDJLBJvrway.JPvL9f5l5BHMIR8tqaW171x_PAkkpYHcOSOVLbCtsv791QL_s QM2y4J_pu3lVlKqbM3vtHhVoroP2f0BIIaCX.J_74snR5y2Y.56LcwyJiOQFJGMYtiiBkvuqRDXn W.3.xoiApHU2_p3RWsVtp_cwEm6tJnCL05nQhO9uR84abknbd_bAS6rVdjIc3PH1cZ1WMAmji1KW 9t8D3oqLDZvAyOQtB Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Aug 2018 18:39:57 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0b547705ac48bb2f0149ec983863b4a8; Mon, 06 Aug 2018 18:39:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> Date: Mon, 6 Aug 2018 11:39:51 -0700 Cc: Mark Millard via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 18:40:05 -0000 [Fixing a confusing "slower" reference . . .] On 2018-Aug-6, at 11:26 AM, Mark Millard wrote: > On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot = wrote: >=20 >> On Mon, 6 Aug 2018 10:12:43 -0700 >> Mark Millard wrote: >>=20 >>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot = wrote: >>>=20 >>>> On Mon, 6 Aug 2018 02:48:57 -0700 >>>> Mark Millard via freebsd-arm wrote: >>>>=20 >>>>> I amd64 -> aarch64 cross built -r337347 and installed it >>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as >>>>> bootaa64.efi) as an update. My attempted synchronization >>>>> of loader.conf and ttys and devd.conf may be incorrect. >>>>> (Previous to this the Pine64+ 2GB seemed to be working >>>>> okay but it was at a very old build.) >>>>>=20 >>>>> The kernel config has GENERIC included but the various >>>>> debug features disabled. (My typical operating >>>>> environment.) >>>>>=20 >>>>> For all I know what the below shows might be expected >>>>> at this point. The kernel seems to have problems with >>>>> the MMC (that the kernel was loaded from). No other >>>>> media are attached. mmcsd0 is really an 128 GiByte >>>>> emmc on an adapter. (This historically worked for me.) >>>>=20 >>>> emmc to sd ? that's weird ... >>>=20 >>> An example of the adapter I've used for this is: >>>=20 >>> = https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-= adapter >>=20 >> So this is a passive adapter, maybe that's something that should work >> but it's definitly is something that calls for problems. >>=20 >>> emmc is multi-mode for its allowed modes of operation. Thus >>> its ability to frequently be used this way, such as via HS200. >>> emmc is commonly more robust as I understand. >>=20 >> I didn't understand a word. >=20 > I got the HS200 reference from the boot -v output. Such is currently = from the > JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC > members have free access, others do not.) >=20 > The output reported: >=20 > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 > mmc0: quirks: 0 > mmc0: bus: 4bit, 200MHz (HS200 timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks >=20 > The e.MMC bus speed modes with I/O Voltage 3V allowed are: >=20 > Backwards Compatibility with legacy MMC card, data rate single, 3V = allowed, bus widths 1,4,8, 0-26 MHz >=20 > High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 = MHz >=20 > High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz >=20 > (The last being the fastest for maximum transfer rate with 3V.) >=20 > There is another 1.8V/1.2V mode: HS400 that is dual data rate and = always 8 bit, > unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. = HS400 > is optional and sufficiently old e.MMC standard vintages would likely = not > even have it. >=20 > So a slower 3.? V mode of use used to be selected (based on the = constraints > on the board's voltages in some way, possibly hard coded). "slower" lacks context: I should have said . . . "a slower than HS200 3.? V mode" As I remember, the 3V range is from 2.7 V to 3.6 V or some such. So 3.3 V would be in range, at least if I remember right. >>>=20 >>> (I had to modify the case the pine64+ 2GB is in in order for >>> the adapter/emmc combination to fit in all the way.) >>>=20 >>>> Can you boot -v and post the result please ? >>>=20 >>> Glad to . . . >>>=20 >>> DRAM: 2048 MiB >>> Trying to boot from MMC1 >>>=20 >>>=20 >>> U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000) >>> DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology >>>=20 >>> CPU: Allwinner A64 (SUN50I) >>> Model: Pine64+ >>> DRAM: 2 GiB >>> MMC: SUNXI SD/MMC: 0 >>> Loading Environment from FAT... *** Warning - bad CRC, using default = environment >>>=20 >>> Failed (-5) >>> In: serial >>> Out: serial >>> Err: serial >>> Net: phy interface7 >>> eth0: ethernet@1c30000 >>> starting USB... >>> USB0: USB EHCI 1.00 >>> USB1: USB OHCI 1.0 >>> scanning bus 0 for devices... 1 USB Device(s) found >>> scanning usb for storage devices... 0 Storage Device(s) found >>> Hit any key to stop autoboot: 0=20 >>> switch to partitions #0, OK >>> mmc0(part 0) is current device >>> Scanning mmc 0:1... >>> Found EFI removable media binary efi/boot/bootaa64.efi >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>> Scanning disks on usb... >>> Disk usb0 not ready >>> Disk usb1 not ready >>> Disk usb2 not ready >>> Disk usb3 not ready >>> Scanning disks on mmc... >>> MMC Device 1 not found >>> MMC Device 2 not found >>> MMC Device 3 not found >>> Found 3 disks >>> 477384 bytes read in 25 ms (18.2 MiB/s) >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>> ## Starting EFI application at 40080000 ... >>> Consoles: EFI console =20 >>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>=20 >>> Command line arguments: loader.efi >>> EFI version: 2.70 >>> EFI Firmware: Das U-Boot (rev 0.00) >>> Console: efi (0) >>> Load Path: /\efi\boot\bootaa64.efi >>> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) >>> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x40= 3b,0x1ffe0) >>> Setting currdev to disk0p1: >>> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24= 400,0xe600000) >>> Setting currdev to disk0p2: >>> Loading /boot/defaults/loader.conf >>> /boot/kernel/kernel text=3D0x8ce84a data=3D0x148020+0x72caac = syms=3D[0x8+0x11d000+0x8+0x1108a8] >>> /boot/entropy size=3D0x1000 >>> /boot/kernel/umodem.ko text=3D0x2168 text=3D0x1410 = data=3D0x102d0+0xfd40 syms=3D[0x8+0xf30+0x8+0xb73] >>>=20 >>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>> Booting [/boot/kernel/kernel] in 9 seconds...=20 >>>=20 >>> Type '?' for a list of commands, 'help' for more detailed help. >>> OK boot -v >>> Booting... >>> Using DTB provided by EFI at 0x47ffc000. >>> EHCI failed to shut down host controller. >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> Type Physical Virtual #Pages Attr >>> ConventionalMemory 000040000000 40000000 00007ffc WB=20 >>> Reserved 000047ffc000 47ffc000 00000003 WB=20 >>> RuntimeServicesData 000047fff000 47fff000 00000001 WB RUNTIME >>> Reserved 000048000000 48000000 00000003 WB=20 >>> RuntimeServicesData 000048003000 48003000 00000001 WB RUNTIME >>> ConventionalMemory 000048005000 40000000 00068ea1 WB=20 >>> LoaderData 0000b0ea6000 b0ea6000 00000001 WB=20 >>> Reserved 0000b0ea7000 b0ea7000 00000001 WB=20 >>> Reserved 0000b0ea8000 b0ea8000 00000001 WB=20 >>> LoaderData 0000b0ea9000 b0ea9000 00004000 WB=20 >>> LoaderData 0000b4ea9000 b4ea9000 00004000 WB=20 >>> LoaderCode 0000b8ea9000 b8ea9000 00000075 WB=20 >>> Reserved 0000b8f1e000 b8f1e000 00000001 WB=20 >>> Reserved 0000b8f1f000 b8f1f000 00000001 WB=20 >>> RuntimeServicesData 0000b8f20000 b8f20000 00000001 WB RUNTIME >>> Reserved 0000b8f21000 b8f21000 00000001 WB=20 >>> Reserved 0000b8f22000 b8f22000 00000001 WB=20 >>> Reserved 0000b8f23000 b8f23000 00000001 WB=20 >>> Reserved 0000b8f24000 b8f24000 00000001 WB=20 >>> LoaderData 0000b8f25000 b8f25000 00005094 WB=20 >>> RuntimeServicesCode 0000bdfb9000 bdfb9000 00000002 WB RUNTIME >>> LoaderData 0000bdfbb000 b8f25000 00002045 WB=20 >>> Physical memory chunk(s): >>> 0x40000000 - 0x47ffbfff, 127 MB ( 32764 pages) >>> 0x47fff000 - 0x47ffffff, 0 MB ( 1 pages) >>> 0x48003000 - 0x48003fff, 0 MB ( 1 pages) >>> 0x48005000 - 0xb0ea6fff, 1678 MB ( 429730 pages) >>> 0xb0ea9000 - 0xb8f1dfff, 128 MB ( 32885 pages) >>> 0xb8f20000 - 0xb8f20fff, 0 MB ( 1 pages) >>> 0xb8f25000 - 0xbdfb8fff, 80 MB ( 20628 pages) >>> 0xbdfbb000 - 0xbfffffff, 32 MB ( 8261 pages) >>> Excluded memory regions: >>> 0x47ffc000 - 0x48003fff, 0 MB ( 8 pages) NoAlloc=20 >>> 0xb0ea7000 - 0xb0ea8fff, 0 MB ( 2 pages) NoAlloc=20 >>> 0xb1000000 - 0xb25e1fff, 21 MB ( 5602 pages) NoAlloc=20 >>> 0xb8f1e000 - 0xb8f24fff, 0 MB ( 7 pages) NoAlloc=20 >>> 0xbdfb9000 - 0xbdfbafff, 0 MB ( 2 pages) NoAlloc=20 >>> Found 4 CPUs in the device tree >>> Copyright (c) 1992-2018 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>> The Regents of the University of California. All rights = reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 12.0-CURRENT r337347M arm64 >>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based = on LLVM 6.0.1) >>> VT: init without driver. >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000. >>> Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020. >>> Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078. >>> KLD file umodem.ko is missing dependencies >>> Starting CPU 1 (1) >>> Starting CPU 2 (2) >>> Starting CPU 3 (3) >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> random: read 3840 bytes from preloaded cache >>> random: unblocking device. >>> arc4random: read 32 bytes from preloaded cache >>> VIMAGE (virtualized network stack) enabled >>> ULE: setup cpu 0 >>> ULE: setup cpu 1 >>> ULE: setup cpu 2 >>> ULE: setup cpu 3 >>> random: entropy device external interface >>> MAP 47fff000 mode 2 pages 1 >>> MAP 48003000 mode 2 pages 1 >>> MAP b8f20000 mode 2 pages 1 >>> MAP bdfb9000 mode 2 pages 2 >>> nfslock: pseudo-device >>> crypto: >>> kbd0 at kbdmux0 >>> mem: >>> null: >>> openfirm: >>> random: harvesting attach, 8 bytes (4 bits) from nexus0 >>> ofwbus0: >>> clk_fixed0: on ofwbus0 >>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed0 >>> clk_fixed1: on ofwbus0 >>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed1 >>> clk_fixed2: on ofwbus0 >>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed2 >>> simplebus0: on ofwbus0 >>> ccu_a64ng0: mem = 0x1c20000-0x1c203ff on simplebus0 >>> ccu_a64ng0: Setting pll_periph0 as parent for ahb1 >>> ccu_a64ng0: Setting pll_periph0 as parent for ahb2 >>> ccu_a64ng0: Setting pll_ddr0 as parent for dram >>> Clock: pll_cpux, parent: osc24M(0), freq: 816000000 >>> Clock: pll_audio, parent: osc24M(0), freq: 24571428 >>> Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000 >>> Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000 >>> Clock: pll_ddr0, parent: osc24M(0), freq: 408000000 >>> Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000 >>> Clock: pll_video0, parent: osc24M(0), freq: 30303 >>> Clock: pll_video1, parent: osc24M(0), freq: 30303 >>> Clock: pll_ve, parent: osc24M(0), freq: 30303 >>> Clock: pll_gpu, parent: osc24M(0), freq: 30303 >>> Clock: pll_de, parent: osc24M(0), freq: 30303 >>> Clock: pll_hsic, parent: osc24M(0), freq: 1200000 >>> Clock: apb2, parent: osc24M(1), freq: 24000000 >>> Clock: nand, parent: osc24M(0), freq: 24000000 >>> Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000 >>> Clock: mmc1, parent: osc24M(0), freq: 24000000 >>> Clock: mmc2, parent: osc24M(0), freq: 24000000 >>> Clock: ts, parent: osc24M(0), freq: 24000000 >>> Clock: ce, parent: osc24M(0), freq: 24000000 >>> Clock: spi0, parent: osc24M(0), freq: 24000000 >>> Clock: spi1, parent: osc24M(0), freq: 24000000 >>> Clock: spdif, parent: pll_audio(0), freq: 24571428 >>> Clock: dram, parent: pll_ddr0(0), freq: 408000000 >>> Clock: de, parent: pll_periph0_2x(0), freq: 600000000 >>> Clock: deinterlace, parent: pll_periph0(0), freq: 300000000 >>> Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000 >>> Clock: csi-mclk, parent: osc24M(0), freq: 24000000 >>> Clock: ve, parent: pll_ve(0), freq: 30303 >>> Clock: hdmi, parent: pll_video0(0), freq: 30303 >>> Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000 >>> Clock: gpu, parent: pll_gpu(0), freq: 30303 >>> Clock: ahb1, parent: pll_periph0(3), freq: 300000000 >>> Clock: ahb2, parent: pll_periph0(1), freq: 150000000 >>> Clock: cpux, parent: pll_cpux(2), freq: 816000000 >>> Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424 >>> Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424 >>> Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424 >>> Clock: axi, parent: cpux(0), freq: 204000000 >>> Clock: apb1, parent: ahb1(0), freq: 75000000 >>> Clock: apb, parent: cpux(0), freq: 272000000 >>> Clock: thsdiv, parent: osc24M(0), freq: 12000000 >>> Clock: osc12M, parent: osc24M(0), freq: 12000000 >>> Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000 >>> Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000 >>> Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856 >>> Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712 >>> Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424 >>> Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000 >>> Clock: bus-ce, parent: ahb1(0), freq: 300000000 >>> Clock: bus-dma, parent: ahb1(0), freq: 300000000 >>> Clock: bus-mmc0, parent: ahb1(0), freq: 300000000 >>> Clock: bus-mmc1, parent: ahb1(0), freq: 300000000 >>> Clock: bus-mmc2, parent: ahb1(0), freq: 300000000 >>> Clock: bus-nand, parent: ahb1(0), freq: 300000000 >>> Clock: bus-dram, parent: ahb1(0), freq: 300000000 >>> Clock: bus-emac, parent: ahb2(0), freq: 150000000 >>> Clock: bus-ts, parent: ahb1(0), freq: 300000000 >>> Clock: bus-hstimer, parent: ahb1(0), freq: 300000000 >>> Clock: bus-spi0, parent: ahb1(0), freq: 300000000 >>> Clock: bus-spi1, parent: ahb1(0), freq: 300000000 >>> Clock: bus-otg, parent: ahb1(0), freq: 300000000 >>> Clock: bus-ehci0, parent: ahb1(0), freq: 300000000 >>> Clock: bus-ehci1, parent: ahb2(0), freq: 150000000 >>> Clock: bus-ohci0, parent: ahb1(0), freq: 300000000 >>> Clock: bus-ohci1, parent: ahb2(0), freq: 150000000 >>> Clock: bus-ve, parent: ahb1(0), freq: 300000000 >>> Clock: bus-tcon0, parent: ahb1(0), freq: 300000000 >>> Clock: bus-tcon1, parent: ahb1(0), freq: 300000000 >>> Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000 >>> Clock: bus-csi, parent: ahb1(0), freq: 300000000 >>> Clock: bus-hdmi, parent: ahb1(0), freq: 300000000 >>> Clock: bus-de, parent: ahb1(0), freq: 300000000 >>> Clock: bus-gpu, parent: ahb1(0), freq: 300000000 >>> Clock: bus-msgbox, parent: ahb1(0), freq: 300000000 >>> Clock: bus-spinlock, parent: ahb1(0), freq: 300000000 >>> Clock: bus-codec, parent: apb1(0), freq: 75000000 >>> Clock: bus-spdif, parent: apb1(0), freq: 75000000 >>> Clock: bus-pio, parent: apb1(0), freq: 75000000 >>> Clock: bus-ths, parent: apb1(0), freq: 75000000 >>> Clock: bus-i2s0, parent: apb1(0), freq: 75000000 >>> Clock: bus-i2s1, parent: apb1(0), freq: 75000000 >>> Clock: bus-i2s2, parent: apb1(0), freq: 75000000 >>> Clock: bus-i2c0, parent: apb2(0), freq: 24000000 >>> Clock: bus-i2c1, parent: apb2(0), freq: 24000000 >>> Clock: bus-i2c2, parent: apb2(0), freq: 24000000 >>> Clock: bus-src, parent: apb2(0), freq: 24000000 >>> Clock: bus-uart0, parent: apb2(0), freq: 24000000 >>> Clock: bus-uart1, parent: apb2(0), freq: 24000000 >>> Clock: bus-uart2, parent: apb2(0), freq: 24000000 >>> Clock: bus-uart3, parent: apb2(0), freq: 24000000 >>> Clock: bus-uart4, parent: apb2(0), freq: 24000000 >>> Clock: bus-dbg, parent: ahb1(0), freq: 300000000 >>> Clock: ths, parent: thsdiv(0), freq: 12000000 >>> Clock: usb-phy0, parent: osc24M(0), freq: 24000000 >>> Clock: usb-phy1, parent: osc24M(0), freq: 24000000 >>> Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000 >>> Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000 >>> Clock: usb-ohci0, parent: osc12M(0), freq: 12000000 >>> Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000 >>> Clock: dram-ve, parent: dram(0), freq: 408000000 >>> Clock: dram-csi, parent: dram(0), freq: 408000000 >>> Clock: dram-deinterlace, parent: dram(0), freq: 408000000 >>> Clock: dram-ts, parent: dram(0), freq: 408000000 >>> Clock: csi-misc, parent: osc24M(0), freq: 24000000 >>> Clock: ac-dig, parent: pll_audio(0), freq: 24571428 >>> Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712 >>> Clock: avs, parent: osc24M(0), freq: 24000000 >>> Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000 >>> random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0 >>> iichb0: mem = 0x1c2b000-0x1c2b3ff irq 21 on simplebus0 >>> iicbus0: on iichb0 >>> random: harvesting attach, 8 bytes (4 bits) from iicbus0 >>> random: harvesting attach, 8 bytes (4 bits) from iichb0 >>> random: harvesting attach, 8 bytes (4 bits) from simplebus0 >>> regfix0: on ofwbus0 >>> random: harvesting attach, 8 bytes (4 bits) from regfix0 >>> random: harvesting attach, 8 bytes (4 bits) from ofwbus0 >>> ccu_sun8i_r0: mem = 0x1f01400-0x1f014ff on simplebus0 >>> Clock: ar100, parent: osc32k(0), freq: 32768 >>> Clock: apb0, parent: ahb0(0), freq: 32768 >>> Clock: ahb0, parent: ar100(0), freq: 32768 >>> Clock: ir, parent: osc32k(0), freq: 32768 >>> Clock: apb0-pio, parent: apb0(0), freq: 32768 >>> Clock: apb0-ir, parent: apb0(0), freq: 32768 >>> Clock: apb0-timer, parent: apb0(0), freq: 32768 >>> Clock: apb0-rsb, parent: apb0(0), freq: 32768 >>> Clock: apb0-uart, parent: apb0(0), freq: 32768 >>> Clock: apb0-i2c, parent: apb0(0), freq: 32768 >>> Clock: apb0-twd, parent: apb0(0), freq: 32768 >>> random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0 >>> psci0: on ofwbus0 >>> psci0: PSCI version 0.2 compatible >>> random: harvesting attach, 8 bytes (4 bits) from psci0 >>> gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 23 on simplebus0 >>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 >>> random: harvesting attach, 8 bytes (4 bits) from gic0 >>> gpio0: mem 0x1c20800-0x1c20bff = irq 12,13,14 on simplebus0 >>> gpiobus0: on gpio0 >>> random: harvesting attach, 8 bytes (4 bits) from gpiobus0 >>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >>> random: harvesting attach, 8 bytes (4 bits) from gpio0 >>> gpio1: mem 0x1f02c00-0x1f02fff = irq 26 on simplebus0 >>> gpiobus1: on gpio1 >>> random: harvesting attach, 8 bytes (4 bits) from gpiobus1 >>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000 >>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000 >>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000 >>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000 >>> random: harvesting attach, 8 bytes (4 bits) from gpio1 >>> generic_timer0: irq 0,1,2,3 on ofwbus0 >>> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 >>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >>> random: harvesting attach, 8 bytes (4 bits) from generic_timer0 >>> rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on = simplebus0 >>> rtc0: Using external oscillator >>> rtc0: registered as a time-of-day clock, resolution 1.000000s >>> random: harvesting attach, 8 bytes (4 bits) from rtc0 >>> awusbphy0: mem = 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 >>> random: harvesting attach, 8 bytes (4 bits) from awusbphy0 >>> efirtc0: cannot read EFI realtime clock >>> cpulist0: on ofwbus0 >>> cpu0: on cpulist0 >>> cpu0: missing 'clock-frequency' property >>> arm64_cpu0: register <0> >>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0 >>> random: harvesting attach, 8 bytes (4 bits) from cpu0 >>> cpu1: on cpulist0 >>> cpu1: missing 'clock-frequency' property >>> arm64_cpu1: register <1> >>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1 >>> random: harvesting attach, 8 bytes (4 bits) from cpu1 >>> cpu2: on cpulist0 >>> cpu2: missing 'clock-frequency' property >>> arm64_cpu2: register <2> >>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2 >>> random: harvesting attach, 8 bytes (4 bits) from cpu2 >>> cpu3: on cpulist0 >>> cpu3: missing 'clock-frequency' property >>> arm64_cpu3: register <3> >>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3 >>> random: harvesting attach, 8 bytes (4 bits) from cpu3 >>> random: harvesting attach, 8 bytes (4 bits) from cpulist0 >>> aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 >>> aw_mmc0: vmmc-supply regulator found >>> mmc0: on aw_mmc0 >>> random: harvesting attach, 8 bytes (4 bits) from mmc0 >>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 >>> simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled = compat allwinner,sun50i-a64-mmc (no driver attached) >>> simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled = compat allwinner,sun50i-a64-emmc (no driver attached) >>> simplebus0: mem 0x1c19000-0x1c193ff irq 7 compat = allwinner,sun8i-a33-musb (no driver attached) >>> simplebus0: mem 0x1c1a000-0x1c1a0ff irq 8 disabled = compat allwinner,sun50i-a64-ehci (no driver attached) >>> simplebus0: mem 0x1c1a400-0x1c1a4ff irq 9 disabled = compat allwinner,sun50i-a64-ohci (no driver attached) >>> ehci0: mem = 0x1c1b000-0x1c1b0ff irq 10 on simplebus0 >>> usbus0: EHCI version 1.0 >>> usbus0 on ehci0 >>> ehci0: usbpf: Attached >>> random: harvesting attach, 8 bytes (4 bits) from usbus0 >>> random: harvesting attach, 8 bytes (4 bits) from ehci0 >>> ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on = simplebus0 >>> usbus1 on ohci0 >>> ohci0: usbpf: Attached >>> random: harvesting attach, 8 bytes (4 bits) from usbus1 >>> random: harvesting attach, 8 bytes (4 bits) from ohci0 >>> gpioc0: on gpio0 >>> random: harvesting attach, 8 bytes (4 bits) from gpioc0 >>> simplebus0: mem 0x1c21400-0x1c21407 disabled compat = allwinner,sun50i-a64-pwm (no driver attached) >>> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on = simplebus0 >>> uart0: console (115384,n,8,1) >>> uart0: fast interrupt >>> uart0: PPS capture mode: DCD >>> random: harvesting attach, 8 bytes (4 bits) from uart0 >>> simplebus0: mem 0x1c28400-0x1c287ff irq 16 disabled = compat snps,dw-apb-uart (no driver attached) >>> simplebus0: mem 0x1c28800-0x1c28bff irq 17 disabled = compat snps,dw-apb-uart (no driver attached) >>> simplebus0: mem 0x1c28c00-0x1c28fff irq 18 disabled = compat snps,dw-apb-uart (no driver attached) >>> simplebus0: mem 0x1c29000-0x1c293ff irq 19 disabled = compat snps,dw-apb-uart (no driver attached) >>> simplebus0: mem 0x1c2ac00-0x1c2afff irq 20 disabled = compat allwinner,sun6i-a31-i2c (no driver attached) >>> iic0: on iicbus0 >>> random: harvesting attach, 8 bytes (4 bits) from iic0 >>> simplebus0: mem 0x1c2b400-0x1c2b7ff irq 22 disabled = compat allwinner,sun6i-a31-i2c (no driver attached) >>> gpioc1: on gpio1 >>> random: harvesting attach, 8 bytes (4 bits) from gpioc1 >>> syscon_generic0: mem 0x1c00000-0x1c00fff on simplebus0 >>> random: harvesting attach, 8 bytes (4 bits) from syscon_generic0 >>> awg0: mem 0x1c30000-0x1c3ffff irq 27 on = simplebus0 >>> simplebus0: no default resources for rid =3D 1, type =3D 3 >>> awg0: PHY type: rgmii, conf mode: reg >>> awg0: EMAC clock: 0x00000006 >>> awg0: AHB frequency 150000000 Hz, MDC div: 0x2 >>> miibus0: on awg0 >>> rgephy0: PHY 0 on = miibus0 >>> rgephy0: OUI 0x00e04c, model 0x0011, rev. 5 >>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >>> random: harvesting attach, 8 bytes (4 bits) from rgephy0 >>> rgephy1: PHY 1 on = miibus0 >>> rgephy1: OUI 0x00e04c, model 0x0011, rev. 5 >>> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >>> random: harvesting attach, 8 bytes (4 bits) from rgephy1 >>> random: harvesting attach, 8 bytes (4 bits) from miibus0 >>> awg0: bpf attached >>> awg0: Ethernet address: 02:ba:b1:c5:93:b7 >>> random: harvesting attach, 8 bytes (4 bits) from awg0 >>> cryptosoft0: >>> crypto: assign cryptosoft0 driver id 0, flags 0x6000000 >>> crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0 >>> crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0 >>> random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 >>> Found SMCCC version 1.0 >>> Device configuration finished. >>> procfs registered >>> Timecounters tick every 1.000 msec >>> vlan: initialized, using hash tables with chaining >>> lo0: bpf attached >>> arc4random: read 32 bytes from preloaded cache >>> arc4random: read 32 bytes from preloaded cache >>> arc4random: read 32 bytes from preloaded cache >>> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384 >>> IPsec: Initialized Security Association Processing. >>> usbus0: 480Mbps High Speed USB v2.0 >>> usbus1: 12Mbps Full Speed USB v1.0 >>> aw_mmc0: Powering up sd/mmc >>> mmc0: Probing bus >>> ugen0.1: at usbus0 >>> uhub0: = on usbus0 >>> ugen1.1: at usbus1 >>> uhub1: on = usbus1 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> mmc0: SD probe: failed >>> mmc0: MMC probe: OK (OCR: 0x40ff8080) >>> mmc0: Current OCR: 0x00ff8080 >>> mmc0: Probing cards >>> mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f) >>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >>> aw_mmc0: error rint: 0x00008010 >>> AW_MMC_INT_DATA_END_BIT_ERR >>> mmc0: Card at relative address 0x0002 added: >>> mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 >>> mmc0: quirks: 0 >>> mmc0: bus: 4bit, 200MHz (HS200 timing) >=20 > The above is where I got the HS200. (I had to look up the details > for this note.) >=20 >>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> aw_mmc0: error rint: 0x00000100 >>> AW_MMC_INT_RESP_TIMEOUT=20 >>> mmc0: setting transfer rate to 52.000MHz (dual data rate timing) >>> mmc0: Failed to set VCCQ for card at relative address 2 >>=20 >> So the driver is selecting DDR52 transfer rate but, of course, >> cannot switch the IO voltage to 1.8V as on this board the IO voltage >> for the SD card is tied to 3.3V >=20 > As I understand the following is allowed for e.MMC in all/most > vintages of the standard: >=20 > High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz >=20 > So no need for 1.8 V or 1.2 V for that much. >=20 > This is not the HS200 mode that the output references. But the > reference is probably just indicate what the e.MMC itself allows > as the fastest speed, not indicating the limitations of the context > of the connection. >=20 >>> uhub1: 1 port with 1 removable, self powered >>> random: harvesting attach, 8 bytes (4 bits) from uhub1 >>> uhub0: 1 port with 1 removable, self powered >>> random: harvesting attach, 8 bytes (4 bits) from uhub0 >>> aw_mmc0: controller timeout >>> aw_mmc0: timeout updating clock >>> aw_mmc0: controller timeout >>> aw_mmc0: timeout updating clock >>> aw_mmc0: controller timeout >>> aw_mmc0: timeout updating clock >>> aw_mmc0: controller timeout >>> aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 >>>=20 >>> mmcsd0: Error reading EXT_CSD Timeout >>=20 >> This seems weird, I have a board with an eMMC IO voltage tied to 3.3V >> (Olinuxino-A64), I'll try HEAD on this board. >>=20 >>> device_attach: mmcsd0 attach returned 6 >>> Release APs...done >>> Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs = [rw,noatime]... >>> CPU 0: ARM Cortex-A53 r0p4mountroot: waiting for device = /dev/ufs/PINE64P2Grootfs... >>> affinity: 0 >>> Instruction Set Attributes 0 =3D >>> Instruction Set Attributes 1 =3D <> >>> Processor Features 0 =3D >>> Processor Features 1 =3D <0> >>> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> >>> Memory Model Features 1 =3D <> >>> Memory Model Features 2 =3D <32b CCIDX,48b VA> >>> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> >>> Debug Features 1 =3D <0> >>> Auxiliary Features 0 =3D <0> >>> Auxiliary Features 1 =3D <0> >>> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 >>> CPU 2: ARM Cortex-A53 r0p4 affinity: 2 >>> CPU 3: ARM Cortex-A53 r0p4 affinity: 3 >>> regulator: shutting down vcc3v3 >>> Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19. >>>=20 >>> Loader variables: >>> vfs.root.mountfrom=3Dufs:/dev/ufs/PINE64P2Grootfs >>> vfs.root.mountfrom.options=3Drw,noatime >>>=20 >>> Manual root filesystem specification: >>> : [options] >>> Mount using filesystem >>> and with the specified (optional) option list. >>>=20 >>> eg. ufs:/dev/da0s1a >>> zfs:tank >>> cd9660:/dev/cd0 ro >>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>>=20 >>> ? List valid disk boot devices >>> . Yield 1 second (for background tasks) >>> Abort manual input >>>=20 >>> mountroot>=20 >>>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 6 18:53:14 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B92C51061E4B for ; Mon, 6 Aug 2018 18:53:13 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23858846A0 for ; Mon, 6 Aug 2018 18:53:13 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) X-YMail-OSG: WgwAQnEVM1kdSEHK01dHj7czzpI31lPyeGiKcas1QJY7DuUXOMLIOKqsBX6NgPX CpBs89PF.DV60XiFdkECa1XqgoQNszrK0aT9DaIpyYWVwb6wlwDwPVQ3iY7_.oChgz4c_hwEHjnJ Rok5SCWKD3G5eQD.vUmzGwCPfgMIXV2NqOVFXgnXa4fEpXs32EfRQwdc3Sjfi735gy1044mWOOG7 KgtQEwqJIAv1dBBImE3yELitBv9GnHVhJn0BFfoKDNQn1OWrkIuTx6W0wH4DPD17U5j9lGDFHfU2 UIOCsHsjB6SQ7HhF.GzVihykQB8ZtPeBCySq8YQwNdMXU.rqhbOd8uq61sWz93G26UZchGYCYD8Q zuU8e1VFol0BT0ihmdWEtikD9F52_whzr2bBOFvX0G_vQuZlyeapUdFxu7zR2l.mX8FzO5yRKdp3 KgHkLKQQwEHQSJGG4w39SlXablSweI8L4XPFp9sF.pY0e0SpteicXH8YWgXy9wHrqXAiPew2uiyW mAlRe0UpXDTkXYYXskF0grz1bgl1Uyx9I42Hn7Q.Z5AWHI5eaCNMAp6pGDEQRDvRomHB7P5RG2HU fZOy6PTDc3qYx17.fL1K2tbJrDJ7vUnSugyEJm74fOXosXPsWIgo1wEbnTn_LPlQo2f9ARPqUI7w oXil_iFdHrjUh.FBWN7S.e_N7QneEw4TjYIPpu56y8F3hy_IbqzX5ulj7b.RcRhKayTT1kJN1kwL jgDoY0sYQN6avopuIXVeT8TrFOT2ScdNYjg3i._85vlkUE7bhxqJnUHTqpVAJlnz7Blfie58fQvS vgFbKggfyufY56fA6hYf7rI8GLysMT9cqStuXOumvK6PufeqlttRpyHv6SSecYmK2d_nOs0Sa1cH iE6xoHOiE5aSkUR8WmHRfnTXinbv4zikSv0_bMqVGhGdOQVcZ5Ez9oeGbjrpAf220Vsum4rnnf7V aakp5hLtQWF3sjp9VrG2vKzZkmWzsu6gv6orSqMha_raNjsoC4U84x0bpKm.MzkZsqsbXlV0pSpS 3inMMnLj4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Aug 2018 18:53:05 +0000 Received: from c-67-180-59-81.hsd1.ca.comcast.net (EHLO [192.168.1.21]) ([67.180.59.81]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7911c2a1a72c4e402996aad8437bf7a8 for ; Mon, 06 Aug 2018 18:53:02 +0000 (UTC) From: Thomas Skibo Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: FreeBSD boots on an Ultra96 Message-Id: <280A8451-8B53-48C0-9712-B1B0F1F4E957@yahoo.com> Date: Mon, 6 Aug 2018 11:53:01 -0700 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 18:53:14 -0000 Hello: For what it=E2=80=99s worth, I=E2=80=99ve successfully booted FreeBSD on = an Ultra96 board which is a Xilinx Zynq UltraScale+ based board = (https://www.96boards.org/product/ultra96/ = ). The Zynq Ultrascale has = an ARM Cortex-A53 with four 64-bit cores. I don=E2=80=99t know how useful this is but it shows that a nearly = untouched generic aarch64 kernel can boot on Zynq UltraScale. The hard = part was coming up with a FSBL that programmed the DDR controller = correctly and sent console output to the correct UART. Unfortunately, the Ultra96 doesn=E2=80=99t have a gigabit ethernet = interface. I=E2=80=99d like to update the cgem driver (ethernet on = Zynq) to handle 64-bit physical addresses which is necessary on systems = with more than 2G of memory. Cheers, =E2=80=94=E2=80=94 Thomas Skibo ThomasSkibo@yahoo.com Xilinx Zynq MP First Stage Boot Loader=20 Release 2018.2 Aug 6 2018 - 09:13:32 NOTICE: ATF running on XCZU3EG/silicon v4/RTL5.1 at 0x1000 NOTICE: BL31: Secure code at 0x0 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v1.4(debug):xilinx-v2018.2 NOTICE: BL31: Built : 15:27:14, Aug 4 2018 INFO: ARM GICv2 driver initialized INFO: BL31: Initializing runtime services INFO: BL31: PM Service Init Complete: API v1.0 WARNING: BL31: cortex_a53: CPU workaround for 835769 was missing! WARNING: BL31: cortex_a53: CPU workaround for 843419 was missing! INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address =3D 0x8000000 INFO: SPSR =3D 0x3c9 PMUFW: v1.0 U-Boot 2018.01-00043-g6d73435 (Aug 05 2018 - 14:17:44 -0700) Xilinx = ZynqMP ZCU100 RevC I2C: ready DRAM: 2 GiB EL Level: EL2 Chip ID: zu3eg MMC: sdhci@ff160000: 0 (SD), sdhci@ff170000: 1 Using default environment In: serial@ff010000 Out: serial@ff010000 Err: serial@ff010000 Bootmode: SD_MODE Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 switch to partitions #0, OK mmc0 is current device Device: sdhci@ff160000 Manufacturer ID: 3 OEM: 5344 Name: SU08G=20 Tran Speed: 50000000 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes reading uEnv.txt 247 bytes read in 9 ms (26.4 KiB/s) Loaded environment from uEnv.txt Importing environment from SD ... Running uenvcmd ... Booting FreeBSD from SD Card: reading board.dtb 3670 bytes read in 12 ms (297.9 KiB/s) reading efi/boot/bootaa64.efi 84296 bytes read in 26 ms (3.1 MiB/s) ## Starting EFI application at 00300000 ... Scanning disk sdhci@ff160000.blk... sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms. sdhci_send_command: MMC: 1 busy timeout. sdhci_send_command: MMC: 1 busy timeout. mmc_init: -70, time 7439 Scanning disk sdhci@ff170000.blk... Found 4 disks =1B[?25h=1B[2J >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: /\uEnv.txt Probing 3 block devices.....+ done ZFS found no pools UFS found 1 partition =1B[?25h=1B[18tConsoles: EFI console =20 =1B[?25h|=08/=08-=08FreeBSD/arm64 EFI loader, Revision 1.1 (Tue Jul 31 22:46:09 PDT 2018 skibo@burke) Command line arguments: loader.efi EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) Console: efi (0) Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/HD(2,0x01,0,0x4003e,0x4= bffc2) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/HD(2,0x01,0,0x4003e,0x4= bffc2) Setting currdev to disk0p2: = \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08Lo= ading /boot/defaults/loader.conf = -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08/boot/= kernel/kernel text=3D0x7141fd = \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08data=3D0x131620+0x7bb3ac = /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08syms=3D[0x8+0xefa78\=08|=08/=08-=08= \=08|=08/=08-=08+0x8+0xe7f0e\=08|=08/=08-=08\=08|=08/=08] -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08efi-autoresize= cons: Neither Graphics Output Protocol nor Universal Graphics Adapter = present Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting = [/boot/kernel/kernel] in 8 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. OK boot -v =1B[37m=1B[44mBooting...=1B[m /=08-=08\=08|=08/=08Using DTB provided by EFI at 0x8000000. KDB: debugger backends: ddb KDB: current backend: ddb Type Physical Virtual #Pages Attr ConventionalMemory 000000000000 0 00008000 WB=20 BootServicesData 000008000000 8000000 00000002 WB=20 ConventionalMemory 000008003000 0 00066cc2 WB=20 LoaderData 00006ecc5000 6ecc5000 00000001 WB=20 Reserved 00006ecc6000 6ecc6000 00000001 WB=20 LoaderData 00006ecc7000 6ecc7000 00004000 WB=20 LoaderData 000072cc7000 72cc7000 00004000 WB=20 LoaderData 000076cc7000 76cc7000 00000074 WB=20 LoaderData 000076d3b000 76d3b000 00000074 WB=20 Reserved 000076daf000 76daf000 00000001 WB=20 LoaderData 000076db0000 76db0000 00000001 WB=20 LoaderData 000076db1000 76db1000 00000001 WB=20 LoaderData 000076db2000 76db2000 00001001 WB=20 LoaderData 000077db3000 77db3000 00001001 WB=20 LoaderData 000078db4000 78db4000 00000101 WB=20 LoaderData 000078eb5000 78eb5000 00000015 WB=20 RuntimeServicesData 000078eca000 78eca000 00000001 WB RUNTIME Reserved 000078ecb000 78ecb000 00000001 WB=20 Reserved 000078ecc000 78ecc000 00000001 WB=20 Reserved 000078ecd000 78ecd000 00000001 WB=20 Reserved 000078ece000 78ece000 00000001 WB=20 Reserved 000078ecf000 78ecf000 00000001 WB=20 Reserved 000078ed0000 78ed0000 00000001 WB=20 Reserved 000078ed1000 78ed1000 00000001 WB=20 Reserved 000078ed2000 78ed2000 00000001 WB=20 LoaderData 000078ed3000 78ed3000 00004000 WB=20 LoaderData 00007ced3000 7ced3000 000030bd WB=20 RuntimeServicesCode 00007ff90000 7ff90000 00000001 WB RUNTIME LoaderData 00007ff91000 7ced3000 0000006f WB=20 Physical memory chunk(s): 0x00001000 - 0x08001fff, 128 MB ( 32769 pages) 0x08003000 - 0x6ecc5fff, 1644 MB ( 421059 pages) 0x6ecc7000 - 0x76daefff, 128 MB ( 33000 pages) 0x76db0000 - 0x78ecafff, 33 MB ( 8475 pages) 0x78ed3000 - 0x7ff8ffff, 112 MB ( 28861 pages) 0x7ff91000 - 0x7fffffff, 0 MB ( 111 pages) Excluded memory regions: 0x6ecc6000 - 0x6ecc6fff, 0 MB ( 1 pages) NoAlloc=20 0x6ee00000 - 0x70204fff, 20 MB ( 5125 pages) NoAlloc=20 0x76daf000 - 0x76daffff, 0 MB ( 1 pages) NoAlloc=20 0x78eca000 - 0x78ed2fff, 0 MB ( 9 pages) NoAlloc=20 0x7ff90000 - 0x7ff90fff, 0 MB ( 1 pages) NoAlloc=20 Found 4 CPUs in the device tree Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #5 r337005M: Sun Aug 5 08:19:07 PDT 2018 skibo@burke:/usr/obj/usr/src/arm64.aarch64/sys/ZYNQMP arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000011dc000. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache VIMAGE (virtualized network stack) enabled ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 random: entropy device external interface MAP 78eca000 mode 2 pages 1 MAP 7ff90000 mode 2 pages 1 openfirm: kbd0 at kbdmux0 mem: nfslock: pseudo-device crypto: null: random: harvesting attach, 8 bytes (4 bits) from nexus0 ofwbus0: simplebus0: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from simplebus0 simplebus1: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from simplebus1 random: harvesting attach, 8 bytes (4 bits) from ofwbus0 psci0: on ofwbus0 psci0: PSCI version 0.2 compatible random: harvesting attach, 8 bytes (4 bits) from psci0 gic0: mem = 0xf9010000-0xf901ffff,0xf902f000-0xf9030fff,0xf9040000-0xf905ffff,0xf906f0= 00-0xf9070fff on simplebus0 simplebus0: no default resources for rid =3D 0, type =3D 1 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 192 random: harvesting attach, 8 bytes (4 bits) from gic0 generic_timer0: irq 0,1,2,3 on simplebus0 Timecounter "ARM MPCore Timecounter" frequency 100000002 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 100000002 Hz quality 1000 random: harvesting attach, 8 bytes (4 bits) from generic_timer0 efirtc0: cannot read EFI realtime clock cpulist0: on ofwbus0 cpu0: on cpulist0 cpu0: missing 'clock-frequency' property arm64_cpu0: register <0> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0 random: harvesting attach, 8 bytes (4 bits) from cpu0 cpu1: on cpulist0 cpu1: missing 'clock-frequency' property arm64_cpu1: register <1> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1 random: harvesting attach, 8 bytes (4 bits) from cpu1 cpu2: on cpulist0 cpu2: missing 'clock-frequency' property arm64_cpu2: register <2> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2 random: harvesting attach, 8 bytes (4 bits) from cpu2 cpu3: on cpulist0 cpu3: missing 'clock-frequency' property arm64_cpu3: register <3> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3 random: harvesting attach, 8 bytes (4 bits) from cpu3 random: harvesting attach, 8 bytes (4 bits) from cpulist0 uart0: mem 0xff000000-0xff000fff irq 4 on simplebus1 uart0: fast interrupt uart0: PPS capture mode: DCD random: harvesting attach, 8 bytes (4 bits) from uart0 uart1: mem 0xff010000-0xff010fff irq 5 on simplebus1 uart1: console (115200,n,8,1) uart1: fast interrupt uart1: PPS capture mode: DCD random: harvesting attach, 8 bytes (4 bits) from uart1 simplebus1: mem 0xff0b0000-0xff0b0fff irq 6,7 = disabled type network compat cdns,gem (no driver attached) simplebus1: mem 0xff0c0000-0xff0c0fff irq 8,9 = disabled type network compat cdns,gem (no driver attached) simplebus1: mem 0xff0d0000-0xff0d0fff irq 10,11 = disabled type network compat cdns,gem (no driver attached) simplebus1: mem 0xff0e0000-0xff0e0fff irq 12,13 = disabled type network compat cdns,gem (no driver attached) simplebus1: mem 0xff0f0000-0xff0f0fff irq 14 disabled = compat xlnx,zynqmp-qspi-1.0 (no driver attached) sdhci_fdt0: mem = 0xff160000-0xff160fff irq 15 on simplebus1 sdhci_fdt0-slot0: 200MHz HS 4bits VDD: 3.3V VCCQ: 3.3V DRV: B DMA = removable sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x01372790 | Version: 0x00001002 sdhci_fdt0-slot0: Blk size: 0x00007200 | Blk cnt: 0x00000000 sdhci_fdt0-slot0: Argument: 0x001de746 | Trn mode: 0x00000036 sdhci_fdt0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 sdhci_fdt0-slot0: Timeout: 0x0000000e | Int stat: 0x00000000 sdhci_fdt0-slot0: Int enab: 0x027f003b | Sig enab: 0x00000000 sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x31e8c881 | Caps2: 0x00002007 sdhci_fdt0-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0: 1 slot(s) allocated sdhci_fdt0-slot0: Card inserted mmc0: on sdhci_fdt0 random: harvesting attach, 8 bytes (4 bits) from mmc0 random: harvesting attach, 8 bytes (4 bits) from sdhci_fdt0 simplebus1: mem 0xff170000-0xff170fff irq 16 disabled = compat arasan,sdhci-8.9a (no driver attached) gpio0: mem 0xff0a0000-0xff0a0fff irq 17 = on simplebus1 gpiobus0: on gpio0 random: harvesting attach, 8 bytes (4 bits) from gpiobus0 gpioc0: on gpio0 random: harvesting attach, 8 bytes (4 bits) from gpioc0 random: harvesting attach, 8 bytes (4 bits) from gpio0 simplebus1: mem 0xfd0c0000-0xfd0c1fff irq 18 disabled = compat ceva,ahci-1v84 (no driver attached) cryptosoft0: crypto: assign cryptosoft0 driver id 0, flags 0x6000000 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0 random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 Device configuration finished. Found SMCCC version 1.1 procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384 IPsec: Initialized Security Association Processing. usb_needs_explore_all: no devclass sdhci_fdt0-slot0: Divider 250 for freq 400000 (base 200000000) mmc0: Probing bus mmc0: SD 2.0 interface conditions: OK mmc0: SD probe: OK (OCR: 0x40ff8000) mmc0: Current OCR: 0x00ff8000 mmc0: Probing cards mmc0: New card detected (CID 0353445355303847800623235c00d300) mmc0: New card detected (CSD 400e00325b5900003b377f800a404000) mmc0: Card at relative address 0xaaaa added: mmc0: card: SDHC SU08G 8.0 SN 0623235C MFG 03/2013 by 3 SD mmc0: quirks: 0 mmc0: bus: 4bit, 50MHz (high speed timing) mmc0: memory: 15523840 blocks, erase sector 8192 blocks mmc0: setting transfer rate to 50.000MHz (high speed timing) sdhci_fdt0-slot0: Divider 2 for freq 50000000 (base 200000000) mmcsd0: 8GB at mmc0 = 50.0MHz/4bit/65535-block random: harvesting attach, 8 bytes (4 bits) from mmcsd0 Release APs...arc4random: no preloaded entropy cache GEOM: new disk mmcsd0 done Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... mmc0: CPU 0: ARM Cortex-A53 r0p4setting bus width to 4 bits high speed = timing affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D GEOM_PART: partition 2 on (mmcsd0, MBR) is not aligned on 4194304 bytes Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Memory Model Features 2 =3D Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> GEOM_PART: partition 1 on (diskid/DISK-0623235C, MBR) is not aligned on = 4194304 bytes Auxiliary Features 0 =3D <0> GEOM_PART: partition 2 on (diskid/DISK-0623235C, MBR) is not aligned on = 4194304 bytes Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4GEOM_PART: partition 1 on = (ufsid/5b68782fdb189365, BSD) is not aligned on 4194304 bytes affinity: 3 WARNING: WITNESS option enabled, expect reduced performance. GEOM_PART: partition 1 on (diskid/DISK-0623235Cs2, BSD) is not aligned = on 4194304 bytes Warning: no time-of-day clock registered, system time will not be set = accurately start_init: trying /sbin/init arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, = generating a new one Setting hostuuid: bee42e48-9997-11e8-a2fa-7fad93598c67. Setting hostid: 0xef1f92c9. No suitable dump device was found. Starting file system checks: /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s2a: clean, 108286 free (14 frags, 13534 blocks, 0.0% = fragmentation) GEOM_PART: partition 1 on (diskid/DISK-0623235C, MBR) is not aligned on = 4194304 bytes GEOM_PART: partition 2 on (diskid/DISK-0623235C, MBR) is not aligned on = 4194304 bytes GEOM_PART: partition 1 on (ufsid/5b68782fdb189365, BSD) is not aligned = on 4194304 bytes GEOM_PART: partition 1 on (diskid/DISK-0623235Cs2, BSD) is not aligned = on 4194304 bytes Mounting local filesystems:random: unblocking device. . ELF ldconfig path: /lib /usr/lib /usr/lib/compat Setting hostname: ultra96. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED Feeding entropy: . lo0: link state changed to UP Starting Network: lo0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D680003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 Starting devd. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. devmatch: Can't read linker hints file. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Creating and/or trimming log files. Setting date via ntp. Error resolving north-america.pool.ntp.org: hostname nor servname = provided, or not known (8) 6 Aug 16:43:06 ntpdate[331]: Can't find host = north-america.pool.ntp.org: hostname nor servname provided, or not known = (8) 6 Aug 16:43:06 ntpdate[331]: no servers can be used, exiting Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Generating RSA host key. 2048 SHA256:+LRGOBJHYah8lIkZGVtxTrcuWnkIYDyFwbWX+2xe4FY root@ultra96 = (RSA) Generating ECDSA host key. 256 SHA256:Uz5qCD8EJGZVEdEbJjLQ8rGq6KU1NgEcZAfSJIqHCDc root@ultra96 = (ECDSA) Generating ED25519 host key. 256 SHA256:2ZVCp/aKTRmw+oXPfwaJZuaru01giKMDD0A7iJmxjIE root@ultra96 = (ED25519) Performing sanity check on sshd configuration. Starting sshd. devmatch: Can't read linker hints file. Starting background file system checks in 60 seconds. Mon Aug 6 16:43:09 UTC 2018 FreeBSD/arm64 (ultra96) (ttyu1) login: root FreeBSD 12.0-CURRENT (ZYNQMP) #5 r337005M: Sun Aug 5 08:19:07 PDT 2018 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the = /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting = questions. Introduction to manual pages: man man FreeBSD directory layout: man hier Edit /etc/motd to change this login announcement. =1B7=1B[r=1B[999;999H=1B[6n=1B8=00resizewin: timeout reading from = terminal root@ultra96:~ # uname -a FreeBSD ultra96 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r337005M: Sun Aug = 5 08:19:07 PDT 2018 = skibo@burke:/usr/obj/usr/src/arm64.aarch64/sys/ZYNQMP arm64 root@ultra96:~ # devinfo -rv nexus0 ofwbus0 cpulist0 pnpinfo name=3Dcpus cpu0 pnpinfo name=3Dcpu@0 compat=3Darm,cortex-a53 arm64_cpu0 cpu1 pnpinfo name=3Dcpu@1 compat=3Darm,cortex-a53 arm64_cpu1 cpu2 pnpinfo name=3Dcpu@2 compat=3Darm,cortex-a53 arm64_cpu2 cpu3 pnpinfo name=3Dcpu@3 compat=3Darm,cortex-a53 arm64_cpu3 psci0 pnpinfo name=3Dpsci compat=3Darm,psci-0.2 simplebus0 pnpinfo name=3Dapu@f9000000 compat=3Dsimple-bus gic0 pnpinfo name=3Dgic compat=3Darm,gic-400 Device Memory: 0xf9010000-0xf901ffff 0xf902f000-0xf9030fff generic_timer0 pnpinfo name=3Dtimer compat=3Darm,armv8-timer Interrupts: 0x0 0x1 0x2 0x3 simplebus1 pnpinfo name=3Dzynqmp_io@fd000000 compat=3Dsimple-bus uart0 pnpinfo name=3Duart@ff000000 compat=3Dxlnx,xuartps Interrupts: 0x4 Device Memory: 0xff000000-0xff000fff uart1 pnpinfo name=3Duart@ff001000 compat=3Dxlnx,xuartps Interrupts: 0x5 Device Memory: 0xff010000-0xff010fff unknown unknown unknown unknown unknown sdhci_fdt0 pnpinfo name=3Dsdhci@ff160000 compat=3Darasan,sdhci-8.9a Interrupts: 0xf Device Memory: 0xff160000-0xff160fff mmc0 mmcsd0 at rca=3D0xaaaa unknown gpio0 pnpinfo name=3Dgpio@ff0a0000 compat=3Dxlnx,zynqmp-gpio-1.0 Device Memory: 0xff0a0000-0xff0a0fff gpiobus0 gpioc0 unknown unknown pnpinfo name=3Dchosen unknown pnpinfo name=3Dmemory efirtc0 cryptosoft0 root@ultra96:~ # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mmcsd0s2a 2412156 1979088 240096 89% / devfs 1 1 0 100% /dev /dev/mmcsd0s1 131000 1168 129832 1% /boot/msdos /dev/md0 29340 24 26972 0% /tmp /dev/md1 14492 56 13280 0% /var/log /dev/md2 4508 8 4140 0% /var/tmp root@ultra96:~ #=20 root@ultra96:~ #=20 root@ultra96:~ # halt Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop...=20 Syncing disks, vnodes remaining... 2 1 1 1 0 0 done Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... = done All buffers synced. lock order reversal: 1st 0xfffffd0000e319c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1343 2nd 0xfffffd0000e31608 syncer (syncer) @ = /usr/src/sys/kern/vfs_subr.c:2734 stack backtrace: #0 0xffff0000002d5514 at witness_debugger+0x64 #1 0xffff000000245640 at lockmgr_lock_fast_path+0x19c #2 0xffff0000005918e4 at VOP_LOCK1_APV+0xac #3 0xffff00000034954c at _vn_lock+0x64 #4 0xffff00000033a224 at vputx+0x154 #5 0xffff0000003324f0 at dounmount+0x4f0 #6 0xffff00000033b918 at vfs_unmountall+0x7c #7 0xffff0000003192dc at bufshutdown+0x298 #8 0xffff00000026f8bc at kern_reboot+0x244 #9 0xffff00000026f60c at sys_reboot+0x354 #10 0xffff00000057f704 at do_el0_sync+0x4b4 #11 0xffff000000565200 at handle_el0_sync+0x84 lock order reversal: 1st 0xfffffd0000e319c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1343 2nd 0xfffffd00041199c8 devfs (devfs) @ = /usr/src/sys/ufs/ffs/ffs_vfsops.c:1373 stack backtrace: #0 0xffff0000002d5514 at witness_debugger+0x64 #1 0xffff000000245640 at lockmgr_lock_fast_path+0x19c #2 0xffff0000005918e4 at VOP_LOCK1_APV+0xac #3 0xffff00000034954c at _vn_lock+0x64 #4 0xffff00000050c288 at ffs_flushfiles+0x88 #5 0xffff0000004f2730 at softdep_flushfiles+0x84 #6 0xffff00000050e48c at ffs_unmount+0x6c #7 0xffff00000033253c at dounmount+0x53c #8 0xffff00000033b918 at vfs_unmountall+0x7c #9 0xffff0000003192dc at bufshutdown+0x298 #10 0xffff00000026f8bc at kern_reboot+0x244 #11 0xffff00000026f60c at sys_reboot+0x354 #12 0xffff00000057f704 at do_el0_sync+0x4b4 #13 0xffff000000565200 at handle_el0_sync+0x84 Uptime: 2m17s The operating system has halted. Please press any key to reboot. From owner-freebsd-arm@freebsd.org Mon Aug 6 22:10:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC3121067932 for ; Mon, 6 Aug 2018 22:10:24 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B5DC8E062 for ; Mon, 6 Aug 2018 22:10:23 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w76M95sc096386 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Aug 2018 15:09:05 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w76M95fj096385; Mon, 6 Aug 2018 15:09:05 -0700 (PDT) (envelope-from warlock) Date: Mon, 6 Aug 2018 15:09:05 -0700 From: John Kennedy To: Per olof Ljungmark Cc: freebsd-arm@freebsd.org Subject: Re: usb-only rpi 3b+ (+UART foo) Message-ID: <20180806220905.GG30738@phouka1.phouka.net> References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 22:10:25 -0000 On Mon, Aug 06, 2018 at 05:54:19PM +0200, Per olof Ljungmark wrote: > Stops after loading kernel: > > Booting [/boot/kernel/kernel] > Using DTB privided by EFI at 0x7ff8000. > EFI frambuffer information: > addr, size 0x3e330000, 0x8ca000 > dimensions 1920 x 1200 > stride 1920 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > and then nothing > > Happens for me with all stock images after July 19. I just burned the FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180802-r337160.img to an SD card and booted it up. The framebuffer information for my system is different (screen resolution? 1024 x 904 I think). After that, it clears the screen and goes into the kernel boot output that gets captured into /var/log/messages. The 20180802-r337160 /boot/loader.conf has a few new things in it: # Configure USB OTG; see usb_template(4). hw.usb.template=3 umodem_load="YES" # Multiple console (serial+efi gop) enabled. boot_multicons="YES" boot_serial="YES" From owner-freebsd-arm@freebsd.org Mon Aug 6 22:28:52 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6DAE1067EB0 for ; Mon, 6 Aug 2018 22:28:51 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A3358E802 for ; Mon, 6 Aug 2018 22:28:51 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w76MRYUX096441 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Aug 2018 15:27:34 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w76MRYNK096440; Mon, 6 Aug 2018 15:27:34 -0700 (PDT) (envelope-from warlock) Date: Mon, 6 Aug 2018 15:27:34 -0700 From: John Kennedy To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: usb-only rpi 3b+ (+UART foo) Message-ID: <20180806222734.GH30738@phouka1.phouka.net> References: <20180806042122.GD30738@phouka1.phouka.net> <20180806044929.GA17044@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806044929.GA17044@www.zefox.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 22:28:52 -0000 On Sun, Aug 05, 2018 at 09:49:29PM -0700, bob prohaska wrote: > My information is now very old, but I _thought_ one had to have u-boot on the > SD card at a minimum. There was an option within u-boot to "boot usb" which > implied the boot process could be transferred to a USB device, but I think > an SD card is required to get things started. The RPI3B+ will boot into USB (without SD card), or at least it will using the same SD card plugged into a Dynex DX-CR112 memory card reader. That gets you past the rainbow screen and into U-Boot land. U-Boot (?) seems to be choking at that point. It goes through the partitions (setting currdev to disk0p#), but it is printing efipart_readwrite messages (rw=1, blk=2591 size=272 status=7). Varies by partition, but rw=1 and status=7 for them and long delays. Putting the same SD card into the SD slot and it boots up fine. As far as booting... https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/host.md I want to say that is a fairly recent change, ~April 2018. Hmm. My Samsung disk is USB3. From owner-freebsd-arm@freebsd.org Tue Aug 7 08:42:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D1AD105298C for ; Tue, 7 Aug 2018 08:42:30 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A1D683F17 for ; Tue, 7 Aug 2018 08:42:30 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533631348; bh=OBNonAK5x8l3mdUUStBX9hkcJ+V/SMMmNuvgIcJMl0E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=tLecNXoiAIyjlIZA3Vvt4a384dxKzMEQF3kIXFzZA7/hwCYKXIFUWdVbR/TvTwpqg NoH7W51AQ3RanM5l81EGRtVwWGir5Oci5wy2jZQw39l2lEDdFKOzVnw/n3OTA17yYB +AW5JvzAjqrnTjYNw4D8x96tpu1bXeBU81PCvGO0= Subject: Re: usb-only rpi 3b+ (+UART foo) To: John Kennedy Cc: freebsd-arm@freebsd.org, Emmanuel Vadot References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> <20180806220905.GG30738@phouka1.phouka.net> From: Per olof Ljungmark Message-ID: <1c54c480-53ac-a88a-b6fb-8ae7072b19b9@nethead.se> Date: Tue, 7 Aug 2018 10:42:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180806220905.GG30738@phouka1.phouka.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 08:42:30 -0000 On 8/7/18 12:09 AM, John Kennedy wrote: > On Mon, Aug 06, 2018 at 05:54:19PM +0200, Per olof Ljungmark wrote: >> Stops after loading kernel: >> >> Booting [/boot/kernel/kernel] >> Using DTB privided by EFI at 0x7ff8000. >> EFI frambuffer information: >> addr, size 0x3e330000, 0x8ca000 >> dimensions 1920 x 1200 >> stride 1920 >> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 >> >> and then nothing >> >> Happens for me with all stock images after July 19. > > I just burned the FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180802-r337160.img > to an SD card and booted it up. > > The framebuffer information for my system is different (screen resolution? > 1024 x 904 I think). After that, it clears the screen and goes into the > kernel boot output that gets captured into /var/log/messages. > Aha. So , I can confirm r337160 *does* boot, but with the following differences from the July 19 snapshot: - There is no output on the big HDMI connector after the above message - Booting only finishes if I do *not* attach the HDMI connector - There are no active LED's at the ethernet connector, but it actually works and finishes the boot *if* HDMI is disconnected This is regardless of commenting out or not: # Multiple console (serial+efi gop) enabled. # boot_multicons="YES" # boot_serial="YES" dmesg at successful boot shows display set to 656x416, so is 1920 x 1200 the problem then? Wish I had another less capable monitor sitting here. Aug 7 08:26:26 generic kernel: fb0: on simplebus0 Aug 7 08:26:26 generic kernel: fbd0 on fb0 Aug 7 08:26:26 generic kernel: VT: Replacing driver "efifb" with new "fb". Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 bits) from fbd0 Aug 7 08:26:26 generic kernel: fb0: 656x416(656x416@0,0) 24bpp Aug 7 08:26:26 generic kernel: fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 bits) from fb0 I suppose I should get myself a serial console connection... From owner-freebsd-arm@freebsd.org Tue Aug 7 12:00:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99920105B111 for ; Tue, 7 Aug 2018 12:00:06 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 374878BDD4 for ; Tue, 7 Aug 2018 12:00:06 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533643204; bh=oWZWAOIMQflfKE1137z5AvaVOGandA46zeArlyECCIE=; h=Subject:From:To:Cc:References:Date:In-Reply-To; b=0SZX0M9/allq4zQKo3oZpyurpW+f5Nojl4KyrEPntxfVQm1ySYCwIgMZ+NwyezJ8Y 2KPI1w4NeeBpYrEznUhYfxjQY4iwH48p6Q/M4vIS/NxnFxIqhm+ZODT7y6eQ+MaMoa /mcSVTxZ7uhw5VBsqORI2Z0TdjDIbcyV1s/Y3gi4= Subject: Re: usb-only rpi 3b+ (+UART foo) From: Per olof Ljungmark To: John Kennedy Cc: freebsd-arm@freebsd.org, Emmanuel Vadot References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> <20180806220905.GG30738@phouka1.phouka.net> <1c54c480-53ac-a88a-b6fb-8ae7072b19b9@nethead.se> Message-ID: <767d4c31-e86a-442e-11a9-a12b80911ea0@nethead.se> Date: Tue, 7 Aug 2018 14:00:02 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <1c54c480-53ac-a88a-b6fb-8ae7072b19b9@nethead.se> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 12:00:06 -0000 On 8/7/18 10:42 AM, Per olof Ljungmark wrote: > On 8/7/18 12:09 AM, John Kennedy wrote: >> On Mon, Aug 06, 2018 at 05:54:19PM +0200, Per olof Ljungmark wrote: >>> Stops after loading kernel: >>> >>> Booting [/boot/kernel/kernel] >>> Using DTB privided by EFI at 0x7ff8000. >>> EFI frambuffer information: >>> addr, size 0x3e330000, 0x8ca000 >>> dimensions 1920 x 1200 >>> stride 1920 >>> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 >>> >>> and then nothing >>> >>> Happens for me with all stock images after July 19. >> >> I just burned the FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180802-r337160.img >> to an SD card and booted it up. >> >> The framebuffer information for my system is different (screen resolution? >> 1024 x 904 I think). After that, it clears the screen and goes into the >> kernel boot output that gets captured into /var/log/messages. >> > > Aha. > > So , I can confirm r337160 *does* boot, but with the following > differences from the July 19 snapshot: > > - There is no output on the big HDMI connector after the above message > - Booting only finishes if I do *not* attach the HDMI connector > - There are no active LED's at the ethernet connector, but it actually > works and finishes the boot *if* HDMI is disconnected > > This is regardless of commenting out or not: > > # Multiple console (serial+efi gop) enabled. > # boot_multicons="YES" > # boot_serial="YES" > > dmesg at successful boot shows display set to 656x416, so is 1920 x 1200 > the problem then? Wish I had another less capable monitor sitting here. > > Aug 7 08:26:26 generic kernel: fb0: on > simplebus0 > Aug 7 08:26:26 generic kernel: fbd0 on fb0 > Aug 7 08:26:26 generic kernel: VT: Replacing driver "efifb" with new "fb". > Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 > bits) from fbd0 > Aug 7 08:26:26 generic kernel: fb0: 656x416(656x416@0,0) 24bpp > Aug 7 08:26:26 generic kernel: fb0: fbswap: 1, pitch 1968, base > 0x3eb33000, screen_size 818688 > Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 > bits) from fb0 Now I remembered that we have an older TV with HD (1024x768) resolution and I can indeed report the the rpi3+ boots at that resolution makes it point even more to a resolution problem. From owner-freebsd-arm@freebsd.org Tue Aug 7 12:20:44 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B833D105C390 for ; Tue, 7 Aug 2018 12:20:44 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 55A758CD1A for ; Tue, 7 Aug 2018 12:20:44 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w77CJNjf090671 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Aug 2018 05:19:24 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w77CJMHQ090670; Tue, 7 Aug 2018 05:19:22 -0700 (PDT) (envelope-from warlock) Date: Tue, 7 Aug 2018 05:19:22 -0700 From: John Kennedy To: Per olof Ljungmark Cc: freebsd-arm@freebsd.org, Emmanuel Vadot Subject: Re: usb-only rpi 3b+ (+UART foo) Message-ID: <20180807121922.GI30738@phouka1.phouka.net> References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> <20180806220905.GG30738@phouka1.phouka.net> <1c54c480-53ac-a88a-b6fb-8ae7072b19b9@nethead.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c54c480-53ac-a88a-b6fb-8ae7072b19b9@nethead.se> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 12:20:45 -0000 On Tue, Aug 07, 2018 at 10:42:26AM +0200, Per olof Ljungmark wrote: > Aha. > > So , I can confirm r337160 *does* boot, but with the following > differences from the July 19 snapshot: > > - There is no output on the big HDMI connector after the above message > - Booting only finishes if I do *not* attach the HDMI connector > - There are no active LED's at the ethernet connector, but it actually > works and finishes the boot *if* HDMI is disconnected Well, I'm definitely getting output on my HDMI connection all through the boot since I haven't figured out how to get the serial output working flawlessly. I haven't seen my ethernet activity LEDs working ever, but I've only had this thing since the ~rpi3-20180709-r336134.img timeframe. That's come up on this list before. > dmesg at successful boot shows display set to 656x416, so is 1920 x 1200 > the problem then? Wish I had another less capable monitor sitting here. Hmm. Well, in screwing around with X in the past, I've seen all kinds of screen screwups but that just leaves the screen unusable, not the OS hung. And by unusable, I just mean using a resolution that the monitor won't sync to, so the game is to limit it to something that will work. > Aug 7 08:26:26 generic kernel: fb0: on simplebus0 > Aug 7 08:26:26 generic kernel: fbd0 on fb0 > Aug 7 08:26:26 generic kernel: VT: Replacing driver "efifb" with new "fb". > Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 bits) from fbd0 > Aug 7 08:26:26 generic kernel: fb0: 656x416(656x416@0,0) 24bpp > Aug 7 08:26:26 generic kernel: fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 > Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 bits) from fb0 kernel: FreeBSD 12.0-CURRENT #10 r337273+da001c8d4b45(master): Sun Aug 5 11:50:29 PDT 2018 kernel: warlock@rpi3.phouka.net:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 ... kernel: fb0: on simplebus0 kernel: fbd0 on fb0 kernel: VT: Replacing driver "efifb" with new "fb". kernel: fb0: 1824x984(1824x984@0,0) 24bpp kernel: fb0: fbswap: 1, pitch 5472, base 0x3e6cd000, screen_size 5428224 I've just got that piped into a Samsung TV-monitor that has been a accidental trooper. The text-character "dimension" is a bit odd (228x61), but it works. > I suppose I should get myself a serial console connection... Heh. That's why I got mine. I've been resorting to iPhone burst photos to try and get a good picture of what's going on, at least so I can retype it. From owner-freebsd-arm@freebsd.org Tue Aug 7 12:32:15 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74153105D009 for ; Tue, 7 Aug 2018 12:32:15 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE1138D661 for ; Tue, 7 Aug 2018 12:32:14 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533645133; bh=6hqYfF6rMFbHUdSPQ3AbtEBRy8y0Nw2DW5xBmw7M7/U=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=a6J+lQZ7LLOMdQcg7zW7YI1FqU86HF6wsb+Z5L/7BOCmqliR8YNgReb37Ef9OXodF G9ip0bDOIYibGjQFkXwjHOWeZyy3yTeTxLGtyryGEzHBihgyNQfexM/48bQpOuV7sv cuD+mJwdL64bUrBRKUaa9Dj1XSgB2tPRC76edQuY= Subject: Re: usb-only rpi 3b+ (+UART foo) To: John Kennedy Cc: freebsd-arm@freebsd.org, Emmanuel Vadot References: <20180806042122.GD30738@phouka1.phouka.net> <0a6af236-84cc-66fb-c2fc-4e1976cbb1f7@nethead.se> <20180806151903.GF30738@phouka1.phouka.net> <4da80506-ba05-86c5-b9ff-c76e106426a2@nethead.se> <20180806220905.GG30738@phouka1.phouka.net> <1c54c480-53ac-a88a-b6fb-8ae7072b19b9@nethead.se> <20180807121922.GI30738@phouka1.phouka.net> From: Per olof Ljungmark Message-ID: <2f8bbc93-8f10-9833-1dd4-4157be63a935@nethead.se> Date: Tue, 7 Aug 2018 14:32:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180807121922.GI30738@phouka1.phouka.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 12:32:15 -0000 On 8/7/18 2:19 PM, John Kennedy wrote: > On Tue, Aug 07, 2018 at 10:42:26AM +0200, Per olof Ljungmark wrote: >> Aha. >> >> So , I can confirm r337160 *does* boot, but with the following >> differences from the July 19 snapshot: >> >> - There is no output on the big HDMI connector after the above message >> - Booting only finishes if I do *not* attach the HDMI connector >> - There are no active LED's at the ethernet connector, but it actually >> works and finishes the boot *if* HDMI is disconnected > > Well, I'm definitely getting output on my HDMI connection all through the boot > since I haven't figured out how to get the serial output working flawlessly. > > I haven't seen my ethernet activity LEDs working ever, but I've only had this > thing since the ~rpi3-20180709-r336134.img timeframe. That's come up on this > list before. > >> dmesg at successful boot shows display set to 656x416, so is 1920 x 1200 >> the problem then? Wish I had another less capable monitor sitting here. > > Hmm. Well, in screwing around with X in the past, I've seen all kinds of screen > screwups but that just leaves the screen unusable, not the OS hung. And by > unusable, I just mean using a resolution that the monitor won't sync to, so the > game is to limit it to something that will work. > >> Aug 7 08:26:26 generic kernel: fb0: on simplebus0 >> Aug 7 08:26:26 generic kernel: fbd0 on fb0 >> Aug 7 08:26:26 generic kernel: VT: Replacing driver "efifb" with new "fb". >> Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 bits) from fbd0 >> Aug 7 08:26:26 generic kernel: fb0: 656x416(656x416@0,0) 24bpp >> Aug 7 08:26:26 generic kernel: fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 >> Aug 7 08:26:26 generic kernel: random: harvesting attach, 8 bytes (4 bits) from fb0 > > kernel: FreeBSD 12.0-CURRENT #10 r337273+da001c8d4b45(master): Sun Aug 5 11:50:29 PDT 2018 > kernel: warlock@rpi3.phouka.net:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > ... > kernel: fb0: on simplebus0 > kernel: fbd0 on fb0 > kernel: VT: Replacing driver "efifb" with new "fb". > kernel: fb0: 1824x984(1824x984@0,0) 24bpp > kernel: fb0: fbswap: 1, pitch 5472, base 0x3e6cd000, screen_size 5428224 > > I've just got that piped into a Samsung TV-monitor that has been a accidental > trooper. The text-character "dimension" is a bit odd (228x61), but it works. > >> I suppose I should get myself a serial console connection... > > Heh. That's why I got mine. I've been resorting to iPhone burst photos to try > and get a good picture of what's going on, at least so I can retype it. Well, the pi booted with HD 1024x768 but not 1920x1200. You don't happen to have a 1920x1200 monitor available? Would be nice to know if it's only me. Anyway, I'm setting up a build enviroment but don't think I will have anything to report until tomorrow. From owner-freebsd-arm@freebsd.org Wed Aug 8 01:25:48 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD7D41070A98 for ; Wed, 8 Aug 2018 01:25:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55CD389649 for ; Wed, 8 Aug 2018 01:25:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: jimxQy0VM1ltyrsNuR3gXq9kqCY9W65Z2W8ZxHAVHQpXg5hVy5pVB_0q8Z.of1B k3EdEDuXUeIZxDsrNGxjSl1mpflmSHYlpyMozZ9OOidt73OIKWbubQTjhiPW.YTrli4nlHPJXoed L9MUWsyi6yt.5Xej.Co2BHkHSD4E6REOSLjXSYgfGlWofU8P65CaE7D7e0uwflFmPQ_I6jQg4n41 hTjnbNbKp7_GM5w_VJoD.NlKQKGf.4wH1J9THrPVcEUR7YGmA94qU88yYNZ1Cm4w2lHt4oweIby_ AxODe7RcBZ90JTqlefCawZXqXqhbG3j1eEvR.3T4l15WWK1oog6vwYap7oOxEnhc3jnXrKXKxs8l KlWLqjezJagganHQk_Nk.cHgCq1bGe4fI9VPgAwrLnvoSrQcQfbnvWHhM9TnjocbKl65O86ZgMdR AEZJ9Oozh_24SX..ro8oNolphoUVXxCgD7ioqK8VEX_v2DE.qs7sUXXLrO78CvOScseuwvPRguND biVjZIZ1gYS.d4RshcoVZuNPEZPCicTMrZWNIzg8x2M6O5heweg3G_PKw3AEw._k9Rjr4RkgMRJO spw06XN.gO7uk8xV3cvj4fbnpJqDZBsTvEIVvkblX07_n14qb7gBavs3D43W.GR6GmTLxSvwbb8b nSfh58ch8HlhGv0mIpg6Xuz7NHUR7hA3KNnVUaS5VfQYRHy.DIxENIloQR8CS4mWscFeQ8mNuYG9 qBDIiTIZumtXkQLTiQmrC3rKIrRtp8nQ3T3DpfzMfQEkJcb.zpaiuTbzKTCORRNEhmdoW21IwB.i djoGKAGqlKI0Ue8bhbjcFTHPyBnnJnglusGDx59E1eevQagvBClvFVNpaFZ0yvDwEn0nFPMOe0RD ph_9aEjQCz1LViZuDFZynenBscz2nxj_2iIh7YU2mKgJ53SXs_qSInq7NBV_XYzUTvt7H7CpjGHb mP1ZaYJjd4YTWXXQpUw2j6XsH_FO9NXbwVskYHsc8hNATkygRVGvCfy7oKPNR64YgXkNkBaqFTGz CItniDs9Tor46NLwjGpLGEdbIvJVf3v01NknsjSZzi2QATKn3JxqOAaixl4bB6n3KGwNhyIExWI2 Z7YPnDM9JxZIdiwGTtg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Wed, 8 Aug 2018 01:25:42 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 479f9167542efdfe6a9c3beafa5bc38f; Wed, 08 Aug 2018 01:25:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> Date: Tue, 7 Aug 2018 18:25:38 -0700 Cc: Mark Millard via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 01:25:48 -0000 [FYI: I duplicated the e.MMC to a microsdhc, made minor changes, and tested booting: it did.] On 2018-Aug-6, at 11:39 AM, Mark Millard wrote: > [Fixing a confusing "slower" reference . . .] >=20 > On 2018-Aug-6, at 11:26 AM, Mark Millard wrote: >=20 >> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot = wrote: >>=20 >>> On Mon, 6 Aug 2018 10:12:43 -0700 >>> Mark Millard wrote: >>>=20 >>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot wrote: >>>>=20 >>>>> On Mon, 6 Aug 2018 02:48:57 -0700 >>>>> Mark Millard via freebsd-arm wrote: >>>>>=20 >>>>>> I amd64 -> aarch64 cross built -r337347 and installed it >>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as >>>>>> bootaa64.efi) as an update. My attempted synchronization >>>>>> of loader.conf and ttys and devd.conf may be incorrect. >>>>>> (Previous to this the Pine64+ 2GB seemed to be working >>>>>> okay but it was at a very old build.) >>>>>>=20 >>>>>> The kernel config has GENERIC included but the various >>>>>> debug features disabled. (My typical operating >>>>>> environment.) >>>>>>=20 >>>>>> For all I know what the below shows might be expected >>>>>> at this point. The kernel seems to have problems with >>>>>> the MMC (that the kernel was loaded from). No other >>>>>> media are attached. mmcsd0 is really an 128 GiByte >>>>>> emmc on an adapter. (This historically worked for me.) >>>>>=20 >>>>> emmc to sd ? that's weird ... >>>>=20 >>>> An example of the adapter I've used for this is: >>>>=20 >>>> = https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-= adapter >>>=20 >>> So this is a passive adapter, maybe that's something that should = work >>> but it's definitly is something that calls for problems. >>>=20 >>>> emmc is multi-mode for its allowed modes of operation. Thus >>>> its ability to frequently be used this way, such as via HS200. >>>> emmc is commonly more robust as I understand. >>>=20 >>> I didn't understand a word. >>=20 >> I got the HS200 reference from the boot -v output. Such is currently = from the >> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC >> members have free access, others do not.) >>=20 >> The output reported: >>=20 >> mmc0: Card at relative address 0x0002 added: >> mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 >> mmc0: quirks: 0 >> mmc0: bus: 4bit, 200MHz (HS200 timing) >> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >>=20 >> The e.MMC bus speed modes with I/O Voltage 3V allowed are: >>=20 >> Backwards Compatibility with legacy MMC card, data rate single, 3V = allowed, bus widths 1,4,8, 0-26 MHz >>=20 >> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 = MHz >>=20 >> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz >>=20 >> (The last being the fastest for maximum transfer rate with 3V.) >>=20 >> There is another 1.8V/1.2V mode: HS400 that is dual data rate and = always 8 bit, >> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. = HS400 >> is optional and sufficiently old e.MMC standard vintages would likely = not >> even have it. >>=20 >> So a slower 3.? V mode of use used to be selected (based on the = constraints >> on the board's voltages in some way, possibly hard coded). >=20 > "slower" lacks context: I should have said . . . >=20 > "a slower than HS200 3.? V mode" >=20 > As I remember, the 3V range is from 2.7 V to 3.6 V or some such. > So 3.3 V would be in range, at least if I remember right. >=20 >>>>=20 >>>> (I had to modify the case the pine64+ 2GB is in in order for >>>> the adapter/emmc combination to fit in all the way.) >>>>=20 >>=20 I duplicated the e.MMC partition content to a microsdhc for each partition (and u-boot but no swap), made minor changes, and tested booting. It booted, with messages like: Trying to boot from MMC1 . . . MMC: SUNXI SD/MMC: 0 . . . mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi . . . Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 3 disks . . . aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 mmc0: on aw_mmc0 . . . mmcsd0: 32GB at mmc0 = 50.0MHz/4bit/32768-block mmc0: ACMD42 failed, RESULT: 4 mmc0: Card at relative address 43690 failed to set bus width Prior to the last 2 lines above looks normal to me for the MMC material. So the only issue seems to be having an e.MCC device and how it is handled (mode of attempted operation, including voltage), given the limitations of the Pine64+ 2GB board. My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD e.MMC reader to be tried via: High Speed DDR mode (Data rate dual), 3.3V (so in the range allowed around 3V), full bus width that can be used (4 in my current context), 52 MHz or so. (At least for any vintage of e.MMC recent enough to have that available. This e.MMC mode has been around since e.MMC 4.4 (2009). I've seen claims that at the host controller level it is basically the same configuration used for SD DDR50, with different arguments in CMD6 for configuration.) But I've no clue if this fits well with the upstream status of things or not. I've seen claims that, unlike for UHS-II and UHS-III, Linux has e.MMC speed mode support being "quite complete" in the more generic parts not specific to each controller. (Only a quick summary.) So I'm hopeful for upstream. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 8 04:26:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 256281073EA6 for ; Wed, 8 Aug 2018 04:26:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 606F58E01A; Wed, 8 Aug 2018 04:26:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w784R5h3026782 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Aug 2018 21:27:06 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w784R4Co026781; Tue, 7 Aug 2018 21:27:05 -0700 (PDT) (envelope-from fbsd) Date: Tue, 7 Aug 2018 21:27:04 -0700 From: bob prohaska To: Mark Johnston Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180808042704.GB26133@www.zefox.net> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806155837.GA6277@raichu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 04:26:50 -0000 On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > > My suspicion, based on the high latency, is that this is a consequence > of r329882, which lowered the period of time that the page daemon will > sleep while waiting for dirty pages to be cleaned. If a certain number > of consecutive wakeups and queue scans occur without making progress, > the OOM killer is triggered. That number is vm.pageout_oom_seq - could > you try increasing it by a factor of 10 and retry your test? > It almost worked. OOMA struck when the buildworld.log file was at 27 MB, compared its normal failure point with this USB/microSD mixed swap setup of around 1.6 MB. So, increasing vm.pageout_oom_seq from 12 to 120 certainly helped, a lot. It does seem slightly odd that the delay on the USB swap partition just before the kill was around 1.2 seconds, far less than worst-case. The log files, console output and some sorted derivatives are at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/ > > If the above suggestion doesn't help, the next thing to try would be to > revert the oom_seq value to the default, apply this patch, and see if > the problem continues to occur. If this doesn't help, please try > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > > diff --git a/sys/vm/vm_pagequeue.h b/sys/vm/vm_pagequeue.h > index fb56bdf2fdfc..29a16060253f 100644 > --- a/sys/vm/vm_pagequeue.h > +++ b/sys/vm/vm_pagequeue.h > @@ -74,7 +74,7 @@ struct vm_pagequeue { > } __aligned(CACHE_LINE_SIZE); > > #ifndef VM_BATCHQUEUE_SIZE > -#define VM_BATCHQUEUE_SIZE 7 > +#define VM_BATCHQUEUE_SIZE 1 > #endif > > struct vm_batchqueue { I'll try compiling a new kernel with the batchqueue patch and re-run the experiment. Thanks for all your help! bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 8 09:13:17 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24C9E1054421 for ; Wed, 8 Aug 2018 09:13:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9697075F08 for ; Wed, 8 Aug 2018 09:13:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ImzAtWQVM1nGa55ItrL2QTqmzkvwmOuyLo20mqWfduyguJ2zfPjyiC7MkITyY8H .k_BRvoR.MCA8sSmofOdR4K8osMIjUMe_1x3NtmIz9tDI3HgWxV2mkRBfWtHXz_tAKuam0S6DRru c.YeCAwFfmSnhn2MVG2xnZxZCFw41o8jc7upfuBwEMyRzutuH2vUz8lUes_bE2yX.uV8B3t5Dwux tUnLpRLKRF807HvDAWwai2m4Gkh4Q30PubWxOw9Q4EX_0JaMzbwK_Zs7NczIp5nTOj_d9zlTtnqt 1PgV2FRRcVpqDnJOGO4VmJLyR_n20xjlN07kjsMxJy_LuyqbAec4F2s.ECp8cCia5.0CPAzBzoNp LDSMiRh7nEM_aPwRLSX1SoQdhnOcNmTO.b.4EF9JOXFlBzlVMkU5i_PUEvahWhwuo60lvuTawiYW hXFFm2pEMyKAEf8n7WZdsjHi0ugMu8kaghewT0Ncr_kDn8zBODyiTJC3tvSDnoXrfZkkhNpHWwvY b3tm_0S8MNPm8_dJ_EIHx3aC9xMLPMmu6F4oOdeq6eO.lB9yd9ZkX0.aUv2tINwOsm1a.wdN4run n4YLBugyQgdjM4es5OYFHt8zxwZvac8kgSlyxffDf5CRrk0lZAQABUGSBZd0BN1mfNqUCHnaGPzT AW3Gii225_ZSO_48NGXFiyH4TOyEjBZuNfg51GIQWqH9k7txs6fyS3NG9Mzu3OI12UPEIjZ9qleb Wo6BIimhll8q6msGp_IdlMHJkB8y6rZWUs1YV9FTYuvnbOhpNVrLg.3Lvuu2MeGNosdzmBErPOFq _n6piAQhbFom4bEx_xTDBKOqj7EVCZ2azZagfTTOtFSaL8n.Ei.K2Etkj9GTY2zkBIGBnui1MiKH zHh.CvvI0PMljwolTHz.HgzG6y4bRPQcCeTwQGoD20Q5zRM42fsci4UhS9UYQO3NAVPsVJna9Nby A08koOxeapE2BKuTfyDCpe4YP7VdW0NAaq409Q2ZenCzaMtMSCtSuGxiLTwRFfhaix5jrtgUlM8. vzRzV5tlPUypRUXKSg2tA9h1iNvyIKfKk94YXZuQCox_lSYwxhn9Wp.tkIe1HQS_sQNvbyKDNwcv PISVYYQNgU2hMyZo- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Aug 2018 09:13:09 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 97738843e83b528c58527c80ac204fe7; Wed, 08 Aug 2018 09:03:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> Date: Wed, 8 Aug 2018 02:02:58 -0700 Cc: Mark Millard via freebsd-arm , marius@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 09:13:17 -0000 On 2018-Aug-7, at 6:25 PM, Mark Millard wrote: > [FYI: I duplicated the e.MMC to a microsdhc, made minor > changes, and tested booting: it did.] >=20 > On 2018-Aug-6, at 11:39 AM, Mark Millard wrote: >=20 >> [Fixing a confusing "slower" reference . . .] >>=20 >> On 2018-Aug-6, at 11:26 AM, Mark Millard = wrote: >>=20 >>> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot wrote: >>>=20 >>>> On Mon, 6 Aug 2018 10:12:43 -0700 >>>> Mark Millard wrote: >>>>=20 >>>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot wrote: >>>>>=20 >>>>>> On Mon, 6 Aug 2018 02:48:57 -0700 >>>>>> Mark Millard via freebsd-arm wrote: >>>>>>=20 >>>>>>> I amd64 -> aarch64 cross built -r337347 and installed it >>>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as >>>>>>> bootaa64.efi) as an update. My attempted synchronization >>>>>>> of loader.conf and ttys and devd.conf may be incorrect. >>>>>>> (Previous to this the Pine64+ 2GB seemed to be working >>>>>>> okay but it was at a very old build.) >>>>>>>=20 >>>>>>> The kernel config has GENERIC included but the various >>>>>>> debug features disabled. (My typical operating >>>>>>> environment.) >>>>>>>=20 >>>>>>> For all I know what the below shows might be expected >>>>>>> at this point. The kernel seems to have problems with >>>>>>> the MMC (that the kernel was loaded from). No other >>>>>>> media are attached. mmcsd0 is really an 128 GiByte >>>>>>> emmc on an adapter. (This historically worked for me.) >>>>>>=20 >>>>>> emmc to sd ? that's weird ... >>>>>=20 >>>>> An example of the adapter I've used for this is: >>>>>=20 >>>>> = https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-= adapter >>>>=20 >>>> So this is a passive adapter, maybe that's something that should = work >>>> but it's definitly is something that calls for problems. >>>>=20 >>>>> emmc is multi-mode for its allowed modes of operation. Thus >>>>> its ability to frequently be used this way, such as via HS200. >>>>> emmc is commonly more robust as I understand. >>>>=20 >>>> I didn't understand a word. >>>=20 >>> I got the HS200 reference from the boot -v output. Such is currently = from the >>> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC >>> members have free access, others do not.) >>>=20 >>> The output reported: >>>=20 >>> mmc0: Card at relative address 0x0002 added: >>> mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 >>> mmc0: quirks: 0 >>> mmc0: bus: 4bit, 200MHz (HS200 timing) >>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >>>=20 >>> The e.MMC bus speed modes with I/O Voltage 3V allowed are: >>>=20 >>> Backwards Compatibility with legacy MMC card, data rate single, 3V = allowed, bus widths 1,4,8, 0-26 MHz >>>=20 >>> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 = MHz >>>=20 >>> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz >>>=20 >>> (The last being the fastest for maximum transfer rate with 3V.) >>>=20 >>> There is another 1.8V/1.2V mode: HS400 that is dual data rate and = always 8 bit, >>> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. = HS400 >>> is optional and sufficiently old e.MMC standard vintages would = likely not >>> even have it. >>>=20 >>> So a slower 3.? V mode of use used to be selected (based on the = constraints >>> on the board's voltages in some way, possibly hard coded). >>=20 >> "slower" lacks context: I should have said . . . >>=20 >> "a slower than HS200 3.? V mode" >>=20 >> As I remember, the 3V range is from 2.7 V to 3.6 V or some such. >> So 3.3 V would be in range, at least if I remember right. >>=20 >>>>>=20 >>>>> (I had to modify the case the pine64+ 2GB is in in order for >>>>> the adapter/emmc combination to fit in all the way.) >>>>>=20 >>>=20 >=20 > I duplicated the e.MMC partition content to a microsdhc > for each partition (and u-boot but no swap), made minor > changes, and tested booting. It booted, with messages > like: >=20 > Trying to boot from MMC1 > . . . > MMC: SUNXI SD/MMC: 0 > . . . > mmc0 is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > . . . > Scanning disks on mmc... > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 3 disks > . . . > aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 > mmc0: on aw_mmc0 > . . . > mmcsd0: 32GB at mmc0 = 50.0MHz/4bit/32768-block > mmc0: ACMD42 failed, RESULT: 4 > mmc0: Card at relative address 43690 failed to set bus width >=20 >=20 >=20 > Prior to the last 2 lines above looks normal to me for the > MMC material. >=20 > So the only issue seems to be having an e.MCC device and > how it is handled (mode of attempted operation, including > voltage), given the limitations of the Pine64+ 2GB board. >=20 > My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD > e.MMC reader to be tried via: >=20 > High Speed DDR mode (Data rate dual), 3.3V (so in the range > allowed around 3V), full bus width that can be used (4 in my > current context), 52 MHz or so. >=20 > (At least for any vintage of e.MMC recent enough to have that > available. This e.MMC mode has been around since e.MMC 4.4 > (2009). I've seen claims that at the host controller level > it is basically the same configuration used for SD DDR50, > with different arguments in CMD6 for configuration.) >=20 > But I've no clue if this fits well with the upstream status > of things or not. I've seen claims that, unlike for UHS-II > and UHS-III, Linux has e.MMC speed mode support being "quite > complete" in the more generic parts not specific to each > controller. (Only a quick summary.) So I'm hopeful for > upstream. The 3V problem for e.MCC DDR @ 52 MHz looks more generic than the Pine64's or even aarch64 or even arm in general. Likely not your issue directly [Emmanuel]. Looking around some more I see that the card-type/device-type bitfield had as of JESD84-A441 (March 2010) [JESD84-A44 was apparently withdrawn, not just updated]: Bits 7:4 reserved (defined in sufficiently more recent vintages) Bit 3: DDR MMC @ 52 MHz 1.2 V I/O Bit 2: DDR MMC @ 52 MHz 1.8 V or 3V I/O Bit 1: SDR @ 52 MHz at rated device voltage(s) Bit 0: SDR @ 26 MHz at rated device voltage(s) (more modern has 3-0 being the same) but the only valid bit patterns with 7:4 being zero were(/are): 0x01, 0x03, 0x07, 0x0B, and 0x0F. Note also that an e.MCC device can for DDR @ 52 MHz: support 1.2 V without supporting 1.8 V/3 V or: support 1.8 V/3 V without supporting 1.2 V (What I was using supports 3V and u-boot through loading the kernel worked fine.) Presuming the environment can supply an I/O voltage in the allowed range around 3V, such as 3.3V being the the range 2.7 V to 3.6 V: (The environment might not have 1.8V available as an alternative even though E.MMC devices have 1.8V and 3V paired, for example the Pine64+ 2GB, from what I'm told, lacks 1.8V.) Then 0x07 implies DDR @ 52 MHz with 3V I/O is available for use And 0x0F implies DDR @ 52 MHz with 3V I/O is available for use (Otherwise DDR @ 52 MHz with 3V I/O is unavailable.) If the e.MCC supports DDR @ 52 MHz with 1.8 V it also supports 3V --and the other way around. So the code is odd/incomplete in /usr/src/sys/dev/mmc/bridge.h : #define MMC_CAP_MMC_DDR52_120 (1 << 11) /* Can do eMMC DDR52 at 1.2 V = */ #define MMC_CAP_MMC_DDR52_180 (1 << 12) /* Can do eMMC DDR52 at 1.8 V = */ #define MMC_CAP_MMC_DDR52 (MMC_CAP_MMC_DDR52_120 | = MMC_CAP_MMC_DDR52_180) unless MMC_CAP_MMC_DDR52_180 implicitly also covers 3V. If so, the comment should mention 3V, as might the macro name. Another possibility is that there should be another macro. Something like: #define MMC_CAP_MMC_DDR52_120 (1 << 11) /* Can do eMMC DDR52 at 1.2 V = (nominal) */ #define MMC_CAP_MMC_DDR52_180 (1 << 12) /* Can do eMMC DDR52 at 1.8 V = (nominal) */ #define MMC_CAP_MMC_DDR52_300 (1 << ??) /* Can do eMMC DDR52 at 3.0 V = (nominal) */ #define MMC_CAP_MMC_DDR52 (MMC_CAP_MMC_DDR52_120 | = MMC_CAP_MMC_DDR52_180 | MMC_CAP_MMC_DDR52_300) (I do not claim such is sufficient, just suggestive.) It looks like this goes back to -r315598 (2017-Mar-19) when the code as 1st added by marius. I've not found any representation of the 3V DDR @ 52 MHz case for e.MMC so far. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 8 14:00:14 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25E96105CD60 for ; Wed, 8 Aug 2018 14:00:14 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 A10B07F3EE for ; Wed, 8 Aug 2018 14:00:12 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id 70F9873 for ; Wed, 8 Aug 2018 16:00:04 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id CE5081350F91A for ; Wed, 8 Aug 2018 10:59:59 -0300 (BRT) From: "Dr. Rolf Jansen" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: BeagleBone Black with a I2C Digital Analog Converter Message-Id: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> Date: Wed, 8 Aug 2018 10:59:58 -0300 To: freebsd-arm@FreeBSD.org X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 14:00:14 -0000 Hello, I got a BeagleBone Black running the latest FreeBSD 12.0-CURRENT = (snapshot o July, 2nd). I am in the process of getting a tiny I2C Digital Analog Converter board = to work with it. It got a MCP4725 DAC chip and it is designed to work = with the Arduino system. = https://learn.sparkfun.com/tutorials/mcp4725-digital-to-analog-converter-h= ookup-guide = However, it should be possible to get it to work with FreeBSD on the = BeagleBone as well, since the operation principle looks very simple, = e.g. write to the base address 0x60 the update command byte 0x40 = followed by two bytes in network byte order which constitutes for the = desired voltage output as a 12bit value. I managed to create a DTB overlay: /dts-v1/; /plugin/; / { compatible =3D "ti,am335x-bone-black", "ti,am335x-bone", = "ti,am33xx"; part-number =3D "MCP4725-I2C1"; version =3D "0001"; exclusive-use =3D "P9.17","P9.18","i2c1"; fragment@0 { target =3D <&am33xx_pinmux>; __overlay__ { pinmux_i2c1_pins { pinctrl-single,pins =3D <0x158 0x32 = 0x15c 0x32>; phandle =3D <0xff>; # pinctrl-single,pins =3D < # AM33XX_IOPAD(0x958, = PIN_INPUT_PULLUP | MUX_MODE2) /* spi0_d1.i2c1_sda */ # AM33XX_IOPAD(0x95c, = PIN_INPUT_PULLUP | MUX_MODE2) /* spi0_cs0.i2c1_scl */ # >; }; }; }; fragment@1 { target =3D <&i2c1>; __overlay__ { status =3D "okay"; pinctrl-names =3D "default"; pinctrl-0 =3D <0xff>; MCP4725 { comaptible =3D "Microchip,MCP4725"; reg =3D <0x60>; }; }; }; }; This actually activates the I2C1 device, and creates a node for the = MCP4725 I2C chip. Since I see the additional iic device in /dev: ls -l /dev/iic* ls -l /dev/iic* crw------- 1 root wheel 0x43 Aug 8 10:36 /dev/iic0 crw------- 1 root wheel 0x45 Aug 8 10:36 /dev/iic1 crw------- 1 root wheel 0x46 Aug 8 10:36 /dev/iic2 Without the overlay, only 2 device show up. Furthermore, the nodes for = nodes activated I2C1, its sub node for the DAC chip and the additional = pinmux node show up in the ofwdump: ... Node 0x2f00: scm@210000 Node 0x2fa0: pinmux@800 Node 0x3064: pinmux_i2c1_pins ... Node 0x5290: i2c@4802a000 Node 0x5360: MCP4725 ... My doubts are now, whether I got the specs of the pinmux right. I read = several documents in the and according to this = https://github.com/jadonk/bonescript/blob/master/src/bone.js, the = addresses of P9.17 and P9.18 should be 0x15c and 0x158 respectively. I = deduced the order and options from other pinmuxes of a decompiled device = tree. Please can somebody, check this, and perhaps give some hints in case I = got something wrong? I don't have an oscilloscope, a multimeter only, = can I check somehow if I specified the correct pins? What needs to be done next? I guess, I need to write a simple device = driver, don't I? Or can I use somehow the iicbb(4) =E2=80=93 I2C generic = bit-banging driver, since actually that DAC chip needs bit banging only = -- repeatedly write 3 byte in row. I yes, how can I use it for my = purpose? Best regards Rolf= From owner-freebsd-arm@freebsd.org Wed Aug 8 15:37:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98206105F9C0 for ; Wed, 8 Aug 2018 15:37:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 19DEE8292E; Wed, 8 Aug 2018 15:37:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w78Fc1Q3028766 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Aug 2018 08:38:01 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w78Fc0sk028765; Wed, 8 Aug 2018 08:38:00 -0700 (PDT) (envelope-from fbsd) Date: Wed, 8 Aug 2018 08:38:00 -0700 From: bob prohaska To: Mark Johnston Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180808153800.GF26133@www.zefox.net> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806155837.GA6277@raichu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 15:37:46 -0000 On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > On Wed, Aug 01, 2018 at 09:27:31PM -0700, Mark Millard wrote: > > [I have a top-posted introduction here in reply > > to a message listed at the bottom.] > > > > Bob P. meet Mark J. Mark J. meet Bob P. I'm > > hopinh you can help Bob P. use a patch that > > you once published on the lists. This was from: > > > > https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html > > > > Bob P. has been having problems with an rpi3 > > based buildworld ending up with "was killed: > > out of swap space" but when the swap partitions > > do not seem to be heavily used (seen via swapinfo > > or watching top). > > > > > The patch to report OOMA information did its job, very tersely. The console reported > > > v_free_count: 5439, v_inactive_count: 1 > > > Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out of swap space > > > > > > The entire buildworld.log and gstat output are at > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r336877M/ > > > > > > It appears that at 18:08:21 a write to the USB swap device took 530.5 ms, > > > next top was killed and ten seconds later c++ was killed, _after_ da0b > > > was no longer busy. > > My suspicion, based on the high latency, is that this is a consequence > of r329882, which lowered the period of time that the page daemon will > sleep while waiting for dirty pages to be cleaned. If a certain number > of consecutive wakeups and queue scans occur without making progress, > the OOM killer is triggered. That number is vm.pageout_oom_seq - could > you try increasing it by a factor of 10 and retry your test? > > > > This buildworld stopped a quite a bit earlier than usual; most of the time > > > the buildworld.log file is close to 20 MB at the time OOMA acts. In this case > > > it was around 13 MB. Not clear if that's of significance. > > > > > > If somebody would indicate whether this result is informative, and any possible > > > improvements to the test, I'd be most grateful. > > If the above suggestion doesn't help, the next thing to try would be to > revert the oom_seq value to the default, apply this patch, and see if > the problem continues to occur. If this doesn't help, please try > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > > diff --git a/sys/vm/vm_pagequeue.h b/sys/vm/vm_pagequeue.h > index fb56bdf2fdfc..29a16060253f 100644 > --- a/sys/vm/vm_pagequeue.h > +++ b/sys/vm/vm_pagequeue.h > @@ -74,7 +74,7 @@ struct vm_pagequeue { > } __aligned(CACHE_LINE_SIZE); > > #ifndef VM_BATCHQUEUE_SIZE > -#define VM_BATCHQUEUE_SIZE 7 > +#define VM_BATCHQUEUE_SIZE 1 > #endif > > struct vm_batchqueue { The patched kernel ran longer than default but OOMA still halted buildworld around 13 MB. That's considerably farther than a default build world have run but less than observed when setting vm.pageout_oom_seq=120 alone. Log files are at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/ Both changes are now in place and -j4 buildworld has been restarted. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 8 15:45:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A95F105FC93 for ; Wed, 8 Aug 2018 15:45:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EF3182D26 for ; Wed, 8 Aug 2018 15:45:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 1a5ae63b-9b22-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 1a5ae63b-9b22-11e8-aff6-0b9b8210da61; Wed, 08 Aug 2018 15:45:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w78FjegR056243; Wed, 8 Aug 2018 09:45:40 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533743140.9860.99.camel@freebsd.org> Subject: Re: BeagleBone Black with a I2C Digital Analog Converter From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@FreeBSD.org Date: Wed, 08 Aug 2018 09:45:40 -0600 In-Reply-To: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> Content-Type: text/plain; charset="windows-1251" 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 15:45:53 -0000 On Wed, 2018-08-08 at 10:59 -0300, Dr. Rolf Jansen wrote: > Hello, > > I got a BeagleBone Black running the latest FreeBSD 12.0-CURRENT (snapshot o July, 2nd). > > I am in the process of getting a tiny I2C Digital Analog Converter board to work with it. It got a MCP4725 DAC chip and it is designed to work with the Arduino system. https://learn.sparkfun.com/tutorials/mcp4725-digital-to-analog-converter-hookup-guide > > However, it should be possible to get it to work with FreeBSD on the BeagleBone as well, since the operation principle looks very simple, e.g. write to the base address 0x60 the update command byte 0x40 followed by two bytes in network byte order which constitutes for the desired voltage output as a 12bit value. > > I managed to create a DTB overlay: > > /dts-v1/; > /plugin/; > > / { >         compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; > >         part-number = "MCP4725-I2C1"; >         version = "0001"; >         exclusive-use = "P9.17","P9.18","i2c1"; > >         fragment@0 { >                 target = <&am33xx_pinmux>; >                 __overlay__ { >                         pinmux_i2c1_pins { >                                 pinctrl-single,pins = <0x158 0x32 0x15c 0x32>; >                                 phandle = <0xff>; > #                               pinctrl-single,pins = < > #                                       AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | MUX_MODE2)       /* spi0_d1.i2c1_sda */ > #                                       AM33XX_IOPAD(0x95c, PIN_INPUT_PULLUP | MUX_MODE2)       /* spi0_cs0.i2c1_scl */ > #                               >; >                         }; >                 }; >         }; > >         fragment@1 { >                 target = <&i2c1>; >                 __overlay__ { >                         status = "okay"; >                         pinctrl-names = "default"; >                         pinctrl-0 = <0xff>; > >                         MCP4725 { >                                 comaptible = "Microchip,MCP4725"; >                                 reg = <0x60>; >                         }; >                 }; >         }; > }; > > > This actually activates the I2C1 device, and creates a node for the MCP4725 I2C chip. Since I see the additional iic device in /dev: > > ls -l /dev/iic* > ls -l /dev/iic* > crw-------  1 root  wheel  0x43 Aug  8 10:36 /dev/iic0 > crw-------  1 root  wheel  0x45 Aug  8 10:36 /dev/iic1 > crw-------  1 root  wheel  0x46 Aug  8 10:36 /dev/iic2 > > Without the overlay, only 2 device show up. Furthermore, the nodes for nodes activated I2C1, its sub node for the DAC chip and the additional pinmux node show up in the ofwdump: > > ... >       Node 0x2f00: scm@210000 >         Node 0x2fa0: pinmux@800 >           Node 0x3064: pinmux_i2c1_pins > ... >     Node 0x5290: i2c@4802a000 >       Node 0x5360: MCP4725 > ... > > My doubts are now, whether I got the specs of the pinmux right. I read several documents in the and according to this https://github.com/jadonk/bonescript/blob/master/src/bone.js, the addresses of P9.17 and P9.18 should be 0x15c and 0x158 respectively. I deduced the order and options from other pinmuxes of a decompiled device tree. > > Please can somebody, check this, and perhaps give some hints in case I got something wrong? I don't have an oscilloscope, a multimeter only, can I check somehow if I specified the correct pins? > > What needs to be done next? I guess, I need to write a simple device driver, don't I? Or can I use somehow the iicbb(4) – I2C generic bit-banging driver, since actually that DAC chip needs bit banging only -- repeatedly write 3 byte in row. I yes, how can I use it for my purpose? > > Best regards > > Rolf At this point, i2c(8) is your friend, it lets you do i2c bus transactions from the commandline without a device-specific driver for each i2c device. A good starting point is a bus scan:   i2c -f /dev/iic1 -s If the bus is working you should see something like:   Scanning I2C devices on /dev/iic1: 60 You can also use i2c(8) to transfer data to and from the device, but that's something I've never done myself, so I can't give a working example here. Writing a custom driver for an i2c device is usually pretty simple. For chips with just a few registers, it's common to provide a userland interface with sysctl, allowing each register to be read or written by reading or setting a sysctl var. Some examples exist in the sys/dev/iicbus directory. -- Ian From owner-freebsd-arm@freebsd.org Wed Aug 8 15:48:09 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FF60105FD2E for ; Wed, 8 Aug 2018 15:48:09 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DD3882DCB for ; Wed, 8 Aug 2018 15:48:09 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533743281; bh=40K/ilZtGam/kUFpKx6b0JnnIc5ZwxZ88b8jwGkHEG0=; h=To:From:Subject:Date; b=v7T2JSXCNnu2JsqUO/PobrCnbScr5ZWbFWvH8FWeyq6t9yJS4kq0EigXGrgAHyFOA hf0uq+ecIk2InfUM08twX/d8l6Aw6B4CS4LpYwCywPc2wap674ESvZyJFPyW8QPBk8 Ku7osdVNssb+hGFD5IY4C+DIdidX9F5OyTAkRp44= To: freebsd-arm From: Per olof Ljungmark Subject: cross compile for rpi3 help needed Message-ID: <9d91c7f3-c41f-7ce0-4c79-0bc31aaa4331@nethead.se> Date: Wed, 8 Aug 2018 17:47:59 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 15:48:09 -0000 In the process of learning arm I have set up a testing platform with 12-CURRENT r336739 and reading release(7). The only change made to src is SRCBRANCH="base/head@r337160" in RPI3.conf /etc/make.conf and src.conf are empty command is sh release.sh -c arm64/RPI3.conf The build goes on for a while and stops with ... --- installconfig_subdir_usr.bin/ofed/libibverbs/ud_pingpong --- ===> usr.bin/ofed/libibverbs/ud_pingpong (installconfig) --- installconfig_subdir_share --- --- installconfig_subdir_share/vt --- ===> share/vt (installconfig) --- installconfig_subdir_share/zoneinfo --- ===> share/zoneinfo (installconfig) --- installconfig_subdir_share/vt --- --- installconfig_subdir_share/vt/fonts --- ===> share/vt/fonts (installconfig) --- installconfig_subdir_share/vt/keymaps --- ===> share/vt/keymaps (installconfig) chroot: /etc/rc.d/ldconfig: Exec format error What am I missing here? From owner-freebsd-arm@freebsd.org Wed Aug 8 17:06:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16CCF10629E4 for ; Wed, 8 Aug 2018 17:06:00 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 A545A86699; Wed, 8 Aug 2018 17:05:58 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id BC04271; Wed, 8 Aug 2018 19:05:56 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 2AE7B1350F91A; Wed, 8 Aug 2018 14:05:50 -0300 (BRT) From: "Dr. Rolf Jansen" Message-Id: <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: BeagleBone Black with a I2C Digital Analog Converter Date: Wed, 8 Aug 2018 14:05:49 -0300 In-Reply-To: <1533743140.9860.99.camel@freebsd.org> Cc: freebsd-arm@FreeBSD.org To: Ian Lepore References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 17:06:00 -0000 > Am 08.08.2018 um 12:45 schrieb Ian Lepore : >=20 > On Wed, 2018-08-08 at 10:59 -0300, Dr. Rolf Jansen wrote: >>=20 >> ... >> Please can somebody, check this, and perhaps give some hints in case = I got something wrong? I don't have an oscilloscope, a multimeter only, = can I check somehow if I specified the correct pins? >>=20 >> What needs to be done next? I guess, I need to write a simple device = driver, don't I? Or can I use somehow the iicbb(4) =E2=80=93 I2C generic = bit-banging driver, since actually that DAC chip needs bit banging only = -- repeatedly write 3 byte in row. I yes, how can I use it for my = purpose? >=20 > At this point, i2c(8) is your friend, it lets you do i2c bus > transactions from the commandline without a device-specific driver for > each i2c device. A good starting point is a bus scan: >=20 > i2c -f /dev/iic1 -s >=20 > If the bus is working you should see something like: >=20 > Scanning I2C devices on /dev/iic1: 60 >=20 > You can also use i2c(8) to transfer data to and from the device, but > that's something I've never done myself, so I can't give a working > example here. >=20 > Writing a custom driver for an i2c device is usually pretty simple. = For > chips with just a few registers, it's common to provide a userland > interface with sysctl, allowing each register to be read or written by > reading or setting a sysctl var. Some examples exist in the > sys/dev/iicbus directory. Ian, thank you very much for your response. As a matter of fact, the source of all my doubts told in the initial = post above is that yesterday after hours in a trial&error circle, I was = not able to get a sensible response from the exact bus scan command = which suggested: i2c -f /dev/iic1 -s -v Up to now, by no means I was able to see anything else than: dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1 Hardware may not support START/STOP scanning; trying less-reliable read = method. This START/STOP thing let me to think that I perhaps need to get = attached a device driver. I am also still in doubt, whether I really got the pinmux straight. I = checked very carefully the physical connections, anyway I am stuck at = this point. Best regards Rolf From owner-freebsd-arm@freebsd.org Wed Aug 8 18:03:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0761610657C5 for ; Wed, 8 Aug 2018 18:03:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-11.consmr.mail.ne1.yahoo.com (sonic308-11.consmr.mail.ne1.yahoo.com [66.163.187.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 628C88AEFB for ; Wed, 8 Aug 2018 18:03:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: _rp3.nIVM1kI1fzKuHADzGCD32Kad3Y9IbEjoe9I4vs0wbtb8PBbiHZ5EwzkTTf vxXHx1Qtu8F0SbGct.ZXfE_7wduCRl8l_ruGMUvcxGexiwFlCZ5jOOGN54mJYrKVArrEi6bO2sh2 ao_BKCHfgqvHZEFeBXCAWiDhOzT_Wo79nGfDOtGoSd59z7gHauL0x2DjxT_4GG.oH99PcG9fzfQ8 DF3WnRIA4ccOU3k9juYaLoafruY1RKQifays20dpZOeNW25uAgoodz2Q8Ml4hCaq1X.C2uxyaYsi 0tJd3nR4DYdzs9of82Ja6NzuFO_.AtwB4X2SmK8JjIHMLl7FEI1wJx.JhJ69I2_EwHjb.ym1pU0J InvXlC5m9UyrF0uPRwQXgtoSmhJKUznpkpDgQDgVaV0MiIV.wDZXSQyBgn7hZNTJPd9UJS3Odmge bIISPqoi2IVlD7lUn6vuMTG7dhrgc1LIaual8qM.kYNBAiq17aWjDW1AQZ_Z60xIBARKdduZL9nG rRdu2o_JUZTxydkhctccVSbufwzJmnoFhOj83MkOn09P_6Y6xkYC_rCuqc98vrCD7f2_q6NhxSTp jhQiLnPPt23ONYC2YDysSLNU_kje.AgMvkvrXqGokqKOXw24.x4nY3IOOsoRgVCaJn5sycCygUOl YT_q1lUqhTDIxAIFCb64KZ8_EXccZAC_t3qTTFRvFPx3NOnH0JpvMf_5wjQlHzl80sv5FvJfx7sX J6xO993M3NowJpAvctJNao8.51q2wfjsHxuhUxyqkC_WNxCdYdBCP0y81W6DjkIM3_3Y75EW7EyI gy7PQ5FWp88P8YUOCHvNE6L1LL1LIvcdzCRdsnlFmpbFVn4aaoUclyuLCYS8sh7EcphZFjFK3sIt 3IUHBg8_JqlPF.nz0lazL53V3dIZ8DZxh4d2afUXr1JiS3eEuQLK1UJaxPxF_wuDzca.I6wTveDR 6Ws8JGvWYjIsfS7bNIyZSC47IetV7_dFNiDdPM.7fWM7InsbI7y.S7N_YnK1RkeoWkPwVfGxoQdZ ZSUKr_V8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Wed, 8 Aug 2018 18:03:42 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp429.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d615beec8ba8e2e8e02f09a9d92fb9e5; Wed, 08 Aug 2018 18:03:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180808153800.GF26133@www.zefox.net> Date: Wed, 8 Aug 2018 11:03:37 -0700 Cc: Mark Johnston , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2AEF9E2E-C303-4962-8CB3-9BF180D91444@yahoo.com> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 18:03:49 -0000 On 2018-Aug-8, at 8:38 AM, bob prohaska wrote: > On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: >> On Wed, Aug 01, 2018 at 09:27:31PM -0700, Mark Millard wrote: >>> [I have a top-posted introduction here in reply >>> to a message listed at the bottom.] >>>=20 >>> Bob P. meet Mark J. Mark J. meet Bob P. I'm >>> hopinh you can help Bob P. use a patch that >>> you once published on the lists. This was from: >>>=20 >>> = https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html >>>=20 >>> Bob P. has been having problems with an rpi3 >>> based buildworld ending up with "was killed: >>> out of swap space" but when the swap partitions >>> do not seem to be heavily used (seen via swapinfo >>> or watching top). >>>=20 >>>> The patch to report OOMA information did its job, very tersely. The = console reported >>>> v_free_count: 5439, v_inactive_count: 1 >>>> Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out = of swap space >>>>=20 >>>> The entire buildworld.log and gstat output are at >>>> http://www.zefox.net/~fbsd/rpi3/swaptests/r336877M/ >>>>=20 >>>> It appears that at 18:08:21 a write to the USB swap device took = 530.5 ms,=20 >>>> next top was killed and ten seconds later c++ was killed, _after_ = da0b >>>> was no longer busy. >>=20 >> My suspicion, based on the high latency, is that this is a = consequence >> of r329882, which lowered the period of time that the page daemon = will >> sleep while waiting for dirty pages to be cleaned. If a certain = number >> of consecutive wakeups and queue scans occur without making progress, >> the OOM killer is triggered. That number is vm.pageout_oom_seq - = could >> you try increasing it by a factor of 10 and retry your test? >>=20 >>>> This buildworld stopped a quite a bit earlier than usual; most of = the time >>>> the buildworld.log file is close to 20 MB at the time OOMA acts. In = this case >>>> it was around 13 MB. Not clear if that's of significance. >>>>=20 >>>> If somebody would indicate whether this result is informative, and = any possible >>>> improvements to the test, I'd be most grateful.=20 >>=20 >> If the above suggestion doesn't help, the next thing to try would be = to >> revert the oom_seq value to the default, apply this patch, and see if >> the problem continues to occur. If this doesn't help, please try >> applying both measures, i.e., set oom_seq to 120 _and_ apply the = patch. >>=20 >> diff --git a/sys/vm/vm_pagequeue.h b/sys/vm/vm_pagequeue.h >> index fb56bdf2fdfc..29a16060253f 100644 >> --- a/sys/vm/vm_pagequeue.h >> +++ b/sys/vm/vm_pagequeue.h >> @@ -74,7 +74,7 @@ struct vm_pagequeue { >> } __aligned(CACHE_LINE_SIZE); >>=20 >> #ifndef VM_BATCHQUEUE_SIZE >> -#define VM_BATCHQUEUE_SIZE 7 >> +#define VM_BATCHQUEUE_SIZE 1 >> #endif >>=20 >> struct vm_batchqueue { >=20 > The patched kernel ran longer than default but OOMA still halted = buildworld around > 13 MB. That's considerably farther than a default build world have run = but less than > observed when setting vm.pageout_oom_seq=3D120 alone. Log files are at > = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/ >=20 > Both changes are now in place and -j4 buildworld has been restarted.=20= >=20 I'll note that top has a "sort by RES"(ident) memory use that can be an interesting order for these contexts, showing largest figures first. -ores on the command line is one way to use that order. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 8 18:35:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB4F21066713 for ; Wed, 8 Aug 2018 18:35:45 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 5F32F8C4D9 for ; Wed, 8 Aug 2018 18:35:44 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id 192D671 for ; Wed, 8 Aug 2018 20:35:42 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 055831350F91A for ; Wed, 8 Aug 2018 15:35:36 -0300 (BRT) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Where are the DTS sources within HEAD Message-Id: <9F663B28-C76A-452E-87FA-58C3BD5C294F@obsigna.com> Date: Wed, 8 Aug 2018 15:35:35 -0300 To: freebsd-arm@FreeBSD.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 18:35:45 -0000 Hello, while it is easy to find the DTS sources for any of the 9.x, 10.x and = 11.x truncs, I cannot seem to find any relevant DTS source for the = BeagleBone Black within HEAD. The old DTS files used named constants and = had some helpful comments, for example: = https://svnweb.freebsd.org/base/release/11.2.0/sys/boot/fdt/dts/arm/beagle= bone-black.dts?revision=3D335563&view=3Dmarkup &am33xx_pinmux { 34 i2c1_pins: pinmux_i2c1_pins { 35 pinctrl-single,pins =3D < 36 AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | = MUX_MODE2) /* spi0_d1.i2c1_sda */ 37 AM33XX_IOPAD(0x95c, PIN_INPUT_PULLUP | = MUX_MODE2) /* spi0_cs0.i2c1_scl */ 38 >; 39 }; Only this does not help anything for 12, because everything changed. So, = out of which hell did the new DTS came to light? Best regards Rolf= From owner-freebsd-arm@freebsd.org Wed Aug 8 18:43:31 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C9491066AE0 for ; Wed, 8 Aug 2018 18:43:31 +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 F3BEC8CA87 for ; Wed, 8 Aug 2018 18:43:30 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: ed32b9f8-9b3a-11e8-93fa-f3ebd9db2b94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id ed32b9f8-9b3a-11e8-93fa-f3ebd9db2b94; Wed, 08 Aug 2018 18:43:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w78IhLoO056589; Wed, 8 Aug 2018 12:43:22 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533753801.9860.101.camel@freebsd.org> Subject: Re: Where are the DTS sources within HEAD From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@FreeBSD.org Date: Wed, 08 Aug 2018 12:43:21 -0600 In-Reply-To: <9F663B28-C76A-452E-87FA-58C3BD5C294F@obsigna.com> References: <9F663B28-C76A-452E-87FA-58C3BD5C294F@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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 18:43:31 -0000 On Wed, 2018-08-08 at 15:35 -0300, Dr. Rolf Jansen wrote: > Hello, > > while it is easy to find the DTS sources for any of the 9.x, 10.x and > 11.x truncs, I cannot seem to find any relevant DTS source for the > BeagleBone Black within HEAD. The old DTS files used named constants > and had some helpful comments, for example: > > https://svnweb.freebsd.org/base/release/11.2.0/sys/boot/fdt/dts/arm/b > eaglebone-black.dts?revision=335563&view=markup > > &am33xx_pinmux { > 34         i2c1_pins: pinmux_i2c1_pins { > 35                 pinctrl-single,pins = < > 36                         AM33XX_IOPAD(0x958, > PIN_INPUT_PULLUP | MUX_MODE2)       /* spi0_d1.i2c1_sda */ > 37                         AM33XX_IOPAD(0x95c, > PIN_INPUT_PULLUP | MUX_MODE2)       /* spi0_cs0.i2c1_scl */ > 38                 >; > 39         }; > > Only this does not help anything for 12, because everything changed. > So, out of which hell did the new DTS came to light? > > Best regards > > Rolf We now use the official public dts sources which come from the vendors. The files are in src/sys/gnu/dts/arm and the beaglebone files are all named am335x-bone* -- Ian From owner-freebsd-arm@freebsd.org Wed Aug 8 20:48:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D88CE106A6ED for ; Wed, 8 Aug 2018 20:48:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 497A2933A2 for ; Wed, 8 Aug 2018 20:48:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x529.google.com with SMTP id z8-v6so1629272pgu.8 for ; Wed, 08 Aug 2018 13:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=a457n+teJwenzC2Gcvvl+5yJ9SFxzHa9zsCq8MZkGyA=; b=CSSbFmDl7cqaAQWvddFGuJc+5ngm7uj9ZAfptWujeC3prslTKOU/MGqYhasdSpzWUb uHwmjn0cOfDWRB2X3xEUwTVsQQr5k8HWERubGLISLO28UGhUCIiw/izbQQjpqYP2hGKx W5yfplFZ2pkQBHvvdPCMQwytqR3HRVrMb892tg5BXLmJUWJYmqsj5f4d5uQkVnlrDyUk OD60aSYU8qBTa2iPnnGJkXG9G9f5MhRQmoxmzjXqZwS1ZUJ3CC7ZGl0dvz3HY4Hp7Kb/ mbLI9NZWJSuqxlSSYFiCI2VXUXVY/gEnkPhUi7eonT4F+Tl9zhCNr8tcMO8ys6jlJo1b AIwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=a457n+teJwenzC2Gcvvl+5yJ9SFxzHa9zsCq8MZkGyA=; b=BmovC0unhZyun5B5AA7oKP/lqybb1Bt7bTDKZaJN4Bki2HGZOKkF7zJm8Q3Xo7cWAM OlE2k3yXK8q6hvwq2LWbnIw+5P+b2c6FuGQF7woWUOIASKChJ5KROadl5MA9eJqr8IC9 FPWB/C74sgLyWzecGw+7/YzwUl+S/mcm1y5wMfz+2iYc9ldBATegG1+mgUOIqECqmxyd 69nY6JdrdMCGFLPAyG3S1QgR2rujM+wWdc3U2LXO/5MjaXpE2/RVufC2qJBvGtls8xEv tXtJVYjLRZQ/1L/ad/bk7kw4mSN3pyCWJGLvmrW5HQi/bxVb3rahfqn/Y3zZSPYH+bHo VXSA== X-Gm-Message-State: AOUpUlH48SdeV9eLiXlg2ZG/VHPzWrs4Vj5bUX0sfUScxLQaZ425ckGY GbS5DCGI//C4BqE4bse9Pf4= X-Google-Smtp-Source: AA+uWPyHfqWOmQ9O+gGxsmgQ33KGW4KQ+mSkxdT2OIQitxZlrWNG8SCyBIr88choAi04miniZ1JlIQ== X-Received: by 2002:a63:c114:: with SMTP id w20-v6mr3917143pgf.234.1533761328064; Wed, 08 Aug 2018 13:48:48 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id r64-v6sm9719809pfk.157.2018.08.08.13.48.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 13:48:46 -0700 (PDT) Sender: Mark Johnston Date: Wed, 8 Aug 2018 16:48:41 -0400 From: Mark Johnston To: bob prohaska Cc: Mark Millard , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180808204841.GA19379@raichu> References: <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180808153800.GF26133@www.zefox.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 20:48:50 -0000 On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: > The patched kernel ran longer than default but OOMA still halted buildworld around > 13 MB. That's considerably farther than a default build world have run but less than > observed when setting vm.pageout_oom_seq=120 alone. Log files are at > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/ > > Both changes are now in place and -j4 buildworld has been restarted. Looking through the gstat output, I'm seeing some pretty abysmal average write latencies for da0, the flash drive. I also realized that my reference to r329882 lowering the pagedaemon sleep period was wrong - things have been this way for much longer than that. Moreover, as you pointed out, bumping oom_seq to a much larger value wasn't quite sufficient. I'm curious as to what the worst case swap I/O latencies are in your test, since the average latencies reported in your logs are high enough to trigger OOM kills even with the increased oom_seq value. When the current test finishes, could you try repeating it with this patch applied on top? https://people.freebsd.org/~markj/patches/slow_swap.diff That is, keep the non-default oom_seq setting and modification to VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the kernel to print messages to the console under certain conditions, so a log of console output will be interesting. From owner-freebsd-arm@freebsd.org Wed Aug 8 21:02:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4AEB106AFDD for ; Wed, 8 Aug 2018 21:02:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3AEF393F40 for ; Wed, 8 Aug 2018 21:02:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: HMj5RcAVM1luvjOQLPn_G5N0BtL3tomjYPkJGP.6Ewk_Wq_dpwdbspNme1uISIs nL7GdqNXaSQMIOGw0Y7CfKNvQtKgMxpomV.pOpgEP2khVCCZEWsZo9X1mB4Pu3lGOGN1fufEoZ.Y VWD0t88yGO6lhB8_7VD1cpRkQWaCrtjdsVNnTauBgxfNIy7Vcu1VrL0EsQ3n.tNLA71EzkFt4qhw ANOIke_2fggpOC4w_MJvVK_Hmm7QG7tsh5HRE6Nd6T_ctqxDkJwaZnN88XOLp0oh7VZZh658qBHx CZU_JIJm4UagxoVDchahifvNd_N83VfxDLfxPErL2J.nZ5hJTdKg_FupQccxCa8Wvxdg2ProMD8n jDACC2fiecCKNlmnMbK6IGYFXzP148VcgaVmPBgpkn1liOALLPPbt5RklZ0GMT9kEPvFt.lxNuLH YXJzJd7xJ6d3tf90l2AO_49I4ZN2SQUw90B9Iix7rzXJuqusbrrcRYXrn6klfb7eYDdvTUVCa6mB hFes.VjEt.3GGvP2eZjIVXojdMNPx24rJVS.S3GzYm1xA6JuTzNAEGTIWy906QBrUlDRAMH6Mlut fNth2XIna3ZAGOd_rJd5SNx5uFfb7FT99Ucww8UJLn8z7Sec4xKw_2Vcnrd0DmgtnSDj_bZhnZSs sakOMRqd2RULajXM7LrA.CkkoaSF725W0TkdrMtkzsDzIMSTw..Bcuw75CA40wGEa3vS9GAgHxS8 eza9GCF1eTtTepLMB.15rLiJo8Na8KLyamd_42.0sviXDwioxEXuFD7nK1VpFDQSho05g8dkra3i 42DDOfTrSC2ZTD8xeZXCBJJUdPU_YnwMtGULli1DysZzXUdvh5cB7t6qHSS6Ca5q732q1.Vj.LJF rnFoGIpgSlxI56K_zdeftHv7tj3TTzkMBt1AlOtAzd_eEa7UrOWS.UKb7ikCItDOy45moNia.zfo WQtbiy1kSD2yuCrr8vWsyFHB_yaKqZeMn.617TDGatQhV.Qy5kQDUZB6NMNn0_y10w9hFtPZM3je 4mncCSOdvUw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Aug 2018 21:02:39 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp430.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d6d90b079c097a43e7e27ad7b7fe5143; Wed, 08 Aug 2018 21:02:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180808204841.GA19379@raichu> Date: Wed, 8 Aug 2018 14:02:36 -0700 Cc: bob prohaska , Mark Millard via freebsd-arm , Trev , John Kennedy , Jamie Landeg-Jones Content-Transfer-Encoding: quoted-printable Message-Id: <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> References: <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> To: Mark Johnston X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 21:02:47 -0000 On 2018-Aug-8, at 1:48 PM, Mark Johnston wrote: > On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: >> The patched kernel ran longer than default but OOMA still halted = buildworld around >> 13 MB. That's considerably farther than a default build world have = run but less than >> observed when setting vm.pageout_oom_seq=3D120 alone. Log files are = at >> = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/ >>=20 >> Both changes are now in place and -j4 buildworld has been restarted.=20= >=20 > Looking through the gstat output, I'm seeing some pretty abysmal = average > write latencies for da0, the flash drive. I also realized that my > reference to r329882 lowering the pagedaemon sleep period was wrong - > things have been this way for much longer than that. Moreover, as you > pointed out, bumping oom_seq to a much larger value wasn't quite > sufficient. My understanding is that some other folks involved in the message exchange replicated the OOM kills without having evidence of issues like Bob P. has with large latencies for his hardware. The latencies may be sufficient but not necessary. Getting some of the other folks to run your tests would likely be good. > I'm curious as to what the worst case swap I/O latencies are in your > test, since the average latencies reported in your logs are high = enough > to trigger OOM kills even with the increased oom_seq value. When the > current test finishes, could you try repeating it with this patch > applied on top? = https://people.freebsd.org/~markj/patches/slow_swap.diff > That is, keep the non-default oom_seq setting and modification to > VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the = kernel > to print messages to the console under certain conditions, so a log of > console output will be interesting. Sounds like anyone else running tests should also have all 3 changes in place. I've CC'd some folks from the exchange that I think were running some tests. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 8 21:12:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D4A7106B33C for ; Wed, 8 Aug 2018 21:12:56 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C1859468C for ; Wed, 8 Aug 2018 21:12:55 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533762772; bh=uFXxV7mjenLkZ9vDRVcRHFVQh/vVHrYOj0VKiwAewPg=; h=Subject:To:References:From:Date:In-Reply-To; b=JH7xKqEExqM3JdT+Cbbh/I1JQBL4fc7I1UTpAZd/lW6yX1efh7ANu+8hami5pI9ym dBhwWF2mZLtU7fy7aCzeKj7o/VpFj/302zj6BKOk8r20AAKIfKowglvlL/lK3/4s9H S/tXTJhDYz5alngPcmbYPIqBIlgDLETYlxrDM+A4= Subject: Re: cross compile for rpi3 help needed To: freebsd-arm@freebsd.org References: <9d91c7f3-c41f-7ce0-4c79-0bc31aaa4331@nethead.se> From: Per olof Ljungmark Message-ID: <75a71863-800a-6449-1bea-ea2dd0aa678a@nethead.se> Date: Wed, 8 Aug 2018 23:12:50 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <9d91c7f3-c41f-7ce0-4c79-0bc31aaa4331@nethead.se> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 21:12:56 -0000 On 8/8/18 5:47 PM, Per olof Ljungmark wrote: > In the process of learning arm I have set up a testing platform with > 12-CURRENT r336739 and reading release(7). > > The only change made to src is > SRCBRANCH="base/head@r337160" > in RPI3.conf > > /etc/make.conf and src.conf are empty > > command is > > sh release.sh -c arm64/RPI3.conf > > The build goes on for a while and stops with > ... > --- installconfig_subdir_usr.bin/ofed/libibverbs/ud_pingpong --- > ===> usr.bin/ofed/libibverbs/ud_pingpong (installconfig) > --- installconfig_subdir_share --- > --- installconfig_subdir_share/vt --- > ===> share/vt (installconfig) > --- installconfig_subdir_share/zoneinfo --- > ===> share/zoneinfo (installconfig) > --- installconfig_subdir_share/vt --- > --- installconfig_subdir_share/vt/fonts --- > ===> share/vt/fonts (installconfig) > --- installconfig_subdir_share/vt/keymaps --- > ===> share/vt/keymaps (installconfig) > chroot: /etc/rc.d/ldconfig: Exec format error > > What am I missing here? Replying to myself: Apparently I started release.sh from the wrong place - next try went well. From owner-freebsd-arm@freebsd.org Wed Aug 8 21:42:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82900106C56F for ; Wed, 8 Aug 2018 21:42:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CE74095E83; Wed, 8 Aug 2018 21:42:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w78LgO7i029802 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Aug 2018 14:42:26 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w78LgOST029801; Wed, 8 Aug 2018 14:42:24 -0700 (PDT) (envelope-from fbsd) Date: Wed, 8 Aug 2018 14:42:24 -0700 From: bob prohaska To: Mark Johnston Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180808214224.GA29312@www.zefox.net> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806155837.GA6277@raichu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 21:42:10 -0000 On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > > If the above suggestion doesn't help, the next thing to try would be to > revert the oom_seq value to the default, apply this patch, and see if > the problem continues to occur. If this doesn't help, please try > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > Applying both measures resulted in a panic, not entirely unlike the effect of deliberately running the machine out of swap on microSD. The first obvious sign of trouble was errors attributed to da0: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 25 bc b8 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain but instead of going on endlessly a panic followed a few lines later: swap_pager: I/O error - pageout failed; blkno 47015,size 16384, error 5 ending with panic: vm_thread_swapin: cannot get kstack for proc 615 It appears that the gstat script stopped before this, since these console messages never made it to swapscript.log. What I could think of to capture is at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/pageout120/ The machine accepted a reboot command at the serial console and came up without any manual intervention. Thanks for reading, any suggestions on what to try next are welcome! bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 8 21:51:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5BCB106CB26 for ; Wed, 8 Aug 2018 21:51:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FA85965AC for ; Wed, 8 Aug 2018 21:51:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x243.google.com with SMTP id 139-v6so5757340itf.0 for ; Wed, 08 Aug 2018 14:51:28 -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=AyqAaVZb2Dk7jJOY0Ae8z8m1WyULXg6bXLOXrk9V6dg=; b=bTNNKWu+9YtyAvJDoxrhGwqDa1PLX89AU9na9UJZ73CKqaySiwoRxBMm7QZtq0lNkj geKXabO+t7jox6pbJDAJg1LNw1pJxhbLlxoeYY4EgicLuEJ6bIeXPEKUjYsjjR3O67Cq Xys+U3ch2TwWA12HMlnf3xti5lRkZukj8hyem2wLpsq9g56ouAxhqS8+gnrqyMg0QF0K qKtrWgPPg01WatE6Biaz7KsLVenvNEj6ceFHbF9a/jyYHJ0SMDfi4zp+/rEOuHYqyRyW yngtsVjVwjkzg5f6WLngjis+mH0Eq8ocpdQalc+1FAE0HJ67LXsmMqLqY9RJOwLP94zZ UPrw== 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=AyqAaVZb2Dk7jJOY0Ae8z8m1WyULXg6bXLOXrk9V6dg=; b=LNHQEga95qDKcFA3/2KIYUq3sfGTlv52K5EclCyVyvI/BcIIWzoBolOEthAMUeEQ5C QqcCqNHupzDMvSxEiIj6fUTi3RE3zduJbnnGUWtzQTTOOzEijZ6sf6GiklHYrejDjp7n oIvTVRiSpq32JPhopXVR6yqnRKcuIBN6wr/JivuNzBU3860kixoptJpq6fAXXBMLLVtU U5QG+5rZPGkwKkgOMxfcQJgdXjhaKQbDjVNwzN7fZEIh3IngFtGbSWfZ/gG8e0X27HBh Ux9LXcYNjuZn+stCqlXuWa7rnzODbKOHFR0DNZGZnIDrbn+z48g6ti5tWYbHL2AEBML1 gzBQ== X-Gm-Message-State: AOUpUlHBoIG0m0lvEShpt8FW20hjBEeXpAYpZ/WQY4cCLe/Eq9Gp8rkt 0Xct3ulOlviWjV9CxfL+iaOd4w42Y4gtWjTPeoazPEfA9/X2NQ== X-Google-Smtp-Source: AA+uWPy7oVUhWJHBkdWqEhzet7LwEqbn1gk9/HicQiOYX81t4qaeUgxbLJWCL1QBeC0YoizBcCtAGOMB+57mg891s3w= X-Received: by 2002:a02:3344:: with SMTP id k4-v6mr4196328jak.45.1533765087484; Wed, 08 Aug 2018 14:51:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 14:51:26 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180808204841.GA19379@raichu> References: <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> From: Warner Losh Date: Wed, 8 Aug 2018 15:51:26 -0600 X-Google-Sender-Auth: vzMNdGSDKNZPXdf2evtU3U_4rxY Message-ID: Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: Mark Johnston Cc: bob prohaska , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 21:51:29 -0000 On Wed, Aug 8, 2018 at 2:48 PM, Mark Johnston wrote: > On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: > > The patched kernel ran longer than default but OOMA still halted > buildworld around > > 13 MB. That's considerably farther than a default build world have run > but less than > > observed when setting vm.pageout_oom_seq=120 alone. Log files are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/ > 1gbsdflash_1gbusbflash/batchqueue/ > > > > Both changes are now in place and -j4 buildworld has been restarted. > > Looking through the gstat output, I'm seeing some pretty abysmal average > write latencies for da0, the flash drive. I also realized that my > reference to r329882 lowering the pagedaemon sleep period was wrong - > things have been this way for much longer than that. Moreover, as you > pointed out, bumping oom_seq to a much larger value wasn't quite > sufficient. > > I'm curious as to what the worst case swap I/O latencies are in your > test, since the average latencies reported in your logs are high enough > to trigger OOM kills even with the increased oom_seq value. When the > current test finishes, could you try repeating it with this patch > applied on top? https://people.freebsd.org/~markj/patches/slow_swap.diff > That is, keep the non-default oom_seq setting and modification to > VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the kernel > to print messages to the console under certain conditions, so a log of > console output will be interesting. Experience tells me that worst case is about 10x-50x median (which kinda tracks the average that gstat reports). For SD cards, it may be much much worse. Like seconds to tens of seconds worst case. I don't think the swapper is well tuned to devices that have such a large dynamic range and suck so bad when driven to the brink. Warner From owner-freebsd-arm@freebsd.org Wed Aug 8 21:55:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 095F0106CE8E for ; Wed, 8 Aug 2018 21:55:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88C3396934 for ; Wed, 8 Aug 2018 21:55:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id o22-v6so3126783ioh.6 for ; Wed, 08 Aug 2018 14:55:54 -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=8MCbMfbLFbhc5sCUF6YeL/6uB+jG3N0JaK3Q7pH4Dxk=; b=yWQcGfO4VR2nWSul9O2Fq2HDtnUWnQODewMf0PXFKzHXQz6tDA78jTq8FXS0Kq4TJd 8XaGuH2MdO19kGtc+0xCtGXfPWFRve1k0gAyw6b/V5SrJ995cSomBVnbCfvr5sNhxUqC SxyStE6xY1BbXJecrz7iQbVqOizY+73irHbSFfetyEBjo4nWPL7lrbPRf2M1OiZfEiN5 8d8bC1JvJNkTvxqZbvxIMGSwZWeXyhmM6O/EtqeWyYdllwqnFhg2Zq3tagPnIwbJXi+0 KggLryxtUOWN8ypbTOZCCA65rFB7pYb544dRF8Zl2f+p4KjGu3Yc0MwBL/qcRoyty6WD /FhA== 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=8MCbMfbLFbhc5sCUF6YeL/6uB+jG3N0JaK3Q7pH4Dxk=; b=Kscpve8fuHsj7iKbg9TOiVdMaDbV7LWVJAwY1+GX93HO0/SipQgNbXm7z+bIUHEXX1 eQLusKjHU3yoZoigpnSp3Rl2a+6S0aYkAM/0yCggQic17gIDFVID+CLgUXEDNkf6A6Th vX5QJL3p6hjUVA2bWMKB0f/+4rlJ88kPTxt46jbY8qFZYI0s8WoD145F7AkY6Sho0sVk R1JrIt9KcFWx/U8sfKEu5ZHSfD5M9Aq1iKVFSqrHqI/kKe5SrJZCkqwyQ28gF+DjRJQe hIDvxiv1tiUHru57HBe7LE3WJdyYDFjQGBDs35+N2MX3NssYp1AU2MK7JpiGocYY7ARl KZhg== X-Gm-Message-State: AOUpUlGneBEOZ4zAGOpgn7ta3lKR5HG29i5tZy2jlK46VrmF7ngR22Mz JZEm/Wayw+Tndx4zbMFvU012JGjxt56FTNCnpgE9VLi3QQ7xWg== X-Google-Smtp-Source: AA+uWPzLct4ZMsA2pDEmYKEOuCY1Gan55qQOeJszSvdS9g67KDaT4OXNhJuAjMEcACQ1dalZYHJ0zTna/rRZ3fjc2vM= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr3727724ioa.299.1533765353649; Wed, 08 Aug 2018 14:55:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 14:55:52 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180808214224.GA29312@www.zefox.net> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808214224.GA29312@www.zefox.net> From: Warner Losh Date: Wed, 8 Aug 2018 15:55:52 -0600 X-Google-Sender-Auth: _NRvnjzhbDGzYq45LlN6nVPqSco Message-ID: Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: bob prohaska Cc: Mark Johnston , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 21:55:55 -0000 On Wed, Aug 8, 2018 at 3:42 PM, bob prohaska wrote: > On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > > > > If the above suggestion doesn't help, the next thing to try would be to > > revert the oom_seq value to the default, apply this patch, and see if > > the problem continues to occur. If this doesn't help, please try > > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > > > > Applying both measures resulted in a panic, not entirely unlike the effect > of deliberately running the machine out of swap on microSD. The first > obvious > sign of trouble was errors attributed to da0: > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 25 bc b8 00 00 80 00 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > So we're pushing so hard that the writes are actively failing... With the da driver there's some hope. Add options IOSCHED to the kernel config file and reboot. This will give you some detailed statistics, as well as power-of-two bucketized latency histograms. It may even be a vector forward to slow the writes / trims down, though there's some issues when you slow writes down TOO much, it helps *A*LOT* keep the system responsive. We do that at work to make our consumer SSDs not suck for serving content (reading) while we're doing some writes to them... The thumb drives are like the consumer SSDs we buy, only crappier... Warner From owner-freebsd-arm@freebsd.org Wed Aug 8 22:42:20 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96278106E1D6 for ; Wed, 8 Aug 2018 22:42:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0226E7038B; Wed, 8 Aug 2018 22:42:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w78MgScY029994 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Aug 2018 15:42:29 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w78MgSvb029993; Wed, 8 Aug 2018 15:42:28 -0700 (PDT) (envelope-from fbsd) Date: Wed, 8 Aug 2018 15:42:27 -0700 From: bob prohaska To: Warner Losh Cc: Mark Johnston , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180808224227.GB29312@www.zefox.net> References: <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808214224.GA29312@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 22:42:20 -0000 On Wed, Aug 08, 2018 at 03:55:52PM -0600, Warner Losh wrote: > On Wed, Aug 8, 2018 at 3:42 PM, bob prohaska wrote: > > > On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > > > > > > If the above suggestion doesn't help, the next thing to try would be to > > > revert the oom_seq value to the default, apply this patch, and see if > > > the problem continues to occur. If this doesn't help, please try > > > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > > > > > > > Applying both measures resulted in a panic, not entirely unlike the effect > > of deliberately running the machine out of swap on microSD. The first > > obvious > > sign of trouble was errors attributed to da0: > > > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 25 bc b8 00 00 80 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > > > > So we're pushing so hard that the writes are actively failing... > > With the da driver there's some hope. Add options IOSCHED to the kernel > config file and reboot. This will give you some detailed statistics, as > well as power-of-two bucketized latency histograms. It may even be a vector > forward to slow the writes / trims down, though there's some issues when > you slow writes down TOO much, it helps *A*LOT* keep the system responsive. > We do that at work to make our consumer SSDs not suck for serving content > (reading) while we're doing some writes to them... The thumb drives are > like the consumer SSDs we buy, only crappier... > I've added some sorted versions of the swapscript output keyed on ms/read and ms/write to the directory at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/pageout120/ and randomly through the older testcases. Some of the delays approach a minute, and that's been the case for as long as I've been keeping track. However, the big delays tend to be scattered through the gstat log and aren't necessarily associated with trouble, nor always with high levels of swap usage. Mark Johnston's slow_swap.diff patch is compiling now, if that succeeds I'll try it first. If it fails (I may have damaged /usr/obj in the last test run) I'll add options IOSCHED to the GENERIC config file before trying again. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 8 22:43:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBB31106E25E for ; Wed, 8 Aug 2018 22:43:07 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 6095370419; Wed, 8 Aug 2018 22:43:06 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id 267175D; Thu, 9 Aug 2018 00:43:05 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 0175F1350F91A; Wed, 8 Aug 2018 19:43:00 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Where are the DTS sources within HEAD From: "Dr. Rolf Jansen" In-Reply-To: <1533753801.9860.101.camel@freebsd.org> Date: Wed, 8 Aug 2018 19:42:59 -0300 Cc: freebsd-arm@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F663B28-C76A-452E-87FA-58C3BD5C294F@obsigna.com> <1533753801.9860.101.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 22:43:07 -0000 > Am 08.08.2018 um 15:43 schrieb Ian Lepore : > On Wed, 2018-08-08 at 15:35 -0300, Dr. Rolf Jansen wrote: >> ... >> while it is easy to find the DTS sources for any of the 9.x, 10.x and >> 11.x truncs, I cannot seem to find any relevant DTS source for the >> BeagleBone Black within HEAD. The old DTS files used named constants >> and had some helpful comments, for example: >>=20 >> https://svnweb.freebsd.org/base/release/11.2.0/sys/boot/fdt/dts/arm/b >> eaglebone-black.dts?revision=3D335563&view=3Dmarkup >>=20 >> &am33xx_pinmux { >> 34 i2c1_pins: pinmux_i2c1_pins { >> 35 pinctrl-single,pins =3D < >> 36 AM33XX_IOPAD(0x958, >> PIN_INPUT_PULLUP | MUX_MODE2) /* spi0_d1.i2c1_sda */ >> 37 AM33XX_IOPAD(0x95c, >> PIN_INPUT_PULLUP | MUX_MODE2) /* spi0_cs0.i2c1_scl */ >> 38 >; >> 39 }; >>=20 >=20 > We now use the official public dts sources which come from the = vendors. > The files are in src/sys/gnu/dts/arm and the beaglebone files are all > named am335x-bone* OK, I found it, thank you very much. Of special help was: = https://svnweb.freebsd.org/base/head/sys/gnu/dts/include/dt-bindings/pinct= rl/omap.h?view=3Dco. = https://svnweb.freebsd.org/base/head/sys/gnu/dts/include/dt-bindings/pinct= rl/am33xx.h?view=3Dco And according to these headers, the following: < AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | MUX_MODE2) AM33XX_IOPAD(0x95c, PIN_INPUT_PULLUP | MUX_MODE2) > translates to: < 0x958-0x800, (1 << 5)|(1 << 4) | 2 0x95c-0x800, (1 << 5)|(1 << 4) | 2 > =3D <0x158 0x32 0x15c 0x32> In addition, = https://github.com/jadonk/bonescript/blob/master/src/bone.js#L1408 and = #L1430 show that MUX_MODE2 is the correct choice. That means, in my I2C1 = overlay, I got the addresses and modes right. Anyway, still no luck. Best regards Rolf From owner-freebsd-arm@freebsd.org Wed Aug 8 23:15:20 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 764AA106EB89 for ; Wed, 8 Aug 2018 23:15:20 +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 G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05DB87169A for ; Wed, 8 Aug 2018 23:15:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id j81-v6so154075ite.0 for ; Wed, 08 Aug 2018 16:15:20 -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=AaPjKjDCrKLsA2ONly+7HNzZSKy1qRpC9M+2ujQDyP0=; b=xsnkjhCGTP/tbvy4EEmTyNjBaxTU20yJ1vMIH2mK1H+EJy13hLzQ0m+pbN6KIoxd7f SMU0xCC/eQfu/8Ky7P5k6updd2ittyaKSZ0indOfCwYPtaolHgxFLdwF5l1tcBMTAEos J4nQxndufzTRVSSFaJ0cJs3R8zyBgZ24hK0IeFdhsla3uQ9dH+hliWUZDaVs6DX0og8Q ajyIc0dBY0DDvEyBRSkODIO0V5CEVIjyGZPxp9kSBZ/zTpJ0R60Ip8R8WIO3dggRoWNA oVj/3oDQZVcHtdGC78rhL5fGsexrGaivzb7mXxEqji3X+jMdrI/pPqhlr8oY9M4uzxnE 6VmQ== 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=AaPjKjDCrKLsA2ONly+7HNzZSKy1qRpC9M+2ujQDyP0=; b=Emo0S7A/WaN96Y91jZ0KRNmYtXVOaRskuG2M2nm1dt1aq3xSFGxwDn4qJm81bTg800 PStZNlgbKOvqf4j8OGknjxY6OsZc5EUWg316LTrvxhLeeCWO81A7cRwJ7kNuxIVJUWI7 RNu9UlOYKUF/YcBSW6EOS/cUitchtPJf3KHMhWkGI63oIJ4ZxxqNiCElh84iB/NsvEyQ ufvkQwoI4MiivBtLDLc2JZb36NGq2Og8j2cc5mAumyjAFS3+Sj3sL8E6LS+VCcPcd2mh L45KuR6pUuapmTJxQBGkgqWc46PXwFEZSCw+zEO9IIyx4UrLD8dTiEr0nMIlFWKaNV8e AZKA== X-Gm-Message-State: AOUpUlFurY5ddRiqTp65gqk2GRnyZS2FIrvGkIdT9zpRoUC/UaLso/EK yuWRoos6rIwLgsz7Is7sjimcDHAJVUXS8yllKkIFxLlVduDYQA== X-Google-Smtp-Source: AA+uWPwFyWIsFpaTmMXwsfk+bQzCRrQikDkXOZ0CY0ZEdYYJPPcqKlARic2Y/4sOLJM/Zoylx/RLV3NsRHazT4p6imA= X-Received: by 2002:a24:b211:: with SMTP id u17-v6mr40748ite.1.1533770119286; Wed, 08 Aug 2018 16:15:19 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 16:15:18 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180808224227.GB29312@www.zefox.net> References: <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808214224.GA29312@www.zefox.net> <20180808224227.GB29312@www.zefox.net> From: Warner Losh Date: Wed, 8 Aug 2018 17:15:18 -0600 X-Google-Sender-Auth: FSMv6HTPEt_AU5hs9Px44EPq0Jw Message-ID: Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: bob prohaska Cc: Mark Johnston , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 23:15:20 -0000 On Wed, Aug 8, 2018 at 4:42 PM, bob prohaska wrote: > On Wed, Aug 08, 2018 at 03:55:52PM -0600, Warner Losh wrote: > > On Wed, Aug 8, 2018 at 3:42 PM, bob prohaska wrote: > > > > > On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > > > > > > > > If the above suggestion doesn't help, the next thing to try would be > to > > > > revert the oom_seq value to the default, apply this patch, and see if > > > > the problem continues to occur. If this doesn't help, please try > > > > applying both measures, i.e., set oom_seq to 120 _and_ apply the > patch. > > > > > > > > > > Applying both measures resulted in a panic, not entirely unlike the > effect > > > of deliberately running the machine out of swap on microSD. The first > > > obvious > > > sign of trouble was errors attributed to da0: > > > > > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 25 bc b8 00 00 80 00 > > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > > > > > > > So we're pushing so hard that the writes are actively failing... > > > > With the da driver there's some hope. Add options IOSCHED to the kernel > > config file and reboot. This will give you some detailed statistics, as > > well as power-of-two bucketized latency histograms. It may even be a > vector > > forward to slow the writes / trims down, though there's some issues when > > you slow writes down TOO much, it helps *A*LOT* keep the system > responsive. > > We do that at work to make our consumer SSDs not suck for serving content > > (reading) while we're doing some writes to them... The thumb drives are > > like the consumer SSDs we buy, only crappier... > > > > I've added some sorted versions of the swapscript output keyed on ms/read > and > ms/write to the directory at > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/ > batchqueue/pageout120/ > and randomly through the older testcases. > > Some of the delays approach a minute, and that's been the case for as long > as I've > been keeping track. However, the big delays tend to be scattered through > the gstat > log and aren't necessarily associated with trouble, nor always with high > levels of > swap usage. > > Mark Johnston's slow_swap.diff patch is compiling now, if that succeeds > I'll > try it first. If it fails (I may have damaged /usr/obj in the last test > run) > I'll add > options IOSCHED > to the GENERIC config file before trying again. Yea, my I/O sched only tracks latencies out to 8.192s, but if we see any writes in that bucket, we know we're 100x slower than normal... Warner > From owner-freebsd-arm@freebsd.org Thu Aug 9 03:40:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1D861050C5B for ; Thu, 9 Aug 2018 03:40:17 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 75ADA7D034; Thu, 9 Aug 2018 03:40:17 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w793baTo095800 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Aug 2018 20:37:36 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w793bZFo095799; Wed, 8 Aug 2018 20:37:35 -0700 (PDT) (envelope-from warlock) Date: Wed, 8 Aug 2018 20:37:35 -0700 From: John Kennedy To: Mark Millard Cc: Mark Johnston , Jamie Landeg-Jones , Mark Millard via freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809033735.GJ30738@phouka1.phouka.net> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 03:40:18 -0000 On Wed, Aug 08, 2018 at 02:02:36PM -0700, Mark Millard via freebsd-arm wrote: > ... My understanding is that some other folks involved in the message > exchange replicated the OOM kills without having evidence of issues > like Bob P. has with large latencies for his hardware. The latencies > may be sufficient but not necessary. > > Getting some of the other folks to run your tests would likely be > good. ... > Sounds like anyone else running tests should also have all 3 > changes in place. > > I've CC'd some folks from the exchange that I think were running > some tests. My system is almost done crunching. Applying patches and tweaks is fine, but I think Bob P has some other reporting tweaks going that we'd want to replicate so we have more than a fail/no fail. I tend to be in the no-fail, which is more data I guess. I also have a much older (slower) SD card that I could put back into service and see if that tweaks me a more towards the maybe-fail camp. From owner-freebsd-arm@freebsd.org Thu Aug 9 06:42:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FE85105720A for ; Thu, 9 Aug 2018 06:42:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F69E82DDD; Thu, 9 Aug 2018 06:41:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w796gBu1031252 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Aug 2018 23:42:11 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w796gAC0031251; Wed, 8 Aug 2018 23:42:10 -0700 (PDT) (envelope-from fbsd) Date: Wed, 8 Aug 2018 23:42:10 -0700 From: bob prohaska To: Warner Losh Cc: Mark Johnston , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809064210.GA30347@www.zefox.net> References: <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808214224.GA29312@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 06:42:01 -0000 On Wed, Aug 08, 2018 at 03:55:52PM -0600, Warner Losh wrote: > > With the da driver there's some hope. Add options IOSCHED to the kernel > config file and reboot. This will give you some detailed statistics, as > well as power-of-two bucketized latency histograms. It may even be a vector > forward to slow the writes / trims down, though there's some issues when > you slow writes down TOO much, it helps *A*LOT* keep the system responsive. > We do that at work to make our consumer SSDs not suck for serving content > (reading) while we're doing some writes to them... The thumb drives are > like the consumer SSDs we buy, only crappier... > I tried adding options IOSCHED to the arm64 GENERIC kernel config at the end of the debugging support options, but buildkernel replied with /usr/src/sys/arm64/conf/GENERIC: unknown option "IOSCHED" I don't see any typos, should this option go elsewhere? Thanks very much! bob prohaska From owner-freebsd-arm@freebsd.org Thu Aug 9 06:56:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FA6E10578FB for ; Thu, 9 Aug 2018 06:56:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC5FE8351C; Thu, 9 Aug 2018 06:56:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w796unT1031311 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Aug 2018 23:56:49 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w796umY4031310; Wed, 8 Aug 2018 23:56:48 -0700 (PDT) (envelope-from fbsd) Date: Wed, 8 Aug 2018 23:56:48 -0700 From: bob prohaska To: Mark Johnston Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809065648.GB30347@www.zefox.net> References: <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180808204841.GA19379@raichu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 06:56:33 -0000 On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: > On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: > > The patched kernel ran longer than default but OOMA still halted buildworld around > > 13 MB. That's considerably farther than a default build world have run but less than > > observed when setting vm.pageout_oom_seq=120 alone. Log files are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/ > > > > Both changes are now in place and -j4 buildworld has been restarted. > > Looking through the gstat output, I'm seeing some pretty abysmal average > write latencies for da0, the flash drive. I also realized that my > reference to r329882 lowering the pagedaemon sleep period was wrong - > things have been this way for much longer than that. Moreover, as you > pointed out, bumping oom_seq to a much larger value wasn't quite > sufficient. > > I'm curious as to what the worst case swap I/O latencies are in your > test, since the average latencies reported in your logs are high enough > to trigger OOM kills even with the increased oom_seq value. When the > current test finishes, could you try repeating it with this patch > applied on top? https://people.freebsd.org/~markj/patches/slow_swap.diff > That is, keep the non-default oom_seq setting and modification to > VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the kernel > to print messages to the console under certain conditions, so a log of > console output will be interesting. The run finished with a panic, I've collected the logs and terminal output at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/pageout120/slow_swap/ There seems to be a considerable discrepancy between the wait times reported by the patch and the wait times reported by gstat in the first couple of occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT 2018 in swapscript.log. I'll see if Warner's IOSCHED option can be made to work. It wasn't recognized on the first try. Thanks for reading, and all your help! bob prohaska From owner-freebsd-arm@freebsd.org Thu Aug 9 08:21:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE399105B939 for ; Thu, 9 Aug 2018 08:21:59 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C11D868D9 for ; Thu, 9 Aug 2018 08:21:59 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533802916; bh=9NqjuYrE9dYZSbsnlEVueN8R9jkymIRshDpp37k1SIE=; h=Subject:To:References:From:Date:In-Reply-To; b=p8LmswQwKGcLJz8X43R2pbnGW6tl2o3IdApOuDiYRmhPUtnkuiBBPB75EB5F5dP37 kJBuTr6wdNGjfungb4uzr22oOJK+BcuU4lVPKLXKdh0v/2eMCiZXnU7TGH84mlL8ti flJtIEoEpv6GxDXjHwTfwJFVX4YhOVKDEb6Hh4Ic= Subject: Re: cross compile for rpi3 help needed To: freebsd-arm@freebsd.org References: <9d91c7f3-c41f-7ce0-4c79-0bc31aaa4331@nethead.se> <75a71863-800a-6449-1bea-ea2dd0aa678a@nethead.se> From: Per olof Ljungmark Message-ID: Date: Thu, 9 Aug 2018 10:21:54 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <75a71863-800a-6449-1bea-ea2dd0aa678a@nethead.se> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 08:22:00 -0000 On 8/8/18 11:12 PM, Per olof Ljungmark wrote: > On 8/8/18 5:47 PM, Per olof Ljungmark wrote: >> In the process of learning arm I have set up a testing platform with >> 12-CURRENT r336739 and reading release(7). >> >> The only change made to src is >> SRCBRANCH="base/head@r337160" >> in RPI3.conf >> >> /etc/make.conf and src.conf are empty >> >> command is >> >> sh release.sh -c arm64/RPI3.conf >> >> The build goes on for a while and stops with >> ... >> --- installconfig_subdir_usr.bin/ofed/libibverbs/ud_pingpong --- >> ===> usr.bin/ofed/libibverbs/ud_pingpong (installconfig) >> --- installconfig_subdir_share --- >> --- installconfig_subdir_share/vt --- >> ===> share/vt (installconfig) >> --- installconfig_subdir_share/zoneinfo --- >> ===> share/zoneinfo (installconfig) >> --- installconfig_subdir_share/vt --- >> --- installconfig_subdir_share/vt/fonts --- >> ===> share/vt/fonts (installconfig) >> --- installconfig_subdir_share/vt/keymaps --- >> ===> share/vt/keymaps (installconfig) >> chroot: /etc/rc.d/ldconfig: Exec format error >> >> What am I missing here? > > Replying to myself: Apparently I started release.sh from the wrong place > - next try went well. But the next failed again - twice - looks like this command is the problem: cd /scratch/usr/src; MACHINE_ARCH=aarch64 MACHINE=arm64 CPUTYPE= CC="cc -target aarch64-unknown-freebsd12.0 --sysroot=/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp -B/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++ -target aarch64-unknown-freebsd12.0 --sysroot=/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp -B/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target aarch64-unknown-freebsd12.0 --sysroot=/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp -B/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" PATH=/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/legacy/bin:/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/usr/sbin:/scratch/tmp/obj/scratch/usr/src/arm64.aarch64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 METALOG= MK_TESTS=no installconfig From owner-freebsd-arm@freebsd.org Thu Aug 9 15:04:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EA431069AB1 for ; Thu, 9 Aug 2018 15:04:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CFD4795E8 for ; Thu, 9 Aug 2018 15:04:33 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf1-x433.google.com with SMTP id p12-v6so2991191pfh.2 for ; Thu, 09 Aug 2018 08:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=m2GJjX16ucthUCPE6scBa3aCTlj18xkaOJsleIm7R7c=; b=JJy44qRDJVFHfebYZo1vEe5SPlADwTfNAayp6KIt9i3rSraVDm8/KCgEeQI3AqmZJP NAipcZUSNoyoN9uYrdrpkgqfjkvHscnAWZ+tUJ1iQ7SKBNVV6TE33BREYgz1Ptfxv0b+ qcem+4DYllbdtBWnVFB9Ei4Qc41lbywGufDwWluzfeq0ntl4MMmVya3QDw30Ve4FXoHd SZq2dTKcjAu5yC20MOU79KfCu4AgpE0SLg/C5PnGD1sQO/64ui0E1iZidQiVpVE4novG XhLFadfvvj3hS9z2Zd5Hsppmg2a1sJCBONU2uhhmt5KpDRfEO69s5AZeW9lZfZ7kpg0A 0jPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=m2GJjX16ucthUCPE6scBa3aCTlj18xkaOJsleIm7R7c=; b=iPEpyKjzzObtZ5/ua/4D3GxMpw8vUcO04i8n9MsUiPqDtepnWQUSFcCPDqet/adu48 jFoFPaKkQlo4I2ns4awSyCu9G54BNl1JT5iMuuo98K9IOgjiRhSJ2/0xXSb4q5pnRXeU 1HoFHb5qZs0DCYY7yQP8BnNkIFLBx9Pss3uHrAjeoJ+1j3fT/T1ESWIunQ47gvZWyIPg 1xkHlSo1ZrHYq8sBmhTyjSoq0ZaclBpFdn1avMDPo71QFhFMFq/mMjLEi7VKRpbm3gTC 7McJ12Ix+eE4TeXsmZ9VkVSrZivV3AT7H07lBfdOb2zQybsM1vJOjnf6PfcCKHw+9xqy 2pOg== X-Gm-Message-State: AOUpUlEp4SKbN/nowx4AgUckvMsFE08tH4N3FSjjYG4FDzLZtwBLEFLm sCwr6FRJ98jjzcQU/0t3Ec0wiv7e X-Google-Smtp-Source: AA+uWPyw3X9BRpb+ZE7HCIXFCjSA1OHUN2UKPJutO5FH2Oqk5A2VeA6VjmPfd9++Y2AU6O/FO85nSA== X-Received: by 2002:a62:c819:: with SMTP id z25-v6mr2773393pff.44.1533827072554; Thu, 09 Aug 2018 08:04:32 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id i1-v6sm11230295pgj.38.2018.08.09.08.04.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 08:04:31 -0700 (PDT) Sender: Mark Johnston Date: Thu, 9 Aug 2018 11:04:28 -0400 From: Mark Johnston To: bob prohaska Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809150428.GB68459@raichu> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808214224.GA29312@www.zefox.net> <20180809064210.GA30347@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180809064210.GA30347@www.zefox.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:04:34 -0000 On Wed, Aug 08, 2018 at 11:42:10PM -0700, bob prohaska wrote: > On Wed, Aug 08, 2018 at 03:55:52PM -0600, Warner Losh wrote: > > > > With the da driver there's some hope. Add options IOSCHED to the kernel > > config file and reboot. This will give you some detailed statistics, as > > well as power-of-two bucketized latency histograms. It may even be a vector > > forward to slow the writes / trims down, though there's some issues when > > you slow writes down TOO much, it helps *A*LOT* keep the system responsive. > > We do that at work to make our consumer SSDs not suck for serving content > > (reading) while we're doing some writes to them... The thumb drives are > > like the consumer SSDs we buy, only crappier... > > > I tried adding > options IOSCHED > to the arm64 GENERIC kernel config at the end of the debugging support options, > but buildkernel replied with > /usr/src/sys/arm64/conf/GENERIC: unknown option "IOSCHED" > > I don't see any typos, should this option go elsewhere? Looks like the proper name is "CAM_IOSCHED_DYNAMIC". From owner-freebsd-arm@freebsd.org Thu Aug 9 15:21:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBAA71069ECE for ; Thu, 9 Aug 2018 15:21:57 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B3DE79D3F for ; Thu, 9 Aug 2018 15:21:57 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl0-x231.google.com with SMTP id x6-v6so2682153plv.10 for ; Thu, 09 Aug 2018 08:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DC6X8l5xKCi6WFmQEueGTpK975YaTWX9ESBXay2TBK8=; b=LyOQfhSe4hAbWUaROIORuFeHg4y3XUTPFV23o7cvrYlQ0iSjE8cbkHKTSvDcrXWt7A vSnAcLFBtHlSebmuUIvjRQT9G2LgnJr0Q9x/13GoBTAeeVDuGKTRM4kdyFjl5xi1liMb ig+WinZm12d008Uory+N4+j8EXW5Kf3V9nFby19ZqKkoqQddRMXuiTF0Lma5G/srVpNl SseoyXkzHHhQlR9O2sHHo/a8R+iUgoh4q4Jpvnwu/YDhpoG0oa9Ja3Yo0Gf3Y+spCrcT VTV55IJlctIAF2hby7QBbt89U3EfzGdPJFve1xa8XBoNwU0LFNw0NiZQiI16/OI1dxlT KMiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=DC6X8l5xKCi6WFmQEueGTpK975YaTWX9ESBXay2TBK8=; b=Q1dBkqlDEZyeGDjv5/IRHEPm7tuLsrnm7pA+7vdNkZ2BL9L+fNEsGVqLxjUn93L/mt OQvUx/rUFtHwWsVij8mv5sDELBox4GThDFQQdMZiUIpnOAM5qclfNHqAhB0lSlfQ5FBJ ux+9GE0rT/8i93F3TJiwMocgAs+2hQ6B0ybMlI52bnLx9CqNBCjaUsTIulqP2e5Rgfvt yz0Bphnu27SmqBg4e1GO0Dv52mpj2MCvKAVj5C71PwMu4l2fVw/JoiVOARL49FNuPo3J eVC5zjUPtnv1Uq2+vx3wQRgsfWsqK/bKF0QdYY5qn6UBx9BHn0sBa3tEZxJgHWygQ6Pf mSjQ== X-Gm-Message-State: AOUpUlHs/39da3fFr74eJyeRfyZDhDqPNg3UoQsOZngIWvrqtcdaWDWp u289NKN+T6EXa4x0UgNbv0I= X-Google-Smtp-Source: AA+uWPyr1m/V+P90i1A0CVwpLvrYFZBl936tCndABQrjVGTM9xRpG1UjUthSpia90rTwaQfcPB9APg== X-Received: by 2002:a17:902:201:: with SMTP id 1-v6mr2519407plc.310.1533828116231; Thu, 09 Aug 2018 08:21:56 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id a20-v6sm15293839pfc.14.2018.08.09.08.21.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 08:21:55 -0700 (PDT) Sender: Mark Johnston Date: Thu, 9 Aug 2018 11:21:52 -0400 From: Mark Johnston To: bob prohaska Cc: Mark Millard , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809152152.GC68459@raichu> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180809065648.GB30347@www.zefox.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:21:58 -0000 On Wed, Aug 08, 2018 at 11:56:48PM -0700, bob prohaska wrote: > On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: > > On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: > > > The patched kernel ran longer than default but OOMA still halted buildworld around > > > 13 MB. That's considerably farther than a default build world have run but less than > > > observed when setting vm.pageout_oom_seq=120 alone. Log files are at > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/ > > > > > > Both changes are now in place and -j4 buildworld has been restarted. > > > > Looking through the gstat output, I'm seeing some pretty abysmal average > > write latencies for da0, the flash drive. I also realized that my > > reference to r329882 lowering the pagedaemon sleep period was wrong - > > things have been this way for much longer than that. Moreover, as you > > pointed out, bumping oom_seq to a much larger value wasn't quite > > sufficient. > > > > I'm curious as to what the worst case swap I/O latencies are in your > > test, since the average latencies reported in your logs are high enough > > to trigger OOM kills even with the increased oom_seq value. When the > > current test finishes, could you try repeating it with this patch > > applied on top? https://people.freebsd.org/~markj/patches/slow_swap.diff > > That is, keep the non-default oom_seq setting and modification to > > VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the kernel > > to print messages to the console under certain conditions, so a log of > > console output will be interesting. > > The run finished with a panic, I've collected the logs and terminal output at > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/pageout120/slow_swap/ > > There seems to be a considerable discrepancy between the wait times reported > by the patch and the wait times reported by gstat in the first couple of > occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT 2018 in > swapscript.log. The reports of "waited for swap buffer" are especially bad: during those periods, the laundry thread is blocked waiting for in-flight swap writes to finish before sending any more. Because the system is generally quite starved for clean pages that it can reuse, it's relying on swap I/O to clean more. If that fails, the system eventually has no choice but to start killing processes (where the time period corresponding to "eventually" is determined by vm.pageout_oom_seq). Based on these latencies, I think the system is behaving more or less as expected from the VM's perspective. I do think the default oom_seq value is too low and will get that addressed in 12.0. From owner-freebsd-arm@freebsd.org Thu Aug 9 15:28:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D030B106A1C9 for ; Thu, 9 Aug 2018 15:28:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5107F79FF5 for ; Thu, 9 Aug 2018 15:28:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id z19-v6so5097550ioh.4 for ; Thu, 09 Aug 2018 08:28:11 -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=WrbUYVSrvd9cwZTkv1c9MBfrIEqYjM95SywAYd7cw9I=; b=wt9ignCU5BRi1UfGNizDSCW10YpfuPtwwHiX/R1+mF7LqoTWKjGEL9zq5nmf31nnkF lee06Rz8wUG8J5gfFHVra8xTVUDrpqpXxKoLTmQ92yUyhjJ9bn2Ppp9WXrym9MVovzUh ShoL7sFBxm4YNgg4WfMiWToMh+rcHXi4PK/ASTfvIpjW4YmthYwcAVJclhrwgSsV7QOW A2+gLgBsvhkoqezZB6l4Vv3Djmt45EVjMLJSal83vNKpKQZISkPv7Il9Qn3cOgQo4lNP UR39MVOQ2UaFfsCoDuDpCCVjA72bBQN0vTiFxwmpT3R5TPMrkLDwh33UwYh6Dt3BXVEL kCjw== 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=WrbUYVSrvd9cwZTkv1c9MBfrIEqYjM95SywAYd7cw9I=; b=G89frOmQfqoES1LrSk+6SDSSUvV7OZ7p04C+VtLBb/CMsZxxjcisM89jcNMxO9f6Rc U+4+HtUjnSVe3W0/W5KY4d5sZjK9h4TpfX2UGDnmiXCNlXYIJVSFpngiFeFX3lROXblL d41jSFs0cJISXPFmho5MkPLUL+/BxdibXQCvwHYtWhSzaeRVPflco8Q/HgvaTaVDo786 WduSms9ppc3CkuPXy67k2eKPGDQxruJ7n5GyJPa/wuKmRcREVYRg5sUTDDDa/DWvdzo0 fgWQeD3XDrYTMcWS1BqAlkg0Z8hMdmtN4IR/st7Mgltvw9ItqkO9PjxqWYwc2hwh8mMK K+dg== X-Gm-Message-State: AOUpUlE6Srbyetn3WQepGjG4wtpyzOmOnv15jyYBgMtsRzZy9GBi6ml1 94WST1aMwoLzSQb9RhSYycMBVK1HEIyjLOlI5aUByezyPng= X-Google-Smtp-Source: AA+uWPx8IRgwJbSTH2wPEOr7V9qQnxd0OpHztaOw7N+IQP+SWZIy0uRfbHBIbv7QQNmplrm79z2+u9xSQ1JlKdrvojA= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr2156544ioa.168.1533828490339; Thu, 09 Aug 2018 08:28:10 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 08:28:09 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180809152152.GC68459@raichu> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> From: Warner Losh Date: Thu, 9 Aug 2018 09:28:09 -0600 X-Google-Sender-Auth: GwYJjP4HrUxuywHRQMKvjwCTeys Message-ID: Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: Mark Johnston Cc: bob prohaska , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:28:12 -0000 On Thu, Aug 9, 2018 at 9:21 AM, Mark Johnston wrote: > On Wed, Aug 08, 2018 at 11:56:48PM -0700, bob prohaska wrote: > > On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: > > > On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: > > > > The patched kernel ran longer than default but OOMA still halted > buildworld around > > > > 13 MB. That's considerably farther than a default build world have > run but less than > > > > observed when setting vm.pageout_oom_seq=120 alone. Log files are at > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/ > 1gbsdflash_1gbusbflash/batchqueue/ > > > > > > > > Both changes are now in place and -j4 buildworld has been restarted. > > > > > > Looking through the gstat output, I'm seeing some pretty abysmal > average > > > write latencies for da0, the flash drive. I also realized that my > > > reference to r329882 lowering the pagedaemon sleep period was wrong - > > > things have been this way for much longer than that. Moreover, as you > > > pointed out, bumping oom_seq to a much larger value wasn't quite > > > sufficient. > > > > > > I'm curious as to what the worst case swap I/O latencies are in your > > > test, since the average latencies reported in your logs are high enough > > > to trigger OOM kills even with the increased oom_seq value. When the > > > current test finishes, could you try repeating it with this patch > > > applied on top? https://people.freebsd.org/~ > markj/patches/slow_swap.diff > > > That is, keep the non-default oom_seq setting and modification to > > > VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the > kernel > > > to print messages to the console under certain conditions, so a log of > > > console output will be interesting. > > > > The run finished with a panic, I've collected the logs and terminal > output at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/ > 1gbsdflash_1gbusbflash/batchqueue/pageout120/slow_swap/ > > > > There seems to be a considerable discrepancy between the wait times > reported > > by the patch and the wait times reported by gstat in the first couple of > > occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT 2018 in > > swapscript.log. > > The reports of "waited for swap buffer" are especially bad: during those > periods, the laundry thread is blocked waiting for in-flight swap writes > to finish before sending any more. Because the system is generally > quite starved for clean pages that it can reuse, it's relying on swap > I/O to clean more. If that fails, the system eventually has no choice > but to start killing processes (where the time period corresponding to > "eventually" is determined by vm.pageout_oom_seq). > Based on these latencies, I think the system is behaving more or less as > expected from the VM's perspective. I do think the default oom_seq value > is too low and will get that addressed in 12.0. Yea. I think we need to take a more active role in managing latencies on some cards. Properly managed, they won't climb that high. Since there's no tagged queueing to these devices, there's an I/O depth of one. The default policy is to do them in order (since it's flash) which means that processes that machine-gun down requests swamp everybody else and do back-to-back-to-back writes which, at least for the few drives I have looked at in detail tends to induce pathological behavior. Warner From owner-freebsd-arm@freebsd.org Thu Aug 9 15:36:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9ABF106A55C for ; Thu, 9 Aug 2018 15:36:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2D87A53C; Thu, 9 Aug 2018 15:36:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w79FbAjl032957 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Aug 2018 08:37:11 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w79FbA9g032956; Thu, 9 Aug 2018 08:37:10 -0700 (PDT) (envelope-from fbsd) Date: Thu, 9 Aug 2018 08:37:10 -0700 From: bob prohaska To: Warner Losh Cc: Mark Johnston , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809153710.GC30347@www.zefox.net> References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:36:57 -0000 On Thu, Aug 09, 2018 at 09:28:09AM -0600, Warner Losh wrote: > On Thu, Aug 9, 2018 at 9:21 AM, Mark Johnston wrote: > > > On Wed, Aug 08, 2018 at 11:56:48PM -0700, bob prohaska wrote: > > > On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: > > > > On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: > > > > > The patched kernel ran longer than default but OOMA still halted > > buildworld around > > > > > 13 MB. That's considerably farther than a default build world have > > run but less than > > > > > observed when setting vm.pageout_oom_seq=120 alone. Log files are at > > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/ > > 1gbsdflash_1gbusbflash/batchqueue/ > > > > > > > > > > Both changes are now in place and -j4 buildworld has been restarted. > > > > > > > > Looking through the gstat output, I'm seeing some pretty abysmal > > average > > > > write latencies for da0, the flash drive. I also realized that my > > > > reference to r329882 lowering the pagedaemon sleep period was wrong - > > > > things have been this way for much longer than that. Moreover, as you > > > > pointed out, bumping oom_seq to a much larger value wasn't quite > > > > sufficient. > > > > > > > > I'm curious as to what the worst case swap I/O latencies are in your > > > > test, since the average latencies reported in your logs are high enough > > > > to trigger OOM kills even with the increased oom_seq value. When the > > > > current test finishes, could you try repeating it with this patch > > > > applied on top? https://people.freebsd.org/~ > > markj/patches/slow_swap.diff > > > > That is, keep the non-default oom_seq setting and modification to > > > > VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the > > kernel > > > > to print messages to the console under certain conditions, so a log of > > > > console output will be interesting. > > > > > > The run finished with a panic, I've collected the logs and terminal > > output at > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/ > > 1gbsdflash_1gbusbflash/batchqueue/pageout120/slow_swap/ > > > > > > There seems to be a considerable discrepancy between the wait times > > reported > > > by the patch and the wait times reported by gstat in the first couple of > > > occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT 2018 in > > > swapscript.log. > > > > The reports of "waited for swap buffer" are especially bad: during those > > periods, the laundry thread is blocked waiting for in-flight swap writes > > to finish before sending any more. Because the system is generally > > quite starved for clean pages that it can reuse, it's relying on swap > > I/O to clean more. If that fails, the system eventually has no choice > > but to start killing processes (where the time period corresponding to > > "eventually" is determined by vm.pageout_oom_seq). > > > > > Based on these latencies, I think the system is behaving more or less as > > expected from the VM's perspective. I do think the default oom_seq value > > is too low and will get that addressed in 12.0. > > > Yea. I think we need to take a more active role in managing latencies on > some cards. Properly managed, they won't climb that high. Since there's no > tagged queueing to these devices, there's an I/O depth of one. The default > policy is to do them in order (since it's flash) which means that processes > that machine-gun down requests swamp everybody else and do > back-to-back-to-back writes which, at least for the few drives I have > looked at in detail tends to induce pathological behavior. > There's a kernel building now with options CAM_IOSCHED_DYNAMIC in the config file. Is it still worth trying? Anything else to try? With my thanks, bob prohaska From owner-freebsd-arm@freebsd.org Thu Aug 9 15:43:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E176106A8C8 for ; Thu, 9 Aug 2018 15:43:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C30F17A9E9 for ; Thu, 9 Aug 2018 15:43:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id y10-v6so5108946ioa.10 for ; Thu, 09 Aug 2018 08:43:00 -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=3av7Q2H/2ko+y8n4YNo45iwlMtwA0xfkztAqsW8TMoc=; b=oeSeJffk/TcYkhBAt7ntvXGw8/xAT6CL0Th6cPO+c2TCTU2w2HgJExYP9tUEiYRD4W 6NeDN1zZC+7DMtWX9eJJBfGKNBlD49jvWmzVrRZjPUx+QExYZw3g7koSSLxRyswO0P9w QM8ApDrr4msxZ8KxF1tlWhASRclI1es5pOt8K1KlpMujU6zw9ruxa7VgY/kxH5KRsH5k xaC3Vdy6g24hrCaiN+mOVb2ij829OzIenFiGPSxt5zb8KPvdCrzJ+d9o4dh7gA0UIgY1 uoxdpokR7kbsfIlDAs0xHZEQvDBd5k3rWbmaGmSw2DHkLAXEicxtqfcHOHs16TsQ4lBZ zxVg== 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=3av7Q2H/2ko+y8n4YNo45iwlMtwA0xfkztAqsW8TMoc=; b=AaO0swXB56RUwG+3PAjy3mEdqEuF/i+lpuztRhLP5ZlFKnAkcE5UpR58cg9d37bWGq SONA9poUCHAFiLP5fF0DdWcbdO/Nr6dgztQiFSDTTljogL9VKZzSH8tHeaLw9F0rgLuC ZYG7ny0JmsNHjg1dVebHFAqRz4y4Dixa3i9Zca0ELle02huExioWTTmHkK8qbHpFC2XH q+lThnsAjWi8YjchO3uSMb0gNpFLGEoIVFQ0cGQyIbSJ/8QP0gbNZPI69js57Ve1Z715 6xTqliR43RCOz2cUxgoHN60po9EKM9p80CziZ9tVAN0Oj3G/u/gkhopIQ59tN7UCxB0T hAvw== X-Gm-Message-State: AOUpUlEqh73ylVusTNFpwX20R0zjJ/GFzwN5Ilgl9uUQQ8oG+EQWyidk yCCKTkpFl8SrsL94bBw7sdmI0woUen0/fJ6uU0ZcaA== X-Google-Smtp-Source: AA+uWPxRYMcD7xCQM37J4xy/y11s2eCOXFgbsZCVIz/ZhrgD9fJyfz0KqlFvqkKhPlKOdsPNeY3CEnMnBAQzjHedAY8= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr2207811ioa.168.1533829380027; Thu, 09 Aug 2018 08:43:00 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 08:42:59 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180809153710.GC30347@www.zefox.net> References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> From: Warner Losh Date: Thu, 9 Aug 2018 09:42:59 -0600 X-Google-Sender-Auth: 5e1z89KCu2qTrGtcbh8L3oE5yFI Message-ID: Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: bob prohaska Cc: Mark Johnston , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:43:01 -0000 On Thu, Aug 9, 2018 at 9:37 AM, bob prohaska wrote: > On Thu, Aug 09, 2018 at 09:28:09AM -0600, Warner Losh wrote: > > On Thu, Aug 9, 2018 at 9:21 AM, Mark Johnston wrote: > > > > > On Wed, Aug 08, 2018 at 11:56:48PM -0700, bob prohaska wrote: > > > > On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: > > > > > On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: > > > > > > The patched kernel ran longer than default but OOMA still halted > > > buildworld around > > > > > > 13 MB. That's considerably farther than a default build world > have > > > run but less than > > > > > > observed when setting vm.pageout_oom_seq=120 alone. Log files > are at > > > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/ > > > 1gbsdflash_1gbusbflash/batchqueue/ > > > > > > > > > > > > Both changes are now in place and -j4 buildworld has been > restarted. > > > > > > > > > > Looking through the gstat output, I'm seeing some pretty abysmal > > > average > > > > > write latencies for da0, the flash drive. I also realized that my > > > > > reference to r329882 lowering the pagedaemon sleep period was > wrong - > > > > > things have been this way for much longer than that. Moreover, as > you > > > > > pointed out, bumping oom_seq to a much larger value wasn't quite > > > > > sufficient. > > > > > > > > > > I'm curious as to what the worst case swap I/O latencies are in > your > > > > > test, since the average latencies reported in your logs are high > enough > > > > > to trigger OOM kills even with the increased oom_seq value. When > the > > > > > current test finishes, could you try repeating it with this patch > > > > > applied on top? https://people.freebsd.org/~ > > > markj/patches/slow_swap.diff > > > > > That is, keep the non-default oom_seq setting and modification to > > > > > VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the > > > kernel > > > > > to print messages to the console under certain conditions, so a > log of > > > > > console output will be interesting. > > > > > > > > The run finished with a panic, I've collected the logs and terminal > > > output at > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/ > > > 1gbsdflash_1gbusbflash/batchqueue/pageout120/slow_swap/ > > > > > > > > There seems to be a considerable discrepancy between the wait times > > > reported > > > > by the patch and the wait times reported by gstat in the first > couple of > > > > occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT > 2018 in > > > > swapscript.log. > > > > > > The reports of "waited for swap buffer" are especially bad: during > those > > > periods, the laundry thread is blocked waiting for in-flight swap > writes > > > to finish before sending any more. Because the system is generally > > > quite starved for clean pages that it can reuse, it's relying on swap > > > I/O to clean more. If that fails, the system eventually has no choice > > > but to start killing processes (where the time period corresponding to > > > "eventually" is determined by vm.pageout_oom_seq). > > > > > > > > > Based on these latencies, I think the system is behaving more or less as > > > expected from the VM's perspective. I do think the default oom_seq > value > > > is too low and will get that addressed in 12.0. > > > > > > Yea. I think we need to take a more active role in managing latencies on > > some cards. Properly managed, they won't climb that high. Since there's > no > > tagged queueing to these devices, there's an I/O depth of one. The > default > > policy is to do them in order (since it's flash) which means that > processes > > that machine-gun down requests swamp everybody else and do > > back-to-back-to-back writes which, at least for the few drives I have > > looked at in detail tends to induce pathological behavior. > > > > There's a kernel building now with > options CAM_IOSCHED_DYNAMIC > in the config file. Is it still worth trying? Anything else to try? > It won't be a cure-all, out of the box, I don't think. However, the read biasing code may help sneak a few 'reads' in between writes which may help keep away from the pathological behavior.... Or not, it's hard to say... I've not looked at swapping to super-crappy nand (I mean thumb drives) in as much detail as the drives we use for work. Warner From owner-freebsd-arm@freebsd.org Thu Aug 9 16:21:47 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11569106BB8F for ; Thu, 9 Aug 2018 16:21:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8EFE7C497 for ; Thu, 9 Aug 2018 16:21:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: vyMTP9IVM1ldpne6ypiiq036MQcoKK3YdDqlC4hH6ZJKk9OXbI979P5ZUjMdXbQ lNpAx6BHD6BKUDtOKTYdkqQpoRr0H0qonU2XwVU1FqaGz0CpHJbsrC.WmV0Vy3YNt5DtvIJMkYvt AztaVzwUEm2JoX1BA0ydxLWuAn6wnZkMuYgQksyi7qgvVEhsc_NzqH4bLS54wXx7vQ.ay_efIMVN nGH3e_oeI7ac.nO2zYouNxUv6gl7adA4DXM6hrOPmuIBD9aS7hQG5V4XXy06zdL4xU6VmFrYGnGb VpSl0w.cq_dEvZikPV3t7rGjahsoUaVagNqjqcH2e.O.yVsk9Yjssiihjidr.8A9Pp5sztOx30dG LeXb927nt4JWc7ldIfu_QZs76CZ_K1iBYXggv4NKAov6R4t1WOqwVKQMj9V1oJRgOuFAxJmj7dJ6 xPetbBIYKhyJpJvfEi_5F4YxUXSb8G5iZ3uWMCcwJMKavuISpe90mVae4LmsGzWr8UdyYtjooW1x V0qpSqAHmUxRNo_ZHqBGAkeYRx84VQNWXStXot5yZfZCYeVskvSY6VfrpKpmASP6k0FD27gnOgIK ijlDzUOc7HrUmnpfnibQSWCR7qC30D6Y.UH8XZVbZR7abLcLOSKZyKK47SuwIkmt0qb6zsvhUwMl Oda.3fPHlUO0bypx2DBzBMYkKppODHqLl_tC2L3.k2sZNMyFxT31S.W8WBDWkcaATOvRIxbVqUre ryrBKGKhMDdaR8JChni_xjis6VCaZMIdtf_Qyd2uiV9GeuGeXpwvlox18eidhfWEVHzjSdURTUT7 AGQ40N0hZdSEK27ps.YDcKnXrJhTAiEzihVw_SrF0u1yuY6ezWpkDbmI5jNqlZUVeVwhhTq7oID. lsRqG2HDsmTV1qxMBe2Do965QWnMt7iqHsDLREYucI26C1GKdhpMhycWsBZlCjPxnUxwF5cEZe6t ObxsJUM0yU7FH8OEgpQwFAxlNYwgRlihpqKIS25wZu188ZuN0CS35r3tnAs71FagxAOcpqw8oL9F 36Sxm0gYY_Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 9 Aug 2018 16:21:46 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c1dcf9cfb6dab5a36d7d0d77290481e6; Thu, 09 Aug 2018 16:21:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180809152152.GC68459@raichu> Date: Thu, 9 Aug 2018 09:21:38 -0700 Cc: bob prohaska , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <915DFC7F-7AC9-484F-8619-C386FF077769@yahoo.com> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> To: Mark Johnston X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 16:21:47 -0000 On 2018-Aug-9, at 8:21 AM, Mark Johnston wrote: > On Wed, Aug 08, 2018 at 11:56:48PM -0700, bob prohaska wrote: >> On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: >>> On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: >>>> The patched kernel ran longer than default but OOMA still halted = buildworld around >>>> 13 MB. That's considerably farther than a default build world have = run but less than >>>> observed when setting vm.pageout_oom_seq=3D120 alone. Log files are = at >>>> = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/ >>>>=20 >>>> Both changes are now in place and -j4 buildworld has been = restarted.=20 >>>=20 >>> Looking through the gstat output, I'm seeing some pretty abysmal = average >>> write latencies for da0, the flash drive. I also realized that my >>> reference to r329882 lowering the pagedaemon sleep period was wrong = - >>> things have been this way for much longer than that. Moreover, as = you >>> pointed out, bumping oom_seq to a much larger value wasn't quite >>> sufficient. >>>=20 >>> I'm curious as to what the worst case swap I/O latencies are in your >>> test, since the average latencies reported in your logs are high = enough >>> to trigger OOM kills even with the increased oom_seq value. When = the >>> current test finishes, could you try repeating it with this patch >>> applied on top? = https://people.freebsd.org/~markj/patches/slow_swap.diff >>> That is, keep the non-default oom_seq setting and modification to >>> VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the = kernel >>> to print messages to the console under certain conditions, so a log = of >>> console output will be interesting. >>=20 >> The run finished with a panic, I've collected the logs and terminal = output at >> = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/pageout120/slow_swap/ >>=20 >> There seems to be a considerable discrepancy between the wait times = reported >> by the patch and the wait times reported by gstat in the first couple = of=20 >> occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT 2018 = in >> swapscript.log.=20 >=20 > The reports of "waited for swap buffer" are especially bad: during = those > periods, the laundry thread is blocked waiting for in-flight swap = writes > to finish before sending any more. Because the system is generally > quite starved for clean pages that it can reuse, it's relying on swap > I/O to clean more. If that fails, the system eventually has no choice > but to start killing processes (where the time period corresponding to > "eventually" is determined by vm.pageout_oom_seq). >=20 > Based on these latencies, I think the system is behaving more or less = as > expected from the VM's perspective. I do think the default oom_seq = value > is too low and will get that addressed in 12.0. Would something like the patch that produced the messages like: waited 3s for async swap write waited 3s for swap buffer be appropriate as able to be enabled via a sysctl or in some other way? In other words: in the source code by standard, off by default, but able to be enabled without patching, possibly without rebuilding? I ask because I've been thinking of having such on the FreeBSD's where I buildworld buildkernel and use poudriere-devel for port builds. It might warning me of marginal contexts and help explain any OOM kills that might occur. (Somethings things are difficult or time consuming to reproduce.) If monitored at the time, it might even help identify contexts that "machine-gun down requests" in environments were such can be a problem for swapping. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 9 16:44:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6540A106C4F1 for ; Thu, 9 Aug 2018 16:44:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8A457D41E for ; Thu, 9 Aug 2018 16:44:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: S.f_sOsVM1nDjIQelQdxyer6R8Yt6PCuPhiL1IxO.k1Wm8l8lmst0kkOVObsvP5 DMaS7rPaHoDF9UO0Dw9UV0eoxARhfxbowtpWkMJQvFmPAD6zvi9uLmoJlItFCo15byWpq6fF1VQ4 AyT4P1QO8BuZ3EfFqmRS2cASl5OgU740luw8V.Iv1_snEo__iWAWzkH5gqxvmMMOqQH2fNDH5naB E8rrm_eklC_XwH0PgguvIKSahSM_ARdYTHjZpaR_kxZGajQFYEmgX_QcjjQcTMz91S3Jng6.9xVI zNijdbVAsu5FOV9qzTmI8JtC5y.4lmTKMTY1u_5tH9sdcxfXg2eAuHRIGcVaMn5rWuEA11NyS9K5 VBlH6m59CCTzNw39709haH60UpYOq5S1kKiyj1eMZQlTzNAQQ.deZcdp6tvdMY6aSRa3anTHH.Lk 00jdKjUDSqmYI92mROL2AFtcjLCeQFwwcG4THC.OnYCVSTqSxkhe9SdJ53bTb8kHu9_EE7NSPZ9W i0VYclgj.N_DBlu.4IIWwOGPXihHZ7f9wbwNhcav.5sfXZkUAfL5KGddQ1BkvGy3Te9s8OZ.5D0O t5HrQ8ew6D7hSfcmZz5G4RoHKLJ8CqJO9BPYSkPSOJtwm.yetFkTc.4JnBCwG2wjbn9BGqNhcIZ4 LR74syGuiAqxkzllIU1_JvPYIBn.7VEirqBOkXc.PcR0nalegQYy.nWsCfCX4Ta7wWHuIzmzcUoG kVoRBrqq4pQGcJ5ud3qTCZDND6kvn13GI4lSXGlCoZaBuxrhU3tkLpaPBI3TSToauQpnLX29iKwS VqK9GqH5S5CNkcGXJBQPwwpQdI.l13We8I0FGusrGDd9mWIp2WpLY3_xvFL5Ef5Oa68cXvNXhp0a 0nKHz4Js8y0DxEpt3VSN__z2cB1Vxc096eB0U6faTFqLenZoGwZzQFANHNqGKv9bZ72VpgDBMNnC xKxl_X_wWVP2CrQ98MeCJ3GMg_P_ivOyb9z3kM.jFC4vD4cizx_SY34BT9_iDzLJM4eT9HKLRi0h oynHIRkYB8Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Aug 2018 16:44:26 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bbe838e6721fbcedd6b30d7ed0ff9332; Thu, 09 Aug 2018 16:44:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180809152152.GC68459@raichu> Date: Thu, 9 Aug 2018 09:44:21 -0700 Cc: Mark Millard via freebsd-arm , Mark Johnston Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 16:44:33 -0000 On 2018-Aug-9, at 8:21 AM, Mark Johnston wrote: > On Wed, Aug 08, 2018 at 11:56:48PM -0700, bob prohaska wrote: >> On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: >>> On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: >>>> The patched kernel ran longer than default but OOMA still halted = buildworld around >>>> 13 MB. That's considerably farther than a default build world have = run but less than >>>> observed when setting vm.pageout_oom_seq=3D120 alone. Log files are = at >>>> = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/ >>>>=20 >>>> Both changes are now in place and -j4 buildworld has been = restarted.=20 >>>=20 >>> Looking through the gstat output, I'm seeing some pretty abysmal = average >>> write latencies for da0, the flash drive. I also realized that my >>> reference to r329882 lowering the pagedaemon sleep period was wrong = - >>> things have been this way for much longer than that. Moreover, as = you >>> pointed out, bumping oom_seq to a much larger value wasn't quite >>> sufficient. >>>=20 >>> I'm curious as to what the worst case swap I/O latencies are in your >>> test, since the average latencies reported in your logs are high = enough >>> to trigger OOM kills even with the increased oom_seq value. When = the >>> current test finishes, could you try repeating it with this patch >>> applied on top? = https://people.freebsd.org/~markj/patches/slow_swap.diff >>> That is, keep the non-default oom_seq setting and modification to >>> VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the = kernel >>> to print messages to the console under certain conditions, so a log = of >>> console output will be interesting. >>=20 >> The run finished with a panic, I've collected the logs and terminal = output at >> = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/pageout120/slow_swap/ >>=20 >> There seems to be a considerable discrepancy between the wait times = reported >> by the patch and the wait times reported by gstat in the first couple = of=20 >> occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT 2018 = in >> swapscript.log.=20 >=20 > The reports of "waited for swap buffer" are especially bad: during = those > periods, the laundry thread is blocked waiting for in-flight swap = writes > to finish before sending any more. Because the system is generally > quite starved for clean pages that it can reuse, it's relying on swap > I/O to clean more. If that fails, the system eventually has no choice > but to start killing processes (where the time period corresponding to > "eventually" is determined by vm.pageout_oom_seq). Just for reference from=20 = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/pageout120/slow_swap/swapscript.log is some context for two of the swap buffer messages that gives some information on the timing of the messages and some other activity: Wed Aug 8 22:01:14 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 23912 1024664 2% /dev/mmcsd0s3b 1048576 23892 1024684 2% Total 2097152 47804 2049348 2% Aug 8 21:36:13 www syslogd: last message repeated 1 times Aug 8 21:36:13 www kernel: waited 3s for async swap write dT: 10.004s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 2 20 1 4 25.5 19 1216 41.4 0 0 = 0.0 29.3 mmcsd0 3 29 1 11 10.8 28 1244 23.9 0 0 = 0.0 18.7 da0 0 0 0 0 0.0 0 3 42.9 0 0 = 0.0 0.4 mmcsd0s2 2 20 1 4 25.6 19 1213 41.5 0 0 = 0.0 29.4 mmcsd0s3 0 0 0 0 0.0 0 3 43.0 0 0 = 0.0 0.4 ufs/rootfs 2 20 1 4 25.6 19 1213 41.6 0 0 = 0.0 29.4 mmcsd0s3b 2 20 1 11 10.9 19 1238 20.6 0 0 = 0.0 18.6 da0b Wed Aug 8 22:01:24 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 37284 1011292 4% /dev/mmcsd0s3b 1048576 36920 1011656 4% Total 2097152 74204 2022948 4% Aug 8 21:36:13 www syslogd: last message repeated 1 times Aug 8 21:36:13 www kernel: waited 3s for async swap write dT: 10.002s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 8 0 0 4.7 8 693 41.7 0 0 = 0.0 12.2 mmcsd0 13 13 0 0 0.0 13 682 132.7 0 0 = 0.0 78.3 da0 0 8 0 0 4.7 8 693 41.8 0 0 = 0.0 12.2 mmcsd0s3 0 8 0 0 4.8 8 693 41.9 0 0 = 0.0 12.3 mmcsd0s3b 5 7 0 0 0.0 7 676 79.5 0 0 = 0.0 40.1 da0b Wed Aug 8 22:01:34 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 44680 1003896 4% /dev/mmcsd0s3b 1048576 44132 1004444 4% Total 2097152 88812 2008340 4% Aug 8 21:36:13 www kernel: waited 3s for async swap write Aug 8 22:01:30 www syslogd: last message repeated 1 times Aug 8 22:01:41 www kernel: waited 10s for async swap write Aug 8 22:01:41 www kernel: waited 6s for swap buffer Aug 8 22:01:41 www kernel: waited 13s for async swap write Aug 8 22:01:41 www kernel: waited 3s for swap buffer Aug 8 22:01:41 www kernel: waited 12s for async swap write Aug 8 22:01:41 www kernel: waited 10s for async swap write Aug 8 22:01:41 www kernel: waited 3s for async swap write dT: 10.001s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 2 1 26 3.4 1 17 3.8 0 0 = 0.0 0.9 mmcsd0 0 4 3 61 3.8 2 70 5.7 0 0 = 0.0 1.7 da0 0 2 1 26 3.5 1 17 3.9 0 0 = 0.0 0.9 mmcsd0s3 0 1 0 0 0.0 1 17 4.0 0 0 = 0.0 0.4 mmcsd0s3a 0 1 1 26 3.5 0 0 0.0 0 0 = 0.0 0.5 mmcsd0s3b 0 2 2 54 3.8 0 0 0.0 0 0 = 0.0 0.9 da0b 0 2 0 7 4.3 1 70 5.8 0 0 = 0.0 0.8 da0d Wed Aug 8 22:01:51 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 46156 1002420 4% /dev/mmcsd0s3b 1048576 45480 1003096 4% Total 2097152 91636 2005516 4% Aug 8 22:01:41 www kernel: waited 10s for async swap write Aug 8 22:01:41 www kernel: waited 3s for async swap write dT: 10.002s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 8 7 251 3.4 0 8 2.6 0 0 = 0.0 2.5 mmcsd0 0 9 7 186 4.2 2 77 7.4 0 0 = 0.0 3.6 da0 0 8 7 251 3.5 0 8 2.6 0 0 = 0.0 2.6 mmcsd0s3 0 0 0 0 0.0 0 8 2.7 0 0 = 0.0 0.1 mmcsd0s3a 0 7 7 251 3.5 0 0 0.0 0 0 = 0.0 2.5 mmcsd0s3b 0 7 7 184 4.2 0 0 0.0 0 0 = 0.0 2.7 da0b 0 2 0 2 4.6 2 76 7.5 0 0 = 0.0 0.9 da0d > Based on these latencies, I think the system is behaving more or less = as > expected from the VM's perspective. I do think the default oom_seq = value > is too low and will get that addressed in 12.0. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 9 16:52:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5043A106C8F5 for ; Thu, 9 Aug 2018 16:52:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-22.consmr.mail.gq1.yahoo.com (sonic312-22.consmr.mail.gq1.yahoo.com [98.137.69.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC9307DA7D for ; Thu, 9 Aug 2018 16:52:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: rNqCreIVM1nBrFtrkI9LxSvMl_dQB49TQ2eIGeNrU.wJZHdc7swkA0TnYCRmm6H RWdR_HJmrUino.nuqg4qp_l1T2XCb_rl0BaLiddA4Y0iwBjuof63S4OL6wX1Bq4zmpT76WbpxbEh aFfgNkQqeHA3TNaG0L80OfrmpWX22vKkSdXyGOZP270mtoYd1RmxTsXcP0E4CbT7tVj3ytS3nT77 qjYvsXcWrqnYMDpMIzbRIRH2zC5B_mi3raloixh6egjaKC6SHC062XRFhOLU.qKKZcQSTCAKsqCP cv9OaEzVWUTKixa_cPKLCZuKuvYunLf_suEMpxZQ_0GusSTKzlQi.in8WHbwWKHvMftfADAiOSWk ZK8_6ld3AIk0_qj0hrylKHHAEW6B_cn.NLBT.YhvojjO07UcjtvGiZdKI1ENblDT25CWIrN0e3Ye HnIDAWZksVYFBpY_m4mzBdpq4s5Ehp5G4xaW1wpB_GivKjyITBYNDyplocJNXYewUlZCFgZPs6lH dTQYnO8XhA0sSo6yaXU.xHXEAITt1MA1wmaDt1XST19fCFsTmo9t2u23NXkTwvlBHLnbVk7LDTdc rIzSN0JxeGmszwCkxgMweSD2hsqcCWmRRV86zDpP3Fa7gvOZkQxS06m_4hKtYKApF.UHptDDA89s .oZnwf2FZqCsuLskcGQ5wKjyGSUlgc_AXLDyJy92KqA5IqgxX2ZdWTnvjTPp7anCvtomFB2UUERy UbsEzXko7vfK7quUdpt4NzdHhMubGvdj.0KRljPM6VRzb9c0hSf7iGGl7JanYcEkgS.MAly3_5XA FzI14azv05Yx_kPzHM4AfIL2e5tZ_rRVFSdtgpBlmmHVzliUqp3bpvwyUYk7iL4AaQvuUuY1OpQY wY.JkvA.k5CRR3w8eWK3R1d5eiB3bL7KTR9B3Bfll_zlUbPPtoNiTxhlmLfhzNxPNC6laoHW2ohp ._2da803YQ2EiKT7H8is870z6yQsX_XCj9RHEZem0MCWueM6VGYbHQWEaM9N2JSSqfi0B6T0t.zY FgVw7lYXn Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Aug 2018 16:52:17 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp408.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 286232a954d50ce1c9415547ac18ad0a; Thu, 09 Aug 2018 16:52:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: Date: Thu, 9 Aug 2018 09:52:11 -0700 Cc: Mark Millard via freebsd-arm , Mark Johnston Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 16:52:25 -0000 [I'm adding what lead up to the first waiting for async swap write notice.] On 2018-Aug-9, at 9:44 AM, Mark Millard wrote: > On 2018-Aug-9, at 8:21 AM, Mark Johnston wrote: >=20 >> On Wed, Aug 08, 2018 at 11:56:48PM -0700, bob prohaska wrote: >>> On Wed, Aug 08, 2018 at 04:48:41PM -0400, Mark Johnston wrote: >>>> On Wed, Aug 08, 2018 at 08:38:00AM -0700, bob prohaska wrote: >>>>> The patched kernel ran longer than default but OOMA still halted = buildworld around >>>>> 13 MB. That's considerably farther than a default build world have = run but less than >>>>> observed when setting vm.pageout_oom_seq=3D120 alone. Log files = are at >>>>> = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/ >>>>>=20 >>>>> Both changes are now in place and -j4 buildworld has been = restarted.=20 >>>>=20 >>>> Looking through the gstat output, I'm seeing some pretty abysmal = average >>>> write latencies for da0, the flash drive. I also realized that my >>>> reference to r329882 lowering the pagedaemon sleep period was wrong = - >>>> things have been this way for much longer than that. Moreover, as = you >>>> pointed out, bumping oom_seq to a much larger value wasn't quite >>>> sufficient. >>>>=20 >>>> I'm curious as to what the worst case swap I/O latencies are in = your >>>> test, since the average latencies reported in your logs are high = enough >>>> to trigger OOM kills even with the increased oom_seq value. When = the >>>> current test finishes, could you try repeating it with this patch >>>> applied on top? = https://people.freebsd.org/~markj/patches/slow_swap.diff >>>> That is, keep the non-default oom_seq setting and modification to >>>> VM_BATCHQUEUE_SIZE, and apply this patch on top. It'll cause the = kernel >>>> to print messages to the console under certain conditions, so a log = of >>>> console output will be interesting. >>>=20 >>> The run finished with a panic, I've collected the logs and terminal = output at >>> = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/pageout120/slow_swap/ >>>=20 >>> There seems to be a considerable discrepancy between the wait times = reported >>> by the patch and the wait times reported by gstat in the first = couple of=20 >>> occurrences. The fun begins at timestamp Wed Aug 8 21:26:03 PDT = 2018 in >>> swapscript.log.=20 >>=20 >> The reports of "waited for swap buffer" are especially bad: during = those >> periods, the laundry thread is blocked waiting for in-flight swap = writes >> to finish before sending any more. Because the system is generally >> quite starved for clean pages that it can reuse, it's relying on swap >> I/O to clean more. If that fails, the system eventually has no = choice >> but to start killing processes (where the time period corresponding = to >> "eventually" is determined by vm.pageout_oom_seq). >=20 > Just for reference from=20 >=20 > = http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/= batchqueue/pageout120/slow_swap/swapscript.log >=20 > is some context for two of the swap buffer messages that gives some > information on the timing of the messages and some other activity: >=20 > Wed Aug 8 22:01:14 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 23912 1024664 2% > /dev/mmcsd0s3b 1048576 23892 1024684 2% > Total 2097152 47804 2049348 2% > Aug 8 21:36:13 www syslogd: last message repeated 1 times > Aug 8 21:36:13 www kernel: waited 3s for async swap write > dT: 10.004s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 2 20 1 4 25.5 19 1216 41.4 0 0 = 0.0 29.3 mmcsd0 > 3 29 1 11 10.8 28 1244 23.9 0 0 = 0.0 18.7 da0 > 0 0 0 0 0.0 0 3 42.9 0 0 = 0.0 0.4 mmcsd0s2 > 2 20 1 4 25.6 19 1213 41.5 0 0 = 0.0 29.4 mmcsd0s3 > 0 0 0 0 0.0 0 3 43.0 0 0 = 0.0 0.4 ufs/rootfs > 2 20 1 4 25.6 19 1213 41.6 0 0 = 0.0 29.4 mmcsd0s3b > 2 20 1 11 10.9 19 1238 20.6 0 0 = 0.0 18.6 da0b > Wed Aug 8 22:01:24 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 37284 1011292 4% > /dev/mmcsd0s3b 1048576 36920 1011656 4% > Total 2097152 74204 2022948 4% > Aug 8 21:36:13 www syslogd: last message repeated 1 times > Aug 8 21:36:13 www kernel: waited 3s for async swap write > dT: 10.002s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 8 0 0 4.7 8 693 41.7 0 0 = 0.0 12.2 mmcsd0 > 13 13 0 0 0.0 13 682 132.7 0 0 = 0.0 78.3 da0 > 0 8 0 0 4.7 8 693 41.8 0 0 = 0.0 12.2 mmcsd0s3 > 0 8 0 0 4.8 8 693 41.9 0 0 = 0.0 12.3 mmcsd0s3b > 5 7 0 0 0.0 7 676 79.5 0 0 = 0.0 40.1 da0b > Wed Aug 8 22:01:34 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 44680 1003896 4% > /dev/mmcsd0s3b 1048576 44132 1004444 4% > Total 2097152 88812 2008340 4% > Aug 8 21:36:13 www kernel: waited 3s for async swap write > Aug 8 22:01:30 www syslogd: last message repeated 1 times > Aug 8 22:01:41 www kernel: waited 10s for async swap write > Aug 8 22:01:41 www kernel: waited 6s for swap buffer > Aug 8 22:01:41 www kernel: waited 13s for async swap write > Aug 8 22:01:41 www kernel: waited 3s for swap buffer > Aug 8 22:01:41 www kernel: waited 12s for async swap write > Aug 8 22:01:41 www kernel: waited 10s for async swap write > Aug 8 22:01:41 www kernel: waited 3s for async swap write > dT: 10.001s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 2 1 26 3.4 1 17 3.8 0 0 = 0.0 0.9 mmcsd0 > 0 4 3 61 3.8 2 70 5.7 0 0 = 0.0 1.7 da0 > 0 2 1 26 3.5 1 17 3.9 0 0 = 0.0 0.9 mmcsd0s3 > 0 1 0 0 0.0 1 17 4.0 0 0 = 0.0 0.4 mmcsd0s3a > 0 1 1 26 3.5 0 0 0.0 0 0 = 0.0 0.5 mmcsd0s3b > 0 2 2 54 3.8 0 0 0.0 0 0 = 0.0 0.9 da0b > 0 2 0 7 4.3 1 70 5.8 0 0 = 0.0 0.8 da0d > Wed Aug 8 22:01:51 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 46156 1002420 4% > /dev/mmcsd0s3b 1048576 45480 1003096 4% > Total 2097152 91636 2005516 4% > Aug 8 22:01:41 www kernel: waited 10s for async swap write > Aug 8 22:01:41 www kernel: waited 3s for async swap write > dT: 10.002s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 8 7 251 3.4 0 8 2.6 0 0 = 0.0 2.5 mmcsd0 > 0 9 7 186 4.2 2 77 7.4 0 0 = 0.0 3.6 da0 > 0 8 7 251 3.5 0 8 2.6 0 0 = 0.0 2.6 mmcsd0s3 > 0 0 0 0 0.0 0 8 2.7 0 0 = 0.0 0.1 mmcsd0s3a > 0 7 7 251 3.5 0 0 0.0 0 0 = 0.0 2.5 mmcsd0s3b > 0 7 7 184 4.2 0 0 0.0 0 0 = 0.0 2.7 da0b > 0 2 0 2 4.6 2 76 7.5 0 0 = 0.0 0.9 da0d Here is what leads to the first waiting for async swap write notice: dT: 10.002s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 6 6.8 0 0 = 0.0 0.1 mmcsd0 0 1 0 1 2.2 1 9 4.6 0 0 = 0.0 0.2 da0 0 0 0 0 0.0 0 6 6.9 0 0 = 0.0 0.1 mmcsd0s3 0 0 0 0 0.0 0 6 6.9 0 0 = 0.0 0.1 mmcsd0s3a 0 1 0 1 2.3 1 9 5.2 0 0 = 0.0 0.2 da0d Wed Aug 8 21:25:32 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 6288 1042288 1% /dev/mmcsd0s3b 1048576 6152 1042424 1% Total 2097152 12440 2084712 1% Aug 8 17:16:04 www syslogd: last message repeated 1 times Aug 8 17:18:59 www su[724]: bob to root on /dev/pts/0 dT: 10.004s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 4 0 0 0.0 4 74 5.2 0 0 = 0.0 1.1 mmcsd0 0 5 1 22 4.2 5 78 6.1 0 0 = 0.0 1.6 da0 0 4 0 0 0.0 4 74 5.3 0 0 = 0.0 1.2 mmcsd0s3 0 0 0 0 0.0 0 1 4.8 0 0 = 0.0 0.1 mmcsd0s3a 0 4 0 0 0.0 4 72 5.4 0 0 = 0.0 1.1 mmcsd0s3b 0 4 0 0 0.0 4 71 6.2 0 0 = 0.0 1.2 da0b 0 1 1 22 4.3 0 6 4.9 0 0 = 0.0 0.4 da0d Wed Aug 8 21:25:42 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 6996 1041580 1% /dev/mmcsd0s3b 1048576 6876 1041700 1% Total 2097152 13872 2083280 1% Aug 8 17:16:04 www syslogd: last message repeated 1 times Aug 8 17:18:59 www su[724]: bob to root on /dev/pts/0 dT: 10.011s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 50 0 0 0.0 50 740 4.1 0 0 = 0.0 13.0 mmcsd0 0 53 0 0 0.0 53 762 7.4 0 0 = 0.0 15.1 da0 0 50 0 0 0.0 50 740 4.2 0 0 = 0.0 13.2 mmcsd0s3 0 50 0 0 0.0 50 740 4.2 0 0 = 0.0 13.3 mmcsd0s3b 0 50 0 0 0.0 50 762 7.3 0 0 = 0.0 15.1 da0b Wed Aug 8 21:25:52 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 15512 1033064 1% /dev/mmcsd0s3b 1048576 14800 1033776 1% Total 2097152 30312 2066840 1% Aug 8 17:16:04 www syslogd: last message repeated 1 times Aug 8 17:18:59 www su[724]: bob to root on /dev/pts/0 dT: 10.004s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 35 0 0 0.0 35 1509 11.2 0 0 = 0.0 20.3 mmcsd0 0 43 0 3 44.8 43 1346 50.1 0 0 = 0.0 55.9 da0 0 35 0 0 0.0 35 1506 11.4 0 0 = 0.0 20.4 mmcsd0s3 0 35 0 0 0.0 35 1503 11.4 0 0 = 0.0 20.4 mmcsd0s3b 0 0 0 3 44.8 0 6 3.3 0 0 = 0.0 0.5 da0a 0 35 0 0 0.0 35 1336 54.3 0 0 = 0.0 56.5 da0b 0 0 0 0 0.0 0 3 1433 0 0 = 0.0 14.3 da0d Wed Aug 8 21:26:03 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 29448 1019128 3% /dev/mmcsd0s3b 1048576 30540 1018036 3% Total 2097152 59988 2037164 3% Aug 8 17:18:59 www su[724]: bob to root on /dev/pts/0 Aug 8 21:25:57 www kernel: waited 3s for async swap write dT: 10.002s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 1 0 1 3.8 1 77 17.5 0 0 = 0.0 1.1 mmcsd0 0 2 0 7 3.5 2 84 14.9 0 0 = 0.0 1.2 da0 0 0 0 1 3.9 0 3 7.4 0 0 = 0.0 0.1 mmcsd0s2 0 1 0 0 0.0 1 74 18.4 0 0 = 0.0 1.0 mmcsd0s3 0 0 0 1 4.0 0 3 7.5 0 0 = 0.0 0.1 ufs/rootfs 0 1 0 0 0.0 1 9 13.5 0 0 = 0.0 0.8 mmcsd0s3a 0 1 0 0 0.0 1 65 23.3 0 0 = 0.0 0.8 mmcsd0s3b 0 1 0 1 2.4 1 77 21.6 0 0 = 0.0 0.8 da0b 0 1 0 6 3.8 0 8 5.2 0 0 = 0.0 0.4 da0d > Based on these latencies, I think the system is behaving more or less = as > expected from the VM's perspective. I do think the default oom_seq = value > is too low and will get that addressed in 12.0. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 9 17:09:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E738B106D281 for ; Thu, 9 Aug 2018 17:09:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 630077E5E2 for ; Thu, 9 Aug 2018 17:09:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x52a.google.com with SMTP id k3-v6so3040574pgq.5 for ; Thu, 09 Aug 2018 10:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=98sIRIcRF+FptGPTcu1sh+Aqa0SDA/pULi+Is+90lrA=; b=aYQDsuGX1GrnQAvCU4JwHGJK4sreNSnR98RHJqwiUI7CtrUEwJb7yWHpPxZkKPhEBp 3Nn6nvJ8PT15tMNWGPf3Fd5K4T5VhHGLEYy9GZo9cnofjVPXPwEaa6fJw13kxHaGt3UM MtRItCssXYJ3cJSUfU+sIodX0tYnJdlyElVGbnLs1u/HC5hAxTLEyKUEso/o5JKMAC8D AoW4Ex+UQd1FLSTSu942cYHh0ZeCIkfkavUVRuRcQANf03NWuD+Mxgn4gcPSXTfqaJVx tH/JPxcuEY/YdEkpl/hFXEPNjUwhj95jWMGfsbxvjkPLzfFimw29yjH+0odpzolykNlP fICA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=98sIRIcRF+FptGPTcu1sh+Aqa0SDA/pULi+Is+90lrA=; b=tQCQgL3fUabHssoeZ6/DnvMbcvBflH5fdi3NlGU6iAJwwDgVm1ISZmj69yJDF+th2B GM7PoPeG2nZU/eql/8wrK5aMRRpyXV90H+/BQC5PUSZXZUlMBvaYK6bgExqXKn4hYNwH J66J5/WNJ2M1RNPE+eAJdCCHmgDRr6OhsluRGWT+iMs5tU84jSWGWzyIdeKVqCvjGhm/ d9ZHDKFtQafUdfHELlaYK4yWb00Qatt43en16rlRmBB6djkmu/HlCjQ75jT2qMO0WfxO IkCW/+FJoqWEJs0PLHZY0i0GjTx5FhCOewGjsUkmXiR/YU9jwckv7hKMTWOpXV+JtJNA LUgQ== X-Gm-Message-State: AOUpUlG4qybr8AdmlZjVEoiSMxT+9iOXlTNvN2N/vX7kCLjxCfvtMYHk sUw0PwzFZvA/if+rAP+5Tqxe2T0j X-Google-Smtp-Source: AA+uWPz4uM1ODJVBNbwyUqk0uJdw5+1k9ti5p7f/8QssQSXtEZWbnJBEPOBcpS4CIFPjlzfeUVVHJw== X-Received: by 2002:a62:d544:: with SMTP id d65-v6mr3194693pfg.107.1533834544400; Thu, 09 Aug 2018 10:09:04 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id w5-v6sm9429997pfn.44.2018.08.09.10.09.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 10:09:03 -0700 (PDT) Sender: Mark Johnston Date: Thu, 9 Aug 2018 13:09:00 -0400 From: Mark Johnston To: Mark Millard Cc: bob prohaska , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809170900.GD68459@raichu> References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <915DFC7F-7AC9-484F-8619-C386FF077769@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <915DFC7F-7AC9-484F-8619-C386FF077769@yahoo.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 17:09:06 -0000 On Thu, Aug 09, 2018 at 09:21:38AM -0700, Mark Millard wrote: > Would something like the patch that produced the messages > like: > > waited 3s for async swap write > waited 3s for swap buffer > > be appropriate as able to be enabled via a sysctl or in > some other way? In other words: in the source code by standard, > off by default, but able to be enabled without patching, > possibly without rebuilding? Yes, I think so. We don't have a lot of visibility into the behaviour of the pageout threads, and I have some ideas on how to improve that. Swap I/O latency measurements are something I've wanted in the past. > I ask because I've been thinking of having such on the > FreeBSD's where I buildworld buildkernel and use poudriere-devel > for port builds. It might warning me of marginal contexts and > help explain any OOM kills that might occur. (Somethings > things are difficult or time consuming to reproduce.) > > If monitored at the time, it might even help identify contexts > that "machine-gun down requests" in environments were such can > be a problem for swapping. From owner-freebsd-arm@freebsd.org Thu Aug 9 17:22:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BDD1106D883 for ; Thu, 9 Aug 2018 17:22:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 191367F4AC for ; Thu, 9 Aug 2018 17:22:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id e14-v6so1297281itf.1 for ; Thu, 09 Aug 2018 10:22:44 -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=rJA7HNRorszMNmaFqOgxXjsZtGTFxAjoNUNBL5cJ1TQ=; b=ZatWM/R8NWzepXke2Wz6tWfjPKPEqDvnfWA7YHSUg6UaDaQky1znUx99cS0RDM9lbR bbxizIb8l5u2W9wR1DQpe7AU+by9ucYNYho91CX8A9byh4ww0jTmscyXwD8l8FjHoQgh 9vdmdQpi/Q9bFxc+rQLhgw+hlJohG9lguQUChucavEUq3Cc9EmsTBGqm/QoXHNLrX9R4 qAE0iHQVwRWr/UVFs5swKRcakZudRb7YXjP8LkD2Q+NrJMgEWnVM0gcUFvfM88f1HEps hR5WXooXE4MAUeiJSQ8bcvpFoLSMDzumCsqWeqidU/IzHICcz9hP1yp86nz+oS+DfK7x s9Bw== 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=rJA7HNRorszMNmaFqOgxXjsZtGTFxAjoNUNBL5cJ1TQ=; b=oysYAJW6led/xmcm4xIp79jgKn3uiKRfc6duMyNpmHh64KgNepihpmRn8n4bBNln43 2olvBwKvOXJGmimGV9Pt4wnVXvBXAs3JeUPULDIOQPAN/RSA2BYnt/ibHevBUwb/RExK ZWozHG9Z/OjXQY5HxgmFMTfflt8xs5hEZMlHH4CV1nM/3bNv/v2m+7/CpGZ6+UKWdA+f 9Y5FCxmaB0yCUEBKFbMGpgBnkkvAvr/65z5PU1FcDhOOyzSwQTnS8iEfnW2HklLGt5Nz FicJ/ybeEpN0G+oZLfWiiVjB6fNBJjT7WBMzGGNvw5z54u4TFmDvQ3j2HrQ4653mfcGe M0DA== X-Gm-Message-State: AOUpUlEeVklHwZTmz2vb69jlXof8F0yxAvwmWZzI0MQYXs8XQxufsze9 zObFwID+hWjAn59yKXeUNokq6YSTeTjQI9uy0Rx5kA== X-Google-Smtp-Source: AA+uWPwSZw6mxxlNL1I/UchsHlBxPLz8N4wcp43B0b2vo+CrHx49m6iGXIUDJYel621onFwuoRBuH4wpVNt3TPehdFk= X-Received: by 2002:a24:b211:: with SMTP id u17-v6mr2655774ite.1.1533835364209; Thu, 09 Aug 2018 10:22:44 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 10:22:43 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180809170900.GD68459@raichu> References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <915DFC7F-7AC9-484F-8619-C386FF077769@yahoo.com> <20180809170900.GD68459@raichu> From: Warner Losh Date: Thu, 9 Aug 2018 11:22:43 -0600 X-Google-Sender-Auth: 8-qMKwk8H0_VRW0ftSU76k2sqIg Message-ID: Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: Mark Johnston Cc: Mark Millard , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 17:22:45 -0000 On Thu, Aug 9, 2018 at 11:09 AM, Mark Johnston wrote: > On Thu, Aug 09, 2018 at 09:21:38AM -0700, Mark Millard wrote: > > Would something like the patch that produced the messages > > like: > > > > waited 3s for async swap write > > waited 3s for swap buffer > > > > be appropriate as able to be enabled via a sysctl or in > > some other way? In other words: in the source code by standard, > > off by default, but able to be enabled without patching, > > possibly without rebuilding? > > Yes, I think so. We don't have a lot of visibility into the behaviour > of the pageout threads, and I have some ideas on how to improve that. > Swap I/O latency measurements are something I've wanted in the past. > There's two ways to measure this: total latency (which is most likely the best) and latency in the hardware (which is a better diagnostic for hardware failure / behavior changes). There's some code to do power-of-two bucket latency measurements in the CAM I/O scheduler that could be abstracted out. It's rock simple. There's some code coming into the tree that may give more nuanced results, but it's not clear when that will land. Warner From owner-freebsd-arm@freebsd.org Thu Aug 9 17:57:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35B1A106E7A2 for ; Thu, 9 Aug 2018 17:57:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8827E80C3A; Thu, 9 Aug 2018 17:57:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w79Hw2f5033401 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Aug 2018 10:58:03 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w79Hw2Lh033400; Thu, 9 Aug 2018 10:58:02 -0700 (PDT) (envelope-from fbsd) Date: Thu, 9 Aug 2018 10:58:02 -0700 From: bob prohaska To: John Kennedy Cc: Mark Millard , Jamie Landeg-Jones , Mark Johnston , Mark Millard via freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180809175802.GA32974@www.zefox.net> References: <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180809033735.GJ30738@phouka1.phouka.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 17:57:50 -0000 On Wed, Aug 08, 2018 at 08:37:35PM -0700, John Kennedy wrote: > On Wed, Aug 08, 2018 at 02:02:36PM -0700, Mark Millard via freebsd-arm wrote: > > ... My understanding is that some other folks involved in the message > > exchange replicated the OOM kills without having evidence of issues > > like Bob P. has with large latencies for his hardware. The latencies > > may be sufficient but not necessary. > > > > Getting some of the other folks to run your tests would likely be > > good. ... > > Sounds like anyone else running tests should also have all 3 > > changes in place. > > > > I've CC'd some folks from the exchange that I think were running > > some tests. > > My system is almost done crunching. Applying patches and tweaks is fine, but > I think Bob P has some other reporting tweaks going that we'd want to replicate > so we have more than a fail/no fail. > I've gathered up what I've been given and put it in http://www.zefox.net/~fbsd/rpi3/swaptests/tools/ in hopes it'll be useful. One thing I haven't figured out is how to organize the test result tree in a simple way. At this point it's /revision/swapconfig/patch1/patch2/.../... but that gets very messy fast, and ambiguous if folks don't standarize terminology (swap configs in particular). > I tend to be in the no-fail, which is more data I guess. I also have a much > older (slower) SD card that I could put back into service and see if that > tweaks me a more towards the maybe-fail camp. It seems a worthwhile experiment, but it'll complicate the test tree even more 8-) This _can't_ be a new problem, how do folks deal with it? Thanks for reading, bob prohaska > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Aug 9 22:00:22 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD7971074C1B for ; Thu, 9 Aug 2018 22:00:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 750018A4DA for ; Thu, 9 Aug 2018 22:00:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id w79M0CT8076316 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Aug 2018 00:00:12 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id w79M0CEN076315; Fri, 10 Aug 2018 00:00:12 +0200 (CEST) (envelope-from marius) Date: Fri, 10 Aug 2018 00:00:12 +0200 From: Marius Strobl To: Mark Millard Cc: Emmanuel Vadot , Mark Millard via freebsd-arm Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted Message-ID: <20180809220012.GU21523@alchemy.franken.de> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (alchemy.franken.de [0.0.0.0]); Fri, 10 Aug 2018 00:00:13 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 22:00:22 -0000 On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: > On 2018-Aug-7, at 6:25 PM, Mark Millard wrote: > > > [FYI: I duplicated the e.MMC to a microsdhc, made minor > > changes, and tested booting: it did.] > > > > On 2018-Aug-6, at 11:39 AM, Mark Millard wrote: > > > >> [Fixing a confusing "slower" reference . . .] > >> > >> On 2018-Aug-6, at 11:26 AM, Mark Millard wrote: > >> > >>> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot wrote: > >>> > >>>> On Mon, 6 Aug 2018 10:12:43 -0700 > >>>> Mark Millard wrote: > >>>> > >>>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot wrote: > >>>>> > >>>>>> On Mon, 6 Aug 2018 02:48:57 -0700 > >>>>>> Mark Millard via freebsd-arm wrote: > >>>>>> > >>>>>>> I amd64 -> aarch64 cross built -r337347 and installed it > >>>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as > >>>>>>> bootaa64.efi) as an update. My attempted synchronization > >>>>>>> of loader.conf and ttys and devd.conf may be incorrect. > >>>>>>> (Previous to this the Pine64+ 2GB seemed to be working > >>>>>>> okay but it was at a very old build.) > >>>>>>> > >>>>>>> The kernel config has GENERIC included but the various > >>>>>>> debug features disabled. (My typical operating > >>>>>>> environment.) > >>>>>>> > >>>>>>> For all I know what the below shows might be expected > >>>>>>> at this point. The kernel seems to have problems with > >>>>>>> the MMC (that the kernel was loaded from). No other > >>>>>>> media are attached. mmcsd0 is really an 128 GiByte > >>>>>>> emmc on an adapter. (This historically worked for me.) > >>>>>> > >>>>>> emmc to sd ? that's weird ... > >>>>> > >>>>> An example of the adapter I've used for this is: > >>>>> > >>>>> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter > >>>> > >>>> So this is a passive adapter, maybe that's something that should work > >>>> but it's definitly is something that calls for problems. > >>>> > >>>>> emmc is multi-mode for its allowed modes of operation. Thus > >>>>> its ability to frequently be used this way, such as via HS200. > >>>>> emmc is commonly more robust as I understand. > >>>> > >>>> I didn't understand a word. > >>> > >>> I got the HS200 reference from the boot -v output. Such is currently from the > >>> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC > >>> members have free access, others do not.) > >>> > >>> The output reported: > >>> > >>> mmc0: Card at relative address 0x0002 added: > >>> mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 > >>> mmc0: quirks: 0 > >>> mmc0: bus: 4bit, 200MHz (HS200 timing) > >>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks > >>> > >>> The e.MMC bus speed modes with I/O Voltage 3V allowed are: > >>> > >>> Backwards Compatibility with legacy MMC card, data rate single, 3V allowed, bus widths 1,4,8, 0-26 MHz > >>> > >>> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz > >>> > >>> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz > >>> > >>> (The last being the fastest for maximum transfer rate with 3V.) > >>> > >>> There is another 1.8V/1.2V mode: HS400 that is dual data rate and always 8 bit, > >>> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. HS400 > >>> is optional and sufficiently old e.MMC standard vintages would likely not > >>> even have it. > >>> > >>> So a slower 3.? V mode of use used to be selected (based on the constraints > >>> on the board's voltages in some way, possibly hard coded). > >> > >> "slower" lacks context: I should have said . . . > >> > >> "a slower than HS200 3.? V mode" > >> > >> As I remember, the 3V range is from 2.7 V to 3.6 V or some such. > >> So 3.3 V would be in range, at least if I remember right. > >> > >>>>> > >>>>> (I had to modify the case the pine64+ 2GB is in in order for > >>>>> the adapter/emmc combination to fit in all the way.) > >>>>> > >>> > > > > I duplicated the e.MMC partition content to a microsdhc > > for each partition (and u-boot but no swap), made minor > > changes, and tested booting. It booted, with messages > > like: > > > > Trying to boot from MMC1 > > . . . > > MMC: SUNXI SD/MMC: 0 > > . . . > > mmc0 is current device > > Scanning mmc 0:1... > > Found EFI removable media binary efi/boot/bootaa64.efi > > . . . > > Scanning disks on mmc... > > MMC Device 1 not found > > MMC Device 2 not found > > MMC Device 3 not found > > Found 3 disks > > . . . > > aw_mmc0: mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0 > > mmc0: on aw_mmc0 > > . . . > > mmcsd0: 32GB at mmc0 50.0MHz/4bit/32768-block > > mmc0: ACMD42 failed, RESULT: 4 > > mmc0: Card at relative address 43690 failed to set bus width > > > > > > > > Prior to the last 2 lines above looks normal to me for the > > MMC material. > > > > So the only issue seems to be having an e.MCC device and > > how it is handled (mode of attempted operation, including > > voltage), given the limitations of the Pine64+ 2GB board. > > > > My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD > > e.MMC reader to be tried via: > > > > High Speed DDR mode (Data rate dual), 3.3V (so in the range > > allowed around 3V), full bus width that can be used (4 in my > > current context), 52 MHz or so. > > > > (At least for any vintage of e.MMC recent enough to have that > > available. This e.MMC mode has been around since e.MMC 4.4 > > (2009). I've seen claims that at the host controller level > > it is basically the same configuration used for SD DDR50, > > with different arguments in CMD6 for configuration.) > > > > But I've no clue if this fits well with the upstream status > > of things or not. I've seen claims that, unlike for UHS-II > > and UHS-III, Linux has e.MMC speed mode support being "quite > > complete" in the more generic parts not specific to each > > controller. (Only a quick summary.) So I'm hopeful for > > upstream. > > The 3V problem for e.MCC DDR @ 52 MHz looks more > generic than the Pine64's or even aarch64 or even arm > in general. Likely not your issue directly [Emmanuel]. > > Looking around some more I see that the card-type/device-type > bitfield had as of JESD84-A441 (March 2010) [JESD84-A44 was > apparently withdrawn, not just updated]: > > Bits 7:4 reserved (defined in sufficiently more recent vintages) > Bit 3: DDR MMC @ 52 MHz 1.2 V I/O > Bit 2: DDR MMC @ 52 MHz 1.8 V or 3V I/O > Bit 1: SDR @ 52 MHz at rated device voltage(s) > Bit 0: SDR @ 26 MHz at rated device voltage(s) > (more modern has 3-0 being the same) > > but the only valid bit patterns with 7:4 being zero > were(/are): 0x01, 0x03, 0x07, 0x0B, and 0x0F. > > Note also that an e.MCC device can for DDR @ 52 MHz: > > support 1.2 V without supporting 1.8 V/3 V > or: > support 1.8 V/3 V without supporting 1.2 V > > (What I was using supports 3V and u-boot through > loading the kernel worked fine.) > > Presuming the environment can supply an I/O voltage in the allowed > range around 3V, such as 3.3V being the the range 2.7 V to 3.6 V: > (The environment might not have 1.8V available as an > alternative even though E.MMC devices have 1.8V and 3V paired, for > example the Pine64+ 2GB, from what I'm told, lacks 1.8V.) > > Then 0x07 implies DDR @ 52 MHz with 3V I/O is available for use > And 0x0F implies DDR @ 52 MHz with 3V I/O is available for use > (Otherwise DDR @ 52 MHz with 3V I/O is unavailable.) > If the e.MCC supports DDR @ 52 MHz with 1.8 V it also supports > 3V --and the other way around. > > So the code is odd/incomplete in /usr/src/sys/dev/mmc/bridge.h : > > #define MMC_CAP_MMC_DDR52_120 (1 << 11) /* Can do eMMC DDR52 at 1.2 V */ > #define MMC_CAP_MMC_DDR52_180 (1 << 12) /* Can do eMMC DDR52 at 1.8 V */ > #define MMC_CAP_MMC_DDR52 (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180) > > unless MMC_CAP_MMC_DDR52_180 implicitly also covers 3V. If so, the > comment should mention 3V, as might the macro name. > > Another possibility is that there should be another macro. Something > like: > > #define MMC_CAP_MMC_DDR52_120 (1 << 11) /* Can do eMMC DDR52 at 1.2 V (nominal) */ > #define MMC_CAP_MMC_DDR52_180 (1 << 12) /* Can do eMMC DDR52 at 1.8 V (nominal) */ > #define MMC_CAP_MMC_DDR52_300 (1 << ??) /* Can do eMMC DDR52 at 3.0 V (nominal) */ > #define MMC_CAP_MMC_DDR52 (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180 | MMC_CAP_MMC_DDR52_300) > > (I do not claim such is sufficient, just suggestive.) > > It looks like this goes back to -r315598 (2017-Mar-19) > when the code as 1st added by marius. I've not found any > representation of the 3V DDR @ 52 MHz case for e.MMC > so far. It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However, with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for example figure 3-14 in the SD physical layer specification version 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was written, Linux didn't support the former either so I saw no point in adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR a bit later in January 2017, though). While I have no problem with support for DDR52 at 3.0 V VCCQ being added to mmc(4), I doubt that will solve your problem given that Linux doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+ or any other Allwinner gear. Based on what I could figure out about Allwinner MMC controllers, their capabilities actually differ depending on the particular instance of MMC controller of a given SoC (apparently, they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO). So I guess what needs to be done is to let aw_mmc(4) announce and support different sets of capabilities depending on which instance of the controller it is driving. For your adapter this likely means that high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD slot complies with the SD physical layer specification if 1.8 V VCCQ isn't supported by the particular board. Marius From owner-freebsd-arm@freebsd.org Fri Aug 10 02:16:31 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F02E105568F for ; Fri, 10 Aug 2018 02:16:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02B8F72AAB for ; Fri, 10 Aug 2018 02:16:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id s7-v6so734826itb.4 for ; Thu, 09 Aug 2018 19:16:30 -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=Nr7Y3vhrmyRR9LU6F7DIufkAHOdJyTUf39NEyQkWTeo=; b=elaRPdGICeFYunMHPSDc3PY7Vu5aNsmRD9l5zCfTCn0vmeBM7xk0vbVl4P3jJG4/+j 0hxcZceZrN4AWiexM3J7Gk/jnEfwNeuKss+YuBmcgv4xNfkyHo7mdqox0+j0srlS+lLs rvi1biJtysE8AAGwBy1sbFRFD160hSfHl6nRv3KEiNpRz0whwxNK6Z/nzzwayTnJNNuT 7VZyYffgZrasA4O823FsUqwsmBolq5lEZbWGRv4g6Z3uG86P+4LB7pDYUp9TGsK4EuXc bgvH8Q37prESgrMXwviAVeRFDe+TWOqNK/IcyNrhLKSQZtqJSOODtvDrT00BpWtQBf+c iu+Q== 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=Nr7Y3vhrmyRR9LU6F7DIufkAHOdJyTUf39NEyQkWTeo=; b=QyPe4c4sEQf/zkQbs4LQTfhhZqURydGzxLar3KdH82xu6fYAundwqO3kZ6BwjhEGm1 Mp09SWxRDfcUY9/HFy6yU2wfu7WzlnyGWJzJH55zBflQG+qqOUm7tXHvs/vR4EpZEXRt AK9G9zUiAaHvbtE58+t/bF5K+vCKrpRhlRr2JKzzbX5yf2+mRUsCTBqd+F3InKoEmdDW UETUCasKmpybbSCA/AsGGpRZ42yQSlEGVlkhWRXgjaLyqDvtvV8H9WAUKErSSQVja5sV 8MMJ0PU17v2qeUKuLJ/EncTFOfEIk1WtmF23bZlGQmJzcpF2jAIzj+0uZkJkTNDSVpMY 1XPw== X-Gm-Message-State: AOUpUlEK/PgacUPm4laprvW/e6LDVPHGftOn5DGfHqiE5gDZZ6bxZlC4 AgUkGXSBhqz7yO20qDW+S6xkIemz9vbub3SMjeCKhA== X-Google-Smtp-Source: AA+uWPzfppMbYU9dHpGYoS6DS2093Kbgd6t1rrjpZElLDYKBzNxlW+JDBPLicX5J4D5IvXehucGtjdGulouaL8g9qRc= X-Received: by 2002:a02:a701:: with SMTP id k1-v6mr4121351jam.140.1533867389778; Thu, 09 Aug 2018 19:16:29 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 19:16:29 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> References: <64850.63077.qm@web101706.mail.ssk.yahoo.co.jp> <387823.67007.qm@web101711.mail.ssk.yahoo.co.jp> <812183.70978.qm@web101705.mail.ssk.yahoo.co.jp> <892631.23713.qm@web101718.mail.ssk.yahoo.co.jp> <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Thu, 9 Aug 2018 20:16:29 -0600 X-Google-Sender-Auth: xUqWdKFuk7jxQaUE43UPCxNpexg Message-ID: Subject: Re: solved Re: still hang up arm/ralink To: Mori Hiroki Cc: Michael Zhilin , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 02:16:31 -0000 Mori-san I took your advice and bought a Buffalo WZR2-G300N off ebay. It arrived while I was on vacation. So, I spent a few minutes with it today. I've installed header for serial port, puzzled out the pins, found your blog that had the pins and the piece I was missing (the baud rate). I now have added it to my test lab's terminal server and hope to start building images for it once I get my test lab's CI infrastructure up and running. So, now I'm sitting at the "RT2860-EVB#" prompt from uboot hoping to boot the RT1310 kernel. However, I lack instructions and can't seem to find all the details in your posts or on your blog. How do I load/create the RAM disk referenced in the kernel config file "options ROOTDEVNAME=\"cd9660:/dev/cfid0s.rootfs.uzip\"" ? what address do I load the kernel at (0x40800000 is listed in a diagram, but 0x40000100 is shown in the dmesg) and which variation of the kernel should I use? Thanks for any help you can offer. Warner On Sat, Mar 10, 2018 at 2:31 AM, Mori Hiroki wrote: > Hi > > I do try to todays current. It' work find on RT1310. > > https://gist.github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5 > > > Thanks > > Hiroki Mori > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Aug 10 03:02:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA78B1056FE4 for ; Fri, 10 Aug 2018 03:02:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 649EF74646 for ; Fri, 10 Aug 2018 03:02:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ipnRuygVM1lZJWP.dy7TvNdCCrMpA_b6S4hMBX_fm.pVQvDVAgMYOev1qCR7zc. 8BKLmWCnoQZMuxoSNhnmeXcjlfaBJrP3eN.rchmyL9KzbaRKkUEUcN9tHzRt1LxzCo9ZgvlAndfP 3HG.YaxPhxLYAI8__oAgsVeC61U6TkDi7RKgNWkAvQyAV.N1gtr2Fab_lg5yJC9wvWbCuglIKThA IlrnjuROWfefHEuraTEyMp8Tguqp_khESwaJ4CB3gYzl_Z1aXXnJR1BeND5roIgLj.fy187tg.v8 YONPO_udtsHAuGZXA40GguWzg6PVWVnq2CVm.OUYDn1iIxdQTkgY99hWBPTzbNBUV4QR3.P1nmOX d0sSSZOKChKLFPv4aYPanWIYmeLhsm7YtVO6NlT3LsBzPJGsXducp0eavogBSqpLYGgyBNK.RoeA X5kSB3Z_vHm9NKYV7K2BtIfWFz44td1e8vuU0kGiUuimWUBT86bji9XJS4Miev3nvsWr6DtGrvtg 6.mCHmBDPszHqcjucp_Hdm2zdlp_8jASOjaDHVvlZujvX0CPvY7kMfNw83Y2uj3Xk.VG5i8i_ych S8GDKoT3VDCWNf8PiUeUKfoWzEkUfX_aKwtnOxcOg6trlIZzPpQG9GeQsSFbjHD5lGUdk9N1MZ1C 40pDmL7GZQ_RXPCQ8q.XDptJkgBAhtkceBWuXH7tuWQS5ekFqvF9UmbJ1Zi8SJVDIbqRpPVXmymI ftIONxZ5cEle8l1mk6ZPIShYUJpF29hxO7O5QIkmhJWZKVxDNvwsqXLnnjCNsEh_qx9rOFs2m3zR mTiWVsAajiX6iXWjiIENqOIQF6_g18hKeDIrvLXhLxwJ5EFNFkAhuj8DhJ65yUFv3SljXLVRVe07 yqhhLU6hs2pIrh5o6.AKwgH57sas1kLgKvceeOjCNiErDPt..FoibZZe9Oos9h13hSFuERDakUiI l0cma2fwxfwI81wTwls9HraRSt6WeHox0By11COpGSovj7CNnqntAjFny1_1zejdLA8ZitWB5wyW 1mpK4g84- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Aug 2018 03:02:44 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp426.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e407f09cd8962aad00baae025a14336c; Fri, 10 Aug 2018 03:02:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <20180809220012.GU21523@alchemy.franken.de> Date: Thu, 9 Aug 2018 20:02:38 -0700 Cc: Emmanuel Vadot , Mark Millard via freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <20180809220012.GU21523@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 03:02:51 -0000 On 2018-Aug-9, at 3:00 PM, Marius Strobl wrote: > On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: >> . . . > > It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However, > with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD > DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for > example figure 3-14 in the SD physical layer specification version > 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with > SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was > written, Linux didn't support the former either so I saw no point in > adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR > a bit later in January 2017, though). > While I have no problem with support for DDR52 at 3.0 V VCCQ being > added to mmc(4), I doubt that will solve your problem given that Linux > doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+ > or any other Allwinner gear. Based on what I could figure out about > Allwinner MMC controllers, their capabilities actually differ depending > on the particular instance of MMC controller of a given SoC (apparently, > they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO). > So I guess what needs to be done is to let aw_mmc(4) announce and > support different sets of capabilities depending on which instance of > the controller it is driving. For your adapter this likely means that > high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD > slot complies with the SD physical layer specification if 1.8 V VCCQ > isn't supported by the particular board. Thanks for the notes. Clearly there is something that I'm missing because: *) Historically (before the switch to official dts's and such) I was able to boot, buildworld, buildkernel, poudreire-devel and the like booting from the e.MCC over the sdcard adapter plugged into the Pine64+ 2GB's sdcard slot. It had been my standard configuration for some time before I made the jump to a more modern environment. As for now: A) u-boot successfully gets the loader from the e.MCC over the sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. B) The loader successfully loads the kernel from the e.MCC over the sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. C) The first failure is from the kernel attempting to deal with the e.MCC (via the adapter). I may have read into this (and the messages from boot -v and what was said about them) the wrong assumptions about what is wrong. What I can say is that the issue looks to be specific to the FreeBSD kernel but not to the prior loader (nor to u-boot). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 10 04:44:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C09A105B4F4 for ; Fri, 10 Aug 2018 04:44:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EB1B47874A; Fri, 10 Aug 2018 04:44:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w7A4iRsG035088 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Aug 2018 21:44:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7A4iQib035087; Thu, 9 Aug 2018 21:44:26 -0700 (PDT) (envelope-from fbsd) Date: Thu, 9 Aug 2018 21:44:26 -0700 From: bob prohaska To: Warner Losh Cc: Mark Johnston , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180810044426.GB32974@www.zefox.net> References: <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 04:44:18 -0000 On Thu, Aug 09, 2018 at 09:42:59AM -0600, Warner Losh wrote: > On Thu, Aug 9, 2018 at 9:37 AM, bob prohaska wrote: > > > > > There's a kernel building now with > > options CAM_IOSCHED_DYNAMIC > > in the config file. Is it still worth trying? Anything else to try? > > > > It won't be a cure-all, out of the box, I don't think. However, the read > biasing code may help sneak a few 'reads' in between writes which may help > keep away from the pathological behavior.... Or not, it's hard to say... > I've not looked at swapping to super-crappy nand (I mean thumb drives) in > as much detail as the drives we use for work. > Alas, 'tis true. Combined with the patches so far it didn't seem to help at all, with or without using vm.pageout_oom_seq to 120. The -j4 buildworld ended with an OOMA kill using 12 and a panic and reboot at 120. A -j4 buildworld actually got farther using vm.pageout_oom_seq=120 with no other changes. Results are at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/batchqueue/pageout120/slow_swap/cam_iosched_dynamic/ Any suggestions on what to try next would be welcome. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Fri Aug 10 05:55:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5CBF105D279 for ; Fri, 10 Aug 2018 05:55:55 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh504-vm10.bullet.mail.kks.yahoo.co.jp (nh504-vm10.bullet.mail.kks.yahoo.co.jp [183.79.57.96]) by mx1.freebsd.org (Postfix) with SMTP id A8F427A6CE for ; Fri, 10 Aug 2018 05:55:54 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.139] by nh504.bullet.mail.kks.yahoo.co.jp with NNFMP; 10 Aug 2018 05:52:52 -0000 Received: from [183.79.100.136] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 10 Aug 2018 05:52:52 -0000 Received: from [127.0.0.1] by omp505.mail.kks.yahoo.co.jp with NNFMP; 10 Aug 2018 05:52:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 153868.2568.bm@omp505.mail.kks.yahoo.co.jp Received: (qmail 24710 invoked by uid 60001); 10 Aug 2018 05:52:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1533880371; bh=FqMjSz17ZPVdk4wwvDzfaeq8oF0ikNgHzm6kKoMC/e0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ANIW49fKX1hIEFC9+HVtlFbpueHGJ3/rRrYo7iC2lgEkWl1kfZpWhSCgSbl24fYdOrIMGIa6ekATC8YZKKzduUcoGHTleMhRgDEYhrCVc6q+ilDTKiBczAqgOKW7N9cFFdapA7RNUPv2+il9NqErbDJoX00cwc6IhJeymz1S96Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UyVnGA6SQs44HnF0PXETCyxacx0metNGtREEENd8xwTJ5GlirRcFiB7sL5R6UVyMsFrTesuWEt/amX39WjRCBy1tn3y4ULpB7ThPXMZi7FmVsZGKcxWxyczIOLxa+bzaSW/TWcBNLyZm2q1Md1iv5Vn/9uceztYcU6IeihcoAO4=; Message-ID: <920419.9428.qm@web103910.mail.ssk.yahoo.co.jp> X-YMail-OSG: Q5HZDbgVM1l_MjJdsePkI5ipiIcVsJzjY.eCAf3WaMONGq1c2K8e1_6T7s98t2mW5vHNHtHioUlHQmDkDEM2qDn0mg0vwXVbCu5yBzCTMDbO5J2Z6_QmfClMClhMzvW4eWCUqJdxslLRpMduLqK17NPXq2MXJAD8fa7QA2PzSRDQW.uxVqvAZJnZ2VlgowGJFMWX1J76AVlX8lu5KhNA.HYno4VQJojXAAOXpTzqQHilDAm4a6lndfBObaXLodsQxzgwssAL4WhZjYUSGrPoE56dY33adzMC4IFDZAEvrxPz2bFf8c7_lEfGL6NpD2SGjVjE_68hOfT0Nem00kVO55Hx4_mPUNrkqKApF139SyAwPTPYWXR8FmTq1OQUGwv4TWAnsXCRfDdz4t3Ha6nhz1VNs8cmhzpk8FoLg9MA3ke6BhZS3dPkMw0ffjuJsp_r2nkXphjcof3ZeE9gts4K6gn1flAGAC7O2BLFCvSqsTlssosD2aqdnX51gaCl_dUiBPVVkwyP1zq4o52qEDDeiX_mSQjG0j0E4njb1VTRJueaQSmRPMTcXANT0sZKAzOPikk.ZdubXb1auk9xN.t8PNnlX62AijzeyJ1ILVJ74K9ZUaBJKETCHTQa333K6bzG Received: from [203.165.91.75] by web103910.mail.ssk.yahoo.co.jp via HTTP; Fri, 10 Aug 2018 14:52:50 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: 9QFOJQwVM1nKlZbDrY3wCbe.OS6SiRWc6fg4xZLzwAQMnfSyKVppJLV8wDsDwhtSmWNtZoTspVFSGGZLXDCGeXPxcdIEwOvFZrg7qqWIoRoo.rWMak220yk3D9mooakQtrip References: <64850.63077.qm@web101706.mail.ssk.yahoo.co.jp> <387823.67007.qm@web101711.mail.ssk.yahoo.co.jp> <812183.70978.qm@web101705.mail.ssk.yahoo.co.jp> <892631.23713.qm@web101718.mail.ssk.yahoo.co.jp> <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> Date: Fri, 10 Aug 2018 14:52:50 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: solved Re: still hang up arm/ralink To: Warner Losh Cc: Michael Zhilin , "freebsd-arm@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 05:55:55 -0000 Hi.=0A=0A----- Original Message -----=0A>From: Warner Losh = =0A>To: Mori Hiroki =0A>Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" =0A>Date: 20= 18/8/10, Fri 11:16=0A>Subject: Re: solved Re: still hang up arm/ralink=0A> = =0A>=0A>Mori-san=0A>=0A>=0A>I took your advice and bought a Buffalo WZR2-G3= 00N off ebay. It arrived while I was on vacation. So, I spent a few minutes= with it today. I've installed header for serial port, puzzled out the pins= , found your blog that had the pins and the piece I was missing (the baud r= ate). I now have added it to my test lab's terminal server and hope to star= t building images for it once I get my test lab's CI infrastructure up and = running.=0A>=0A=0AThanks for your cooperation.=0A=0A>=0A>So, now I'm sittin= g at the "RT2860-EVB#" prompt from uboot hoping to boot the RT1310 kernel. = However, I lack instructions and can't seem to find all the details in your= posts or on your blog. How do I load/create the RAM disk referenced in the= kernel config file "options=A0 =A0 =A0 =A0 =A0ROOTDEVNAME=3D\"cd9660:/dev/= cfid0s.rootfs.uzip\"" ? what address do I load the kernel at (0x40800000 is= listed in a diagram, but 0x40000100 is shown in the dmesg) and which varia= tion of the kernel should I use? Thanks for any help you can offer.=0A>=0A= =0AI use ZRouter build system. But I am a suggestion normal build system.= =0A=0AI think=A0Buffalo WZR2-G300N is different u-boot on US and Japan mode= l.=0ABecause of my target prompt is "5VT1310-EVB#". =A0Be careful operation= .=0AYou can find some information=A0in printenv at u-boot.=0A=0ASorry I for= get memory address setting in build system. I add this to review.=0A=0Ahttp= s://reviews.freebsd.org/D16622=0A=0AIn this setting build kernel header is = this.=0A=0A% readelf -h Buffalo_WZR2-G300N_kernel=0AELF Header:=0A=A0 Magic= : =A0 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00=A0=0A=A0 Class: =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ELF32=0A=A0 Data:=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2's complement, lit= tle endian=0A=A0 Version: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 1 (current)=0A=A0 OS/ABI:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 UNIX - FreeBSD=0A=A0 ABI Version: =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 0=0A=A0 Type:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 EXEC (Executable file)=0A=A0 Machine: =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ARM=0A=A0 Version: =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x1=0A=A0 Entry point address: =A0 =A0 =A0 =A0 = =A0 =A0 =A0 0xc0000100=0A=A0 Start of program headers:=A0 =A0 =A0 =A0 =A0 5= 2 (bytes into file)=0A=A0 Start of section headers:=A0 =A0 =A0 =A0 =A0 3633= 180 (bytes into file)=0A=A0 Flags: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 0x5000202, has entry point, Version5 EABI, =0A=A0 = Size of this header: =A0 =A0 =A0 =A0 =A0 =A0 =A0 52 (bytes)=0A=A0 Size of p= rogram headers: =A0 =A0 =A0 =A0 =A0 32 (bytes)=0A=A0 Number of program head= ers: =A0 =A0 =A0 =A0 6=0A=A0 Size of section headers: =A0 =A0 =A0 =A0 =A0 4= 0 (bytes)=0A=A0 Number of section headers: =A0 =A0 =A0 =A0 37=0A=A0 Section= header string table index: 34=0A=0ADo opjcopy and compress and make u-boot= image by load and entry address is=A00x40000100.=0A=0A% file Buffalo_WZR2-= G300N_kernel.kbin.oldlzma.uboot=0A=0ABuffalo_WZR2-G300N_kernel.kbin.oldlzma= .uboot: u-boot legacy uImage, FreeBSD Kernel Image, Linux/ARM, OS Kernel Im= age (lzma), 999004 bytes, Wed Aug=A0 8 22:50:36 2018, Load Address: 0x40000= 100, Entry Point: 0x40000100, Header CRC: 0xFEC4D6B9, Data CRC: 0xE650EDDF= =0A=0AIt can execute on memory. (not flash)=0AYou need set ipaddr and serve= rip on u-boot.=0A=0A5VT1310-EVB# tftpboot 00800000 Buffalo_WZR2-G300N_kerne= l.kbin.oldlzma.uboot=0ATFTP from server 10.10.10.3; our IP address is 10.10= .10.190=0AFilename 'Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot'.=0ALoad a= ddress: 0x800000=0ALoading: ###############################################= ##################=0A######################################################= ###########=0A#############################################################= ####=0A#=0Adone=0ABytes transferred =3D 999068 (f3e9c hex)=0A5VT1310-EVB# b= ootm=0A## Booting image at 00800000 ...=0A=A0=A0 Image Name: =A0 FreeBSD Ke= rnel Image=0A=A0=A0 Image Type: =A0 ARM Linux Kernel Image (lzma compressed= )=0A=A0=A0 Data Size:=A0 =A0 999004 Bytes =3D 975.6 kB=0A=A0=A0 Load Addres= s: 40000100=0A=A0=A0 Entry Point:=A0 40000100=0A=A0=A0 Verifying Checksum .= .. OK=0A=A0=A0 Uncompressing LZMA Kernel Image ............................= ..............OK=0A=0AStarting kernel @40000100...=0A=0AKDB: debugger backe= nds: ddb=0AKDB: current backend: ddb=0ACopyright (c) 1992-2018 The FreeBSD = Project.=0ACopyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 19= 93, 1994=0AThe Regents of the University of California. All rights reserved= .=0A=0AIf you can execute kernel then stop at rootfs mount.=0A=0AI think th= is is first step.=0A=0AThanks=0A=0AHiroki Mori=0A=0A>=0A>Warner=0A>=0A>=0A>= On Sat, Mar 10, 2018 at 2:31 AM, Mori Hiroki wrote:= =0A>=0A>Hi=0A>>=0A>>I do try to todays current. It' work find on RT1310.=0A= >>=0A>>https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a15e4a b= 5=0A>>=0A>>=0A>>Thanks=0A>>=0A>>Hiroki Mori=0A>>___________________________= ___ _________________=0A>>freebsd-arm@freebsd.org mailing list=0A>>https://= lists.freebsd.org/ mailman/listinfo/freebsd-arm=0A>>To unsubscribe, send an= y mail to "freebsd-arm-unsubscribe@ freebsd.org"=0A>>=0A>=0A>=0A> From owner-freebsd-arm@freebsd.org Fri Aug 10 06:39:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92003105EB6A for ; Fri, 10 Aug 2018 06:39:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22EBA7BCE5 for ; Fri, 10 Aug 2018 06:39:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: IY9kfEAVM1kUBLoEUIRhgExrsynzsfevKZtLGJFWhKILbwZUBHyYtuezTsH4rTe 69zCq55CNawdHcjHlxqwehEte4Erkz_QMjBz7mb2I4BdG_kKMOqaIzQFtCdXk9Gpd0AMBjiR84nQ _L.B0ppRa_yA6IkzAJu29tbP0BCiVr8YyYnO88j0OMZ4LptAyjUzdO3HH_AHtM7_J8vnkEevQgeZ 2o_rj_XjNnQAem6njgPWe0wdeg0JIBMZC7H7P18YWSR9mUSw0SRj.eSiVBM1Tfeb2nATr_nyMkYq fCMg3gZ2N6GR3Q4WPYTTkC0RO3WCwFMiDhqbtBafeU2RgYdlF.ISyftZqjs60NK_4_5.2cIbaLp2 nT7eP27r7YTituOB79FdyWAXrD3RPrzc2ofbDLQ9MqiE0l2S5NZrRxGyewcoy9w4I1c0OMgEZseN Aq36sBkEYjHI6g1nEhZPoEmJOwlDLQENF.C8FBsE73ors.C.u0AfKs0jtrFSYQ.3z3b.Znrr0Sem Aq2XCQNq0MfwYaSUvk8tJnDggqzJmx4WJ3e07UBmlUcLEuW_CEGXOa8Ze68cy2C3b7tDtq.uCrJ5 CtrzvwbR1bAN_K.pQkpMxOqUxZbqyyJXl7dXJrvZ3CmTDhFHkAjIFUL40jemdvuBciIFyU_DxgQw PyKwIO5nMaGqr2HrQBD36YieaJSLtRE7vaOF7bYuwxGWVnVAGH7eu6esKh0YsWLcwUM0D14qdJBb l..Oy1CuqWYCRdhLfOn3b2ummqc1Wd23VZbaOMErIfSWBFD4ZxzhS5PFN..KvIc8mk_2hCAP6DXH bHa7t.2ZuQDCHNWP21O89QgVtCKMMs5GnSpWVYlFUYracwlpR8Pno0hS0GZq3LT_58ekYvpOYjl4 dVSA04W9pAgKbHnQaTOpIbOHIZzgR2uuTGI.JG45KpnWSFwXfLBHyoUN.DX15FHXVeXdfwzrUyox EqWo_QOgaw8ixSA.JsqCR0nSbZVhohWIR7FnTSF597ecMKWTTg3Uluw8KUyupXT4cW6yq2VKlVuu nLIR4FEajOXNEBWXlAns- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 10 Aug 2018 06:39:40 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6e0631071d8867569185862ce3b9ba10; Fri, 10 Aug 2018 06:39:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> Date: Thu, 9 Aug 2018 23:39:35 -0700 Cc: Mark Millard via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <20180809220012.GU21523@alchemy.franken.de> <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> To: Marius Strobl , Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 06:39:42 -0000 On 2018-Aug-9, at 8:02 PM, Mark Millard wrote: > On 2018-Aug-9, at 3:00 PM, Marius Strobl = wrote: >=20 >> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: >>> . . . >>=20 >> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However, >> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD >> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for >> example figure 3-14 in the SD physical layer specification version >> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with >> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was >> written, Linux didn't support the former either so I saw no point in >> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew = MMC_CAP_3_3V_DDR >> a bit later in January 2017, though). >> While I have no problem with support for DDR52 at 3.0 V VCCQ being >> added to mmc(4), I doubt that will solve your problem given that = Linux >> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for = Pine64+ >> or any other Allwinner gear. Based on what I could figure out about >> Allwinner MMC controllers, their capabilities actually differ = depending >> on the particular instance of MMC controller of a given SoC = (apparently, >> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO). >> So I guess what needs to be done is to let aw_mmc(4) announce and >> support different sets of capabilities depending on which instance of >> the controller it is driving. For your adapter this likely means that >> high-speed at 3.0 V VCCQ is the achievable maximum so that the = microSD >> slot complies with the SD physical layer specification if 1.8 V VCCQ >> isn't supported by the particular board. >=20 > Thanks for the notes. >=20 > Clearly there is something that I'm missing because: >=20 > *) Historically (before the switch to official dts's and such) > I was able to boot, buildworld, buildkernel, poudreire-devel > and the like booting from the e.MCC over the sdcard > adapter plugged into the Pine64+ 2GB's sdcard slot. >=20 > It had been my standard configuration for some time before > I made the jump to a more modern environment. >=20 > As for now: >=20 > A) u-boot successfully gets the loader from the e.MCC over the sdcard > adapter plugged into the Pine64+ 2GB's sdracard slot. >=20 > B) The loader successfully loads the kernel from the e.MCC over the > sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. >=20 > C) The first failure is from the kernel attempting to deal with > the e.MCC (via the adapter). >=20 > I may have read into this (and the messages from boot -v and what > was said about them) the wrong assumptions about what is wrong. >=20 > What I can say is that the issue looks to be specific to the > FreeBSD kernel but not to the prior loader (nor to u-boot). As for the Pine A64+ 2GB specifics . . . Quoting pine6.org about the microsd support for Pine A64: QUOTE The Pine A64 board supports SD, SDHC, and SDXC format microSD card =E2=80=93= this means the largest capacity is 256GB. Please note that if a microSD = card is formatted as an FAT32 file format, the maximum capacity is 32GB. END QUOTE I would expect supporting SDHC and SDXC to mean support for various 1.8V modes of use: Such required if UHS-I is supported (UHS50 or UHS104). Also DDR50 is required for microSD (but not Standard SD). This would seem to match what the schematics suggest to me (see below). I looked and the Power Tree page of the schematics for the Pine A64+ 2GB at: = http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20= Rev%20C-20160113_Release.pdf and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to VDD. T-CARD looks to me like the sdcard slot connections. (Yes: the mix of T-CADD and T-CARD naming is as in the document.) (I'm not listing the capacitor and such.) For reference, for the e.MCC adaptor for anyone that cares: (things like "3.3V" are as labeled in those schematics, whatever the actual voltage of use for some mode of use) https://forum.odroid.com/download/file.php?id=3D1036&mode=3Dview shows a 49.9K resister in line between 3.3V and RSTN at the e.MMC end of things. It also shows a 10uF capacitor between 3.3V and ground on VDD from the micrSD end of things. The rest is direct connections. But the connections are for using a Hardkernel eMMC module, in my case V0.3. http://forum.odroid.com/download/file.php?id=3D433 is for that module. Other than some parallel capacitors to ground off of VDD and VDDF, and one off of VDDI, it looks like direct connections there to the e.MMC device as well. End "for reference". The above does not say the the loader and u-boot are using a 1.8 V mode instead of a 3.3V mode of operation for the sdcard interface, even if 1.8V is possible. =46rom an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be any of (for 3V): Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device = voltage(s)" Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device = voltage(s)" that match up with one of the sdcard 3.3V modes: UHS-I modes: DS: Default Speed up to 25 MHz 3.3V signaling HS: High Speed up to 50 MHz 3.3V signaling (Looks like the signal timings are distinct from 1.8 V modes.) So not bit 2 if 3V, unsure about the other two bits for 3V. In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1 UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does boot from) the kernel seems to pick the UHS-I HS mode, instead of SDR50 or DDR50 or higher: aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 aw_mmc0: vmmc-supply regulator found mmc0: on aw_mmc0 random: harvesting attach, 8 bytes (4 bits) from mmc0 random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled compat = allwinner,sun50i-a64-mmc (no driver attached) simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled compat = allwinner,sun50i-a64-emmc (no driver attached) . . . aw_mmc0: Powering up sd/mmc mmc0: Probing bus . . . mmc0: SD 2.0 interface conditions: OK mmc0: SD probe: OK (OCR: 0x40ff8000) mmc0: Current OCR: 0x00ff8000 mmc0: Probing cards mmc0: New card detected (CID 0353445345333247800978130301171d) mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3) mmc0: Card at relative address 0xaaaa added: mmc0: card: SDHC SE32G 8.0 SN MFG 07/2017 by 3 SD mmc0: quirks: 0 mmc0: bus: 4bit, 50MHz (high speed timing) mmc0: memory: 62333952 blocks, erase sector 8192 blocks mmc0: setting transfer rate to 50.000MHz (high speed timing) mmcsd0: 32GB MFG 07/2017 by 3 SD> at mmc0 = 50.0MHz/4bit/32768-block random: harvesting attach, 8 bytes (4 bits) from mmcsd0 GEOM: new disk mmcsd0 mmc0: setting bus width to 4 bits high speed timing mmc0: ACMD42 failed, RESULT: 4 mmc0: Card at relative address 43690 failed to set bus width =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 10 06:59:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0B32105F1CB for ; Fri, 10 Aug 2018 06:59:41 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 081E17C560; Fri, 10 Aug 2018 06:59:40 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id efb8ab38; Fri, 10 Aug 2018 08:59:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=p3UypAs2jQqa6buj8eEscj29VsE=; b=Z/vpRn5uizafUUBKigT3W/OdP+8E uxoQu+oOLjwvZdPHtnx3MEafk2OyUdr0KqRGrDo7klxJMryd8RO9WXcr8BNr2+ok yqLsTHnkZ1e1WagK1SgB+oU+1Q968uSQoSLICfWdwDdpCiXOp8igu99CiEe3TqEM 0yRPyJ4drNPK+CQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=gFt7KyA6Dn6XvnJuY+XqrJ0B6kKnTSJBW8Zu84b+iNMD+GEx4vgoB+Lx UtrClfUBXcekH8twY8gX06dCB9bw5cGj/N+AZJIFN7n3x1zeHqZZcFk+hLwuPgOP GcQ259xbu6qwtALnruXwBWDVfGNbYQYVfpAEq4okwRlZdouMVU4= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8fccee04 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 10 Aug 2018 08:59:32 +0200 (CEST) Date: Fri, 10 Aug 2018 08:59:32 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Marius Strobl , Mark Millard via freebsd-arm Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted Message-Id: <20180810085932.248050e3383151efb41c967c@bidouilliste.com> In-Reply-To: <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <20180809220012.GU21523@alchemy.franken.de> <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 06:59:42 -0000 On Thu, 9 Aug 2018 23:39:35 -0700 Mark Millard wrote: > On 2018-Aug-9, at 8:02 PM, Mark Millard wrote: >=20 > > On 2018-Aug-9, at 3:00 PM, Marius Strobl wrote: > >=20 > >> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: > >>> . . . > >>=20 > >> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However, > >> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD > >> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for > >> example figure 3-14 in the SD physical layer specification version > >> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with > >> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was > >> written, Linux didn't support the former either so I saw no point in > >> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR > >> a bit later in January 2017, though). > >> While I have no problem with support for DDR52 at 3.0 V VCCQ being > >> added to mmc(4), I doubt that will solve your problem given that Linux > >> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+ > >> or any other Allwinner gear. Based on what I could figure out about > >> Allwinner MMC controllers, their capabilities actually differ depending > >> on the particular instance of MMC controller of a given SoC (apparentl= y, > >> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO). Yes, the first controller is usually used for SD, second for SDIO and the third for eMMC. I don't know if any of them can be used for any of the function or if they are intended to be used for a specific mode. > >> So I guess what needs to be done is to let aw_mmc(4) announce and > >> support different sets of capabilities depending on which instance of > >> the controller it is driving.=20 That seems the easiest fix. > >> For your adapter this likely means that > >> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD > >> slot complies with the SD physical layer specification if 1.8 V VCCQ > >> isn't supported by the particular board. > >=20 > > Thanks for the notes. > >=20 > > Clearly there is something that I'm missing because: > >=20 > > *) Historically (before the switch to official dts's and such) > > I was able to boot, buildworld, buildkernel, poudreire-devel > > and the like booting from the e.MCC over the sdcard > > adapter plugged into the Pine64+ 2GB's sdcard slot. We always used official DTS for aarch64. What changed recently is that I added DDR52 support to the controller. > > It had been my standard configuration for some time before > > I made the jump to a more modern environment. > >=20 > > As for now: > >=20 > > A) u-boot successfully gets the loader from the e.MCC over the sdcard > > adapter plugged into the Pine64+ 2GB's sdracard slot. > >=20 > > B) The loader successfully loads the kernel from the e.MCC over the > > sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. Loaded use u-boot driver and it only work with HS mode iirc. > > C) The first failure is from the kernel attempting to deal with > > the e.MCC (via the adapter). > >=20 > > I may have read into this (and the messages from boot -v and what > > was said about them) the wrong assumptions about what is wrong. > >=20 > > What I can say is that the issue looks to be specific to the > > FreeBSD kernel but not to the prior loader (nor to u-boot). >=20 > As for the Pine A64+ 2GB specifics . . . >=20 > Quoting pine6.org about the microsd support for Pine A64: >=20 > QUOTE > The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? this= means the largest capacity is 256GB. Please note that if a microSD card is= formatted as an FAT32 file format, the maximum capacity is 32GB. > END QUOTE >=20 > I would expect supporting SDHC and SDXC to mean support for > various 1.8V modes of use: Such required if UHS-I is > supported (UHS50 or UHS104). Also DDR50 is required for > microSD (but not Standard SD). This would seem to match what > the schematics suggest to me (see below). >=20 > I looked and the Power Tree page of the schematics for > the Pine A64+ 2GB at: >=20 > http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%2= 0Rev%20C-20160113_Release.pdf >=20 > and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to > "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page > shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows > VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to > VDD. T-CARD looks to me like the sdcard slot connections. > (Yes: the mix of T-CADD and T-CARD naming is as in the > document.) (I'm not listing the capacitor and such.) VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO, VCC3V3-USB etc .... so it needs to stay at 3.3V >=20 >=20 > For reference, for the e.MCC adaptor for anyone that cares: > (things like "3.3V" are as labeled in those schematics, > whatever the actual voltage of use for some mode of use) >=20 > https://forum.odroid.com/download/file.php?id=3D1036&mode=3Dview >=20 > shows a 49.9K resister in line between 3.3V and RSTN at the > e.MMC end of things. It also shows a 10uF capacitor between > 3.3V and ground on VDD from the micrSD end of things. >=20 > The rest is direct connections. >=20 > But the connections are for using a Hardkernel eMMC module, > in my case V0.3. >=20 > http://forum.odroid.com/download/file.php?id=3D433 >=20 > is for that module. Other than some parallel capacitors to > ground off of VDD and VDDF, and one off of VDDI, it looks > like direct connections there to the e.MMC device as well. >=20 > End "for reference". >=20 >=20 >=20 > The above does not say the the loader and u-boot are using > a 1.8 V mode instead of a 3.3V mode of operation for the > sdcard interface, even if 1.8V is possible. It doesn't, see https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner= /sun50i-a64-pine64.dts#L151 Again, 1.8V is in theory possible, but I wouldn't try that on my boards. > From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be > any of (for 3V): >=20 > Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V > Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltag= e(s)" > Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltag= e(s)" >=20 > that match up with one of the sdcard 3.3V modes: >=20 > UHS-I modes: > DS: Default Speed up to 25 MHz 3.3V signaling > HS: High Speed up to 50 MHz 3.3V signaling > (Looks like the signal timings are distinct from 1.8 V modes.) >=20 > So not bit 2 if 3V, unsure about the other two bits for 3V. >=20 > In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1 > UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does > boot from) the kernel seems to pick the UHS-I HS mode, > instead of SDR50 or DDR50 or higher: Because SDR50 or DDR50 needs 1.8V signaling. So the maximum mode that we can select is HS at 50Mhz which is using 3.3V signaling. > aw_mmc0: mem 0x1c0f000-0x1c0ffff= irq 4 on simplebus0 > aw_mmc0: vmmc-supply regulator found > mmc0: on aw_mmc0 > random: harvesting attach, 8 bytes (4 bits) from mmc0 > random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 > simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled compat a= llwinner,sun50i-a64-mmc (no driver attached) > simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled compat a= llwinner,sun50i-a64-emmc (no driver attached) > . . . > aw_mmc0: Powering up sd/mmc > mmc0: Probing bus > . . . > mmc0: SD 2.0 interface conditions: OK > mmc0: SD probe: OK (OCR: 0x40ff8000) > mmc0: Current OCR: 0x00ff8000 > mmc0: Probing cards > mmc0: New card detected (CID 0353445345333247800978130301171d) > mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3) > mmc0: Card at relative address 0xaaaa added: > mmc0: card: SDHC SE32G 8.0 SN MFG 07/2017 by 3 SD > mmc0: quirks: 0 > mmc0: bus: 4bit, 50MHz (high speed timing) > mmc0: memory: 62333952 blocks, erase sector 8192 blocks > mmc0: setting transfer rate to 50.000MHz (high speed timing) > mmcsd0: 32GB MFG 07/2017 by 3 SD> at mmc0 5= 0.0MHz/4bit/32768-block > random: harvesting attach, 8 bytes (4 bits) from mmcsd0 > GEOM: new disk mmcsd0 > mmc0: setting bus width to 4 bits high speed timing > mmc0: ACMD42 failed, RESULT: 4 > mmc0: Card at relative address 43690 failed to set bus width >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Aug 10 08:10:47 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 262B71061598 for ; Fri, 10 Aug 2018 08:10:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-10.consmr.mail.ne1.yahoo.com (sonic308-10.consmr.mail.ne1.yahoo.com [66.163.187.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7DC47E6DF for ; Fri, 10 Aug 2018 08:10:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: p9xEZY8VM1mQ3yPyUYf94xJjpNL_96F6I6dAk7SwaxV0EI1VqmkSlSHoTyGytcf Nl138o4b_nbPBZ6I9QrFDtJF3RcjwnZwt6ObMdMwbM4pXLrE7_SKXy6OCammNhmQTmhH59oFxmdp gqPeNmUG3TlHlcQ66U5M3qv6zFNb.D4Js_.IdEjYwSH1uuwQ7edYzIVQOmbjuvaPKPnLHOkyKOao 4j4pHsp0VpnsOpT9Cl7JISuH1E10uF.9_gC7brCxW2Q2El0Zgr6KPv5MC__9aR_3RcaxrJwfAc.K omK5ImXPY3ErB1Yt_xkBrdcrtpIdF6e4oVTOq9datsdE50Xzq.WwGyWrgcWCM9tZFaxPycCzusbA 0O.CEcPfumKeeneqeN_yEMlbD6g1J3Zyz8EFhbaPgswWmEgNTlvUixMEWjf3x_l8kU03W72hVOfi vpZoIheRZ39V7luRjT9oxyZi4UhPbgX1gQpg3diniFn_tt_og_icz5FZNHCh72E7K9KFS.0K9KcH fP4HRZVbOyJ0b84aX.D9KsgWPZw09WVx8hrX4o3NDoxWeysxQLJ.z_wPJ6VKsI8p0RPP1mHobiLp jS9reevvX0cSdnpHxqgJWGl8evL44rdPBPrqEywH6kO0AVd7jImWCB08RFku__haxJK2Os4XKPII CIk8EJvLcmePzKZ7nbZKHE_n1g2e6imOsZdwuRqgeKBy6uUBh9USYI7AvAABgvzzECd_vov_2fif 8qaLj_.nREbhsyw_AFe8r7_syuUwXewGieGFvAsDji0xNmPxe7XDGU0yQz2zHWaWgg4.oXxAKB5c xypKoC8UsGhMD75HgtyBWLJq45ce2aJ7wmnvlIWO2NwbttaP0Fg55Y2cSbOZLAtDjdud7qKDAUwH SyTI2lFd45EFO7ElRfjqGuohnhHh9567P4coaOitj3qME0iwYQheaFO71hkcXtnPMfGdK1xVN4YM jU_k1CUv.DAcZGXiBitjVb958MtarbxjGltaP0fqWJ6uLCVoZmxt6y_w3eAHnc.hGgp6Zf3CDBeQ ee9Cb0RALMm35PoodkA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Aug 2018 08:10:44 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 52a5f6a814245449beb1f499505c1e7b; Fri, 10 Aug 2018 08:10:43 +0000 (UTC) From: Mark Millard Message-Id: <0A01DBA9-557A-435D-9CB4-35A7BFA1BAC1@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted Date: Fri, 10 Aug 2018 01:10:41 -0700 In-Reply-To: <20180810085932.248050e3383151efb41c967c@bidouilliste.com> Cc: Marius Strobl , Mark Millard via freebsd-arm To: Emmanuel Vadot References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <20180809220012.GU21523@alchemy.franken.de> <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> <20180810085932.248050e3383151efb41c967c@bidouilliste.com> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 08:10:47 -0000 On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot = wrote: > On Thu, 9 Aug 2018 23:39:35 -0700 > Mark Millard wrote: >=20 >> On 2018-Aug-9, at 8:02 PM, Mark Millard wrote: >>=20 >>> On 2018-Aug-9, at 3:00 PM, Marius Strobl = wrote: >>>=20 >>>> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: >>>>> . . . >>>>=20 >>>> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. = However, >>>> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD >>>> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see = for >>>> example figure 3-14 in the SD physical layer specification version >>>> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible = with >>>> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was >>>> written, Linux didn't support the former either so I saw no point = in >>>> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew = MMC_CAP_3_3V_DDR >>>> a bit later in January 2017, though). >>>> While I have no problem with support for DDR52 at 3.0 V VCCQ being >>>> added to mmc(4), I doubt that will solve your problem given that = Linux >>>> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for = Pine64+ >>>> or any other Allwinner gear. Based on what I could figure out about >>>> Allwinner MMC controllers, their capabilities actually differ = depending >>>> on the particular instance of MMC controller of a given SoC = (apparently, >>>> they are intended for different purposes, i. e. eMMC, eSD, SD, = SDIO). >=20 > Yes, the first controller is usually used for SD, second for SDIO and > the third for eMMC. I don't know if any of them can be used for any of > the function or if they are intended to be used for a specific mode. >=20 >>>> So I guess what needs to be done is to let aw_mmc(4) announce and >>>> support different sets of capabilities depending on which instance = of >>>> the controller it is driving.=20 >=20 > That seems the easiest fix. >=20 >>>> For your adapter this likely means that >>>> high-speed at 3.0 V VCCQ is the achievable maximum so that the = microSD >>>> slot complies with the SD physical layer specification if 1.8 V = VCCQ >>>> isn't supported by the particular board. >>>=20 >>> Thanks for the notes. >>>=20 >>> Clearly there is something that I'm missing because: >>>=20 >>> *) Historically (before the switch to official dts's and such) >>> I was able to boot, buildworld, buildkernel, poudreire-devel >>> and the like booting from the e.MCC over the sdcard >>> adapter plugged into the Pine64+ 2GB's sdcard slot. >=20 > We always used official DTS for aarch64. > What changed recently is that I added DDR52 support to the controller. My quick attempt at identifying the history point was poor. It looks like I should have referenced before and during the ccu-ng switch, before and during the USB being temporarily unsupported in the similar time frame. I held back to materials that allowed USB use and did not update past that until just recently. (This is still just a = summary, not the full history of my builds based on the older materials in this = area. But it should be good enough.) >>> It had been my standard configuration for some time before >>> I made the jump to a more modern environment. >>>=20 >>> As for now: >>>=20 >>> A) u-boot successfully gets the loader from the e.MCC over the = sdcard >>> adapter plugged into the Pine64+ 2GB's sdracard slot. >>>=20 >>> B) The loader successfully loads the kernel from the e.MCC over the >>> sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. >=20 > Loaded use u-boot driver and it only work with HS mode iirc. Sounds likely. Good to know. Thanks. >>> C) The first failure is from the kernel attempting to deal with >>> the e.MCC (via the adapter). >>>=20 >>> I may have read into this (and the messages from boot -v and what >>> was said about them) the wrong assumptions about what is wrong. >>>=20 >>> What I can say is that the issue looks to be specific to the >>> FreeBSD kernel but not to the prior loader (nor to u-boot). >>=20 >> As for the Pine A64+ 2GB specifics . . . >>=20 >> Quoting pine6.org about the microsd support for Pine A64: >>=20 >> QUOTE >> The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? = this means the largest capacity is 256GB. Please note that if a microSD = card is formatted as an FAT32 file format, the maximum capacity is 32GB. >> END QUOTE >>=20 >> I would expect supporting SDHC and SDXC to mean support for >> various 1.8V modes of use: Such required if UHS-I is >> supported (UHS50 or UHS104). Also DDR50 is required for >> microSD (but not Standard SD). This would seem to match what >> the schematics suggest to me (see below). >>=20 >> I looked and the Power Tree page of the schematics for >> the Pine A64+ 2GB at: >>=20 >> = http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20= Rev%20C-20160113_Release.pdf >>=20 >> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to >> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page >> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows >> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to >> VDD. T-CARD looks to me like the sdcard slot connections. >> (Yes: the mix of T-CADD and T-CARD naming is as in the >> document.) (I'm not listing the capacitor and such.) >=20 > VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO, > VCC3V3-USB etc .... so it needs to stay at 3.3V Ahh, I see. All the control of such is at DC/DC1 and the rest follow together. >>=20 >>=20 >> For reference, for the e.MCC adaptor for anyone that cares: >> (things like "3.3V" are as labeled in those schematics, >> whatever the actual voltage of use for some mode of use) >>=20 >> https://forum.odroid.com/download/file.php?id=3D1036&mode=3Dview >>=20 >> shows a 49.9K resister in line between 3.3V and RSTN at the >> e.MMC end of things. It also shows a 10uF capacitor between >> 3.3V and ground on VDD from the micrSD end of things. >>=20 >> The rest is direct connections. >>=20 >> But the connections are for using a Hardkernel eMMC module, >> in my case V0.3. >>=20 >> http://forum.odroid.com/download/file.php?id=3D433 >>=20 >> is for that module. Other than some parallel capacitors to >> ground off of VDD and VDDF, and one off of VDDI, it looks >> like direct connections there to the e.MMC device as well. >>=20 >> End "for reference". >>=20 >>=20 >>=20 >> The above does not say the the loader and u-boot are using >> a 1.8 V mode instead of a 3.3V mode of operation for the >> sdcard interface, even if 1.8V is possible. >=20 > It doesn't, see > = https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinne= r/sun50i-a64-pine64.dts#L151 >=20 > Again, 1.8V is in theory possible, but I wouldn't try that on my > boards. So it looks like if the e.MMC on an adapter card were to be supported, it would be via Bit 1 or Bit 0 below, much like u-boot is apparently doing. >> =46rom an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be >> any of (for 3V): >>=20 >> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V >> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device = voltage(s)" >> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device = voltage(s)" >>=20 >> that match up with one of the sdcard 3.3V modes: >>=20 >> UHS-I modes: >> DS: Default Speed up to 25 MHz 3.3V signaling >> HS: High Speed up to 50 MHz 3.3V signaling >> (Looks like the signal timings are distinct from 1.8 V modes.) >>=20 >> So not bit 2 if 3V, unsure about the other two bits for 3V. >>=20 >> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1 >> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does >> boot from) the kernel seems to pick the UHS-I HS mode, >> instead of SDR50 or DDR50 or higher: >=20 > Because SDR50 or DDR50 needs 1.8V signaling. > So the maximum mode that we can select is HS at 50Mhz which is > using 3.3V signaling. Okay. It would be nice if the e.MMC on an sdcard adapter also did so someday, somewhat like u-boot apparently does (up to clock rate differences?). Even going slower, I'd prefer e.MMC media. >> aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 >> aw_mmc0: vmmc-supply regulator found >> mmc0: on aw_mmc0 >> random: harvesting attach, 8 bytes (4 bits) from mmc0 >> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 >> simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled = compat allwinner,sun50i-a64-mmc (no driver attached) >> simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled = compat allwinner,sun50i-a64-emmc (no driver attached) >> . . . >> aw_mmc0: Powering up sd/mmc >> mmc0: Probing bus >> . . . >> mmc0: SD 2.0 interface conditions: OK >> mmc0: SD probe: OK (OCR: 0x40ff8000) >> mmc0: Current OCR: 0x00ff8000 >> mmc0: Probing cards >> mmc0: New card detected (CID 0353445345333247800978130301171d) >> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3) >> mmc0: Card at relative address 0xaaaa added: >> mmc0: card: SDHC SE32G 8.0 SN MFG 07/2017 by 3 SD >> mmc0: quirks: 0 >> mmc0: bus: 4bit, 50MHz (high speed timing) >> mmc0: memory: 62333952 blocks, erase sector 8192 blocks >> mmc0: setting transfer rate to 50.000MHz (high speed timing) >> mmcsd0: 32GB MFG 07/2017 by 3 SD> at = mmc0 50.0MHz/4bit/32768-block >> random: harvesting attach, 8 bytes (4 bits) from mmcsd0 >> GEOM: new disk mmcsd0 >> mmc0: setting bus width to 4 bits high speed timing >> mmc0: ACMD42 failed, RESULT: 4 >> mmc0: Card at relative address 43690 failed to set bus width >>=20 >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 10 10:53:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79D6010666EC for ; Fri, 10 Aug 2018 10:53:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-21.consmr.mail.ne1.yahoo.com (sonic312-21.consmr.mail.ne1.yahoo.com [66.163.191.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 047E48509F for ; Fri, 10 Aug 2018 10:53:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: v1PEG9kVM1nckp.vlzpIjv6W6a7YP1BK5ZRclPLAMQex8mq4nGNkQo_1qAxtPjr t0SCoRk1NDP6lZ_nq1Igo56R1MVeMro14hgGeSYczmnm76C0W4DDUBrhhrQIf3lrg5P7Hkobs5Za T4JuJ_JqWuzezgoh836ywpNhqNHOgfShg2sGNE0nIJQjwcsVleDh47dkimUzAOCMRJ7j7CZc.GEh IEEIHGW33rrDzwLkKEPPoioGwvGpTu0kX7I9pxOhWKQtWRilHF17IzEsPtx8lzbzEKv4HR3e09C5 U6g51ezZ_fH9R.YeKwAgDKWmU3S9sDKxBCR._nI9DMyjLKxvf1saa2mn9piFd4z6cyu9pAhq0ew_ WaKVGk5nt.qEv5KC50E2L9G_C9uf4PwQcKVwzZQNBpyDz7oTejU47kCIJxso9aPY4.aywoY9ZlHN KqhEo08wpqImaynpAm_ImLr1ieb0SoEawx4jgFqtqLBgRa2BKb_hWVjrHeFIub0UMjMP0kdaXt53 GmtFEypMOOvZhQWtU_MdnOLZczaktCexhQODWQguXpJS7mTy2C8mgPDazXJ97EpFGCZZJz8nWq5y 7m4r6C9q85LWCgMk2s4Jcq1D9kRWnFrge3OuPzZ03CZSWvhnHbD8YW0vhZ66n9gIxzZ24ryz6N_z _6Al37nUM0my1YbpE84K1Mqqtzs7u8li4J04XKpFp4XRAsifNaSVUM0AyNLQFutUNWfqqiwB0yRA rtsnVPthAXpyI3LaAjez8x4jw0Tk3nIsqKdi0ta5.42NHBrpHrk5E57GT2Xay5NZg3JXsGemx2qp 29om4IwN9M_LTRs_RQtbmXFP583ykcelzRm0AaZ1hrSV2TU1NLkfbut4nXoBR34Ik4HXLu0NlxGh feOWt1xIQFs.8kfPvbAKgg0xNefE3PDpLLVM8L5sBSJNJcM2mLFYDlgdJKlnI9vkaGvdVD0I3ioF P3.0kDz7x.C7KqeXCwqDabJWYf.iQZHZcx2Na7D8QpeluG9I9qtg4XcQ2bt_BmCf8B3TjohrrNuB muLjEhVZ9cOZlpmSeipFy7b9X5O2PaIqyHwXmbyyM_EUnOFN8VwNnzxJUbdn361F2Cnk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Aug 2018 10:53:56 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp430.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cbd3a256f76476b85e2d73fc61c19ec5; Fri, 10 Aug 2018 10:53:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <0A01DBA9-557A-435D-9CB4-35A7BFA1BAC1@yahoo.com> Date: Fri, 10 Aug 2018 03:53:49 -0700 Cc: Mark Millard via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <20180809220012.GU21523@alchemy.franken.de> <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> <20180810085932.248050e3383151efb41c967c@bidouilliste.com> <0A01DBA9-557A-435D-9CB4-35A7BFA1BAC1@yahoo.com> To: Emmanuel Vadot , Marius Strobl X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 10:53:58 -0000 [A note about linux booting is added.] On 2018-Aug-10, at 1:10 AM, Mark Millard wrote: > On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot = wrote: >=20 >> On Thu, 9 Aug 2018 23:39:35 -0700 >> Mark Millard wrote: >>=20 >>> On 2018-Aug-9, at 8:02 PM, Mark Millard = wrote: >>>=20 >>>> On 2018-Aug-9, at 3:00 PM, Marius Strobl = wrote: >>>>=20 >>>>> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: >>>>>> . . . >>>>>=20 >>>>> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. = However, >>>>> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to = SD >>>>> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see = for >>>>> example figure 3-14 in the SD physical layer specification version >>>>> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible = with >>>>> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD = was >>>>> written, Linux didn't support the former either so I saw no point = in >>>>> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew = MMC_CAP_3_3V_DDR >>>>> a bit later in January 2017, though). >>>>> While I have no problem with support for DDR52 at 3.0 V VCCQ being >>>>> added to mmc(4), I doubt that will solve your problem given that = Linux >>>>> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for = Pine64+ >>>>> or any other Allwinner gear. Based on what I could figure out = about >>>>> Allwinner MMC controllers, their capabilities actually differ = depending >>>>> on the particular instance of MMC controller of a given SoC = (apparently, >>>>> they are intended for different purposes, i. e. eMMC, eSD, SD, = SDIO). >>=20 >> Yes, the first controller is usually used for SD, second for SDIO and >> the third for eMMC. I don't know if any of them can be used for any = of >> the function or if they are intended to be used for a specific mode. >>=20 >>>>> So I guess what needs to be done is to let aw_mmc(4) announce and >>>>> support different sets of capabilities depending on which instance = of >>>>> the controller it is driving.=20 >>=20 >> That seems the easiest fix. >>=20 >>>>> For your adapter this likely means that >>>>> high-speed at 3.0 V VCCQ is the achievable maximum so that the = microSD >>>>> slot complies with the SD physical layer specification if 1.8 V = VCCQ >>>>> isn't supported by the particular board. >>>>=20 >>>> Thanks for the notes. >>>>=20 >>>> Clearly there is something that I'm missing because: >>>>=20 >>>> *) Historically (before the switch to official dts's and such) >>>> I was able to boot, buildworld, buildkernel, poudreire-devel >>>> and the like booting from the e.MCC over the sdcard >>>> adapter plugged into the Pine64+ 2GB's sdcard slot. >>=20 >> We always used official DTS for aarch64. >> What changed recently is that I added DDR52 support to the = controller. >=20 > My quick attempt at identifying the history point was poor. It > looks like I should have referenced before and during the ccu-ng = switch, > before and during the USB being temporarily unsupported in the > similar time frame. I held back to materials that allowed USB use and > did not update past that until just recently. (This is still just a = summary, > not the full history of my builds based on the older materials in this = area. > But it should be good enough.) >=20 >>>> It had been my standard configuration for some time before >>>> I made the jump to a more modern environment. >>>>=20 >>>> As for now: >>>>=20 >>>> A) u-boot successfully gets the loader from the e.MCC over the = sdcard >>>> adapter plugged into the Pine64+ 2GB's sdracard slot. >>>>=20 >>>> B) The loader successfully loads the kernel from the e.MCC over the >>>> sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. >>=20 >> Loaded use u-boot driver and it only work with HS mode iirc. >=20 > Sounds likely. Good to know. Thanks. >=20 >>>> C) The first failure is from the kernel attempting to deal with >>>> the e.MCC (via the adapter). >>>>=20 >>>> I may have read into this (and the messages from boot -v and what >>>> was said about them) the wrong assumptions about what is wrong. >>>>=20 >>>> What I can say is that the issue looks to be specific to the >>>> FreeBSD kernel but not to the prior loader (nor to u-boot). >>>=20 >>> As for the Pine A64+ 2GB specifics . . . >>>=20 >>> Quoting pine6.org about the microsd support for Pine A64: >>>=20 >>> QUOTE >>> The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? = this means the largest capacity is 256GB. Please note that if a microSD = card is formatted as an FAT32 file format, the maximum capacity is 32GB. >>> END QUOTE >>>=20 >>> I would expect supporting SDHC and SDXC to mean support for >>> various 1.8V modes of use: Such required if UHS-I is >>> supported (UHS50 or UHS104). Also DDR50 is required for >>> microSD (but not Standard SD). This would seem to match what >>> the schematics suggest to me (see below). >>>=20 >>> I looked and the Power Tree page of the schematics for >>> the Pine A64+ 2GB at: >>>=20 >>> = http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20= Rev%20C-20160113_Release.pdf >>>=20 >>> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to >>> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page >>> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows >>> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to >>> VDD. T-CARD looks to me like the sdcard slot connections. >>> (Yes: the mix of T-CADD and T-CARD naming is as in the >>> document.) (I'm not listing the capacitor and such.) >>=20 >> VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO, >> VCC3V3-USB etc .... so it needs to stay at 3.3V >=20 > Ahh, I see. All the control of such is at DC/DC1 and the rest follow > together. >=20 >>>=20 >>>=20 >>> For reference, for the e.MCC adaptor for anyone that cares: >>> (things like "3.3V" are as labeled in those schematics, >>> whatever the actual voltage of use for some mode of use) >>>=20 >>> https://forum.odroid.com/download/file.php?id=3D1036&mode=3Dview >>>=20 >>> shows a 49.9K resister in line between 3.3V and RSTN at the >>> e.MMC end of things. It also shows a 10uF capacitor between >>> 3.3V and ground on VDD from the micrSD end of things. >>>=20 >>> The rest is direct connections. >>>=20 >>> But the connections are for using a Hardkernel eMMC module, >>> in my case V0.3. >>>=20 >>> http://forum.odroid.com/download/file.php?id=3D433 >>>=20 >>> is for that module. Other than some parallel capacitors to >>> ground off of VDD and VDDF, and one off of VDDI, it looks >>> like direct connections there to the e.MMC device as well. >>>=20 >>> End "for reference". >>>=20 >>>=20 >>>=20 >>> The above does not say the the loader and u-boot are using >>> a 1.8 V mode instead of a 3.3V mode of operation for the >>> sdcard interface, even if 1.8V is possible. >>=20 >> It doesn't, see >> = https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinne= r/sun50i-a64-pine64.dts#L151 >>=20 >> Again, 1.8V is in theory possible, but I wouldn't try that on my >> boards. >=20 > So it looks like if the e.MMC on an adapter card were to be supported, > it would be via Bit 1 or Bit 0 below, much like u-boot is apparently > doing. >=20 >>> =46rom an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be >>> any of (for 3V): >>>=20 >>> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V >>> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device = voltage(s)" >>> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device = voltage(s)" >>>=20 >>> that match up with one of the sdcard 3.3V modes: >>>=20 >>> UHS-I modes: >>> DS: Default Speed up to 25 MHz 3.3V signaling >>> HS: High Speed up to 50 MHz 3.3V signaling >>> (Looks like the signal timings are distinct from 1.8 V modes.) >>>=20 >>> So not bit 2 if 3V, unsure about the other two bits for 3V. >>>=20 >>> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1 >>> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does >>> boot from) the kernel seems to pick the UHS-I HS mode, >>> instead of SDR50 or DDR50 or higher: >>=20 >> Because SDR50 or DDR50 needs 1.8V signaling. >> So the maximum mode that we can select is HS at 50Mhz which is >> using 3.3V signaling. >=20 > Okay. It would be nice if the e.MMC on an sdcard adapter also did so > someday, somewhat like u-boot apparently does (up to clock rate > differences?). Even going slower, I'd prefer e.MMC media. >=20 >>> aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 >>> aw_mmc0: vmmc-supply regulator found >>> mmc0: on aw_mmc0 >>> random: harvesting attach, 8 bytes (4 bits) from mmc0 >>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 >>> simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled = compat allwinner,sun50i-a64-mmc (no driver attached) >>> simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled = compat allwinner,sun50i-a64-emmc (no driver attached) >>> . . . >>> aw_mmc0: Powering up sd/mmc >>> mmc0: Probing bus >>> . . . >>> mmc0: SD 2.0 interface conditions: OK >>> mmc0: SD probe: OK (OCR: 0x40ff8000) >>> mmc0: Current OCR: 0x00ff8000 >>> mmc0: Probing cards >>> mmc0: New card detected (CID 0353445345333247800978130301171d) >>> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3) >>> mmc0: Card at relative address 0xaaaa added: >>> mmc0: card: SDHC SE32G 8.0 SN MFG 07/2017 by 3 SD >>> mmc0: quirks: 0 >>> mmc0: bus: 4bit, 50MHz (high speed timing) >>> mmc0: memory: 62333952 blocks, erase sector 8192 blocks >>> mmc0: setting transfer rate to 50.000MHz (high speed timing) >>> mmcsd0: 32GB MFG 07/2017 by 3 SD> at = mmc0 50.0MHz/4bit/32768-block >>> random: harvesting attach, 8 bytes (4 bits) from mmcsd0 >>> GEOM: new disk mmcsd0 >>> mmc0: setting bus width to 4 bits high speed timing >>> mmc0: ACMD42 failed, RESULT: 4 >>> mmc0: Card at relative address 43690 failed to set bus width >>>=20 >>>=20 >=20 Just to see what a modern linux with a modern kernel might do I downloaded: https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z which is: nightly mainline kernel master branch 4.17.y or 4.18.y # uname -ap Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 = aarch64 aarch64 aarch64 GNU/Linux I put it on an e.MMC and used it to boot the pine64+ 2GB via the e.MMC adapter and it booted fine. # cat /sys/kernel/debug/mmc0/ios clock: 52000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 8 (mmc DDR52) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) # hdparm -t /dev/mmcblk0 /dev/mmcblk0: Timing buffered disk reads: 134 MB in 3.04 seconds =3D 44.03 MB/sec # hdparm -T /dev/mmcblk0 /dev/mmcblk0: Timing cached reads: 1298 MB in 2.00 seconds =3D 649.15 MB/sec For interpreting those (-t vs. -T): QUOTE -t Perform timings of device reads for benchmark and = comparison purposes. For meaningful results, this operation should be = repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes = of free memory. This displays the speed of reading through the buffer = cache to the disk without any prior caching of data. This measurement is an indication of how fast the drive = can sustain sequential data reads under Linux, without any filesystem = overhead. To ensure accurate measurements, the buffer cache is flushed during the processing of -t using the = BLKFLSBUF ioctl. -T Perform timings of cache reads for benchmark and = comparison purposes. For meaningful results, this operation should be = repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of = free memory. This displays the speed of reading directly from the Linux = buffer cache without disk access. This measurement is essentially an indication of the throughput of the = processor, cache, and memory of the system under test. END QUOTE So it appears to me that the DDR52 over 4 data bits is real, despite the apparent 3.3V usage for VCCQ (and so VCC as well). In other words: they are using e.MCC CARD_TYPE/DEVICE_TYPE bit 2: Bit 2: High-speed DDR MultimediaCard @ (at most) 52 MHz - 1.8aV or 3V = I/O and were not restricted to just the microSDHC speed and I/O voltage combinations by the Pine64+ 2GB. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 10 11:45:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CCD11067C15 for ; Fri, 10 Aug 2018 11:45:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 181C286828 for ; Fri, 10 Aug 2018 11:45:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: fbNKOVMVM1kDDfgwDi8dm.mSCXWZZX6OiXvJb6.6DNJ4BMRtEo5Ea84dRawgJL_ vnf9iK2wds8a.pJ_xKP8.Lu6CZDa6EIjDT2l1jfWBwlWg9.i9ZK.o1ppT8YBnntU0IyQKSt8ARZP 3dqdeYYqc7q8GsqnhDuLY4fac94Hsymr_Dy45DIlGrf2Ramnsf0kQgsShos2VgxLR1CGbuS7dS4M XbSyn4fvurfFOGlyfUdQDiNxmRJfM4EOaW3xP5oZbVrfhpkjqr_EYqdhai5H9NYxZ.t8h.EDPUX. AL2AndX2nRDjgNLC3NFCYMV94IM2FlvmPSsdGYCLUhBClBTeIY7mZDVbQdiVV1107d2tjz57ywXK NuzDCmzn4cDnTHmSHP8AeC0YdcXG6baOfVycBLFB9.WOMF94tNGMVwNe2K1WhiSRZnS0KY99Qlm1 YVzNyzpjqlaxGTXWRqhlje99703gImbySKBuncLVV1hvxDWqgn743j9O7H2J1P740lKaW98brpYZ 2DotY4uqaT7DgSMpHIa7Iz9RYuwBJcsG7Owh4ZdAPNAUvbNtXJ1F2ij7nBAEH882_rMZ4YdJ4wsC JLSLMGzLEzE_Xnwy_hiCXREhslEm6NUGHgzwW7z3pOvXAF2tKX..xmeIJj75UVejrw8nsWXgkiNL zDUwL6plSSrC6VG4dETRyZXk8edxLBQzbZvYD6R59BdKIQg.zcSuIKIxAKHBo0pMbg4iMzTwV4y. .bucaWQ5M6v3G7Tgi1LVHUleM1XBq1rRo.5NpBVlKxb561xjY22t.4P41xlbgPG7LfKa..cOqtYy 2u1LeZb0h.q461YBX2InJDbLFdniGSSQbJ2D_gH7dIYmK05od721tuZIJqoxLRgM1C2p_DcxyFyw Uk13bezqVcvheQDZcyrsj0TeqGLgaqouE7EUBNxAO3cWB5Y3MlpOZDIhzNTUB1K4RiyeGOogXzZm XawK_fDEpsUUfdD.gnjKX.VwPqhnKC6dGTprA5xS50ZKDeKU1RZwiMMN9xzsolRXpn_cHv.YU35E KLL.CThEV8x4LeF9ET8plB2ksXU4FLN4GeAi1wwLyOFqLPuyHjqQ8fVUn2gg6VViHkfbDnA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Fri, 10 Aug 2018 11:45:41 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID da662688d6a7ad98ae938bb90f7f2948; Fri, 10 Aug 2018 11:45:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: Date: Fri, 10 Aug 2018 04:45:36 -0700 Cc: Mark Millard via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <33AFF697-FB1E-4349-93C7-888C184CBBD4@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <20180809220012.GU21523@alchemy.franken.de> <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> <20180810085932.248050e3383151efb41c967c@bidouilliste.com> <0A01DBA9-557A-435D-9CB4-35A7BFA1BAC1@yahoo.com> To: Emmanuel Vadot , Marius Strobl X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 11:45:42 -0000 [A note about CARD_TYPE/DEVICE_TYPE is added.] On 2018-Aug-10, at 3:53 AM, Mark Millard wrote: > [A note about linux booting is added.] >=20 > On 2018-Aug-10, at 1:10 AM, Mark Millard wrote: >=20 >> On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot = wrote: >>=20 >>> On Thu, 9 Aug 2018 23:39:35 -0700 >>> Mark Millard wrote: >>>=20 >>>> On 2018-Aug-9, at 8:02 PM, Mark Millard = wrote: >>>>=20 >>>>> On 2018-Aug-9, at 3:00 PM, Marius Strobl = wrote: >>>>>=20 >>>>>> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: >>>>>>> . . . >>>>>>=20 >>>>>> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. = However, >>>>>> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to = SD >>>>>> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see = for >>>>>> example figure 3-14 in the SD physical layer specification = version >>>>>> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible = with >>>>>> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD = was >>>>>> written, Linux didn't support the former either so I saw no point = in >>>>>> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew = MMC_CAP_3_3V_DDR >>>>>> a bit later in January 2017, though). >>>>>> While I have no problem with support for DDR52 at 3.0 V VCCQ = being >>>>>> added to mmc(4), I doubt that will solve your problem given that = Linux >>>>>> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for = Pine64+ >>>>>> or any other Allwinner gear. Based on what I could figure out = about >>>>>> Allwinner MMC controllers, their capabilities actually differ = depending >>>>>> on the particular instance of MMC controller of a given SoC = (apparently, >>>>>> they are intended for different purposes, i. e. eMMC, eSD, SD, = SDIO). >>>=20 >>> Yes, the first controller is usually used for SD, second for SDIO = and >>> the third for eMMC. I don't know if any of them can be used for any = of >>> the function or if they are intended to be used for a specific mode. >>>=20 >>>>>> So I guess what needs to be done is to let aw_mmc(4) announce and >>>>>> support different sets of capabilities depending on which = instance of >>>>>> the controller it is driving.=20 >>>=20 >>> That seems the easiest fix. >>>=20 >>>>>> For your adapter this likely means that >>>>>> high-speed at 3.0 V VCCQ is the achievable maximum so that the = microSD >>>>>> slot complies with the SD physical layer specification if 1.8 V = VCCQ >>>>>> isn't supported by the particular board. >>>>>=20 >>>>> Thanks for the notes. >>>>>=20 >>>>> Clearly there is something that I'm missing because: >>>>>=20 >>>>> *) Historically (before the switch to official dts's and such) >>>>> I was able to boot, buildworld, buildkernel, poudreire-devel >>>>> and the like booting from the e.MCC over the sdcard >>>>> adapter plugged into the Pine64+ 2GB's sdcard slot. >>>=20 >>> We always used official DTS for aarch64. >>> What changed recently is that I added DDR52 support to the = controller. >>=20 >> My quick attempt at identifying the history point was poor. It >> looks like I should have referenced before and during the ccu-ng = switch, >> before and during the USB being temporarily unsupported in the >> similar time frame. I held back to materials that allowed USB use and >> did not update past that until just recently. (This is still just a = summary, >> not the full history of my builds based on the older materials in = this area. >> But it should be good enough.) >>=20 >>>>> It had been my standard configuration for some time before >>>>> I made the jump to a more modern environment. >>>>>=20 >>>>> As for now: >>>>>=20 >>>>> A) u-boot successfully gets the loader from the e.MCC over the = sdcard >>>>> adapter plugged into the Pine64+ 2GB's sdracard slot. >>>>>=20 >>>>> B) The loader successfully loads the kernel from the e.MCC over = the >>>>> sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. >>>=20 >>> Loaded use u-boot driver and it only work with HS mode iirc. >>=20 >> Sounds likely. Good to know. Thanks. >>=20 >>>>> C) The first failure is from the kernel attempting to deal with >>>>> the e.MCC (via the adapter). >>>>>=20 >>>>> I may have read into this (and the messages from boot -v and what >>>>> was said about them) the wrong assumptions about what is wrong. >>>>>=20 >>>>> What I can say is that the issue looks to be specific to the >>>>> FreeBSD kernel but not to the prior loader (nor to u-boot). >>>>=20 >>>> As for the Pine A64+ 2GB specifics . . . >>>>=20 >>>> Quoting pine6.org about the microsd support for Pine A64: >>>>=20 >>>> QUOTE >>>> The Pine A64 board supports SD, SDHC, and SDXC format microSD card = ? this means the largest capacity is 256GB. Please note that if a = microSD card is formatted as an FAT32 file format, the maximum capacity = is 32GB. >>>> END QUOTE >>>>=20 >>>> I would expect supporting SDHC and SDXC to mean support for >>>> various 1.8V modes of use: Such required if UHS-I is >>>> supported (UHS50 or UHS104). Also DDR50 is required for >>>> microSD (but not Standard SD). This would seem to match what >>>> the schematics suggest to me (see below). >>>>=20 >>>> I looked and the Power Tree page of the schematics for >>>> the Pine A64+ 2GB at: >>>>=20 >>>> = http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20= Rev%20C-20160113_Release.pdf >>>>=20 >>>> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to >>>> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page >>>> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows >>>> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to >>>> VDD. T-CARD looks to me like the sdcard slot connections. >>>> (Yes: the mix of T-CADD and T-CARD naming is as in the >>>> document.) (I'm not listing the capacitor and such.) >>>=20 >>> VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO, >>> VCC3V3-USB etc .... so it needs to stay at 3.3V >>=20 >> Ahh, I see. All the control of such is at DC/DC1 and the rest follow >> together. >>=20 >>>>=20 >>>>=20 >>>> For reference, for the e.MCC adaptor for anyone that cares: >>>> (things like "3.3V" are as labeled in those schematics, >>>> whatever the actual voltage of use for some mode of use) >>>>=20 >>>> https://forum.odroid.com/download/file.php?id=3D1036&mode=3Dview >>>>=20 >>>> shows a 49.9K resister in line between 3.3V and RSTN at the >>>> e.MMC end of things. It also shows a 10uF capacitor between >>>> 3.3V and ground on VDD from the micrSD end of things. >>>>=20 >>>> The rest is direct connections. >>>>=20 >>>> But the connections are for using a Hardkernel eMMC module, >>>> in my case V0.3. >>>>=20 >>>> http://forum.odroid.com/download/file.php?id=3D433 >>>>=20 >>>> is for that module. Other than some parallel capacitors to >>>> ground off of VDD and VDDF, and one off of VDDI, it looks >>>> like direct connections there to the e.MMC device as well. >>>>=20 >>>> End "for reference". >>>>=20 >>>>=20 >>>>=20 >>>> The above does not say the the loader and u-boot are using >>>> a 1.8 V mode instead of a 3.3V mode of operation for the >>>> sdcard interface, even if 1.8V is possible. >>>=20 >>> It doesn't, see >>> = https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinne= r/sun50i-a64-pine64.dts#L151 >>>=20 >>> Again, 1.8V is in theory possible, but I wouldn't try that on my >>> boards. >>=20 >> So it looks like if the e.MMC on an adapter card were to be = supported, >> it would be via Bit 1 or Bit 0 below, much like u-boot is apparently >> doing. >>=20 >>>> =46rom an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be >>>> any of (for 3V): >>>>=20 >>>> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V >>>> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device = voltage(s)" >>>> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device = voltage(s)" >>>>=20 >>>> that match up with one of the sdcard 3.3V modes: >>>>=20 >>>> UHS-I modes: >>>> DS: Default Speed up to 25 MHz 3.3V signaling >>>> HS: High Speed up to 50 MHz 3.3V signaling >>>> (Looks like the signal timings are distinct from 1.8 V modes.) >>>>=20 >>>> So not bit 2 if 3V, unsure about the other two bits for 3V. >>>>=20 >>>> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1 >>>> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does >>>> boot from) the kernel seems to pick the UHS-I HS mode, >>>> instead of SDR50 or DDR50 or higher: >>>=20 >>> Because SDR50 or DDR50 needs 1.8V signaling. >>> So the maximum mode that we can select is HS at 50Mhz which is >>> using 3.3V signaling. >>=20 >> Okay. It would be nice if the e.MMC on an sdcard adapter also did so >> someday, somewhat like u-boot apparently does (up to clock rate >> differences?). Even going slower, I'd prefer e.MMC media. >>=20 >>>> aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 4 on simplebus0 >>>> aw_mmc0: vmmc-supply regulator found >>>> mmc0: on aw_mmc0 >>>> random: harvesting attach, 8 bytes (4 bits) from mmc0 >>>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 >>>> simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled = compat allwinner,sun50i-a64-mmc (no driver attached) >>>> simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled = compat allwinner,sun50i-a64-emmc (no driver attached) >>>> . . . >>>> aw_mmc0: Powering up sd/mmc >>>> mmc0: Probing bus >>>> . . . >>>> mmc0: SD 2.0 interface conditions: OK >>>> mmc0: SD probe: OK (OCR: 0x40ff8000) >>>> mmc0: Current OCR: 0x00ff8000 >>>> mmc0: Probing cards >>>> mmc0: New card detected (CID 0353445345333247800978130301171d) >>>> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3) >>>> mmc0: Card at relative address 0xaaaa added: >>>> mmc0: card: SDHC SE32G 8.0 SN MFG 07/2017 by 3 SD >>>> mmc0: quirks: 0 >>>> mmc0: bus: 4bit, 50MHz (high speed timing) >>>> mmc0: memory: 62333952 blocks, erase sector 8192 blocks >>>> mmc0: setting transfer rate to 50.000MHz (high speed timing) >>>> mmcsd0: 32GB MFG 07/2017 by 3 SD> at = mmc0 50.0MHz/4bit/32768-block >>>> random: harvesting attach, 8 bytes (4 bits) from mmcsd0 >>>> GEOM: new disk mmcsd0 >>>> mmc0: setting bus width to 4 bits high speed timing >>>> mmc0: ACMD42 failed, RESULT: 4 >>>> mmc0: Card at relative address 43690 failed to set bus width >>>>=20 >>>>=20 >>=20 >=20 >=20 > Just to see what a modern linux with a modern kernel > might do I downloaded: >=20 > https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z >=20 > which is: >=20 > nightly mainline kernel master branch 4.17.y or 4.18.y >=20 > # uname -ap > Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 = aarch64 aarch64 aarch64 GNU/Linux >=20 > I put it on an e.MMC and used it to boot the pine64+ 2GB > via the e.MMC adapter and it booted fine. >=20 > # cat /sys/kernel/debug/mmc0/ios > clock: 52000000 Hz > actual clock: 50000000 Hz > vdd: 21 (3.3 ~ 3.4 V) > bus mode: 2 (push-pull) > chip select: 0 (don't care) > power mode: 2 (on) > bus width: 2 (4 bits) > timing spec: 8 (mmc DDR52) > signal voltage: 0 (3.30 V) > driver type: 0 (driver type B) >=20 > # hdparm -t /dev/mmcblk0 >=20 > /dev/mmcblk0: > Timing buffered disk reads: 134 MB in 3.04 seconds =3D 44.03 MB/sec >=20 > # hdparm -T /dev/mmcblk0 >=20 > /dev/mmcblk0: > Timing cached reads: 1298 MB in 2.00 seconds =3D 649.15 MB/sec >=20 > For interpreting those (-t vs. -T): >=20 > QUOTE > -t Perform timings of device reads for benchmark and = comparison purposes. For meaningful results, this operation should be = repeated 2-3 times on an otherwise inactive system (no other > active processes) with at least a couple of megabytes = of free memory. This displays the speed of reading through the buffer = cache to the disk without any prior caching of data. > This measurement is an indication of how fast the drive = can sustain sequential data reads under Linux, without any filesystem = overhead. To ensure accurate measurements, the buffer > cache is flushed during the processing of -t using the = BLKFLSBUF ioctl. >=20 > -T Perform timings of cache reads for benchmark and = comparison purposes. For meaningful results, this operation should be = repeated 2-3 times on an otherwise inactive system (no other > active processes) with at least a couple of megabytes of = free memory. This displays the speed of reading directly from the Linux = buffer cache without disk access. This measurement > is essentially an indication of the throughput of the = processor, cache, and memory of the system under test. > END QUOTE >=20 > So it appears to me that the DDR52 over 4 data bits is real, > despite the apparent 3.3V usage for VCCQ (and so VCC as well). >=20 > In other words: they are using e.MCC CARD_TYPE/DEVICE_TYPE bit 2: >=20 > Bit 2: High-speed DDR MultimediaCard @ (at most) 52 MHz - 1.8aV or 3V = I/O >=20 > and were not restricted to just the microSDHC speed and I/O voltage > combinations by the Pine64+ 2GB. I discovered another command: # mmc extcsd read /dev/mmcblk0 | more =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 Extended CSD rev 1.8 (MMC 5.1) =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 . . . Card Type [CARD_TYPE: 0x57] HS200 Single Data Rate eMMC @200MHz 1.8VI/O HS Dual Data Rate eMMC @52MHz 1.8V or 3VI/O HS eMMC @52MHz - at rated device voltage(s) HS eMMC @26MHz - at rated device voltage(s) . . . Which is interesting by having 5 bits set in 0x57 but only listing 4 of the alternatives. The missing one would be for: HS400 DDR e.MMC @ 200 MHz - 1.8V I/O (In essence, no 1.2V alternative is supported.) It did not pick to attempt a 1.8V-only mode but instead to pick the fastest of the 3V-compatibile modes (in e.MCC terms). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Aug 11 02:01:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DD1C105650E for ; Sat, 11 Aug 2018 02:01:38 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA42286012; Sat, 11 Aug 2018 02:01:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w7B21aNa024119 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Aug 2018 19:01:36 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w7B21aJO024118; Fri, 10 Aug 2018 19:01:36 -0700 (PDT) (envelope-from jmg) Date: Fri, 10 Aug 2018 19:01:36 -0700 From: John-Mark Gurney To: Ian Lepore Cc: freebsd-arm@FreeBSD.org Subject: Re: sx_sleep not waking up when timo expires Message-ID: <20180811020136.GD97145@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org References: <20180729010157.GC2884@funkthat.com> <1532874944.61594.110.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1532874944.61594.110.camel@freebsd.org> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 10 Aug 2018 19:01:36 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 02:01:38 -0000 Ian Lepore wrote this message on Sun, Jul 29, 2018 at 08:35 -0600: > On Sat, 2018-07-28 at 18:01 -0700, John-Mark Gurney wrote: > > I recently upgraded my router to an Pine A64-LTS board, and have hit > > the same issue as PR 222126[1].  The solution at the end does not work > > for me, as I do not have that line in my loader.conf: > > kern.timecounter.smp_tsc_adjust=1 > > > > I have verified that the wake up does not happen, as I used a dtrace > > script to verify that pf_purge_expired_states is called or not called.. > > When I change the timeout, pf will kick the thread and get things > > running again, but it has stopped a couple times later... > > > > I'm running a recent SNAPSHOT: > > FreeBSD gate2.funkthat.com 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336134: Mon Jul  9 19:20:11 UTC 2018     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 > > > > This is likely reproducable by just starting pf, even in a pass all > > mode, and watching for when the function stops getting called...  I'll > > see if I can't get an extermely minimal config to reproduce it. > > > > Any suggestions? > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126 > > > > Sounds like > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229644  > > which has some patches attached which reduce but don't quite eliminate > the occurrances, so nothing has been committed yet. I just ordered a > SOPINE board so I can do some hands-on debugging. That patch does not fix the problem.. didn't even take 2 days w/ the patch applied before I got the failure... I had the pf thread stop w/ that patch applied.. # ps laxwww | grep 'pf purge' | grep -v grep; sleep 5; ps laxwww | grep 'pf purge' | grep -v grep 0 614 0 0 -16 0 0 16 pftm DL - 15:15.23 [pf purge] 0 614 0 0 -16 0 0 16 pftm DL - 15:15.23 [pf purge] There'll be cpu usage even w/o traffic running... simply loading pf, and then waiting till the cpu usage time stops incrementing is another easy way to test for it... Also, I've had the shell command sleep hang as well.. I figure that's expected, but made me realized that a good test program could be to fire up a bunch of threads and sleep in them, to make finding the problem more quickly.... Anything I can do to help debug/fix it? I have a couple spare LTS boards specifically to do stuff like this. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Sat Aug 11 11:34:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 661131068441 for ; Sat, 11 Aug 2018 11:34:45 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh502-vm3.bullet.mail.kks.yahoo.co.jp (nh502-vm3.bullet.mail.kks.yahoo.co.jp [183.79.56.148]) by mx1.freebsd.org (Postfix) with SMTP id 6F82777FEA for ; Sat, 11 Aug 2018 11:34:43 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.141] by nh502.bullet.mail.kks.yahoo.co.jp with NNFMP; 11 Aug 2018 11:32:31 -0000 Received: from [183.79.100.134] by t504.bullet.mail.kks.yahoo.co.jp with NNFMP; 11 Aug 2018 11:32:31 -0000 Received: from [127.0.0.1] by omp503.mail.kks.yahoo.co.jp with NNFMP; 11 Aug 2018 11:32:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 870310.81861.bm@omp503.mail.kks.yahoo.co.jp Received: (qmail 98600 invoked by uid 60001); 11 Aug 2018 11:32:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1533987151; bh=MBvbmRL1j7Zp0GLEEEyurLjGQEMfHPJTjstaVpxeNjI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Vg0aeYXHDOXvS2425kgatPFaxfVYm5mm8QBMfUg2lenNNpFXLDC/YU4xeLoQXNxZNmO3t7ojKKKtWmGC6SgeOP9IUSk9BCuVCQX8tvj3Bw4664vmoAocDiFpMI5IETHeomhiJMSFu63mzEeVR44DuQi1VGXSCc2wkp5G+UdhuTQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cPzPMA6Snde6lNDoParquSiibohk6DG0mbGI92+5hyQtYNf7U1IU8xdByFP0rwYJuayQhdvrR/preZc9W+vNhEyPmK1VCMCrc6c2NzCZSqKLi9WatsUxRSJ8zoYS/xGXYo5XhJzCc5fyI8anB7oNi0o5teo57B2DZPYyOs2TZlc=; Message-ID: <632838.94717.qm@web103913.mail.ssk.yahoo.co.jp> X-YMail-OSG: bbD2csAVM1lKM.U55Zq7GQhGCIZ.sxVb7w7TGLgz2VpKutprWnkWAp.DoQFTrT2ftuSdlQXaVE_JkdwF5JsT7i3nXqkJqWUFHOEP3edYwakWjNV4FXDrRlNnxKT5TcDZsqIXCfBmndgBN6ubq.MnhKddeay7AaQjf7fzF0rZz2a_HFfOlv7eua1AyETGyl33RvSWeeqXV09WMAK3pCd.nvJQ5DgaP4mP.LM4drLoTyFwcStMhqxQH0bt3DOJIGZQ7Oa8KOpRIx6iADvChB2TCrWjpPG3NsqZPBrkMuMoWeb9elItZvTRL8GFKSK7.DnAxs1p_cNl54aHN.oRarGW51pBnUnCb_yciI0wVUw9.69ZKpsWGkUnfJry9_Gxy7BNwpOjEltVxXItlWoTBCUsnywtETPkbw.9njopR72UU454mfpvbSm.GCDRLOoVYfaRAbe7P5IbVnpB4T_1j1Pb6IsLnNlsY_ww6LU9GCXxIejVOIyF2Thile3wUR5JrFJGib2YOwKVthx1e6VZqg39hEp3k1hE275NCFqpAY5QFRGKNMKYwzhZLdjIdMuVr2VMbTlSX8S_pka4r5QORqjlACtHMkSSa_a58DLCazDk_wklWKz2w_oIVQ033D51 Received: from [203.165.91.75] by web103913.mail.ssk.yahoo.co.jp via HTTP; Sat, 11 Aug 2018 20:32:30 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: dLtGWGYVM1nIPe7U1vPR1OgROmu5154DD30Nc2bBuNbhN64bjmM9HAgnk415iRhMEbZQLE5RT1fx1E1VMvnvqYKaFR10c5og5TkuJBsILHxywbjRYzj2mh0WBiMvEQkEUzvX Date: Sat, 11 Aug 2018 20:32:30 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: =?utf-8?B?TVY4OEY1MTgx44CAY2FuJ3QgIGRldGVjdCBjZmk=?= To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 11:34:45 -0000 Hi.=0A=0AI try to Current on=C2=A088F5181.=0A=0ABoot is fine but cfi flash = not detect.=0A=0ALast time I check this soc, cfi flash detect fine.=0A=0AWh= y don't detect cfi flash now ?=0A=0AThanks=0A=0AHiroki Mori From owner-freebsd-arm@freebsd.org Sat Aug 11 12:09:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECA7F106A309 for ; Sat, 11 Aug 2018 12:09:50 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8426D79E66 for ; Sat, 11 Aug 2018 12:09:50 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qt0-x235.google.com with SMTP id t5-v6so13060070qtn.3 for ; Sat, 11 Aug 2018 05:09:50 -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=Ar6NFiwb+wSUgq45ZsjXdWTPSmjPRlB3xQ22YBu64GY=; b=XTkSERSJGbW7RxhKPPzHrMgSwKtOGybaHvFjL5ruFbYhs+z1ifvO0tXnEujTn0x0hT rmmCgGXjlzNJ4kUliaKS19TdkqzjbHsElgne56DFkX0cpR3EPEPsftacV/oTmQaSlp1e kIhBB2QoWN6PC8emzo5QqhAI/JOErnGojSR+pTY8LrmPPB4BXOGG7bWkg0jiwUSUhYzz zOtZXJYIRENROXxiE5SsB+09szOOMEFPTvLnG73Zm1nhclJxnlPrKqtyE8eQtLrqZ2AK xXqAL4E8tQ1wZVnNCoVmLcrEOaWGRZasCjMTfezGNUAXvV8MBa2BmJUKvw/z+Nx+Gt3m mG3Q== 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=Ar6NFiwb+wSUgq45ZsjXdWTPSmjPRlB3xQ22YBu64GY=; b=UuXm5xH2yItSk60/OTKgRO3MSrGGhJX9poxngwEyRJaB/EcZJQ753VZToHNNNEthEV 92v/BHSM/Ztfmzqi/s+vfqN2LvhmqmXcH/xCmjwX2I+Ouc6neu3nqeSCIcJKrcxlWm/n U6dfMFH6VbyAwU5Hd2oRfT2jy2at8yom/R3F5o5cGGUUCn+LNlKKk2yoJnOtgzlzVgEm NvkIZbjF7KIP4FwQUnFV1u3n4on3ZrIRxJzu+WleTn8xL0cXMYuYbjEIVJnWH/QCZ2lw XCMqmIfeRL5ua0yZjYEpkHbyR+teYwHyxXUFiqOzk8qHgaLPqz2XAaIBZRKXoYMHyv38 3iLA== X-Gm-Message-State: AOUpUlFuXv3Q8MtlZdyJWpZgzl9k9P71RxLweuppf79oCh5HqYosOXFI AFCxf264Awvwr/MzMnB0ucj6S7kVbU3lXtKvFJHDuC25 X-Google-Smtp-Source: AA+uWPxtWOY1tGDKFepIOOYcpiOVYarGl1qomaTh3VSuAinWW/MLm9Jjb318mb6JOyA8Tc1T6pWgapQ4JieM7N/Ecbc= X-Received: by 2002:aed:24e7:: with SMTP id u36-v6mr10044471qtc.58.1533989390127; Sat, 11 Aug 2018 05:09:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:29c3:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 05:09:49 -0700 (PDT) In-Reply-To: <1533577708.4175.0@hraggstad.unrelenting.technology> References: <1533577708.4175.0@hraggstad.unrelenting.technology> From: Ganbold Tsagaankhuu Date: Sat, 11 Aug 2018 20:09:49 +0800 Message-ID: Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Greg V Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 12:09:51 -0000 On Tue, Aug 7, 2018 at 1:48 AM, Greg V wrote: > Hi, > > I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64 > board): > > https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 > > Very nice. I have NanoPC-T4 board and will test your patch. Did you try to load kernel via tftp at u-boot prompt? like: tftpboot 0x02000000 kernel.bin, go 0x02000000 Does it work for you that way? thanks, Ganbold > As with the ROCK64, boot is over the network. To boot, dd ayufan's ubuntu > image onto an sdcard and Ctrl-C the linux boot on the kernel selection > screen. U-Boot on SPI flash is not available yet. > > Unfortunately, performance is very disappointing =E2=80=94 I think the bi= g > cluster's default frequency is very low. > (Everything runs faster if cpuset to the LITTLE cores.) > > Looks like we'll need a driver for the "rockchip,rk808" PMIC to make > cpufreq_dt work=E2=80=A6 > Also my attempt at the clock driver is very incomplete ;) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sat Aug 11 12:44:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D6B6106B054 for ; Sat, 11 Aug 2018 12:44:04 +0000 (UTC) (envelope-from alydiomc@yahoo.com) Received: from sonic302-48.consmr.mail.ne1.yahoo.com (sonic302-48.consmr.mail.ne1.yahoo.com [66.163.186.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA85D7AD2E for ; Sat, 11 Aug 2018 12:44:03 +0000 (UTC) (envelope-from alydiomc@yahoo.com) X-YMail-OSG: grWDtR8VM1moLcBf7MgbEU0wHAe1Vntvm4_4bZLUM8VBGw.ceVdkLoeAYhegkUv 9g60WOzBVgAx6j0wGihPOIFWZyg_9l..rWCT35kBh6z.CSEtr4aPy0iB689QHkdm3.KJFQtnsk3. IKSuuxUv2Rf8nerWk85bWViVMAysGlq2vBXpjg9BFcZgQ5sW.X8yWnkdbFVKzm0VafOPMCyyQpPH LtIV.w_Z.2eru8djyQkKsT4NUb2Hc4X2hOJSgy724vpi1Bx8B43MtrUD8fM_NWVSwYJGNZjImYOF za58xiCilUbfKhlFh08mZNX7kewdRgf0J42KBabrRkvJJPWtsKnoswMG00RECgstFhWOhL2v.MdZ Nhw6SYo_KVraO_NVXuPojFZ_P2b.wQwkbH5mG1oV44PWWGTZhJdT03E5NhjpnA9JG3c7625xsP0D mPRvOZtsZ6CM0Uatl7LL9rd67FAB02uFjdo1XPFVpJb2NojF5O04uyscxKCpeoGI933UmBYBaqx0 2x_au7DBzEBi7CDu7ND8oCEWyB_LbyjdJchyg2kKNc1DB8LVhH7N51bUoTWgft1kinw80MPJSdWL hqbP_YnODMqTXa1hynO4h37ja0ufldKz45_7VIp8azYVxkIkIcJiA8wq830TI03uTzWBg71lED.p ZKjHkia3yJ15P4WM.4AvI3pNzCBm4Qg7svHwRX6E8U4LLVlpNrgOYCB39cETBnXx5w5AKuZ3rYtP 39NEvP7bv2uGsxKurVwsvikKq58NnssSmi8PTC.pEZ7T_nUIjeSLCASNQMHJYpW85mB9.JkKBDOr eu6UoSB0swt_ZsqvEXz7_e6ZF.K49IA83_Nk1RraskfFRflcm11j5F.kQ_KPUnC1JQzrzFaHI9Qo yxO_86riapuWIhC1sw8_sEs4VdC7HJc9m_y4R3NePRdCyhI3phFprxzqfiM0KyFY7cBGIxn1B7vo - Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sat, 11 Aug 2018 12:44:03 +0000 Date: Sat, 11 Aug 2018 11:49:25 +0000 (UTC) From: lyd mc To: "freebsd-arm@freebsd.org" Message-ID: <165877705.5351934.1533988165694@mail.yahoo.com> Subject: Nanopi Neo I2C MIME-Version: 1.0 References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> X-Mailer: WebService/1.1.12206 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 12:44:04 -0000 Hi List, Can you help me make I2C work in this board? I can detect the controller but cannot access it through iic ioctl.=20 root@nanopi-neo:~/prog/I2C # dmesg |grep iic iichb0: mem 0x1c2ac00-0x1c2afff i= rq 34 on simplebus0 iicbus0: on iichb0 iichb1: mem 0x1c2b000-0x1c2b3ff i= rq 35 on simplebus0 iicbus1: on iichb1 iichb2: mem 0x1c2b400-0x1c2b7ff i= rq 36 on simplebus0 iicbus2: on iichb2 iic0: on iicbus0 iic1: on iicbus1 iic2: on iicbus2 kdump output: =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NAMI=C2=A0 "/dev/iic0" =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 openat 3 =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,= 0xbfbfecd4) =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl -1 errn= o 2 No such file or directory This seems to work on my RPI. Regards,Alyd From owner-freebsd-arm@freebsd.org Sat Aug 11 14:32:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8849106EC95 for ; Sat, 11 Aug 2018 14:32:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80D4481364 for ; Sat, 11 Aug 2018 14:32:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1foUvq-00053p-Bf; Sat, 11 Aug 2018 17:31:54 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Nanopi Neo I2C From: Daniel Braniss In-Reply-To: <165877705.5351934.1533988165694@mail.yahoo.com> Date: Sat, 11 Aug 2018 17:31:54 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4D0332E4-901A-45A7-93F6-0FA7D9437587@cs.huji.ac.il> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.com> To: lyd mc X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 14:32:08 -0000 > On 11 Aug 2018, at 14:49, lyd mc via freebsd-arm = wrote: >=20 > Hi List, > Can you help me make I2C work in this board? > I can detect the controller but cannot access it through iic ioctl.=20 >=20 > root@nanopi-neo:~/prog/I2C # dmesg |grep iic > iichb0: mem = 0x1c2ac00-0x1c2afff irq 34 on simplebus0 > iicbus0: on iichb0 > iichb1: mem = 0x1c2b000-0x1c2b3ff irq 35 on simplebus0 > iicbus1: on iichb1 > iichb2: mem = 0x1c2b400-0x1c2b7ff irq 36 on simplebus0 > iicbus2: on iichb2 > iic0: on iicbus0 > iic1: on iicbus1 > iic2: on iicbus2 >=20 > kdump output: >=20 > 1290 mcp NAMI "/dev/iic0" > 1290 mcp RET openat 3 > 1290 mcp CALL ioctl(0x3,I2CRDWR,0xbfbfecd4) > 1290 mcp RET ioctl -1 errno 2 No such file or directory >=20 > This seems to work on my RPI. >=20 > Regards,Alyd what FreeBSD are you using? I have it working on CURRENT. what does=20 i2c -s say? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Aug 11 14:50:52 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 028F6106F712 for ; Sat, 11 Aug 2018 14:50:52 +0000 (UTC) (envelope-from alydiomc@yahoo.com) Received: from sonic301-7.consmr.mail.ne1.yahoo.com (sonic301-7.consmr.mail.ne1.yahoo.com [66.163.184.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90B55820EC for ; Sat, 11 Aug 2018 14:50:51 +0000 (UTC) (envelope-from alydiomc@yahoo.com) X-YMail-OSG: 4mcyzqYVM1mWRRq9SK1GxHF3eT4d2raLX6AGWSPXVr9QEhYHrbiHH_JgGHS358e hcq0It48ZtHNoho0BG17t2kf5VrVCf9yEf02Ydh3wQnvyWOMD5IDe8z2EWJ7NGz3u2VQaKcH22.P TUMfWI6K_xnxca4h000bI4YkNXwWjf6KpZrV_PX.OF.y1VAQscqzOVbe74J5qQkYIPElCYsiJcX9 baeZOWioJOYW.TUEu.TWI2BpB7UsmFyu4mJcUmfFoX.v9MJ5eb3mmWTnChwWO4jNeQpM4IaPezXq nDMTxij8AvGC1SY3gGqwf_Xm2v2nesAbmeHXX32iAsGLyQ7_8kXuksR_InD6jBljtowJ8b8txUz8 0NPx.gh4l4Z1v7HoWbCTm7UGXJEEHfaWQ0E87PX2jwXXAIBpr5DxxTwL8oMDLXG7DlOIohYD8RkH IAF9qRSc9LEgXFcCYKrYQ1Xixx3v5z2AcLo4ixIEgug6QshQMwSwRVTgSyHgKBsJinzINWn31UlM gomYRp9Q8jdkFKNyEYbu.nF1CfpsFqmdYRbxA8EF1qxIjAcMv0eGr3Rs3DvV3zmsYhtEADxy.iSg yOo60KZhey97Udgm67rnkXLzrOnrRhUGott1oF_BYjNt7J1OQWqIfWXAEgqTSknuaYRX6gZyQu8X d9SZtSNXXm9qyN0AZRBUhYss7UGLgcGboDTpWThAcsv_x9YqhSvrtRhuYJLxtvMXVOaCwC2zkHal yk_pFR4OsL43Vb6HXSydm.sp4Kkz6ORUTdo6tq9oc6fVJ6AxlIhdm7vfDPLo9O75xe5hgupTY5SP crIZiE21MpefMXXCWVQB9C6rjBGWPB4LhX99pFsPT52jrEwQ.tNKzQcvQU9Kfj5hy7iDTCHynkR7 zblF1XAZSIrE34nbK96cWD5K4QRudqNa7E5tJQPxub_iDFui8xNqVQ3eIXcAtLvhHPyIUpgtaBRD vtjqof.mpC_IZDK4XV5AWxQQQjaF8R2ZqrSo87Tk0x36Q5.b2xntSOy0TMYSWl4hL4k.5VDNgyI4 x Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Sat, 11 Aug 2018 14:50:50 +0000 Date: Sat, 11 Aug 2018 14:36:41 +0000 (UTC) From: lyd mc To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Message-ID: <736558299.5378642.1533998201917@mail.yahoo.com> In-Reply-To: <4D0332E4-901A-45A7-93F6-0FA7D9437587@cs.huji.ac.il> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.com> <4D0332E4-901A-45A7-93F6-0FA7D9437587@cs.huji.ac.il> Subject: Re: Nanopi Neo I2C MIME-Version: 1.0 X-Mailer: WebService/1.1.12206 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 14:50:52 -0000 Hi Daniel, I am using Current. root@nanopi-neo:~ # uname -a FreeBSD nanopi-neo 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r337527: Thu Aug=C2= =A0 9 20:21:07 +08 2018=C2=A0=C2=A0=C2=A0=C2=A0 root@mserver:/root/crochet/= work/obj/usr/src/arm.armv7/sys/GENERIC=C2=A0 arm root@nanopi-neo:~ # i2c -sHardware may not support START/STOP scanning; try= ing less-reliable read method. Scanning I2C devices on /dev/iic0: Regards,Alyd On Saturday, August 11, 2018, 10:32:01 PM GMT+8, Daniel Braniss wrote: =20 =20 =20 > On 11 Aug 2018, at 14:49, lyd mc via freebsd-arm wrote: >=20 > Hi List, > Can you help me make I2C work in this board? > I can detect the controller but cannot access it through iic ioctl.=20 >=20 > root@nanopi-neo:~/prog/I2C # dmesg |grep iic > iichb0: mem 0x1c2ac00-0x1c2afff= irq 34 on simplebus0 > iicbus0: on iichb0 > iichb1: mem 0x1c2b000-0x1c2b3ff= irq 35 on simplebus0 > iicbus1: on iichb1 > iichb2: mem 0x1c2b400-0x1c2b7ff= irq 36 on simplebus0 > iicbus2: on iichb2 > iic0: on iicbus0 > iic1: on iicbus1 > iic2: on iicbus2 >=20 > kdump output: >=20 >=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 NAMI=C2=A0 "/dev/iic0" >=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 openat 3 >=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0xbfbfecd= 4) >=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No such fil= e or directory >=20 > This seems to work on my RPI. >=20 > Regards,Alyd what FreeBSD are you using? I have it working on CURRENT. what does=20 =C2=A0 i2c -s say? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" =20 From owner-freebsd-arm@freebsd.org Sat Aug 11 14:52:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCDD5106F787 for ; Sat, 11 Aug 2018 14:52:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5905C82417 for ; Sat, 11 Aug 2018 14:52:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id v71-v6so6801147itb.3 for ; Sat, 11 Aug 2018 07:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=7vl6ev8jMeDYT7+MeFK+LTvxs6JVQmviz+5/yTN9itg=; b=mUhoe8eXIoVYSWfJpHXSXILa+AY6/b77RF5QHt6cn0PxEkBnuhVatBbyFIhKsG/WQW rELj7vpBzvQNupot38z+gTWM8sre3NLZG/cGDgArgQdf1aAhfDpTLa4Y+aQE0fvtVyKX YbNo0gQhRV16SlOClsmMoad77W81ZyCoyXOSmfGIrLF9nknm7kNDtiUQULwDQvqa1xVQ TtxuFOW7+dLQOLvDkt2DGJMth6PyUNcTd+PUOT0di/Wt1xNq58l8YgcqdTkk/B5Eppsm dbiN5/GpASqxjdIBN8ElMZXdZOx0YdOJezWPfOvEmwSnXMdKUXy/+SAH8HDnW6KvfVKo tAmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=7vl6ev8jMeDYT7+MeFK+LTvxs6JVQmviz+5/yTN9itg=; b=MjQYh+V2Hq1hO9fVSq9FDVXQE1qxQ6tojIdgEDtez4jvI1CUAvMRnDM3k/6bSGcAmb y6fBPnGcTfmZ3gNhJYzW1T/3zjnsHgx5ibZDQfn5/p8dxmK7yzrwx0DPBFfyQH9kYWu0 cEMf+tUbIhQkvEb0D4F7lIhpYtnCCgDpOc+zb+r8fxqcDx6zO6qv97MpW/oD78LO/ZHv M8M0i8O/6rEtd5jHp1t7WmV+umguJymD/quxm8GYoKIyA2ItS4uDUS8Xtxpl8mLlXvbD LHXSjLWj1e+XmYX7TkAqPa9RbdwFFZ472epNQOrqTSZDAqPZMk934fzAy92CzFWgwdlU VAcg== X-Gm-Message-State: AOUpUlGfAE4vx95i+iHzWQ0I3MsUTsPlKZu1XhGm/00eLMSLCBsndBkB AGUZUJPByw7BsysDMv+B7We9tWWIT51zJxTeU+rVGIdo2VI= X-Google-Smtp-Source: AA+uWPx9jCfG/ReWs1zNE7n7V6y3BG23QbBh9Rq+rUWKON1oUBnWD3IhaNE1ijxJ/ScoezKLpSvUw40IJnb4JciYzBw= X-Received: by 2002:a24:4f52:: with SMTP id c79-v6mr5632789itb.36.1533999145217; Sat, 11 Aug 2018 07:52:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 07:52:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] From: Warner Losh Date: Sat, 11 Aug 2018 08:52:24 -0600 X-Google-Sender-Auth: qf0tNw_cLYh9lBFnM_IvVPZf7A4 Message-ID: Subject: Kill old, non-INTRNG code on ARM To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 14:52:27 -0000 One last thing, even though we're in a slush, is to kill the pre-INTRNG code. It's required for armv6 and v7 for some time (only the Amlogic 8726 boards remain broken there). And we're down to two families of chips which support armv5: rt1310 and the Marvel gear. Both of them support INTRNG. I propose we eliminate the INTRNG option and unifdef the code to remove the undefined case. Comments? Warner From owner-freebsd-arm@freebsd.org Sat Aug 11 15:05:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DF0B106FD21 for ; Sat, 11 Aug 2018 15:05:00 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B6F782E41 for ; Sat, 11 Aug 2018 15:04:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: e447933b-9d77-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e447933b-9d77-11e8-aff6-0b9b8210da61; Sat, 11 Aug 2018 15:04:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7BF4mT4063988; Sat, 11 Aug 2018 09:04:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533999888.31375.6.camel@freebsd.org> Subject: Re: Nanopi Neo I2C From: Ian Lepore To: lyd mc , "freebsd-arm@freebsd.org" Date: Sat, 11 Aug 2018 09:04:48 -0600 In-Reply-To: <165877705.5351934.1533988165694@mail.yahoo.com> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 15:05:00 -0000 On Sat, 2018-08-11 at 11:49 +0000, lyd mc via freebsd-arm wrote: > Hi List, > Can you help me make I2C work in this board? > I can detect the controller but cannot access it through iic ioctl.  > > root@nanopi-neo:~/prog/I2C # dmesg |grep iic > iichb0: mem 0x1c2ac00- > 0x1c2afff irq 34 on simplebus0 > iicbus0: on iichb0 > iichb1: mem 0x1c2b000- > 0x1c2b3ff irq 35 on simplebus0 > iicbus1: on iichb1 > iichb2: mem 0x1c2b400- > 0x1c2b7ff irq 36 on simplebus0 > iicbus2: on iichb2 > iic0: on iicbus0 > iic1: on iicbus1 > iic2: on iicbus2 > > kdump output: > >   1290 mcp      NAMI  "/dev/iic0" >   1290 mcp      RET   openat 3 >   1290 mcp      CALL  ioctl(0x3,I2CRDWR,0xbfbfecd4) >   1290 mcp      RET   ioctl -1 errno 2 No such file or directory > > This seems to work on my RPI. > In this case, I wonder if the "errno 2" is not ENOENT, but rather IIC_ENOACK which has not been translated to a proper errno before returning. IIC_ENOACK is basically a timeout and can happen if the slave address is wrong, or if the pinmux is wrong so that the bus is electrically inactive. Is the bus working in general? Do any devices show up on a scan with   i2c -f /dev/iic0 -s -- Ian From owner-freebsd-arm@freebsd.org Sat Aug 11 15:07:20 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03B66106FDE4 for ; Sat, 11 Aug 2018 15:07:20 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84A2B82EF0 for ; Sat, 11 Aug 2018 15:07:19 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w7BF7Fpr028164; Sat, 11 Aug 2018 08:07:15 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w7BF7Fmi028163; Sat, 11 Aug 2018 08:07:15 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201808111507.w7BF7Fmi028163@pdx.rh.CN85.dnsmgr.net> Subject: Re: Kill old, non-INTRNG code on ARM In-Reply-To: To: Warner Losh Date: Sat, 11 Aug 2018 08:07:15 -0700 (PDT) CC: "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 15:07:20 -0000 > One last thing, even though we're in a slush, is to kill the pre-INTRNG > code. > > It's required for armv6 and v7 for some time (only the Amlogic 8726 boards > remain broken there). And we're down to two families of chips which support > armv5: rt1310 and the Marvel gear. Both of them support INTRNG. > > I propose we eliminate the INTRNG option and unifdef the code to remove the > undefined case. > > Comments? Where is the deprication policy? (Ducks, cause he knows rocks are coming :-)) -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sat Aug 11 15:25:19 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FC3C10705D9 for ; Sat, 11 Aug 2018 15:25:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC38D83854 for ; Sat, 11 Aug 2018 15:25:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id w11-v6so10365735iob.2 for ; Sat, 11 Aug 2018 08:25:18 -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=8oQAMi5fEdQLuvvM9obh3w8hlM8sushNaPJiGvazv9Y=; b=Fjv+M+fEcM79pauvjqgASUzfFRZXe4zKxvdpVC4NEkz0Y9Jg9R5CEWvyE+GmU/dl+Q wPxetGePsYx3tiZOlQfJVLLXeBDNZ3cnrDSPL++C9maeAzCoe5r14ipezB//bh04TaQu XciHSx+E7Tq0AarTPwmlQAtHCIFFz+3yqObDxBL4iL9vxRAIejgzvey89HGU/f2huzal PKQUdOW2LKZHTDTASu1BXgA+InYLslJm4icgMWMujrDEYgkvXiqYMR0MOmQG9YipNg+J p+MQNULgSIjoJodHNmEQ3sgtIwUfZImFXWblne5PUhZEJcjuS32bW6d5Az4Ia0TAVquK hHhw== 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=8oQAMi5fEdQLuvvM9obh3w8hlM8sushNaPJiGvazv9Y=; b=hKPQLzFIgq5/Pd7iYasooW3ndncH9fy+Rd8HVKq5bwVE3sCZPfEaTiEjLftKVeyff0 9GTi7FY9MFdw+zvFdboGIYxwR37gRCEwh7SU+IqCpNZykP0NtEx2NoF7h0r6vxWqDrEY y6o1YwQ9+acJdhU+c57wXOadq0sFkxfhDH/QIe2Rw71r0NPb6LbcmwLV3uDFKcvsnXES 7qPhNDS5dHnhoeJFymlLmloJxVKDdB2VCDAGBrdtaOgHp7m1jEbrqeojawx4FFGSk8sn ro0v6g+20xeIaAtnaECzLzJXR7S9JgifSWreMd+rTF/B7uxwPKHkx4yQ8iEkX1fg9hZz dEuA== X-Gm-Message-State: AOUpUlGYDwRTKOzGjMiFisaMz2wm9zk/liTk0X04Wn/7sRDfpCx2+6Lx mLwALdOtTOg8zM0100RsvEMhil9Lw93QbIcd0ursfE8QTby/mA== X-Google-Smtp-Source: AA+uWPxKE8iwAM0A3VtbB23Yvo/jafK844GVRBhis3/hCJd8ORjSquNF+JpVd1syCw3CR+00JY6SkT7JfYftd4ukCqQ= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr9124527ioa.168.1534001117990; Sat, 11 Aug 2018 08:25:17 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 08:25:17 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <920419.9428.qm@web103910.mail.ssk.yahoo.co.jp> References: <64850.63077.qm@web101706.mail.ssk.yahoo.co.jp> <387823.67007.qm@web101711.mail.ssk.yahoo.co.jp> <812183.70978.qm@web101705.mail.ssk.yahoo.co.jp> <892631.23713.qm@web101718.mail.ssk.yahoo.co.jp> <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> <920419.9428.qm@web103910.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Sat, 11 Aug 2018 09:25:17 -0600 X-Google-Sender-Auth: x6Ko-ryDTDqzlibU1Q6-LbAuDys Message-ID: Subject: Re: solved Re: still hang up arm/ralink To: Mori Hiroki Cc: Michael Zhilin , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 15:25:19 -0000 On Thu, Aug 9, 2018 at 11:52 PM, Mori Hiroki wrote: > Hi. > > ----- Original Message ----- > >From: Warner Losh > >To: Mori Hiroki > >Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" < > freebsd-arm@freebsd.org> > >Date: 2018/8/10, Fri 11:16 > >Subject: Re: solved Re: still hang up arm/ralink > > > > > >Mori-san > > > > > >I took your advice and bought a Buffalo WZR2-G300N off ebay. It arrived > while I was on vacation. So, I spent a few minutes with it today. I've > installed header for serial port, puzzled out the pins, found your blog > that had the pins and the piece I was missing (the baud rate). I now have > added it to my test lab's terminal server and hope to start building images > for it once I get my test lab's CI infrastructure up and running. > > > > Thanks for your cooperation. > > > > >So, now I'm sitting at the "RT2860-EVB#" prompt from uboot hoping to boot > the RT1310 kernel. However, I lack instructions and can't seem to find all > the details in your posts or on your blog. How do I load/create the RAM > disk referenced in the kernel config file "options > ROOTDEVNAME=\"cd9660:/dev/cfid0s.rootfs.uzip\"" ? what address do I load > the kernel at (0x40800000 is listed in a diagram, but 0x40000100 is shown > in the dmesg) and which variation of the kernel should I use? Thanks for > any help you can offer. > > > > I use ZRouter build system. But I am a suggestion normal build system. > > I think Buffalo WZR2-G300N is different u-boot on US and Japan model. > Because of my target prompt is "5VT1310-EVB#". Be careful operation. > You can find some information in printenv at u-boot. > > Sorry I forget memory address setting in build system. I add this to > review. > > https://reviews.freebsd.org/D16622 > > In this setting build kernel header is this. > > % readelf -h Buffalo_WZR2-G300N_kernel > ELF Header: > Magic: 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 > Class: ELF32 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - FreeBSD > ABI Version: 0 > Type: EXEC (Executable file) > Machine: ARM > Version: 0x1 > Entry point address: 0xc0000100 > Start of program headers: 52 (bytes into file) > Start of section headers: 3633180 (bytes into file) > Flags: 0x5000202, has entry point, Version5 > EABI, > Size of this header: 52 (bytes) > Size of program headers: 32 (bytes) > Number of program headers: 6 > Size of section headers: 40 (bytes) > Number of section headers: 37 > Section header string table index: 34 > > Do opjcopy and compress and make u-boot image by load and entry address > is 0x40000100. > > % file Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot > > Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot: u-boot legacy uImage, > FreeBSD Kernel Image, Linux/ARM, OS Kernel Image (lzma), 999004 bytes, Wed > Aug 8 22:50:36 2018, Load Address: 0x40000100, Entry Point: 0x40000100, > Header CRC: 0xFEC4D6B9, Data CRC: 0xE650EDDF > > It can execute on memory. (not flash) > You need set ipaddr and serverip on u-boot. > > 5VT1310-EVB# tftpboot 00800000 Buffalo_WZR2-G300N_kernel. > kbin.oldlzma.uboot > TFTP from server 10.10.10.3; our IP address is 10.10.10.190 > Filename 'Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot'. > Load address: 0x800000 > Loading: ################################################################# > ################################################################# > ################################################################# > # > done > Bytes transferred = 999068 (f3e9c hex) > 5VT1310-EVB# bootm > ## Booting image at 00800000 ... > Image Name: FreeBSD Kernel Image > Image Type: ARM Linux Kernel Image (lzma compressed) > Data Size: 999004 Bytes = 975.6 kB > Load Address: 40000100 > Entry Point: 40000100 > Verifying Checksum ... OK > Uncompressing LZMA Kernel Image .............................. > ............OK > > Starting kernel @40000100... > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > > If you can execute kernel then stop at rootfs mount. > > I think this is first step. > Where do I find oldlzma utility? The current one produces an unbootable image: % objcopy -S -O binary kernel kernel.kbin % lzma kernel.kbin % mkimage -A arm -O FreeBSD -T kernel -C lzma -a 0x40000100 -e 0x40000100 -n rt1310 -d kernel.kbin.lzma kernel.kbin.lzma.u-boot Image Name: rt1310 Created: Sat Aug 11 09:06:27 2018 Image Type: ARM FreeBSD Kernel Image (lzma compressed) Data Size: 1317305 Bytes = 1286.43 KiB = 1.26 MiB Load Address: 40000100 Entry Point: 40000100 % scp kernel.kbin.lzma.u-boot tftp:tftpboot ... RT2860-EVB# bootm ## Booting image at 00800000 ... Image Name: rt1310 Image Type: ARM Unknown OS Kernel Image (lzma compressed) Data Size: 1317305 Bytes = 1.3 MB Load Address: 40000100 Entry Point: 40000100 Verifying Checksum ... OK Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover OK I see you have 'oldlzma' and online instructions use an oldlzma command... Warner > Thanks > > Hiroki Mori > > > > >Warner > > > > > >On Sat, Mar 10, 2018 at 2:31 AM, Mori Hiroki > wrote: > > > >Hi > >> > >>I do try to todays current. It' work find on RT1310. > >> > >>https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a15e4a b5 > >> > >> > >>Thanks > >> > >>Hiroki Mori > >>______________________________ _________________ > >>freebsd-arm@freebsd.org mailing list > >>https://lists.freebsd.org/ mailman/listinfo/freebsd-arm > >>To unsubscribe, send any mail to "freebsd-arm-unsubscribe@ freebsd.org" > >> > > > > > > > From owner-freebsd-arm@freebsd.org Sat Aug 11 15:26:32 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E3111070776 for ; Sat, 11 Aug 2018 15:26:32 +0000 (UTC) (envelope-from alydiomc@yahoo.com) Received: from sonic302-48.consmr.mail.ne1.yahoo.com (sonic302-48.consmr.mail.ne1.yahoo.com [66.163.186.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F31D683958 for ; Sat, 11 Aug 2018 15:26:31 +0000 (UTC) (envelope-from alydiomc@yahoo.com) X-YMail-OSG: QkzY2i8VM1mxG_D17cBGvzcjzLMKedctGQGz1DhBoFNG72n9uha5AWLm2LkjnQC BpVlexrk4SFQ34gmOEJ6MYoyQxfLArsuT1O9HG_nR8Rwf3..QH.We0tpcNPSfp2x.Zr7j9LCsDvZ LtunebdEL9sht7nczNkk18B7BdyPHzqjulPv.xK1oe0MiAeC7Ghs5SR2MLArTfFkxikVjw6HVYzZ cFNPxXasyTpdI8LGpFnIix9WqjM_FBPLl90aIdshtq6mzv7aI_65PWscGIk8eT8YarkmUjeE6HlA OIEPqFjm1eNdXlNilQqslM0EAbeQCuSpX28jX0McDyVJY_oRS27VqPWphKqPoweyocvYzWhmp6H0 AS6d9AUQ3VQFmPYj.0IJ9Uv8PKCnJmOB4RimQgcIwkyB8FCXt4KwuuMGEdwgUbXrCXKV0ej1icG8 .3fZ4ZHnfRbWFkz5xyMjPEi4TixTrN.hLziXLTEENJdrrnRt7UhZPPMhA654X57yxhRRkSRgvtZi MWYzkCzqOhlMu8Bw7q1N4P7Fk1ShKlv3991L6kv1m5ybF730s_iJqgJ88Wt4Wd8v1sz1EVOrhncS rVUe2LHMCaj_PeESwdTWCNyQfKcP7q6w84EPD_WQmxgPliHZ7TDq8vcygZofVCaqxRa3YrDkDWlA j0iRVTm1ZxtDJrYddqatkqiAKWCU.CkdTvk6SdORpOGzCNvQQS1_CM9Trr8jeumlGfPlHoFlF9D7 5STr7tB8hDsPkXzLokwDZNzXWqAgtdPqEahiKrys.Tjh2Duf6SND1JtILV8c24SdEnwvR60tTwcb fDbYb2C5B9mzpXsCYsZIUahjDuY9T9v9hNhLQt4tTpwSZFma9HE7gfNBvwTBF4cJqV.jW1VfnhGi .H_oXhDrHEPn8zf24oXS5ZLxPeWbd3rExxhi6j9JzmDEk_6R00Jx_C53r88m5FgHUdxhfl5j5ewe ZqC81PJvJBNk9K0Axq.FjU4EV6ilRMfavonIwRUP9q1iDUds.ZA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sat, 11 Aug 2018 15:26:30 +0000 Date: Sat, 11 Aug 2018 15:21:54 +0000 (UTC) From: lyd mc To: "freebsd-arm@freebsd.org" , Ian Lepore Message-ID: <2122126425.5355832.1534000914963@mail.yahoo.com> In-Reply-To: <1533999888.31375.6.camel@freebsd.org> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.com> <1533999888.31375.6.camel@freebsd.org> Subject: Re: Nanopi Neo I2C MIME-Version: 1.0 X-Mailer: WebService/1.1.12206 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 15:26:32 -0000 Hi Ian, The iic bus seem to be working on linux image. I can detect the device at 0= x18. root@nanopi-neo:~/prog/I2C #=C2=A0 i2c -f /dev/iic0 -s Hardware may not support START/STOP scanning; trying less-reliable read met= hod. Scanning I2C devices on /dev/iic0: some kdump output of above command:=C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2CRSTCARD,0xbfbfec64) =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl 0 =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2C= START,0xbfbfec64) =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl -1= errno 2 No such file or directory =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2C= STOP,0xbfbfec64) =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl 0 .=C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(= 0x3,I2CRSTCARD,0xbfbfec64) =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl 0 =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2C= RDWR,0xbfbfec50) =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl -1= errno 2 No such file or directory =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2C= RSTCARD,0xbfbfec64) =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl 0 =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2C= RDWR,0xbfbfec50) =C2=A0=C2=A0 871 i2c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl -1= errno 2 No such file or directory Seems I2CRSTCARD and I2CSTOP are the only working ioctl on me. I activated i2c0 using below dts code: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 i2c@1c2ac00 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 compatible = =3D "allwinner,sun6i-a31-i2c"; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reg =3D <0x= 1c2ac00 0x400>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interrupts = =3D <0x0 0x6 0x4>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clocks =3D = <0x1d 0x3b>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 resets =3D = <0x1d 0x2e>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pinctrl-nam= es =3D "default"; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pinctrl-0 = =3D <0x20>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status =3D = "okay"; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #address-ce= lls =3D <0x1>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #size-cells= =3D <0x0>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 phandle =3D= <0x41>; Regards,Alyd On Saturday, August 11, 2018, 11:04:54 PM GMT+8, Ian Lepore wrote: =20 =20 On Sat, 2018-08-11 at 11:49 +0000, lyd mc via freebsd-arm wrote: > Hi List, > Can you help me make I2C work in this board? > I can detect the controller but cannot access it through iic ioctl.=C2=A0 >=20 > root@nanopi-neo:~/prog/I2C # dmesg |grep iic > iichb0: mem 0x1c2ac00- > 0x1c2afff irq 34 on simplebus0 > iicbus0: on iichb0 > iichb1: mem 0x1c2b000- > 0x1c2b3ff irq 35 on simplebus0 > iicbus1: on iichb1 > iichb2: mem 0x1c2b400- > 0x1c2b7ff irq 36 on simplebus0 > iicbus2: on iichb2 > iic0: on iicbus0 > iic1: on iicbus1 > iic2: on iicbus2 >=20 > kdump output: >=20 > =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NAMI=C2=A0 "/dev/iic0" > =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 openat 3 > =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDW= R,0xbfbfecd4) > =C2=A0 1290 mcp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET=C2=A0=C2=A0 ioctl -1 er= rno 2 No such file or directory >=20 > This seems to work on my RPI. >=20 In this case, I wonder if the "errno 2" is not ENOENT, but rather=C2=A0IIC_ENOACK which has not been translated to a proper errno before returning. IIC_ENOACK is basically a timeout and can happen if the slave address is wrong, or if the pinmux is wrong so that the bus is electrically inactive. Is the bus working in general? Do any devices show up on a scan with =C2=A0 i2c -f /dev/iic0 -s -- Ian =20 From owner-freebsd-arm@freebsd.org Sat Aug 11 15:50:37 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B277107115A for ; Sat, 11 Aug 2018 15:50:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9522584519; Sat, 11 Aug 2018 15:50:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1foW9i-00088Z-Hb; Sat, 11 Aug 2018 18:50:18 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Nanopi Neo I2C From: Daniel Braniss In-Reply-To: <2122126425.5355832.1534000914963@mail.yahoo.com> Date: Sat, 11 Aug 2018 18:50:18 +0300 Cc: "freebsd-arm@freebsd.org" , Ian Lepore , eval@iptk.ru, Milan Obuch Content-Transfer-Encoding: quoted-printable Message-Id: <5E1DB0F5-EF98-46A8-8D33-11052834E35C@cs.huji.ac.il> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.com> <1533999888.31375.6.camel@freebsd.org> <2122126425.5355832.1534000914963@mail.yahoo.com> To: lyd mc X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 15:50:37 -0000 > On 11 Aug 2018, at 18:21, lyd mc via freebsd-arm = wrote: >=20 > Hi Ian, > The iic bus seem to be working on linux image. I can detect the device = at 0x18. > root@nanopi-neo:~/prog/I2C # i2c -f /dev/iic0 -s > Hardware may not support START/STOP scanning; trying less-reliable = read method. > Scanning I2C devices on /dev/iic0: >=20 > some kdump output of above command: 871 i2c CALL = ioctl(0x3,I2CRSTCARD,0xbfbfec64) > 871 i2c RET ioctl 0 > 871 i2c CALL ioctl(0x3,I2CSTART,0xbfbfec64) > 871 i2c RET ioctl -1 errno 2 No such file or directory > 871 i2c CALL ioctl(0x3,I2CSTOP,0xbfbfec64) > 871 i2c RET ioctl 0 > . 871 i2c CALL ioctl(0x3,I2CRSTCARD,0xbfbfec64) > 871 i2c RET ioctl 0 > 871 i2c CALL ioctl(0x3,I2CRDWR,0xbfbfec50) > 871 i2c RET ioctl -1 errno 2 No such file or directory > 871 i2c CALL ioctl(0x3,I2CRSTCARD,0xbfbfec64) > 871 i2c RET ioctl 0 > 871 i2c CALL ioctl(0x3,I2CRDWR,0xbfbfec50) > 871 i2c RET ioctl -1 errno 2 No such file or directory > Seems I2CRSTCARD and I2CSTOP are the only working ioctl on me. > I activated i2c0 using below dts code: > i2c@1c2ac00 { >=20 > compatible =3D "allwinner,sun6i-a31-i2c"; > reg =3D <0x1c2ac00 0x400>; > interrupts =3D <0x0 0x6 0x4>; > clocks =3D <0x1d 0x3b>; > resets =3D <0x1d 0x2e>; > pinctrl-names =3D "default"; > pinctrl-0 =3D <0x20>; > status =3D "okay"; > #address-cells =3D <0x1>; > #size-cells =3D <0x0>; > phandle =3D <0x41>; >=20 >=20 > Regards,Alyd > On Saturday, August 11, 2018, 11:04:54 PM GMT+8, Ian Lepore = wrote: =20 >=20 > On Sat, 2018-08-11 at 11:49 +0000, lyd mc via freebsd-arm wrote: >> Hi List, >> Can you help me make I2C work in this board? >> I can detect the controller but cannot access it through iic ioctl.=20= >>=20 >> root@nanopi-neo:~/prog/I2C # dmesg |grep iic >> iichb0: mem 0x1c2ac00- >> 0x1c2afff irq 34 on simplebus0 >> iicbus0: on iichb0 >> iichb1: mem 0x1c2b000- >> 0x1c2b3ff irq 35 on simplebus0 >> iicbus1: on iichb1 >> iichb2: mem 0x1c2b400- >> 0x1c2b7ff irq 36 on simplebus0 >> iicbus2: on iichb2 >> iic0: on iicbus0 >> iic1: on iicbus1 >> iic2: on iicbus2 >>=20 >> kdump output: >>=20 >> 1290 mcp NAMI "/dev/iic0" >> 1290 mcp RET openat 3 >> 1290 mcp CALL ioctl(0x3,I2CRDWR,0xbfbfecd4) >> 1290 mcp RET ioctl -1 errno 2 No such file or directory >>=20 >> This seems to work on my RPI. >>=20 >=20 > In this case, I wonder if the "errno 2" is not ENOENT, but > rather IIC_ENOACK which has not been translated to a proper errno > before returning. IIC_ENOACK is basically a timeout and can happen if > the slave address is wrong, or if the pinmux is wrong so that the bus > is electrically inactive. >=20 > Is the bus working in general? Do any devices show up on a scan with >=20 > i2c -f /dev/iic0 -s >=20 > -- Ian >=20 the driver has timing issues (among others :-). I=E2=80=99m cc=E2=80=99ing= the guys I got a =E2=80=98working=E2=80=99 twsi stuff=20 to see if I can pass it on. danny From owner-freebsd-arm@freebsd.org Sat Aug 11 16:32:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 954331072B5B for ; Sat, 11 Aug 2018 16:32:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 109C086F97; Sat, 11 Aug 2018 16:32:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w7BGW9mQ041266 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Aug 2018 09:32:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7BGW9BH041265; Sat, 11 Aug 2018 09:32:09 -0700 (PDT) (envelope-from fbsd) Date: Sat, 11 Aug 2018 09:32:09 -0700 From: bob prohaska To: Warner Losh Cc: Mark Johnston , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180811163209.GA38922@www.zefox.net> References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> <20180810044426.GB32974@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180810044426.GB32974@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 16:32:01 -0000 Simply moving all swap to microSD (and leaving vm.pageout_oom_seq at the default value of 12) allowed an uneventul -j4 buildworld on r337226M, upgrading to r337564M with the patches suggested to date still in place. There were no warnings or errors on the console or controlling terminal. The microSD card used for /root, /tmp and swap is a Sandisk Ultra, supposedly a notch or two slower than the Sandisk Extreme USB flash drive that caused all the trouble. One small curiosity happened on reboot: the old kernel reported in part: Syncing disks, buffers remaining... 8 8 8 8 8 8 8 8 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 20 e6 00 00 00 40 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain 8 8 8 8 8 8 8 8 8 8 8 8 Giving up on 8 buffers Uptime: 1d4h36m2s There followed a repetition of previously-seen errors on da0, but somewhow u-boot got control and the system came back up after self-fsck without intervention. Do the errors reported above narrow down at all what might be going wrong? Is there a patch or setting that would reveal what the CCB request error was? More complete transcripts are at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/3gbsdflash/ Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sat Aug 11 16:46:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF1BB10738F3 for ; Sat, 11 Aug 2018 16:46:23 +0000 (UTC) (envelope-from alydiomc@yahoo.com) Received: from sonic301-8.consmr.mail.ne1.yahoo.com (sonic301-8.consmr.mail.ne1.yahoo.com [66.163.184.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 298DD88C76 for ; Sat, 11 Aug 2018 16:46:23 +0000 (UTC) (envelope-from alydiomc@yahoo.com) X-YMail-OSG: SJMHFgoVM1lEJNOzXvT4WEUZKXF9EYIxWCrpinDaM3EYJiqi3EMI79999euJ38x LIY4gY48UQV2h9Xn7DrjBjrc67FXP_uruo2NjzVPm6NNlElkGhQcDNqiyGA2e1l.TiDyhzhw6q19 m.SxuSOZxsPVdkK_VJxx8.evu2VqHoOmTdLLbXGMuXjQQNLkn_Uekg2qzTi6dLyBmpVzxNlkk5Ar F.JKYeb7nj90aPTwuE0X2KenV5.GTJR2VylwBzlOCj5sgbO3YjZ69Da3_RRotoSjtN0EmNXp5V15 NJ.vKe.hqlrCS1LzxCM5pu5tHWFTEx5H.8IM0NTXGcJeEcbV4A9LKjv33Ih3zW1Cx9JvxohnepV4 bAlWFJsRsOjfE590eahDA3Ok0jW2xL7UUvl4zLiP6m7eKzXw9JZvzVMFLfFIzrL7S4WJcDaFn8mn zwyxG4a3nt9dxniekw2I_YlJaPnarDPzTVEPGV5znaG_vCgVBfE6j2eMehJfDQB_NjWfSwtucZMr sWR31HMWOhuo7HnanPMuf5eRSM3omFOkTj5kXUm9jKk6X5X0pwgZ2oXSblM.reRvqnesLQ8N50yH 6AmAMVqINJDqn35AAf8EUamfQ1ojCSLKKDZ7eWcenu4rG0_VMdiAbxwtQ9ptxhGg1QmerxO03R5c 6nvWm4bSTpS5Pjg0vIGT1E8Nu4y6y5rkGdoOdQPzGCOnnyFfpsj7b9ZlMp.OtCQRZcANy2WGUNff v_zgaRSG5tcSxUHTvptldtkP4wLtC_EUQ0xvpWtJGBOsXSTdHPDpZ.deUvUypDsY1MeIlynifmvj iAG8abezXcwzpK44w.iC3LZoWXYL_1UXba5hog8fVziQ3BxS_YWhyD7oFUB_ZPkCES33_w_aowGr 5nP8Xr..S8CxGTGnVk_t_tw1841rY5i.aeSem29qTdeKwrvsVPKQj_YX.j3r0RLTW4ak6cF_x5TZ rm8VGUNnyVQPF4iyJGnOq4nRw0CGgVYOKLPI8Tt5pQ0BUggntrBaK8x7DOtTU0.iwMZ0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Sat, 11 Aug 2018 16:46:22 +0000 Date: Sat, 11 Aug 2018 16:01:52 +0000 (UTC) From: lyd mc To: Daniel Braniss , "ian@freebsd.org" Cc: "freebsd-arm@freebsd.org" , eval@iptk.ru, Milan Obuch Message-ID: <289384556.5384363.1534003312078@mail.yahoo.com> In-Reply-To: <5E1DB0F5-EF98-46A8-8D33-11052834E35C@cs.huji.ac.il> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.com> <1533999888.31375.6.camel@freebsd.org> <2122126425.5355832.1534000914963@mail.yahoo.com> <5E1DB0F5-EF98-46A8-8D33-11052834E35C@cs.huji.ac.il> Subject: Re: Nanopi Neo I2C MIME-Version: 1.0 X-Mailer: WebService/1.1.12206 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 16:46:24 -0000 =20 Thanks Danny and Ian! Regards,Alyd On Saturday, August 11, 2018, 11:50:37 PM GMT+8, Daniel Braniss wrote: =20 =20 =20 > On 11 Aug 2018, at 18:21, lyd mc via freebsd-arm wrote: >=20 > Hi Ian, > The iic bus seem to be working on linux image. I can detect the device at= 0x18. > root@nanopi-neo:~/prog/I2C #=C2=A0 i2c -f /dev/iic0 -s > Hardware may not support START/STOP scanning; trying less-reliable read m= ethod. > Scanning I2C devices on /dev/iic0: >=20 > some kdump output of above command:=C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CAL= L=C2=A0 ioctl(0x3,I2CRSTCARD,0xbfbfec64) >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CSTART,0x= bfbfec64) >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No su= ch file or directory >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CSTOP,0xb= fbfec64) >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > .=C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRSTCARD= ,0xbfbfec64) >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0xb= fbfec50) >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No su= ch file or directory >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRSTCARD,= 0xbfbfec64) >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0xb= fbfec50) >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No su= ch file or directory > Seems I2CRSTCARD and I2CSTOP are the only working ioctl on me. > I activated i2c0 using below dts code: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2c@1c2ac00 { >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 compatible =3D "allwinner,sun6i-a31-i2c"; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 reg =3D <0x1c2ac00 0x400>; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 interrupts =3D <0x0 0x6 0x4>; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 clocks =3D <0x1d 0x3b>; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 resets =3D <0x1d 0x2e>; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 pinctrl-names =3D "default"; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 pinctrl-0 =3D <0x20>; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 status =3D "okay"; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 #address-cells =3D <0x1>; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 #size-cells =3D <0x0>; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 phandle =3D <0x41>; >=20 >=20 > Regards,Alyd >=C2=A0 =C2=A0 On Saturday, August 11, 2018, 11:04:54 PM GMT+8, Ian Lepore = wrote:=C2=A0=20 >=20 > On Sat, 2018-08-11 at 11:49 +0000, lyd mc via freebsd-arm wrote: >> Hi List, >> Can you help me make I2C work in this board? >> I can detect the controller but cannot access it through iic ioctl.=20 >>=20 >> root@nanopi-neo:~/prog/I2C # dmesg |grep iic >> iichb0: mem 0x1c2ac00- >> 0x1c2afff irq 34 on simplebus0 >> iicbus0: on iichb0 >> iichb1: mem 0x1c2b000- >> 0x1c2b3ff irq 35 on simplebus0 >> iicbus1: on iichb1 >> iichb2: mem 0x1c2b400- >> 0x1c2b7ff irq 36 on simplebus0 >> iicbus2: on iichb2 >> iic0: on iicbus0 >> iic1: on iicbus1 >> iic2: on iicbus2 >>=20 >> kdump output: >>=20 >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 NAMI=C2=A0 "/dev/iic0" >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 openat 3 >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0xbfbfec= d4) >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No such fi= le or directory >>=20 >> This seems to work on my RPI. >>=20 >=20 > In this case, I wonder if the "errno 2" is not ENOENT, but > rather IIC_ENOACK which has not been translated to a proper errno > before returning. IIC_ENOACK is basically a timeout and can happen if > the slave address is wrong, or if the pinmux is wrong so that the bus > is electrically inactive. >=20 > Is the bus working in general? Do any devices show up on a scan with >=20 >=C2=A0 i2c -f /dev/iic0 -s >=20 > -- Ian >=20 the driver has timing issues (among others :-). I=E2=80=99m cc=E2=80=99ing = the guys I got a =E2=80=98working=E2=80=99=C2=A0 twsi stuff=20 to see if I can pass it on. danny =20 From owner-freebsd-arm@freebsd.org Sat Aug 11 16:58:19 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE1F11073D16 for ; Sat, 11 Aug 2018 16:58:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 644908912B for ; Sat, 11 Aug 2018 16:58:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id w11-v6so10509441iob.2 for ; Sat, 11 Aug 2018 09:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1QLuUpyF4QExTPSy3xXbuSqQGA+XNY/7IAwNQFr2U7Q=; b=x8x8De5EBuVanWhAHR19gmaUXBSAV8Nlh7nLl/UqQTpf7TqriG6Z3KCsnWjKw46tpH kYLSfj+wxn01xP5b+zUksLJvkOA7VIaPXEFXGjxT4tLsVKxh8/vDQEiYcficlh5Q7NnO V0v5bc2PaDYUfevCWU6EnKb54mZmdZDnGg7sk+3kqAeWpvBS6QsemiFien45mXX7XI2V 0h9y+aRLb1Cgt7uX84dfXoc57RGH4+1bCVj7zm49BVec+4388p35g5dwWOJRM7Af9Vd1 WE1ZmiGZsqVOgKlZGzzq6fgd0Kj1ryN9YF052ESTrsBsEdCciEAR3uKZDfaIfvdffQRY Cg1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1QLuUpyF4QExTPSy3xXbuSqQGA+XNY/7IAwNQFr2U7Q=; b=csFOMs4+1TStKdwht/uZtJ0WUwHjegAU2k//KuCozkuBsNAIzPg+1NUMod+pfs6dpj KFY4f0RZsbw+1ekepDQtkD/N0eiZ6770up+g3ZaPPcvTjoOH37Az/jcw9p8MZICc31Tj 4W4Ql246VqG2BWqssMJrunXnLzb2u4W8T03m1FGAWYhWnsWchf3cnuj7gqqa02owzb3m eN/98s+LSYsesWkMndIGonNt31ug3xzQ7t2QVq/nHm5YEhaObvOWntof4ZzktwFdpOuJ 8ZpDSfT25jXV7RkDkHntYjbnQ4Jr5F9KKi0RdLgRn9ruIWGwFC5YrLL21PktvvXqUfPn I78Q== X-Gm-Message-State: AOUpUlFVnS2xIM9VuIZfUKTbadXdmH82l3aFhsIAmy6frx6nwpTPfEIF fr+KKcvuLDA2kcXNcF/9LA4nPm/oISO2qdBemdwOAXy0 X-Google-Smtp-Source: AA+uWPy5fKPPDrxrnGhvpVHRVRnRdUCQHWdKZCuwrKg9NPUvzV6EMZq13aMqBde/mz37U+ATvUc9CIqCue93R9ZQRmA= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr9347418ioa.168.1534006698486; Sat, 11 Aug 2018 09:58:18 -0700 (PDT) MIME-Version: 1.0 References: <201808111507.w7BF7Fmi028163@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201808111507.w7BF7Fmi028163@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sat, 11 Aug 2018 10:33:16 -0600 Message-ID: Subject: Re: Kill old, non-INTRNG code on ARM To: "Rodney W. Grimes" Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 16:58:20 -0000 On Sat, Aug 11, 2018, 9:07 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > One last thing, even though we're in a slush, is to kill the pre-INTRNG > > code. > > > > It's required for armv6 and v7 for some time (only the Amlogic 8726 > boards > > remain broken there). And we're down to two families of chips which > support > > armv5: rt1310 and the Marvel gear. Both of them support INTRNG. > > > > I propose we eliminate the INTRNG option and unifdef the code to remove > the > > undefined case. > > > > Comments? > > Where is the deprication policy? > This is dead code elimination only... ;) Warner > From owner-freebsd-arm@freebsd.org Sat Aug 11 17:11:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB85E10744A3 for ; Sat, 11 Aug 2018 17:11:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5580F89CE1 for ; Sat, 11 Aug 2018 17:11:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: a4d59bb0-9d89-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id a4d59bb0-9d89-11e8-aff6-0b9b8210da61; Sat, 11 Aug 2018 17:11:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7BHBrEl064264; Sat, 11 Aug 2018 11:11:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1534007513.31375.9.camel@freebsd.org> Subject: Re: Kill old, non-INTRNG code on ARM From: Ian Lepore To: Warner Losh , "freebsd-arm@freebsd.org" Date: Sat, 11 Aug 2018 11:11:53 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 17:11:59 -0000 On Sat, 2018-08-11 at 08:52 -0600, Warner Losh wrote: > One last thing, even though we're in a slush, is to kill the pre- > INTRNG > code. > > It's required for armv6 and v7 for some time (only the Amlogic 8726 > boards > remain broken there). And we're down to two families of chips which > support > armv5: rt1310 and the Marvel gear. Both of them support INTRNG. > > I propose we eliminate the INTRNG option and unifdef the code to > remove the > undefined case. > > Comments? > Wait a sec, the INTRNG option can't go away, it's used by multiple arches these days. What we can do is make it on-by-default for arm* arches, and eliminate any #if[n]def INTRNG in arm-specific code. -- Ian From owner-freebsd-arm@freebsd.org Sat Aug 11 17:55:36 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE7FC10757FC for ; Sat, 11 Aug 2018 17:55:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 691AB8B6D3 for ; Sat, 11 Aug 2018 17:55:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id g141-v6so7286418ita.4 for ; Sat, 11 Aug 2018 10:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LItvOatXyPFAIpPMiDnrqVb1cIDsx/SlKtKNmTsOhm8=; b=pKrsk+oCEQWh425rgJhx0vSP4KcVQagmEUqOrK05OS35myWJK4jw5HipgLF3ArBj8v dn3vpyNPffIa04hGpI2kDSCGDtWLn9ZJzxND3j9/g7J2aEqHq4O99k9G/+2t7pF8yH9+ r8ToC5/CVm6ZMUbbSlXcraZNbdR9/sI4xkA/eC+gHkt9K1/cp9zeGiYYej1D97pTwtHq iEz3oFX1EZulb3gXO2FRSF0aPoSiGs2rL9+nAcDRJKZB91MotR5f6UD/9M0r3NTzTSoF edsXizZgLJzWdRXobobuMzMeN4fv9DHYa7bAnA75yLjTeVojInX7phRCV/Cj65cM8rSa uX0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LItvOatXyPFAIpPMiDnrqVb1cIDsx/SlKtKNmTsOhm8=; b=n/UIh4gKHl0FKfoIHXg8hX3sX33IujP7JQv6GzyhT/s41+K2IrNJqPTQh4x+hS4mR7 eBp2A0NsHHA5CbVfBqAtoX/i3uxbUHF+z/SQWiEUsio3MFio8Jg+XqBuMl2uLkMAi10f /162ymdEb7fqFFNCdiCdgyzFFR8LyfY598qpjq2IPRLTfsVFtSmvwjlj7BbYtLHHigsg 6t9TNYiFWETP9LEE5fX9dUxkj85SEyHJ90aZI4u++ligAmHWEBFgZSBzU13salwBKdoS YkdueBATbbDy3Ck4Lp2mouEC13LNN+7Sscgt8qiixoeIDLePGyAkDAKeVH7KTb7h+0au EcQQ== X-Gm-Message-State: AOUpUlGNyDSmz2BoJ0/yGGoBmf73VileDIw2IOf0yyOK/rK/FpmB4PZn hRbMeR0rq41qeFtrTOtucmiXC+yyyl4DnUzErPGKNw== X-Google-Smtp-Source: AA+uWPy921x0cRt79lkK92Ji9+spAMdPKH0cY4TQMsYkaKSWrmuPptH0Ofi+Civj5ZLGSnqbmGfCNcUD44NFQ8ViuvE= X-Received: by 2002:a02:a701:: with SMTP id k1-v6mr9979900jam.140.1534010134692; Sat, 11 Aug 2018 10:55:34 -0700 (PDT) MIME-Version: 1.0 References: <1534007513.31375.9.camel@freebsd.org> In-Reply-To: <1534007513.31375.9.camel@freebsd.org> From: Warner Losh Date: Sat, 11 Aug 2018 11:40:14 -0600 Message-ID: Subject: Re: Kill old, non-INTRNG code on ARM To: Ian Lepore Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 17:55:36 -0000 On Sat, Aug 11, 2018, 11:11 AM Ian Lepore wrote: > On Sat, 2018-08-11 at 08:52 -0600, Warner Losh wrote: > > One last thing, even though we're in a slush, is to kill the pre- > > INTRNG > > code. > > > > It's required for armv6 and v7 for some time (only the Amlogic 8726 > > boards > > remain broken there). And we're down to two families of chips which > > support > > armv5: rt1310 and the Marvel gear. Both of them support INTRNG. > > > > I propose we eliminate the INTRNG option and unifdef the code to > > remove the > > undefined case. > > > > Comments? > > > > Wait a sec, the INTRNG option can't go away, it's used by multiple > arches these days. What we can do is make it on-by-default for arm* > arches, and eliminate any #if[n]def INTRNG in arm-specific code. > Yes. That's a better way of saying what I had in mind. GC the code that will never compile on arm so we don't have to support it on 12. Or rather trip over it... Warner > From owner-freebsd-arm@freebsd.org Sat Aug 11 19:14:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 111B110772C3 for ; Sat, 11 Aug 2018 19:14:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 746518D967 for ; Sat, 11 Aug 2018 19:14:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id y10-v6so10703718ioa.10 for ; Sat, 11 Aug 2018 12:14:24 -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=HeygdkXhe0gwl4n1Px+evdbYW7zmzrqBp5FmMv/5C10=; b=Uz+RWbXr9W6vz4d3G4C3aNlAFaHu5mp4braUgT4PaD8zqJ125GAICEw0gRdGFpmLIf tNbmgSsAMThzv/YX4DJzW24dUfqmCGys5/ls8NbiI/9znqAE6sn4VkMEMBOvzry6ZWtx K3dVyl+wkohZ8G/VOeIAxAZoqVvsV2trwUnvjMg7deZ20uzNsiGnnT6FAqW0Beqtlwot XcWRFc12FpxlyquQEuOmsV1SaRisiaJurH8l+0OI9c7sMnjAshccWinD19AlmliKJY1g XEShJcR9LbSI+LxD4SKZ+YYMF/tZEU7RWm23zUn47uPQDjdxpmYFRtWbFmZIZtu6Wh1Y 0Zhg== 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=HeygdkXhe0gwl4n1Px+evdbYW7zmzrqBp5FmMv/5C10=; b=g+fwEwuN//BxPujB+RcVFr5F+zSuJmg0M2fyG/giT4fwnsP+UpopoTcoXPlX/ug5Jn bWBrf16wUzIfp9s1JF43pWI/ks8xjhuAM35o7trGP05xycZvg2BO+Xcm5KeNXhk8ZdwT dX7TkWGPIMdGy/Z3VEIdmsEZYvDn8SDhUL3wgsq0Lf69jOxpuDhlOmDdwPqX9b+YTxyb gBUv2h+kEfbYtJ7GTfb66bVLq0NELk6TL9GzjDY/l9VetXAHLz20ZMVFplaRa6yyCHJI 2jfrSIdLNHyxks+PDsGHSzz8VOpEd52/zs4BoHdJaWu1wXRTK0cb5263MLTsFILDFItv nevg== X-Gm-Message-State: AOUpUlGOX/YTtYh+PdevOXgb810x9KG3OEx5gWehStOp5hd4u+7YdLUW 8CpRkD3dbjzO7TNgbcPHgJpPmlAbuPDz4Nm36pMBKA== X-Google-Smtp-Source: AA+uWPw65yCT2BKBPNeJjWisRhBdqa0zZ2nickyyA8jD7/hpyblXkkT+bQoe9WaK9tpxmIGNwjEWq5MGPMM5npr6eBc= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr9627337ioa.168.1534014863629; Sat, 11 Aug 2018 12:14:23 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 12:14:23 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <64850.63077.qm@web101706.mail.ssk.yahoo.co.jp> <387823.67007.qm@web101711.mail.ssk.yahoo.co.jp> <812183.70978.qm@web101705.mail.ssk.yahoo.co.jp> <892631.23713.qm@web101718.mail.ssk.yahoo.co.jp> <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> <920419.9428.qm@web103910.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Sat, 11 Aug 2018 13:14:23 -0600 X-Google-Sender-Auth: bF7821FZHm4Sl5aZs6zVdF8LCt0 Message-ID: Subject: Re: solved Re: still hang up arm/ralink To: Mori Hiroki Cc: Michael Zhilin , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 19:14:25 -0000 On Sat, Aug 11, 2018 at 9:25 AM, Warner Losh wrote: > > > On Thu, Aug 9, 2018 at 11:52 PM, Mori Hiroki > wrote: > >> Hi. >> >> ----- Original Message ----- >> >From: Warner Losh >> >To: Mori Hiroki >> >Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" < >> freebsd-arm@freebsd.org> >> >Date: 2018/8/10, Fri 11:16 >> >Subject: Re: solved Re: still hang up arm/ralink >> > >> > >> >Mori-san >> > >> > >> >I took your advice and bought a Buffalo WZR2-G300N off ebay. It arrived >> while I was on vacation. So, I spent a few minutes with it today. I've >> installed header for serial port, puzzled out the pins, found your blog >> that had the pins and the piece I was missing (the baud rate). I now have >> added it to my test lab's terminal server and hope to start building images >> for it once I get my test lab's CI infrastructure up and running. >> > >> >> Thanks for your cooperation. >> >> > >> >So, now I'm sitting at the "RT2860-EVB#" prompt from uboot hoping to >> boot the RT1310 kernel. However, I lack instructions and can't seem to find >> all the details in your posts or on your blog. How do I load/create the RAM >> disk referenced in the kernel config file "options >> ROOTDEVNAME=\"cd9660:/dev/cfid0s.rootfs.uzip\"" ? what address do I >> load the kernel at (0x40800000 is listed in a diagram, but 0x40000100 is >> shown in the dmesg) and which variation of the kernel should I use? Thanks >> for any help you can offer. >> > >> >> I use ZRouter build system. But I am a suggestion normal build system. >> >> I think Buffalo WZR2-G300N is different u-boot on US and Japan model. >> Because of my target prompt is "5VT1310-EVB#". Be careful operation. >> You can find some information in printenv at u-boot. >> >> Sorry I forget memory address setting in build system. I add this to >> review. >> >> https://reviews.freebsd.org/D16622 >> >> In this setting build kernel header is this. >> >> % readelf -h Buffalo_WZR2-G300N_kernel >> ELF Header: >> Magic: 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 >> Class: ELF32 >> Data: 2's complement, little endian >> Version: 1 (current) >> OS/ABI: UNIX - FreeBSD >> ABI Version: 0 >> Type: EXEC (Executable file) >> Machine: ARM >> Version: 0x1 >> Entry point address: 0xc0000100 >> Start of program headers: 52 (bytes into file) >> Start of section headers: 3633180 (bytes into file) >> Flags: 0x5000202, has entry point, Version5 >> EABI, >> Size of this header: 52 (bytes) >> Size of program headers: 32 (bytes) >> Number of program headers: 6 >> Size of section headers: 40 (bytes) >> Number of section headers: 37 >> Section header string table index: 34 >> >> Do opjcopy and compress and make u-boot image by load and entry address >> is 0x40000100. >> >> % file Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot >> >> Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot: u-boot legacy uImage, >> FreeBSD Kernel Image, Linux/ARM, OS Kernel Image (lzma), 999004 bytes, Wed >> Aug 8 22:50:36 2018, Load Address: 0x40000100, Entry Point: 0x40000100, >> Header CRC: 0xFEC4D6B9, Data CRC: 0xE650EDDF >> >> It can execute on memory. (not flash) >> You need set ipaddr and serverip on u-boot. >> >> 5VT1310-EVB# tftpboot 00800000 Buffalo_WZR2-G300N_kernel.kbin >> .oldlzma.uboot >> TFTP from server 10.10.10.3; our IP address is 10.10.10.190 >> Filename 'Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot'. >> Load address: 0x800000 >> Loading: ############################################################ >> ##### >> ################################################################# >> ################################################################# >> # >> done >> Bytes transferred = 999068 (f3e9c hex) >> 5VT1310-EVB# bootm >> ## Booting image at 00800000 ... >> Image Name: FreeBSD Kernel Image >> Image Type: ARM Linux Kernel Image (lzma compressed) >> Data Size: 999004 Bytes = 975.6 kB >> Load Address: 40000100 >> Entry Point: 40000100 >> Verifying Checksum ... OK >> Uncompressing LZMA Kernel Image .............................. >> ............OK >> >> Starting kernel @40000100... >> >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2018 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> >> If you can execute kernel then stop at rootfs mount. >> >> I think this is first step. >> > > Where do I find oldlzma utility? The current one produces an unbootable > image: > > % objcopy -S -O binary kernel kernel.kbin > % lzma kernel.kbin > % mkimage -A arm -O FreeBSD -T kernel -C lzma -a 0x40000100 -e 0x40000100 > -n rt1310 -d kernel.kbin.lzma kernel.kbin.lzma.u-boot > Image Name: rt1310 > Created: Sat Aug 11 09:06:27 2018 > Image Type: ARM FreeBSD Kernel Image (lzma compressed) > Data Size: 1317305 Bytes = 1286.43 KiB = 1.26 MiB > Load Address: 40000100 > Entry Point: 40000100 > % scp kernel.kbin.lzma.u-boot tftp:tftpboot > ... > RT2860-EVB# bootm > ## Booting image at 00800000 ... > Image Name: rt1310 > Image Type: ARM Unknown OS Kernel Image (lzma compressed) > Data Size: 1317305 Bytes = 1.3 MB > Load Address: 40000100 > Entry Point: 40000100 > Verifying Checksum ... OK > Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to > recover > OK > > I see you have 'oldlzma' and online instructions use an oldlzma command... > I built oldlzma from zrouter and have the same results... Warner > Warner > > >> Thanks >> >> Hiroki Mori >> >> > >> >Warner >> > >> > >> >On Sat, Mar 10, 2018 at 2:31 AM, Mori Hiroki >> wrote: >> > >> >Hi >> >> >> >>I do try to todays current. It' work find on RT1310. >> >> >> >>https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a15e4a b5 >> >> >> >> >> >>Thanks >> >> >> >>Hiroki Mori >> >>______________________________ _________________ >> >>freebsd-arm@freebsd.org mailing list >> >>https://lists.freebsd.org/ mailman/listinfo/freebsd-arm >> >>To unsubscribe, send any mail to "freebsd-arm-unsubscribe@ freebsd.org" >> >> >> > >> > >> > >> > > From owner-freebsd-arm@freebsd.org Sat Aug 11 20:30:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73C511078D85 for ; Sat, 11 Aug 2018 20:30:53 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 0EE149018A; Sat, 11 Aug 2018 20:30:52 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id B102BE1; Sat, 11 Aug 2018 22:30:44 +0200 (CEST) Received: from [192.168.222.5] (unknown [192.168.222.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 318B31350F91D; Sat, 11 Aug 2018 17:30:39 -0300 (BRT) From: "Dr. Rolf Jansen" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: BeagleBone Black with a I2C Digital Analog Converter Date: Sat, 11 Aug 2018 17:30:38 -0300 In-Reply-To: <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> Cc: freebsd-arm@FreeBSD.org To: Ian Lepore References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 20:30:53 -0000 > Am 08.08.2018 um 14:05 schrieb Dr. Rolf Jansen : >=20 >> Am 08.08.2018 um 12:45 schrieb Ian Lepore >: >>=20 >> On Wed, 2018-08-08 at 10:59 -0300, Dr. Rolf Jansen wrote: >>>=20 >>> ... >>> Please can somebody, check this, and perhaps give some hints in case = I got something wrong? I don't have an oscilloscope, a multimeter only, = can I check somehow if I specified the correct pins? >>>=20 >>> What needs to be done next? I guess, I need to write a simple device = driver, don't I? Or can I use somehow the iicbb(4) =E2=80=93 I2C generic = bit-banging driver, since actually that DAC chip needs bit banging only = -- repeatedly write 3 byte in row. I yes, how can I use it for my = purpose? >>=20 >> At this point, i2c(8) is your friend, it lets you do i2c bus >> transactions from the commandline without a device-specific driver = for >> each i2c device. A good starting point is a bus scan: >>=20 >> i2c -f /dev/iic1 -s >>=20 >> If the bus is working you should see something like: >>=20 >> Scanning I2C devices on /dev/iic1: 60 >=20 > Ian, thank you very much for your response. >=20 > As a matter of fact, the source of all my doubts told in the initial = post above is that yesterday after hours in a trial&error circle, I was = not able to get a sensible response from the exact bus scan command = which suggested: >=20 > i2c -f /dev/iic1 -s -v >=20 > Up to now, by no means I was able to see anything else than: >=20 > dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1 > Hardware may not support START/STOP scanning; trying less-reliable = read method. >=20 > This START/STOP thing let me to think that I perhaps need to get = attached a device driver. >=20 > I am also still in doubt, whether I really got the pinmux straight. I = checked very carefully the physical connections, anyway I am stuck at = this point. I got it working. 1.) The specification of the DAC board which I attached to my BBB was = wrong in regards to the acceptable Vcc voltage range (2.7 to 5.5 V). I = started to use it with 5 V, and by no means I got any response from it. = After doing a full u-turn around the block =E2=80=93 to no avail I tried = all possible settings with FreeBSD 11.2, then all with Debian/Linux 9, = then all with new spare DAC board =E2=80=93 I switched the Vcc to the = 3.3 V supply, and it works. Halleluja! I am back on FreeBSD 12-CURRENT, = and I can live with 3.3 V, since I need to pass the DAC output through a = scaling OpAmp anyway in order to have 0 ... 10 V.=20 2. There is still something wrong with my overlay. I need to hack in the = same I2C1 changes into the main DT, and then the bus scan by i2c -f = /dev/iic1 -s gives me the expected output. For my present project this = is a minor issue, though. My best guess here is, that there is a problem = with the reference of the I2C1 node to the proposed pinmux node. On Debian/Linux the very overlay does work. Best regards Rolf From owner-freebsd-arm@freebsd.org Sat Aug 11 20:42:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E5541079159 for ; Sat, 11 Aug 2018 20:42:30 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.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 A1ABF90ABE for ; Sat, 11 Aug 2018 20:42:29 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 0aacc66f-9da7-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 0aacc66f-9da7-11e8-904b-1d2e466b3c59; Sat, 11 Aug 2018 20:42:21 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7BKgJcU064573; Sat, 11 Aug 2018 14:42:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1534020139.31375.16.camel@freebsd.org> Subject: Re: BeagleBone Black with a I2C Digital Analog Converter From: Ian Lepore To: "Dr. Rolf Jansen" Cc: freebsd-arm@FreeBSD.org Date: Sat, 11 Aug 2018 14:42:19 -0600 In-Reply-To: References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> Content-Type: text/plain; charset="windows-1251" 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 20:42:30 -0000 On Sat, 2018-08-11 at 17:30 -0300, Dr. Rolf Jansen wrote: > > > > Am 08.08.2018 um 14:05 schrieb Dr. Rolf Jansen : > > > > > > > > Am 08.08.2018 um 12:45 schrieb Ian Lepore > > >: > > > > > > On Wed, 2018-08-08 at 10:59 -0300, Dr. Rolf Jansen wrote: > > > > > > > > > > > > ... > > > > Please can somebody, check this, and perhaps give some hints in > > > > case I got something wrong? I don't have an oscilloscope, a > > > > multimeter only, can I check somehow if I specified the correct > > > > pins? > > > > > > > > What needs to be done next? I guess, I need to write a simple > > > > device driver, don't I? Or can I use somehow the iicbb(4) – I2C > > > > generic bit-banging driver, since actually that DAC chip needs > > > > bit banging only -- repeatedly write 3 byte in row. I yes, how > > > > can I use it for my purpose? > > > At this point, i2c(8) is your friend, it lets you do i2c bus > > > transactions from the commandline without a device-specific > > > driver for > > > each i2c device. A good starting point is a bus scan: > > > > > >   i2c -f /dev/iic1 -s > > > > > > If the bus is working you should see something like: > > > > > >   Scanning I2C devices on /dev/iic1: 60 > > Ian, thank you very much for your response. > > > > As a matter of fact, the source of all my doubts told in the > > initial post above is that yesterday after hours in a trial&error > > circle, I was not able to get a sensible response from the exact > > bus scan command which suggested: > > > > i2c -f  /dev/iic1 -s -v > > > > Up to now, by no means I was able to see anything else than: > > > > dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1 > > Hardware may not support START/STOP scanning; trying less-reliable > > read method. > > > > This START/STOP thing let me to think that I perhaps need to get > > attached a device driver. > > > > I am also still in doubt, whether I really got the pinmux straight. > > I checked very carefully the physical connections, anyway I am > > stuck at this point. > I got it working. > > 1.) The specification of the DAC board which I attached to my BBB was > wrong in regards to the acceptable Vcc voltage range (2.7 to 5.5 V). > I started to use it with 5 V, and by no means I got any response from > it. After doing a full u-turn around the block – to no avail I tried > all possible settings with FreeBSD 11.2, then all with Debian/Linux > 9, then all with new spare DAC board – I switched the Vcc to the 3.3 > V supply, and it works. Halleluja! I am back on FreeBSD 12-CURRENT, > and I can live with 3.3 V, since I need to pass the DAC output > through a scaling OpAmp anyway in order to have 0 ... 10 V.  > > 2. There is still something wrong with my overlay. I need to hack in > the same I2C1 changes into the main DT, and then the bus scan by i2c > -f  /dev/iic1 -s gives me the expected output. For my present project > this is a minor issue, though. My best guess here is, that there is a > problem with the reference of the I2C1 node to the proposed pinmux > node. > > On Debian/Linux the very overlay does work. > > Best regards > > Rolf > Ah.  The board probably does support 2.7-5.5v, but if the i2c bus has pullups that only pull the lines up to 3.3v, that may be too close to the VIH transition levels for the DAC chip running at 5v. Even if it's within the VIH range, if the pulls aren't strong enough the clock signal may not rise above the 5v VIH fast enough for reliable comms. -- Ian From owner-freebsd-arm@freebsd.org Sat Aug 11 20:48:44 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED30F1079342 for ; Sat, 11 Aug 2018 20:48:43 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DF1890D25 for ; Sat, 11 Aug 2018 20:48:43 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:subject:to:message-id; s=default; bh=iOvyXXLK/U0vge+W9OQGd54zcAR9HCQFMpswp2/aJjM=; b=BUMa1HlfNBG0wvjT3QZDUWFyas7ifUxgJ9SvFp/KnS5SdpkFWnOxqPFKFrG0oLCh6Nn/8DqUJMk/wUhmKVbYhJiHCrbIXAR6P6rE/QxTJiuf5urAF0ZXuyp6PqaGvJkalbRzD6ez/llbpwNan3nC/DPTZ8R3JW8rrVk34YtullI= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 3c96ca4f TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 11 Aug 2018 20:48:38 +0000 (UTC) Date: Sat, 11 Aug 2018 23:48:40 +0300 From: Greg V Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Ganbold Tsagaankhuu Cc: freebsd-arm Message-Id: <1534020520.35460.1@hraggstad.unrelenting.technology> In-Reply-To: References: <1533577708.4175.0@hraggstad.unrelenting.technology> X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 20:48:44 -0000 On Sat, Aug 11, 2018 at 3:09 PM, Ganbold Tsagaankhuu wrote: > > > On Tue, Aug 7, 2018 at 1:48 AM, Greg V > wrote: >> Hi, >> >> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 >> ROCKPro64 board): >> >> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 >> > > Very nice. I have NanoPC-T4 board and will test your patch. > Did you try to load kernel via tftp at u-boot prompt? like: > > tftpboot 0x02000000 kernel.bin, go 0x02000000 > > Does it work for you that way? kernel.bin?? EFI has always been the way to go with aarch64 (and I think it's even recommended on armv7/6 too). I do it like this: env set serverip 192.168.1.2 env set bootargs boot.nfsroot.server=${serverip} boot.nfsroot.path=/some/path comconsole_speed=${baudrate} tftpboot ${kernel_addr_r} loader.efi tftpboot ${fdt_addr_r} dtb/rockchip/rk3328-rock64.dtb bootefi ${kernel_addr_r} ${fdt_addr_r} But the more-automated way (fully configured by dhcp) should work too, at least if you don't have dhcp and tftp on different servers From owner-freebsd-arm@freebsd.org Sat Aug 11 23:23:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 886D91055A30 for ; Sat, 11 Aug 2018 23:23:18 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD88895211 for ; Sat, 11 Aug 2018 23:23:17 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w7BNN5Tk074512 for ; Sun, 12 Aug 2018 09:23:05 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: "freebsd-arm@freebsd.org" References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> <20180810044426.GB32974@www.zefox.net> <20180811163209.GA38922@www.zefox.net> From: Trev Message-ID: <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> Date: Sun, 12 Aug 2018 09:23:05 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20180811163209.GA38922@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Sun, 12 Aug 2018 09:23:05 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 23:23:18 -0000 bob prohaska wrote on 12/08/2018 02:32: > Simply moving all swap to microSD (and leaving vm.pageout_oom_seq at the > default value of 12) allowed an uneventul -j4 buildworld on r337226M, > upgrading to r337564M with the patches suggested to date still in place. > There were no warnings or errors on the console or controlling terminal. > > The microSD card used for /root, /tmp and swap is a Sandisk Ultra, supposedly > a notch or two slower than the Sandisk Extreme USB flash drive that caused > all the trouble. Curious, my experience was the opposite - the 16G SanDisk Ultra had OOM swap issues with -j4 buildworld, whereas the 32G SanDisk Extreme doesn't. Both cards were new at the time. Note: in my case all file systems were on the micro-SD card except for /tmp/ (100M), /var/tmp (15M) and /var/log (15M) which were memory disks. I'd retest with the sysctl and patches but I have to be interstate again for a few days :(