From owner-freebsd-arm@freebsd.org Sun Dec 1 01:16:21 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 50E0F1BFABB; Sun, 1 Dec 2019 01:16:21 +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 47QVgl67Tsz3Hbd; Sun, 1 Dec 2019 01:16: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 xB11GGSH045957 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Nov 2019 17:16:17 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id xB11GGGk045956; Sat, 30 Nov 2019 17:16:16 -0800 (PST) (envelope-from fbsd) Date: Sat, 30 Nov 2019 17:16:15 -0800 From: bob prohaska To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Rpi3 panic: non-current pmap 0xfffffd001e05b130 Message-ID: <20191201011615.GA45887@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 47QVgl67Tsz3Hbd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.811,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.30), ipnet: 50.1.16.0/20(0.15), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.63)[-0.633,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 01:16:21 -0000 A Pi3 running r355024 reported a panic while doing a -j3 make of www/chromium: panic: non-current pmap 0xfffffd001e05b130 cpuid = 0 time = 1575161361 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff000000729e4c lr = 0xffff0000001066c8 sp = 0xffff000059f3e2b0 fp = 0xffff000059f3e4c0 db_trace_self_wrapper() at vpanic+0x18c pc = 0xffff0000001066c8 lr = 0xffff000000400d7c sp = 0xffff000059f3e4d0 fp = 0xffff000059f3e580 vpanic() at panic+0x44 pc = 0xffff000000400d7c lr = 0xffff000000400b2c sp = 0xffff000059f3e590 fp = 0xffff000059f3e610 panic() at pmap_remove_pages+0x8d4 pc = 0xffff000000400b2c lr = 0xffff00000074154c sp = 0xffff000059f3e620 fp = 0xffff000059f3e6e0 pmap_remove_pages() at vmspace_exit+0xc0 pc = 0xffff00000074154c lr = 0xffff0000006c9c00 sp = 0xffff000059f3e6f0 fp = 0xffff000059f3e720 vmspace_exit() at exit1+0x4f8 pc = 0xffff0000006c9c00 lr = 0xffff0000003bc2a4 sp = 0xffff000059f3e730 fp = 0xffff000059f3e7a0 exit1() at sys_sys_exit+0x10 pc = 0xffff0000003bc2a4 lr = 0xffff0000003bbda8 sp = 0xffff000059f3e7b0 fp = 0xffff000059f3e7b0 sys_sys_exit() at do_el0_sync+0x514 pc = 0xffff0000003bbda8 lr = 0xffff000000747aa4 sp = 0xffff000059f3e7c0 fp = 0xffff000059f3e860 do_el0_sync() at handle_el0_sync+0x90 pc = 0xffff000000747aa4 lr = 0xffff00000072ca14 sp = 0xffff000059f3e870 fp = 0xffff000059f3e980 handle_el0_sync() at 0x404e6d60 pc = 0xffff00000072ca14 lr = 0x00000000404e6d60 sp = 0xffff000059f3e990 fp = 0x0000ffffffffd590 KDB: enter: panic [ thread pid 94966 tid 100145 ] Stopped at 0x40505460: undefined 54000042 db> bt Tracing pid 94966 tid 100145 td 0xfffffd002552b000 db_trace_self() at db_stack_trace+0xf8 pc = 0xffff000000729e4c lr = 0xffff000000103b0c sp = 0xffff000059f3de80 fp = 0xffff000059f3deb0 db_stack_trace() at db_command+0x228 pc = 0xffff000000103b0c lr = 0xffff000000103784 sp = 0xffff000059f3dec0 fp = 0xffff000059f3dfa0 db_command() at db_command_loop+0x58 pc = 0xffff000000103784 lr = 0xffff00000010352c sp = 0xffff000059f3dfb0 fp = 0xffff000059f3dfd0 db_command_loop() at db_trap+0xf4 pc = 0xffff00000010352c lr = 0xffff000000106830 sp = 0xffff000059f3dfe0 fp = 0xffff000059f3e200 db_trap() at kdb_trap+0x1d8 pc = 0xffff000000106830 lr = 0xffff0000004492fc sp = 0xffff000059f3e210 fp = 0xffff000059f3e2c0 kdb_trap() at do_el1h_sync+0xf4 pc = 0xffff0000004492fc lr = 0xffff000000747418 sp = 0xffff000059f3e2d0 fp = 0xffff000059f3e300 do_el1h_sync() at handle_el1h_sync+0x78 pc = 0xffff000000747418 lr = 0xffff00000072c878 sp = 0xffff000059f3e310 fp = 0xffff000059f3e420 handle_el1h_sync() at kdb_enter+0x34 pc = 0xffff00000072c878 lr = 0xffff000000448948 sp = 0xffff000059f3e430 fp = 0xffff000059f3e4c0 kdb_enter() at vpanic+0x1a8 pc = 0xffff000000448948 lr = 0xffff000000400d98 sp = 0xffff000059f3e4d0 fp = 0xffff000059f3e580 vpanic() at panic+0x44 pc = 0xffff000000400d98 lr = 0xffff000000400b2c sp = 0xffff000059f3e590 fp = 0xffff000059f3e610 panic() at pmap_remove_pages+0x8d4 pc = 0xffff000000400b2c lr = 0xffff00000074154c sp = 0xffff000059f3e620 fp = 0xffff000059f3e6e0 pmap_remove_pages() at vmspace_exit+0xc0 pc = 0xffff00000074154c lr = 0xffff0000006c9c00 sp = 0xffff000059f3e6f0 fp = 0xffff000059f3e720 vmspace_exit() at exit1+0x4f8 pc = 0xffff0000006c9c00 lr = 0xffff0000003bc2a4 sp = 0xffff000059f3e730 fp = 0xffff000059f3e7a0 exit1() at sys_sys_exit+0x10 pc = 0xffff0000003bc2a4 lr = 0xffff0000003bbda8 sp = 0xffff000059f3e7b0 fp = 0xffff000059f3e7b0 sys_sys_exit() at do_el0_sync+0x514 pc = 0xffff0000003bbda8 lr = 0xffff000000747aa4 sp = 0xffff000059f3e7c0 fp = 0xffff000059f3e860 do_el0_sync() at handle_el0_sync+0x90 pc = 0xffff000000747aa4 lr = 0xffff00000072ca14 sp = 0xffff000059f3e870 fp = 0xffff000059f3e980 handle_el0_sync() at 0x404e6d60 pc = 0xffff00000072ca14 lr = 0x00000000404e6d60 sp = 0xffff000059f3e990 fp = 0x0000ffffffffd590 db> The last top screen showed last pid: 94966; load averages: 1.22, 1.42, 1.40 up 0+05:10:16 16:49:20 43 processes: 1 running, 42 sleeping CPU: 3.7% user, 0.0% nice, 20.0% system, 5.5% interrupt, 70.8% idle Mem: 502M Active, 6672K Inact, 150M Laundry, 184M Wired, 90M Buf, 55M Free Swap: 7194M Total, 3835M Used, 3359M Free, 53% Inuse, 11M In, 3852K Out PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 71350 root 1 22 0 951M 144M swread 0 10:20 5.97% c++ 58502 root 1 21 0 986M 232M swread 1 11:23 3.42% c++ 77283 root 1 22 0 963M 151M swread 0 8:45 3.30% c++ 6904 root 1 22 0 1144M 191M swread 0 21:26 3.29% c++ 1091 bob 1 52 0 11M 324K wait 3 0:55 0.27% sh 1079 bob 1 20 0 13M 1636K CPU0 0 0:57 0.22% top 1074 bob 1 20 0 19M 1316K select 1 0:13 0.03% sshd 970 root 1 20 0 16M 1500K select 1 0:02 0.02% sendmail 1069 root 1 20 0 204M 1044K select 3 1:40 0.00% ninja 1050 root 1 20 0 12M 972K select 2 0:02 0.00% make 977 root 1 20 0 11M 0B nanslp 1 0:02 0.00% 957 root 1 20 0 19M 1216K select 1 0:01 0.00% sshd 824 root 1 20 0 11M 1084K select 2 0:01 0.00% syslogd 1084 bob 1 20 0 13M 1008K ttyin 0 0:00 0.00% tcsh and the last few storage activity log entries were: dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 1 713 694 4666 3.7 20 116 6.0 0 0 0.0 90.9 mmcsd0 1 713 694 4666 3.8 20 116 6.0 0 0 0.0 91.2 mmcsd0s2 2 751 734 4730 2.0 17 96 0.6 0 0 0.0 79.4 da0 1 713 694 4666 3.8 20 116 6.0 0 0 0.0 91.4 mmcsd0s2b 2 751 734 4730 2.0 17 96 0.6 0 0 0.0 79.9 da0p6 Sat Nov 30 16:48:21 PST 2019 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s2b 4404252 1958976 2445276 44% /dev/da0p6 5242880 1956872 3286008 37% Total 9647132 3915848 5731284 41% Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id 0 0 12 4523836 56064 6988 186 715 257 6931 25128 0 0 30789 1073 29817 14 26 60 dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 709 687 4588 3.9 22 144 5.8 0 0 0.0 90.5 mmcsd0 0 709 687 4588 3.9 22 144 5.8 0 0 0.0 90.9 mmcsd0s2 2 698 679 4696 2.1 19 104 0.6 0 0 0.0 75.2 da0 0 709 687 4588 3.9 22 144 5.8 0 0 0.0 91.0 mmcsd0s2b 2 698 679 4696 2.2 19 104 0.6 0 0 0.0 75.7 da0p6 Sat Nov 30 16:48:22 PST 2019 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s2b 4404252 1959032 2445220 44% /dev/da0p6 5242880 1956928 3285952 37% Total 9647132 3915960 5731172 41% Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id 0 0 12 4523836 55844 6989 186 715 257 6932 25127 604 604 30790 1073 29819 14 26 60 dT: 1.001s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 2 736 680 4829 3.9 56 292 5.0 0 0 0.0 94.4 mmcsd0 2 736 680 4829 4.0 56 292 5.0 0 0 0.0 94.6 mmcsd0s2 1 680 627 4014 1.9 53 328 1.0 0 0 0.0 71.1 da0 2 736 680 4829 4.0 56 292 5.0 0 0 0.0 94.7 mmcsd0s2b 1 680 627 4014 1.9 53 328 1.0 0 0 0.0 71.7 da0p6 Sat Nov 30 16:48:24 PST 2019 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s2b 4404252 1959324 2444928 44% /dev/da0p6 5242880 1957468 3285412 37% Total 9647132 3916792 5730340 41% Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id 0 0 12 4523836 52860 6989 186 715 257 6932 25125 1038 1038 30790 1073 29820 14 26 60 dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 1 751 702 4860 4.0 49 251 5.0 0 0 0.0 94.4 mmcsd0 1 751 702 4860 4.1 49 251 5.1 0 0 0.0 94.7 mmcsd0s2 2 704 658 4082 1.8 46 235 0.6 0 0 0.0 71.9 da0 1 751 702 4860 4.1 49 251 5.1 0 0 0.0 94.8 mmcsd0s2b 2 704 658 4082 1.8 46 235 0.7 0 0 0.0 72.6 da0p6 Sat Nov 30 16:48:26 PST 2019 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s2b 4404252 1959504 2444748 44% /dev/da0p6 5242880 1957540 3285340 37% Total 9647132 3917044 5730088 41% Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id 0 0 12 4523868 46872 6989 186 715 257 6932 25123 0 0 30790 1073 29820 14 26 60 dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 2 700 681 4888 3.7 19 108 3.7 0 0 0.0 92.1 mmcsd0 2 700 681 4888 3.8 19 108 3.7 0 0 0.0 92.5 mmcsd0s2 2 709 687 4314 2.1 22 108 3.4 0 0 0.0 78.2 da0 2 700 681 4888 3.8 19 108 3.7 0 0 0.0 92.6 mmcsd0s2b 2 709 687 4314 2.1 22 108 3.4 0 0 0.0 78.7 da0p6 Sat Nov 30 16:48:28 PST 2019 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s2b 440 It's clear the machine was heavily loaded, but storage didn't appear to be swamped. I hope the foregoing has been of some interest, thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sun Dec 1 01:52:51 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C909A1C1AF3; Sun, 1 Dec 2019 01:52:51 +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 47QWTt4xRdz3KyL; Sun, 1 Dec 2019 01:52:50 +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 xB11qrF4046037 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Nov 2019 17:52:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id xB11qqSk046036; Sat, 30 Nov 2019 17:52:52 -0800 (PST) (envelope-from fbsd) Date: Sat, 30 Nov 2019 17:52:52 -0800 From: bob prohaska To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rpi3 panic: non-current pmap 0xfffffd001e05b130 Message-ID: <20191201015252.GB45887@www.zefox.net> References: <20191201011615.GA45887@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191201011615.GA45887@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 47QWTt4xRdz3KyL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.54 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.808,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.30), ipnet: 50.1.16.0/20(0.15), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.62)[-0.619,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 01:52:51 -0000 On Sat, Nov 30, 2019 at 05:16:15PM -0800, bob prohaska wrote: > A Pi3 running r355024 reported a panic while doing a -j3 make of > www/chromium: > Ok, another panic, looks like a dying storage device. This time there was a preamble on the console: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 c3 90 d8 00 00 08 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted swap_pager: I/O error - pageout failed; blkno 1442883,size 4096, error 5 swap_pager: I/O error - pageout failed; blkno 1442884,size 4096, error 5 swap_pager: I/O error - pageout failed; blkno 1442885,size 8192, error 5 swap_pager: I/O error - pageout failed; blkno 1442887,size 4096, error 5 swap_pager: I/O error - pagein failed; blkno 1103209,size 4096, error 5 vm_fault: pager read error, pid 681 (devd) swap_pager: I/O error - pagein failed; blkno 1130270,size 4096, error 5 vm_fault: pager read error, pid 2362 (c++) Nov 30 17:37:34 www kernel: Failed to fully fault in a core file segment at VA 0x40400000 with size 0x60b000 to be written at offset 0x32b000 for process devd panic: vm_page_assert_unbusied: page 0xfffffd0030f8af80 busy @ /usr/src/sys/vm/vm_object.c:777 cpuid = 3 time = 1575164255 Earlier panics didn't have any proximate warnings on the console, but they're probably the same story. apologies for the noise! bob prohaska > panic: non-current pmap 0xfffffd001e05b130 > cpuid = 0 > time = 1575161361 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc = 0xffff000000729e4c lr = 0xffff0000001066c8 > sp = 0xffff000059f3e2b0 fp = 0xffff000059f3e4c0 > > db_trace_self_wrapper() at vpanic+0x18c > pc = 0xffff0000001066c8 lr = 0xffff000000400d7c > sp = 0xffff000059f3e4d0 fp = 0xffff000059f3e580 > > vpanic() at panic+0x44 > pc = 0xffff000000400d7c lr = 0xffff000000400b2c > sp = 0xffff000059f3e590 fp = 0xffff000059f3e610 > > panic() at pmap_remove_pages+0x8d4 > pc = 0xffff000000400b2c lr = 0xffff00000074154c > sp = 0xffff000059f3e620 fp = 0xffff000059f3e6e0 > > pmap_remove_pages() at vmspace_exit+0xc0 > pc = 0xffff00000074154c lr = 0xffff0000006c9c00 > sp = 0xffff000059f3e6f0 fp = 0xffff000059f3e720 > > vmspace_exit() at exit1+0x4f8 > pc = 0xffff0000006c9c00 lr = 0xffff0000003bc2a4 > sp = 0xffff000059f3e730 fp = 0xffff000059f3e7a0 > > exit1() at sys_sys_exit+0x10 > pc = 0xffff0000003bc2a4 lr = 0xffff0000003bbda8 > sp = 0xffff000059f3e7b0 fp = 0xffff000059f3e7b0 > > sys_sys_exit() at do_el0_sync+0x514 > pc = 0xffff0000003bbda8 lr = 0xffff000000747aa4 > sp = 0xffff000059f3e7c0 fp = 0xffff000059f3e860 > > do_el0_sync() at handle_el0_sync+0x90 > pc = 0xffff000000747aa4 lr = 0xffff00000072ca14 > sp = 0xffff000059f3e870 fp = 0xffff000059f3e980 > > handle_el0_sync() at 0x404e6d60 > pc = 0xffff00000072ca14 lr = 0x00000000404e6d60 > sp = 0xffff000059f3e990 fp = 0x0000ffffffffd590 > > KDB: enter: panic > [ thread pid 94966 tid 100145 ] > Stopped at 0x40505460: undefined 54000042 > db> bt > Tracing pid 94966 tid 100145 td 0xfffffd002552b000 > db_trace_self() at db_stack_trace+0xf8 > pc = 0xffff000000729e4c lr = 0xffff000000103b0c > sp = 0xffff000059f3de80 fp = 0xffff000059f3deb0 > > db_stack_trace() at db_command+0x228 > pc = 0xffff000000103b0c lr = 0xffff000000103784 > sp = 0xffff000059f3dec0 fp = 0xffff000059f3dfa0 > > db_command() at db_command_loop+0x58 > pc = 0xffff000000103784 lr = 0xffff00000010352c > sp = 0xffff000059f3dfb0 fp = 0xffff000059f3dfd0 > > db_command_loop() at db_trap+0xf4 > pc = 0xffff00000010352c lr = 0xffff000000106830 > sp = 0xffff000059f3dfe0 fp = 0xffff000059f3e200 > > db_trap() at kdb_trap+0x1d8 > pc = 0xffff000000106830 lr = 0xffff0000004492fc > sp = 0xffff000059f3e210 fp = 0xffff000059f3e2c0 > > kdb_trap() at do_el1h_sync+0xf4 > pc = 0xffff0000004492fc lr = 0xffff000000747418 > sp = 0xffff000059f3e2d0 fp = 0xffff000059f3e300 > > do_el1h_sync() at handle_el1h_sync+0x78 > pc = 0xffff000000747418 lr = 0xffff00000072c878 > sp = 0xffff000059f3e310 fp = 0xffff000059f3e420 > > handle_el1h_sync() at kdb_enter+0x34 > pc = 0xffff00000072c878 lr = 0xffff000000448948 > sp = 0xffff000059f3e430 fp = 0xffff000059f3e4c0 > > kdb_enter() at vpanic+0x1a8 > pc = 0xffff000000448948 lr = 0xffff000000400d98 > sp = 0xffff000059f3e4d0 fp = 0xffff000059f3e580 > > vpanic() at panic+0x44 > pc = 0xffff000000400d98 lr = 0xffff000000400b2c > sp = 0xffff000059f3e590 fp = 0xffff000059f3e610 > > panic() at pmap_remove_pages+0x8d4 > pc = 0xffff000000400b2c lr = 0xffff00000074154c > sp = 0xffff000059f3e620 fp = 0xffff000059f3e6e0 > > pmap_remove_pages() at vmspace_exit+0xc0 > pc = 0xffff00000074154c lr = 0xffff0000006c9c00 > sp = 0xffff000059f3e6f0 fp = 0xffff000059f3e720 > > vmspace_exit() at exit1+0x4f8 > pc = 0xffff0000006c9c00 lr = 0xffff0000003bc2a4 > sp = 0xffff000059f3e730 fp = 0xffff000059f3e7a0 > > exit1() at sys_sys_exit+0x10 > pc = 0xffff0000003bc2a4 lr = 0xffff0000003bbda8 > sp = 0xffff000059f3e7b0 fp = 0xffff000059f3e7b0 > > sys_sys_exit() at do_el0_sync+0x514 > pc = 0xffff0000003bbda8 lr = 0xffff000000747aa4 > sp = 0xffff000059f3e7c0 fp = 0xffff000059f3e860 > > do_el0_sync() at handle_el0_sync+0x90 > pc = 0xffff000000747aa4 lr = 0xffff00000072ca14 > sp = 0xffff000059f3e870 fp = 0xffff000059f3e980 > > handle_el0_sync() at 0x404e6d60 > pc = 0xffff00000072ca14 lr = 0x00000000404e6d60 > sp = 0xffff000059f3e990 fp = 0x0000ffffffffd590 > > db> > > The last top screen showed > > last pid: 94966; load averages: 1.22, 1.42, 1.40 up 0+05:10:16 16:49:20 > 43 processes: 1 running, 42 sleeping > CPU: 3.7% user, 0.0% nice, 20.0% system, 5.5% interrupt, 70.8% idle > Mem: 502M Active, 6672K Inact, 150M Laundry, 184M Wired, 90M Buf, 55M Free > Swap: 7194M Total, 3835M Used, 3359M Free, 53% Inuse, 11M In, 3852K Out > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 71350 root 1 22 0 951M 144M swread 0 10:20 5.97% c++ > 58502 root 1 21 0 986M 232M swread 1 11:23 3.42% c++ > 77283 root 1 22 0 963M 151M swread 0 8:45 3.30% c++ > 6904 root 1 22 0 1144M 191M swread 0 21:26 3.29% c++ > 1091 bob 1 52 0 11M 324K wait 3 0:55 0.27% sh > 1079 bob 1 20 0 13M 1636K CPU0 0 0:57 0.22% top > 1074 bob 1 20 0 19M 1316K select 1 0:13 0.03% sshd > 970 root 1 20 0 16M 1500K select 1 0:02 0.02% sendmail > 1069 root 1 20 0 204M 1044K select 3 1:40 0.00% ninja > 1050 root 1 20 0 12M 972K select 2 0:02 0.00% make > 977 root 1 20 0 11M 0B nanslp 1 0:02 0.00% > 957 root 1 20 0 19M 1216K select 1 0:01 0.00% sshd > 824 root 1 20 0 11M 1084K select 2 0:01 0.00% syslogd > 1084 bob 1 20 0 13M 1008K ttyin 0 0:00 0.00% tcsh > > and the last few storage activity log entries were: > > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 1 713 694 4666 3.7 20 116 6.0 0 0 0.0 90.9 mmcsd0 > 1 713 694 4666 3.8 20 116 6.0 0 0 0.0 91.2 mmcsd0s2 > 2 751 734 4730 2.0 17 96 0.6 0 0 0.0 79.4 da0 > 1 713 694 4666 3.8 20 116 6.0 0 0 0.0 91.4 mmcsd0s2b > 2 751 734 4730 2.0 17 96 0.6 0 0 0.0 79.9 da0p6 > Sat Nov 30 16:48:21 PST 2019 > Device 1K-blocks Used Avail Capacity > /dev/mmcsd0s2b 4404252 1958976 2445276 44% > /dev/da0p6 5242880 1956872 3286008 37% > Total 9647132 3915848 5731284 41% > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id > 0 0 12 4523836 56064 6988 186 715 257 6931 25128 0 0 30789 1073 29817 14 26 60 > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 0 709 687 4588 3.9 22 144 5.8 0 0 0.0 90.5 mmcsd0 > 0 709 687 4588 3.9 22 144 5.8 0 0 0.0 90.9 mmcsd0s2 > 2 698 679 4696 2.1 19 104 0.6 0 0 0.0 75.2 da0 > 0 709 687 4588 3.9 22 144 5.8 0 0 0.0 91.0 mmcsd0s2b > 2 698 679 4696 2.2 19 104 0.6 0 0 0.0 75.7 da0p6 > Sat Nov 30 16:48:22 PST 2019 > Device 1K-blocks Used Avail Capacity > /dev/mmcsd0s2b 4404252 1959032 2445220 44% > /dev/da0p6 5242880 1956928 3285952 37% > Total 9647132 3915960 5731172 41% > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id > 0 0 12 4523836 55844 6989 186 715 257 6932 25127 604 604 30790 1073 29819 14 26 60 > dT: 1.001s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 2 736 680 4829 3.9 56 292 5.0 0 0 0.0 94.4 mmcsd0 > 2 736 680 4829 4.0 56 292 5.0 0 0 0.0 94.6 mmcsd0s2 > 1 680 627 4014 1.9 53 328 1.0 0 0 0.0 71.1 da0 > 2 736 680 4829 4.0 56 292 5.0 0 0 0.0 94.7 mmcsd0s2b > 1 680 627 4014 1.9 53 328 1.0 0 0 0.0 71.7 da0p6 > Sat Nov 30 16:48:24 PST 2019 > Device 1K-blocks Used Avail Capacity > /dev/mmcsd0s2b 4404252 1959324 2444928 44% > /dev/da0p6 5242880 1957468 3285412 37% > Total 9647132 3916792 5730340 41% > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id > 0 0 12 4523836 52860 6989 186 715 257 6932 25125 1038 1038 30790 1073 29820 14 26 60 > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 1 751 702 4860 4.0 49 251 5.0 0 0 0.0 94.4 mmcsd0 > 1 751 702 4860 4.1 49 251 5.1 0 0 0.0 94.7 mmcsd0s2 > 2 704 658 4082 1.8 46 235 0.6 0 0 0.0 71.9 da0 > 1 751 702 4860 4.1 49 251 5.1 0 0 0.0 94.8 mmcsd0s2b > 2 704 658 4082 1.8 46 235 0.7 0 0 0.0 72.6 da0p6 > Sat Nov 30 16:48:26 PST 2019 > Device 1K-blocks Used Avail Capacity > /dev/mmcsd0s2b 4404252 1959504 2444748 44% > /dev/da0p6 5242880 1957540 3285340 37% > Total 9647132 3917044 5730088 41% > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for illegal user support from 103.133.104.114 > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from 103.133.104.114 port 52716:14: No more user authentication methods available. [preauth] > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id > 0 0 12 4523868 46872 6989 186 715 257 6932 25123 0 0 30790 1073 29820 14 26 60 > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 2 700 681 4888 3.7 19 108 3.7 0 0 0.0 92.1 mmcsd0 > 2 700 681 4888 3.8 19 108 3.7 0 0 0.0 92.5 mmcsd0s2 > 2 709 687 4314 2.1 22 108 3.4 0 0 0.0 78.2 da0 > 2 700 681 4888 3.8 19 108 3.7 0 0 0.0 92.6 mmcsd0s2b > 2 709 687 4314 2.1 22 108 3.4 0 0 0.0 78.7 da0p6 > Sat Nov 30 16:48:28 PST 2019 > Device 1K-blocks Used Avail Capacity > /dev/mmcsd0s2b 440 > > It's clear the machine was heavily loaded, but storage didn't appear to be swamped. > I hope the foregoing has been of some interest, thanks for reading! > > bob prohaska > From owner-freebsd-arm@freebsd.org Sun Dec 1 02:32:30 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06C011C31CF for ; Sun, 1 Dec 2019 02:32:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47QXMd21ZZz3MqF for ; Sun, 1 Dec 2019 02:32:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x842.google.com with SMTP id g24so30416094qtq.11 for ; Sat, 30 Nov 2019 18:32:29 -0800 (PST) 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=Yv+Wf8CnGrqpUHXZS3RKu+HSzVvZXVEqrm9hVOBK4CM=; b=ic49btchzVqKXANd6tOosf+lQ9bRx0bkZAW2KjHPPAnSD27vTdk7Vj2qPttyY7kyVv 4eFE43Cbxm92se9qJFDBXqCyOSnP2W5Qbc3fopvzhW1UvREEXc3WxsNAxpmLJnDoGYmE J2PI47v+jJUgnR9xEuOKe2lbALmvc8f9A3ofyoh1h73ywJj1DgWh3CbYC862PdayUbzM m68RmF3gnqnUcJem4+8fMpX9n3G42oe4s9JzsSPhCiQfQ7zxWyclQLY5tzOLxe+NtbMm iQVXPBHhNkdTmbEfC22XFr44e8SkEPXk5fBMXm3sH6rWKAvvRJs18+FzJwY687BbUMw6 e66A== 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=Yv+Wf8CnGrqpUHXZS3RKu+HSzVvZXVEqrm9hVOBK4CM=; b=BguxdpuNkSnrkDN/qdOkk0WTmHEIF01LXjBfLJBz6IEdW2GVtWmjg6K+TAAXbu3EaL 5k77deE+0Qa3paUdDpltDuxGx2tVwsD17v/N4+9ILx6efakhqS01PXgiSFPYeZzXUuvS WYv8kiZqEzfSZZIqZ9w/JIceNwcCjss2o1FQ9wefjE/K1JBMOvM0qYN0+k9ZoW7wLr0E lVuliMnwkF9bavEjvSo3JIYz40fvjK+pxUPVJbnWw+PsRHhpURhr054zr8ffu4u5cX4X rCMNrmCW4qpB1BIxuYBxUJnQ2S4FEG9ub61XxKMZ6tJ+9VEAWeFzir2IzVbShlrc8SHt XIMA== X-Gm-Message-State: APjAAAUTSSESo+sLlvfZ6HiSy9wQxIvSMuko7C5Z89mH7zW6KHbNsLXO IBWeT4QuRZlPTRjEybZLWbTbb4Q4xp479/rGbZByFA== X-Google-Smtp-Source: APXvYqx7fxImkxNcFSkykrZpodqJYQSz3whotuOUIrKnlMxz+8sRHfIuBfYxE9zbeZL/993OcqTRppRc6Y/cf++b+OM= X-Received: by 2002:ac8:67d0:: with SMTP id r16mr10037134qtp.187.1575167547401; Sat, 30 Nov 2019 18:32:27 -0800 (PST) MIME-Version: 1.0 References: <20191201011615.GA45887@www.zefox.net> <20191201015252.GB45887@www.zefox.net> In-Reply-To: <20191201015252.GB45887@www.zefox.net> From: Warner Losh Date: Sat, 30 Nov 2019 19:32:15 -0700 Message-ID: Subject: Re: Rpi3 panic: non-current pmap 0xfffffd001e05b130 To: bob prohaska Cc: freebsd-arm@freebsd.org, FreeBSD Current X-Rspamd-Queue-Id: 47QXMd21ZZz3MqF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ic49btch; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::842) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.22 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.937,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.955,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MIME_BASE64_TEXT(0.10)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.42)[ip: (2.13), ipnet: 2607:f8b0::/32(-2.25), asn: 15169(-1.94), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 02:32:30 -0000 Page out errors can be caused by crappy nand... Warner On Sat, Nov 30, 2019, 6:53 PM bob prohaska wrote: > On Sat, Nov 30, 2019 at 05:16:15PM -0800, bob prohaska wrote: > > A Pi3 running r355024 reported a panic while doing a -j3 make of > > www/chromium: > > > Ok, another panic, looks like a dying storage device. This time there > was a preamble on the console: > > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 c3 90 d8 00 00 08 00 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > swap_pager: I/O error - pageout failed; blkno 1442883,size 4096, error 5 > swap_pager: I/O error - pageout failed; blkno 1442884,size 4096, error 5 > swap_pager: I/O error - pageout failed; blkno 1442885,size 8192, error 5 > swap_pager: I/O error - pageout failed; blkno 1442887,size 4096, error 5 > swap_pager: I/O error - pagein failed; blkno 1103209,size 4096, error 5 > vm_fault: pager read error, pid 681 (devd) > swap_pager: I/O error - pagein failed; blkno 1130270,size 4096, error 5 > vm_fault: pager read error, pid 2362 (c++) > Nov 30 17:37:34 www kernel: Failed to fully fault in a core file segment > at VA 0x40400000 with size 0x60b000 to be written at offset 0x32b000 for > process devd > panic: vm_page_assert_unbusied: page 0xfffffd0030f8af80 busy @ > /usr/src/sys/vm/vm_object.c:777 > cpuid = 3 > time = 1575164255 > > Earlier panics didn't have any proximate warnings on the console, but > they're > probably the same story. > > apologies for the noise! > > bob prohaska > > > > > panic: non-current pmap 0xfffffd001e05b130 > > cpuid = 0 > > time = 1575161361 > > KDB: stack backtrace: > > db_trace_self() at db_trace_self_wrapper+0x28 > > pc = 0xffff000000729e4c lr = 0xffff0000001066c8 > > sp = 0xffff000059f3e2b0 fp = 0xffff000059f3e4c0 > > > > db_trace_self_wrapper() at vpanic+0x18c > > pc = 0xffff0000001066c8 lr = 0xffff000000400d7c > > sp = 0xffff000059f3e4d0 fp = 0xffff000059f3e580 > > > > vpanic() at panic+0x44 > > pc = 0xffff000000400d7c lr = 0xffff000000400b2c > > sp = 0xffff000059f3e590 fp = 0xffff000059f3e610 > > > > panic() at pmap_remove_pages+0x8d4 > > pc = 0xffff000000400b2c lr = 0xffff00000074154c > > sp = 0xffff000059f3e620 fp = 0xffff000059f3e6e0 > > > > pmap_remove_pages() at vmspace_exit+0xc0 > > pc = 0xffff00000074154c lr = 0xffff0000006c9c00 > > sp = 0xffff000059f3e6f0 fp = 0xffff000059f3e720 > > > > vmspace_exit() at exit1+0x4f8 > > pc = 0xffff0000006c9c00 lr = 0xffff0000003bc2a4 > > sp = 0xffff000059f3e730 fp = 0xffff000059f3e7a0 > > > > exit1() at sys_sys_exit+0x10 > > pc = 0xffff0000003bc2a4 lr = 0xffff0000003bbda8 > > sp = 0xffff000059f3e7b0 fp = 0xffff000059f3e7b0 > > > > sys_sys_exit() at do_el0_sync+0x514 > > pc = 0xffff0000003bbda8 lr = 0xffff000000747aa4 > > sp = 0xffff000059f3e7c0 fp = 0xffff000059f3e860 > > > > do_el0_sync() at handle_el0_sync+0x90 > > pc = 0xffff000000747aa4 lr = 0xffff00000072ca14 > > sp = 0xffff000059f3e870 fp = 0xffff000059f3e980 > > > > handle_el0_sync() at 0x404e6d60 > > pc = 0xffff00000072ca14 lr = 0x00000000404e6d60 > > sp = 0xffff000059f3e990 fp = 0x0000ffffffffd590 > > > > KDB: enter: panic > > [ thread pid 94966 tid 100145 ] > > Stopped at 0x40505460: undefined 54000042 > > db> bt > > Tracing pid 94966 tid 100145 td 0xfffffd002552b000 > > db_trace_self() at db_stack_trace+0xf8 > > pc = 0xffff000000729e4c lr = 0xffff000000103b0c > > sp = 0xffff000059f3de80 fp = 0xffff000059f3deb0 > > > > db_stack_trace() at db_command+0x228 > > pc = 0xffff000000103b0c lr = 0xffff000000103784 > > sp = 0xffff000059f3dec0 fp = 0xffff000059f3dfa0 > > > > db_command() at db_command_loop+0x58 > > pc = 0xffff000000103784 lr = 0xffff00000010352c > > sp = 0xffff000059f3dfb0 fp = 0xffff000059f3dfd0 > > > > db_command_loop() at db_trap+0xf4 > > pc = 0xffff00000010352c lr = 0xffff000000106830 > > sp = 0xffff000059f3dfe0 fp = 0xffff000059f3e200 > > > > db_trap() at kdb_trap+0x1d8 > > pc = 0xffff000000106830 lr = 0xffff0000004492fc > > sp = 0xffff000059f3e210 fp = 0xffff000059f3e2c0 > > > > kdb_trap() at do_el1h_sync+0xf4 > > pc = 0xffff0000004492fc lr = 0xffff000000747418 > > sp = 0xffff000059f3e2d0 fp = 0xffff000059f3e300 > > > > do_el1h_sync() at handle_el1h_sync+0x78 > > pc = 0xffff000000747418 lr = 0xffff00000072c878 > > sp = 0xffff000059f3e310 fp = 0xffff000059f3e420 > > > > handle_el1h_sync() at kdb_enter+0x34 > > pc = 0xffff00000072c878 lr = 0xffff000000448948 > > sp = 0xffff000059f3e430 fp = 0xffff000059f3e4c0 > > > > kdb_enter() at vpanic+0x1a8 > > pc = 0xffff000000448948 lr = 0xffff000000400d98 > > sp = 0xffff000059f3e4d0 fp = 0xffff000059f3e580 > > > > vpanic() at panic+0x44 > > pc = 0xffff000000400d98 lr = 0xffff000000400b2c > > sp = 0xffff000059f3e590 fp = 0xffff000059f3e610 > > > > panic() at pmap_remove_pages+0x8d4 > > pc = 0xffff000000400b2c lr = 0xffff00000074154c > > sp = 0xffff000059f3e620 fp = 0xffff000059f3e6e0 > > > > pmap_remove_pages() at vmspace_exit+0xc0 > > pc = 0xffff00000074154c lr = 0xffff0000006c9c00 > > sp = 0xffff000059f3e6f0 fp = 0xffff000059f3e720 > > > > vmspace_exit() at exit1+0x4f8 > > pc = 0xffff0000006c9c00 lr = 0xffff0000003bc2a4 > > sp = 0xffff000059f3e730 fp = 0xffff000059f3e7a0 > > > > exit1() at sys_sys_exit+0x10 > > pc = 0xffff0000003bc2a4 lr = 0xffff0000003bbda8 > > sp = 0xffff000059f3e7b0 fp = 0xffff000059f3e7b0 > > > > sys_sys_exit() at do_el0_sync+0x514 > > pc = 0xffff0000003bbda8 lr = 0xffff000000747aa4 > > sp = 0xffff000059f3e7c0 fp = 0xffff000059f3e860 > > > > do_el0_sync() at handle_el0_sync+0x90 > > pc = 0xffff000000747aa4 lr = 0xffff00000072ca14 > > sp = 0xffff000059f3e870 fp = 0xffff000059f3e980 > > > > handle_el0_sync() at 0x404e6d60 > > pc = 0xffff00000072ca14 lr = 0x00000000404e6d60 > > sp = 0xffff000059f3e990 fp = 0x0000ffffffffd590 > > > > db> > > > > The last top screen showed > > > > last pid: 94966; load averages: 1.22, 1.42, 1.40 > up 0+05:10:16 16:49:20 > > 43 processes: 1 running, 42 sleeping > > CPU: 3.7% user, 0.0% nice, 20.0% system, 5.5% interrupt, 70.8% idle > > Mem: 502M Active, 6672K Inact, 150M Laundry, 184M Wired, 90M Buf, 55M > Free > > Swap: 7194M Total, 3835M Used, 3359M Free, 53% Inuse, 11M In, 3852K Out > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > > 71350 root 1 22 0 951M 144M swread 0 10:20 5.97% > c++ > > 58502 root 1 21 0 986M 232M swread 1 11:23 3.42% > c++ > > 77283 root 1 22 0 963M 151M swread 0 8:45 3.30% > c++ > > 6904 root 1 22 0 1144M 191M swread 0 21:26 3.29% > c++ > > 1091 bob 1 52 0 11M 324K wait 3 0:55 0.27% sh > > 1079 bob 1 20 0 13M 1636K CPU0 0 0:57 0.22% > top > > 1074 bob 1 20 0 19M 1316K select 1 0:13 0.03% > sshd > > 970 root 1 20 0 16M 1500K select 1 0:02 0.02% > sendmail > > 1069 root 1 20 0 204M 1044K select 3 1:40 0.00% > ninja > > 1050 root 1 20 0 12M 972K select 2 0:02 0.00% > make > > 977 root 1 20 0 11M 0B nanslp 1 0:02 0.00% > > > 957 root 1 20 0 19M 1216K select 1 0:01 0.00% > sshd > > 824 root 1 20 0 11M 1084K select 2 0:01 0.00% > syslogd > > 1084 bob 1 20 0 13M 1008K ttyin 0 0:00 0.00% > tcsh > > > > and the last few storage activity log entries were: > > > > dT: 1.002s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > 1 713 694 4666 3.7 20 116 6.0 0 0 > 0.0 90.9 mmcsd0 > > 1 713 694 4666 3.8 20 116 6.0 0 0 > 0.0 91.2 mmcsd0s2 > > 2 751 734 4730 2.0 17 96 0.6 0 0 > 0.0 79.4 da0 > > 1 713 694 4666 3.8 20 116 6.0 0 0 > 0.0 91.4 mmcsd0s2b > > 2 751 734 4730 2.0 17 96 0.6 0 0 > 0.0 79.9 da0p6 > > Sat Nov 30 16:48:21 PST 2019 > > Device 1K-blocks Used Avail Capacity > > /dev/mmcsd0s2b 4404252 1958976 2445276 44% > > /dev/da0p6 5242880 1956872 3286008 37% > > Total 9647132 3915848 5731284 41% > > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for > illegal user support from 103.133.104.114 > > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from > 103.133.104.114 port 52716:14: No more user authentication methods > available. [preauth] > > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > > procs memory page disks faults > cpu > > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs > us sy id > > 0 0 12 4523836 56064 6988 186 715 257 6931 25128 0 0 30789 > 1073 29817 14 26 60 > > dT: 1.002s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > 0 709 687 4588 3.9 22 144 5.8 0 0 > 0.0 90.5 mmcsd0 > > 0 709 687 4588 3.9 22 144 5.8 0 0 > 0.0 90.9 mmcsd0s2 > > 2 698 679 4696 2.1 19 104 0.6 0 0 > 0.0 75.2 da0 > > 0 709 687 4588 3.9 22 144 5.8 0 0 > 0.0 91.0 mmcsd0s2b > > 2 698 679 4696 2.2 19 104 0.6 0 0 > 0.0 75.7 da0p6 > > Sat Nov 30 16:48:22 PST 2019 > > Device 1K-blocks Used Avail Capacity > > /dev/mmcsd0s2b 4404252 1959032 2445220 44% > > /dev/da0p6 5242880 1956928 3285952 37% > > Total 9647132 3915960 5731172 41% > > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for > illegal user support from 103.133.104.114 > > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from > 103.133.104.114 port 52716:14: No more user authentication methods > available. [preauth] > > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > > procs memory page disks faults > cpu > > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs > us sy id > > 0 0 12 4523836 55844 6989 186 715 257 6932 25127 604 604 30790 > 1073 29819 14 26 60 > > dT: 1.001s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > 2 736 680 4829 3.9 56 292 5.0 0 0 > 0.0 94.4 mmcsd0 > > 2 736 680 4829 4.0 56 292 5.0 0 0 > 0.0 94.6 mmcsd0s2 > > 1 680 627 4014 1.9 53 328 1.0 0 0 > 0.0 71.1 da0 > > 2 736 680 4829 4.0 56 292 5.0 0 0 > 0.0 94.7 mmcsd0s2b > > 1 680 627 4014 1.9 53 328 1.0 0 0 > 0.0 71.7 da0p6 > > Sat Nov 30 16:48:24 PST 2019 > > Device 1K-blocks Used Avail Capacity > > /dev/mmcsd0s2b 4404252 1959324 2444928 44% > > /dev/da0p6 5242880 1957468 3285412 37% > > Total 9647132 3916792 5730340 41% > > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for > illegal user support from 103.133.104.114 > > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from > 103.133.104.114 port 52716:14: No more user authentication methods > available. [preauth] > > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > > procs memory page disks faults > cpu > > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs > us sy id > > 0 0 12 4523836 52860 6989 186 715 257 6932 25125 1038 1038 30790 > 1073 29820 14 26 60 > > dT: 1.002s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > 1 751 702 4860 4.0 49 251 5.0 0 0 > 0.0 94.4 mmcsd0 > > 1 751 702 4860 4.1 49 251 5.1 0 0 > 0.0 94.7 mmcsd0s2 > > 2 704 658 4082 1.8 46 235 0.6 0 0 > 0.0 71.9 da0 > > 1 751 702 4860 4.1 49 251 5.1 0 0 > 0.0 94.8 mmcsd0s2b > > 2 704 658 4082 1.8 46 235 0.7 0 0 > 0.0 72.6 da0p6 > > Sat Nov 30 16:48:26 PST 2019 > > Device 1K-blocks Used Avail Capacity > > /dev/mmcsd0s2b 4404252 1959504 2444748 44% > > /dev/da0p6 5242880 1957540 3285340 37% > > Total 9647132 3917044 5730088 41% > > Nov 30 16:38:17 www sshd[91264]: error: PAM: Authentication error for > illegal user support from 103.133.104.114 > > Nov 30 16:38:17 www sshd[91264]: error: Received disconnect from > 103.133.104.114 port 52716:14: No more user authentication methods > available. [preauth] > > 0/1016/1016/19178 mbuf clusters in use (current/cache/total/max) > > procs memory page disks faults > cpu > > r b w avm fre flt re pi po fr sr mm0 da0 in sy cs > us sy id > > 0 0 12 4523868 46872 6989 186 715 257 6932 25123 0 0 30790 > 1073 29820 14 26 60 > > dT: 1.002s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > 2 700 681 4888 3.7 19 108 3.7 0 0 > 0.0 92.1 mmcsd0 > > 2 700 681 4888 3.8 19 108 3.7 0 0 > 0.0 92.5 mmcsd0s2 > > 2 709 687 4314 2.1 22 108 3.4 0 0 > 0.0 78.2 da0 > > 2 700 681 4888 3.8 19 108 3.7 0 0 > 0.0 92.6 mmcsd0s2b > > 2 709 687 4314 2.1 22 108 3.4 0 0 > 0.0 78.7 da0p6 > > Sat Nov 30 16:48:28 PST 2019 > > Device 1K-blocks Used Avail Capacity > > /dev/mmcsd0s2b 440 > > > > It's clear the machine was heavily loaded, but storage didn't appear to > be swamped. > > I hope the foregoing has been of some interest, 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 Sun Dec 1 10:21:30 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5498F1C6311 for ; Sun, 1 Dec 2019 10:21:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 47Qkmn2D8wz4g1D for ; Sun, 1 Dec 2019 10:21:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: CJCor_UVM1mhTW6DYrWYwbscGn6f9VzYeSfSTZEZAC35SO3igg4XmmjhfmTny.W kRvi6XuwgN3uRpPmClhimsaZv0W6Iav4rrvpYuUoqc_fqhxLI5vAYTk80YKL1_wFVG7bXprDlK2l Vp4pQxY.uuUdEd4RS9re7HYw19506.QkEM1uXstjIMSS_rbYkGc_O1f2PLbvvybCoj_T92CJ50II YWPSCzFjtbieZD2qPs5HB6D5NyRFNXCaS0iq8jlJlxxqEOIGRqVvkRWq4LNvRek9TJ7uhXIg0j8B L7vos2hUwe.N2s_Xof7T.OYDctc2ZWJiiCRdCD0rV7HMB9zaHGFJLqO3SubizQVuqpPeOMP0D47V N5L8XqZ248ecgTX7rm66nGccYXJ0ghCeVc1RVqKuXkieYLePDBDJ54egJ1wQ62ueQASNWcwU7EiQ UVMGJtwjgjykdeR7Gqhrey09K5OTTEx22qTg9JN4fKYsiGIQTaZ6TAOo4Ej5R6ZYzMhS1VLtHi0w VxwN4tZBBaajFo9yqSBuKq6p2loFK4UELWS1LL1yYbX.z42wmgcpTldBjQzx10ZVog8j8HXwofFl 8cTAg.a4_8bggAwO_ByfC9xlJyp5vX4x7Rb3S6pHPt3Uj3KCIjshchrOEKNDUj6EWDF53QkbTxjo bLZ9aWihlYQUhQRgGDP2XVXlCaMPW9umn5cO4fkO.viLs6suvdIj7RPW8chdxijksKwv2yvH8bHt j74mvj82_LNmVjemJU3X1DwFLjjMgdKId4JJFCsIlD5bxJsr6znayvkpzD19OqIYayEs.Kq9OpAU 9YB4yOizQYVmyZskQ2gMW5p1XVq3trhhaMVqHpXVR.gNVhOt6CYamENlNvOYxUfmeNrfx35xBNCs hkDU6xdPxM7xdzCQTNgF9X3ae.JV0_3lPqbdEUEdVG4UxUSF.vsvnGssEXvuJfIMjQVo20AGWzOs pgQAqdREcwjnoj8rL2DI7AW0cpFXvKPiGo7hg1Q_H0IvJdragTRTC7Ut9sgEla2XbLiG7W9mrK3m jyvI.KGUzclzQJNlgRjcq9TcAggT.lyRGfJY.vBYV9U7TmqiD6dlDjBsQQVjbcB061cBct1DjntM TZxDYn98ShARPJMZ.v_N.VMKbTIphZL5HkhR8.lvCuLkFsWaTuaWzlYzUsRqM8AvaPAZ60DG0E0j F8r8EiSvzZZXTUAweXRhlZXA7Hyt0a40OGE09UDkBRADB8UW8Ylpm1vnlttko2rS_msx4BsA7Pu6 YvRHvSV2BoWuhmL_yYPRVBc1q.C5_9EfFTp9Wu6T.A96VeBu5SnECwgEZq1YPewcQpJ5Gg7A6ywO lJkf9Nsg5bp2RZoA3n.J0PMJSHH6iD4OTmLbgKLcOmVJbBo1x5AFEm0qH8zvVxqRKQYK9eNCJROs 6rs36QEKXAd3VAxAXNmpj0wpeoxMUC4.WyjN4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Dec 2019 10:21:27 +0000 Received: by smtp404.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f5b1d867af23850e7db55c7a7ad165f6; Sun, 01 Dec 2019 10:21:24 +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 13.0 \(3601.0.10\)) Subject: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 Message-Id: Date: Sun, 1 Dec 2019 02:21:24 -0800 Cc: mw@semihalf.com To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3601.0.10) References: X-Rspamd-Queue-Id: 47Qkmn2D8wz4g1D X-Spamd-Bar: / X-Spamd-Result: default: False [0.23 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MV_CASE(0.50)[]; NEURAL_SPAM_MEDIUM(0.24)[0.235,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[82.68.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_SPAM_LONG(0.49)[0.490,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (6.19), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 10:21:30 -0000 I tried to get a MACCHIATObin Double Shot Rev 1.3 to boot -r355027 (a non-debug build). The first (partial) result based on older materials made me hopeful, but trying more modern materials did not get as far. I started from old media that I happened to have around from last time I'd had access and tried to boot the MACCHIATObin and got to (showing the old vintage as well): . . . FreeBSD 12.0-ALPHA8 #3 r339076M: Thu Oct 4 14:24:26 PDT 2018 = markmi@FBSDUSSD:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarch= 64/sys/GENERIC-NODBG arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) . . . Release APs...done Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... The /etc/fstab was wrong and I knew it would be. This was a quick test = before updating to more modern content that I was actually interested in. / for = all this was (and is) on a Samsung SATA SSD. I got here via using a UEFI image from: = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/Binar= ies/ specifically using: = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/files= /flash-image-mcbin-mainline-r20190509.bin on uSD media via (on another FreeBSD machine): dd if=3D/root/flash-image-mcbin-mainline-r20190509.bin bs=3D512 seek=3D1 = of=3D/dev/da3 conv=3Dsync I had set the jumpers to have the MACCHIATObin use the uSD media instead of spi content. (That is also how I booted Arch Linux ARM from uSD media so it was already set up that way.) After getting this far I updated to having head -r355027 on the SATA SSD (matching other context I have around) and copied over the modern loader.efi to replace the old efi file. Having done this I only get as far as: . . . Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0xbe844018. A "|" or "/" sometimes shows up on the next line but it does not show the typical sequence of symbols and there is no more evidence of progress. The text is seen via the serial console. I've hypothesized bunches of things that might make a difference, none have. I tried putting back the old .efi file. I tried building the .dtb from the -r355027 materials and forcing that to be loaded. (Each failing alternative was reverted as I went along.) I tried an old .dtb file that I had around. I tried the 18.09.4 .bin file on the uSD media. I tried various ways of specifying were / was supposed to be from. I tried with and without: kern.cam.boot_delay=3D10000 vfs.mountroot.timeout=3D10 I did notice one distinction for before vs. after the -r35027 update. Before the update always got: loaddev=3Ddisk0p2: After the update always got: loaddev=3Ddisk0p1: disk0p1 has the efi file system; disk0p2 has the ufs file system. By contrast, currdev got "disk0p2:" in both contexts. (Side note: I last tried to boot this board with FreeBSD was over a year ago but ended up redirected and without access until recently. Marcin had tried to help me back then. I'm not sure how long I'll have access this round.) =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 Dec 1 11:07:40 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 045591C74B2 for ; Sun, 1 Dec 2019 11:07:40 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Qlp24brHz3DTD; Sun, 1 Dec 2019 11:07:38 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB1B7M5x041631 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 1 Dec 2019 22:07:28 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB1B7Glb042720 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Dec 2019 22:07:16 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id xB1B7GJb042719; Sun, 1 Dec 2019 22:07:16 +1100 (AEDT) (envelope-from peter) Date: Sun, 1 Dec 2019 22:07:16 +1100 From: Peter Jeremy To: Michal Meloun Cc: freebsd-arm@freebsd.org Subject: rk_tsadc breaks (my) Rock64 Message-ID: <20191201110716.GA41224@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47Qlp24brHz3DTD X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-7.65 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.5,0.0.0.6,0.0.0.8]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-3.25)[ip: (-9.60), ipnet: 2001:19f0:5800::/38(-4.81), asn: 20473(-1.80), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[]; SH_EMAIL_ZRD(0.00)[0.0.0.5,0.0.0.8,0.0.0.6] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 11:07:40 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable r355173 added code to read the Rockchip temperature sensors. Unfortunately, this breaks on my Rock64. I've tried to understand what's going wrong but haven't managed to make much headway. It looks like there some configurati= on missing from syscon that tsadc needs but I'm not sure what (and I don't rea= lly understand what syscon is doing). I'd appreciate any insights. Relevant extract from the dmesg: simple_mfd0: mem 0xff450000-0xff45fff= f on ofwbus0 =2E.. rk_tsadc0: mem 0xff250000-0xff2500ff irq 22 = on ofwbus0 rk_tsadc0: nclocks=3D1, nparents=3D-1 rk_tsadc0: Set clk_tsadc to 50000 panic: data abort with spinlock held cpuid =3D 0 time =3D 1 KDB: stack backtrace: =2E.. data_abort() at do_el1h_sync+0x144 pc =3D 0xffff00000053f590 lr =3D 0xffff00000053e8c8 sp =3D 0xffff000000010530 fp =3D 0xffff000000010560 do_el1h_sync() at handle_el1h_sync+0x78 pc =3D 0xffff00000053e8c8 lr =3D 0xffff000000525078 sp =3D 0xffff000000010570 fp =3D 0xffff000000010680 handle_el1h_sync() at simple_mfd_syscon_write_4+0x60 pc =3D 0xffff000000525078 lr =3D 0xffff0000000fb028 sp =3D 0xffff000000010690 fp =3D 0xffff000000010740 simple_mfd_syscon_write_4() at tsadc_attach+0x44c pc =3D 0xffff0000000fb028 lr =3D 0xffff000000553b58 sp =3D 0xffff000000010750 fp =3D 0xffff0000000107c0 tsadc_attach() at device_attach+0x3e0 pc =3D 0xffff000000553b58 lr =3D 0xffff00000028ad1c sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010830 device_attach() at bus_generic_new_pass+0x12c pc =3D 0xffff00000028ad1c lr =3D 0xffff00000028cb58 sp =3D 0xffff000000010840 fp =3D 0xffff000000010870 =2E.. Stopped at generic_bs_w_4: undefined b8226823 Relevant extract from FDT: syscon@ff100000 { compatible =3D "rockchip,rk3328-grf", "syscon", "simple-mfd= "; reg =3D <0x0 0xff100000 0x0 0x1000>; #address-cells =3D <0x1>; #size-cells =3D <0x1>; phandle =3D <0x13>; io-domains { compatible =3D "rockchip,rk3328-io-voltage-domain"; status =3D "okay"; vccio1-supply =3D <0x20>; vccio2-supply =3D <0x22>; vccio3-supply =3D <0x20>; vccio4-supply =3D <0x21>; vccio5-supply =3D <0x20>; vccio6-supply =3D <0x20>; pmuio-supply =3D <0x20>; phandle =3D <0x14>; }; grf-gpio { compatible =3D "rockchip,rk3328-grf-gpio"; gpio-controller; #gpio-cells =3D <0x2>; phandle =3D <0x15>; }; power-controller { compatible =3D "rockchip,rk3328-power-controller"; #power-domain-cells =3D <0x1>; #address-cells =3D <0x1>; #size-cells =3D <0x0>; phandle =3D <0x16>; pd_hevc@6 { reg =3D <0x6>; }; pd_video@5 { reg =3D <0x5>; }; pd_vpu@8 { reg =3D <0x8>; }; }; reboot-mode { compatible =3D "syscon-reboot-mode"; offset =3D <0x5c8>; mode-normal =3D <0x5242c300>; mode-recovery =3D <0x5242c303>; mode-bootloader =3D <0x5242c309>; mode-loader =3D <0x5242c301>; }; }; =2E.. tsadc@ff250000 { compatible =3D "rockchip,rk3328-tsadc"; reg =3D <0x0 0xff250000 0x0 0x100>; interrupts =3D <0x0 0x3a 0x4>; assigned-clocks =3D <0x46 0x24>; assigned-clock-rates =3D <0xc350>; clocks =3D <0x46 0x24 0x46 0xd5>; clock-names =3D "tsadc", "apb_pclk"; pinctrl-names =3D "init", "default", "sleep"; pinctrl-0 =3D <0x7c>; pinctrl-1 =3D <0x7d>; pinctrl-2 =3D <0x7c>; resets =3D <0x46 0x42>; reset-names =3D "tsadc-apb"; rockchip,grf =3D <0x13>; rockchip,hw-tshut-temp =3D <0x186a0>; #thermal-sensor-cells =3D <0x1>; status =3D "okay"; rockchip,hw-tshut-mode =3D <0x0>; rockchip,hw-tshut-polarity =3D <0x0>; phandle =3D <0x30>; }; --=20 Peter Jeremy --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl3jnt5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQLiBAAnajr+fJOKvnn7+fVFIcrowWQDDFQzrVeJ5TEp68Obl7p+wykfg6mNC2Q a8eW2UwUfam4XKJQY28gAApFTqa2dyYDUOesyKmaFq9SYpo9TVw3bfEGIUa+kg8R mdnG4GG9WaXT94wZyQ6d23KYmRXJV6eR9q7cQ8FmKS6i6crlCbP/m1T2PMbueol3 oaiGY0dYdn9AySPOsshzL+7MW7p4iM3M5b7QgkSxbNbuI61JrCIxYvADtrnif87F bZlOm5ZmG2Q3H3KzDMD+jsgwajgItVrbTYXh8i5VYIGK2Z6OvbiBtqwsq/CI1g69 TgcwxB+NV88stt60qcsYjvshg/G6BF5DjgEkVyrglOeylrhSxSx44V+uUkWok1Bb u+cFKgWxEOeRG9N5XCjV8ZGfe149w7SrwgY9u0nyKLGOQ7rvYM7ZAktx3TUnewme uLifXbRp3EFqO2vwlcAOYoV6bRjBzhB1Ru4fstwz4pbkfGq//aV88odry3keWHnR njqkHxRs0GyoOY/Xr3CUs1ac7NuuLg+FLR+VD3rZR3lwRLAw8eNZkS4mHUThYr8u 5MNJTlYvDFblM1miMGhXsmTgQLqtCpxepOGtNmrwpUzUWsLp0CP9kkLC9oQOn1/p jBo1uupEGmcdzl2zP594pMxF59GoG2JjJPVYuzUcBCWVMi953ao= =J54v -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-arm@freebsd.org Sun Dec 1 13:41:02 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9AA8C1AB664 for ; Sun, 1 Dec 2019 13:41:02 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47QqC16VR5z3Lcn; Sun, 1 Dec 2019 13:41:01 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qv1-xf34.google.com with SMTP id v12so338430qvq.2; Sun, 01 Dec 2019 05:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R2D7PNGrNSlAEa6MM/v/0CqVkMAoQIAEWcxtYhPd4L8=; b=qCrnXdiWg+56TWItJTZMBQ2hY4mc597P9Krufz2yRYZvsWBFR2Ti0GiUCpd5CNTDjj 1nFGOT/HQgnpN9FkK1RTZ3b3EAfBQrQ6Q4wvyAbb5exNLjKtfkGaJ5Jb+ljpTes4MjRG s0w1PGzi5SB9cU4rwFJ2YhOFeUanOhew9K7ko9KjPr5X+98ps54OX9XrFbi3fNGpduJe MNTCEAiCXYsapRf7DlkQviC1bKI+lXN2rHmlUrQnS6G3SPVabUmoNcNY3fwRsdbcIOD3 fZUr7lKCK3lfq+IxmQzhNbIPYEMc7W9/DjIBpl1zCliEmWQ8FRaDKbkbsLLPjkQilWVP bc/w== 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=R2D7PNGrNSlAEa6MM/v/0CqVkMAoQIAEWcxtYhPd4L8=; b=TUWE7IABZu5BhwhpFEfVnDK8TqGa8Ia5q0wDcVXKygp4PZ8skBK8gEDjpHuN2bKVSm t1IlmXe/oEx+aZgPHSp/SHCUusSfAvfmqcRJvEB1dOWzR65KRlgwqKwSPSFR9Gz1ji+M SywR2wMHY3rSyHhVovhv60Aa1Y0j3ShyFPbepbsM7GZqG0uInEVqPwhJXE1BUdz4lJbu r3kbNxYkdf1OPkk8JJ0vfTS9MGn2eOdCk01QiF8y+xM9KdMDVYpwpYou49xmh+IFuNN4 cJ9woUdsVbmBr21FUzGWmwNebx8IDesHJPJqfJemdenLEAKBwn6Ta6PiUlcfHJ2k9ZSn kcuA== X-Gm-Message-State: APjAAAWGzegi5mINZgnT5PQzh/2N4mdk9MPcgxaIB+7zBRowYaQjVKmB ydgb+dE0SDqMlNhniJh2z5q1wuklIschlea9Cvs= X-Google-Smtp-Source: APXvYqw/jmMe0daHgmsb9nSvpSe/zi1afckxmjHm+WOIjEH6R8nLHCHJ0mdDdn+2FjodeOmyvsUUH3lwwl1aG+C4Izw= X-Received: by 2002:a05:6214:c3:: with SMTP id f3mr15992858qvs.226.1575207654764; Sun, 01 Dec 2019 05:40:54 -0800 (PST) MIME-Version: 1.0 References: <20191201110716.GA41224@server.rulingia.com> In-Reply-To: <20191201110716.GA41224@server.rulingia.com> From: Ganbold Tsagaankhuu Date: Sun, 1 Dec 2019 21:40:43 +0800 Message-ID: Subject: Re: rk_tsadc breaks (my) Rock64 To: Peter Jeremy Cc: Michal Meloun , "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: 47QqC16VR5z3Lcn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qCrnXdiW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ganbold@gmail.com designates 2607:f8b0:4864:20::f34 as permitted sender) smtp.mailfrom=ganbold@gmail.com X-Spamd-Result: default: False [-1.89 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ipnet: 2607:f8b0::/32(-2.25), asn: 15169(-1.94), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SH_EMAIL_ZRD(0.00)[0.0.0.8,0.0.0.5,0.0.0.6]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.8,0.0.0.6,0.0.0.5]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 13:41:02 -0000 On Sun, Dec 1, 2019 at 7:07 PM Peter Jeremy wrote: > r355173 added code to read the Rockchip temperature sensors. > Unfortunately, > this breaks on my Rock64. I've tried to understand what's going wrong but > haven't managed to make much headway. It looks like there some > configuration > missing from syscon that tsadc needs but I'm not sure what (and I don't > really > understand what syscon is doing). I'd appreciate any insights. > > Relevant extract from the dmesg: > simple_mfd0: mem > 0xff450000-0xff45ffff on ofwbus0 > ... > rk_tsadc0: mem 0xff250000-0xff2500ff irq 22 > on ofwbus0 > rk_tsadc0: nclocks=1, nparents=-1 > rk_tsadc0: Set clk_tsadc to 50000 > panic: data abort with spinlock held > cpuid = 0 > time = 1 > KDB: stack backtrace: > ... > data_abort() at do_el1h_sync+0x144 > pc = 0xffff00000053f590 lr = 0xffff00000053e8c8 > sp = 0xffff000000010530 fp = 0xffff000000010560 > > do_el1h_sync() at handle_el1h_sync+0x78 > pc = 0xffff00000053e8c8 lr = 0xffff000000525078 > sp = 0xffff000000010570 fp = 0xffff000000010680 > > handle_el1h_sync() at simple_mfd_syscon_write_4+0x60 > pc = 0xffff000000525078 lr = 0xffff0000000fb028 > sp = 0xffff000000010690 fp = 0xffff000000010740 > > simple_mfd_syscon_write_4() at tsadc_attach+0x44c > pc = 0xffff0000000fb028 lr = 0xffff000000553b58 > sp = 0xffff000000010750 fp = 0xffff0000000107c0 > > tsadc_attach() at device_attach+0x3e0 > pc = 0xffff000000553b58 lr = 0xffff00000028ad1c > sp = 0xffff0000000107d0 fp = 0xffff000000010830 > > device_attach() at bus_generic_new_pass+0x12c > pc = 0xffff00000028ad1c lr = 0xffff00000028cb58 > sp = 0xffff000000010840 fp = 0xffff000000010870 > ... > Stopped at generic_bs_w_4: undefined b8226823 > > Relevant extract from FDT: > syscon@ff100000 { > compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd"; > reg = <0x0 0xff100000 0x0 0x1000>; > #address-cells = <0x1>; > #size-cells = <0x1>; > phandle = <0x13>; > io-domains { > compatible = "rockchip,rk3328-io-voltage-domain"; > status = "okay"; > vccio1-supply = <0x20>; > vccio2-supply = <0x22>; > vccio3-supply = <0x20>; > vccio4-supply = <0x21>; > vccio5-supply = <0x20>; > vccio6-supply = <0x20>; > pmuio-supply = <0x20>; > phandle = <0x14>; > }; > grf-gpio { > compatible = "rockchip,rk3328-grf-gpio"; > gpio-controller; > #gpio-cells = <0x2>; > phandle = <0x15>; > }; > power-controller { > compatible = "rockchip,rk3328-power-controller"; > #power-domain-cells = <0x1>; > #address-cells = <0x1>; > #size-cells = <0x0>; > phandle = <0x16>; > pd_hevc@6 { > > reg = <0x6>; > }; > pd_video@5 { > > reg = <0x5>; > }; > pd_vpu@8 { > > reg = <0x8>; > }; > }; > reboot-mode { > compatible = "syscon-reboot-mode"; > offset = <0x5c8>; > mode-normal = <0x5242c300>; > mode-recovery = <0x5242c303>; > mode-bootloader = <0x5242c309>; > mode-loader = <0x5242c301>; > }; > }; > ... > tsadc@ff250000 { > compatible = "rockchip,rk3328-tsadc"; > reg = <0x0 0xff250000 0x0 0x100>; > interrupts = <0x0 0x3a 0x4>; > assigned-clocks = <0x46 0x24>; > assigned-clock-rates = <0xc350>; > clocks = <0x46 0x24 0x46 0xd5>; > clock-names = "tsadc", "apb_pclk"; > pinctrl-names = "init", "default", "sleep"; > pinctrl-0 = <0x7c>; > pinctrl-1 = <0x7d>; > pinctrl-2 = <0x7c>; > resets = <0x46 0x42>; > reset-names = "tsadc-apb"; > rockchip,grf = <0x13>; > rockchip,hw-tshut-temp = <0x186a0>; > #thermal-sensor-cells = <0x1>; > status = "okay"; > rockchip,hw-tshut-mode = <0x0>; > rockchip,hw-tshut-polarity = <0x0>; > phandle = <0x30>; > }; > > What dts are you using? The syscon should be syscon@ff770000. In my case: ... syscon@ff770000 { compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd"; reg = <0x0 0xff770000 0x0 0x10000>; #address-cells = <0x1>; #size-cells = <0x1>; phandle = <0x82>; ... tsadc@ff260000 { compatible = "rockchip,rk3399-tsadc"; reg = <0x0 0xff260000 0x0 0x100>; interrupts = <0x0 0x61 0x4 0x0>; assigned-clocks = <0x81 0x4f>; assigned-clock-rates = <0xb71b0>; clocks = <0x81 0x4f 0x81 0x164>; clock-names = "tsadc", "apb_pclk"; resets = <0x81 0xe8>; reset-names = "tsadc-apb"; rockchip,grf = <0x82>; rockchip,hw-tshut-temp = <0x17318>; pinctrl-names = "init", "default", "sleep"; pinctrl-0 = <0x112>; pinctrl-1 = <0x113>; pinctrl-2 = <0x112>; #thermal-sensor-cells = <0x1>; status = "okay"; rockchip,hw-tshut-mode = <0x1>; rockchip,hw-tshut-polarity = <0x1>; phandle = <0x3a>; }; ... here http://dpaste.com/3MTFPPG is full dts I'm using on NanoPC-T4 board. Ganbold > -- > Peter Jeremy > From owner-freebsd-arm@freebsd.org Sun Dec 1 13:54:14 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 191001ABC35 for ; Sun, 1 Dec 2019 13:54:14 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47QqVD5p9sz3M9s; Sun, 1 Dec 2019 13:54:12 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qk1-x731.google.com with SMTP id d124so14765589qke.6; Sun, 01 Dec 2019 05:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EfBO+pB+11BTqqQ/+nVVle6fh726VMkt9UnFYn1fAm8=; b=Wu/FT282XTHkYmotwm2sYFz+9l0IxHGrSKHfMRJ1DBBTUVrLzbKBMusn+vCQNGUmxF XFAsUJ49YTwwm576UYzu0k+stGPZ9xGJa3JeR0GKqxXUUpWRSiA2xU69nWNhq7HNjVUn UAl/8WzFsdzc1LgEh2GbavgD90zD65R4YjFq/MVbMJ4Px6MN4gixlYVOAyzjCKMvHPUM A1h/lfTq7ks/XCBzBSfxUYD1iXNaiDI2z7u9l38RhG5CNu1muFSv5sinknHl9nPtGKOh GjDEigIcGlXfFCHqDp8Wwa43k11m+LHtkamDjGHuldWZkcQK4Yw55u1jHRtkDDsyjUeS d2zA== 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=EfBO+pB+11BTqqQ/+nVVle6fh726VMkt9UnFYn1fAm8=; b=H2+u24eKCo50Y/GFikzCpKHrniMPdHtvyUt9CAdG8j4y9X4RsBNTRA6O7sf2wGY4zt J2l/8KLnPBIONP1iFLCz360FuWYScyBhD/nJh8hnQrmFhk+vbVQW2htF1lYg0uOfHhnw 9+XhrV03j52j3cUjhvWONdeqWfvsIll84Ax3SokDM8Q3BBhN/rC2KNJQNFpx8b8mzlwN RUC2QZozDe6pHj1jcdMlW7Kb+VKYSS82M6rWx5c/ItO4yKPbsoJYYA2UTG0EvRH/fgyH Lmp6KKNWmXsy314NGxEd7HA34uOofzNtyrIiZR+DHodSVDarGoWdq9pVYg2WXdAr1tJF W1zA== X-Gm-Message-State: APjAAAUl5B7vehsR+NV2qn4xTKFcIVhszpigxQx/w1fpAwcXaSPjr+uX eJ35DU/mDSP6obWm2pbkeeGgATqRHsgdGpn6y6hD34Jp X-Google-Smtp-Source: APXvYqxabz8n06MZwBJjjbD6+Qjxb0kMq06Vfn1mFXHXbaNCwJNyKplP5+bcLPwe0VyBDwM85iqBIpFpM8GVczrbTCE= X-Received: by 2002:a37:8185:: with SMTP id c127mr27396986qkd.43.1575208450960; Sun, 01 Dec 2019 05:54:10 -0800 (PST) MIME-Version: 1.0 References: <20191201110716.GA41224@server.rulingia.com> In-Reply-To: From: Ganbold Tsagaankhuu Date: Sun, 1 Dec 2019 21:54:00 +0800 Message-ID: Subject: Re: rk_tsadc breaks (my) Rock64 To: Peter Jeremy Cc: Michal Meloun , "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: 47QqVD5p9sz3M9s X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Wu/FT282; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ganbold@gmail.com designates 2607:f8b0:4864:20::731 as permitted sender) smtp.mailfrom=ganbold@gmail.com X-Spamd-Result: default: False [-1.90 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.28), ipnet: 2607:f8b0::/32(-2.25), asn: 15169(-1.94), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SH_EMAIL_ZRD(0.00)[0.0.0.8,0.0.0.5,0.0.0.6]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.6,0.0.0.8,0.0.0.5]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 13:54:14 -0000 On Sun, Dec 1, 2019 at 9:40 PM Ganbold Tsagaankhuu wrote: > > > On Sun, Dec 1, 2019 at 7:07 PM Peter Jeremy wrote: > >> r355173 added code to read the Rockchip temperature sensors. >> Unfortunately, >> this breaks on my Rock64. I've tried to understand what's going wrong but >> haven't managed to make much headway. It looks like there some >> configuration >> missing from syscon that tsadc needs but I'm not sure what (and I don't >> really >> understand what syscon is doing). I'd appreciate any insights. >> >> Relevant extract from the dmesg: >> simple_mfd0: mem >> 0xff450000-0xff45ffff on ofwbus0 >> ... >> rk_tsadc0: mem 0xff250000-0xff2500ff irq >> 22 on ofwbus0 >> rk_tsadc0: nclocks=1, nparents=-1 >> rk_tsadc0: Set clk_tsadc to 50000 >> panic: data abort with spinlock held >> cpuid = 0 >> time = 1 >> KDB: stack backtrace: >> ... >> data_abort() at do_el1h_sync+0x144 >> pc = 0xffff00000053f590 lr = 0xffff00000053e8c8 >> sp = 0xffff000000010530 fp = 0xffff000000010560 >> >> do_el1h_sync() at handle_el1h_sync+0x78 >> pc = 0xffff00000053e8c8 lr = 0xffff000000525078 >> sp = 0xffff000000010570 fp = 0xffff000000010680 >> >> handle_el1h_sync() at simple_mfd_syscon_write_4+0x60 >> pc = 0xffff000000525078 lr = 0xffff0000000fb028 >> sp = 0xffff000000010690 fp = 0xffff000000010740 >> >> simple_mfd_syscon_write_4() at tsadc_attach+0x44c >> pc = 0xffff0000000fb028 lr = 0xffff000000553b58 >> sp = 0xffff000000010750 fp = 0xffff0000000107c0 >> >> tsadc_attach() at device_attach+0x3e0 >> pc = 0xffff000000553b58 lr = 0xffff00000028ad1c >> sp = 0xffff0000000107d0 fp = 0xffff000000010830 >> >> device_attach() at bus_generic_new_pass+0x12c >> pc = 0xffff00000028ad1c lr = 0xffff00000028cb58 >> sp = 0xffff000000010840 fp = 0xffff000000010870 >> ... >> Stopped at generic_bs_w_4: undefined b8226823 >> >> Relevant extract from FDT: >> syscon@ff100000 { >> compatible = "rockchip,rk3328-grf", "syscon", >> "simple-mfd"; >> reg = <0x0 0xff100000 0x0 0x1000>; >> #address-cells = <0x1>; >> #size-cells = <0x1>; >> phandle = <0x13>; >> io-domains { >> compatible = "rockchip,rk3328-io-voltage-domain"; >> status = "okay"; >> vccio1-supply = <0x20>; >> vccio2-supply = <0x22>; >> vccio3-supply = <0x20>; >> vccio4-supply = <0x21>; >> vccio5-supply = <0x20>; >> vccio6-supply = <0x20>; >> pmuio-supply = <0x20>; >> phandle = <0x14>; >> }; >> grf-gpio { >> compatible = "rockchip,rk3328-grf-gpio"; >> gpio-controller; >> #gpio-cells = <0x2>; >> phandle = <0x15>; >> }; >> power-controller { >> compatible = "rockchip,rk3328-power-controller"; >> #power-domain-cells = <0x1>; >> #address-cells = <0x1>; >> #size-cells = <0x0>; >> phandle = <0x16>; >> pd_hevc@6 { >> >> reg = <0x6>; >> }; >> pd_video@5 { >> >> reg = <0x5>; >> }; >> pd_vpu@8 { >> >> reg = <0x8>; >> }; >> }; >> reboot-mode { >> compatible = "syscon-reboot-mode"; >> offset = <0x5c8>; >> mode-normal = <0x5242c300>; >> mode-recovery = <0x5242c303>; >> mode-bootloader = <0x5242c309>; >> mode-loader = <0x5242c301>; >> }; >> }; >> ... >> tsadc@ff250000 { >> compatible = "rockchip,rk3328-tsadc"; >> reg = <0x0 0xff250000 0x0 0x100>; >> interrupts = <0x0 0x3a 0x4>; >> assigned-clocks = <0x46 0x24>; >> assigned-clock-rates = <0xc350>; >> clocks = <0x46 0x24 0x46 0xd5>; >> clock-names = "tsadc", "apb_pclk"; >> pinctrl-names = "init", "default", "sleep"; >> pinctrl-0 = <0x7c>; >> pinctrl-1 = <0x7d>; >> pinctrl-2 = <0x7c>; >> resets = <0x46 0x42>; >> reset-names = "tsadc-apb"; >> rockchip,grf = <0x13>; >> rockchip,hw-tshut-temp = <0x186a0>; >> #thermal-sensor-cells = <0x1>; >> status = "okay"; >> rockchip,hw-tshut-mode = <0x0>; >> rockchip,hw-tshut-polarity = <0x0>; >> phandle = <0x30>; >> }; >> >> > What dts are you using? > The syscon should be syscon@ff770000. > In my case: > ... > syscon@ff770000 { > > compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd"; > reg = <0x0 0xff770000 0x0 0x10000>; > #address-cells = <0x1>; > #size-cells = <0x1>; > phandle = <0x82>; > ... > tsadc@ff260000 { > > compatible = "rockchip,rk3399-tsadc"; > reg = <0x0 0xff260000 0x0 0x100>; > interrupts = <0x0 0x61 0x4 0x0>; > assigned-clocks = <0x81 0x4f>; > assigned-clock-rates = <0xb71b0>; > clocks = <0x81 0x4f 0x81 0x164>; > clock-names = "tsadc", "apb_pclk"; > resets = <0x81 0xe8>; > reset-names = "tsadc-apb"; > rockchip,grf = <0x82>; > rockchip,hw-tshut-temp = <0x17318>; > pinctrl-names = "init", "default", "sleep"; > pinctrl-0 = <0x112>; > pinctrl-1 = <0x113>; > pinctrl-2 = <0x112>; > #thermal-sensor-cells = <0x1>; > status = "okay"; > rockchip,hw-tshut-mode = <0x1>; > rockchip,hw-tshut-polarity = <0x1>; > phandle = <0x3a>; > }; > ... > > here http://dpaste.com/3MTFPPG is full dts I'm using on NanoPC-T4 board. > Sorry, I missed that you seem to be using rk3328 based board. In my case it is rk3399 board and it is working. Ganbold > > Ganbold > > >> -- >> Peter Jeremy >> > From owner-freebsd-arm@freebsd.org Sun Dec 1 14:54:05 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 005F51AE0F2 for ; Sun, 1 Dec 2019 14:54:05 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47QrqH4vwXz3Pkf for ; Sun, 1 Dec 2019 14:54:03 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 01 Dec 2019 14:53:19 +0000 To: Mark Millard From: Robert Crowston Cc: "freebsd-arm@freebsd.org" , "mw@semihalf.com" Reply-To: Robert Crowston Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 Message-ID: In-Reply-To: References: Feedback-ID: 2OVbcR1yHYpdkD8cgQllkFwcuMVZg_LiVMMPvptooFDfHD_03MuQO4ZaF626jWHZYFEhNR2cmIbZ53j4QGWMBQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: 47QrqH4vwXz3Pkf X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.00)[ip: (-9.64), ipnet: 185.70.40.0/24(-4.89), asn: 62371(-3.92), country: CH(0.02)]; RCVD_IN_DNSWL_LOW(-0.10)[22.40.70.185.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=default]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 14:54:05 -0000 Given your hang happens before "----" is written to the console, it s= eems like a problem in stand. (mountroot etc is a distraction; that happens= towards the end of the boot process.) > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0xbe844018. I would try using a different dtb instead of the one u-boot is providing. At the boot loader "OK" prompt, you can change the DTB. You can even try to= pass in the one you think u-boot is giving you, in case it is passing the = wrong address to the bootloader. Something like (I don't remember exactly): OK load /path/to/kernel OK load -t dtb /path/to/dtb OK boot You can also enable verbose boot, which might show a tiny little more detai= l before the hang, but since we don't get to ----, I am not optimisti= c. btw, if you are a programmer, these problems are much easier to diagnose wi= th a JTAG, which can be as cheap as 20 USD. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, 1 December 2019 10:21, Mark Millard via freebsd-arm wrote: > I tried to get a MACCHIATObin Double Shot Rev 1.3 to boot -r355027 > (a non-debug build). The first (partial) result based on older > materials made me hopeful, but trying more modern materials did not > get as far. > > I started from old media that I happened to have around from last time > I'd had access and tried to boot the MACCHIATObin and got to (showing > the old vintage as well): > > . . . > FreeBSD 12.0-ALPHA8 #3 r339076M: Thu Oct 4 14:24:26 PDT 2018 > markmi@FBSDUSSD:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLV= M 6.0.1) > . . . > Release APs...done > Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... > > The /etc/fstab was wrong and I knew it would be. This was a quick test be= fore > updating to more modern content that I was actually interested in. / for = all > this was (and is) on a Samsung SATA SSD. > > I got here via using a UEFI image from: > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/Bina= ries/ > > specifically using: > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/file= s/flash-image-mcbin-mainline-r20190509.bin > > on uSD media via (on another FreeBSD machine): > > dd if=3D/root/flash-image-mcbin-mainline-r20190509.bin bs=3D512 seek=3D1 = of=3D/dev/da3 conv=3Dsync > > I had set the jumpers to have the MACCHIATObin use the uSD media instead > of spi content. (That is also how I booted Arch Linux ARM from uSD media > so it was already set up that way.) > > After getting this far I updated to having head -r355027 on the SATA > SSD (matching other context I have around) and copied over the modern > loader.efi to replace the old efi file. > > Having done this I only get as far as: > > . . . > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0xbe844018. > > A "|" or "/" sometimes shows up on the next line but it does not > show the typical sequence of symbols and there is no more evidence > of progress. The text is seen via the serial console. > > I've hypothesized bunches of things that might make a difference, > none have. I tried putting back the old .efi file. I tried building > the .dtb from the -r355027 materials and forcing that to be loaded. > (Each failing alternative was reverted as I went along.) I tried > an old .dtb file that I had around. I tried the 18.09.4 .bin file > on the uSD media. I tried various ways of specifying were / was > supposed to be from. I tried with and without: > > kern.cam.boot_delay=3D10000 > vfs.mountroot.timeout=3D10 > > I did notice one distinction for before vs. after the -r35027 > update. Before the update always got: > > loaddev=3Ddisk0p2: > > After the update always got: > > loaddev=3Ddisk0p1: > > disk0p1 has the efi file system; disk0p2 has the ufs file system. > > By contrast, currdev got "disk0p2:" in both contexts. > > (Side note: I last tried to boot this board with FreeBSD was over > a year ago but ended up redirected and without access until > recently. Marcin had tried to help me back then. I'm not sure > how long I'll have access this round.) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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" From owner-freebsd-arm@freebsd.org Sun Dec 1 19:32:04 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 901D51B5ABA for ; Sun, 1 Dec 2019 19:32:04 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (mail.yourbox.net [IPv6:2001:41d0:1:767d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.yourbox.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Qz032HTDz49Ym for ; Sun, 1 Dec 2019 19:32:02 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail.yourbox.net (8.15.2/8.15.2) with ESMTP id xB1JVsQi002901 for ; Sun, 1 Dec 2019 20:31:55 +0100 (CET) (envelope-from fbl@aoek.com) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 01 Dec 2019 20:31:49 +0100 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: freebsd-arm@freebsd.org Subject: How to build working images for RPI Message-ID: <7b0c24213c7f9f0657802978e5ca82f7@mail.yourbox.net> X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.2.0 X-Rspamd-Queue-Id: 47Qz032HTDz49Ym X-Spamd-Bar: - X-Spamd-Result: default: False [-1.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.60)[-0.604,0]; R_DKIM_ALLOW(-0.20)[aoek.com:s=mailbox]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.85)[-0.845,0]; IP_SCORE(0.66)[ipnet: 2001:41d0::/32(1.48), asn: 16276(1.80), country: FR(-0.00)]; DKIM_TRACE(0.00)[aoek.com:+]; DMARC_POLICY_ALLOW(-0.50)[aoek.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 19:32:04 -0000 Hi, images built with crochet are not working (no boot, no nothing) on RPI but images downloaded from https://download.freebsd.org/ftp/snapshots/arm/armv6/ISO-IMAGES do How do they build the downloadable images? The wiki https://wiki.freebsd.org/arm/Raspberry%20Pi states that you can build your own images with crochet but it does not state how THEY build the working images that are on the FTP site. I notice that the images built with crochet are VERY different from the ones you download, for example: md0 has the crochet image, md1 the downloaded one crochet # gpart show md0 => 1 5859374 md0 MBR (2.8G) 1 62 - free - (31K) 63 34776 1 fat32lba [active] (17M) 34839 1001 - free - (501K) 35840 5823488 2 freebsd (2.8G) 5859328 47 - free - (24K) crochet # gpart show md1 => 63 6291393 md1 MBR (3.0G) 63 1008 - free - (504K) 1071 102312 1 fat32lba [active] (50M) 103383 6188049 2 freebsd (3.0G) 6291432 24 - free - (12K) rochet # ll /mnt/md0/boot/msdos/ total 2448 -rwxr-xr-x 1 root wheel 765 Nov 23 15:53 README* -rwxr-xr-x 1 root wheel 199 Nov 23 15:53 boot.scr* -rwxr-xr-x 1 root wheel 75 Nov 23 15:53 config.txt* -rwxr-xr-x 1 root wheel 37 Nov 23 15:53 metadata* -rwxr-xr-x 1 root wheel 19602 Nov 23 15:53 rpi.dtb* -rwxr-xr-x 1 root wheel 21186 Nov 23 15:53 rpi.dts* -rwxr-xr-x 1 root wheel 465860 Nov 23 15:53 u-boot.bin* -rwxr-xr-x 1 root wheel 0 Nov 23 15:53 uEnv.txt* -rwxr-xr-x 1 root wheel 1586895 Nov 23 15:53 ubldr* -rwxr-xr-x 1 root wheel 386184 Nov 23 15:53 ubldr.bin* crochet # ll /mnt/md1/boot/msdos/ total 13460 drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 EFI/ -rwxr-xr-x 1 root wheel 23315 Nov 12 2018 bcm2708-rpi-0-w.dtb* -rwxr-xr-x 1 root wheel 23071 Nov 12 2018 bcm2708-rpi-b-plus.dtb* -rwxr-xr-x 1 root wheel 22812 Nov 12 2018 bcm2708-rpi-b.dtb* -rwxr-xr-x 1 root wheel 22589 Nov 12 2018 bcm2708-rpi-cm.dtb* -rwxr-xr-x 1 root wheel 52116 Nov 12 2018 bootcode.bin* -rwxr-xr-x 1 root wheel 89 Nov 21 03:11 config.txt* drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 dtb/ -rwxr-xr-x 1 root wheel 6666 Nov 12 2018 fixup.dat* -rwxr-xr-x 1 root wheel 2621 Nov 12 2018 fixup_cd.dat* -rwxr-xr-x 1 root wheel 9895 Nov 12 2018 fixup_db.dat* -rwxr-xr-x 1 root wheel 9895 Nov 12 2018 fixup_x.dat* drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 overlays/ -rwxr-xr-x 1 root wheel 2857060 Nov 12 2018 start.elf* -rwxr-xr-x 1 root wheel 678532 Nov 12 2018 start_cd.elf* -rwxr-xr-x 1 root wheel 5120484 Nov 12 2018 start_db.elf* -rwxr-xr-x 1 root wheel 4057956 Nov 12 2018 start_x.elf* -rwxr-xr-x 1 root wheel 465868 Nov 21 03:06 u-boot.bin* -r-xr-xr-x 1 root wheel 386408 Nov 21 04:48 ubldr.bin* crochet # cat /mnt/md0/boot/msdos/config.txt gpu_mem=32 device_tree=rpi.dtb device_tree_address=0x100 kernel=u-boot.bin crochet # cat /mnt/md1/boot/msdos/config.txt init_uart_clock=3000000 enable_uart=1 kernel=u-boot.bin kernel7=u-boot.bin dtoverlay=mmc I had to patch crochet to have the image built, but that's another story. Can anyone point me on how to build working images for RPI? Thanks in advance. Regards, -- José Pérez From owner-freebsd-arm@freebsd.org Sun Dec 1 19:47:04 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2EADF1B5E56 for ; Sun, 1 Dec 2019 19:47:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.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 47QzKL66xqz4B6P for ; Sun, 1 Dec 2019 19:47:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Wmz92uwVM1n8E_OojsI_WBljw6SpniLOz.OIfDZxmYjND5C1usF680UV84EAGYX MWeLss9F.jwFp3fwsTLv79KuYBAu14dkUCG7ZAC2.tzOB370qDmEsHRAKxaf2WLeTT3ejfSYAHcW OrGa4z2uMW7kXp44EV2bnSKZcarBI5nCn.jWPS.83rNbPscg8wU9dUzR_nA19IN8WjwEhLmyZHyn eJHqmWGpAnSjAXyfwJHgDmUStCTb3Wcb3VjkIFPFX18r4uId_yHj3fqPXYlW7Uk3gL4wCa80jvIj LfguAWf3uug_Vktrl.5xfQVHe2DHWUpHz5mVHTJYQMIfbi6u5Mpn5KIWe8vq1I1TDBwL.s6_rhN3 LzqT_V1VUfWfdRRfKriJIZD5IiFOxnYDGCIkWMhhEp0jXFdqflTOC0rhqZ8r8RcWMmlprDjv87xC Sna.NIIYku0fxLVdMo6n2tADRDN7XkkNd7cjNJ6_EgtQZm6wgFtuIiCMtw7.mzmqH3hhP_HHuKwE 0AvCU6E0ebCzS3LM9SU3WARj5jTymSq23tsrXb9bVoM4udmcKI.4CTc1fLeW32CYQMmE279xhMD2 0kjp3zsa8XUnMdCbqUc.V7dJScrykcNY3dInSezDhyDfKCfBihEWBov668k1w7xyWUOrH4i_jTP1 31rQN5mmrXCn8qMAgDjNMDSiGUj7kkOpdbqn8ThA0zn6I6bYyawsaWpzFE7DrdkoRfFTCImJioLO keCN8t23NEOEX9FS58QE9iB2p4x9_pI_FgYXs4FWOC4YAVGRFLSXnsUCXPAaXSUNdEiPbXzPNApy 72ZIu8gV3YzadHf3C3dOPJgwHzMN8P7uYVWmqU2q0.JwrlO18gMkmRGUdGdh3eruHAFPu2NLW8hZ cgGUCa0aoDJKfr6j_rB3TR_5drWKuWiK1KeKjO5v2gH_E.2ycnhCE3hQpoMyNz1vuumGDfOtO3eE Tqj8tfVz80PNoVjBZY5rZsS6ICJYJNGjY1.hqotORk0XygB04tObCZI91QuXA5Fsvnu_De3Ln9a4 B9KhUvdGwxc6GmND9m_BDk.CpBP07FZ03E2HT6fx8hioQykLPmwM3j7PditeMuv5o3WiTsc5aIjH ldIdlSoy1x3aFl0tyVWsVQXoh59FrIRC5Vdzv6v297Tk89xyCh5L03jncRpSZtDZCXZLO891Xhxt wiPp1iaP9_7cVaopO9sYW5iPizER_ku3KISEc_j83KpUmFZa34RUrHd8E0giZ4BLyjsmnzAKSgsE seWgV5pRNP1lUoaYnr7f8OZYwVTyZA80cfj2MOqOSFIb_QqJRCKXxC23v_uciKUk4ob7FAfBlicW .UW1uodVS_N4fVrijLFm67Sb3ibf7Eb4jlGly_8V6o6l9.Ye07sjKI7pxlLtxtf2fJol8XF09YKr eBXdC9ZC0uGCllMOyEl3qjrD_X4eZsdM1Yvtvgg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Dec 2019 19:47:00 +0000 Received: by smtp419.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e299619ad87ea2a7286fde6bfdf460bc; Sun, 01 Dec 2019 19:46:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 From: Mark Millard In-Reply-To: Date: Sun, 1 Dec 2019 11:46:54 -0800 Cc: "freebsd-arm@freebsd.org" , "mw@semihalf.com" Content-Transfer-Encoding: quoted-printable Message-Id: <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> References: To: Robert Crowston X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47QzKL66xqz4B6P X-Spamd-Bar: / X-Spamd-Result: default: False [0.34 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (6.80), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; NEURAL_SPAM_MEDIUM(0.25)[0.255,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.58)[0.581,0]; RCVD_IN_DNSWL_NONE(0.00)[148.68.137.98.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 19:47:04 -0000 On 2019-Dec-1, at 06:53, Robert Crowston = wrote: > Given your hang happens before "----" is written to the console, = it seems like a problem in stand. (mountroot etc is a distraction; that = happens towards the end of the boot process.) The mountroot material from when the kernel got that far was from the old version of FreeBSD. What changed was the FreeBSD materials being updated. A mismatch between the more modern FreeBSD and the dtb content it is set up to deal with vs. what is provided for the dtb is a possibility. >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by EFI at 0xbe844018. >=20 > I would try using a different dtb instead of the one u-boot is = providing. >=20 Note that edk2 is for UEFI. It is configurable for if it hands over a dtb vs. ACPI information. Trying ACPI just got a report of the dtb being missing. So I continued with the dtb option. Both before and after updating the FreeBSD version involved reported the same dtb line, with the address matching: Using DTB provided by EFI at 0xbe844018 As far as I can tell the dtb did not vary except when I tried other ones: I built and tried -r355027 's materials and tried another old one that I had around. I'm not sure where another appropriate one might be. Of course, when I tried the older edk2 (18.09.4) = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/files= /flash-image-18.09.4.bin the reported address was different --and likely the older content might have been somewhat different for the dtb. So I've tried 3-4 dtb's so far. > At the boot loader "OK" prompt, you can change the DTB. You can even = try to pass in the one you think u-boot is giving you, in case it is = passing the wrong address to the bootloader. Something like (I don't = remember exactly): >=20 > OK load /path/to/kernel > OK load -t dtb /path/to/dtb > OK boot Yep. But, so far, I've not found one that gets any farther along in the serial output with head -r355027 . > You can also enable verbose boot, which might show a tiny little more = detail before the hang, but since we don't get to ----, I am not = optimistic. boot -v displayed nothing extra. (It is one of the things I'd tried in order to get information but produced nothing to report.) > btw, if you are a programmer, these problems are much easier to = diagnose with a JTAG, which can be as cheap as 20 USD. JTAG is not something I've ever used. (Accident of my history.) I made need to. What I'm thinking of doing next is trying different kernels (and possibly loaders) from artifacts.ci.freebsd.org . (Avoiding needing to build them, plus they are debug builds, in case that helps figure things out.) First I'd likely confirm that reverting to somewhere around 339076 repeats what I originally got. (I may have to replace the -r355027 world with an old one so the time relationship to the kernel is right if it looks like I want try beyond mountroot at some point.) Thanks for the notes. [Nothing more added below.] > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90 > On Sunday, 1 December 2019 10:21, Mark Millard via freebsd-arm = wrote: >=20 >> I tried to get a MACCHIATObin Double Shot Rev 1.3 to boot -r355027 >> (a non-debug build). The first (partial) result based on older >> materials made me hopeful, but trying more modern materials did not >> get as far. >>=20 >> I started from old media that I happened to have around from last = time >> I'd had access and tried to boot the MACCHIATObin and got to (showing >> the old vintage as well): >>=20 >> . . . >> FreeBSD 12.0-ALPHA8 #3 r339076M: Thu Oct 4 14:24:26 PDT 2018 >> = markmi@FBSDUSSD:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarch= 64/sys/GENERIC-NODBG arm64 >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) >> . . . >> Release APs...done >> Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... >>=20 >> The /etc/fstab was wrong and I knew it would be. This was a quick = test before >> updating to more modern content that I was actually interested in. / = for all >> this was (and is) on a Samsung SATA SSD. >>=20 >> I got here via using a UEFI image from: >>=20 >> = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/Binar= ies/ >>=20 >> specifically using: >>=20 >> = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/files= /flash-image-mcbin-mainline-r20190509.bin >>=20 >> on uSD media via (on another FreeBSD machine): >>=20 >> dd if=3D/root/flash-image-mcbin-mainline-r20190509.bin bs=3D512 = seek=3D1 of=3D/dev/da3 conv=3Dsync >>=20 >> I had set the jumpers to have the MACCHIATObin use the uSD media = instead >> of spi content. (That is also how I booted Arch Linux ARM from uSD = media >> so it was already set up that way.) >>=20 >> After getting this far I updated to having head -r355027 on the SATA >> SSD (matching other context I have around) and copied over the modern >> loader.efi to replace the old efi file. >>=20 >> Having done this I only get as far as: >>=20 >> . . . >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by EFI at 0xbe844018. >>=20 >> A "|" or "/" sometimes shows up on the next line but it does not >> show the typical sequence of symbols and there is no more evidence >> of progress. The text is seen via the serial console. >>=20 >> I've hypothesized bunches of things that might make a difference, >> none have. I tried putting back the old .efi file. I tried building >> the .dtb from the -r355027 materials and forcing that to be loaded. >> (Each failing alternative was reverted as I went along.) I tried >> an old .dtb file that I had around. I tried the 18.09.4 .bin file >> on the uSD media. I tried various ways of specifying were / was >> supposed to be from. I tried with and without: >>=20 >> kern.cam.boot_delay=3D10000 >> vfs.mountroot.timeout=3D10 >>=20 >> I did notice one distinction for before vs. after the -r35027 >> update. Before the update always got: >>=20 >> loaddev=3Ddisk0p2: >>=20 >> After the update always got: >>=20 >> loaddev=3Ddisk0p1: >>=20 >> disk0p1 has the efi file system; disk0p2 has the ufs file system. >>=20 >> By contrast, currdev got "disk0p2:" in both contexts. >>=20 >> (Side note: I last tried to boot this board with FreeBSD was over >> a year ago but ended up redirected and without access until >> recently. Marcin had tried to help me back then. I'm not sure >> how long I'll have access this round.) >>=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 Sun Dec 1 20:16:18 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 611F01B6A51 for ; Sun, 1 Dec 2019 20:16:18 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Qzz50lz7z4CRj for ; Sun, 1 Dec 2019 20:16:16 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 01 Dec 2019 20:16:13 +0000 Received: from wms1-eu-central.migadu.com (wms1-eu-central.migadu.com [172.104.244.218]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 6D7FF534-0E9A-4EBC-835A-39C8E9496FFB.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 01 Dec 2019 20:16:12 +0000 MIME-Version: 1.0 Date: Sun, 01 Dec 2019 20:16:12 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: <48debf6151a25b93b4e740460e226682@unrelenting.technology> Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 To: "Mark Millard" , freebsd-arm@freebsd.org In-Reply-To: References: DKIM-Signature: v=1; a=rsa-sha256; bh=ppTMC3V+omhf5iA/837SXAK7OhUqLeyTuacgDSOBz5Q=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=EB8sU5IOlqzA0ZTsijatAuCk2AIn6PjnaqBlvla2s7pWzruZiaTE57/AAn6Jku3cyaw2tdWcC9skj4gbV88vSCIvckl+AGQ6xtZNhROhWTFw2Zk8v54TLuJNUbgJHRpITekaNu2iZQwkQ97FasqW0xCPcaUkKwUCzCixBVq45dg= X-Rspamd-Queue-Id: 47Qzz50lz7z4CRj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=EB8sU5IO; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.29)[ip: (-9.85), ipnet: 91.121.0.0/16(-3.39), asn: 16276(1.80), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 20:16:18 -0000 December 1, 2019 1:21 PM, "Mark Millard via freebsd-arm" wrote:=0A=0A> I tried to get a MACCHIATObin Double Shot Rev 1.3= to boot -r355027=0A> . . .=0A> Hit [Enter] to boot immediately, or any o= ther key for command prompt.=0A> Booting [/boot/kernel/kernel]...=0A> Usi= ng DTB provided by EFI at 0xbe844018.=0A> =0A> A "|" or "/" sometimes sho= ws up on the next line but it does not=0A> show the typical sequence of s= ymbols and there is no more evidence=0A> of progress. The text is seen vi= a the serial console.=0A=0AHave you tried connecting a GPU and monitor in= stead? :)=0A=0AMake sure to have boot_multicons=3DYES and boot_serial=3DY= ES in /boot/loader.conf=0Aif you use serial =E2=80=94 if there is an EFI = framebuffer (which I think might=0Abe available even without a GPU maybe?= ? I don't remember) FreeBSD would default=0Ato graphical console only I'm= pretty sure.=0A=0A> I've hypothesized bunches of things that might make = a difference,=0A> none have. I tried putting back the old .efi file. I tr= ied building=0A> the .dtb from the -r355027 materials and forcing that to= be loaded.=0A> (Each failing alternative was reverted as I went along.) = I tried=0A> an old .dtb file that I had around.=0A=0AHave you tried ACPI = instead of DTB? (in setup, Device Manager - O/S Hardware Description)=0A= =0AActually on Marcin's builds the serial console might not work with tha= t=0Abecause the SPCR table there is intentionally wrong to support Linux,= but the links=0Abelow should be my builds, you can try ACPI with them (t= hey also remove a=0APCIe hack for supporting "~legacy" devices to make ot= her devices=0Alike the Radeon RX 480 work).=0A=0Ahttps://unrelentingtech.= s3.dualstack.eu-west-1.amazonaws.com/flash-image.bin=0Ahttps://unrelentin= gtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image2.bin From owner-freebsd-arm@freebsd.org Sun Dec 1 20:18:36 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F2921B6BA2 for ; Sun, 1 Dec 2019 20:18:36 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R01l3p7Yz4Cfr for ; Sun, 1 Dec 2019 20:18:35 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 01 Dec 2019 20:18:33 +0000 Received: from wms1-eu-central.migadu.com (wms1-eu-central.migadu.com [172.104.244.218]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id BC593528-6C14-4E98-B4F4-43FABBF7A8AA.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 01 Dec 2019 20:18:33 +0000 MIME-Version: 1.0 Date: Sun, 01 Dec 2019 20:18:33 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 To: "Mark Millard" , "Robert Crowston" Cc: freebsd-arm@freebsd.org In-Reply-To: <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> References: <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> DKIM-Signature: v=1; a=rsa-sha256; bh=P/ciFbFVlQk3IXKSMPWJQ8K3naUy/i3fOSAmlWjguqw=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=kwoVdYOSZc0fD003NLv0RcjZMFiuX2OoXnC66PTLqbcPESbJtVzaPhU+/cAUmX8HDw27qAsMYHwMnsXz7N0UvQrM+l6cI3zEejF3NtYmNXnZEdIJIv4xfSz2dNRLcThik9LpSRy2nLaEuJiZRO4NmVw59F7gGMFRuKa64jIPAnQ= X-Rspamd-Queue-Id: 47R01l3p7Yz4Cfr X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=kwoVdYOS; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.29)[ip: (-9.85), ipnet: 91.121.0.0/16(-3.41), asn: 16276(1.80), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 20:18:36 -0000 December 1, 2019 10:46 PM, "Mark Millard via freebsd-arm" wrote:=0A=0A> Note that edk2 is for UEFI. It is configurable f= or if it hands over=0A> a dtb vs. ACPI information. Trying ACPI just got = a report of the=0A> dtb being missing. So I continued with the dtb option= .=0A=0Adtb missing is *correct* with ACPI :)=0A=0A>> You can also enable = verbose boot, which might show a tiny little more detail before the hang,= but=0A>> since we don't get to ----, I am not optimistic.=0A=0AYep= , not getting ---- pretty much always means the serial console is n= ot configured correctly. From owner-freebsd-arm@freebsd.org Sun Dec 1 20:45:36 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 631301B7B6F for ; Sun, 1 Dec 2019 20:45:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 47R0cv1m00z4FRP for ; Sun, 1 Dec 2019 20:45:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gbyLMZ4VM1nZLoUNPB4GH32R7aIdx4vYDgDF1Fj48CJ6crnsOvR_Umajlf2KwxZ VYSEA2dvmkg4gL.XG7Qeu6gjSNPluZdqRtoNVODlOx.Q5paQB6Q__t9M.n01_u3TJVq7.97NltTX FmRX7w6VvZxH27eK1T5ChVecJpOiKHB8y7BaQER2RLxEq5SyRxAhEQtpCVW8RcFFaCCMHYoyWGa2 .Eb5.JqK2ZR4jlQvDlc8cZB02DJ.jx06SrmTSYqpSutcOlza5J.3Fwp.PEfIq85VJEcCMhWSxZld C5eo5t0x9kINAfwZHQ7s7zxmevI43YX5u0GIZnQT9NChG2VejLX0Smq2G9GJ.cc5sOo_BIpGWVjS b3pgZnEfxcbvjYxy.Nr3287_0ZfcqhnUqZhIIN_qgBXwXVnDMm6PQNYBp5yM41TtzjKpGlkGc4F5 puxlaJ.IrM3RY93SLee0MIRUyFr7rTZE4FzqKdtDl.BylmKE9Mk44ESxLqE6Fhjo6D4AtxxJKmuj GlA7Cv76WZX.Dn5bemQuQ2apzni0.q_XuTI2e4.AB8pBuWuRO3mvTT7OOsjoitHLblZno9EC5_Ux axxzGdHm8tL2PRTb_hMiA.Z07b9O8mnahwFEPii_nAeC4_vjMdygAi3bK4TfsFcNncXbxtcvSVe. iQlV690QtBksSYXu8JfLbdS2BK3GtimGgibYgqhbggndh3snnlNgVgliOBhJVgSBH6h.FdipL5rY mQDw.sNwiU0nnxJBEx5HKeTMQl1nY2pqcz5s7Um4V7DoNKXbcGIgllQ6vGrzxZd7_AYn7hspfXRT TnPb80yk5jU2orViRoj98qlJrVRdhscSYbwHBEeyGVIg2nzbudUSJnjvmc4TfP_fzZsZS_umJO2L v.kFvsI2GWPwMLcJCmK_H8VVMw0nmEVAxwX_eKtjnRzveHkYh3DobSFFTgQX7EPNNfovbaiq.q0O 5bSB5ZJONxCRxDW1ROfORDvejdHHYbAe7N5Leek9x6KPooxCrHxn6_SYY10LMYX2zzupZj3gXbfA IbhLIA_c3Y.o2ij.gEtlVCA4CqaVEMDzL8pLPuOmVpuHvKX9lYtkfYPHGLG04eui2rGDn2Gxbu.x 8Ou0Cl2KSoiTY3Daz.Ph9JCawVx_9CTDrM5BLS3QKSk3IaaytJjeocp.yy1Uo1V4U5bY8DEKIaT8 n1OhLICDoxcwC.FtFJSUECxegR8xBg3jy_x0xbIpRD5Adk67HvYkqrb37TYmTQS5aEGKz1AmLZhF lfrKSrvKEktDw97Xgk3nayG9gU0jb4DtR3lgITUq34t7gmThnR6GIOpkSynAKUjiL04Lr6oKAvIf fjcMxbcwKi2cY72S7Hw3lG6DKnLCSav4_D0ZunsgxBBVsdSDo05VTxUUXP02YGuS9UtCpCEl2fkR B29UVzzOfMfdBC9mfs4yCaGMcR8Opyy09pDGhitc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Dec 2019 20:45:32 +0000 Received: by smtp403.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1408b7889ab6e15cab147b4bd9257daa; Sun, 01 Dec 2019 20:45:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 From: Mark Millard In-Reply-To: Date: Sun, 1 Dec 2019 12:45:27 -0800 Cc: Robert Crowston , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B89ADF5-FA8B-4EB9-B2CC-CFBF017A8BD7@yahoo.com> References: <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> To: Greg V X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47R0cv1m00z4FRP X-Spamd-Bar: / X-Spamd-Result: default: False [-0.21 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (4.85), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.04)[0.041,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.25)[0.252,0]; RCVD_IN_DNSWL_NONE(0.00)[83.65.137.98.list.dnswl.org : 127.0.5.0]; FREEMAIL_CC(0.00)[protonmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 20:45:36 -0000 [Mixing materials from 2 emails that came in.] On 2019-Dec-1, at 12:18, greg at unrelenting.technology wrote: > December 1, 2019 10:46 PM, "Mark Millard via freebsd-arm" = wrote: >=20 >> Note that edk2 is for UEFI. It is configurable for if it hands over >> a dtb vs. ACPI information. Trying ACPI just got a report of the >> dtb being missing. So I continued with the dtb option. >=20 > dtb missing is *correct* with ACPI :) Yep. But: A) The older FreeBSD got as far as did using dtb, not ACPI. (Not that I'd tried ACPI then.) So my best evidence of progress was with dtb. B) It looked like FreeBSD materials were reporting an error and possibly stopping because of it. Not being familiar with what to expect beyond what I was seeing, I went with dtb after that message showed up. >>> You can also enable verbose boot, which might show a tiny little = more detail before the hang, but >>> since we don't get to ----, I am not optimistic. >=20 > Yep, not getting ---- pretty much always means the serial = console is not configured correctly. On 2019-Dec-1, at 12:16, greg at unrelenting.technology wrote: > Have you tried connecting a GPU and monitor instead? :) No GPU around to plug in. (No original intent to use a GPU either.) > Have you tried ACPI instead of DTB? (in setup, Device Manager - O/S = Hardware Description) Yep. It did not work either. See above. > Actually on Marcin's builds the serial console might not work with = that > because the SPCR table there is intentionally wrong to support Linux, = but the links > below should be my builds, you can try ACPI with them (they also = remove a > PCIe hack for supporting "~legacy" devices to make other devices > like the Radeon RX 480 work). Thanks. That gives me another direction to try. What is the distinction between the two .bin files? Should I try both even if the first I try works? Is there something of interest to be learned? =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 Dec 1 21:00:11 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D6B621B80AD for ; Sun, 1 Dec 2019 21:00:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R0xl5SKcz4G12 for ; Sun, 1 Dec 2019 21:00:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A03941C786 for ; Sun, 1 Dec 2019 21:00:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xB1L0BSb018491 for ; Sun, 1 Dec 2019 21:00:11 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xB1L0BAG018490 for freebsd-arm@FreeBSD.org; Sun, 1 Dec 2019 21:00:11 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201912012100.xB1L0BAG018490@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, 1 Dec 2019 21:00:11 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 21:00:11 -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 ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 2 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Sun Dec 1 21:32:19 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E803D1BA170 for ; Sun, 1 Dec 2019 21:32:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 47R1fp5pxwz4Jf3 for ; Sun, 1 Dec 2019 21:32:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: FTyKVjoVM1kSt7OVnLvFpujqixodJQmzdnRHQ6PFAdie_bMxhTQNKDXN7kS3m_o C8I8KHCGdMPDVJAa7I6S2Tt5Xkh5UQuhTgPU0Wn1G6lwg.OnQLWGq0Y0rJqlqatGpKlX0P4Gf.gY EQDt46iIOiXPYVD0fRB.4iM7Gmv7676HAhB_F5ncxm2OmYfz3jgrAAZ_LW3TLZ3_Y_1JRLkH8mfy trbELIIvlV1iH3.JNZr2oOSmXkz.IE1Z45WoMgCGZ3Ks0QdEoYXbLcXwMusFrzPIDaJ.3ZMchV9r t7.b5_YVNJftw_0_JTxZeCwq1HFCcSHl_stU6ekTOkE5T0noxmyWBK4QtcEkmlGEWtSpkPQOUIGO X2MRkJAwUFGtffdAHR.RbrLmDwliBd9aV7_UfU4Vw0X8MVyL_vTqAMoqbf.88h5eSNoxmVoj3Vpw gEXRIz71IdE.0JamckET8_Sh2sfPLsVsUPSXqAlcoOqiIwsJ37Ual_GrSJXXAbvRaIIk9RwIHY0B KbzfEgyoqTuW.Ane8oOf32Ebf5_yhIeUsB56hT1Mb95WxZgB4GEDlln1.UV.7yzH_YW7k6c4o2hs QKEpkx8Ew3BbIVWkZ9dRDW4Fw4fg.Bee9Wu2nIthaTdEyArMDDGfeX1YS5T96IZGUMLMJzoNi_cX V6IP18uScBBEMzKY8ArFXdvvRhBq3U4rL1UM1SdbCoWUaAnERM.roIbmP8mymvf3uQWVJfWjFBHx Gv_vsAnpg9S4EowY2He5IRPav5eTY8RtpZwg5i0lbYEkSnSk3elzl2vJYp6knEqt._Nt7TYhiR2v .2iFanJZCmHJ368s6fUeqyFQy9sbcLAgmGAX8ZODU9QY9fUQdJ3_EoKxaEK30c.GV__aJHvMVa1c 6d4ex0GTgJMW9YdMSqN5_g0MK1SMCpPa3MeNfNjhHdqrgPtI0bUzjZGFtkez2UqBPjzDD_6wpCKT MsKysXKQqr7A4v_XuLgGeY5xfcJlVUfBGSgEu9nNOuizg_MYF6HT2HmlQnr05iXy7.eahlUoTSqN _2sT_MjS_PXQx90zRWhTGyrFi0KAVzRIpH5F5y_OKRWFSpFdGDMN_KETULkR7T8YIHa3MlLahaYG upKHWDKHQeKTxx92QHT88sbeAe4Ga7Yf1G.YZuHTe687NLDA2PqjWIG5EQ2K6kzhoYu2YYawfHm6 dKNWX0uLBhsmkrd40xQen8L78PM_PZbRHdEk9bFmeG.W_hYIXxFmwyFr9vog07GiT4X6EA1uXv9z Vu8p4MOU7n46q5q5MnRV_QPhdQhQSSIjRMWrLfpSwfZN7X.SixPt0TCL_dDJyFcRrRXQtBiFTOyQ TRHKjiPLbWewUPZmg.FZLg4RFsQRuUZiuk1bKC.QtfbmJcONE8KiiegehNAztUpJfoC1fKUKTOcz hzWgk.CMvMcSk2LV7f4m9hqK2_sKuixSR7KhbIA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Dec 2019 21:32:17 +0000 Received: by smtp414.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9a8ac8273d317c16ca4bca17652b6f82; Sun, 01 Dec 2019 21:32:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 From: Mark Millard In-Reply-To: <8B89ADF5-FA8B-4EB9-B2CC-CFBF017A8BD7@yahoo.com> Date: Sun, 1 Dec 2019 13:32:10 -0800 Cc: Robert Crowston , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <366042EF-094B-4E7D-9582-256C5379DA20@yahoo.com> References: <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> <8B89ADF5-FA8B-4EB9-B2CC-CFBF017A8BD7@yahoo.com> To: Greg V X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47R1fp5pxwz4Jf3 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.54 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (4.04), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.08)[-0.079,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.04)[0.043,0]; RCVD_IN_DNSWL_NONE(0.00)[206.64.137.98.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[protonmail.com] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 21:32:20 -0000 On 2019-Dec-1, at 12:45, Mark Millard wrote: > [Mixing materials from 2 emails that came in.] >=20 > On 2019-Dec-1, at 12:18, greg at unrelenting.technology wrote: >=20 >> December 1, 2019 10:46 PM, "Mark Millard via freebsd-arm" = wrote: >>=20 >>> Note that edk2 is for UEFI. It is configurable for if it hands over >>> a dtb vs. ACPI information. Trying ACPI just got a report of the >>> dtb being missing. So I continued with the dtb option. >>=20 >> dtb missing is *correct* with ACPI :) >=20 > Yep. But: >=20 > A) The older FreeBSD got as far as did using dtb, not ACPI. > (Not that I'd tried ACPI then.) So my best evidence of > progress was with dtb. > B) It looked like FreeBSD materials were reporting an error > and possibly stopping because of it. >=20 > Not being familiar with what to expect beyond what I was > seeing, I went with dtb after that message showed up. >=20 >>>> You can also enable verbose boot, which might show a tiny little = more detail before the hang, but >>>> since we don't get to ----, I am not optimistic. >>=20 >> Yep, not getting ---- pretty much always means the serial = console is not configured correctly. >=20 >=20 > On 2019-Dec-1, at 12:16, greg at unrelenting.technology wrote: >=20 >> Have you tried connecting a GPU and monitor instead? :) >=20 > No GPU around to plug in. (No original intent to use a GPU > either.) >=20 >> Have you tried ACPI instead of DTB? (in setup, Device Manager - O/S = Hardware Description) >=20 > Yep. It did not work either. See above. >=20 >> Actually on Marcin's builds the serial console might not work with = that >> because the SPCR table there is intentionally wrong to support Linux, = but the links >> below should be my builds, you can try ACPI with them (they also = remove a >> PCIe hack for supporting "~legacy" devices to make other devices >> like the Radeon RX 480 work). >=20 >=20 > Thanks. That gives me another direction to try. >=20 > What is the distinction between the two .bin files? > Should I try both even if the first I try works? Is > there something of interest to be learned? With changing to ACPI with flash-image2.bin mostly worked and did boot to multi-user (dtb failed the same old way): # uname -apKU FreeBSD FBSDmacch 13.0-CURRENT FreeBSD 13.0-CURRENT #14 r355027M: Sat = Nov 23 03:58:57 PST 2019 = markmi@FBSDFHUGE:/usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarc= h64/sys/GENERIC-NODBG arm64 aarch64 1300061 1300061 But the console output for the boot has a large hole in it: . . . Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! !!!! LOTS OF STUFF MISSING HERE. !!!! Setting hostuuid: 7c431ce3-c871-11e8-974a-e0fff70020ed. Setting hostid: 0x22ac6547. Starting file system checks: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p2: clean, 189820987 free (59587 frags, 23720175 blocks, 0.0% = fragmentation) Mounting local filesystems:. . . . I do not know what to do to get, say, the slower speed EtherNet going, or if I can. But the serial console seems to be working fine once it starts going. FYI: Making no adjustments (such as to ACPI) failed in two different ways, one per .bin: dd if=3D/root/flash-image.bin bs=3D512 seek=3D1 of=3D/dev/da3 conv=3Dsync produced a uSD card that resulted in: ASSERT_EFI_ERROR (Status =3D Device Error) ASSERT [PciHostBridgeDxe] = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDx= e/DEBUG/AutoGen.c(436): !EFI_ERROR (Status) dd if=3D/root/flash-image2.bin bs=3D512 seek=3D1 of=3D/dev/da3 conv=3Dsync= produced a uSD card that resulted in: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0xbe7e4018. (stopping at the same place/way as my original report, at least for what is visible on the serial console). Thanks! =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 Dec 1 21:38:17 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AFD721BA26A for ; Sun, 1 Dec 2019 21:38:17 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R1nh2p34z4Jkn for ; Sun, 1 Dec 2019 21:38:16 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id xB1LblhA015070 for ; Sun, 1 Dec 2019 16:38:16 -0500 Received: from w92expo29.exchange.mit.edu (18.7.74.41) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 1 Dec 2019 16:37:36 -0500 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by w92expo29.exchange.mit.edu (18.7.74.41) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 1 Dec 2019 16:37:53 -0500 Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1365.000; Sun, 1 Dec 2019 16:37:53 -0500 From: John F Carr To: "freebsd-arm@freebsd.org" Subject: 64 bit ARM systems with more than four cores Thread-Topic: 64 bit ARM systems with more than four cores Thread-Index: AQHVqI+WQAw9H9EGNE2x2ZhuP9fHBA== Date: Sun, 1 Dec 2019 21:37:53 +0000 Message-ID: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [108.7.221.50] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 47R1nh2p34z4Jkn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.13 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [-3.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[mit.edu]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.96)[ipnet: 18.9.0.0/16(-4.73), asn: 3(-0.00), country: US(-0.05)]; RCVD_IN_DNSWL_MED(-0.20)[13.28.9.18.list.dnswl.org : 127.0.11.2]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 21:38:17 -0000 I have a quad core 64 bit ARM system (SoftIron Overdrive 1000). I am wonde= ring what faster 64 bit ARM systems exist and which of them work, or almost= work, with FreeBSD. Excluding 4 core and below systems regardless of performance, and also excl= uding cloud-only hardware, I made the list below. Did I miss anything or i= naccurately describe support? Two RK3399 based systems, 2 A-72 + 4 A-53: RockPro64 (http://www.pine64.com= /) and ROCK Pi 4 (http://radxa.com). I can't use the RockPro64 due to the = 1.5 MBps serial port. Apparently it works or almost works with some specia= l handling if your serial interface can count to 1,500,000. The ROCK Pi 4 = is in crochet so it must work... right? Does it have a reasonable console = port bit rate? SoftIron Overdrive 3000, 8 A-53 cores. No longer available. One LX2160A based system, 16 A-72 cores: HoneyComb LX2K (https://www.solid-= run.com/nxp-lx2160a-family/honeycomb-workstation/). I see relevant files i= n sys/gnu/dts/arm64/freescale but nothing outside of these files imported f= rom Linux. It's not mentioned on https://wiki.freebsd.org/arm64. My guess= is that means FreeBSD does not run. Is it a little job or a big one? SC2A11, 24 A-53 cores at 1 GHz: SynQuacer (https://www.96boards.org/product= /developerbox/). I don't see any evidence of SC2A11 support in the kernel= tree or on https://wiki.freebsd.org/arm64. My guess is that means FreeBSD= does not run. ThunderX in various forms, rack mount or workstation. Nice specs and appar= ently supported but the two American system builders don't seem interested = in selling me one. ThunderX2. Great specs and apparently mostly supported but rather expensiv= e.. (Honorable mention to Banana PI M3 with 8 cores, but 32 bits only.)= From owner-freebsd-arm@freebsd.org Sun Dec 1 21:39:21 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25B461BA2FC for ; Sun, 1 Dec 2019 21:39:21 +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 47R1pw04bPz4Jn6 for ; Sun, 1 Dec 2019 21:39: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 xB1LdL25049435 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Dec 2019 13:39:22 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id xB1LdK9b049434; Sun, 1 Dec 2019 13:39:20 -0800 (PST) (envelope-from fbsd) Date: Sun, 1 Dec 2019 13:39:20 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Reverting -current by date. Message-ID: <20191201213920.GA49395@www.zefox.net> References: <20191120233653.GA1475@www.zefox.net> <20191121031141.GB1837@www.zefox.net> <20191121175817.GA5375@www.zefox.net> <20191121190903.GB5375@www.zefox.net> <20191126010310.GA26370@www.zefox.net> <254A5077-DE9E-4B6A-9A4D-D9FA2F858F54@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <254A5077-DE9E-4B6A-9A4D-D9FA2F858F54@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 47R1pw04bPz4Jn6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.23 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.875,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.30), ipnet: 50.1.16.0/20(0.15), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.87)[-0.869,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 21:39:21 -0000 On Mon, Nov 25, 2019 at 05:52:02PM -0800, Mark Millard wrote: > > > > FYI, one contributor to from-scratch build times might be > the update to llvm 9: > > QUOTE > Revision 353358 - (view) (download) (annotate) - [select for diffs] > Modified Wed Oct 9 17:06:56 2019 UTC (6 weeks, 5 days ago) by dim > File length: 12392 byte(s) > Diff to previous 353274 > Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp > 9.0.0 final release > r372316 > . > > Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: > > > https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html > https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html > https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html > https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html > > > PR: 240629 > MFC after: 1 month > END QUOTE > > I do not know if you do anything to limit what is built relative to > llvm or not. (I do not remember the defaults or the minimums.) > > Are your from-scratch rebuilds building both a bootstrap llvm9 and > the normal llvm9? Or is the existing llvm9 used instead of making > a bootstrap build of llvm9? > > Any llvm8->llvm9 transition will get the bootstrap build of llvm9, > which then will be used for the later stages. > I think the transition is complete at this point, with clang60 through clang80 resident in /usr/local/bin and clang9 being default. Is there any reason to think clang9 is substantially slower or more resource-intensive than clang 8? if so, that, that would at least contribute to the difficulties I'm observing (along with tired flash devices). Last time the machine successfully compiled www/chromium it took about 3.5 GB of swap at peak. Recent attempts, even with -j2, are approaching 4 GB and failing with random kernel panics. Thanks very much for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sun Dec 1 21:42:27 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7AA2C1BA561 for ; Sun, 1 Dec 2019 21:42:27 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R1tV2mCqz4K3T for ; Sun, 1 Dec 2019 21:42:25 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 01 Dec 2019 21:42:23 +0000 Received: from wms0-eu-central.migadu.com (wms0-eu-central.migadu.com [139.162.159.86]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id A35FB0B7-8537-41EC-82E3-70C71A71362B.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 01 Dec 2019 21:42:23 +0000 MIME-Version: 1.0 Date: Sun, 01 Dec 2019 21:42:23 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 To: "Mark Millard" Cc: "Robert Crowston" , freebsd-arm@freebsd.org In-Reply-To: <366042EF-094B-4E7D-9582-256C5379DA20@yahoo.com> References: <366042EF-094B-4E7D-9582-256C5379DA20@yahoo.com> <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> <8B89ADF5-FA8B-4EB9-B2CC-CFBF017A8BD7@yahoo.com> DKIM-Signature: v=1; a=rsa-sha256; bh=9rYfizr0K/ZeQI5aeFRb9OVMM2YlqtBDDCUVsjtYehY=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=NyHoGDGpAswPIUAZHxavPwUPYXVgpxvUJRfic0sLBXdc2hE3boBBfM16CzTzu+B+1agEBH2f1y23QV+/d83toWOEC5ZLdZwAQX/V/t4gg+MMQLIbK/Fqo68Td43XVW19P+BLYNOxynCVwfEoUsz96+Vsa19LtQgWXY5CqQbd0yQ= X-Rspamd-Queue-Id: 47R1tV2mCqz4K3T X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=NyHoGDGp; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.30)[ip: (-9.85), ipnet: 91.121.0.0/16(-3.43), asn: 16276(1.80), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; FREEMAIL_CC(0.00)[protonmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 21:42:27 -0000 December 2, 2019 12:32 AM, "Mark Millard" wrote:=0A>>= What is the distinction between the two .bin files?=0A=0AI don't remembe= r, but I just decided not to overwrite one of the files=0Aon the S3 bucke= t for some reason back then :D=0A=0A> With changing to ACPI with flash-im= age2.bin mostly worked=0A> and did boot to multi-user (dtb failed the sam= e old way):=0A> =0A> But the console output for the boot has a large hole= in it:=0A=0AHm, only the userspace but not the kernel one.=0AI'm more fa= miliar with the opposite case :)=0A(namely on amazon ec2: https://reviews= .freebsd.org/D19896)=0A=0AAgain, did you enable boot_multicons in loader.= conf?=0A=0A> I do not know what to do to get, say, the slower speed Ether= Net going,=0A> or if I can. But the serial console seems to be working fi= ne once it=0A> starts going.=0A=0AThe onboard Ethernet? Nope, even the 1G= bit port belongs to the fancy Marvell PPv2 NIC.=0AI sort of barely attemp= ted porting the driver from Linux:=0Ahttps://github.com/myfreeweb/pepevtw= o-kmod=0Abut did not have the time/energy to implement anything beyond wr= iting the initial=0Aconfiguration registers on the device.=0A=0AI just us= e an axge(4) based USB Ethernet dongle.=0ASince you don't use a GPU, you = can add a PCIe NIC instead :) From owner-freebsd-arm@freebsd.org Sun Dec 1 21:56:58 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 24EC71BA8E4 for ; Sun, 1 Dec 2019 21:56:58 +0000 (UTC) (envelope-from Michael.Tuexen@macmic.franken.de) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R2CD3R5bz4KPg for ; Sun, 1 Dec 2019 21:56:55 +0000 (UTC) (envelope-from Michael.Tuexen@macmic.franken.de) Received: from mb.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 0733E721E281C; Sun, 1 Dec 2019 22:56:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: 64 bit ARM systems with more than four cores From: Michael Tuexen In-Reply-To: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> Date: Sun, 1 Dec 2019 22:56:27 +0100 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9B00305C-115E-4D56-97A9-D34DD37F90FF@macmic.franken.de> References: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> To: John F Carr X-Mailer: Apple Mail (2.3601.0.10) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 47R2CD3R5bz4KPg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of Michael.Tuexen@macmic.franken.de has no SPF policy when checking 193.175.24.27) smtp.mailfrom=Michael.Tuexen@macmic.franken.de X-Spamd-Result: default: False [-2.39 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; IP_SCORE(-1.70)[ip: (-8.56), ipnet: 193.174.0.0/15(-0.01), asn: 680(0.10), country: DE(-0.01)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[franken.de]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[27.24.175.193.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 21:56:58 -0000 > On 1. Dec 2019, at 22:37, John F Carr wrote: >=20 > I have a quad core 64 bit ARM system (SoftIron Overdrive 1000). I am = wondering what faster 64 bit ARM systems exist and which of them work, = or almost work, with FreeBSD. >=20 > Excluding 4 core and below systems regardless of performance, and also = excluding cloud-only hardware, I made the list below. Did I miss = anything or inaccurately describe support? >=20 > Two RK3399 based systems, 2 A-72 + 4 A-53: RockPro64 = (http://www.pine64.com/) and ROCK Pi 4 (http://radxa.com). I can't use = the RockPro64 due to the 1.5 MBps serial port. Apparently it works or = almost works with some special handling if your serial interface can = count to 1,500,000. The ROCK Pi 4 is in crochet so it must work... = right? Does it have a reasonable console port bit rate? >=20 > SoftIron Overdrive 3000, 8 A-53 cores. No longer available. >=20 > One LX2160A based system, 16 A-72 cores: HoneyComb LX2K = (https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/). = I see relevant files in sys/gnu/dts/arm64/freescale but nothing outside = of these files imported from Linux. It's not mentioned on = https://wiki.freebsd.org/arm64. My guess is that means FreeBSD does not = run. Is it a little job or a big one? >=20 > SC2A11, 24 A-53 cores at 1 GHz: SynQuacer = (https://www.96boards.org/product/developerbox/). I don't see any = evidence of SC2A11 support in the kernel tree or on = https://wiki.freebsd.org/arm64. My guess is that means FreeBSD does not = run. >=20 > ThunderX in various forms, rack mount or workstation. Nice specs and = apparently supported but the two American system builders don't seem = interested in selling me one. >=20 > ThunderX2. Great specs and apparently mostly supported but rather = expensive.. I'm running a system from Ampere Computing / Lenovo: https://amperecomputing.com/ in my lab. See the dmesg output at https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5068 Best regards Michael >=20 > (Honorable mention to Banana PI M3 with 8 cores, but 32 bits only.) > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Dec 1 22:05:40 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36F181BAC70 for ; Sun, 1 Dec 2019 22:05:40 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R2PH1VYhz4KlG for ; Sun, 1 Dec 2019 22:05:39 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 01 Dec 2019 22:05:37 +0000 Received: from wms0-eu-central.migadu.com (wms0-eu-central.migadu.com [139.162.159.86]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 5DED345C-84E9-4D6C-BC4D-D55ABA38ACB7.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 01 Dec 2019 22:05:37 +0000 MIME-Version: 1.0 Date: Sun, 01 Dec 2019 22:05:37 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: Subject: Re: 64 bit ARM systems with more than four cores To: "John F Carr" , freebsd-arm@freebsd.org In-Reply-To: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> References: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; bh=M1jKrgqD2kxZGPkETteP3WnIcwhCvs3jO4+675kUa6E=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=LIPJqVhuwsBO7Tng3woYTyCFWfmSaa7//TVDYOwZ4c99R+S4ccbWXYTGAArh7yjw3Vrw498F/OiSkMdOiigkCMwLtTM6gGAPkRruAdIXcydvuFLqQxHcZg65CxjG1zQ3so1wHE205PGabqNKq9mbeWqgkdAk+dAA7DWEvJiUkgs= X-Rspamd-Queue-Id: 47R2PH1VYhz4KlG X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=LIPJqVhu; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.30)[ip: (-9.85), ipnet: 91.121.0.0/16(-3.46), asn: 16276(1.80), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 22:05:40 -0000 December 2, 2019 12:37 AM, "John F Carr" wrote:=0A=0A> Two = RK3399 based systems, 2 A-72 + 4 A-53: RockPro64 (http://www.pine64.com) = and ROCK Pi 4=0A> (http://radxa.com). I can't use the RockPro64 due to th= e 1.5 MBps serial port. Apparently it works=0A> or almost works with some= special handling if your serial interface can count to 1,500,000. The=0A= > ROCK Pi 4 is in crochet so it must work... right? Does it have a reason= able console port bit rate?=0A=0ABefore I got my 1.5M capable dongle for = the ROCKPro64, I just had an u-boot command to=0Aswitch to 115200 in the = boot script.=0A=0AI consider 2xA72+4xA53 worse than 4xA72 to be honest.= =0AEspecially since the FreeBSD scheduler is not big.LITTLE aware =E2=80= =94 it loves to schedule=0Ae.g. a big single-threaded linker job onto the= slow cores. So you have to mess with=0Acpuset but apply it carefully to = still utilize all cores on parallel tasks.. argh.=0A=0A> One LX2160A base= d system, 16 A-72 cores: HoneyComb LX2K=0A> (https://www.solid-run.com/nx= p-lx2160a-family/honeycomb-workstation). I see relevant files in=0A> sys/= gnu/dts/arm64/freescale but nothing outside of these files imported from = Linux. It's not=0A> mentioned on https://wiki.freebsd.org/arm64. My guess= is that means FreeBSD does not run. Is it a=0A> little job or a big one?= =0A=0AThere's SBSA-ish ACPI-capable firmware so it should boot, but proba= bly with uhh not a lot of devices.=0AThey've been sort of vaguely promisi= ng that PCIe would work in ACPI..=0Aand recently this commit dropped:=0Ah= ttps://source.codeaurora.org/external/qoriq/qoriq-components/edk2-platfor= ms/commit/?h=3DLX2-UEFI-ACPI-0.2&id=3Dec8deb524171a03448395e6b8acc49978bc= f5ce5=0Aso maybe I shouldn't have doubted them, but I missed the $500 dis= count period waiting for this :(=0A=0A> SC2A11, 24 A-53 cores at 1 GHz: S= ynQuacer (https://www.96boards.org/product/developerbox). I don't=0A> see= any evidence of SC2A11 support in the kernel tree or on https://wiki.fre= ebsd.org/arm64. My=0A> guess is that means FreeBSD does not run.=0A=0AThe= re's SBSA-ish ACPI-capable firmware so it should boot, and PCIe should wo= rk.=0AI guess nobody tried because it's very expensive for something with= A53 cores.=0A=0AI would *not* trade my MACCHIATObin for this because A53= is just so slow.=0A=0A> ThunderX in various forms, rack mount or worksta= tion. Nice specs and apparently supported but the=0A> two American system= builders don't seem interested in selling me one.=0A=0AKeep in mind that= the TX1 cores are slow. It's great at super parallel workloads,=0Abut wh= en you have something single-threaded, it's no better than an A53.=0A=0A= =0A=0ANow, if you have cash but not ThunderX2 levels of cash: Ampere eMAG= is the best option.=0AAvailable in Lenovo HR350A and HR330A boxes, also = from Avantek (idk what's the mainboard there??),=0Aalso rentable in bare-= metal-cloud at Packet (they have the Lenovos).=0A=0ASee https://bugs.free= bsd.org/bugzilla/show_bug.cgi?id=3D237055 for the bringup story :)=0AI th= ink most of the bugfixes required for eMAG are in -CURRENT. From owner-freebsd-arm@freebsd.org Sun Dec 1 22:07:24 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A47481BAD18 for ; Sun, 1 Dec 2019 22:07:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.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 47R2RH4mKMz4Knp for ; Sun, 1 Dec 2019 22:07:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: j1AAxUAVM1lyb04i6vTbT1zfh0a8c0nY78jZ0ssyEA7Uxw8fZVi0RxXXXHF5vmf CIFCNCVjOQ_L50p604qsZHqe6oN.WNSnmRSVglxnZsteo2Nve_e2feoL.8Cv9Yo3qcl8hDhyZWt5 eMjLk0HA2CsN4KLpEer1eE0V1m1dmWevDYFU2WmYfQsDjF4BdGd12uQgKevg5qUAcSu3CcaDpltg tSVALtLyp3MF_U2iib.VL3irIu2xkeK.2i6abNl62HaOkxr0LgqmOKmo3V0WsYxZo_EnNdcO8alp gErJ2wdEcLbG5MGh6HmyhNq8oaaqJb_3Wswz2KB9NzVQZEdllGyOzJrPdFlCXyFoiF1XpzawdpHa Rku0_YHyf9jUhahW2t9bqe.P7zSRtPIf0BygLSv5DH8j7zF0K6S4zB1w8H2QYvAvM61Jsxk8Lwan kvrZ_T9KPHp65gSkNBVrtk0ijP2464nw0XA3dLt_E9wu_Xe7y_xIpPUaz.KffRXgtzIAhG.FtGIP bJTyBQX8ZF7ghujw0VlgW5DPuWyZQqyBYnrp3xIV0xd9T16dhI1wOI1njKNH_9fNm1aZfSHYCpJO q_vK797n7HLky5UzXYrq2vF.6f6Wm76ecDW_jzVierVlXW1tKo0vZuoG3X0Qb8P.XUSh_5AtvGKA 64k._b5HzSPcbSAma1WrRJLG8qo.W0U0lw01gu_QM1vzzZ2wQVogDfKoUmO8yibbtdIfP36hQmNO CHiD_7bfVGVAuXh.QCPrg9iVQJYeHojKZIkPmq4zVq8xoW9D196LCtz6lZ1OLzu7o2wWmor8Cy7_ ctgOm0An37EoTQDpYms5XuYjjh7RLP1cOZzogiEI60jf8rJTyvKwxZPXPp3SkwHcNSy4LGcRd56q nf1z_CjFDlQLF1vq9YtaMAHUJ32nWFkRf3VNNEitwv0Q_JkxkPs2ybXnoz7_Tlvx2j0i6Xx4Jv7a alRQidF.OXqMDuHi1s5bAFgYMbTBWb3lcXeryiNzzY8FL88YcV_GMJYYqcJcaYJrgWnx.HCrQB_J uo75Q6q1xI7naiGjm_Yz.Ed73QMxgtpm_l23RTlObSw3b_X3A045iQGMMZsMNfbfiUGAxGJNR2_u Fv06h463NZIgKgzacOp_Veq9zVTn7PnPDtlJjyoJwfKV.1vWzg80aRiEJ2AcZQSat3T21HTZotkU psGtXzJNgt0jgQZHo1DJZSyvcSnLd3wvXgUQB8kLZCpSHniwrSy8MDCfjoNMHvSpNxgP5G7.A1Pg Xo_WWobB92d3K1eXRdTyjIr27Y3QvWzhPk9u8i7dGh1mjmD2qirBnHvGYWBckMpAPNBOKg01rIBc CvHWYq8qzPsIFkbUnVTdS3ycTKtNxCabuucQZa02boOKEAzonrz4BPZqE3Huu5uunTWFJyArbEZZ CgaNfpv8P_GHYiyhfXZnBIpfuKSy_l276dJz7lnxs Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Dec 2019 22:07:21 +0000 Received: by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 66504a53bcf70f82d7a94c7261f7fcc3; Sun, 01 Dec 2019 22:07:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 From: Mark Millard In-Reply-To: Date: Sun, 1 Dec 2019 14:07:15 -0800 Cc: Robert Crowston , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C089454-02E4-42C0-B967-3081B6FDBD3A@yahoo.com> References: <366042EF-094B-4E7D-9582-256C5379DA20@yahoo.com> <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> <8B89ADF5-FA8B-4EB9-B2CC-CFBF017A8BD7@yahoo.com> To: greg@unrelenting.technology X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47R2RH4mKMz4Knp X-Spamd-Bar: / X-Spamd-Result: default: False [0.24 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (6.53), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.26)[0.260,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.48)[0.480,0]; RCVD_IN_DNSWL_NONE(0.00)[148.68.137.98.list.dnswl.org : 127.0.5.0]; FREEMAIL_CC(0.00)[protonmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 22:07:24 -0000 On 2019-Dec-1, at 13:42, greg at unrelenting.technology wrote: > December 2, 2019 12:32 AM, "Mark Millard" = wrote: >>> What is the distinction between the two .bin files? >=20 > I don't remember, but I just decided not to overwrite one of the files > on the S3 bucket for some reason back then :D >=20 >> With changing to ACPI with flash-image2.bin mostly worked >> and did boot to multi-user (dtb failed the same old way): >>=20 >> But the console output for the boot has a large hole in it: >=20 > Hm, only the userspace but not the kernel one. > I'm more familiar with the opposite case :) > (namely on amazon ec2: https://reviews.freebsd.org/D19896) >=20 > Again, did you enable boot_multicons in loader.conf? boot_multicons=3DYES boot_serial=3DYES made no difference to the hole in the output --or any other difference that I've noticed. My interpretation is that the hole in: Booting [/boot/kernel/kernel]... No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! !!!! LOTS OF STUFF MISSING HERE. !!!! Setting hostuuid: 7c431ce3-c871-11e8-974a-e0fff70020ed. spans from at the end of the the loader, through all the kernel output, into the output associated with world. Given that it managed to boot, dmesg does show from ---<>--- on. And I observe that the dtb notice really is a to-be-expected warning for ACPI in this sort of context. >> I do not know what to do to get, say, the slower speed EtherNet = going, >> or if I can. But the serial console seems to be working fine once it >> starts going. >=20 > The onboard Ethernet? Nope, even the 1Gbit port belongs to the fancy = Marvell PPv2 NIC. > I sort of barely attempted porting the driver from Linux: > https://github.com/myfreeweb/pepevtwo-kmod > but did not have the time/energy to implement anything beyond writing = the initial > configuration registers on the device. >=20 > I just use an axge(4) based USB Ethernet dongle. > Since you don't use a GPU, you can add a PCIe NIC instead :) Good to know. I'll look into finding and using a USB Ethernet dongle that I think is around somewhere. Thanks much. =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 Dec 1 22:36:04 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 323571BB86F for ; Sun, 1 Dec 2019 22:36:04 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 47R34L6W0Dz4LvY for ; Sun, 1 Dec 2019 22:36:02 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id xB1MZpai007260; Sun, 1 Dec 2019 16:35:51 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201912012235.xB1MZpai007260@mail.karels.net> To: Jose Perez cc: freebsd-arm@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: How to build working images for RPI In-reply-to: Your message of Sun, 01 Dec 2019 20:31:49 +0100. <7b0c24213c7f9f0657802978e5ca82f7@mail.yourbox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7258.1575239751.1@mail.karels.net> Date: Sun, 01 Dec 2019 16:35:51 -0600 X-Rspamd-Queue-Id: 47R34L6W0Dz4LvY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [-4.16 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[mike@karels.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[karels.net]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.96)[ip: (-6.53), ipnet: 216.160.0.0/15(-3.21), asn: 209(0.01), country: US(-0.05)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.0.0/15, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 22:36:04 -0000 (Sorry, I'm using a UTF-8-challenged mailer at the moment...) Jose wrote: > Hi, > images built with crochet are not working (no boot, > no nothing) on RPI but images downloaded from > https://download.freebsd.org/ftp/snapshots/arm/armv6/ISO-IMAGES do > How do they build the downloadable images? > The wiki > https://wiki.freebsd.org/arm/Raspberry%20Pi > states that you can build your own images with crochet > but it does not state how THEY build the working images > that are on the FTP site. > I notice that the images built with crochet are VERY different > from the ones you download, for example: > md0 has the crochet image, md1 the downloaded one > crochet # gpart show md0 > => 1 5859374 md0 MBR (2.8G) > 1 62 - free - (31K) > 63 34776 1 fat32lba [active] (17M) > 34839 1001 - free - (501K) > 35840 5823488 2 freebsd (2.8G) > 5859328 47 - free - (24K) > crochet # gpart show md1 > => 63 6291393 md1 MBR (3.0G) > 63 1008 - free - (504K) > 1071 102312 1 fat32lba [active] (50M) > 103383 6188049 2 freebsd (3.0G) > 6291432 24 - free - (12K) > rochet # ll /mnt/md0/boot/msdos/ > total 2448 > -rwxr-xr-x 1 root wheel 765 Nov 23 15:53 README* > -rwxr-xr-x 1 root wheel 199 Nov 23 15:53 boot.scr* > -rwxr-xr-x 1 root wheel 75 Nov 23 15:53 config.txt* > -rwxr-xr-x 1 root wheel 37 Nov 23 15:53 metadata* > -rwxr-xr-x 1 root wheel 19602 Nov 23 15:53 rpi.dtb* > -rwxr-xr-x 1 root wheel 21186 Nov 23 15:53 rpi.dts* > -rwxr-xr-x 1 root wheel 465860 Nov 23 15:53 u-boot.bin* > -rwxr-xr-x 1 root wheel 0 Nov 23 15:53 uEnv.txt* > -rwxr-xr-x 1 root wheel 1586895 Nov 23 15:53 ubldr* > -rwxr-xr-x 1 root wheel 386184 Nov 23 15:53 ubldr.bin* > crochet # ll /mnt/md1/boot/msdos/ > total 13460 > drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 EFI/ > -rwxr-xr-x 1 root wheel 23315 Nov 12 2018 bcm2708-rpi-0-w.dtb* > -rwxr-xr-x 1 root wheel 23071 Nov 12 2018 bcm2708-rpi-b-plus.dtb* > -rwxr-xr-x 1 root wheel 22812 Nov 12 2018 bcm2708-rpi-b.dtb* > -rwxr-xr-x 1 root wheel 22589 Nov 12 2018 bcm2708-rpi-cm.dtb* > -rwxr-xr-x 1 root wheel 52116 Nov 12 2018 bootcode.bin* > -rwxr-xr-x 1 root wheel 89 Nov 21 03:11 config.txt* > drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 dtb/ > -rwxr-xr-x 1 root wheel 6666 Nov 12 2018 fixup.dat* > -rwxr-xr-x 1 root wheel 2621 Nov 12 2018 fixup_cd.dat* > -rwxr-xr-x 1 root wheel 9895 Nov 12 2018 fixup_db.dat* > -rwxr-xr-x 1 root wheel 9895 Nov 12 2018 fixup_x.dat* > drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 overlays/ > -rwxr-xr-x 1 root wheel 2857060 Nov 12 2018 start.elf* > -rwxr-xr-x 1 root wheel 678532 Nov 12 2018 start_cd.elf* > -rwxr-xr-x 1 root wheel 5120484 Nov 12 2018 start_db.elf* > -rwxr-xr-x 1 root wheel 4057956 Nov 12 2018 start_x.elf* > -rwxr-xr-x 1 root wheel 465868 Nov 21 03:06 u-boot.bin* > -r-xr-xr-x 1 root wheel 386408 Nov 21 04:48 ubldr.bin* > crochet # cat /mnt/md0/boot/msdos/config.txt > gpu_mem=32 > device_tree=rpi.dtb > device_tree_address=0x100 > kernel=u-boot.bin > crochet # cat /mnt/md1/boot/msdos/config.txt > init_uart_clock=3000000 > enable_uart=1 > kernel=u-boot.bin > kernel7=u-boot.bin > dtoverlay=mmc > I had to patch crochet to have the image built, but that's another > story. > Can anyone point me on how to build working images > for RPI? I'm not an expert, having done this for the first time yesterday, but the short answer is like this: cd ^/release/; ./release.sh -c arm64/RPI3.conf Note that this will build a complete chroot for the build system, including ports, with sources that it checks out, and then builds the target system. The chroot is built in /scratch. I built from head on amd64. Mike From owner-freebsd-arm@freebsd.org Sun Dec 1 22:47:34 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0554D1BBC7E for ; Sun, 1 Dec 2019 22:47:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 47R3Kc4dRjz4MVL for ; Sun, 1 Dec 2019 22:47:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 2B62321109A for ; Sun, 1 Dec 2019 17:46:55 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id B6C7E15BDE0 for ; Sun, 1 Dec 2019 16:46:54 -0600 (CST) Subject: Re: How to build working images for RPI To: freebsd-arm@freebsd.org References: <201912012235.xB1MZpai007260@mail.karels.net> From: Karl Denninger Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= xsFNBF1Rd+gBEACmLAH7SAzdQq57ZN56QQEy0jDFfH5BvGOMZgCaP+Y5lJQ5u9WphCoCALMs Rg0o1Q9DRNWgUmy/cgsxioXAEzZFXXzOHPJhwplVOgfjxnoByD5KQhWG8Owm9QmATdtiZPSV 4UYVNUIbZv7btSnnAXysG2OUHajYS5PVeFQxFbhNFq/SS8VaXr1WEVTFa8NFKp2W3/KY1A+U KKDUlYwnOauK3fnY9chF2IRSoxAbBJFrJ4lPGz04HtzNos4Q9CBfTphKcdFjcPntNS9wrqs3 sm+7hLNTH9B2Kj6aekG5UhD03eyP+gevTgBy51RL6ULzI13Kc4aeyOByuBXrA8D2m2Ee67iy 4+ZSxM9Wn1gQce5624OWzCYIGBH2r75Bshp1KHKu36N2rN//kyKYnwl/z6UZB/S9cMUFKZgL gFx7QxpFX/HvSiBcPfcGS0meModpg6qma7/2jRoQAXacslpiT+uOfRGspNbnglkbw435RzX/ kMUclJQNZBBBUpPiGjVCjeBTiAfN8TyjS+pWzwxNCUZWbYO5xVaS0gbIhgVNoBOGn1rdTsdA PP65SRjaoL5KY6bzkkzrXLB2Djx8/p4vr0qIqxIQWbewJq3xKyKGiqI46ae77BF7k0B++Ndx g9K9UeWKl/iJ0eoI0ftR+xH3aIHTU1Or3j/tj4j8Z0tnVSyt1wARAQABzSNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PsLBfwQTAQgAKQUCXVF36AIbIwUJCWYBgAcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG8twBXrj1l4swkP/3uOzRxW16K6H4JIEIRMUEbt nxDhmk+gR/7H9phg7HtvR7i22QejZX1N1NHcGRNmBwLshWVjJkHKhCE/AM8Cf9XyaV2ft6qn g1xK6NuhapxVuaaMeCVPUzsPkTcR+JMl72ZR4Q+mJMVQButCITekmr7aIzIZ80fF0t86rnq+ O74ZGt0SAMsLV/GAKlIw8fGMi9Xj4OKDgqmxTnIoV4+0mpo26W957pnlOrjN3/6VqWUyAdHH DkyqsuP/9jx2f5pZCcD7X04+93GI+sGb1s6BOFRHq2oJgs6W0z0nPx5Ks9MDDgSQlxXAryje 17WphTR7DWn1BeF3Y8AhRkzc2+Mgc5s1i2fPe6YwvksDNOEyNXIvFV7chwDQYb0Q3I8XsoHu 2WUjXp0kVokobJPdVdY55nbY+brezweRJMiEpFtGOmoUekQWlI5KS1kE8+Xuqpm+MSxEpqY8 5ncPt0lekOrICGajlOotkUK86iVemlW1rMzMc5Xwp9j8oxa+bRtGD6u1rYz4i+qIdE+GSCBy 1nnHN/my0nefhQyHXr8wGVEbyiMZCten9fm1iXpBr0jY+tvtbo8XqZQG7Lr+3kSO6VUgc8kW IPf2HxIV7AnGUN+ddZGCcPPhb2mY/Yy7si54wJFj6YoG+/+rNjF9F5d8WeLoeUWczgHTvZmS o6F7UhjjuwzgzsFNBF1Rd+gBEADNVFS8nQ+kpKOpgtP+f3bCVxHAm7eHMbX6oew5yZiQwfD+ 1RWNWLVOMeTt7G2e5HsHpJOUwFUJhbDb0omB0r38xTSVSAig9kmUfb7tTMJG2bG7WfWykBOM WIZ4OhCf+ISv9dUkjNgx4ionWotFxwDiPRwWumVQ7WYZmRZlhDWMiaHgKvBrjJ7Y6GKPRbQc 5/0Qz9xGhXKlFxDQrrSMkyRThIOxXqdfD9z3rEsV3ZwOojzNsnkIImnQMKyIAR0FBQop34G9 wDQi7fxk8wGIfDszwfR4oAdDdPGq4gcAvE7Fd3xKyNpGyjSED5szoaFjldaZSXQIffquSUvy sFCTTLRIso5Dn9uQgi57gIv+5mnyKBfm2Z2P6pEQPSt073TED9rS0+JpniJL7rKRVpO5niqw sQJS6ht+JF88rXro+SiwxD/KeDpTuuJ10+ohLVi1Y+X82X7BIQEhqtFp9FVJSds4o/eNyaHd SoqfoeWMy3EV+rdJ3DneXcPS1BgxO57Rko5Hx3NUSVK83ovFb+Ofes9SLNdqNu3xAUcfpRdS DyxzpVbCq6Y2CIojiaweiYe5BOBhmR9OPGhqP8YD7GukYmQufAVuOrIVyctBlVPHgMBb+UX+ ItYXuX4weSJWLOsmM45xd/EYvBq2DWFpKlyihoktNzTGqxGsNeG7gCOEUTAnUwARAQABwsFl BBgBCAAPBQJdUXfoAhsMBQkJZgGAAAoJEG8twBXrj1l4Dm0P/iEx2gIHSOnvgpG799Vf2RM0 7gPbDWzDaw8YTV49H+VTOqq7RlT52aO0QfNAmtppX0V1/5f30fuSCF46NWnYGu35P/LvOAPb sLbeWCyJy4GOPN4cjsBMbgmooGdl24RdcvGMmY177o7oOSWBqXfhAj+YA6r+hEar1qxqLgwB Gy8wAId4qYSQhN/FxiQbyUs2tPAI6Wn/41pI7Hu6WgmRGpZrBv8HhVV9Gl7jallSsS/g+fhu WRbDKCknUS5SX3+w2AUFr4kf62gSSxXBxd075KnViV9c0sraAPI31XbM5QUc0Xssfaqs6Srr z4MjKaLhb7GD8C1JwI23PuGdFvk9WK996UvIyjdWIE99VSlg/5gEKkXzwx7oysrSG9BqkfGf I4addK55xRQPul0V3s2LtDoQTxg3VHrL6wrvGhYUcTHLmlsvNx1EOb5a3xBT+SUK/Ltq08LW YcmNbU/G217MlfvDJYHCb0uOtxqJFm8RiZGj2eEcLgvyWnlWCD2rfP4EqCxmpr3Ic725FiQR cBbdTV3clTgclhBG3TA9dxVjfZDcatz5cFBwXP8k5Yn9tNl90T2r79V4SNh1mCHtGTSEf449 qz9tm7EguLchjmoirJTuiipZKcalcHAHtz4VPUykdXsrfEJTzdEcujzqF6v/9CY+DjpAd3et Z0vw7xC5tS+b Message-ID: Date: Sun, 1 Dec 2019 16:46:54 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <201912012235.xB1MZpai007260@mail.karels.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080006050003060709080803" X-Rspamd-Queue-Id: 47R3Kc4dRjz4MVL X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-7.37 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.47)[ip: (-9.83), ipnet: 104.236.64.0/18(-4.37), asn: 14061(1.90), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 22:47:34 -0000 This is a cryptographically signed message in MIME format. --------------ms080006050003060709080803 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/1/2019 16:35, Mike Karels wrote: > (Sorry, I'm using a UTF-8-challenged mailer at the moment...) > > Jose wrote: >> Hi, >> images built with crochet are not working (no boot, >> no nothing) on RPI but images downloaded from >> https://download.freebsd.org/ftp/snapshots/arm/armv6/ISO-IMAGES do >> How do they build the downloadable images? >> The wiki >> https://wiki.freebsd.org/arm/Raspberry%20Pi >> states that you can build your own images with crochet >> but it does not state how THEY build the working images >> that are on the FTP site. >> I notice that the images built with crochet are VERY different >> from the ones you download, for example: >> md0 has the crochet image, md1 the downloaded one >> crochet # gpart show md0 >> =3D> 1 5859374 md0 MBR (2.8G) >> 1 62 - free - (31K) >> 63 34776 1 fat32lba [active] (17M) >> 34839 1001 - free - (501K) >> 35840 5823488 2 freebsd (2.8G) >> 5859328 47 - free - (24K) >> crochet # gpart show md1 >> =3D> 63 6291393 md1 MBR (3.0G) >> 63 1008 - free - (504K) >> 1071 102312 1 fat32lba [active] (50M) >> 103383 6188049 2 freebsd (3.0G) >> 6291432 24 - free - (12K) >> rochet # ll /mnt/md0/boot/msdos/ >> total 2448 >> -rwxr-xr-x 1 root wheel 765 Nov 23 15:53 README* >> -rwxr-xr-x 1 root wheel 199 Nov 23 15:53 boot.scr* >> -rwxr-xr-x 1 root wheel 75 Nov 23 15:53 config.txt* >> -rwxr-xr-x 1 root wheel 37 Nov 23 15:53 metadata* >> -rwxr-xr-x 1 root wheel 19602 Nov 23 15:53 rpi.dtb* >> -rwxr-xr-x 1 root wheel 21186 Nov 23 15:53 rpi.dts* >> -rwxr-xr-x 1 root wheel 465860 Nov 23 15:53 u-boot.bin* >> -rwxr-xr-x 1 root wheel 0 Nov 23 15:53 uEnv.txt* >> -rwxr-xr-x 1 root wheel 1586895 Nov 23 15:53 ubldr* >> -rwxr-xr-x 1 root wheel 386184 Nov 23 15:53 ubldr.bin* >> crochet # ll /mnt/md1/boot/msdos/ >> total 13460 >> drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 EFI/ >> -rwxr-xr-x 1 root wheel 23315 Nov 12 2018 bcm2708-rpi-0-w.dtb* >> -rwxr-xr-x 1 root wheel 23071 Nov 12 2018 bcm2708-rpi-b-plus.dtb= * >> -rwxr-xr-x 1 root wheel 22812 Nov 12 2018 bcm2708-rpi-b.dtb* >> -rwxr-xr-x 1 root wheel 22589 Nov 12 2018 bcm2708-rpi-cm.dtb* >> -rwxr-xr-x 1 root wheel 52116 Nov 12 2018 bootcode.bin* >> -rwxr-xr-x 1 root wheel 89 Nov 21 03:11 config.txt* >> drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 dtb/ >> -rwxr-xr-x 1 root wheel 6666 Nov 12 2018 fixup.dat* >> -rwxr-xr-x 1 root wheel 2621 Nov 12 2018 fixup_cd.dat* >> -rwxr-xr-x 1 root wheel 9895 Nov 12 2018 fixup_db.dat* >> -rwxr-xr-x 1 root wheel 9895 Nov 12 2018 fixup_x.dat* >> drwxr-xr-x 1 root wheel 4096 Nov 21 04:55 overlays/ >> -rwxr-xr-x 1 root wheel 2857060 Nov 12 2018 start.elf* >> -rwxr-xr-x 1 root wheel 678532 Nov 12 2018 start_cd.elf* >> -rwxr-xr-x 1 root wheel 5120484 Nov 12 2018 start_db.elf* >> -rwxr-xr-x 1 root wheel 4057956 Nov 12 2018 start_x.elf* >> -rwxr-xr-x 1 root wheel 465868 Nov 21 03:06 u-boot.bin* >> -r-xr-xr-x 1 root wheel 386408 Nov 21 04:48 ubldr.bin* >> crochet # cat /mnt/md0/boot/msdos/config.txt >> gpu_mem=3D32 >> device_tree=3Drpi.dtb >> device_tree_address=3D0x100 >> kernel=3Du-boot.bin >> crochet # cat /mnt/md1/boot/msdos/config.txt >> init_uart_clock=3D3000000 >> enable_uart=3D1 >> kernel=3Du-boot.bin >> kernel7=3Du-boot.bin >> dtoverlay=3Dmmc >> I had to patch crochet to have the image built, but that's another >> story. >> Can anyone point me on how to build working images >> for RPI? > I'm not an expert, having done this for the first time yesterday, but > the short answer is like this: > > cd ^/release/; ./release.sh -c arm64/RPI3.conf > > Note that this will build a complete chroot for the build system, inclu= ding > ports, with sources that it checks out, and then builds the target syst= em. > The chroot is built in /scratch. I built from head on amd64. > > Mike > _______________________________________________ Depends on what you want. Crochet builds a system that runs read-only off the SD card, leveraging the "diskless" paradigm to pretend it's an NFS-mounted, tftp/bootp loaded client.=C2=A0 Except it isn't; the writeable bits are on a ramdisk= =2E This makes the resulting system exceptionally fault-tolerant but does require that configuration changes and the like be "noticed" back (there are tools in the root directory to copy them back) If you want a "traditional" system then the above is how you build it.=C2= =A0 But be aware that on the Pi specifically the SD controller is usb-attached and slow. I use Crochet all the time to build Pi-specific images and while there have been small changes required from time to time it works fine for 12.x images at present.=C2=A0 I have not (yet) tried building one with -H= EAD. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080006050003060709080803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjAxMjI0NjU0 WjBPBgkqhkiG9w0BCQQxQgRAfmaEuXELeqOg8vwty6Kq2uqHnWk0Zw80dlHaizpp3AA4SA7X /nrTR6IjG/dnrFgHHvDWJ5B5nMSHB8f41/NiXTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCh57Six/TmPRmkwvDzHwgiR2UiiVqeCgthgneeoPW8oEfeVNnO9V4n+ITzkStvu/H4 yXHUegVOpZn/d6/16TrMhIaSuCJT1TQnQyiRa8R7ABij4/Ng0xKMUWeP7livQE7mHvtMQYv7 5vGoyC8VG27KxaGVjlADP+RY3L2pNQZekLKYUQ+ScY6bJCS4XQa73Cj/LIst8qDCUuYUCPYX Sws7Xxs/+np02Z7ceO5K8JB5BprM5elk8e7C7WXYQ0Fl1sSQrlm/99vaSiZ61yUXqic3vQfT pqTYBas8OPusyTX8byR/4LRC8LlDYjncitbjb7RJn5wDFdAjHNxVhViAIBSZfI8TTod7/5+u 4p4HYdNkx76AILj9Th6mh+WUgkLo2Dy83e32Xp1ecOd5gjD3IgHV+TfizupZxAPQ9KMDTex0 qd/MNiwWI5RKSdAovarGBwnhNBPSAw8cqfbu0iZyNfURV7TvQoK8gf6EI5VG633PCL/hYqMx eHWCUI+qf066NI/tayfoOn+Gu6mNMHHR9jmYS0JFmFwx3tNdCzXxziVLlInFR638H1/GP6qj WpswQ4mPVbeHZuVuN7DlECGPmaVw/+WmgANLT0SuIkNWL/KtYhAHT+piMsAVkxW3PAC2Wg+d +OPcndHGVrNri1R8SnnWcDKYttOS/1lvNIEYfxYgVQAAAAAAAA== --------------ms080006050003060709080803-- From owner-freebsd-arm@freebsd.org Sun Dec 1 23:42:22 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE14A1BD194 for ; Sun, 1 Dec 2019 23:42:22 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R4Xs4TWGz4PRT for ; Sun, 1 Dec 2019 23:42:21 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 01 Dec 2019 23:42:19 +0000 Received: from wms1-eu-central.migadu.com (wms1-eu-central.migadu.com [172.104.244.218]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id E1F9FFB4-3299-4CEE-88A9-BAD0A2EED5FB.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 01 Dec 2019 23:42:19 +0000 MIME-Version: 1.0 Date: Sun, 01 Dec 2019 23:42:19 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: <9ba15e4eaf553514587a55f054163d15@unrelenting.technology> Subject: Re: 64 bit ARM systems with more than four cores To: "John F Carr" , freebsd-arm@freebsd.org In-Reply-To: <40CC0F4E-1ACD-41DE-8A0B-302FD5218C46@exchange.mit.edu> References: <40CC0F4E-1ACD-41DE-8A0B-302FD5218C46@exchange.mit.edu> <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; bh=4LJH95iJkiwO8msOIraA3fhiMtTHH7NcEHT15eiF6ic=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=NJ5/0EkVtETTMmpEmUOeEZtP41z7oQBaJ7I6N+QOXQ5s27/SphPLSRULKvNIjDWn0eYFPc1rj+Z/fY7B4r+Shy0/PfJHzQDYBQ80/aJPRrupQ4sdG0PoTViQoaqIuGjpcLNaHgUrfUzB7T5sjhdvH8/tP6bridDDcFeFqdhl+6s= X-Rspamd-Queue-Id: 47R4Xs4TWGz4PRT X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=NJ5/0EkV; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [0.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(0.00)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.30)[ip: (-9.84), ipnet: 91.121.0.0/16(-3.45), asn: 16276(1.80), country: FR(-0.00)]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[text/plain]; URIBL_RED(3.50)[amperecomputing.com.multi.uribl.com]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(0.00)[unrelenting.technology,none]; HAS_ANON_DOMAIN(0.10)[]; URIBL_XBL(1.50)[amperecomputing.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 23:42:22 -0000 December 2, 2019 2:37 AM, "John F Carr" wrote:=0A=0A> Can a= person just buy a HR350A or HR330A? The Lenovo web site won't even admit= their existence=0A> unless you have a commercial account so I have no id= ea what they cost.=0A=0AYou can order.. something from Ampere, there's a = big order button on=0Ahttps://developer.amperecomputing.com=0A=0ANo idea = if it's the Lenovo or their internal Osprey board or how much it costs.= =0A=0AThe only public prices I saw are from Avantek. From owner-freebsd-arm@freebsd.org Mon Dec 2 00:10:29 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E662E1BE03B for ; Mon, 2 Dec 2019 00:10:29 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (flets-sg1026.kamome.or.jp [202.216.24.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R59J5Q0zz4QXQ for ; Mon, 2 Dec 2019 00:10:28 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [202.216.24.26]) by kx.truefc.org (8.15.2/8.15.2) with ESMTP id xB20AIf9082064; Mon, 2 Dec 2019 09:10:18 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <201912020010.xB20AIf9082064@kx.truefc.org> Date: Mon, 02 Dec 2019 09:10:18 +0900 From: KIRIYAMA Kazuhiko To: "freebsd-arm@freebsd.org" Subject: Can't boot arm64 image by qemu-system-aarch64 User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 47R59J5Q0zz4QXQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of kiri@truefc.org has no SPF policy when checking 202.216.24.26) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-0.48 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.886,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.70)[-0.699,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[truefc.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4704, ipnet:202.216.0.0/19, country:JP]; IP_SCORE(0.00)[country: JP(0.02)]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 00:10:30 -0000 Hi, all # I've posted freebsd-virtualization,but any responces. # Sorry for same posting. I've installed successfully by qemu-system-aarch64 below: root@vm:/vm/test # truncate -s 16g test.img root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu cortex-a57 -name test -bios QEMU_EFI.fd -nographic -hda test.img -hdc FreeBSD-13.0-CURRENT-arm64-aarch64-20191127-r355121-memstick.img and rebooted successfully and login with root: root@test:~ # uname -a FreeBSD test.tfc 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355121: Wed Nov 27 03:49:21 UTC 2019 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 root@test:~ # df -h Filesystem Size Used Avail Capacity Mounted on /dev/vtbd0p2 14G 1.3G 12G 10% / devfs 1.0K 1.0K 0B 100% /dev root@test:~ # ifconfig vtnet0: flags=8843 metric 0 mtu 1500 options=80028 ether 52:54:00:12:34:56 inet 192.168.1.196 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet 10Gbase-T status: active nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 root@test:~ # So, I shutdowned and run by qemu-system-aarch64: root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu cortex-a57 -name test -bios QEMU_EFI.fd -nographic -drive if=none,format=raw,file=test.img,id=hd0 -device virtio-blk-device,drive=hd0 -device virtio-net-device,netdev=net0 -netdev tap,id=net0,ifname=tap2 But failed to boot: BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Found >>Start PXE over IPv4. where, tap2 is ready to use: root@vm:/vm/test # ifconfig tap2 tap2: flags=8902 metric 0 mtu 1500 description: vmnet-test-0-local options=80000 ether 58:9c:fc:10:ec:02 groups: tap qemu-port media: Ethernet autoselect status: no carrier nd6 options=21 root@vm:/vm/test # What's wrong ? Best regards. --- Kiriyama Kazuhiko From owner-freebsd-arm@freebsd.org Mon Dec 2 02:17:35 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B52481C14EE for ; Mon, 2 Dec 2019 02:17:35 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47R7zy2ff8z4W6g for ; Mon, 2 Dec 2019 02:17:33 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB22HMKg049253 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 2 Dec 2019 13:17:28 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB22HHKY047695 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Dec 2019 13:17:17 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id xB22HHQX047694; Mon, 2 Dec 2019 13:17:17 +1100 (AEDT) (envelope-from peter) Date: Mon, 2 Dec 2019 13:17:17 +1100 From: Peter Jeremy To: John F Carr Cc: "freebsd-arm@freebsd.org" Subject: Re: 64 bit ARM systems with more than four cores Message-ID: <20191202021717.GA70723@server.rulingia.com> References: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47R7zy2ff8z4W6g X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-7.67 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; IP_SCORE(-3.27)[ip: (-9.61), ipnet: 2001:19f0:5800::/38(-4.82), asn: 20473(-1.85), country: US(-0.05)]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 02:17:35 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-Dec-01 21:37:53 +0000, John F Carr wrote: >Two RK3399 based systems, 2 A-72 + 4 A-53: RockPro64 (http://www.pine64.co= m/) >and ROCK Pi 4 (http://radxa.com). I can't use the RockPro64 due to the >1.5 MBps serial port. Apparently it works or almost works with some speci= al >handling if your serial interface can count to 1,500,000. I can't help with the >4 cores bit but the 1.5Mbps serial link shouldn't be a problem. I have a Rock64 connected to a FT232R clone (something like https://www.aliexpress.com/item/32680591167.html) and don't have any proble= ms. (I had to patch ports/comms/conserver-com to support 1.5Mbps but everything else "just worked"). --=20 Peter Jeremy --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl3kdCZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzThAhAAhd0v+/p7sJhuzjxYxf9OM45r9FMBzrh3OAQzWljuHLAytjTT+brRYq5t jDAYrxxf4mQPt8e5sEttTlrVzMI1eGx+OlIbV6RP1SXT8iOnWPevQVoIgl084Pnf x/mRRqfILfbd/FlxXgTQycK9GuK/TpXoMccsTpJAr504G8qCzjjHyJ1Ox6wfIylY ROjoBFFO/srQyTQZrkWk2muzepqmrLlX+Cs2VaI462Nc2/5VIfJDtBQW3ebJmtbC 5wN/uF9r1qieEMWwR5fBbFx+mQWXZglCQ2fijoRHm1w3Qa3Ezd2BkaFZq/PBIcme IJJCWNWHscFrru+fyWawuMsRRIoNQxH1G4CP/rMgPTP3E9nUcTq3GZcQfwEtTIw9 /rkRXUx3uJ+8YVAzFJ/HgswBF0qKrbYgs0r9R+2ggtYMQVBg+DrQJOjGObkxTioG ZXCbkFZrkJ3d68+Q7aJcjkHFQpvqFPEL5UNjOY78vX3fYBSU2zBnjL8eCOidGEGj y2u3UoyAaIDTtpLi3xWkbMyI6XnE8ryF1KxzHJFwhBUFgGWZGkGP4nUzUSGHT+6N zoT6bseOprVN3i7TpKNCq9QW8oxZmgGYfJp0ZibrpspLjiKifZMLWCk0m43lu8dn BKNjpvPu02IZgeHtq0rX26DTeLuTzWeecZqUWnvKvOpnhxDOAeQ= =VVuT -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-arm@freebsd.org Mon Dec 2 06:01:14 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 195451C64EA for ; Mon, 2 Dec 2019 06:01:14 +0000 (UTC) (envelope-from james@opentech.cc) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800041.outbound.protection.outlook.com [40.107.80.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RDy03KmBz4gKv for ; Mon, 2 Dec 2019 06:01:11 +0000 (UTC) (envelope-from james@opentech.cc) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SUKcCD4jo0rA7HaAhjUucabXoKPYj3vm04sO9RlndHCMmdmxvBZ2lGvt1prGifXSiZWiwILuJuN0VsiNK1S8A7Z5UjTCoh+2D1ljsPIVLsaQGy6MgM6zLCAH6JoThEn0tQt6tYYBn5iTk+o8R+y4NXrfbZqHFICR9L3cwWUnWKKFKVTh2peH+99MhDUcLkD/aI3nlgUj/OomEDANpqyy93s9eHRJ4/3fb/tOExoPJpSCBx4nQJbNI0j+XmIDhcPekAW/rkwXmWyJDdRxMOJS+5GwdJlwmmGrawO+AAXH2td36I8Fk9U+TaKiP/TQlcJ5vvlASIJfmj0lFeX4vm92ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cBbQnVqSc1ejQlXEvSaKIqCgHwMhM6jLKCBFwdsbiVw=; b=nMK+dp7rMlZHGiDa9+vPB6kmIJKs1pLTARGMDOrBaVFXY26cZNA0gJC4TTaCgpd7CDa3YAKSYXRHgii+HWAqt2RVqbTZefWwk6WKFyLAsQZVGaDgQpQYFX46HRiNwFCc/I0lyGsp6QtfWb82nRyO7o8ybQPt6aE2iPNHUkhM7KfjgHtJaO/VEu9NPns3byDdqk2Hizt9go8gfqBmIPtrLkkmD382UJs7KnPvmh+5IwIECZwM66Qk3IeQN+JCX7I+7QkQou3ZcPiQdjqZUroT51AzAToeRGkXc/wh7bImTGCqLuLuE8kPpS7sdKN0fj2FGe4lmBbI22Uh3C0s0wV9Zw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=opentech.cc; dmarc=pass action=none header.from=opentech.cc; dkim=pass header.d=opentech.cc; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opentech.cc; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cBbQnVqSc1ejQlXEvSaKIqCgHwMhM6jLKCBFwdsbiVw=; b=JcPlKFy4T2pQ5odov5iVNr0Sx0XVP/V8lU4sUbnwPPV/cdOR1mzeJOKKfkdx6TlIArSXNRvQF39HB46C9Gw9DPKvz1vCnTw4fcLs85pvPm/4okUWCJig7zT10jsZ7FJdTmjOQyszf72oyOFP4ffh6ogyQEw9EBwjLiE4n3cDwb8= Received: from MWHPR06MB3134.namprd06.prod.outlook.com (10.174.248.13) by MWHPR06MB2752.namprd06.prod.outlook.com (10.168.202.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.17; Mon, 2 Dec 2019 06:01:08 +0000 Received: from MWHPR06MB3134.namprd06.prod.outlook.com ([fe80::c4ee:9ac3:cf08:5ec2]) by MWHPR06MB3134.namprd06.prod.outlook.com ([fe80::c4ee:9ac3:cf08:5ec2%5]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 06:01:07 +0000 From: James Shuriff To: "freebsd-arm@freebsd.org" Subject: RE: How to build working images for RPI Thread-Topic: How to build working images for RPI Thread-Index: AQHVqJe+ZxcjW8VjWEqAG9JAC4tt46el4UUAgABNfHA= Date: Mon, 2 Dec 2019 06:01:07 +0000 Message-ID: References: <201912012235.xB1MZpai007260@mail.karels.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [71.251.5.193] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 86d1d31d-41b4-4721-1ab9-08d776ed0632 x-ms-traffictypediagnostic: MWHPR06MB2752: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:341; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(39830400003)(366004)(396003)(13464003)(189003)(199004)(38564003)(6506007)(53546011)(71200400001)(86362001)(76176011)(102836004)(30864003)(9686003)(14454004)(52536014)(6306002)(305945005)(66556008)(25786009)(6246003)(76116006)(64756008)(2906002)(508600001)(5660300002)(6916009)(4326008)(5640700003)(66446008)(7736002)(66066001)(74316002)(66616009)(6436002)(66946007)(66476007)(229853002)(81166006)(186003)(99286004)(55016002)(81156014)(8676002)(8936002)(26005)(7696005)(71190400001)(2351001)(966005)(2501003)(33656002)(446003)(5024004)(14444005)(256004)(316002)(3846002)(6116002)(11346002)(139555002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR06MB2752; H:MWHPR06MB3134.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: opentech.cc does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iDJtwKr0u8ZC6hsAYJozmtjxCMQUJZcNwq6P3liSKwcIk0dYnS5wckwdjQY5IaxrKyqg6GJ+FWzcJdw3x6nEvclUWIH8d+DtCr0bcNpGjzKXqJsY/jD/EHkEYegp2bj8Lxv1xrgmSMdEi8XphtHbxPA+edy1jjcgWof8TSpL8CKVIJrPf9npSjxQXt3XDqH5voUg/Ba5PtRPAwi+1l1o0eo1/gyv2CeMNrIn/PLLLuCjxbfsGDTdkj3cKpag7lV7TzicDRXu/0ogO/dLr9Ux70nTUybvNRAAQ8S/MZCjvBNkSap9EWO8KfKKs0whm83YC+r3w4rNAMmdKLr6vKdq/Ea+PGvmS+rUOTvTxkZ6P4tgZgmVvLZt7vRpZH9pA6ys9wfbiBcR92wUh+Y8ZD5uvY99N7XKs2pEgVXS41FQ1WhXqPw4Cnqky9Ujz6ITSj+534oKORZy0U9toUberbsdcMn6UQdd8BpUtDqDC1h4v6I= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_002_MWHPR06MB31346CB5D826EE885034AD1CAA430MWHPR06MB3134namp_" MIME-Version: 1.0 X-OriginatorOrg: opentech.cc X-MS-Exchange-CrossTenant-Network-Message-Id: 86d1d31d-41b4-4721-1ab9-08d776ed0632 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 06:01:07.6140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5c5dd5ac-929c-48f6-a3f4-c0c8602c24af X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CmaceALZgFpLtUJ0S3X+A+Tpmvsxj/zX3hMrhcCptEwmiN8KbzyibM+6sfY/WJ0yoixXSJvFAhKmbzXk7qyleA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2752 X-Rspamd-Queue-Id: 47RDy03KmBz4gKv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=opentech.cc header.s=selector1 header.b=JcPlKFy4; dmarc=pass (policy=none) header.from=opentech.cc; spf=pass (mx1.freebsd.org: domain of james@opentech.cc designates 40.107.80.41 as permitted sender) smtp.mailfrom=james@opentech.cc X-Spamd-Result: default: False [-4.25 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[opentech.cc,none]; R_DKIM_ALLOW(-0.20)[opentech.cc:s=selector1]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[opentech.cc:+]; CTYPE_MIXED_BOGUS(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[41.80.107.40.list.dnswl.org : 127.0.3.0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_BASE64_TEXT(0.10)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[41.80.107.40.rep.mailspike.net : 127.0.0.17]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1]; IP_SCORE(-1.35)[ipnet: 40.64.0.0/10(-3.85), asn: 8075(-2.86), country: US(-0.05)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 06:01:14 -0000 --_002_MWHPR06MB31346CB5D826EE885034AD1CAA430MWHPR06MB3134namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBtb2RlbCBpcyB5b3VyIFJhc3BiZXJyeSBQaT8gV2h5IGFyZSB5b3UgbG9va2luZyBhdCBh cm12Nj8gWW91ciBjb21tYW5kIGxpbmUgaXMgZm9yIFJhc3BiZXJyeSBQaSAzIHNvIEkgd2lsbCBh c3N1bWUgdGhhdCdzIHdoYXQgeW91IGhhdmUuIEkgbWFrZSBpbWFnZXMgYnkgaGFuZCBmb3IgUmFz cGJlcnJ5IFBpIDMgQi4gRnJlZUJTRCBoYXMgYSBudW1iZXIgb2YgUG9ydHMgZm9yIFJhc3BiZXJy eSBQaSBzdWNoIGFzIHN5c3V0aWxzL3JwaS1maXJtd2FyZSBhbmQgc3lzdXRpbHMvdS1ib290LXJw aTMuIEkgbXlzZWxmIGJ1aWxkIGZyb20gc291cmNlIGJ1dCBpdCdzIGVhc2llciB0byBncmFiIHRo ZXNlIGZyb20gUG9ydHMuIEkgd291bGQgcmVjb21tZW5kIG5vdCB1c2luZyBjcm9jaGV0LiBJdCdz IHN0cmFpZ2h0Zm9yd2FyZCBlbm91Z2ggdG8gbWFrZSBhIHdvcmtpbmcgUmFzcGJlcnJ5IFBpIDMg U0QgY2FyZC4NCg0KWW91IG5lZWQgdG8gY29weSB0aGUgVmlkZW9Db3JlIGJpbmFyaWVzIChmaXh1 cC5kYXQsIGZpeHVwX2NkLmRhdCwgZml4dXBfZGIuZGF0LCBmaXh1cF94LmRhdCwgc3RhcnQuZWxm LCBzdGFydF9jZC5lbGYsIHN0YXJ0X2RiLmVsZiwgc3RhcnRfeC5lbGYsIGJvb3Rjb2RlLmJpbiks IGFuZCB0aGUgRFRCIChmb3IgUlBJIDMgQiB0aGF0J3MgYmNtMjcxMC1ycGktMy1iLmR0YikgZnJv bSB0aGUgUmFzcGJlcnJ5IFBpIGZpcm13YXJlIGFuZCBpZiB5b3UgdXNlIHRoZSBzeXN1dGlscy9y cGktZmlybXdhcmUgcG9ydCB0aGF0J2xsIGFsbCBiZSBpbnN0YWxsZWQgaW4gL3Vzci9sb2NhbC9z aGFyZS9ycGktZmlybXdhcmUuIFRoZSBQU0NJIE1vbml0b3IgKGFybXN0dWI4LmJpbikgbmVlZHMg dG8gZ28gb24gdGhlIGNhcmQgYXMgd2VsbCBhbmQgdGhhdCBjYW4gYmUgZm91bmQgb24gR2l0SHVi IGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9nb256b3VhL3JwaTMtcHNjaS1tb25pdG9yIGJ1dCBpdCdz IHByb3ZpZGVkIGJ5IHRoZSBycGktZmlybXdhcmUgcG9ydCBhcyB3ZWxsIGFuZCB3aWxsIGFsc28g YmUgaW4gL3Vzci9sb2NhbC9zaGFyZS9ycGktZmlybXdhcmUuIFRoZXJlIGFyZSBjb25maWcudHh0 IGZpbGVzIGluIHRoZSBwb3J0LiBJIHVzZSBjb25maWdfcnBpMy50eHQgKHdoaWNoIG11c3QgYmUg cmVuYW1lZCB0byBjb25maWcudHh0IG9uIHRoZSBTRCBjYXJkKSBhbmQgaWYgeW91IGxvb2sgaW4g dGhlIGZpbGUgeW91J2xsIHNlZSBpdCByZWZlcmVuY2VzIHNldmVyYWwgb3ZlcmxheXM6IG1tYywg cHdtLCBhbmQgcGkzLWRpc2FibGUtYnQuIFRob3NlIG92ZXJsYXlzIGNhbiBiZSBmb3VuZCBpbiAv dXNyL2xvY2FsL3NoYXJlL3JwaS1maXJtd2FyZS9vdmVybGF5cyBhbmQgdGhleSBuZWVkIHRvIGJl IGNvcGllZCB0byB0aGUgU0QgQ2FyZCdzIC9vdmVybGF5cyBkaXJlY3RvcnkuDQoNClUtQm9vdCBj YW4gYmUgYnVpbHQgZnJvbSBzeXN1dGlscy91LWJvb3QtcnBpMy4gSSBwcmVmZXIgdG8gYnVpbGQg aXQgYnkgaGFuZCBidXQgdGhlcmUncyBub3QgbXVjaCBiZW5lZml0IGZyb20gZG9pbmcgdGhpcyB1 bmxlc3MgeW91IG5lZWQgdG8gY2hhbmdlIGJvYXJkIGNvbmZpZ3MuIFRoZSBvdXRwdXQgd2lsbCBi ZSBvZmYgb2YgL3Vzci9sb2NhbC9zaGFyZS91LWJvb3QgYW5kIHdoYXQgeW91IG5lZWQgaXMgdS1i b290LmJpbi4gQ29weSBpdCB0byB0aGUgU0QgY2FyZCByb290LiBUaGlzIGlzIGJlY2F1c2UgVS1C b290IGZvciBSYXNwYmVycnkgUGkgKGFuZCBmb3IgbW9zdCBBYXJjaDY0IHN5c3RlbXMpIGltcGxl bWVudCBVRUZJLiBSYXNwYmVycnkgUGkgaXRzZWxmIGRvZXMgbm90IGltcGxlbWVudCBVRUZJLiBS YXNwYmVycnkgUGkncyBzdGFydC5lbGYgd2lsbCBsb29rIGZvciBrZXJuZWw4LmltZyBpZiBub25l IGlzIHByb3ZpZGVkIGJ1dCBzaW5jZSB3ZSBuZWVkIHRvIHVzZSBVLUJvb3Qgd2UgdGVsbCB0aGUg ZmlybXdhcmUgdmlhIGNvbmZpZy50eHQgdGhhdCB3ZSBuZWVkIHRvIGxvYWQgdS1ib290LmJpbi4g VS1Cb290IHdpbGwgdGhlbiBzdGFydCBsb29raW5nIGZvciBhIFVFRkkgYXBwbGljYXRpb24sIHdo aWNoIGlzIHdoZXJlIHdlIGhhbmQgb2ZmIHRvIEZyZWVCU0QncyBib290bG9hZGVyLg0KDQpZb3Un bGwgbmVlZCBmaWxlcyBmcm9tIHRoZSBGcmVlQlNEIGJ1aWxkIG91dHB1dC4gVS1Cb290IGZvciBS YXNwYmVycnkgUGkgMyBpbXBsZW1lbnRzIFVFRkkgdG8gYm9vdCB0aGUgT1Mgc28geW91IG5lZWQg dG8gY29weSBGcmVlQlNEJ3MgVUVGSSBib290bG9hZGVyLiBUaGF0IGNhbiBiZSBmb3VuZCBpbiAk TUFLRU9CSkRJUlBSRUZJWC8kU1JDRElSL2FybTY0LmFhcmNoNjQvc3RhbmQvZWZpL2xvYWRlcl9s dWEvbG9hZGVyX2x1YS5lZmkgKGFzc3VtaW5nIHlvdSB3YW50IHRvIHVzZSB0aGUgTHVhIGxvYWRl cikgYW5kIGl0IG5lZWRzIHRvIGJlIGNvcGllZCB0byB0aGUgU0QgQ2FyZCdzIC9FRkkvQk9PVC9i b290YWE2NC5lZmkuIE1BS0VPQkpESVJQUkVGSVggd2lsbCBiZSAvdXNyL29iaiBpZiB5b3UgZG9u 4oCZdCBzcGVjaWZ5IGEgcHJlZml4IGR1cmluZyBidWlsZCBhbmQgU1JDRElSIGlzIHdoZXJldmVy IHlvdSBrZWVwIHRoZSBGcmVlQlNEIHNvdXJjZXMuIEkgYnVpbGQgbXkgUmFzcGJlcnJ5IFBpIGZy b20gaGVhZCBzbyBJIGRvbid0IHB1dCB0aGUgc291cmNlcyBpbiAvdXNyL3NyYywgYXMgdGhlcmUg YXJlIHBvcnRzIGxpa2Ugc3lzdXRpbHMvbHNvZiB0aGF0IG5lZWQgdGhlIHNvdXJjZXMgdGhhdCBt YXRjaCB0aGUgaG9zdCBzeXN0ZW0gYW5kIGV4cGVjdHMgdGhlbSB0byBiZSBpbiAvdXNyL3NyYyBz byBJIHB1dCBteSBzb3VyY2VzIGluIC91c3Ivc3JjLmhlYWQgYW5kIHRoYXQncyBteSBTUkNESVIu DQoNClRoZXJlIGFyZSB2YXJpb3VzIG90aGVyIGRldmljZSB0cmVlIGJsb2JzIHRoYXQgbmVlZCB0 byBiZSBjb3BpZWQgb3ZlciBhcyB3ZWxsLiBJZiB5b3UgbG9vayBhdCB0aGUgUlBJMyBJU08geW91 IGNhbiBzZWUgdGhlIG5hbWVzIG9mIGFsbCBvZiB0aGVtLiAgSW4gZ2VuZXJhbCB0aGVyZSdzIHRo ZSBhbGx3aW5uZXIgYmxvYnMgKHN1bjUwaS1hNjQtbmFub3BpLWE2NC5kdGIgc3VuNTBpLWE2NC1v bGludXhpbm8uZHRiIHN1bjUwaS1hNjQtcGluZTY0LXBsdXMuZHRiIHN1bjUwaS1hNjQtcGluZTY0 LmR0YiBzdW41MGktYTY0LXNvcGluZS1iYXNlYm9hcmQuZHRiIHN1bjUwaS1oNS1vcmFuZ2VwaS1w YzIuZHRiKSB0aGUgb3ZlcmxheXMgKHN1bjUwaS1hNjQtc2lkLmR0Ym8gc3VuNTBpLWE2NC10aHMu ZHRibyBzdW41MGktYTY0LXRpbWVyLmR0Ym8pIGFuZCB0aGUgcm9ja2NoaXAgYmxvYnMgKHJrMzMy OC1yb2NrNjQuZHRiIHJrMzM5OS1yb2NrcHJvNjQuZHRiKS4gVGhlc2UgYXJlIGFsbCBjb3BpZWQg dG8gL2R0Yi9hbGx3aW5uZXIsIC9kdGIvb3ZlcmxheXMsIGFuZCAvZHRiL3JvY2tjaGlwIHJlc3Bl Y3RpdmVseS4gVGhlIGFsbHdpbm5lcnMgYW5kIG92ZXJsYXlzIGNhbiBiZSBmb3VuZCBhdCAkTUFL RU9CSkRJUlBSRUZJWC8kU1JDRElSL2FybTY0LmFhcmNoNjQvc3lzLyRLRVJOQ09ORi9tb2R1bGVz LyRTUkNESVIvc3lzL21vZHVsZXMvZHRiL2FsbHdpbm5lci8gYW5kIHRoZSByb2NrY2hpcHMgY2Fu IGJlIGZvdW5kIGF0ICRNQUtFT0JKRElSUFJFRklYLyRTUkNESVIvYXJtNjQuYWFyY2g2NC9zeXMv JEtFUk5DT05GL21vZHVsZXMvJFNSQ0RJUi9zeXMvbW9kdWxlcy9kdGIvcm9ja2NoaXAvLiBUaGUg aW1hZ2VzIEZyZWVCU0QgZGlzdHJpYnV0ZXMgaGF2ZSBjaGFuZ2VkIHRoZSBEVEJzIGFuZCBvdmVy bGF5cyB0aGV5IGluY2x1ZGUgaW4gdGhlIFJQSTMgaW1hZ2Ugb3ZlciB0aGUgeWVhcnMgYnV0IHRo ZXNlIGFyZSB0aGUgb25lcyBJIHVzZS4gWW91IGNhbiBjaGVjayB0aGUgUlBJMyBpbWFnZSB0byBz ZWUgd2hhdCB0aGUgbGF0ZXN0IG9uZXMgYXJlIGFuZCBjb3B5IHRoZW0gb3ZlciBmcm9tIHlvdXIg YnVpbGQuDQoNCkkgaGF2ZSBhdHRhY2hlZCB0aGUgc2NyaXB0IEkgdXNlIGZvciBzZXR0aW5nIHVw IHRoZSBGQVQgcGFydGl0aW9uLiBZb3Ugd2lsbCBoYXZlIHRvIG1vZGlmeSBCT09URlMsIE1BS0VP QkpESVJQUkVGSVgsIFNSQ0NPTkYsIEtFUk5DT05GLCBhbmQgYWxsIHRoZSBoYXJkY29kZWQgcGF0 aHMgc3VjaCBhcyBGSVJNV0FSRV9SRVBPX1BBVEggYW5kIHRoZSB0d28gdmFycyBiZWxvdyBpdC4g RklSTVdBUkVfQ09ORklHX1BBVEggc2hvdWxkIHdvcmsgZm9yIHlvdSBzaW5jZSBpdCdzIHB1bGxp bmcgc3RyYWlnaHQgZnJvbSB0aGUgcG9ydCBzb3VyY2VzLg0KDQpTbyBmYXIgSSd2ZSBvbmx5IGNv dmVyZWQgdGhlIGNvbnRlbnRzIG9mIHRoZSBGQVQgcGFydGl0aW9uLiBUaGlzIGlzIGhvdyBJIGZv cm1hdCBteSBTRCBjYXJkOg0KIyBDcmVhdGUgdGhlIHBhcnRpdGlvbnMNCmdwYXJ0IGNyZWF0ZSAt cyBNQlIgJFNEDQpncGFydCBhZGQgLXQgZmF0MzJsYmEgLXMgNTBNICRTRA0KZ3BhcnQgYWRkIC10 IGZyZWVic2QgJFNEDQpncGFydCBjcmVhdGUgLXMgQlNEICR7U0R9czINCmdwYXJ0IGFkZCAtdCBm cmVlYnNkLXVmcyAke1NEfXMyDQoNCm5ld2ZzX21zZG9zIC1BIC1GIDE2IC9kZXYvJHtTRH1zMQ0K Z2xhYmVsIGxhYmVsIE1TRE9TQk9PVCAvZGV2LyR7U0R9czENCg0KbmV3ZnMgLVUgLUwgcm9vdGZz IC9kZXYvJHtTRH1zMmENCnR1bmVmcyAtTiBlbmFibGUgL2Rldi8ke1NEfXMyYQ0KDQpBcyBmb3Ig dGhlIFVGUyBmaWxlc3lzdGVtIHNldCB1cCBmc3RhYiB0byBtb3VudCBVRlMgdG8gcm9vdCBhbmQg RkFUIHRvIC9ib290L2Zpcm13YXJlLiBZb3UgY2FuIG1vdW50IHRoZSBGQVQgZnMgYW55d2hlcmUg b3IgeW91IGNvdWxkIGNob29zZSBub3QgdG8gbW91bnQgaXQgYXQgYWxsICh3aGljaCBJIHdvdWxk IG5vdCByZWNvbW1lbmQpLiBJIHVzZSB0aGUgQ0FNLWJhc2VkIE1NQyBzdGFjayBzbyB3aXRoaW4g UGkgbXkgU0QgY2FyZCBpcyBzZGRhMCBidXQgd2l0aG91dCBNTUNDQU0gaXQgd2lsbCBwcm9iYWJs eSBiZSBtbWNzZDAgc28gY3JlYXRlIC9ldGMvZnN0YWIgd2l0aDoNCi9kZXYvbW1jc2QwczJhIC8g dWZzIHJ3IDEgMQ0KL2Rldi9tbWNzZDBzMSAvYm9vdC9maXJtd2FyZSBtc2Rvc2ZzIHJ3LG5vYXRp bWUgMCAwDQoNCllvdSBjb3VsZCBvcHRpb25hbGx5IG1vdW50IHRtcGZzIGxpa2Ugc286DQp0bXBm cyAvdG1wIHRtcGZzIHJ3LG1vZGU9MTc3NyxzaXplPTUwbSAwIDANCg0KSSBkbyBub3QgZG8gdGhp cyBiZWNhdXNlIGNlcnRhaW4gYXBwcyBsaWtlIHN2bmxpdGUgdXNlIHVwIGEgbG90IG9mIHRlbXAg c3BhY2UgYW5kIGNhbiBjcmFwIG91dCB3aXRob3V0IGV2ZW4gZ2l2aW5nIGFuIGluZGljYXRpb24g b2Ygd2hhdCBoYXBwZW5lZC4gSSB1c2UgbGFyZ2UgU0QgY2FyZHMgYW5kIGNvbnNpZGVyIFJBTSB0 byBiZSBtb3JlIHByZWNpb3VzIHRoYW4gc3RvcmFnZSBzcGFjZS4gSWYgeW91J3JlIGdvaW5nIHRv IHVzZSB0bXBmcyBtYWtlIHN1cmUgeW91IHB1dCB0bXBmc19sb2FkPSJZRVMiIGluIC9ib290L2xv YWRlci5jb25mLiBTZXQgdXAgL2V0Yy9yYy5jb25mIGxpa2Ugc286DQoNCmhvc3RuYW1lPSJycGki DQppZmNvbmZpZ19ERUZBVUxUPSJESENQIg0Kc3NoZF9lbmFibGU9IllFUyINCnNlbmRtYWlsX2Vu YWJsZT0iTk9ORSINCg0KSWYgeW91IHdhbnQgc2VyaWFsIHJlcGxhY2UgdHR5dTAgaW4gL2V0Yy90 dHlzIHdpdGggdGhlIGZvbGxvd2luZzoNCg0KdHR5dTAgIi91c3IvbGliZXhlYy9nZXR0eSBzdGQu MTE1MjAwIiB4dGVybSBvbiBzZWN1cmUNCg0KLi4uIGFuZCBpbiAvYm9vdC9sb2FkZXIuY29uZjoN Cg0KYm9vdF9zZXJpYWw9IllFUyINCg0KRm9yIHRoZSBzYWtlIG9mIGluaXRpYWxseSBzZXR0aW5n IHVwIHRoZSBQaSB5b3UgbWF5IHdhbnQgdG8gZW5hYmxlIHJvb3QgZm9yIHNzaGQsIHNvIG1ha2Ug dGhpcyBjaGFuZ2UgaW4gL2V0Yy9zc2gvc3NoZF9jb25maWc6DQoNClBlcm1pdFJvb3RMb2dpbiB5 ZXMNCg0KT2YgY291cnNlIHlvdSBjYW5ub3QgZG8gdGhpcyB3aXRoIGFuIGVtcHR5IHBhc3N3b3Jk LiBUaGlzIHBhcnQgSSBjYW4gb25seSBnaXZlIHRoZW9yZXRpY2FsIGFkdmljZSBvbiwgYXMgSSBh bHdheXMgdXNlIHRoZSBhdHRhY2hlZCBjb25zb2xlIHRvIGNoYW5nZSB0aGUgcm9vdCBwYXNzd29y ZC4gSSBkbyBub3Qga25vdyBpZiB0aGlzIHdpbGwgd29yayBidXQgeW91IGNhbiBnaXZlIGl0IGEg dHJ5LiBZb3UgY2FuJ3Qgc2ltcGx5IGNocm9vdCBpbnRvIHRoZSBVRlMgbW91bnQgYmVjYXVzZSB5 b3VyIGhvc3Qgc3lzdGVtIGlzIChwcm9iYWJseSkgbm90IEFhcmNoNjQuIFNvIHRvdWNoIC9ldGMv cHdkLmRiIHdpdGggNjQ0IGFuZCAvZXRjL3Nwd2QuZGIgd2l0aCA2MDAgaW4gdGhlIFVGUyBwYXJ0 aXRpb24uIFRoZW4gcnVuIHRoaXMgY29tbWFuZDoNCg0KcHcgdXNlcm1vZCByb290IC1SICRST09U IC1oIDANCg0KV2l0aCBST09UIGJlaW5nIHRoZSByb290IG9mIHRoZSBTRCBjYXJkJ3MgVUZTIHBh cnRpdGlvbi4gVGhpcyB3aWxsIHByb21wdCB5b3UgKG9uY2UpIGZvciB0aGUgbmV3IHJvb3QgcGFz c3dvcmQuIEkndmUgb25seSBkb25lIHRoaXMgb24gc3lzdGVtcyB0aGF0IGFscmVhZHkgaGFkIHRo ZSBwYXNzd29yZCBkYXRhYmFzZXMgZ2VuZXJhdGVkIGJ1dCB0aGVvcmV0aWNhbGx5IHRoaXMgc2hv dWxkIHdvcmsgZm9yIGEgYnJhbmQgbmV3IHN5c3RlbS4NCg0KQSBmZXcgdGhpbmdzIHRvIGNvbnNp ZGVyOg0KDQpUaGUgVS1Cb290IHBvcnQgY2hlYXRzLiBVLUJvb3Qgd2FzIG5vdCB3cml0dGVuIHdp dGggYSBCU0Qgc3lzdGVtIGluIG1pbmQsIHNvIGl0IGV4cGVjdHMgY29tbWFuZHMgbGlrZSAic2Vk IiBhcmUgZ29pbmcgdG8gYmUgdGhlIEdOVSAoKnNwaXRzKikgdmVyc2lvbnMuIFRoZSBVLUJvb3Qg cG9ydCB0dXJucyBvZmYgT0ZfRU1CRUQgYW5kIHR1cm5zIG9uIE9GX0JPQVJEIGJlY2F1c2UgVS1C b290IGF0dGVtcHRzIHRvIGludm9rZSAic2VkIiB3aXRoIEdOVSBmbGFncy4gSSB3YXMgYWJsZSB0 byBnZXQgYXJvdW5kIHRoaXMgYnkgbW9kaWZ5aW5nIFUtQm9vdCdzIE1ha2VmaWxlcyB0byB1c2Ug Z3NlZC4gVGhlIFJhc3BiZXJyeSBQaSAzIGl0c2VsZiBkb2VzIG5vdCBoYXZlIGFuIEZEVCBidXJu ZWQgaW4sIGFuZCB3aXRoIHlvdXIgVS1Cb290IGhhdmluZyBPRl9CT0FSRCAoaWYgeW91IHVzZSB0 aGUgcG9ydCkgaXQgaXMgY3J1Y2lhbCB0aGF0IHlvdSBwcm92aWRlIHRoZSBjb3JyZWN0IERUQi4g VGhlIFZpZGVvQ29yZSBzdGFnZSBsb2FkcyB0aGUgRFRCIGZyb20gdGhlIEZBVCBwYXJ0aXRpb24g d2hpY2ggaGFuZHMgaXQgdG8gVS1Cb290IHdoaWNoIHRoZW4gaGFuZHMgaXQgdG8gRnJlZUJTRC4g U2luY2UgeW91IGNhbm5vdCBkZXBlbmQgb24gVS1Cb290IHRvIHByb3ZpZGUgdGhlIEZEVCB5b3Ug bXVzdCBlbnN1cmUgdGhlIERUQiBpcyB0aGUgY29ycmVjdCBvbmUgZm9yIHlvdXIgc3lzdGVtLiBK dXN0IGJlY2F1c2UgaXQgYm9vdHMgZG9lcyBub3QgbWVhbiBpdCdzIHRoZSByaWdodCBEVEIuDQoN Ci0gSmFtZXMgU2h1cmlmZg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3du ZXItZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcgPG93bmVyLWZyZWVic2QtYXJtQGZyZWVic2Qub3Jn PiBPbiBCZWhhbGYgT2YgS2FybCBEZW5uaW5nZXINClNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMSwg MjAxOSA1OjQ3IFBNDQpUbzogZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcNClN1YmplY3Q6IFJlOiBI b3cgdG8gYnVpbGQgd29ya2luZyBpbWFnZXMgZm9yIFJQSQ0KDQpPbiAxMi8xLzIwMTkgMTY6MzUs IE1pa2UgS2FyZWxzIHdyb3RlOg0KPiAoU29ycnksIEknbSB1c2luZyBhIFVURi04LWNoYWxsZW5n ZWQgbWFpbGVyIGF0IHRoZSBtb21lbnQuLi4pDQo+DQo+IEpvc2Ugd3JvdGU6DQo+PiBIaSwNCj4+ IGltYWdlcyBidWlsdCB3aXRoIGNyb2NoZXQgYXJlIG5vdCB3b3JraW5nIChubyBib290LA0KPj4g bm8gbm90aGluZykgb24gUlBJIGJ1dCBpbWFnZXMgZG93bmxvYWRlZCBmcm9tDQo+PiBodHRwczov L2Rvd25sb2FkLmZyZWVic2Qub3JnL2Z0cC9zbmFwc2hvdHMvYXJtL2FybXY2L0lTTy1JTUFHRVMg ZG8NCj4+IEhvdyBkbyB0aGV5IGJ1aWxkIHRoZSBkb3dubG9hZGFibGUgaW1hZ2VzPw0KPj4gVGhl IHdpa2kNCj4+IGh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9hcm0vUmFzcGJlcnJ5JTIwUGkNCj4+ IHN0YXRlcyB0aGF0IHlvdSBjYW4gYnVpbGQgeW91ciBvd24gaW1hZ2VzIHdpdGggY3JvY2hldA0K Pj4gYnV0IGl0IGRvZXMgbm90IHN0YXRlIGhvdyBUSEVZIGJ1aWxkIHRoZSB3b3JraW5nIGltYWdl cw0KPj4gdGhhdCBhcmUgb24gdGhlIEZUUCBzaXRlLg0KPj4gSSBub3RpY2UgdGhhdCB0aGUgaW1h Z2VzIGJ1aWx0IHdpdGggY3JvY2hldCBhcmUgVkVSWSBkaWZmZXJlbnQNCj4+IGZyb20gdGhlIG9u ZXMgeW91IGRvd25sb2FkLCBmb3IgZXhhbXBsZToNCj4+IG1kMCBoYXMgdGhlIGNyb2NoZXQgaW1h Z2UsIG1kMSB0aGUgZG93bmxvYWRlZCBvbmUNCj4+IGNyb2NoZXQgIyBncGFydCBzaG93IG1kMA0K Pj4gPT4gICAgICAxICA1ODU5Mzc0ICBtZDAgIE1CUiAgKDIuOEcpDQo+PiAgICAgICAgICAxICAg ICAgIDYyICAgICAgIC0gZnJlZSAtICAoMzFLKQ0KPj4gICAgICAgICA2MyAgICAzNDc3NiAgICAx ICBmYXQzMmxiYSAgW2FjdGl2ZV0gICgxN00pDQo+PiAgICAgIDM0ODM5ICAgICAxMDAxICAgICAg IC0gZnJlZSAtICAoNTAxSykNCj4+ICAgICAgMzU4NDAgIDU4MjM0ODggICAgMiAgZnJlZWJzZCAg KDIuOEcpDQo+PiAgICA1ODU5MzI4ICAgICAgIDQ3ICAgICAgIC0gZnJlZSAtICAoMjRLKQ0KPj4g Y3JvY2hldCAjIGdwYXJ0IHNob3cgbWQxDQo+PiA9PiAgICAgNjMgIDYyOTEzOTMgIG1kMSAgTUJS ICAoMy4wRykNCj4+ICAgICAgICAgNjMgICAgIDEwMDggICAgICAgLSBmcmVlIC0gICg1MDRLKQ0K Pj4gICAgICAgMTA3MSAgIDEwMjMxMiAgICAxICBmYXQzMmxiYSAgW2FjdGl2ZV0gICg1ME0pDQo+ PiAgICAgMTAzMzgzICA2MTg4MDQ5ICAgIDIgIGZyZWVic2QgICgzLjBHKQ0KPj4gICAgNjI5MTQz MiAgICAgICAyNCAgICAgICAtIGZyZWUgLSAgKDEySykNCj4+IHJvY2hldCAjIGxsIC9tbnQvbWQw L2Jvb3QvbXNkb3MvDQo+PiB0b3RhbCAyNDQ4DQo+PiAtcnd4ci14ci14ICAxIHJvb3QgIHdoZWVs ICAgICAgNzY1IE5vdiAyMyAxNTo1MyBSRUFETUUqDQo+PiAtcnd4ci14ci14ICAxIHJvb3QgIHdo ZWVsICAgICAgMTk5IE5vdiAyMyAxNTo1MyBib290LnNjcioNCj4+IC1yd3hyLXhyLXggIDEgcm9v dCAgd2hlZWwgICAgICAgNzUgTm92IDIzIDE1OjUzIGNvbmZpZy50eHQqDQo+PiAtcnd4ci14ci14 ICAxIHJvb3QgIHdoZWVsICAgICAgIDM3IE5vdiAyMyAxNTo1MyBtZXRhZGF0YSoNCj4+IC1yd3hy LXhyLXggIDEgcm9vdCAgd2hlZWwgICAgMTk2MDIgTm92IDIzIDE1OjUzIHJwaS5kdGIqDQo+PiAt cnd4ci14ci14ICAxIHJvb3QgIHdoZWVsICAgIDIxMTg2IE5vdiAyMyAxNTo1MyBycGkuZHRzKg0K Pj4gLXJ3eHIteHIteCAgMSByb290ICB3aGVlbCAgIDQ2NTg2MCBOb3YgMjMgMTU6NTMgdS1ib290 LmJpbioNCj4+IC1yd3hyLXhyLXggIDEgcm9vdCAgd2hlZWwgICAgICAgIDAgTm92IDIzIDE1OjUz IHVFbnYudHh0Kg0KPj4gLXJ3eHIteHIteCAgMSByb290ICB3aGVlbCAgMTU4Njg5NSBOb3YgMjMg MTU6NTMgdWJsZHIqDQo+PiAtcnd4ci14ci14ICAxIHJvb3QgIHdoZWVsICAgMzg2MTg0IE5vdiAy MyAxNTo1MyB1Ymxkci5iaW4qDQo+PiBjcm9jaGV0ICMgbGwgL21udC9tZDEvYm9vdC9tc2Rvcy8N Cj4+IHRvdGFsIDEzNDYwDQo+PiBkcnd4ci14ci14ICAxIHJvb3QgIHdoZWVsICAgICA0MDk2IE5v diAyMSAwNDo1NSBFRkkvDQo+PiAtcnd4ci14ci14ICAxIHJvb3QgIHdoZWVsICAgIDIzMzE1IE5v diAxMiAgMjAxOCBiY20yNzA4LXJwaS0wLXcuZHRiKg0KPj4gLXJ3eHIteHIteCAgMSByb290ICB3 aGVlbCAgICAyMzA3MSBOb3YgMTIgIDIwMTggYmNtMjcwOC1ycGktYi1wbHVzLmR0YioNCj4+IC1y d3hyLXhyLXggIDEgcm9vdCAgd2hlZWwgICAgMjI4MTIgTm92IDEyICAyMDE4IGJjbTI3MDgtcnBp LWIuZHRiKg0KPj4gLXJ3eHIteHIteCAgMSByb290ICB3aGVlbCAgICAyMjU4OSBOb3YgMTIgIDIw MTggYmNtMjcwOC1ycGktY20uZHRiKg0KPj4gLXJ3eHIteHIteCAgMSByb290ICB3aGVlbCAgICA1 MjExNiBOb3YgMTIgIDIwMTggYm9vdGNvZGUuYmluKg0KPj4gLXJ3eHIteHIteCAgMSByb290ICB3 aGVlbCAgICAgICA4OSBOb3YgMjEgMDM6MTEgY29uZmlnLnR4dCoNCj4+IGRyd3hyLXhyLXggIDEg cm9vdCAgd2hlZWwgICAgIDQwOTYgTm92IDIxIDA0OjU1IGR0Yi8NCj4+IC1yd3hyLXhyLXggIDEg cm9vdCAgd2hlZWwgICAgIDY2NjYgTm92IDEyICAyMDE4IGZpeHVwLmRhdCoNCj4+IC1yd3hyLXhy LXggIDEgcm9vdCAgd2hlZWwgICAgIDI2MjEgTm92IDEyICAyMDE4IGZpeHVwX2NkLmRhdCoNCj4+ IC1yd3hyLXhyLXggIDEgcm9vdCAgd2hlZWwgICAgIDk4OTUgTm92IDEyICAyMDE4IGZpeHVwX2Ri LmRhdCoNCj4+IC1yd3hyLXhyLXggIDEgcm9vdCAgd2hlZWwgICAgIDk4OTUgTm92IDEyICAyMDE4 IGZpeHVwX3guZGF0Kg0KPj4gZHJ3eHIteHIteCAgMSByb290ICB3aGVlbCAgICAgNDA5NiBOb3Yg MjEgMDQ6NTUgb3ZlcmxheXMvDQo+PiAtcnd4ci14ci14ICAxIHJvb3QgIHdoZWVsICAyODU3MDYw IE5vdiAxMiAgMjAxOCBzdGFydC5lbGYqDQo+PiAtcnd4ci14ci14ICAxIHJvb3QgIHdoZWVsICAg Njc4NTMyIE5vdiAxMiAgMjAxOCBzdGFydF9jZC5lbGYqDQo+PiAtcnd4ci14ci14ICAxIHJvb3Qg IHdoZWVsICA1MTIwNDg0IE5vdiAxMiAgMjAxOCBzdGFydF9kYi5lbGYqDQo+PiAtcnd4ci14ci14 ICAxIHJvb3QgIHdoZWVsICA0MDU3OTU2IE5vdiAxMiAgMjAxOCBzdGFydF94LmVsZioNCj4+IC1y d3hyLXhyLXggIDEgcm9vdCAgd2hlZWwgICA0NjU4NjggTm92IDIxIDAzOjA2IHUtYm9vdC5iaW4q DQo+PiAtci14ci14ci14ICAxIHJvb3QgIHdoZWVsICAgMzg2NDA4IE5vdiAyMSAwNDo0OCB1Ymxk ci5iaW4qDQo+PiBjcm9jaGV0ICMgY2F0IC9tbnQvbWQwL2Jvb3QvbXNkb3MvY29uZmlnLnR4dA0K Pj4gZ3B1X21lbT0zMg0KPj4gZGV2aWNlX3RyZWU9cnBpLmR0Yg0KPj4gZGV2aWNlX3RyZWVfYWRk cmVzcz0weDEwMA0KPj4ga2VybmVsPXUtYm9vdC5iaW4NCj4+IGNyb2NoZXQgIyBjYXQgL21udC9t ZDEvYm9vdC9tc2Rvcy9jb25maWcudHh0DQo+PiBpbml0X3VhcnRfY2xvY2s9MzAwMDAwMA0KPj4g ZW5hYmxlX3VhcnQ9MQ0KPj4ga2VybmVsPXUtYm9vdC5iaW4NCj4+IGtlcm5lbDc9dS1ib290LmJp bg0KPj4gZHRvdmVybGF5PW1tYw0KPj4gSSBoYWQgdG8gcGF0Y2ggY3JvY2hldCB0byBoYXZlIHRo ZSBpbWFnZSBidWlsdCwgYnV0IHRoYXQncyBhbm90aGVyDQo+PiBzdG9yeS4NCj4+IENhbiBhbnlv bmUgcG9pbnQgbWUgb24gaG93IHRvIGJ1aWxkIHdvcmtpbmcgaW1hZ2VzDQo+PiBmb3IgUlBJPw0K PiBJJ20gbm90IGFuIGV4cGVydCwgaGF2aW5nIGRvbmUgdGhpcyBmb3IgdGhlIGZpcnN0IHRpbWUg eWVzdGVyZGF5LCBidXQNCj4gdGhlIHNob3J0IGFuc3dlciBpcyBsaWtlIHRoaXM6DQo+DQo+IGNk IF4vcmVsZWFzZS87IC4vcmVsZWFzZS5zaCAtYyBhcm02NC9SUEkzLmNvbmYNCj4NCj4gTm90ZSB0 aGF0IHRoaXMgd2lsbCBidWlsZCBhIGNvbXBsZXRlIGNocm9vdCBmb3IgdGhlIGJ1aWxkIHN5c3Rl bSwgaW5jbHVkaW5nDQo+IHBvcnRzLCB3aXRoIHNvdXJjZXMgdGhhdCBpdCBjaGVja3Mgb3V0LCBh bmQgdGhlbiBidWlsZHMgdGhlIHRhcmdldCBzeXN0ZW0uDQo+IFRoZSBjaHJvb3QgaXMgYnVpbHQg aW4gL3NjcmF0Y2guICBJIGJ1aWx0IGZyb20gaGVhZCBvbiBhbWQ2NC4NCj4NCj4gTWlrZQ0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEZXBlbmRz IG9uIHdoYXQgeW91IHdhbnQuDQoNCkNyb2NoZXQgYnVpbGRzIGEgc3lzdGVtIHRoYXQgcnVucyBy ZWFkLW9ubHkgb2ZmIHRoZSBTRCBjYXJkLCBsZXZlcmFnaW5nDQp0aGUgImRpc2tsZXNzIiBwYXJh ZGlnbSB0byBwcmV0ZW5kIGl0J3MgYW4gTkZTLW1vdW50ZWQsIHRmdHAvYm9vdHANCmxvYWRlZCBj bGllbnQuICBFeGNlcHQgaXQgaXNuJ3Q7IHRoZSB3cml0ZWFibGUgYml0cyBhcmUgb24gYSByYW1k aXNrLg0KDQpUaGlzIG1ha2VzIHRoZSByZXN1bHRpbmcgc3lzdGVtIGV4Y2VwdGlvbmFsbHkgZmF1 bHQtdG9sZXJhbnQgYnV0IGRvZXMNCnJlcXVpcmUgdGhhdCBjb25maWd1cmF0aW9uIGNoYW5nZXMg YW5kIHRoZSBsaWtlIGJlICJub3RpY2VkIiBiYWNrICh0aGVyZQ0KYXJlIHRvb2xzIGluIHRoZSBy b290IGRpcmVjdG9yeSB0byBjb3B5IHRoZW0gYmFjaykNCg0KSWYgeW91IHdhbnQgYSAidHJhZGl0 aW9uYWwiIHN5c3RlbSB0aGVuIHRoZSBhYm92ZSBpcyBob3cgeW91IGJ1aWxkIGl0Lg0KQnV0IGJl IGF3YXJlIHRoYXQgb24gdGhlIFBpIHNwZWNpZmljYWxseSB0aGUgU0QgY29udHJvbGxlciBpcw0K dXNiLWF0dGFjaGVkIGFuZCBzbG93Lg0KDQpJIHVzZSBDcm9jaGV0IGFsbCB0aGUgdGltZSB0byBi dWlsZCBQaS1zcGVjaWZpYyBpbWFnZXMgYW5kIHdoaWxlIHRoZXJlDQpoYXZlIGJlZW4gc21hbGwg Y2hhbmdlcyByZXF1aXJlZCBmcm9tIHRpbWUgdG8gdGltZSBpdCB3b3JrcyBmaW5lIGZvcg0KMTIu eCBpbWFnZXMgYXQgcHJlc2VudC4gIEkgaGF2ZSBub3QgKHlldCkgdHJpZWQgYnVpbGRpbmcgb25l IHdpdGggLUhFQUQuDQoNCi0tDQpLYXJsIERlbm5pbmdlcg0Ka2FybEBkZW5uaW5nZXIubmV0IDxt YWlsdG86a2FybEBkZW5uaW5nZXIubmV0Pg0KL1RoZSBNYXJrZXQgVGlja2VyLw0KL1tTL01JTUUg ZW5jcnlwdGVkIGVtYWlsIHByZWZlcnJlZF0vDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KIERJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIHJlY2lwaWVudCBhbmQgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgcHJvbXB0bHkgbm90aWZ5IHRoZSBz ZW5kZXIsIEphbWVzIFNodXJpZmYgKGphbWVzQG9wZW50ZWNoLmNjPG1haWx0bzpqYW1lc0BvcGVu dGVjaC5jYz4pLg0K --_002_MWHPR06MB31346CB5D826EE885034AD1CAA430MWHPR06MB3134namp_ Content-Type: text/plain; name="sdboot.txt" Content-Description: sdboot.txt Content-Disposition: attachment; filename="sdboot.txt"; size=2669; creation-date="Mon, 02 Dec 2019 05:32:35 GMT"; modification-date="Mon, 02 Dec 2019 05:32:35 GMT" Content-Transfer-Encoding: base64 IyEvYmluL3Rjc2gKCmlmIChgdW5hbWUgLW1gID09IGFybTY0KSB0aGVuCiBzZXQgQk9PVEZTPS9i b290L2Zpcm13YXJlLwoKIHNldCBVRUZJX0xPQURFUl9QQVRIID0gL2Jvb3QvbG9hZGVyX2x1YS5l ZmkKIHNldCBEVEJfQVdfUEFUSD0vYm9vdC9kdGIvYWxsd2lubmVyLwogc2V0IERUQl9PTF9QQVRI PS9ib290L2R0Yi9vdmVybGF5cy8KICNzZXQgRFRCX1JDX1BBVEgKZWxzZQogc2V0IEJPT1RGUz0v bW50L2Jvb3Rmcy8KCiBzZXQgTUFLRU9CSkRJUlBSRUZJWD0vdXNyL29iagogc2V0IFNSQ0RJUj0i L3Vzci9zcmMuaGVhZCIKIHNldCBLRVJOQ09ORj1PVENDCgogc2V0IFVFRklfTE9BREVSX1BBVEgg PSAkTUFLRU9CSkRJUlBSRUZJWC8kU1JDRElSL2FybTY0LmFhcmNoNjQvc3RhbmQvZWZpL2xvYWRl cl9sdWEvbG9hZGVyX2x1YS5lZmkKIHNldCBEVEJfQVdfUEFUSD0kTUFLRU9CSkRJUlBSRUZJWC8k U1JDRElSL2FybTY0LmFhcmNoNjQvc3lzLyRLRVJOQ09ORi9tb2R1bGVzLyRTUkNESVIvc3lzL21v ZHVsZXMvZHRiL2FsbHdpbm5lci8KIHNldCBEVEJfT0xfUEFUSD0kTUFLRU9CSkRJUlBSRUZJWC8k U1JDRElSL2FybTY0LmFhcmNoNjQvc3lzLyRLRVJOQ09ORi9tb2R1bGVzLyRTUkNESVIvc3lzL21v ZHVsZXMvZHRiL2FsbHdpbm5lci8KIHNldCBEVEJfUkNfUEFUSD0kTUFLRU9CSkRJUlBSRUZJWC8k U1JDRElSL2FybTY0LmFhcmNoNjQvc3lzLyRLRVJOQ09ORi9tb2R1bGVzLyRTUkNESVIvc3lzL21v ZHVsZXMvZHRiL3JvY2tjaGlwLwplbmRpZgoKc2V0IEZJUk1XQVJFX1JFUE9fUEFUSCA9IC9yb290 L3JwaS9maXJtd2FyZS9ib290LwpzZXQgVUJPT1RfQklOX1BBVEg9L3Jvb3Qvc3JjL3UtYm9vdC12 MjAxOS4xMC91LWJvb3QuYmluCnNldCBQU0NJX01PTl9QQVRIID0gL3Jvb3QvcnBpL3JwaTMtcHNj aS1tb25pdG9yL2FybXN0dWI4LmJpbgpzZXQgRklSTVdBUkVfQ09ORklHX1BBVEggPSAvdXNyL3Bv cnRzL3N5c3V0aWxzL3JwaS1maXJtd2FyZS9maWxlcy9jb25maWdfcnBpMy50eHQKCiMgRW5kIG9m IENvbmZpZwoKc2V0IERUQl9BV19GSUxFUyA9IChzdW41MGktYTY0LW5hbm9waS1hNjQuZHRiIHN1 bjUwaS1hNjQtb2xpbnV4aW5vLmR0YiBzdW41MGktYTY0LXBpbmU2NC1wbHVzLmR0YiBzdW41MGkt YTY0LXBpbmU2NC5kdGIgc3VuNTBpLWE2NC1zb3BpbmUtYmFzZWJvYXJkLmR0YiBzdW41MGktaDUt b3JhbmdlcGktcGMyLmR0YikKc2V0IERUQl9PTF9GSUxFUyA9IChzdW41MGktYTY0LXNpZC5kdGJv IHN1bjUwaS1hNjQtdGhzLmR0Ym8gc3VuNTBpLWE2NC10aW1lci5kdGJvKQpzZXQgRFRCX1JDX0ZJ TEVTID0gKHJrMzMyOC1yb2NrNjQuZHRiIHJrMzM5OS1yb2NrcHJvNjQuZHRiKQoKc2V0IEZJUk1X QVJFX1JFUE9fRklMRVMgPSAoTElDRU5DRS5icm9hZGNvbSBib290Y29kZS5iaW4gZml4dXAuZGF0 IGZpeHVwX2NkLmRhdCBmaXh1cF9kYi5kYXQgZml4dXBfeC5kYXQgc3RhcnQuZWxmIHN0YXJ0X2Nk LmVsZiBzdGFydF9kYi5lbGYgc3RhcnRfeC5lbGYgYmNtMjcxMC1ycGktMy1iLmR0YikKI3NldCBG SVJNV0FSRV9GRFRfRklMRSA9IC9yb290L3JwaS9iY20yNzEwLXJwaS0zLWItY2xvY2tmaXguZHRz CgojIGkyYy1ydGMgaXMgZm9yIG9wdGlvbmFsIEkyQyBSVEMuIENvbmZpZy50eHQgbXVzdCBiZSBt b2RpZmllZCB0byBzdXBwb3J0IGl0LgpzZXQgRklSTVdBUkVfT0xfUEFUSCA9ICRGSVJNV0FSRV9S RVBPX1BBVEgvb3ZlcmxheXMKc2V0IEZJUk1XQVJFX09MX0ZJTEVTID0gKG1tYy5kdGJvIHBpMy1k aXNhYmxlLWJ0LmR0Ym8gcHdtLmR0Ym8gaTJjLXJ0Yy5kdGJvKQoKIyAvCmZvcmVhY2ggeCAoJEZJ Uk1XQVJFX1JFUE9fRklMRVMpCgljcCAkRklSTVdBUkVfUkVQT19QQVRILyR4ICRCT09URlMKZW5k CgojZHRjIC1JIGR0cyAtTyBkdGIgLW8gJEJPT1RGUy9iY20yNzEwLXJwaS0zLWIuZHRiICRGSVJN V0FSRV9GRFRfRklMRQoKY3AgJFBTQ0lfTU9OX1BBVEggJFVCT09UX0JJTl9QQVRIICRCT09URlMK Y3AgJEZJUk1XQVJFX0NPTkZJR19QQVRIICRCT09URlMvY29uZmlnLnR4dAoKIyAvb3ZlcmxheXMK bWtkaXIgLXAgJEJPT1RGUy9vdmVybGF5cwpmb3JlYWNoIHggKCRGSVJNV0FSRV9PTF9GSUxFUykK CWNwICRGSVJNV0FSRV9PTF9QQVRILyR4ICRCT09URlMvb3ZlcmxheXMvCmVuZAoKIyBEVEIKbWtk aXIgLXAgJEJPT1RGUy9kdGIvYWxsd2lubmVyICRCT09URlMvZHRiL292ZXJsYXlzICRCT09URlMv ZHRiL3JvY2tjaGlwCmZvcmVhY2ggeCAoJERUQl9BV19GSUxFUykKCWNwICREVEJfQVdfUEFUSC8k eCAkQk9PVEZTL2R0Yi9hbGx3aW5uZXIvCmVuZApmb3JlYWNoIHggKCREVEJfT0xfRklMRVMpCglj cCAkRFRCX09MX1BBVEgvJHggJEJPT1RGUy9kdGIvb3ZlcmxheXMvCmVuZApmb3JlYWNoIHggKCRE VEJfUkNfRklMRVMpCgljcCAkRFRCX1JDX1BBVEgvJHggJEJPT1RGUy9kdGIvcm9ja2NoaXAvCmVu ZAoKIyBFRkkKIyBsb2FkZXJfbHVhLmVmaSBpcyBhIGhhcmQgbGluayB3aXRoIGxvYWRlci5lZmkK bWtkaXIgLXAgJEJPT1RGUy9FRkkvQk9PVApjcCAkVUVGSV9MT0FERVJfUEFUSCAkQk9PVEZTL0VG SS9CT09UL2Jvb3RhYTY0LmVmaQoKbWtkaXIgLXAgJEJPT1RGUy9FRkkvRlJFRUJTRAplY2hvIGN1 cnJkZXY9ZGlzazBwMiA+ICRCT09URlMvRUZJL0ZSRUVCU0QvbG9hZGVyLmVudgo= --_002_MWHPR06MB31346CB5D826EE885034AD1CAA430MWHPR06MB3134namp_-- From owner-freebsd-arm@freebsd.org Mon Dec 2 11:13:48 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D9941CE0E3 for ; Mon, 2 Dec 2019 11:13:48 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RMtf1kKTz3DqT; Mon, 2 Dec 2019 11:13:45 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB2BDSku053893 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 2 Dec 2019 22:13:34 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB2BDMYK065631 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Dec 2019 22:13:22 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id xB2BDMI6065630; Mon, 2 Dec 2019 22:13:22 +1100 (AEDT) (envelope-from peter) Date: Mon, 2 Dec 2019 22:13:22 +1100 From: Peter Jeremy To: Michal Meloun Cc: freebsd-arm@freebsd.org Subject: Re: rk_tsadc breaks (my) Rock64 Message-ID: <20191202111322.GF37113@server.rulingia.com> References: <20191201110716.GA41224@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oj4kGyHlBMXGt3Le" Content-Disposition: inline In-Reply-To: <20191201110716.GA41224@server.rulingia.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RMtf1kKTz3DqT X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-7.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-3.27)[ip: (-9.63), ipnet: 2001:19f0:5800::/38(-4.82), asn: 20473(-1.87), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 11:13:48 -0000 --oj4kGyHlBMXGt3Le Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-Dec-01 22:07:16 +1100, Peter Jeremy wrote: >r355173 added code to read the Rockchip temperature sensors. Unfortunatel= y, >this breaks on my Rock64. I've tried to understand what's going wrong but >haven't managed to make much headway. It looks like there some configurat= ion >missing from syscon that tsadc needs but I'm not sure what (and I don't re= ally >understand what syscon is doing). I'd appreciate any insights. I've added a pile of printf's and done some more digging and have made some progress. Firstly, I've found that the syscon@ff100000 FDT entry attaches as two distinct devices: rk_grf0: mem 0xff100000-0xff100fff on ofw= bus0 (via compatible =3D "rockchip,rk3328-grf") simple_mfd0: mem 0xff450000-0xff45fff= f on ofwbus0 (via compatible =3D "simple-mfd") Based on the traceback going via simple_mfd_syscon_write_4(), I had assumed that tsadc_attach() was using the latter device but when I added code to print structure addresses, I discovered it was the former. This makes the problem clearer: rk_grf0 requests and is allocated 4KiB memory ("reg =3D <0x0 0xff100000 0x0 0x1000>;" in the FDT and "mem 0xff100000-0xff100fff" in the device attach message above) but the tsadc_init() code is doing: SYSCON_WRITE_4(sc->grf, GRF_TSADC_TESTBIT_L, GRF_TSADC_VCM_EN_L); with #define GRF_TSADC_TESTBIT_L 0x0e648 and that offset is well outside the 4KiB allocated to the device. (On the positive side, a panic makes the problem a lot clearer than writing to a random device location would have been). Ganbold's followup shows that the RK3399 allocates 64KiB to the syscon device so the equivalent write is valid on a RK3399. I suspect the problem is that the following defines are only valid for the RK3399 since I can't find any matches to either the names or offsets in the following: #define GRF_SARADC_TESTBIT 0x0e644 #define GRF_TSADC_TESTBIT_L 0x0e648 #define GRF_TSADC_TESTBIT_H 0x0e64c Unfortunately, that also means I currently have no idea what the RK3328 equivalents to those offsets are. --=20 Peter Jeremy --oj4kGyHlBMXGt3Le Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl3k8cJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzRkwg/+IxI/vMksjqSgWDSJ8jXNd6H7ftRcBsy0e4K4TAhuKg5kglFR1SBFOQyW VgcvZQtLr6uAUEGYGQhmDpEaRacKPoS3ltCqDkqCuVUKqsp0v2b1k7njSlxYr9k+ jTz1WNLHozmOLHks1/oPJ3bE4RE3Q1yVnK+9dcmW5EnS1i5SPw0JbBQAOB7jdQzs 9Wo6sEdewvQhRuPExX5aOrd92vA8AzJL5fJM4v4MkPztvEj3pusOXA6vysAGJd5m yxsGH4FnP5laxCkV/DFsBmVnE1UEBvjqNTfoGo8p73t0GOXcFwf8FyEWDf4J+mMh nEaI6mN4cA0Ez8kq6fW/Rf7s7cXwX/8XgaMVAb+EGDLXyAGCdyWC1m0CJ9BLyETV Wpva6f7FWI8NOYweCcGsqKI1fBAU7J9G2M+8piPlBs0peLT6/KibjcG5bXxCg/NJ TRYFxNFpf6m7RXKM1n1qdtNoYoA8HMkbq9Ogk38PKbLqn/YLdDs75mxZY63yK7dN IPkvGgV3P9xPpzSeU5Ck5dhGOh1qrFDkvKugKY7tUTlq9Sb0EQnEhKaYW4jHtLoz 2aMJVA7UMQX5MpIUDCsxuN0pIISYfKXFCB0iQ/4LS2nhekZanD3Ucq/wyjxnbhH6 B3lDRRVzsSSUSI0w9ZM37NF63a+zpb6cF27+0r6bT4h1tpg6PmU= =uKjc -----END PGP SIGNATURE----- --oj4kGyHlBMXGt3Le-- From owner-freebsd-arm@freebsd.org Mon Dec 2 13:04:27 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 11AD11A93FB for ; Mon, 2 Dec 2019 13:04:27 +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 47RQLK6WQBz3L2M; Mon, 2 Dec 2019 13:04:25 +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 d5cfb9f6; Mon, 2 Dec 2019 14:04:17 +0100 (CET) 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=PXzajdEW1kZEoy4F9+NwN2yq64E=; b=dUba3/BF74VddAdxPv/r9P6VT/cY p9WJ3s+br9Lm1VqXTyUx77Y8noHoBXrpy+S2bJGFow12Ru5wQmZWTucbpuhP23FS gNT1E2gWDlK47ScFdIF1/bwc6b8sRTBgToOMiEqRjINyY6z6HzpU+VFpfTSvgbWC RtA8DVROqUMKVF0= 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=rzpxz2wmGBKimmINXJ6vU6XoYygIns6pN2gObADoyuxwKMK9b+kQC1Ej SXP4q3ZoKbgBqLUpFKmFZNfGHrV1y4XrknuezJY6F1E+htnBTeSMsK9+bFOuzEYI nDBRw+rCnnQLcXQ4MF84klQCEwI8kxxLLitKBKYsofEYfdHVhKQ= Received: from skull.home.blih.net (lfbn-1-12172-130.w90-92.abo.wanadoo.fr [90.92.223.130]) by mail.blih.net (OpenSMTPD) with ESMTPSA id a47957ca TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 2 Dec 2019 14:04:17 +0100 (CET) Date: Mon, 2 Dec 2019 14:04:16 +0100 From: Emmanuel Vadot To: Peter Jeremy Cc: Michal Meloun , freebsd-arm@freebsd.org Subject: Re: rk_tsadc breaks (my) Rock64 Message-Id: <20191202140416.936a457adebce6fca1341b18@bidouilliste.com> In-Reply-To: <20191202111322.GF37113@server.rulingia.com> References: <20191201110716.GA41224@server.rulingia.com> <20191202111322.GF37113@server.rulingia.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RQLK6WQBz3L2M X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mail header.b=dUba3/BF; dmarc=none; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.177.182 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-0.54 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mail]; NEURAL_HAM_MEDIUM(-0.63)[-0.626,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.83.177.182/32]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bidouilliste.com]; NEURAL_HAM_LONG(-0.39)[-0.389,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.38)[ip: (-0.58), ipnet: 212.83.160.0/19(2.42), asn: 12876(0.06), country: FR(-0.00)]; ASN(0.00)[asn:12876, ipnet:212.83.160.0/19, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 13:04:27 -0000 On Mon, 2 Dec 2019 22:13:22 +1100 Peter Jeremy wrote: > On 2019-Dec-01 22:07:16 +1100, Peter Jeremy wrote: > >r355173 added code to read the Rockchip temperature sensors. Unfortunately, > >this breaks on my Rock64. I've tried to understand what's going wrong but > >haven't managed to make much headway. It looks like there some configuration > >missing from syscon that tsadc needs but I'm not sure what (and I don't really > >understand what syscon is doing). I'd appreciate any insights. > > I've added a pile of printf's and done some more digging and have made some > progress. > > Firstly, I've found that the syscon@ff100000 FDT entry attaches as two > distinct devices: > rk_grf0: mem 0xff100000-0xff100fff on ofwbus0 > (via compatible = "rockchip,rk3328-grf") > simple_mfd0: mem 0xff450000-0xff45ffff on ofwbus0 > (via compatible = "simple-mfd") ??? those aren't the same devices. > Based on the traceback going via simple_mfd_syscon_write_4(), I had assumed > that tsadc_attach() was using the latter device but when I added code to > print structure addresses, I discovered it was the former. > > This makes the problem clearer: rk_grf0 requests and is allocated 4KiB > memory ("reg = <0x0 0xff100000 0x0 0x1000>;" in the FDT and > "mem 0xff100000-0xff100fff" in the device attach message above) but the > tsadc_init() code is doing: > SYSCON_WRITE_4(sc->grf, GRF_TSADC_TESTBIT_L, > GRF_TSADC_VCM_EN_L); > with > #define GRF_TSADC_TESTBIT_L 0x0e648 > and that offset is well outside the 4KiB allocated to the device. > (On the positive side, a panic makes the problem a lot clearer than > writing to a random device location would have been). > > Ganbold's followup shows that the RK3399 allocates 64KiB to the syscon > device so the equivalent write is valid on a RK3399. > > I suspect the problem is that the following defines are only valid for > the RK3399 since I can't find any matches to either the names or offsets > in the following: > #define GRF_SARADC_TESTBIT 0x0e644 > #define GRF_TSADC_TESTBIT_L 0x0e648 > #define GRF_TSADC_TESTBIT_H 0x0e64c > > Unfortunately, that also means I currently have no idea what the RK3328 > equivalents to those offsets are. > > -- > Peter Jeremy root@rock64:~ # uname -a FreeBSD rock64.home.blih.net 13.0-CURRENT FreeBSD 13.0-CURRENT #13 r355188:355190M: Thu Nov 28 21:43:00 CET 2019 manu@skull.home.blih.net:/usr/home/manu/Work/freebsd/obj/usr/home/manu/Work/freebsd/freebsd-svn/base/head/arm64.aarch64/sys/GENERIC arm64 root@rock64:~ # sysctl hw.temperature hw.temperature.CPU: 50.7C Everything is working for me after I've added the clocks, so I don't know what's happening for you. But after looking again at the docs it seems that rk3328 is a mix between v2 and v3 so the GRF write are wrong. I'll have a look today or tomorow and fix this. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Dec 2 13:53:09 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8BAA31AAA0B for ; Mon, 2 Dec 2019 13:53:09 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RRQX5LVwz3NXQ for ; Mon, 2 Dec 2019 13:53:08 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm1-x343.google.com with SMTP id t14so5875190wmi.5 for ; Mon, 02 Dec 2019 05:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:reply-to:subject:to:cc:references:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=CuLRiUr95THl62FLvgKd/dFbFXerHT36aceO0P6PuvA=; b=PLs0OH/8V2XsUJDwGl4jerx7mVfQWygE4kwJbMTtqF/UO5YlLKD7jh55TSDrfLU4+G k+L7GiZF0zuP+ZBaQNj3LCclmozafP2cFr63xGBuzTiGaJ1mmK693LfM0NPjxlH+ML/G E6IcstorM5aoDTB8Nr6Et2tYY4G7PlYldrD2+ocFngIornbWCuVU+fdggAIib9Xa4N9H bg9KBVuwUsVns4chCFK1lRp0fFBcjzH6yb0cxHX0GNy+8ON2BdRLP6OfFGeZxDF5Il/k iJfSFZd+DfDJG6dL9YE4oaX7rgDkGraiLlrBbXJTVZNbH5GNXUVnCpPDzp/GK1BUXHU3 TOuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:reply-to:subject:to:cc:references :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=CuLRiUr95THl62FLvgKd/dFbFXerHT36aceO0P6PuvA=; b=dk3Jxy8CtfTI7nlnPPLSJxM3qUh3+nItRTY8MTsA0iPqaVXkIZeBjKizhxrdrt90AN rDfBqJO0N2t+B1nfa6GzB3GzEpFOo6Ci5Gw9pRXuIu4GXDtnvWX6n2Qp4D0pW/jI5qqp F/1p/WmImVOIVabvXadKoRCnJEKpKe7lSrQrFiKm+eURONFFfXBrnhFxFOTPOJWTKA7t f0acG9bwQ8cq22G8oyDDKOMa0dWbvhVsKSyteDL3oNC51EG/v97lE/K3dx1mR8AGMh11 vrUYV9uHpIZt9NpytQVA+SGqxd4yayZ/x6mk1q/kXGdyhHgBzTOC9aCNZpoLraM61bx6 z6Rw== X-Gm-Message-State: APjAAAUfyvvooPrBmIqLhMJkElD3wanRzEtGTrHdB9uNWc9D2T+Q7EVj iRnyPZrShaAt8Bwq5uRxE7r5WP0Z X-Google-Smtp-Source: APXvYqyTB23pMi5WctDQ0ePm+8FKf5vYaYNLm57ozHwp3E5QiP8/JAzhZhGdAvgZvtoAmzALSgu0IA== X-Received: by 2002:a05:600c:1007:: with SMTP id c7mr5281689wmc.158.1575294787184; Mon, 02 Dec 2019 05:53:07 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id h8sm23746276wrx.63.2019.12.02.05.53.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2019 05:53:06 -0800 (PST) Sender: Michal Meloun From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: rk_tsadc breaks (my) Rock64 To: Emmanuel Vadot , Peter Jeremy Cc: freebsd-arm@freebsd.org References: <20191201110716.GA41224@server.rulingia.com> <20191202111322.GF37113@server.rulingia.com> <20191202140416.936a457adebce6fca1341b18@bidouilliste.com> Autocrypt: addr=mmel@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFYuVRkBCADZiwLCCne3wG9b9k+R2Neo5zVo2bLaZRfNNY/v9kg283i0sb1Da4EdEiNT 15El5UyozhphUIbIR/zrVpxF1TvvFdoCyzx6a68bNY2d9dBrDcNDZC+XnyDdHQoobN87DWT1 mRVkmbg9LHZ/SVUOkGYuWyE+8UYeDAcUizuXwSK5zFWmeTyIoWNa68ifrWLfQe0p4x5jC/AI VURCi17p360vU4fhgwoMvEEhrRBWCr4DYHToFjIt2WdBy3GR1qoO0+Xkd6G+OoBULo+XDfgu L2WdPvh0K69F9/LgHkMmG5Il7SCe62QGpG2vaCgRV7BQhLX+kxlvM+WrdRatWRml4Y/3ABEB AAHNIE1pY2hhbCBNZWxvdW4gPG1tZWxAZnJlZWJzZC5vcmc+wsCuBBMBCgBBAhsDBQsJCAcD BRUKCQgLBRYDAgEAAh4BAheAAhkBFiEEAN1KEEuAn+Apg413aR6ya17FqqoFAlw3aO8FCQ9v FVYAIQkQaR6ya17FqqoWIQQA3UoQS4Cf4CmDjXdpHrJrXsWqqsgXB/9X81G4C63DVxn8dELB +nTQpj7yDvfQrA5oAyE9i+ry2p/ySsPCEVFa32zgNJVNUlQLZ1FlrmDUxLvuJAv9ZbMFSEmP utbi4ylwqmLtReLTrSwqucT7VkG9qcbxgIxMcrFCBAMPRwGqzI4B+tID4/LJrf8fICHW++NB l+7m9bEDVfk1fmXkq2iemsn7JtVpzA5bfjJ9ZJf6dzHTz0mlSSd6cZ0j6BWgp9rq6H/xiIJl MjmmjEG22s4Hw0Z/KVOxNNNvDamSKt5WRzzuqr74j1sE21OpY5mMH/coFR3irW94RRrgxLrd Na0C9wRyzEeIG/gAfqek87+I/Jy4YaGqV1PUzsBNBFYuVRkBCAC6oEZH0ttQ/zqlhPZl34dm yI66fbgvE9DAropm7KwHSyjTaKxrtpxPq3m4F/J+Z2DN++xzp2pTxsjrl7wm0PDBVUXVjh8X pyY1yYmpTXQbDn9sC72t70klbHaD84m1gyHCaoQTkNxLobCC8lkj72GChIsveZn4aw7bk0zg GFUfWjUAThDc7QdkwycjMf6mZrRq6BldzdB6nXv85xz7UDvERufxUBjHxzCORhTLsnK9XHh5 y6P6L66gJeE2FflB0hyfhQxPXbfcFx3JVm1mwtMjboHIWauq4aOSY37+Gtr+z6cp9x6A4p4d ZVj+4WANGTRMRh3pC511lajv5cxkumzBABEBAAHCwGUEGAEKAA8CGwwFAlmMEcMFCQcgI6oA CgkQaR6ya17Fqqq7Kwf+IOBEiuUy8VMYvKS1nCz8r8LTeBZn+1bAlXn5IWpGhqwz5n735xvj hcDetF6qJ4uxgXmpJdNccE+ESDX71X0oQ8unB6S0u0C/zPKc37pVV9/DJFZDg8hmYcIxPo8k /5GTQNTpWsNzdyHnx6t267JEOxuHfaD3qdgw28OwuEO+rjgY8ct+CVQdFjrAejcjEAfYeixp Y0LXRHXclKsJ0Wc8x4hr6dIT7XWEB0GZam4+BVfZU0Su2vBIGvsuzIJnjIs7Rs3l8ozT9Nq9 z0Rwj2oMGue2z8R9mgIeEO1MwQWdBkzJuwyyjbQj+fFg8W5a64Wfu5B6hivBbG3XlKQ3RGC1 XcLAkwQYAQoAJgIbDBYhBADdShBLgJ/gKYONd2kesmtexaqqBQJcN2mbBQkPbxYCACEJEGke smtexaqqFiEEAN1KEEuAn+Apg413aR6ya17FqqrTqwf/TpJP3Ztv5gLN7WwOpZSjmQMH1MAa J8Bu2ISvXTm+TaP2yaGPBvbNiFV6sFiqgg79aiguDPKTFzw/X1bHzTxvBgNRma6WaGcRxbXl 2R6BNYK6VsqRNE94adVtIUDVlyr9DErhDEVSlNZv4si2tdF+6vAWirRA7N+V3wwoe3lYNb6o irVshZ9bvsvRstWbXP0ik7PJkLzGDVHQWblerzdFUs9yOsA/R1X6OhKNzO3FaaqkPioa6xog gmED32cKRQCUkoFd20eTtAZTWhiiTqFU1dcnsUW1RErbMIhT/CRUKelPkt56hBRaG+3WkAS8 YvNKFFUZ+nhHc0fLQYSMu7G3gw== Message-ID: Date: Mon, 2 Dec 2019 14:53:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191202140416.936a457adebce6fca1341b18@bidouilliste.com> Content-Type: multipart/mixed; boundary="------------2008DF11CC7EBBE6A82A354C" Content-Language: en-US X-Rspamd-Queue-Id: 47RRQX5LVwz3NXQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PLs0OH/8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of melounmichal@gmail.com designates 2a00:1450:4864:20::343 as permitted sender) smtp.mailfrom=melounmichal@gmail.com X-Spamd-Result: default: False [-1.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; CTYPE_MIXED_BOGUS(1.00)[]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (3.09), ipnet: 2a00:1450::/32(-2.69), asn: 15169(-1.94), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 13:53:09 -0000 This is a multi-part message in MIME format. --------------2008DF11CC7EBBE6A82A354C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 02.12.2019 14:04, Emmanuel Vadot wrote: > On Mon, 2 Dec 2019 22:13:22 +1100 > Peter Jeremy wrote: > >> On 2019-Dec-01 22:07:16 +1100, Peter Jeremy wrote: >>> r355173 added code to read the Rockchip temperature sensors. Unfortunately, >>> this breaks on my Rock64. I've tried to understand what's going wrong but >>> haven't managed to make much headway. It looks like there some configuration >>> missing from syscon that tsadc needs but I'm not sure what (and I don't really >>> understand what syscon is doing). I'd appreciate any insights. >> >> I've added a pile of printf's and done some more digging and have made some >> progress. >> >> Firstly, I've found that the syscon@ff100000 FDT entry attaches as two >> distinct devices: >> rk_grf0: mem 0xff100000-0xff100fff on ofwbus0 >> (via compatible = "rockchip,rk3328-grf") >> simple_mfd0: mem 0xff450000-0xff45ffff on ofwbus0 >> (via compatible = "simple-mfd") > > ??? those aren't the same devices. > >> Based on the traceback going via simple_mfd_syscon_write_4(), I had assumed >> that tsadc_attach() was using the latter device but when I added code to >> print structure addresses, I discovered it was the former. >> >> This makes the problem clearer: rk_grf0 requests and is allocated 4KiB >> memory ("reg = <0x0 0xff100000 0x0 0x1000>;" in the FDT and >> "mem 0xff100000-0xff100fff" in the device attach message above) but the >> tsadc_init() code is doing: >> SYSCON_WRITE_4(sc->grf, GRF_TSADC_TESTBIT_L, >> GRF_TSADC_VCM_EN_L); >> with >> #define GRF_TSADC_TESTBIT_L 0x0e648 >> and that offset is well outside the 4KiB allocated to the device. >> (On the positive side, a panic makes the problem a lot clearer than >> writing to a random device location would have been). >> >> Ganbold's followup shows that the RK3399 allocates 64KiB to the syscon >> device so the equivalent write is valid on a RK3399. >> >> I suspect the problem is that the following defines are only valid for >> the RK3399 since I can't find any matches to either the names or offsets >> in the following: >> #define GRF_SARADC_TESTBIT 0x0e644 >> #define GRF_TSADC_TESTBIT_L 0x0e648 >> #define GRF_TSADC_TESTBIT_H 0x0e64c >> >> Unfortunately, that also means I currently have no idea what the RK3328 >> equivalents to those offsets are. >> >> -- >> Peter Jeremy > > root@rock64:~ # uname -a > FreeBSD rock64.home.blih.net 13.0-CURRENT FreeBSD 13.0-CURRENT #13 r355188:355190M: Thu Nov 28 21:43:00 CET 2019 manu@skull.home.blih.net:/usr/home/manu/Work/freebsd/obj/usr/home/manu/Work/freebsd/freebsd-svn/base/head/arm64.aarch64/sys/GENERIC arm64 > root@rock64:~ # sysctl hw.temperature > hw.temperature.CPU: 50.7C > > Everything is working for me after I've added the clocks, so I don't > know what's happening for you. But after looking again at the docs it > seems that rk3328 is a mix between v2 and v3 so the GRF write are wrong. > I'll have a look today or tomorow and fix this. > Peter, can you please try following trivial patch? Michal --------------2008DF11CC7EBBE6A82A354C Content-Type: text/plain; charset=UTF-8; name="tsaadc_fix.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tsaadc_fix.diff" ZGlmZiAtLWdpdCBhL3N5cy9hcm02NC9yb2NrY2hpcC9ya190c2FkYy5jIGIvc3lzL2FybTY0 L3JvY2tjaGlwL3JrX3RzYWRjLmMKaW5kZXggNzQ0ZGMxYjhhZmIuLjk5NGQ0ZTE3NmU4IDEw MDY0NAotLS0gYS9zeXMvYXJtNjQvcm9ja2NoaXAvcmtfdHNhZGMuYworKysgYi9zeXMvYXJt NjQvcm9ja2NoaXAvcmtfdHNhZGMuYwpAQCAtMjQxLDcgKzI0MSw3IEBAIHN0YXRpYyBzdHJ1 Y3QgdHNlbnNvciByazMzMjhfdHNlbnNvcnNbXSA9IHsKIH07CiAKIHN0YXRpYyBzdHJ1Y3Qg dHNhZGNfY29uZiByazMzMjhfdHNhZGNfY29uZiA9IHsKLQkudHlwZSA9IAkJUktfVFNBRENf VjMsCisJLnR5cGUgPSAJCVJLX1RTQURDX1YyLAogCS5zaHV0ZG93bl90ZW1wID0JOTUwMDAs CiAJLnNodXRkb3duX21vZGUgPQkwLCAvKiBDUlUgKi8KIAkuc2h1dGRvd25fcG9sID0JCTAs IC8qIExvdyAgKi8K --------------2008DF11CC7EBBE6A82A354C-- From owner-freebsd-arm@freebsd.org Mon Dec 2 14:45:52 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5A7A11AC0BF for ; Mon, 2 Dec 2019 14:45:52 +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 47RSbM5yHbz3R2s; Mon, 2 Dec 2019 14:45:51 +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 18fef891; Mon, 2 Dec 2019 15:45:49 +0100 (CET) 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=Un7xzeU/30T3J8p3RfZ7vxbj150=; b=D/d44CIh87pRHS79yG8oX9NBHUog FN4MjkceLRq/J7nfGcQBQXH6zrASkRK4qWQuWG5vGh8TEqnBcdICDpBIjJZE6L9v ewq29XC8vGr6yrFURPNn7t4fGgDYtANaSNPv7o0hnPArwElFKOi4mHwtACYd5/Rs VIYk2OeHdI6Hgk8= 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=Y1Of+MiW1U7wksyjGwMoV6MPxK67G3INRS1Gq797VFEa96XM2RzHRPc5 EuHkFis+O9rI/6WGWfcp079IDYSwAGD5MqkZ7O5YvvcoSQU81e+kj3Phw3eRLrT8 FO7VWCT4nKuola0hUVGBVpstojLbyr0mUpSQaPhyl50dhCZEO0A= Received: from sonic.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1a0c5f36 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 2 Dec 2019 15:45:49 +0100 (CET) Date: Mon, 2 Dec 2019 15:45:48 +0100 From: Emmanuel Vadot To: mmel@freebsd.org Cc: Michal Meloun , Peter Jeremy , freebsd-arm@freebsd.org Subject: Re: rk_tsadc breaks (my) Rock64 Message-Id: <20191202154548.095d7d8ec8796af15e41e47c@bidouilliste.com> In-Reply-To: References: <20191201110716.GA41224@server.rulingia.com> <20191202111322.GF37113@server.rulingia.com> <20191202140416.936a457adebce6fca1341b18@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RSbM5yHbz3R2s X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 14:45:52 -0000 On Mon, 2 Dec 2019 14:53:07 +0100 Michal Meloun wrote: > > > On 02.12.2019 14:04, Emmanuel Vadot wrote: > > On Mon, 2 Dec 2019 22:13:22 +1100 > > Peter Jeremy wrote: > > > >> On 2019-Dec-01 22:07:16 +1100, Peter Jeremy wrote: > >>> r355173 added code to read the Rockchip temperature sensors. Unfortunately, > >>> this breaks on my Rock64. I've tried to understand what's going wrong but > >>> haven't managed to make much headway. It looks like there some configuration > >>> missing from syscon that tsadc needs but I'm not sure what (and I don't really > >>> understand what syscon is doing). I'd appreciate any insights. > >> > >> I've added a pile of printf's and done some more digging and have made some > >> progress. > >> > >> Firstly, I've found that the syscon@ff100000 FDT entry attaches as two > >> distinct devices: > >> rk_grf0: mem 0xff100000-0xff100fff on ofwbus0 > >> (via compatible = "rockchip,rk3328-grf") > >> simple_mfd0: mem 0xff450000-0xff45ffff on ofwbus0 > >> (via compatible = "simple-mfd") > > > > ??? those aren't the same devices. > > > >> Based on the traceback going via simple_mfd_syscon_write_4(), I had assumed > >> that tsadc_attach() was using the latter device but when I added code to > >> print structure addresses, I discovered it was the former. > >> > >> This makes the problem clearer: rk_grf0 requests and is allocated 4KiB > >> memory ("reg = <0x0 0xff100000 0x0 0x1000>;" in the FDT and > >> "mem 0xff100000-0xff100fff" in the device attach message above) but the > >> tsadc_init() code is doing: > >> SYSCON_WRITE_4(sc->grf, GRF_TSADC_TESTBIT_L, > >> GRF_TSADC_VCM_EN_L); > >> with > >> #define GRF_TSADC_TESTBIT_L 0x0e648 > >> and that offset is well outside the 4KiB allocated to the device. > >> (On the positive side, a panic makes the problem a lot clearer than > >> writing to a random device location would have been). > >> > >> Ganbold's followup shows that the RK3399 allocates 64KiB to the syscon > >> device so the equivalent write is valid on a RK3399. > >> > >> I suspect the problem is that the following defines are only valid for > >> the RK3399 since I can't find any matches to either the names or offsets > >> in the following: > >> #define GRF_SARADC_TESTBIT 0x0e644 > >> #define GRF_TSADC_TESTBIT_L 0x0e648 > >> #define GRF_TSADC_TESTBIT_H 0x0e64c > >> > >> Unfortunately, that also means I currently have no idea what the RK3328 > >> equivalents to those offsets are. > >> > >> -- > >> Peter Jeremy > > > > root@rock64:~ # uname -a > > FreeBSD rock64.home.blih.net 13.0-CURRENT FreeBSD 13.0-CURRENT #13 r355188:355190M: Thu Nov 28 21:43:00 CET 2019 manu@skull.home.blih.net:/usr/home/manu/Work/freebsd/obj/usr/home/manu/Work/freebsd/freebsd-svn/base/head/arm64.aarch64/sys/GENERIC arm64 > > root@rock64:~ # sysctl hw.temperature > > hw.temperature.CPU: 50.7C > > > > Everything is working for me after I've added the clocks, so I don't > > know what's happening for you. But after looking again at the docs it > > seems that rk3328 is a mix between v2 and v3 so the GRF write are wrong. > > I'll have a look today or tomorow and fix this. > > > > Peter, > can you please try following trivial patch? > Michal > This isn't enough, RK3328 initialization is V2 but needs the AUTO_Q_SEL bit too (like v3). There might be other stuff that I haven't found yet. That still doesn't explain why it's working for me (both DEBUG and NODEBUG kernels). -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Dec 2 15:11:45 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9C2551ACCBD for ; Mon, 2 Dec 2019 15:11:45 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RT9D3bJbz3xTZ for ; Mon, 2 Dec 2019 15:11:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id xB2FCamV062046 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Dec 2019 16:12:37 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1575299557; bh=kvHJDFCPB871FqVfY0dUPyQ8WBnRldfF/xX8WAzlSqU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=otElm957HW7hWgjfUACp7SwzwXaZbhb57FpSahryiOs3cMQG4Npe1LNqjsMlXjxVB enQMQ3l6zOFSc66Nv6IQecg+YvNP7/RwXnopd/H1AuxvudysQHKZuDaY3YMkznIo2p 1/aDUXCv3XB7bnOD+aIFHHbWJ+hZX2ptTA8GvITk= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id xB2FBWeB004816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2019 16:11:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id xB2FBWXc041072; Mon, 2 Dec 2019 16:11:32 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id xB2FBV0R041071; Mon, 2 Dec 2019 16:11:31 +0100 (CET) (envelope-from ticso) Date: Mon, 2 Dec 2019 16:11:31 +0100 From: Bernd Walter To: Peter Jeremy Cc: John F Carr , "freebsd-arm@freebsd.org" Subject: Re: 64 bit ARM systems with more than four cores Message-ID: <20191202151131.GJ95260@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> <20191202021717.GA70723@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191202021717.GA70723@server.rulingia.com> X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-Rspamd-Queue-Id: 47RT9D3bJbz3xTZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=otElm957; dmarc=none; spf=none (mx1.freebsd.org: domain of ticso@cicely7.cicely.de has no SPF policy when checking 195.149.99.3) smtp.mailfrom=ticso@cicely7.cicely.de X-Spamd-Result: default: False [-1.78 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; HAS_REPLYTO(0.00)[ticso@cicely.de]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cicely.de]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cicely.de:+]; RCVD_IN_DNSWL_NONE(0.00)[3.99.149.195.list.dnswl.org : 127.0.20.0]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:21461, ipnet:195.149.99.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 15:11:45 -0000 On Mon, Dec 02, 2019 at 01:17:17PM +1100, Peter Jeremy wrote: > On 2019-Dec-01 21:37:53 +0000, John F Carr wrote: > >Two RK3399 based systems, 2 A-72 + 4 A-53: RockPro64 (http://www.pine64.com/) > >and ROCK Pi 4 (http://radxa.com). I can't use the RockPro64 due to the > >1.5 MBps serial port. Apparently it works or almost works with some special > >handling if your serial interface can count to 1,500,000. > > I can't help with the >4 cores bit but the 1.5Mbps serial link shouldn't be > a problem. I have a Rock64 connected to a FT232R clone (something like > https://www.aliexpress.com/item/32680591167.html) and don't have any problems. > (I had to patch ports/comms/conserver-com to support 1.5Mbps but everything > else "just worked"). I still can't get my RockPro64 to boot though. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Dec 2 17:42:16 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 22F051B1743 for ; Mon, 2 Dec 2019 17:42:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RXVv1DXmz47R6 for ; Mon, 2 Dec 2019 17:42:15 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f46.google.com with SMTP id x1so226990iop.7 for ; Mon, 02 Dec 2019 09:42:15 -0800 (PST) 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=1um95eb0s7mLYcso6C6GT3vgp04LVlCdYvL27GPH49Y=; b=ccuPvp0lW8RYKgYW7sU4fo9bnv+wHKwEAE/XENkqfwHvXcgxGfweiNfSvjSxbRFSnc yA7TNa+HweYRUbze7COhmOE2FMPcrQOypI80j9dyU16tfO+O8+L8J/qxXcwfV/gJtfxk W9JzYrb+cvjR3u0qTFxm6GkoDQn9JyXF7tdzhOYh74PAA5Fi29n+8/8MdDMMPtwLJoII cRdxfzsz3+JwuSdOJMG/D/MexYkk+EWO0b4ARWbpwPKrS91dMDYz0M2qeAsVBSi/VQff crfaXYintu551QasuK6lHqTJ5XL4lWrf66ix/fcbNxcJPsQ2CzoeCiWwa2bqB98YQ1ob T5kA== X-Gm-Message-State: APjAAAU55GVuZs8fXJxhi09Dr/vymJ5RHNht38X+uUh4DZ/i6UCWkLM4 IftZBsQ/Ck86CUBcBk5o1b1FWWdDm9cg4mwbh9Y= X-Google-Smtp-Source: APXvYqzXlDlxBmIYafuCOIWQ+lnyBEPZXe1FFMWVTEipUpV/gWyqtW9KPNKi06BfuXnlc05FRh6CjwGqKkcAlFuM8Xs= X-Received: by 2002:a02:c009:: with SMTP id y9mr653699jai.111.1575308534084; Mon, 02 Dec 2019 09:42:14 -0800 (PST) MIME-Version: 1.0 References: <94BC4785-B16E-43B2-B222-3D3C8C5DEB50@exchange.mit.edu> In-Reply-To: From: Ed Maste Date: Mon, 2 Dec 2019 08:55:43 -0500 Message-ID: Subject: Re: 64 bit ARM systems with more than four cores To: Greg V Cc: John F Carr , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47RXVv1DXmz47R6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.12 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[46.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.12)[ip: (-5.46), ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.94), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[46.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 17:42:16 -0000 On Sun, 1 Dec 2019 at 17:05, wrote: > > Now, if you have cash but not ThunderX2 levels of cash: Ampere eMAG is the best option. > Available in Lenovo HR350A and HR330A boxes, also from Avantek (idk what's the mainboard there??), > also rentable in bare-metal-cloud at Packet (they have the Lenovos). > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237055 for the bringup story :) > I think most of the bugfixes required for eMAG are in -CURRENT. s/most/all/ - folks might have more work in progress, but I have an HR350A in my office and that works just fine with -CURRENT. A Poudriere run of the full ports tree took around 60h. I tried to find all of the required commits and merge them to stable/12 in time for 12.1 but wasn't able to do so, and unfortunately 12.1 doesn't boot (at least in my diskless NFS root setup). From owner-freebsd-arm@freebsd.org Mon Dec 2 22:11:24 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B8ADE1BA2A8 for ; Mon, 2 Dec 2019 22:11:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.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 47RfTR2LNJz4T16 for ; Mon, 2 Dec 2019 22:11:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 61K8NxsVM1kaLZIVseiuAH9JNd0zKQ9wqGZDsY.ZeK2c5xObI70iCEbPzyV3DIR igFCSiFEcM0ebL8E7f7NoCsmGDHjB1KmXdjUsbQCHcLfyo8SLk3kL9.xrtqEnMxkUELELttv2gdu V6.deuJpgAqp88CwiOOt3EbXsb3zgb5T4W3C4lG4bL2k69MjkfQ_gTQIrUaKYSofveTyFv1UhMJG LK7jAhYuBeHApmynNKK3QWy3EotsoHEkojGu.1G4QN2kUuMeSVdN7uajmZ1YUYiAqDh0GNdvgFgf XoTz7kFWOXD6oOGe0usErNvyvcT6rbjvGNAGpXYzrshOtkixgdl2S4572tnhVaiDGLVnXRN0_c_M l85Fzr.0pdgqzrDJmSkX0oCGbOegatGA6osjLX5uBSQ0PtfiqKNy3sD1SyLVyAfGqjUOsRMlCwHC x6v_Q87UbxVs1bE3TEk5Xc5G_3ftn8YXhyEGmANRXl5j6zl_rIPwVlHHUT3tK6W2klrAi_bFQfvx yRndIlBTr5jD1qzmwOxpKb8Uo4aNfqEPoWvZ3wMxoXQT3mEP1.pt4EztIGbPzcgYe.lWNHdhNu4H vtroVG_VifpcmkQnKMtCPiToiRH__or1yunFHNnjTmojhJanZdQR1RhRQpaSwltkNMXayoNzXBjT jNjfrxeED9UDRNrHclfmTXV5Qw3sgGrg5efcAq0l4Qdv0S6LNE2.uVvYXw9k6hvkfv1x8OZhJlzw lJExuoV_JGkvnBsbot69U2ET7IO5TxIshBCpO.ANws64lqyxC2KDFVaQaEnu9i912HWIsL6d6N_T czunSflStsala_hQ8HXpBVKI9YSGs.mrazGhfLKh.jnm0QFdqpVRXZeJLTixe1QegNEOmGQkHdA4 nNgO0F7EqY55OBowZI5iJua5eCOlrIT_L7vh6jFH5TxvF8PYD5iVJINy5K.K5jQvOL9m.pEjdxtP xEMJL9K_NA9D9A25yKH1Q2_W.Dl1VjhfJv5vaht86u8VSm4Wiq2XN6D_bcgEkt33a4lSqUFitps2 pO12A1a3QZusQaBbTFEpHBuEepTSRzKq3mEGw4Xpm0XQukpl_fqvP4WJTX_V2bRHqIcesHynkLfu z8GnQdiHt.97olMn3Rhaakrsr5Hbtfh4LUgG5JNpB7VWCtTPzNLeEwGgnl2KzJ6Hm8eAZd2MHtAR DU2TDvmB.naIzgrThqyUvE9bsTUZroRaJwccvTGaLTUjRewb0FDI3JoaHWKld78heFWFzPDIdOVt dcYNczzPwVrB2apPkQ.zaBbYGMjVzW17f7DT1Sh8z3GUJymZxFJ3n3RnKJZPd17EosCMr.dLbjLY .PzbvQmlWUJCU8_3VmRQ6SUdZX8qB_gjP1vDvJKiwJ_prncwzlZK8RQuEtCW6JWaghc9XDwZEtgj ts5Q3EFYoOxsx1DphAx4Si8TbFuz92lZqAAUn1oBVRg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 Dec 2019 22:11:20 +0000 Received: by smtp430.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0efedd7b765ba89c350a766bc76164d1; Mon, 02 Dec 2019 22:11:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: Reverting -current by date. From: Mark Millard In-Reply-To: <20191201213920.GA49395@www.zefox.net> Date: Mon, 2 Dec 2019 14:11:17 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <49C39BF2-0F0A-4D79-831C-89A6F853874B@yahoo.com> References: <20191120233653.GA1475@www.zefox.net> <20191121031141.GB1837@www.zefox.net> <20191121175817.GA5375@www.zefox.net> <20191121190903.GB5375@www.zefox.net> <20191126010310.GA26370@www.zefox.net> <254A5077-DE9E-4B6A-9A4D-D9FA2F858F54@yahoo.com> <20191201213920.GA49395@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47RfTR2LNJz4T16 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.02)[-0.020,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[148.64.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.26)[0.258,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (4.95), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 22:11:24 -0000 On 2019-Dec-1, at 13:39, bob prohaska wrote: > On Mon, Nov 25, 2019 at 05:52:02PM -0800, Mark Millard wrote: >> >> >> >> FYI, one contributor to from-scratch build times might be >> the update to llvm 9: >> >> QUOTE >> Revision 353358 - (view) (download) (annotate) - [select for diffs] >> Modified Wed Oct 9 17:06:56 2019 UTC (6 weeks, 5 days ago) by dim >> File length: 12392 byte(s) >> Diff to previous 353274 >> Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp >> 9.0.0 final release >> r372316 >> . >> >> Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: >> >> >> https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html >> https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html >> https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html >> https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html >> >> >> PR: 240629 >> MFC after: 1 month >> END QUOTE >> >> I do not know if you do anything to limit what is built relative to >> llvm or not. (I do not remember the defaults or the minimums.) >> >> Are your from-scratch rebuilds building both a bootstrap llvm9 and >> the normal llvm9? Or is the existing llvm9 used instead of making >> a bootstrap build of llvm9? >> >> Any llvm8->llvm9 transition will get the bootstrap build of llvm9, >> which then will be used for the later stages. >> > > I think the transition is complete at this point, with clang60 through > clang80 resident in /usr/local/bin and clang9 being default. > > Is there any reason to think clang9 is substantially slower or more > resource-intensive than clang 8? My intended context here was buildworld (and buildkernel), not port building. There can be a big difference here for 2 aspects: A) Building the (ever larger) llvm materials B) General rate at which the llvm tool chain processes things or the sizes for the RAM use It is (A) that I was thinking of: the llvm9 materials to be built may be more time consuming to build. Building llvm materials takes a sizable part of the total buildworld time last I checked. This can be true even if the rates in (B) have improved. (I've no clue if any have.) > if so, that, that would at least > contribute to the difficulties I'm observing (along with tired flash > devices). Last time the machine successfully compiled www/chromium > it took about 3.5 GB of swap at peak. Recent attempts, even with > -j2, are approaching 4 GB and failing with random kernel panics. As for ports (other than llvm* ones) . . . Clearly (B) above is involved but I've no general specifics. I am not aware of a way to set up for port builds that use lld to automatically use --no-threads . (But I've no clue if link-time via lld is one of your large swap usage points --or, if it is, if this would be enough to help.) For buildworld buildkernel there is a way. The binutils ld does not support --no-threads as a command line option last I checked, not even as an ignored compatibility option. Thus adding the option to all link activity is not a working alternative. I do not know if your -j2 is with or without MAKE_JOBS being enabled for some or all jobs. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Dec 2 22:15:32 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EDD381BA431 for ; Mon, 2 Dec 2019 22:15:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.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 47RfZD18ppz4TK5 for ; Mon, 2 Dec 2019 22:15:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: hyXnFU0VM1kClqYGWfPzlQR9oi8RWfm45Qmyi5Qruxzk3KzbenCKbKicoyj9qW5 mPXu0JyBJcZcjWgA8hOoG6.gTDgewYucP3_IdNfB17fDp4teIO5xs8L_nzX.PcoKOlYKOTGHGJPz mAjNEs1IDE.IPiUVp1i1x_J6acfXswW_ZOJDGA7FaHch9Apam9rGRl3IGwWCBf_w4_6W_wG2VYmh sUwwi6ZXcZaQTDEOD98No8iu6knqf.djNm6jWVUosXWKbsAVnu4a2ZubFxRGubwpaUZaFrMaPG72 FWoIAMj42cVJVOUgxJuGDuAqJUphQiwIFfXvF4pClXW70CiOszo9jQyvRe_rwfyHKzxSAqhWuDkp kj3440YwPg1p43AkhvgelluxwqTWYdoKFg8b1alJRsFSNwlxUhY0aQB0bB4ObqqEy5UFxAgT6CGT WtiKs5PzmfIY1eQKzxfbiMST2tZ2zMx6CFvYwBMpfOI6O4xz81W0jkHPSNTUaHwsj6YxyEYTapp4 1nj3I_uKCxBYv17mHZYqQ7pbndPPqSQy7VeZPEz57XtCMpVi5iXJ1SiwjKtaSFtciJwzYqnxtz8b U8efzknxvFwESQq3s5bvqqzX6aohkWct7CeV2lj7wQ5dCzwbMZKFOcAMddSSZso_fXn39lPwJ7I4 YTkUbmpPUgBpLTi52Ohb7EDslpdzgWw.j5cJWgYLeEQfQonE5i7Nz4DpvZCIcOuHZxO_LwNogxU9 uP6Tutde9rn5.wAFwQCtvdEEwdX05V1u5u.X644sBBIRGhKsxHZRxwNR18RRxQUX8cLt8Nja_OGU a.ZFi1lmCUQVbDAZ3sS5l2ZY4mtOoGX4kyphWFD2qB52jVhX.9KtYij0P_.CXWuSxf55BFkSCFuK GQertpMhEd2ChUDvn51lhhr7UPNfDQS5ItfjD4DTj82QPwIe_FvDDmTvWPlKQ3OEGNUgZ78azFz6 ROyaCTEfDSOtAy3y4sPReIeAbKYW9BBa.Cp5AQ5e_ZqK5_n.aiU1EJnurJPXPuGin4FQ9e9xylph lv1UCxlFGimYIcu9U1B9Ro0WqGlkW7RjfhYzIxMNlwe2kcFop3eb.aI2zYuaevGoRSRQ9qb5ECIC UhiVsgqJi..l.LijbOfkNl3C6jJ6VD0UpvzxBQS6c2yepIl.XILxUFYeoi8tudRtvhV6icLI3hiU sNzdqhChk_5G9SAlhcHT899n1CT3MPUuuXD2mkbynp0mr.0.wqFzZfGTDYdwJ_NwSqo5pOLu5Bhg T4vq1RamOjNdaEnfqm6b87HU9GhzzFwaJZ8zwvtdmcfpCcINDi0pbtKlAYFY5ZAGb9.UJegxKuzH ffqsiIxxUJQ.Uouh2l8hgGo7zgHYjkPcxfQVS8nDcVv.0eOB9nUMG70pmxL9oYljxkKStniQVu_W UegRrKTLlLczRAz4XjCg1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 Dec 2019 22:15:30 +0000 Received: by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a95c4a4951f45b3a79db0318a57106be; Mon, 02 Dec 2019 22:15:27 +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 13.0 \(3601.0.10\)) Subject: Comparing the OverDrive 1000 (A57) vs. MACCHIATObin Double Shot (A72) for buildworld and via a CPU/cache/RAM tradeoff-exploring benchmark Message-Id: <92E7B63A-E790-4815-9D91-2161A4F66B71@yahoo.com> Date: Mon, 2 Dec 2019 14:15:26 -0800 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3601.0.10) References: <92E7B63A-E790-4815-9D91-2161A4F66B71.ref@yahoo.com> X-Rspamd-Queue-Id: 47RfZD18ppz4TK5 X-Spamd-Bar: / X-Spamd-Result: default: False [0.05 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.23)[0.226,0]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[148.64.137.98.list.dnswl.org : 127.0.5.0]; MV_CASE(0.50)[]; IP_SCORE(0.00)[ip: (4.70), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_SPAM_LONG(0.33)[0.328,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 22:15:33 -0000 It looks like the OverDrive 1000 vs. MACCHIATObin Double Shot comparison ends up being an example of memory access making the difference for the specific workload: -j4 buildworld for head -r355027 (building itself from scratch). buildworld times (not needing a llvm bootstrap build): OverDrive 1000: 13895 sec (about 3.86 hrs) MACCHIATObin Double Shot: 16561 sec (about 4.60 hrs) So a little under 45 min difference when the mean and geometric mean are both a little over 4.2 hrs. SSD ufs file systems: One with Samsung 860 Pro, the other with Samsung 850 Pro. I do not expect that I/O made much of a difference, but I did nothing to measure such for the buildworld activity. OverDrive RAM: 8GiByte, half in each of the 2 slots MACCHIATObin RAM: 16GiByte, all in its 1 slot. MACCHIATObin: jumpers set for the fastest CPU/RAM speed for the Double Shot. A comparison graph from exploring single threaded and multi-threaded CPU/cache and RAM limited performance (a variation on the old HINT serial and pthread benchmarks) is shown at: = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-OverDrive_1000_MacchDblShot-threads_4-LP64-g%2B%2B_9_8.3_O3-libc%2B%2B= _libstdc%2B%2B-DSIZE_large_fast_types-RAM.gp There are curves for various involved types: double (d), unsigned long long (ull), unsigned long (ul), unsigned int (ui). The match for ull and ul for the context provides some evidence of the variability observed. (The OverDrive and MACCHIATObin were not benchmarked for the graph at the same version of head: -r352341 based vs. -r355027 based.) (I did not set things such that the benchmark run would explore paging getting involved. Thus there is basically no I/O considered in the comparison graph.) The MACCHIATObin clearly wins single threaded and its memory subsystem was well matched to the single threaded use when the same-invovled-types are compared. (Single threaded are the blueish curves, MACCHIATObin having the lighter colors.) For multi-threaded in the range where RAM access limits things, the two systems are a close match. (Greenish colors, right side of plot, upper curves.) The range were the OverDrive 1000 is clearly faster is part of the middle of the multi-threaded curves. (This might be tied to whatever is done with the dual RAM slot structure or to the amount of caching, or some such, I do not know the details.) I would expect "-j1 buildworld" would take less time on the MACCHIATObin than on the OverDrive, but I'm not planing on measuring that. A more historical comparison, old PowerMac11,2 (2 sockets, 2 cores each) vs. the MACCHIATObin, both having 16 GiBytes of RAM: For analogous benchmark graphs (matching types), the MACCHIATObin single threaded is faster than the old PowerMac11,2 single threaded and also is usually faster than that 11,2's multi-threaded benchmark data as well. Multi-threaded, the MACCHIATObin is faster for the exploration by the benchmark. = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-MacchDblShot_PowerMac11%2C2-threads_4-LP64-g%2B%2B_9_O3-libc%2B%2B-DSI= ZE_large_fast_types-RAM.gp I expect that this is interesting for the likely difference in power usage during the benchmarking. (Not that I've measured the power usage.) (The FreeBSD head vintages are not the same in the graph: -r355027 based vs. -r352341 based.) =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 Dec 2 22:31:43 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2DA3B1BA88A for ; Mon, 2 Dec 2019 22:31:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 47Rfwt13krz4Tvk for ; Mon, 2 Dec 2019 22:31:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: u8Nw.8QVM1lpmMhMwGPxhpZ8zFtlV8z0L2AqCnZG0Ox2Tu7vRMmbt0buC2lR46P KXLzvKC7NaLzOh76Ku072Vt8eb4OPvIXmq2ucd.5e0Rz_mzai8LTwgNRLPLuAnsBIRuv_SdtBFaT Mymb4X0eQ7txQqCxf648QMILesDVe2H2OTp2wcLkwAx9DpqxiQE.uL4eR.dHWMIxVjYaT2iz5Pns hj324BgZpH8WZymEDfeImVG.arudqRcdEoyUiojoKvkFkNv1nZEwkwmSflPsq8snv3Clj0ZumUMH Ol2XHQ91hiqd2r2VxtUe.9I0QPGAWdPGFdO6DKfQ_7ddliCGa3prhQVCg1UNyUQu5MRAStOuCAi3 wl2kEOlalVl8Oq05Ov4Pd3GKCAp2SiZ0bjDUnUuDipzVU.pAZJXVHEXbx7JC2gBjXpz2cVsPqQZY usPAB1lHYWftdGJ86ulIfcgxfKF1j3wLyWUieLY7_VxIcBSnZxgriqqhMxoZaDWAYXWMZjIUWKdi bASgQ4ARUp.SVqG9hRI9zIc2gbqu3jI15mQ6iBn7ZT0vg__H007fqefSh7XpiatKcWSGN51oZzmK gdVHCqyGpbAAS1gmbRyQ1kQqRWKjHDp.J2u3oAQHaG1QPA_3A1iWL5vgpYPpOWVduGmt.uw.6L9U ZGdRuaPXD0MvZ9HIDUUyIGl5qVEUBryP.wmy8.Xm1WSlXnH2dGDE9_KreNZffWF03VeQe.UF_LBs YpXjzKROPNESOg7.HQ1nyWDETcfAVQgytYpIjNz.0bdhQJjGrLfB29os9huvQr94gUKmlZoYrWYa ZPD7lPAlN1_socllFw1y7DkKN55SDso.60qiMpe2ZR4J3qy3OFVKfSzg0sLOAn3zrEdC4cmH1exs QYBOecuiyG80MyjkTnBFkAskrQY3tmaXaY6PLlR2dhFOz3AVnAWgmJXsm1uRd5zJjQjpBdRR.htO Z0cnm0jsMoggcyIM2Q4obesqFhTsILNH45icGwp.GxXLkr1vLiduaPojKseeQlIvdJM8Njma0MuW jdrRhEq85WQ1fs_64M7AD8ia_68bw0VlpmvIaHZr_YDp3S2tACrkOTpCxx1NVtbm8SJXwuRBCwDr DZehJBXnKOgNzfGMm2O47jUMbu3VRK4qolxv9QBuD68DTtXIOVgq8XowlrdCPL9BhVH6GfhzsKgl NUhccUdCkmhBTyPZGSZfNJadrG3GuFTVgtYrQsye8wurXjV8nDO8XLNAVrNrpguyzYa7jtT6SdWY mczrzn0TYa7g6RUZMIf1TyiPnGgXtpW35pTq9prtIxyZrGTJWdTitRaod0IPDurvs5dC2CqapPI8 5P2pqvN3SPcjdouu3LBcJeJg90csX6JmwYBTOnThVmiNvJAtvB18jjTCI71NbQOsLCAoiU_HIq3g EVDRSZyO3Y9x7q8z6Z0rR.2E- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 Dec 2019 22:31:39 +0000 Received: by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a4eb31099961f50ea70df737e1a4fcf7; Mon, 02 Dec 2019 22:31:38 +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 13.0 \(3601.0.10\)) Subject: Re: Comparing the OverDrive 1000 (A57) vs. MACCHIATObin Double Shot (A72) for buildworld and via a CPU/cache/RAM tradeoff-exploring benchmark Date: Mon, 2 Dec 2019 14:31:36 -0800 References: <92E7B63A-E790-4815-9D91-2161A4F66B71.ref@yahoo.com> <92E7B63A-E790-4815-9D91-2161A4F66B71@yahoo.com> To: freebsd-arm@freebsd.org In-Reply-To: <92E7B63A-E790-4815-9D91-2161A4F66B71@yahoo.com> Message-Id: <5F7E7618-A503-4D16-B83C-0379F4B6327F@yahoo.com> X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47Rfwt13krz4Tvk X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.29 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.843,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.947,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (0.48), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 22:31:43 -0000 [The links I sent are to the gnuplot .gp files, not to copies of the plots. I've not even uploaded the plots yet. (too distracted today, I guess.) I will later upload .png files and resend with corrected links. Nothing new in this note below.] On 2019-Dec-2, at 14:15, Mark Millard wrote: > It looks like the OverDrive 1000 vs. MACCHIATObin Double > Shot comparison ends up being an example of memory > access making the difference for the specific workload: > -j4 buildworld for head -r355027 (building itself > from scratch). >=20 > buildworld times (not needing a llvm bootstrap build): >=20 > OverDrive 1000: 13895 sec (about 3.86 hrs) > MACCHIATObin Double Shot: 16561 sec (about 4.60 hrs) >=20 > So a little under 45 min difference when the mean > and geometric mean are both a little over 4.2 hrs. >=20 > SSD ufs file systems: One with Samsung 860 Pro, the > other with Samsung 850 Pro. I do not expect that I/O > made much of a difference, but I did nothing to measure > such for the buildworld activity. >=20 > OverDrive RAM: 8GiByte, half in each of the 2 slots > MACCHIATObin RAM: 16GiByte, all in its 1 slot. >=20 > MACCHIATObin: jumpers set for the fastest CPU/RAM > speed for the Double Shot. >=20 > A comparison graph from exploring single threaded > and multi-threaded CPU/cache and RAM limited > performance (a variation on the old HINT serial > and pthread benchmarks) is shown at: >=20 > = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-OverDrive_1000_MacchDblShot-threads_4-LP64-g%2B%2B_9_8.3_O3-libc%2B%2B= _libstdc%2B%2B-DSIZE_large_fast_types-RAM.gp >=20 > There are curves for various involved types: > double (d), unsigned long long (ull), unsigned > long (ul), unsigned int (ui). The match for > ull and ul for the context provides some > evidence of the variability observed. >=20 > (The OverDrive and MACCHIATObin were not benchmarked > for the graph at the same version of head: -r352341 > based vs. -r355027 based.) >=20 > (I did not set things such that the benchmark run > would explore paging getting involved. Thus there > is basically no I/O considered in the comparison > graph.) >=20 > The MACCHIATObin clearly wins single threaded and > its memory subsystem was well matched to the single > threaded use when the same-invovled-types are > compared. (Single threaded are the blueish curves, > MACCHIATObin having the lighter colors.) >=20 > For multi-threaded in the range where RAM access > limits things, the two systems are a close match. > (Greenish colors, right side of plot, upper > curves.) >=20 > The range were the OverDrive 1000 is clearly faster > is part of the middle of the multi-threaded curves. > (This might be tied to whatever is done with the > dual RAM slot structure or to the amount of caching, > or some such, I do not know the details.) >=20 > I would expect "-j1 buildworld" would take less time > on the MACCHIATObin than on the OverDrive, but I'm > not planing on measuring that. >=20 >=20 >=20 > A more historical comparison, old PowerMac11,2 > (2 sockets, 2 cores each) vs. the MACCHIATObin, > both having 16 GiBytes of RAM: >=20 > For analogous benchmark graphs (matching types), > the MACCHIATObin single threaded is faster than > the old PowerMac11,2 single threaded and also is > usually faster than that 11,2's multi-threaded > benchmark data as well. Multi-threaded, the > MACCHIATObin is faster for the exploration by > the benchmark. >=20 > = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-MacchDblShot_PowerMac11%2C2-threads_4-LP64-g%2B%2B_9_O3-libc%2B%2B-DSI= ZE_large_fast_types-RAM.gp >=20 > I expect that this is interesting for the likely > difference in power usage during the benchmarking. > (Not that I've measured the power usage.) >=20 > (The FreeBSD head vintages are not the same in > the graph: -r355027 based vs. -r352341 based.) >=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 Dec 2 22:40:53 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2146B1BAE60 for ; Mon, 2 Dec 2019 22:40:53 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (flets-sg1026.kamome.or.jp [202.216.24.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rg7R3Dcwz4VYc for ; Mon, 2 Dec 2019 22:40:50 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [202.216.24.26]) by kx.truefc.org (8.15.2/8.15.2) with ESMTP id xB2Mekq0016285; Tue, 3 Dec 2019 07:40:47 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <201912022240.xB2Mekq0016285@kx.truefc.org> Date: Tue, 03 Dec 2019 07:40:46 +0900 From: KIRIYAMA Kazuhiko To: "freebsd-arm@freebsd.org" Subject: Can't boot arm64 image by qemu-system-aarch64 User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 47Rg7R3Dcwz4VYc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of kiri@truefc.org has no SPF policy when checking 202.216.24.26) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-0.50 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.907,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.70)[-0.699,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[truefc.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4704, ipnet:202.216.0.0/19, country:JP]; IP_SCORE(0.00)[country: JP(0.02)]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 22:40:53 -0000 Hi, all # I've posted freebsd-virtualization,but any responces. # Sorry for same posting. I've installed successfully by qemu-system-aarch64 below: root@vm:/vm/test # truncate -s 16g test.img root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu cortex-a57 -name test -bios QEMU_EFI.fd -nographic -hda test.img -hdc FreeBSD-13.0-CURRENT-arm64-aarch64-20191127-r355121-memstick.img and rebooted successfully and login with root: root@test:~ # uname -a FreeBSD test.tfc 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355121: Wed Nov 27 03:49:21 UTC 2019 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 root@test:~ # df -h Filesystem Size Used Avail Capacity Mounted on /dev/vtbd0p2 14G 1.3G 12G 10% / devfs 1.0K 1.0K 0B 100% /dev root@test:~ # ifconfig vtnet0: flags=8843 metric 0 mtu 1500 options=80028 ether 52:54:00:12:34:56 inet 192.168.1.196 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet 10Gbase-T status: active nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 root@test:~ # So, I shutdowned and run by qemu-system-aarch64: root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu cortex-a57 -name test -bios QEMU_EFI.fd -nographic -drive if=none,format=raw,file=test.img,id=hd0 -device virtio-blk-device,drive=hd0 -device virtio-net-device,netdev=net0 -netdev tap,id=net0,ifname=tap2 But failed to boot: BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Found >>Start PXE over IPv4. where, tap2 is ready to use: root@vm:/vm/test # ifconfig tap2 tap2: flags=8902 metric 0 mtu 1500 description: vmnet-test-0-local options=80000 ether 58:9c:fc:10:ec:02 groups: tap qemu-port media: Ethernet autoselect status: no carrier nd6 options=21 root@vm:/vm/test # What's wrong ? Best regards. --- Kiriyama Kazuhiko From owner-freebsd-arm@freebsd.org Mon Dec 2 22:56:35 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4F5531BB5F3 for ; Mon, 2 Dec 2019 22:56:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.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 47RgTY3Bpyz4WZ1 for ; Mon, 2 Dec 2019 22:56:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VCy9fuoVM1mSvhcF2RI5L.nsGKbsxjRu6hx25rWGnHnlbMH6vuHfOd3EZPqTbyn 2ENO7xdZ9_3dYpfLl0.BG7Q0f9Yl_cH3rPE4tbj9Y9dadZRyYRZhniZOOrdherVyUawQR6ildHWP m1KECo8fE_etwIsC1Ie3kgIhEHw05k1DkfxUlX6QM1JByozDBYnHnQr34fn2t7yn5fcUDmnT8g6I GB2hF2lRsH.I0UZukdjItXzuNS1iAAUKO98OCqwIzVdXLIPvC5Tmq55mB1Pa4nZz_1CKXY7Mxug4 fWpB.0w.d8B6sQnb3gkX1sn37AYrQxgWSnZ3aafaoOk.SCdGMoPftNNkT6TgdalNkZ7hMPJs7YIu AJ56kHUlFs.X4nZOpsVNMLt17.nMKqMYMiPRC3TzNvnqn3ohwrSDg3ZUJ2wRuw2oYSeo5jHf0htP EQRNGzCBa26rq.NU0dyZStzVZ.6VaaavQ8NKi0XXMx.TkPoNgjFPAFZGBZTjQih2WfpawcseSvsp q9ryf_KoUTfR.c8UdkzyVmIIi7hneMMSVizrdl5NzJFcuw1.96CFVA2tVDdcPwZ3K0wPAjL31fOf lTVbthXsGKZlbEOjwv47JA95hKTz6d8IyPudNx0ji0yZmFQjobq4IeSY.W1r5.DNrF55OiSZoTMe Krfi4anLAJhwsqNzFFEQ4Y.ndpOZL_d2kdcglTNboN7f.5ZRLh9gf_gtuzlUc.jGtd46CuPCugIR ai.G5Y9eREyMAkxEaNuJ62_ahlo1TtJQrA8C.Ntyb6sxxPO59MCZzkCqmWZ98Nmn2cdi8LnXYfYt 3c_IkIwuCAz_nY0G0gnSPFGpjEylLwFdneIv4ddEK4NgD9vkYzP1O2pinHxbDvz0PkNEED.z_Zr0 HB4GgyaOsJ.FbPR7LrFGp1B49cGunt233IvM6N9XqgU5N_smGVijkarh3ssrFXU.LWbBzaSV7dWh VMB0gRJacksdRLcL1bTd4_ihFQ87gSfGnwunIfZpzOC94IrMogrnvju9NNqaT0YfxTpy8CsvuIWz 1oKhgYQMiJ3yacxv7XDKh6RPOZ0DiJhBwVVVXetXSmsRZvC2tHtbDrVA.TRiC8Cq7lK11OG8TuXe 0luEoQvs4RxAImQC4sJXfIEjdMGpx1TvoRkO5_O0SEhylxNCIssYJMrqjyu4H2b1jf6UH8R5hdSx GPLOgdKQgJcFnBi.om7U2xYWONAq5qYUQy0ucIOFGWVhZPRyy0F5mk0Y_WDQfGDFlYI.xR_QkkM9 i71bDh46hQy41ajoISDO9.d4xfl_ri_ow7gF0_ORUgs14xEMIXJP6QH3yL5Me16oE0heToQRD14U SRdROXU.FQv.lCW3CYxw.c0PWqThbFl8I0W09kXtMcESGiEkxTIi7qYHEhTNtYDx.J57AclP.nlO 92N5uFmv6Po6xfc5OugxYgQg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 Dec 2019 22:56:30 +0000 Received: by smtp416.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8272d2249384b91c51b71e3d0ace3587; Mon, 02 Dec 2019 22:56:26 +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 13.0 \(3601.0.10\)) Subject: Re: Comparing the OverDrive 1000 (A57) vs. MACCHIATObin Double Shot (A72) for buildworld and via a CPU/cache/RAM tradeoff-exploring benchmark (links corrected) Date: Mon, 2 Dec 2019 14:56:25 -0800 References: <92E7B63A-E790-4815-9D91-2161A4F66B71.ref@yahoo.com> <92E7B63A-E790-4815-9D91-2161A4F66B71@yahoo.com> <5F7E7618-A503-4D16-B83C-0379F4B6327F@yahoo.com> To: freebsd-arm@freebsd.org In-Reply-To: <5F7E7618-A503-4D16-B83C-0379F4B6327F@yahoo.com> Message-Id: <63787F5A-A3B7-434A-B594-999D95559BEE@yahoo.com> X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47RgTY3Bpyz4WZ1 X-Spamd-Bar: / X-Spamd-Result: default: False [0.65 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.49)[0.493,0]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[147.66.137.98.list.dnswl.org : 127.0.5.0]; MV_CASE(0.50)[]; IP_SCORE(0.00)[ip: (7.39), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_SPAM_LONG(0.66)[0.660,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 22:56:35 -0000 [Just correcting the links to be to .png files and correcting some PowerMac11,2 related wording.] On 2019-Dec-2, at 14:15, Mark Millard wrote: > It looks like the OverDrive 1000 vs. MACCHIATObin Double > Shot comparison ends up being an example of memory > access making the difference for the specific workload: > -j4 buildworld for head -r355027 (building itself > from scratch). >=20 > buildworld times (not needing a llvm bootstrap build): >=20 > OverDrive 1000: 13895 sec (about 3.86 hrs) > MACCHIATObin Double Shot: 16561 sec (about 4.60 hrs) >=20 > So a little under 45 min difference when the mean > and geometric mean are both a little over 4.2 hrs. >=20 > SSD ufs file systems: One with Samsung 860 Pro, the > other with Samsung 850 Pro. I do not expect that I/O > made much of a difference, but I did nothing to measure > such for the buildworld activity. >=20 > OverDrive RAM: 8GiByte, half in each of the 2 slots > MACCHIATObin RAM: 16GiByte, all in its 1 slot. >=20 > MACCHIATObin: jumpers set for the fastest CPU/RAM > speed for the Double Shot. >=20 > A comparison graph from exploring single threaded > and multi-threaded CPU/cache and RAM limited > performance (a variation on the old HINT serial > and pthread benchmarks) is shown at: Corrected link: = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-OverDrive_1000_MacchDblShot-threads_4-LP64-g%2B%2B_9_8.3_O3-libc%2B%2B= _libstdc%2B%2B-DSIZE_large_fast_types-RAM.png > There are curves for various involved types: > double (d), unsigned long long (ull), unsigned > long (ul), unsigned int (ui). The match for > ull and ul for the context provides some > evidence of the variability observed. >=20 > (The OverDrive and MACCHIATObin were not benchmarked > for the graph at the same version of head: -r352341 > based vs. -r355027 based.) >=20 > (I did not set things such that the benchmark run > would explore paging getting involved. Thus there > is basically no I/O considered in the comparison > graph.) >=20 > The MACCHIATObin clearly wins single threaded and > its memory subsystem was well matched to the single > threaded use when the same-invovled-types are > compared. (Single threaded are the blueish curves, > MACCHIATObin having the lighter colors.) >=20 > For multi-threaded in the range where RAM access > limits things, the two systems are a close match. > (Greenish colors, right side of plot, upper > curves.) >=20 > The range were the OverDrive 1000 is clearly faster > is part of the middle of the multi-threaded curves. > (This might be tied to whatever is done with the > dual RAM slot structure or to the amount of caching, > or some such, I do not know the details.) >=20 > I would expect "-j1 buildworld" would take less time > on the MACCHIATObin than on the OverDrive, but I'm > not planing on measuring that. >=20 >=20 >=20 > A more historical comparison, old PowerMac11,2 > (2 sockets, 2 cores each) vs. the MACCHIATObin, > both having 16 GiBytes of RAM: >=20 > For analogous benchmark graphs (matching types), > the MACCHIATObin single threaded is faster than > the old PowerMac11,2 single threaded and also is > usually faster than that 11,2's multi-threaded > benchmark data as well. I should have pointed out that the MACCHIATObin single threaded and PowerMac11,2 multi-threaded results are similar where memory access limits things, with use of double (d) being a little slower on the MACCHIATObin in this region. > Multi-threaded, the > MACCHIATObin is faster for the exploration by > the benchmark. Corrected link: = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-MacchDblShot_PowerMac11%2C2-threads_4-LP64-g%2B%2B_9_O3-libc%2B%2B-DSI= ZE_large_fast_types-RAM.png > I expect that this is interesting for the likely > difference in power usage during the benchmarking. > (Not that I've measured the power usage.) >=20 > (The FreeBSD head vintages are not the same in > the graph: -r355027 based vs. -r352341 based.) >=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 Dec 2 23:07:17 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 129001BB9C9 for ; Mon, 2 Dec 2019 23:07:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 47Rgjw0MxRz4X43 for ; Mon, 2 Dec 2019 23:07:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1ZBRW_4VM1l5HNZSLoMZQgvhCTBIcw3wcry90h7BxQZyKtvz.CObVodQsJoUT1_ ZXD6h761v.Z1dldDCoGo0hTBDgcF.PudFUOvM1pRBi4gU4RuhjyReB9rooxJ3_feD_NyLWHdSXxj _m.YBPUFwNmGYIYJYRuxwNhTegfZTQUzOdhRHvtdCWYLcR1VzUM0yZv6ggpuv3Mnw6afWblPN6Tm ZZyQlw84XBcHn.0rirUHtQ0OV6kbrJz4gzsQ3vMhf2wfXJ4DgSMliKwqxCWawnK5CrXm2vgqCfnk Leht5gfk4s8zZ5Nbwch8YAXKTMShNB.OLyFF14L1FBKUuJv8A1J1npfFqdphlnTMvYSmnHlgtwcw Gl1n4ekcPbSh_A5fo7Y3rtwFCrlAKAlgGUdURqrfgbx2j1fmpFoRZ_6YBB5l1YLhZ6WNoWFXnJF3 fMipIyDzoI7rXTY_kz9WQCZFEH6.8FNr8iSd2ngSq1y.JAct4K.ALVmj5_Tv2VPxMIXZ9IEb9J3o 9xe9xvOujdQC8hkSKU1KWNTvkeEdZKBs2xrS7mzSTMV3I68BOJi_ATWGIMafrZNlRgQlDpuKQ2vs UonenhSwpuUQCdtAuuq7BmAqJwcScaZces.D0xD4abkWi8ZkZmms4l_AXZx6DsQWZGCwtzuArDdT NGmD773aCIp4sZ9Hq.aECqikIZ4w4.dqJHGVg4RQEIQOdapwzp47xewLKpwj8xcCUoO1NNYlzt7B Q72694uFT9bcBVy9_h4OL6kKpvBtcTgFwM_hbDb9pBgY7aS2bT9svspaVK_ZXS1oBlB8vlGNb3nF w7kS50mpovlOE534IlNjsi_pa4x6pDM.AiVCiaWVrLPtOSCYUhEQ9a7bWh9BPjTe78cpnSgKZ3EX TFnE31rJcrqQ5VnGzU1tAZyZ1GPwS.UYLIcEL46iPGRPht8BXXJuGq3zmYf.L0LtB3gxpzzODOnL ms99MsbYmu4gIhZPkDuHsyh6OJR0QkikVf.SMEf6ma2hiBLTP501Y_tVqyJ43oerlGI.Y1SNTEmn N5TCwWc67KRoEf.goQ8ZhPYg8aO32zZOFCJ39qzNAWWCZ_AR7SsJyq5fkVQrUf7EM.UkO9zTL.tU ZHZfcPV2s6rznNZv7v2pWbID.cd5n7H4ZDeQ18jooTooxqkFHpITXl4MgiDGfzgXv5JwJcqfgTTU A87J7UEvyL3zk3nc7BF5b0gj.EQUv04oHPkxrGzThB.tHMAx2XEDwXXv8zsNGYhEglzcfBCKt3kh 2Ykp6nDGo805yw_psLL5ZiUE3vq7jBZmgC2yOYFDZ6m5eRv9vFaJq3kZeM1gYI2zvbFFzwVr1PYg BuiIHCZraktgyem..bH0FH4aBz8KHanjAYvxcUyEi735EuQQq2c7l62Dvh6dcKZVyJAjKf8S5oYy kiCga4ss_RiBAIlVgXMgV Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 Dec 2019 23:07:14 +0000 Received: by smtp416.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ba5e6e1d90896c429b3283c62bd8124d; Mon, 02 Dec 2019 23:07:00 +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 13.0 \(3601.0.10\)) Subject: Re: Comparing the OverDrive 1000 (A57) vs. MACCHIATObin Double Shot (A72) for buildworld and via a CPU/cache/RAM tradeoff-exploring benchmark (links corrected, again) Date: Mon, 2 Dec 2019 15:07:00 -0800 References: <92E7B63A-E790-4815-9D91-2161A4F66B71.ref@yahoo.com> <92E7B63A-E790-4815-9D91-2161A4F66B71@yahoo.com> <5F7E7618-A503-4D16-B83C-0379F4B6327F@yahoo.com> <63787F5A-A3B7-434A-B594-999D95559BEE@yahoo.com> To: freebsd-arm@freebsd.org In-Reply-To: <63787F5A-A3B7-434A-B594-999D95559BEE@yahoo.com> Message-Id: <8E3A0E01-F22D-4635-A8CF-CDB98CFF9794@yahoo.com> X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47Rgjw0MxRz4X43 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.62 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.05)[-0.050,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.07)[-0.070,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[206.64.137.98.list.dnswl.org : 127.0.5.0]; MV_CASE(0.50)[]; IP_SCORE(0.00)[ip: (3.42), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 23:07:17 -0000 [May be this time I'll get working links in place . . .] On 2019-Dec-2, at 14:56, Mark Millard wrote: > [Just correcting the links to be to .png files > and correcting some PowerMac11,2 related wording.] >=20 > On 2019-Dec-2, at 14:15, Mark Millard wrote: >=20 >> It looks like the OverDrive 1000 vs. MACCHIATObin Double >> Shot comparison ends up being an example of memory >> access making the difference for the specific workload: >> -j4 buildworld for head -r355027 (building itself >> from scratch). >>=20 >> buildworld times (not needing a llvm bootstrap build): >>=20 >> OverDrive 1000: 13895 sec (about 3.86 hrs) >> MACCHIATObin Double Shot: 16561 sec (about 4.60 hrs) >>=20 >> So a little under 45 min difference when the mean >> and geometric mean are both a little over 4.2 hrs. >>=20 >> SSD ufs file systems: One with Samsung 860 Pro, the >> other with Samsung 850 Pro. I do not expect that I/O >> made much of a difference, but I did nothing to measure >> such for the buildworld activity. >>=20 >> OverDrive RAM: 8GiByte, half in each of the 2 slots >> MACCHIATObin RAM: 16GiByte, all in its 1 slot. >>=20 >> MACCHIATObin: jumpers set for the fastest CPU/RAM >> speed for the Double Shot. >>=20 >> A comparison graph from exploring single threaded >> and multi-threaded CPU/cache and RAM limited >> performance (a variation on the old HINT serial >> and pthread benchmarks) is shown at: Corrected link (2nd try): = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-OverDrive_1000_MacchDblShot-threads_4-LP64-g%2B%2B_9_O3-libc%2B%2B-DSI= ZE_large_fast_types-RAM.png >> There are curves for various involved types: >> double (d), unsigned long long (ull), unsigned >> long (ul), unsigned int (ui). The match for >> ull and ul for the context provides some >> evidence of the variability observed. >>=20 >> (The OverDrive and MACCHIATObin were not benchmarked >> for the graph at the same version of head: -r352341 >> based vs. -r355027 based.) >>=20 >> (I did not set things such that the benchmark run >> would explore paging getting involved. Thus there >> is basically no I/O considered in the comparison >> graph.) >>=20 >> The MACCHIATObin clearly wins single threaded and >> its memory subsystem was well matched to the single >> threaded use when the same-invovled-types are >> compared. (Single threaded are the blueish curves, >> MACCHIATObin having the lighter colors.) >>=20 >> For multi-threaded in the range where RAM access >> limits things, the two systems are a close match. >> (Greenish colors, right side of plot, upper >> curves.) >>=20 >> The range were the OverDrive 1000 is clearly faster >> is part of the middle of the multi-threaded curves. >> (This might be tied to whatever is done with the >> dual RAM slot structure or to the amount of caching, >> or some such, I do not know the details.) >>=20 >> I would expect "-j1 buildworld" would take less time >> on the MACCHIATObin than on the OverDrive, but I'm >> not planing on measuring that. >>=20 >>=20 >>=20 >> A more historical comparison, old PowerMac11,2 >> (2 sockets, 2 cores each) vs. the MACCHIATObin, >> both having 16 GiBytes of RAM: >>=20 >> For analogous benchmark graphs (matching types), >> the MACCHIATObin single threaded is faster than >> the old PowerMac11,2 single threaded and also is >> usually faster than that 11,2's multi-threaded >> benchmark data as well. >=20 > I should have pointed out that the MACCHIATObin > single threaded and PowerMac11,2 multi-threaded > results are similar where memory access limits > things, with use of double (d) being a little > slower on the MACCHIATObin in this region. >=20 >> Multi-threaded, the >> MACCHIATObin is faster for the exploration by >> the benchmark. >=20 Corrected link (2nd try): = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-MacchDblShot_PowerMac11%2C2-threads_4-LP64-g%2B%2B_9_O3-libc%2B%2B-DSI= ZE_large_fast_types-RAM.png >> I expect that this is interesting for the likely >> difference in power usage during the benchmarking. >> (Not that I've measured the power usage.) >>=20 >> (The FreeBSD head vintages are not the same in >> the graph: -r355027 based vs. -r352341 based.) >>=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 Tue Dec 3 00:05:07 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFB231BCBC9 for ; Tue, 3 Dec 2019 00:05:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rj0g2Bz4z4Z4v for ; Tue, 3 Dec 2019 00:05:07 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1575331505; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=khrMpYCFNdrIM8lf3NaZuJjnMCzEFcRCK7MFF/ZX15cuc39UXsvZ1tKQRbEHipTqgpVnDfYdNd8sz qt9VHuxDlHJ/SWwMWUC63uVqLQHnoXOD8G+Xb3HA4GStJwXEqSJZzV7htPKp4HOXhOt5ivOEjJN8QY 0cFMiuaxx8ItUDqwlTd6tjEkT6gDhKS1/ew8Moo+BM+nku6vSBS8MU4N7jw9ne8HjJ+IktlncjTEX+ Dn0EfPQCHj+Iys8aQf0R5nwPU9FxScRqjVBb4AtEcsNmr3XcZtcrY9k86uoyTXKR5dpk0U5SB3JBmD AuCng6CfMPZeP4cTqaSAIn7Cp9rJ8Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=mime-version:content-type:references:in-reply-to:date:cc:to:from:subject: message-id:dkim-signature:from; bh=wzgFVCXFuS1yjKT+2q+2Tw/kBMZxsI6O4WnNcIjgawM=; b=iY9rSx0pkQ+R3XRhqAgR3+4VFSkXTiSj/lNEttV8TdY1cQ9+fR/jWU9kXH7abttYARdcwGC7wZMvs PpB3hffaWqOTLAcKmzLjosjyQDGvMMIrApuChu8KjnBjK/mLM2MXCiftW7gHztfMuRs1boEItjqxgt pTiJ0BXp21NlPnNnqIcFZPAPvK+dniyvAg9lSjnjEOVxIVSG2pPe3mMPMQsweabGo4+SWM+elH+Byq Q8n24h4+2N6j27o91+cbFOyMKW+PwyH9ftxRAJaTmzMPbR8vJgbG6K+nxU/bqgMzPvr/bnc1ATx7Cj RBYgby2GnG1nyNK6Y0ycXHhX2jqMc+Q== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=mime-version:content-type:references:in-reply-to:date:cc:to:from:subject: message-id:from; bh=wzgFVCXFuS1yjKT+2q+2Tw/kBMZxsI6O4WnNcIjgawM=; b=agdvMPf/onQorev2X0700g7VnbqLMFQrYWq1DwQzmLQjXZQShKofizJx9M1TP+FeSz4hPx3b7iatA Metouu9TnF3TtzkqcliiY50cvN0Nb7O7KHYZVXxMdzkxgc4hngepS4RmpaDGtXQdoKmrhmYkg4cfh6 mrPkHSQ+X8NpT768wAf3pwiSDlklRY0w54CpGdeKmeZ0OToZcNrcTtxxCi+RPxRF1K8BHU4n7STAa3 0AA+jUmIElGCkEwtCTj5LeUaNE+D/eZHBorgeEPamR3GINJwknVgneSVgGMCopZrqjT5Pe2YAnzzWv /c/oG+PchhV30YXU6tk4HZoP8+WhklA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 8bf70368-1560-11ea-b80c-052b4a66b6b2 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 outbound3.ore.mailhop.org (Halon) with ESMTPSA id 8bf70368-1560-11ea-b80c-052b4a66b6b2; Tue, 03 Dec 2019 00:05:03 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id xB304wMU097597; Mon, 2 Dec 2019 17:04:59 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: gpioiic FDT overlays for sun8i-h3 From: Ian Lepore To: Nick Kostirya Cc: Milan Obuch , freebsd-arm@freebsd.org Date: Mon, 02 Dec 2019 17:04:58 -0700 In-Reply-To: <20191129201244.0bc85b09@thinkpad> References: <20191128152901.39dbeb4d@thinkpad> <20191128062149.577be86eb7dc15ae5805f31a@bidouilliste.com> <20191129153754.28fb5763@thinkpad> <20191129144316.739c8664@zeta.dino.sk> <20191129155431.05d4e14f@thinkpad> <20191129150944.67a2b723a6724c46f7559f96@bidouilliste.com> <0ce78262af1dd3b404b9a85a780933d7e11f008e.camel@freebsd.org> <20191129201244.0bc85b09@thinkpad> Content-Type: multipart/mixed; boundary="=-MzQpjdwgpxxGsx/on2aO" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 X-Rspamd-Queue-Id: 47Rj0g2Bz4z4Z4v X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.83 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.94)[-0.937,0]; NEURAL_HAM_LONG(-0.89)[-0.891,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 00:05:07 -0000 --=-MzQpjdwgpxxGsx/on2aO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2019-11-29 at 20:12 +0200, Nick Kostirya via freebsd-arm wrote: > On Fri, 29 Nov 2019 09:23:31 -0700 > Ian Lepore wrote: > > > [...] > > > > I am working on this, though. I'm thinking we should have something > > usable later today, or at worst by the end of the weekend if it turns > > complicated. > > > > -- Ian > > Thank you very match!!! > > I hope the new driver can be used in FreeBSD 12. > > Well, it did turn complicated, but I got it all worked out. Are you building an image from source code, or using a downloaded snapshot or release image, or what? If you are building from source, apply the attached patch to your source tree and rebuild the kernel. If you are using a prebuilt image, then I'll get these changes merged to the stable-12 tree this week, and the next stable-12 snapshot images will include what you need. I think those images get built every Thursday. -- Ian --=-MzQpjdwgpxxGsx/on2aO Content-Disposition: attachment; filename="gpioiic_for_stable-12.diff" Content-Type: text/x-patch; name="gpioiic_for_stable-12.diff"; charset="UTF-8" Content-Transfer-Encoding: base64 SW5kZXg6IHNoYXJlL21hbi9tYW40L2dwaW9paWMuNAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tYW4v bWFuNC9ncGlvaWljLjQJKHJldmlzaW9uIDM1NTMxNSkKKysrIHNoYXJlL21hbi9tYW40L2dwaW9p aWMuNAkod29ya2luZyBjb3B5KQpAQCAtMjQsNyArMjQsNyBAQAogLlwiCiAuXCIgJEZyZWVCU0Qk CiAuXCIKLS5EZCBNYXkgMTQsIDIwMTQKKy5EZCBEZWNlbWJlciAxLCAyMDE5CiAuRHQgR1BJT0lJ QyA0CiAuT3MKIC5TaCBOQU1FCkBAIC0zNywzMSArMzcsMzUgQEAga2VybmVsIGNvbmZpZ3VyYXRp b24gZmlsZToKIC5CZCAtcmFnZ2VkIC1vZmZzZXQgaW5kZW50CiAuQ2QgImRldmljZSBncGlvIgog LkNkICJkZXZpY2UgZ3Bpb2lpYyIKLS5DZCAiZGV2aWNlIGlpYyIKIC5DZCAiZGV2aWNlIGlpY2Ji IgogLkNkICJkZXZpY2UgaWljYnVzIgogLkVkCisuUHAKK0FsdGVybmF0aXZlbHksIHRvIGxvYWQg dGhlIGRyaXZlciBhcyBhCittb2R1bGUgYXQgYm9vdCB0aW1lLCBwbGFjZSB0aGUgZm9sbG93aW5n IGxpbmUgaW4KKy5YciBsb2FkZXIuY29uZiA1IDoKKy5CZCAtbGl0ZXJhbCAtb2Zmc2V0IGluZGVu dAorZ3Bpb2lpY19sb2FkPSJZRVMiCisuRWQKIC5TaCBERVNDUklQVElPTgogVGhlCiAuTm0KIGRy aXZlciBwcm92aWRlcyBhbiBJSUMgYml0LWJhbmdpbmcgaW50ZXJmYWNlIHVzaW5nIHR3byBHUElP IHBpbnMgZm9yIHRoZQotU0NMIGFuZCBTREEgb24gdGhlCi0uTm0gZ3Bpb2J1cyAuCitTQ0wgYW5k IFNEQSBsaW5lcyBvbiB0aGUgYnVzLgorLlBwCiAuTm0KLWltcGxlbWVudHMgYW4gb3BlbiBjb2xs ZWN0b3Iga2luZCBvZiBvdXRwdXQsIGFzIHJlY29tbWVuZGVkIGJ5IHRoZSBzdGFuZGFyZCwKLXdo ZW4gZHJpdmluZyB0aGUgcGlucyBvbiB0aGUKLS5ObSBncGlvYnVzICwKLWkuZSwgdGhleSBhcmUg bmV2ZXIgc3dpdGNoZWQgdG8gdGhlIGxvZ2ljYWwgdmFsdWUgb2YgJzEnLAotb3IgdGhleSBhcmUg JzAnIG9yIHNpbXBseSBvcGVuIChIaS1aL3RyaS1zdGF0ZSkuCi1TbyB0aGUgcHVsbHVwIHJlc2lz dG9ycyBhcmUgcmVxdWlyZWQgc28KLS5ObQotY2FuIHdvcmsuCitzaW11bGF0ZXMgYW4gb3BlbiBj b2xsZWN0b3Iga2luZCBvZiBvdXRwdXQgd2hlbiBtYW5hZ2luZyB0aGUgcGlucyBvbiB0aGUKK2J1 cywgZXZlbiBvbiBzeXN0ZW1zIHdoaWNoIGRvbid0IGRpcmVjdGx5IHN1cHBvcnQgY29uZmlndXJp bmcgZ3BpbyBwaW5zCitpbiB0aGF0IG1vZGUuCitUaGUgcGlucyBhcmUgbmV2ZXIgZHJpdmVuIHRv IHRoZSBsb2dpY2FsIHZhbHVlIG9mICcxJy4KK1RoZXkgYXJlIGRyaXZlbiB0byAnMCcgb3Igc3dp dGNoZWQgdG8gaW5wdXQgbW9kZSAoSGktWi90cmktc3RhdGUpLCBhbmQKK2FuIGV4dGVybmFsIHB1 bGx1cCByZXNpc3RvciBwdWxscyB0aGUgbGluZSB0byB0aGUgMSBzdGF0ZSB1bmxlc3Mgc29tZQor b3RoZXIgZGV2aWNlIG9uIHRoZSBidXMgaXMgZHJpdmluZyBpdCB0byAwLgogLlBwCisuU2ggSElO VFMgQ09ORklHVVJBVElPTgogT24gYQogLlhyIGRldmljZS5oaW50cyA1Ci1iYXNlZCBzeXN0ZW0s IGxpa2UKLS5MaSBNSVBTICwKLXRoZXNlIHZhbHVlcyBhcmUgY29uZmlndXJhYmxlIGZvciB0aGUK K2Jhc2VkIHN5c3RlbSwgc3VjaCBhcyBNSVBTLCB0aGVzZSB2YWx1ZXMgYXJlIGNvbmZpZ3VyYWJs ZSBmb3IKIC5ObSA6CiAuQmwgLXRhZyAtd2lkdGggIi5WYSBoaW50LmdwaW9paWMuJWQuYXRYWFgi CiAuSXQgVmEgaGludC5ncGlvaWljLiVkLmF0CkBAIC02OCw3ICs3Miw3IEBAIE9uIGEKIFRoZQog Lk5tIGdwaW9idXMKIHlvdSBhcmUgYXR0YWNoaW5nIHRvLgotTm9ybWFsbHkganVzdCBncGlvYnVz MC4KK05vcm1hbGx5IGp1c3QgZ3Bpb2J1czAgb24gc3lzdGVtcyB3aXRoIGEgc2luZ2xlIGJhbmsg b2YgZ3BpbyBwaW5zLgogLkl0IFZhIGhpbnQuZ3Bpb2lpYy4lZC5waW5zCiBUaGlzIGlzIGEgYml0 bWFzayBvZiB0aGUgcGlucyBvbiB0aGUKIC5ObSBncGlvYnVzCkBAIC03OCw2ICs4Miw5IEBAIFRv IGNvbmZpZ3VyZSBwaW4gMCBhbmQgNywgdXNlIHRoZSBiaXRtYXNrIG9mCiAwYjEwMDAwMDAxIGFu ZCBjb252ZXJ0IGl0IHRvIGEgaGV4YWRlY2ltYWwgdmFsdWUgb2YgMHgwMDgxLgogUGxlYXNlIG5v dGUgdGhhdCB0aGlzIG1hc2sgc2hvdWxkIG9ubHkgZXZlciBoYXZlIHR3byBiaXRzIHNldAogKGFu eSBvdGhlciBiaXRzIC0gaS5lLiwgcGlucyAtIHdpbGwgYmUgaWdub3JlZCkuCitCZWNhdXNlCisu Tm0KK211c3QgYmUgYSBjaGlsZCBvZiB0aGUgZ3Bpb2J1cywgYm90aCBncGlvIHBpbnMgbXVzdCBi ZSBwYXJ0IG9mIHRoYXQgYnVzLgogLkl0IFZhIGhpbnQuZ3Bpb2lpYy4lZC5zY2wKIEluZGljYXRl cyB3aGljaCBiaXQgaW4gdGhlCiAuVmEgaGludC5ncGlvaWljLiVkLnBpbnMKQEAgLTkxLDM1ICs5 OCwzMiBAQCBzaG91bGQgYmUgdXNlZCBhcyB0aGUgU0RBVEEKIHNvdXJjZS4KIE9wdGlvbmFsLCBk ZWZhdWx0cyB0byAxLgogLkVsCi0uUHAKLU9uIGEKKy5TaCBGRFQgQ09ORklHVVJBVElPTgorT24g YW4KIC5YciBGRFQgNAotYmFzZWQgc3lzdGVtLCBsaWtlCi0uTGkgQVJNICwKLXRoZSBEVFMgcGFy dCBmb3IgYQorYmFzZWQgc3lzdGVtLCBzdWNoIGFzIEFSTSwgdGhlIERUUyBub2RlIGZvcgogLk5t IGdwaW9paWMKLWRldmljZSB1c3VhbGx5IGxvb2tzIGxpa2U6Citjb25mb3JtcyB0byB0aGUgc3Rh bmRhcmQgYmluZGluZ3MgZG9jdW1lbnQgaTJjL2kyYy1ncGlvLnlhbWwuCitUaGUgZGV2aWNlIG5v ZGUgdHlwaWNhbGx5IGFwcGVhcnMgYXQgdGhlIHJvb3Qgb2YgdGhlIGRldmljZSB0cmVlLgorVGhl IGZvbGxvd2luZyBpcyBhbiBleGFtcGxlIG9mIGEKKy5ObQorbm9kZSB3aXRoIG9uZSBzbGF2ZSBk ZXZpY2UKK29uIHRoZSBJSUMgYnVzOgogLkJkIC1saXRlcmFsCi1ncGlvOiBncGlvIHsKLQotCWdw aW8tY29udHJvbGxlcjsKLQkuLi4KLQorLyB7CiAJZ3Bpb2lpYzAgewotCQljb21wYXRpYmxlID0g ImdwaW9paWMiOwotCQkvKgotCQkgKiBBdHRhY2ggdG8gR1BJTyBwaW5zIDIxIGFuZCAyMi4gIFNl dCB0aGVtCi0JCSAqIGluaXRpYWxseSBhcyBpbnB1dHMuCi0JCSAqLwotCQlncGlvcyA9IDwmZ3Bp byAyMSAxIDAKLQkJCSAmZ3BpbyAyMiAxIDA+OwotCQlzY2wgPSA8MD47CQkvKiBHUElPIHBpbiAy MSAtIG9wdGlvbmFsICovCi0JCXNkYSA9IDwxPjsJCS8qIEdQSU8gcGluIDIyIC0gb3B0aW9uYWwg Ki8KKwkJY29tcGF0aWJsZSA9ICJpMmMtZ3BpbyI7CisJCXBpbmN0cmwtbmFtZXMgPSAiZGVmYXVs dCI7CisJCXBpbmN0cmwtMCA9IDwmcGluY3RybF9ncGlvaWljMD47CisJCXNjbC1ncGlvcyA9IDwm Z3BpbzEgIDUgR1BJT19BQ1RJVkVfSElHSD47CisJCXNkYS1ncGlvcyA9IDwmZ3BpbzcgMTEgR1BJ T19BQ1RJVkVfSElHSD47CisJCXN0YXR1cyA9ICJva2F5IjsKIAotCQkvKiBUaGlzIGlzIGFuIGV4 YW1wbGUgb2YgYSBncGlvaWljIGNoaWxkLiAqLwotCQlncGlvaWljLWNoaWxkMCB7Ci0JCQljb21w YXRpYmxlID0gImxtNzUiOwotCQkJaTJjLWFkZHJlc3MgPSA8MHg0Zj47CisJCS8qIE9uZSBzbGF2 ZSBkZXZpY2Ugb24gdGhlIGkyYyBidXMuICovCisJCXJ0Y0A1MSB7CisJCQljb21wYXRpYmxlPSJu eHAscGNmMjEyNyI7CisJCQlyZWcgPSA8MHg1MT47CisJCQlzdGF0dXMgPSAib2theSI7CiAJCX07 CiAJfTsKIH07CkBAIC0xMjgsMzUgKzEzMiwxOSBAQCBPcHRpb25hbCwgZGVmYXVsdHMgdG8gMS4K IFdoZXJlOgogLkJsIC10YWcgLXdpZHRoICIuVmEgY29tcGF0aWJsZSIKIC5JdCBWYSBjb21wYXRp YmxlCi1TaG91bGQgYWx3YXlzIGJlIHNldCB0byAiZ3Bpb2lpYyIuCi0uSXQgVmEgZ3Bpb3MKLVRo ZQotLlZhIGdwaW9zCi1wcm9wZXJ0eSBpbmRpY2F0ZXMgd2hpY2ggR1BJTyBwaW5zIHNob3VsZCBi ZSB1c2VkIGZvciBTQ0xPQ0sgYW5kIFNEQVRBCi1vbiB0aGUgR1BJTyBJSUMgYml0LWJhbmdpbmcg YnVzLgotRm9yIG1vcmUgZGV0YWlscyBhYm91dCB0aGUKLS5WYSBncGlvcwotcHJvcGVydHksIHBs ZWFzZSBjb25zdWx0Ci0uUGEgL3Vzci9zcmMvc3lzL2R0cy9iaW5kaW5ncy1ncGlvLnR4dCAuCi0u SXQgVmEgc2NsCi1UaGUKLS5WYSBzY2wKLW9wdGlvbiBpbmRpY2F0ZXMgd2hpY2ggYml0IGluIHRo ZQotLlZhIGdwaW9zCi1zaG91bGQgYmUgdXNlZCBhcyB0aGUgU0NMT0NLIHNvdXJjZS4KLU9wdGlv bmFsLCBkZWZhdWx0cyB0byAwLgotLkl0IFZhIHNkYQotVGhlCi0uVmEgc2RhCi1vcHRpb24gaW5k aWNhdGVzIHdoaWNoIGJpdCBpbiB0aGUKLS5WYSBncGlvcwotc2hvdWxkIGJlIHVzZWQgYXMgdGhl IFNEQVRBIHNvdXJjZS4KLU9wdGlvbmFsLCBkZWZhdWx0cyB0byAxLgorU2hvdWxkIGJlIHNldCB0 byAiaTJjLWdwaW8iLgorVGhlIGRlcHJlY2F0ZWQgc3RyaW5nICJncGlvaWljIiBpcyBhbHNvIGFj Y2VwdGVkIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4KKy5JdCBWYSBzY2wtZ3Bpb3MgVmEg c2RhLWdwaW9zCitUaGVzZSBwcm9wZXJ0aWVzIGluZGljYXRlIHdoaWNoIEdQSU8gcGlucyBzaG91 bGQgYmUgdXNlZCBmb3IgY2xvY2sKK2FuZCBkYXRhIG9uIHRoZSBHUElPIElJQyBiaXQtYmFuZ2lu ZyBidXMuCitUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IHRoZSB0d28gcGlucyBiZWxvbmcg dG8gdGhlIHNhbWUgZ3BpbyBjb250cm9sbGVyLgorLkl0IFZhIHBpbmN0cmwtbmFtZXMgcGluY3Ry bC0wCitUaGVzZSBwcm9wZXJ0aWVzIG1heSBiZSByZXF1aXJlZCB0byBjb25maWd1cmUgdGhlIGNo b3NlbiBwaW5zIGFzIGdwaW8KK3BpbnMsIHVubGVzcyB0aGUgcGlucyBkZWZhdWx0IHRvIHRoYXQg c3RhdGUgb24geW91ciBzeXN0ZW0uCiAuRWwKIC5TaCBTRUUgQUxTTwogLlhyIGZkdCA0ICwKIC5Y ciBncGlvIDQgLAotLlhyIGdwaW9sZWQgNCAsCiAuWHIgaWljIDQgLAogLlhyIGlpY2JiIDQgLAog LlhyIGlpY2J1cyA0CkluZGV4OiBzeXMvZGV2L2dwaW8vZ3Bpb2J1cy5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHN5cy9kZXYvZ3Bpby9ncGlvYnVzLmMJKHJldmlzaW9uIDM1NTMxNSkKKysrIHN5cy9kZXYvZ3Bp by9ncGlvYnVzLmMJKHdvcmtpbmcgY29weSkKQEAgLTc4LDYgKzc4LDE4IEBAIHN0YXRpYyBpbnQg Z3Bpb2J1c19waW5fZ2V0KGRldmljZV90LCBkZXZpY2VfdCwgdWluCiBzdGF0aWMgaW50IGdwaW9i dXNfcGluX3RvZ2dsZShkZXZpY2VfdCwgZGV2aWNlX3QsIHVpbnQzMl90KTsKIAogLyoKKyAqIGdw aW9idXNfcGluIGZsYWdzCisgKiAgVGhlIGZsYWdzIGluIHN0cnVjdCBncGlvYnVzX3BpbiBhcmUg bm90IHJlbGF0ZWQgdG8gdGhlIGZsYWdzIHVzZWQgYnkgdGhlCisgKiAgbG93LWxldmVsIGNvbnRy b2xsZXIgZHJpdmVyIGluIHN0cnVjdCBncGlvX3Bpbi4gIEN1cnJlbnRseSwgb25seSBwaW5zCisg KiAgYWNxdWlyZWQgdmlhIEZEVCBkYXRhIGhhdmUgZ3Bpb2J1c19waW4uZmxhZ3Mgc2V0LCBzb3Vy Y2VkIGZyb20gdGhlIGZsYWdzIGluCisgKiAgdGhlIEZEVCBwcm9wZXJ0aWVzLiAgSW4gdGhlb3J5 LCB0aGVzZSBmbGFncyBhcmUgZGVmaW5lZCBwZXItcGxhdGZvcm0uICBJbgorICogIHByYWN0aWNl IHRoZXkgYXJlIGFsd2F5cyB0aGUgZmxhZ3MgZnJvbSB0aGUgZHQtYmluZGluZ3MvZ3Bpby9ncGlv LmggZmlsZS4KKyAqICBUaGUgb25seSBvbmUgb2YgdGhvc2UgZmxhZ3Mgd2UgY3VycmVudGx5IHN1 cHBvcnQgaXMgZm9yIGhhbmRsaW5nIGFjdGl2ZS1sb3cKKyAqICBwaW5zLCBzbyB3ZSBqdXN0IGRl ZmluZSB0aGF0IGZsYWcgaGVyZSBpbnN0ZWFkIG9mIGluY2x1ZGluZyBhIEdQTCdkIGhlYWRlci4K KyAqLworI2RlZmluZQlHUElPX0FDVElWRV9MT1cgMQorCisvKgogICogWFhYIC0+IE1vdmUgbWUg dG8gYmV0dGVyIHBsYWNlIC0gZ3Bpb19zdWJyLmM/CiAgKiBBbHNvLCB0aGlzIGZ1bmN0aW9uIG11 c3QgYmUgY2hhbmdlZCB3aGVuIGludGVycnVwdCBjb25maWd1cmF0aW9uCiAgKiBkYXRhIHdpbGwg YmUgbW92ZWQgaW50byBzdHJ1Y3QgcmVzb3VyY2UuCkBAIC0xMzUsNiArMTQ3LDExNCBAQCBncGlv X2NoZWNrX2ZsYWdzKHVpbnQzMl90IGNhcHMsIHVpbnQzMl90IGZsYWdzKQogCXJldHVybiAoMCk7 CiB9CiAKK2ludAorZ3Bpb19waW5fZ2V0X2J5X2J1c19waW5udW0oZGV2aWNlX3QgYnVzZGV2LCB1 aW50MzJfdCBwaW5udW0sIGdwaW9fcGluX3QgKnBwaW4pCit7CisJZ3Bpb19waW5fdCBwaW47CisJ aW50IGVycjsKKworCWVyciA9IGdwaW9idXNfYWNxdWlyZV9waW4oYnVzZGV2LCBwaW5udW0pOwor CWlmIChlcnIgIT0gMCkKKwkJcmV0dXJuIChFQlVTWSk7CisKKwlwaW4gPSBtYWxsb2Moc2l6ZW9m KCpwaW4pLCBNX0RFVkJVRiwgTV9XQUlUT0sgfCBNX1pFUk8pOworCisJcGluLT5kZXYgPSBkZXZp Y2VfZ2V0X3BhcmVudChidXNkZXYpOworCXBpbi0+cGluID0gcGlubnVtOworCXBpbi0+ZmxhZ3Mg PSAwOworCisJKnBwaW4gPSBwaW47CisJcmV0dXJuICgwKTsKK30KKworaW50CitncGlvX3Bpbl9n ZXRfYnlfY2hpbGRfaW5kZXgoZGV2aWNlX3QgY2hpbGRkZXYsIHVpbnQzMl90IGlkeCwgZ3Bpb19w aW5fdCAqcHBpbikKK3sKKwlzdHJ1Y3QgZ3Bpb2J1c19pdmFyICpkZXZpOworCisJZGV2aSA9IEdQ SU9CVVNfSVZBUihjaGlsZGRldik7CisJaWYgKGlkeCA+PSBkZXZpLT5ucGlucykKKwkJcmV0dXJu IChFSU5WQUwpOworCisJcmV0dXJuIChncGlvX3Bpbl9nZXRfYnlfYnVzX3Bpbm51bShkZXZpY2Vf Z2V0X3BhcmVudChjaGlsZGRldiksCisJICAgIGRldmktPnBpbnNbaWR4XSwgcHBpbikpOworfQor CitpbnQKK2dwaW9fcGluX2dldGNhcHMoZ3Bpb19waW5fdCBwaW4sIHVpbnQzMl90ICpjYXBzKQor eworCisJS0FTU0VSVChwaW4gIT0gTlVMTCwgKCJHUElPIHBpbiBpcyBOVUxMLiIpKTsKKwlLQVNT RVJUKHBpbi0+ZGV2ICE9IE5VTEwsICgiR1BJTyBwaW4gZGV2aWNlIGlzIE5VTEwuIikpOworCXJl dHVybiAoR1BJT19QSU5fR0VUQ0FQUyhwaW4tPmRldiwgcGluLT5waW4sIGNhcHMpKTsKK30KKwor aW50CitncGlvX3Bpbl9pc19hY3RpdmUoZ3Bpb19waW5fdCBwaW4sIGJvb2wgKmFjdGl2ZSkKK3sK KwlpbnQgcnY7CisJdWludDMyX3QgdG1wOworCisJS0FTU0VSVChwaW4gIT0gTlVMTCwgKCJHUElP IHBpbiBpcyBOVUxMLiIpKTsKKwlLQVNTRVJUKHBpbi0+ZGV2ICE9IE5VTEwsICgiR1BJTyBwaW4g ZGV2aWNlIGlzIE5VTEwuIikpOworCXJ2ID0gR1BJT19QSU5fR0VUKHBpbi0+ZGV2LCBwaW4tPnBp biwgJnRtcCk7CisJaWYgKHJ2ICAhPSAwKSB7CisJCXJldHVybiAocnYpOworCX0KKworCWlmIChw aW4tPmZsYWdzICYgR1BJT19BQ1RJVkVfTE9XKQorCQkqYWN0aXZlID0gdG1wID09IDA7CisJZWxz ZQorCQkqYWN0aXZlID0gdG1wICE9IDA7CisJcmV0dXJuICgwKTsKK30KKwordm9pZAorZ3Bpb19w aW5fcmVsZWFzZShncGlvX3Bpbl90IGdwaW8pCit7CisJZGV2aWNlX3QgYnVzZGV2OworCisJaWYg KGdwaW8gPT0gTlVMTCkKKwkJcmV0dXJuOworCisJS0FTU0VSVChncGlvLT5kZXYgIT0gTlVMTCwg KCJHUElPIHBpbiBkZXZpY2UgaXMgTlVMTC4iKSk7CisKKwlidXNkZXYgPSBHUElPX0dFVF9CVVMo Z3Bpby0+ZGV2KTsKKwlpZiAoYnVzZGV2ICE9IE5VTEwpCisJCWdwaW9idXNfcmVsZWFzZV9waW4o YnVzZGV2LCBncGlvLT5waW4pOworCisJZnJlZShncGlvLCBNX0RFVkJVRik7Cit9CisKK2ludAor Z3Bpb19waW5fc2V0X2FjdGl2ZShncGlvX3Bpbl90IHBpbiwgYm9vbCBhY3RpdmUpCit7CisJaW50 IHJ2OworCXVpbnQzMl90IHRtcDsKKworCWlmIChwaW4tPmZsYWdzICYgR1BJT19BQ1RJVkVfTE9X KQorCQl0bXAgPSBhY3RpdmUgPyAwIDogMTsKKwllbHNlCisJCXRtcCA9IGFjdGl2ZSA/IDEgOiAw OworCisJS0FTU0VSVChwaW4gIT0gTlVMTCwgKCJHUElPIHBpbiBpcyBOVUxMLiIpKTsKKwlLQVNT RVJUKHBpbi0+ZGV2ICE9IE5VTEwsICgiR1BJTyBwaW4gZGV2aWNlIGlzIE5VTEwuIikpOworCXJ2 ID0gR1BJT19QSU5fU0VUKHBpbi0+ZGV2LCBwaW4tPnBpbiwgdG1wKTsKKwlyZXR1cm4gKHJ2KTsK K30KKworaW50CitncGlvX3Bpbl9zZXRmbGFncyhncGlvX3Bpbl90IHBpbiwgdWludDMyX3QgZmxh Z3MpCit7CisJaW50IHJ2OworCisJS0FTU0VSVChwaW4gIT0gTlVMTCwgKCJHUElPIHBpbiBpcyBO VUxMLiIpKTsKKwlLQVNTRVJUKHBpbi0+ZGV2ICE9IE5VTEwsICgiR1BJTyBwaW4gZGV2aWNlIGlz IE5VTEwuIikpOworCisJcnYgPSBHUElPX1BJTl9TRVRGTEFHUyhwaW4tPmRldiwgcGluLT5waW4s IGZsYWdzKTsKKwlyZXR1cm4gKHJ2KTsKK30KKwogc3RhdGljIHZvaWQKIGdwaW9idXNfcHJpbnRf cGlucyhzdHJ1Y3QgZ3Bpb2J1c19pdmFyICpkZXZpLCBjaGFyICpidWYsIHNpemVfdCBidWZsZW4p CiB7CkBAIC0zNzAsOCArNDkwLDYgQEAgZ3Bpb2J1c19wYXJzZV9waW5zKHN0cnVjdCBncGlvYnVz X3NvZnRjICpzYywgZGV2aWMKIAkJZGV2aS0+cGluc1tucGlucysrXSA9IGk7CiAJfQogCi0JaWYg KGdwaW9idXNfYWNxdWlyZV9jaGlsZF9waW5zKHNjLT5zY19idXNkZXYsIGNoaWxkKSAhPSAwKQot CQlyZXR1cm4gKEVJTlZBTCk7CiAJcmV0dXJuICgwKTsKIH0KIApAQCAtNDI1LDggKzU0Myw2IEBA IGdwaW9idXNfcGFyc2VfcGluX2xpc3Qoc3RydWN0IGdwaW9idXNfc29mdGMgKnNjLCBkCiAJCXAg PSBlbmRwICsgMTsKIAl9CiAKLQlpZiAoZ3Bpb2J1c19hY3F1aXJlX2NoaWxkX3BpbnMoc2MtPnNj X2J1c2RldiwgY2hpbGQpICE9IDApCi0JCXJldHVybiAoRUlOVkFMKTsKIAlyZXR1cm4gKDApOwog fQogCkluZGV4OiBzeXMvZGV2L2dwaW8vZ3Bpb2J1c3Zhci5oCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9k ZXYvZ3Bpby9ncGlvYnVzdmFyLmgJKHJldmlzaW9uIDM1NTMxNSkKKysrIHN5cy9kZXYvZ3Bpby9n cGlvYnVzdmFyLmgJKHdvcmtpbmcgY29weSkKQEAgLTE0MSw3ICsxNDEsNyBAQCBpbnQgb2Z3X2dw aW9idXNfcGFyc2VfZ3Bpb3MoZGV2aWNlX3QsIGNoYXIgKiwgc3RydQogdm9pZCBvZndfZ3Bpb2J1 c19yZWdpc3Rlcl9wcm92aWRlcihkZXZpY2VfdCk7CiB2b2lkIG9md19ncGlvYnVzX3VucmVnaXN0 ZXJfcHJvdmlkZXIoZGV2aWNlX3QpOwogCi0vKiBDb25zdW1lcnMgaW50ZXJmYWNlLiAqLworLyog QWNxdWlyZSBhIHBpbiBieSBwYXJzaW5nIEZEVCBkYXRhLiAqLwogaW50IGdwaW9fcGluX2dldF9i eV9vZndfbmFtZShkZXZpY2VfdCBjb25zdW1lciwgcGhhbmRsZV90IG5vZGUsCiAgICAgY2hhciAq bmFtZSwgZ3Bpb19waW5fdCAqZ3Bpbyk7CiBpbnQgZ3Bpb19waW5fZ2V0X2J5X29md19pZHgoZGV2 aWNlX3QgY29uc3VtZXIsIHBoYW5kbGVfdCBub2RlLApAQCAtMTUwLDE0ICsxNTAsMjkgQEAgaW50 IGdwaW9fcGluX2dldF9ieV9vZndfcHJvcGVydHkoZGV2aWNlX3QgY29uc3VtZXIKICAgICBjaGFy ICpuYW1lLCBncGlvX3Bpbl90ICpncGlvKTsKIGludCBncGlvX3Bpbl9nZXRfYnlfb2Z3X3Byb3Bp ZHgoZGV2aWNlX3QgY29uc3VtZXIsIHBoYW5kbGVfdCBub2RlLAogICAgIGNoYXIgKm5hbWUsIGlu dCBpZHgsIGdwaW9fcGluX3QgKmdwaW8pOworI2VuZGlmIC8qIEZEVCAqLworCisvKiBBY3F1aXJl IGEgcGluIGJ5IGJ1cyBhbmQgcGluIG51bWJlci4gKi8KK2ludCBncGlvX3Bpbl9nZXRfYnlfYnVz X3Bpbm51bShkZXZpY2VfdCBfYnVzLCB1aW50MzJfdCBfcGlubnVtLCBncGlvX3Bpbl90ICpfZ3Ap OworCisvKiBBY3F1aXJlIGEgcGluIGJ5IGNoaWxkIGFuZCBpbmRleCAodXNlZCBieSBkaXJlY3Qg Y2hpbGRyZW4gb2YgZ3Bpb2J1cykuICovCitpbnQgZ3Bpb19waW5fZ2V0X2J5X2NoaWxkX2luZGV4 KGRldmljZV90IF9jaGlsZCwgdWludDMyX3QgX2lkeCwgZ3Bpb19waW5fdCAqX2dwKTsKKworLyog UmVsZWFzZSBhIHBpbiBhY3F1aXJlZCB2aWEgYW55IGdwaW9fcGluX2dldF94eHgoKSBmdW5jdGlv bi4gKi8KIHZvaWQgZ3Bpb19waW5fcmVsZWFzZShncGlvX3Bpbl90IGdwaW8pOworCisvKiBXb3Jr IHdpdGggZ3BpbyBwaW5zIGFjcXVpcmVkIHVzaW5nIHRoZSBmdW5jdGlvbnMgYWJvdmUuICovCiBp bnQgZ3Bpb19waW5fZ2V0Y2FwcyhncGlvX3Bpbl90IHBpbiwgdWludDMyX3QgKmNhcHMpOwogaW50 IGdwaW9fcGluX2lzX2FjdGl2ZShncGlvX3Bpbl90IHBpbiwgYm9vbCAqYWN0aXZlKTsKIGludCBn cGlvX3Bpbl9zZXRfYWN0aXZlKGdwaW9fcGluX3QgcGluLCBib29sIGFjdGl2ZSk7CiBpbnQgZ3Bp b19waW5fc2V0ZmxhZ3MoZ3Bpb19waW5fdCBwaW4sIHVpbnQzMl90IGZsYWdzKTsKLSNlbmRpZgog c3RydWN0IHJlc291cmNlICpncGlvX2FsbG9jX2ludHJfcmVzb3VyY2UoZGV2aWNlX3QgY29uc3Vt ZXJfZGV2LCBpbnQgKnJpZCwKICAgICB1X2ludCBhbGxvY19mbGFncywgZ3Bpb19waW5fdCBwaW4s IHVpbnQzMl90IGludHJfbW9kZSk7CisKKy8qCisgKiBGdW5jdGlvbnMgc2hhcmVkIGJldHdlZW4g Z3Bpb2J1cyBhbmQgb3RoZXIgYnVzIGNsYXNzZXMgdGhhdCBkZXJpdmUgZnJvbSBpdDsKKyAqIHRo ZXNlIHNob3VsZCBub3QgYmUgY2FsbGVkIGRpcmVjdGx5IGJ5IG90aGVyIGRyaXZlcnMuCisgKi8K IGludCBncGlvX2NoZWNrX2ZsYWdzKHVpbnQzMl90LCB1aW50MzJfdCk7CiBkZXZpY2VfdCBncGlv YnVzX2F0dGFjaF9idXMoZGV2aWNlX3QpOwogaW50IGdwaW9idXNfZGV0YWNoX2J1cyhkZXZpY2Vf dCk7CkluZGV4OiBzeXMvZGV2L2dwaW8vZ3Bpb2lpYy5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv Z3Bpby9ncGlvaWljLmMJKHJldmlzaW9uIDM1NTMxNSkKKysrIHN5cy9kZXYvZ3Bpby9ncGlvaWlj LmMJKHdvcmtpbmcgY29weSkKQEAgLTEsOSArMSw5IEBACiAvKi0KLSAqIFNQRFgtTGljZW5zZS1J ZGVudGlmaWVyOiBCU0QtMi1DbGF1c2UtRnJlZUJTRAorICogU1BEWC1MaWNlbnNlLUlkZW50aWZp ZXI6IEJTRC0yLUNsYXVzZQogICoKICAqIENvcHlyaWdodCAoYykgMjAwOSBPbGVrc2FuZHIgVHlt b3NoZW5rbyA8Z29uem9AZnJlZWJzZC5vcmc+CiAgKiBDb3B5cmlnaHQgKGMpIDIwMTAgTHVpeiBP dGF2aW8gTyBTb3V6YQotICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqIENvcHlyaWdodCAoYykg MjAxOSBJYW4gTGVwb3JlIDxpYW5AZnJlZWJzZC5vcmc+CiAgKgogICogUmVkaXN0cmlidXRpb24g YW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CiAgKiBt b2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNv bmRpdGlvbnMKQEAgLTM5LDE0ICszOSw4IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNs dWRlIDxzeXMva2VybmVsLmg+CiAjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgogCi0jaWZkZWYgRkRU Ci0jaW5jbHVkZSA8ZGV2L2ZkdC9mZHRfY29tbW9uLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndf YnVzLmg+Ci0jZW5kaWYKLQogI2luY2x1ZGUgPGRldi9ncGlvL2dwaW9idXN2YXIuaD4KICNpbmNs dWRlIDxkZXYvaWljYnVzL2lpY29uZi5oPgotI2luY2x1ZGUgPGRldi9paWNidXMvaWljYnVzLmg+ CiAKICNpbmNsdWRlICJncGlvYnVzX2lmLmgiCiAjaW5jbHVkZSAiaWljYmJfaWYuaCIKQEAgLTU3 LDIwMCArNTEsMjgxIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIAogc3RydWN0IGdwaW9paWNf c29mdGMgCiB7Ci0JZGV2aWNlX3QJc2NfZGV2OwotCWRldmljZV90CXNjX2J1c2RldjsKLQlpbnQJ CXNjbF9waW47Ci0JaW50CQlzZGFfcGluOworCWRldmljZV90CWRldjsKKwlncGlvX3Bpbl90CXNj bHBpbjsKKwlncGlvX3Bpbl90CXNkYXBpbjsKIH07CiAKLXN0YXRpYyBpbnQgZ3Bpb2lpY19wcm9i ZShkZXZpY2VfdCk7Ci1zdGF0aWMgaW50IGdwaW9paWNfYXR0YWNoKGRldmljZV90KTsKKyNpZmRl ZiBGRFQKIAotLyogaWljYmIgaW50ZXJmYWNlICovCi1zdGF0aWMgdm9pZCBncGlvaWljX3Jlc2V0 X2J1cyhkZXZpY2VfdCk7Ci1zdGF0aWMgdm9pZCBncGlvaWljX3NldHNkYShkZXZpY2VfdCwgaW50 KTsKLXN0YXRpYyB2b2lkIGdwaW9paWNfc2V0c2NsKGRldmljZV90LCBpbnQpOwotc3RhdGljIGlu dCBncGlvaWljX2dldHNkYShkZXZpY2VfdCk7Ci1zdGF0aWMgaW50IGdwaW9paWNfZ2V0c2NsKGRl dmljZV90KTsKLXN0YXRpYyBpbnQgZ3Bpb2lpY19yZXNldChkZXZpY2VfdCwgdV9jaGFyLCB1X2No YXIsIHVfY2hhciAqKTsKKyNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KIAorc3RhdGljIHN0 cnVjdCBvZndfY29tcGF0X2RhdGEgY29tcGF0X2RhdGFbXSA9IHsKKwl7ImkyYy1ncGlvIiwgIHRy dWV9LCAvKiBTdGFuZGFyZCBkZXZpY2V0cmVlIGNvbXBhdCBzdHJpbmcgKi8KKwl7ImdwaW9paWMi LCAgIHRydWV9LCAvKiBEZXByZWNhdGVkIG9sZCBmcmVlYnNkIGNvbXBhdCBzdHJpbmcgKi8KKwl7 TlVMTCwgICAgICAgIGZhbHNlfQorfTsKK09GV0JVU19QTlBfSU5GTyhjb21wYXRfZGF0YSk7CitT SU1QTEVCVVNfUE5QX0lORk8oY29tcGF0X2RhdGEpOworCitzdGF0aWMgcGhhbmRsZV90CitncGlv aWljX2dldF9ub2RlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgZGV2KQoreworCisJLyogU2hhcmUg b3VyIGZkdCBub2RlIHdpdGggaWljYnVzIHNvIGl0IGNhbiBmaW5kIGl0cyBjaGlsZCBub2Rlcy4g Ki8KKwlyZXR1cm4gKG9md19idXNfZ2V0X25vZGUoYnVzKSk7Cit9CisKIHN0YXRpYyBpbnQKLWdw aW9paWNfcHJvYmUoZGV2aWNlX3QgZGV2KQorZ3Bpb2lpY19zZXR1cF9mZHRfcGlucyhzdHJ1Y3Qg Z3Bpb2lpY19zb2Z0YyAqc2MpCiB7Ci0Jc3RydWN0IGdwaW9idXNfaXZhciAqZGV2aTsKKwlwaGFu ZGxlX3Qgbm9kZTsKKwlpbnQgZXJyOwogCi0jaWZkZWYgRkRUCi0JaWYgKCFvZndfYnVzX3N0YXR1 c19va2F5KGRldikpCi0JCXJldHVybiAoRU5YSU8pOwotCWlmICghb2Z3X2J1c19pc19jb21wYXRp YmxlKGRldiwgImdwaW9paWMiKSkKLQkJcmV0dXJuIChFTlhJTyk7Ci0jZW5kaWYKLQlkZXZpID0g R1BJT0JVU19JVkFSKGRldik7Ci0JaWYgKGRldmktPm5waW5zIDwgR1BJT0lJQ19NSU5fUElOUykg ewotCQlkZXZpY2VfcHJpbnRmKGRldiwKLQkJICAgICJncGlvaWljIG5lZWRzIGF0IGxlYXN0ICVk IEdQSU8gcGlucyAob25seSAlZCBnaXZlbikuXG4iLAotCQkgICAgR1BJT0lJQ19NSU5fUElOUywg ZGV2aS0+bnBpbnMpOwotCQlyZXR1cm4gKEVOWElPKTsKKwlub2RlID0gb2Z3X2J1c19nZXRfbm9k ZShzYy0+ZGV2KTsKKworCS8qCisJICogSGlzdG9yaWNhbGx5LCB3ZSB1c2VkIHRoZSBmaXJzdCB0 d28gYXJyYXkgZWxlbWVudHMgb2YgdGhlIGdwaW9zCisJICogcHJvcGVydHkuICBUaGUgbW9kZXJu IGJpbmRpbmdzIHNwZWNpZnkgc2VwYXJhdGUgc2NsLWdwaW9zIGFuZAorCSAqIHNkYS1ncGlvcyBw cm9wZXJ0aWVzLiAgV2UgY29wZSB3aXRoIHdoaWNoZXZlciBpcyBwcmVzZW50LgorCSAqLworCWlm IChPRl9oYXNwcm9wKG5vZGUsICJncGlvcyIpKSB7CisJCWlmICgoZXJyID0gZ3Bpb19waW5fZ2V0 X2J5X29md19pZHgoc2MtPmRldiwgbm9kZSwKKwkJICAgIEdQSU9JSUNfU0NMX0RGTFQsICZzYy0+ c2NscGluKSkgIT0gMCkgeworCQkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAiaW52YWxpZCBncGlv cyBwcm9wZXJ0eVxuIik7CisJCQlyZXR1cm4gKGVycik7CisJCX0KKwkJaWYgKChlcnIgPSBncGlv X3Bpbl9nZXRfYnlfb2Z3X2lkeChzYy0+ZGV2LCBub2RlLAorCQkgICAgR1BJT0lJQ19TREFfREZM VCwgJnNjLT5zZGFwaW4pKSAhPSAwKSB7CisJCQlkZXZpY2VfcHJpbnRmKHNjLT5kZXYsICJpdmFs aWQgZ3Bpb3MgcHJvcGVydHlcbiIpOworCQkJcmV0dXJuIChlcnIpOworCQl9CisJfSBlbHNlIHsK KwkJaWYgKChlcnIgPSBncGlvX3Bpbl9nZXRfYnlfb2Z3X3Byb3BlcnR5KHNjLT5kZXYsIG5vZGUs CisJCSAgICAic2NsLWdwaW9zIiwgJnNjLT5zY2xwaW4pKSAhPSAwKSB7CisJCQlkZXZpY2VfcHJp bnRmKHNjLT5kZXYsICJtaXNzaW5nIHNjbC1ncGlvcyBwcm9wZXJ0eVxuIik7CisJCQlyZXR1cm4g KGVycik7CisJCX0KKwkJaWYgKChlcnIgPSBncGlvX3Bpbl9nZXRfYnlfb2Z3X3Byb3BlcnR5KHNj LT5kZXYsIG5vZGUsCisJCSAgICAic2RhLWdwaW9zIiwgJnNjLT5zZGFwaW4pKSAhPSAwKSB7CisJ CQlkZXZpY2VfcHJpbnRmKHNjLT5kZXYsICJtaXNzaW5nIHNkYS1ncGlvcyBwcm9wZXJ0eVxuIik7 CisJCQlyZXR1cm4gKGVycik7CisJCX0KIAl9Ci0JZGV2aWNlX3NldF9kZXNjKGRldiwgIkdQSU8g STJDIGJpdC1iYW5naW5nIGRyaXZlciIpOwotCi0JcmV0dXJuIChCVVNfUFJPQkVfREVGQVVMVCk7 CisJcmV0dXJuICgwKTsKIH0KKyNlbmRpZiAvKiBGRFQgKi8KIAogc3RhdGljIGludAotZ3Bpb2lp Y19hdHRhY2goZGV2aWNlX3QgZGV2KQorZ3Bpb2lpY19zZXR1cF9oaW50ZWRfcGlucyhzdHJ1Y3Qg Z3Bpb2lpY19zb2Z0YyAqc2MpCiB7Ci0JZGV2aWNlX3QJCWJpdGJhbmc7Ci0jaWZkZWYgRkRUCi0J cGhhbmRsZV90CQlub2RlOwotCXBjZWxsX3QJCQlwaW47Ci0jZW5kaWYKLQlzdHJ1Y3QgZ3Bpb2J1 c19pdmFyCSpkZXZpOwotCXN0cnVjdCBncGlvaWljX3NvZnRjCSpzYzsKKwlkZXZpY2VfdCBidXNk ZXY7CisJY29uc3QgY2hhciAqYnVzbmFtZSwgKmRldm5hbWU7CisJaW50IGVyciwgbnVtcGlucywg c2NsbnVtLCBzZGFudW0sIHVuaXQ7CiAKLQlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKLQlz Yy0+c2NfZGV2ID0gZGV2OwotCXNjLT5zY19idXNkZXYgPSBkZXZpY2VfZ2V0X3BhcmVudChkZXYp OwotCWlmIChyZXNvdXJjZV9pbnRfdmFsdWUoZGV2aWNlX2dldF9uYW1lKGRldiksCi0JCWRldmlj ZV9nZXRfdW5pdChkZXYpLCAic2NsIiwgJnNjLT5zY2xfcGluKSkKLQkJc2MtPnNjbF9waW4gPSBH UElPSUlDX1NDTF9ERkxUOwotCWlmIChyZXNvdXJjZV9pbnRfdmFsdWUoZGV2aWNlX2dldF9uYW1l KGRldiksCi0JCWRldmljZV9nZXRfdW5pdChkZXYpLCAic2RhIiwgJnNjLT5zZGFfcGluKSkKLQkJ c2MtPnNkYV9waW4gPSBHUElPSUlDX1NEQV9ERkxUOworCWRldm5hbWUgPSBkZXZpY2VfZ2V0X25h bWUoc2MtPmRldik7CisJdW5pdCA9IGRldmljZV9nZXRfdW5pdChzYy0+ZGV2KTsKKwlidXNkZXYg PSBkZXZpY2VfZ2V0X3BhcmVudChzYy0+ZGV2KTsKIAorCS8qCisJICogSWYgdGhlcmUgaXMgbm90 IGFuICJhdCIgaGludCBuYW1pbmcgb3VyIGFjdHVhbCBwYXJlbnQsIHRoZW4gd2UKKwkgKiB3ZXJl bid0IGluc3RhbnRpYXRlZCBhcyBhIGNoaWxkIG9mIGdwaW9idXMgdmlhIGhpbnRzLCBhbmQgd2Ug dGh1cworCSAqIGNhbid0IGFjY2VzcyBpdmFycyB0aGF0IG9ubHkgZXhpc3QgZm9yIHN1Y2ggY2hp bGRyZW4uCisJICovCisJaWYgKHJlc291cmNlX3N0cmluZ192YWx1ZShkZXZuYW1lLCB1bml0LCAi YXQiLCAmYnVzbmFtZSkgIT0gMCB8fAorCSAgICAoc3RyY21wKGJ1c25hbWUsIGRldmljZV9nZXRf bmFtZXVuaXQoYnVzZGV2KSkgIT0gMCAmJgorCSAgICAgc3RyY21wKGJ1c25hbWUsIGRldmljZV9n ZXRfbmFtZShidXNkZXYpKSAhPSAwKSkgeworCQlyZXR1cm4gKEVOT0VOVCk7CisJfQorCisJLyog TWFrZSBzdXJlIHRoZXJlIHdlcmUgaGludHMgZm9yIGF0IGxlYXN0IHR3byBwaW5zLiAqLworCW51 bXBpbnMgPSBncGlvYnVzX2dldF9ucGlucyhzYy0+ZGV2KTsKKwlpZiAobnVtcGlucyA8IEdQSU9J SUNfTUlOX1BJTlMpIHsKICNpZmRlZiBGRFQKLQlpZiAoKG5vZGUgPSBvZndfYnVzX2dldF9ub2Rl KGRldikpID09IC0xKQotCQlyZXR1cm4gKEVOWElPKTsKLQlpZiAoT0ZfZ2V0ZW5jcHJvcChub2Rl LCAic2NsIiwgJnBpbiwgc2l6ZW9mKHBpbikpID4gMCkKLQkJc2MtPnNjbF9waW4gPSAoaW50KXBp bjsKLQlpZiAoT0ZfZ2V0ZW5jcHJvcChub2RlLCAic2RhIiwgJnBpbiwgc2l6ZW9mKHBpbikpID4g MCkKLQkJc2MtPnNkYV9waW4gPSAoaW50KXBpbjsKKwkJLyoKKwkJICogQmUgc2lsZW50IHdoZW4g dGhlcmUgYXJlIG5vIGhpbnRzIG9uIEZEVCBzeXN0ZW1zOyB0aGUgRkRUCisJCSAqIGRhdGEgd2ls bCBwcm92aWRlIHRoZSBwaW4gY29uZmlnICh3ZSdsbCB3aGluZSBpZiBpdCBkb2Vzbid0KS4KKwkJ ICovCisJCWlmIChudW1waW5zID09IDApIHsKKwkJCXJldHVybiAoRU5PRU5UKTsKKwkJfQogI2Vu ZGlmCisJCWRldmljZV9wcmludGYoc2MtPmRldiwgCisJCSAgICAiaW52YWxpZCBwaW5zIGhpbnQ7 IGl0IG11c3QgY29udGFpbiBhdCBsZWFzdCAlZCBwaW5zXG4iLAorCQkgICAgR1BJT0lJQ19NSU5f UElOUyk7CisJCXJldHVybiAoRUlOVkFMKTsKKwl9CiAKLQlpZiAoc2MtPnNjbF9waW4gPCAwIHx8 IHNjLT5zY2xfcGluID4gMSkKLQkJc2MtPnNjbF9waW4gPSBHUElPSUlDX1NDTF9ERkxUOwotCWlm IChzYy0+c2RhX3BpbiA8IDAgfHwgc2MtPnNkYV9waW4gPiAxKQotCQlzYy0+c2RhX3BpbiA9IEdQ SU9JSUNfU0RBX0RGTFQ7CisJLyoKKwkgKiBPdXIgcGFyZW50IGJ1cyBoYXMgYWxyZWFkeSBwYXJz ZWQgdGhlIHBpbnMgaGludCBhbmQgaXQgd2lsbCB1c2UgdGhhdAorCSAqIGluZm8gd2hlbiB3ZSBj YWxsIGdwaW9fcGluX2dldF9ieV9jaGlsZF9pbmRleCgpLiAgQnV0IHdlIGhhdmUgdG8KKwkgKiBo YW5kbGUgdGhlIHNjbC9zZGEgaW5kZXggaGludHMgdGhhdCB0ZWxsIHVzIHdoaWNoIG9mIHRoZSB0 d28gcGlucyBpcworCSAqIHRoZSBjbG9jayBhbmQgd2hpY2ggaXMgdGhlIGRhdGEuICBUaGV5J3Jl IG9wdGlvbmFsLCBidXQgaWYgcHJlc2VudAorCSAqIHRoZXkgbXVzdCBiZSBhIHZhbGlkIGluZGV4 ICgwIDw9IGluZGV4IDwgbnVtcGlucykuCisJICovCisJaWYgKChlcnIgPSByZXNvdXJjZV9pbnRf dmFsdWUoZGV2bmFtZSwgdW5pdCwgInNjbCIsICZzY2xudW0pKSAhPSAwKQorCQlzY2xudW0gPSBH UElPSUlDX1NDTF9ERkxUOworCWVsc2UgaWYgKHNjbG51bSA8IDAgfHwgc2NsbnVtID49IG51bXBp bnMpIHsKKwkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAiaW52YWxpZCBzY2wgaGludCAlZFxuIiwg c2NsbnVtKTsKKwkJcmV0dXJuIChFSU5WQUwpOworCX0KKwlpZiAoKGVyciA9IHJlc291cmNlX2lu dF92YWx1ZShkZXZuYW1lLCB1bml0LCAic2RhIiwgJnNkYW51bSkpICE9IDApCisJCXNkYW51bSA9 IEdQSU9JSUNfU0RBX0RGTFQ7CisJZWxzZSBpZiAoc2RhbnVtIDwgMCB8fCBzZGFudW0gPj0gbnVt cGlucykgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5kZXYsICJpbnZhbGlkIHNkYSBoaW50ICVkXG4i LCBzZGFudW0pOworCQlyZXR1cm4gKEVJTlZBTCk7CisJfQogCi0JZGV2aSA9IEdQSU9CVVNfSVZB UihkZXYpOwotCWRldmljZV9wcmludGYoZGV2LCAiU0NMIHBpbjogJWQsIFNEQSBwaW46ICVkXG4i LAotCSAgICBkZXZpLT5waW5zW3NjLT5zY2xfcGluXSwgZGV2aS0+cGluc1tzYy0+c2RhX3Bpbl0p OworCS8qIEFsbG9jYXRlIGdwaW9idXNfcGluIHN0cnVjdHMgZm9yIHRoZSBwaW5zIHdlIGZvdW5k IGFib3ZlLiAqLworCWlmICgoZXJyID0gZ3Bpb19waW5fZ2V0X2J5X2NoaWxkX2luZGV4KHNjLT5k ZXYsIHNjbG51bSwKKwkgICAgJnNjLT5zY2xwaW4pKSAhPSAwKQorCQlyZXR1cm4gKGVycik7CisJ aWYgKChlcnIgPSBncGlvX3Bpbl9nZXRfYnlfY2hpbGRfaW5kZXgoc2MtPmRldiwgc2RhbnVtLAor CSAgICAmc2MtPnNkYXBpbikpICE9IDApCisJCXJldHVybiAoZXJyKTsKIAotCS8qIGFkZCBnZW5l cmljIGJpdC1iYW5naW5nIGNvZGUgKi8KLQliaXRiYW5nID0gZGV2aWNlX2FkZF9jaGlsZChkZXYs ICJpaWNiYiIsIC0xKTsKLQlkZXZpY2VfcHJvYmVfYW5kX2F0dGFjaChiaXRiYW5nKTsKLQogCXJl dHVybiAoMCk7CiB9CiAKLXN0YXRpYyBpbnQKLWdwaW9paWNfZGV0YWNoKGRldmljZV90IGRldikK K3N0YXRpYyB2b2lkCitncGlvaWljX3NldHNkYShkZXZpY2VfdCBkZXYsIGludCB2YWwpCiB7CisJ c3RydWN0IGdwaW9paWNfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCWludCBl cnI7CiAKLQlidXNfZ2VuZXJpY19kZXRhY2goZGV2KTsKLQlkZXZpY2VfZGVsZXRlX2NoaWxkcmVu KGRldik7Ci0JcmV0dXJuICgwKTsKKwkvKgorCSAqIFNvbWUgY29udHJvbGxlcnMgY2Fubm90IHNl dCBhbiBvdXRwdXQgdmFsdWUgd2hpbGUgYSBwaW4gaXMgaW4gaW5wdXQKKwkgKiBtb2RlOyBpbiB0 aGF0IGNhc2Ugd2Ugc2V0IHRoZSBwaW4gYWdhaW4gYWZ0ZXIgY2hhbmdpbmcgbW9kZS4KKwkgKi8K KwllcnIgPSBncGlvX3Bpbl9zZXRfYWN0aXZlKHNjLT5zZGFwaW4sIHZhbCk7CisJZ3Bpb19waW5f c2V0ZmxhZ3Moc2MtPnNkYXBpbiwgR1BJT19QSU5fT1VUUFVUIHwgR1BJT19QSU5fT1BFTkRSQUlO KTsKKwlpZiAoZXJyICE9IDApCisJCWdwaW9fcGluX3NldF9hY3RpdmUoc2MtPnNkYXBpbiwgdmFs KTsKIH0KIAotLyoKLSAqIFJlc2V0IGJ1cyBieSBzZXR0aW5nIFNEQSBmaXJzdCBhbmQgdGhlbiBT Q0wuIAotICogTXVzdCBhbHdheXMgYmUgY2FsbGVkIHdpdGggZ3BpbyBidXMgbG9ja2VkLgotICov CiBzdGF0aWMgdm9pZAotZ3Bpb2lpY19yZXNldF9idXMoZGV2aWNlX3QgZGV2KQorZ3Bpb2lpY19z ZXRzY2woZGV2aWNlX3QgZGV2LCBpbnQgdmFsKQogewotCXN0cnVjdCBncGlvaWljX3NvZnRjCQkq c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc3RydWN0IGdwaW9paWNfc29mdGMgKnNjID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwogCi0JR1BJT0JVU19QSU5fU0VURkxBR1Moc2MtPnNjX2J1 c2Rldiwgc2MtPnNjX2Rldiwgc2MtPnNkYV9waW4sCi0JICAgIEdQSU9fUElOX0lOUFVUKTsKLQlH UElPQlVTX1BJTl9TRVRGTEFHUyhzYy0+c2NfYnVzZGV2LCBzYy0+c2NfZGV2LCBzYy0+c2NsX3Bp biwKLQkgICAgR1BJT19QSU5fSU5QVVQpOworCWdwaW9fcGluX3NldGZsYWdzKHNjLT5zY2xwaW4s IEdQSU9fUElOX09VVFBVVCB8IEdQSU9fUElOX09QRU5EUkFJTik7CisJZ3Bpb19waW5fc2V0X2Fj dGl2ZShzYy0+c2NscGluLCB2YWwpOwogfQogCi1zdGF0aWMgdm9pZAotZ3Bpb2lpY19zZXRwaW4o c3RydWN0IGdwaW9paWNfc29mdGMgKnNjLCBpbnQgcGluLCBpbnQgdmFsKQorc3RhdGljIGludAor Z3Bpb2lpY19nZXRzY2woZGV2aWNlX3QgZGV2KQogewotCWludAkJCQllcnI7CisJc3RydWN0IGdw aW9paWNfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCWJvb2wgdmFsOwogCi0J aWYgKHZhbCA9PSAwKSB7Ci0JCWVyciA9IEdQSU9CVVNfUElOX1NFVChzYy0+c2NfYnVzZGV2LCBz Yy0+c2NfZGV2LCBwaW4sIDApOwotCQlHUElPQlVTX1BJTl9TRVRGTEFHUyhzYy0+c2NfYnVzZGV2 LCBzYy0+c2NfZGV2LCBwaW4sCi0JCSAgICBHUElPX1BJTl9PVVRQVVQpOwotCi0JCS8qCi0JCSAq IFNvbWUgY29udHJvbGxlcnMgY2Fubm90IHNldCBvdXRwdXQgdmFsdWUgd2hpbGUgYSBwaW4gaXMg aW4KLQkJICogaW5wdXQgbW9kZS4KLQkJICovCi0JCWlmIChlcnIgIT0gMCkKLQkJCUdQSU9CVVNf UElOX1NFVChzYy0+c2NfYnVzZGV2LCBzYy0+c2NfZGV2LCBwaW4sIDApOwotCX0gZWxzZSB7Ci0J CUdQSU9CVVNfUElOX1NFVEZMQUdTKHNjLT5zY19idXNkZXYsIHNjLT5zY19kZXYsIHBpbiwKLQkJ ICAgIEdQSU9fUElOX0lOUFVUKTsKLQl9CisJZ3Bpb19waW5fc2V0ZmxhZ3Moc2MtPnNjbHBpbiwg R1BJT19QSU5fSU5QVVQpOworCWdwaW9fcGluX2lzX2FjdGl2ZShzYy0+c2NscGluLCAmdmFsKTsK KwlyZXR1cm4gKHZhbCk7CiB9CiAKLXN0YXRpYyB2b2lkCi1ncGlvaWljX3NldHNkYShkZXZpY2Vf dCBkZXYsIGludCB2YWwpCitzdGF0aWMgaW50CitncGlvaWljX2dldHNkYShkZXZpY2VfdCBkZXYp CiB7Ci0Jc3RydWN0IGdwaW9paWNfc29mdGMJCSpzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsK KwlzdHJ1Y3QgZ3Bpb2lpY19zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJYm9v bCB2YWw7CiAKLQlncGlvaWljX3NldHBpbihzYywgc2MtPnNkYV9waW4sIHZhbCk7CisJZ3Bpb19w aW5fc2V0ZmxhZ3Moc2MtPnNkYXBpbiwgR1BJT19QSU5fSU5QVVQpOworCWdwaW9fcGluX2lzX2Fj dGl2ZShzYy0+c2RhcGluLCAmdmFsKTsKKwlyZXR1cm4gKHZhbCk7CiB9CiAKLXN0YXRpYyB2b2lk Ci1ncGlvaWljX3NldHNjbChkZXZpY2VfdCBkZXYsIGludCB2YWwpCitzdGF0aWMgaW50CitncGlv aWljX3Jlc2V0KGRldmljZV90IGRldiwgdV9jaGFyIHNwZWVkLCB1X2NoYXIgYWRkciwgdV9jaGFy ICpvbGRhZGRyKQogewotCXN0cnVjdCBncGlvaWljX3NvZnRjCQkqc2MgPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldik7CisJc3RydWN0IGdwaW9paWNfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0Yyhk ZXYpOwogCi0JZ3Bpb2lpY19zZXRwaW4oc2MsIHNjLT5zY2xfcGluLCB2YWwpOworCS8qIFN0b3Ag ZHJpdmluZyB0aGUgYnVzIHBpbnMuICovCisJZ3Bpb19waW5fc2V0ZmxhZ3Moc2MtPnNkYXBpbiwg R1BJT19QSU5fSU5QVVQpOworCWdwaW9fcGluX3NldGZsYWdzKHNjLT5zY2xwaW4sIEdQSU9fUElO X0lOUFVUKTsKKworCS8qIEluZGljYXRlIHRoYXQgd2UgaGF2ZSBubyBzbGF2ZSBhZGRyZXNzICht YXN0ZXIgbW9kZSkuICovCisJcmV0dXJuIChJSUNfRU5PQUREUik7CiB9CiAKLXN0YXRpYyBpbnQK LWdwaW9paWNfZ2V0cGluKHN0cnVjdCBncGlvaWljX3NvZnRjICpzYywgaW50IHBpbikKK3N0YXRp YyB2b2lkCitncGlvaWljX2NsZWFudXAoc3RydWN0IGdwaW9paWNfc29mdGMgKnNjKQogewotCXVu c2lnbmVkIGludAkJCXZhbDsKIAotCUdQSU9CVVNfUElOX1NFVEZMQUdTKHNjLT5zY19idXNkZXYs IHNjLT5zY19kZXYsIHBpbiwgR1BJT19QSU5fSU5QVVQpOwotCUdQSU9CVVNfUElOX0dFVChzYy0+ c2NfYnVzZGV2LCBzYy0+c2NfZGV2LCBwaW4sICZ2YWwpOwotCXJldHVybiAoKGludCl2YWwpOwor CWRldmljZV9kZWxldGVfY2hpbGRyZW4oc2MtPmRldik7CisKKwlpZiAoc2MtPnNjbHBpbiAhPSBO VUxMKQorCQlncGlvX3Bpbl9yZWxlYXNlKHNjLT5zY2xwaW4pOworCisJaWYgKHNjLT5zZGFwaW4g IT0gTlVMTCkKKwkJZ3Bpb19waW5fcmVsZWFzZShzYy0+c2RhcGluKTsKIH0KIAogc3RhdGljIGlu dAotZ3Bpb2lpY19nZXRzY2woZGV2aWNlX3QgZGV2KQorZ3Bpb2lpY19wcm9iZShkZXZpY2VfdCBk ZXYpCiB7Ci0Jc3RydWN0IGdwaW9paWNfc29mdGMJCSpzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2 KTsKKwlpbnQgcnY7CiAKLQlyZXR1cm4gKGdwaW9paWNfZ2V0cGluKHNjLCBzYy0+c2NsX3Bpbikp OworCS8qCisJICogQnkgZGVmYXVsdCB3ZSBvbmx5IGJpZCB0byBhdHRhY2ggaWYgc3BlY2lmaWNh bGx5IGFkZGVkIGJ5IG91ciBwYXJlbnQKKwkgKiAodXN1YWxseSB2aWEgaGludC5ncGlvaWljLiMu YXQ9YnVzbmFtZSkuICBPbiBGRFQgc3lzdGVtcyB3ZSBiaWQgYXMKKwkgKiB0aGUgZGVmYXVsdCBk cml2ZXIgYmFzZWQgb24gYmVpbmcgY29uZmlndXJlZCBpbiB0aGUgRkRUIGRhdGEuCisJICovCisJ cnYgPSBCVVNfUFJPQkVfTk9XSUxEQ0FSRDsKKworI2lmZGVmIEZEVAorCWlmIChvZndfYnVzX3N0 YXR1c19va2F5KGRldikgJiYKKwkgICAgb2Z3X2J1c19zZWFyY2hfY29tcGF0aWJsZShkZXYsIGNv bXBhdF9kYXRhKS0+b2NkX2RhdGEpCisgICAgICAgICAgICAgICAgcnYgPSBCVVNfUFJPQkVfREVG QVVMVDsKKyNlbmRpZgorCisJZGV2aWNlX3NldF9kZXNjKGRldiwgIkdQSU8gSTJDIik7CisKKwly ZXR1cm4gKHJ2KTsKIH0KIAogc3RhdGljIGludAotZ3Bpb2lpY19nZXRzZGEoZGV2aWNlX3QgZGV2 KQorZ3Bpb2lpY19hdHRhY2goZGV2aWNlX3QgZGV2KQogewotCXN0cnVjdCBncGlvaWljX3NvZnRj CQkqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc3RydWN0IGdwaW9paWNfc29mdGMgKnNj ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCWludCBlcnI7CiAKLQlyZXR1cm4gKGdwaW9paWNf Z2V0cGluKHNjLCBzYy0+c2RhX3BpbikpOworCXNjLT5kZXYgPSBkZXY7CisKKwkvKiBBY3F1aXJl IG91ciBncGlvIHBpbnMuICovCisJZXJyID0gZ3Bpb2lpY19zZXR1cF9oaW50ZWRfcGlucyhzYyk7 CisjaWZkZWYgRkRUCisJaWYgKGVyciAhPSAwKQorCQllcnIgPSBncGlvaWljX3NldHVwX2ZkdF9w aW5zKHNjKTsKKyNlbmRpZgorCWlmIChlcnIgIT0gMCkgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5k ZXYsICJubyBwaW5zIGNvbmZpZ3VyZWRcbiIpOworCQlncGlvaWljX2NsZWFudXAoc2MpOworCQly ZXR1cm4gKEVOWElPKTsKKwl9CisKKwkvKiBTYXkgd2hhdCB3ZSBjYW1lIHVwIHdpdGggZm9yIHBp biBjb25maWcuICovCisJZGV2aWNlX3ByaW50ZihkZXYsICJTQ0wgcGluOiAlczolZCwgU0RBIHBp bjogJXM6JWRcbiIsCisJICAgIGRldmljZV9nZXRfbmFtZXVuaXQoR1BJT19HRVRfQlVTKHNjLT5z Y2xwaW4tPmRldikpLCBzYy0+c2NscGluLT5waW4sCisJICAgIGRldmljZV9nZXRfbmFtZXVuaXQo R1BJT19HRVRfQlVTKHNjLT5zZGFwaW4tPmRldikpLCBzYy0+c2RhcGluLT5waW4pOworCisJLyog QWRkIHRoZSBiaXRiYW5nIGRyaXZlciBhcyBvdXIgb25seSBjaGlsZDsgaXQgd2lsbCBhZGQgaWlj YnVzLiAqLworCWRldmljZV9hZGRfY2hpbGQoc2MtPmRldiwgImlpY2JiIiwgLTEpOworCXJldHVy biAoYnVzX2dlbmVyaWNfYXR0YWNoKGRldikpOwogfQogCiBzdGF0aWMgaW50Ci1ncGlvaWljX3Jl c2V0KGRldmljZV90IGRldiwgdV9jaGFyIHNwZWVkLCB1X2NoYXIgYWRkciwgdV9jaGFyICpvbGRh ZGRyKQorZ3Bpb2lpY19kZXRhY2goZGV2aWNlX3QgZGV2KQogewotCXN0cnVjdCBncGlvaWljX3Nv ZnRjCQkqc2M7CisJc3RydWN0IGdwaW9paWNfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0Yyhk ZXYpOworCWludCBlcnI7CiAKLQlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKLQlncGlvaWlj X3Jlc2V0X2J1cyhzYy0+c2NfZGV2KTsKKwlpZiAoKGVyciA9IGJ1c19nZW5lcmljX2RldGFjaChk ZXYpKSAhPSAwKQorCQlyZXR1cm4gKGVycik7CiAKLQlyZXR1cm4gKElJQ19FTk9BRERSKTsKLX0K KwlncGlvaWljX2NsZWFudXAoc2MpOwogCi0jaWZkZWYgRkRUCi1zdGF0aWMgcGhhbmRsZV90Ci1n cGlvaWljX2dldF9ub2RlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgZGV2KQotewotCi0JLyogV2Ug b25seSBoYXZlIG9uZSBjaGlsZCwgdGhlIGlpY2JiLCB3aGljaCBuZWVkcyBvdXIgb3duIG5vZGUu ICovCi0JcmV0dXJuIChvZndfYnVzX2dldF9ub2RlKGJ1cykpOworCXJldHVybiAoMCk7CiB9Ci0j ZW5kaWYKIAogc3RhdGljIGRldmNsYXNzX3QgZ3Bpb2lpY19kZXZjbGFzczsKIApAQCAtMjgyLDYg KzM1Nyw3IEBAIHN0YXRpYyBkcml2ZXJfdCBncGlvaWljX2RyaXZlciA9IHsKIH07CiAKIERSSVZF Ul9NT0RVTEUoZ3Bpb2lpYywgZ3Bpb2J1cywgZ3Bpb2lpY19kcml2ZXIsIGdwaW9paWNfZGV2Y2xh c3MsIDAsIDApOworRFJJVkVSX01PRFVMRShncGlvaWljLCBzaW1wbGVidXMsIGdwaW9paWNfZHJp dmVyLCBncGlvaWljX2RldmNsYXNzLCAwLCAwKTsKIERSSVZFUl9NT0RVTEUoaWljYmIsIGdwaW9p aWMsIGlpY2JiX2RyaXZlciwgaWljYmJfZGV2Y2xhc3MsIDAsIDApOwogTU9EVUxFX0RFUEVORChn cGlvaWljLCBpaWNiYiwgSUlDQkJfTUlOVkVSLCBJSUNCQl9QUkVGVkVSLCBJSUNCQl9NQVhWRVIp OwogTU9EVUxFX0RFUEVORChncGlvaWljLCBncGlvYnVzLCAxLCAxLCAxKTsKSW5kZXg6IHN5cy9k ZXYvZ3Bpby9vZndfZ3Bpb2J1cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvZ3Bpby9vZndfZ3Bp b2J1cy5jCShyZXZpc2lvbiAzNTUzMTUpCisrKyBzeXMvZGV2L2dwaW8vb2Z3X2dwaW9idXMuYwko d29ya2luZyBjb3B5KQpAQCAtNDMsOCArNDMsNiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAK ICNpbmNsdWRlICJncGlvYnVzX2lmLmgiCiAKLSNkZWZpbmUJR1BJT19BQ1RJVkVfTE9XCQkxCi0K IHN0YXRpYyBzdHJ1Y3Qgb2Z3X2dwaW9idXNfZGV2aW5mbyAqb2Z3X2dwaW9idXNfc2V0dXBfZGV2 aW5mbyhkZXZpY2VfdCwKIAlkZXZpY2VfdCwgcGhhbmRsZV90KTsKIHN0YXRpYyB2b2lkIG9md19n cGlvYnVzX2Rlc3Ryb3lfZGV2aW5mbyhkZXZpY2VfdCwgc3RydWN0IG9md19ncGlvYnVzX2Rldmlu Zm8gKik7CkBAIC0xNDAsODIgKzEzOCw2IEBAIGdwaW9fcGluX2dldF9ieV9vZndfbmFtZShkZXZp Y2VfdCBjb25zdW1lciwgcGhhbmRsCiAJcmV0dXJuIChncGlvX3Bpbl9nZXRfYnlfb2Z3X2lkeChj b25zdW1lciwgbm9kZSwgaWR4LCBwaW4pKTsKIH0KIAotdm9pZAotZ3Bpb19waW5fcmVsZWFzZShn cGlvX3Bpbl90IGdwaW8pCi17Ci0JZGV2aWNlX3QgYnVzZGV2OwotCi0JaWYgKGdwaW8gPT0gTlVM TCkKLQkJcmV0dXJuOwotCi0JS0FTU0VSVChncGlvLT5kZXYgIT0gTlVMTCwgKCJpbnZhbGlkIHBp biBzdGF0ZSIpKTsKLQotCWJ1c2RldiA9IEdQSU9fR0VUX0JVUyhncGlvLT5kZXYpOwotCWlmIChi dXNkZXYgIT0gTlVMTCkKLQkJZ3Bpb2J1c19yZWxlYXNlX3BpbihidXNkZXYsIGdwaW8tPnBpbik7 Ci0KLQkvKiBYWFhYIFVucmVzZXJ2ZSBwaW4uICovCi0JZnJlZShncGlvLCBNX0RFVkJVRik7Ci19 Ci0KLWludAotZ3Bpb19waW5fZ2V0Y2FwcyhncGlvX3Bpbl90IHBpbiwgdWludDMyX3QgKmNhcHMp Ci17Ci0KLQlLQVNTRVJUKHBpbiAhPSBOVUxMLCAoIkdQSU8gcGluIGlzIE5VTEwuIikpOwotCUtB U1NFUlQocGluLT5kZXYgIT0gTlVMTCwgKCJHUElPIHBpbiBkZXZpY2UgaXMgTlVMTC4iKSk7Ci0J cmV0dXJuIChHUElPX1BJTl9HRVRDQVBTKHBpbi0+ZGV2LCBwaW4tPnBpbiwgY2FwcykpOwotfQot Ci1pbnQKLWdwaW9fcGluX2lzX2FjdGl2ZShncGlvX3Bpbl90IHBpbiwgYm9vbCAqYWN0aXZlKQot ewotCWludCBydjsKLQl1aW50MzJfdCB0bXA7Ci0KLQlLQVNTRVJUKHBpbiAhPSBOVUxMLCAoIkdQ SU8gcGluIGlzIE5VTEwuIikpOwotCUtBU1NFUlQocGluLT5kZXYgIT0gTlVMTCwgKCJHUElPIHBp biBkZXZpY2UgaXMgTlVMTC4iKSk7Ci0JcnYgPSBHUElPX1BJTl9HRVQocGluLT5kZXYsIHBpbi0+ cGluLCAmdG1wKTsKLQlpZiAocnYgICE9IDApIHsKLQkJcmV0dXJuIChydik7Ci0JfQotCi0JaWYg KHBpbi0+ZmxhZ3MgJiBHUElPX0FDVElWRV9MT1cpCi0JCSphY3RpdmUgPSB0bXAgPT0gMDsKLQll bHNlCi0JCSphY3RpdmUgPSB0bXAgIT0gMDsKLQlyZXR1cm4gKDApOwotfQotCi1pbnQKLWdwaW9f cGluX3NldF9hY3RpdmUoZ3Bpb19waW5fdCBwaW4sIGJvb2wgYWN0aXZlKQotewotCWludCBydjsK LQl1aW50MzJfdCB0bXA7Ci0KLQlpZiAocGluLT5mbGFncyAmIEdQSU9fQUNUSVZFX0xPVykKLQkJ dG1wID0gYWN0aXZlID8gMCA6IDE7Ci0JZWxzZQotCQl0bXAgPSBhY3RpdmUgPyAxIDogMDsKLQot CUtBU1NFUlQocGluICE9IE5VTEwsICgiR1BJTyBwaW4gaXMgTlVMTC4iKSk7Ci0JS0FTU0VSVChw aW4tPmRldiAhPSBOVUxMLCAoIkdQSU8gcGluIGRldmljZSBpcyBOVUxMLiIpKTsKLQlydiA9IEdQ SU9fUElOX1NFVChwaW4tPmRldiwgcGluLT5waW4sIHRtcCk7Ci0JcmV0dXJuIChydik7Ci19Ci0K LWludAotZ3Bpb19waW5fc2V0ZmxhZ3MoZ3Bpb19waW5fdCBwaW4sIHVpbnQzMl90IGZsYWdzKQot ewotCWludCBydjsKLQotCUtBU1NFUlQocGluICE9IE5VTEwsICgiR1BJTyBwaW4gaXMgTlVMTC4i KSk7Ci0JS0FTU0VSVChwaW4tPmRldiAhPSBOVUxMLCAoIkdQSU8gcGluIGRldmljZSBpcyBOVUxM LiIpKTsKLQotCXJ2ID0gR1BJT19QSU5fU0VURkxBR1MocGluLT5kZXYsIHBpbi0+cGluLCBmbGFn cyk7Ci0JcmV0dXJuIChydik7Ci19Ci0KIC8qCiAgKiBPRldfR1BJT0JVUyBkcml2ZXIuCiAgKi8K QEAgLTQ5Miw3ICs0MTQsNyBAQCBvZndfZ3Bpb2J1c19wcm9iZShkZXZpY2VfdCBkZXYpCiAJCXJl dHVybiAoRU5YSU8pOwogCWRldmljZV9zZXRfZGVzYyhkZXYsICJPRlcgR1BJTyBidXMiKTsKIAot CXJldHVybiAoMCk7CisJcmV0dXJuIChCVVNfUFJPQkVfREVGQVVMVCk7CiB9CiAKIHN0YXRpYyBp bnQKQEAgLTUxMSw2ICs0MzMsOCBAQCBvZndfZ3Bpb2J1c19hdHRhY2goZGV2aWNlX3QgZGV2KQog CSAqLwogCWZvciAoY2hpbGQgPSBPRl9jaGlsZChvZndfYnVzX2dldF9ub2RlKGRldikpOyBjaGls ZCAhPSAwOwogCSAgICBjaGlsZCA9IE9GX3BlZXIoY2hpbGQpKSB7CisJCWlmIChPRl9oYXNwcm9w KGNoaWxkLCAiZ3Bpby1ob2ciKSkKKwkJCWNvbnRpbnVlOwogCQlpZiAoIU9GX2hhc3Byb3AoY2hp bGQsICJncGlvcyIpKQogCQkJY29udGludWU7CiAJCWlmIChvZndfZ3Bpb2J1c19hZGRfZmR0X2No aWxkKGRldiwgTlVMTCwgY2hpbGQpID09IE5VTEwpCkluZGV4OiBzeXMvZGV2L29mdy9vZndfYnVz X3N1YnIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L29mdy9vZndfYnVzX3N1YnIuaAkocmV2aXNp b24gMzU1MzE1KQorKysgc3lzL2Rldi9vZncvb2Z3X2J1c19zdWJyLmgJKHdvcmtpbmcgY29weSkK QEAgLTY5LDcgKzY5LDggQEAgc3RydWN0IGludHJfbWFwX2RhdGFfZmR0IHsKICNkZWZpbmUgRkRU Q09NUEFUX1BOUF9JTkZPKHQsIGJ1c25hbWUpIFwKIAlNT0RVTEVfUE5QX0lORk8oRkRUQ09NUEFU X1BOUF9ERVNDUiwgYnVzbmFtZSwgdCwgdCwgc2l6ZW9mKHQpIC8gc2l6ZW9mKHRbMF0pKTsKIAot I2RlZmluZSBTSU1QTEVCVVNfUE5QX0lORk8odCkgRkRUQ09NUEFUX1BOUF9JTkZPKHQsIHNpbXBs ZWJ1cykKKyNkZWZpbmUJT0ZXQlVTX1BOUF9JTkZPKHQpCUZEVENPTVBBVF9QTlBfSU5GTyh0LCBv ZndidXMpCisjZGVmaW5lCVNJTVBMRUJVU19QTlBfSU5GTyh0KQlGRFRDT01QQVRfUE5QX0lORk8o dCwgc2ltcGxlYnVzKQogCiAvKiBHZW5lcmljIGltcGxlbWVudGF0aW9uIG9mIG9md19idXNfaWYu bSBtZXRob2RzIGFuZCBoZWxwZXIgcm91dGluZXMgKi8KIGludAlvZndfYnVzX2dlbl9zZXR1cF9k ZXZpbmZvKHN0cnVjdCBvZndfYnVzX2RldmluZm8gKiwgcGhhbmRsZV90KTsKSW5kZXg6IC4KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gLgkocmV2aXNpb24gMzU1MzE1KQorKysgLgkod29ya2luZyBjb3B5KQoKUHJv cGVydHkgY2hhbmdlcyBvbjogLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1vZGlmaWVkOiBzdm46bWVyZ2VpbmZvCiMj IC0wLDAgKzAsMSAjIwogICBNZXJnZWQgL2hlYWQ6cjM1NTIxNCwzNTUyMzksMzU1Mjc0LDM1NTI3 Ni0zNTUyNzcsMzU1Mjk1LDM1NTI5OAo= --=-MzQpjdwgpxxGsx/on2aO-- From owner-freebsd-arm@freebsd.org Tue Dec 3 02:17:21 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C52EC1C32AE for ; Tue, 3 Dec 2019 02:17:21 +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 47RlxD3bbcz3Dhl for ; Tue, 3 Dec 2019 02:17:20 +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 xB32HHdK056406 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Dec 2019 18:17:18 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id xB32HH3w056405; Mon, 2 Dec 2019 18:17:17 -0800 (PST) (envelope-from fbsd) Date: Mon, 2 Dec 2019 18:17:17 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Reverting -current by date. Message-ID: <20191203021716.GA56261@www.zefox.net> References: <20191121031141.GB1837@www.zefox.net> <20191121175817.GA5375@www.zefox.net> <20191121190903.GB5375@www.zefox.net> <20191126010310.GA26370@www.zefox.net> <254A5077-DE9E-4B6A-9A4D-D9FA2F858F54@yahoo.com> <20191201213920.GA49395@www.zefox.net> <49C39BF2-0F0A-4D79-831C-89A6F853874B@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C39BF2-0F0A-4D79-831C-89A6F853874B@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 47RlxD3bbcz3Dhl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.19 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.918,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.30), ipnet: 50.1.16.0/20(0.15), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.86)[-0.859,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 02:17:21 -0000 On Mon, Dec 02, 2019 at 02:11:17PM -0800, Mark Millard wrote: > > > > I do not know if your -j2 is with or without MAKE_JOBS > being enabled for some or all jobs. > Possibly that's part of my problem. My system is -current, not intentionally modified. Is there an environment variable that now needs to be set to enable use of -j on the make command line to limit parallelism? It might explain the behavior seen when using -j2. In that case more than two compiler instances occur. Thanks for your attention! bob prohaska > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > From owner-freebsd-arm@freebsd.org Tue Dec 3 04:31:23 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2FA571C7400 for ; Tue, 3 Dec 2019 04:31:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.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 47Rpvs10JPz3Lwf for ; Tue, 3 Dec 2019 04:31:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5AwCxEAVM1l4V_Vuq8lPx6jpmRQcLjMQ.sNLb3Cz3_PeuacwObD6zUSelEYAN_q 5Nuwoj1y1RDN99_KQkrEenKpXmJSD99JGeilRJfqm9EiAOByU7kI9bnwUdR2EQ.t7aH6t70Em3T. D7AnxQHxSf9_kRB12.aJVnM56U7MhWGUUv4pljf.c2a5Ys22CbXh0PxktAF0h7Ry2aOgnw_8HVRt StT9fsBcu8jKKUW8MPhCOo2jB3zp9G3EERKwbgeF3UE.4OrVFnpljTUHhSp9oAxTVXlI0glqdPwy Mxo.jGZ9MMTMCQpteShTTSnxBA0TFWHplROy16RG7mgK9HMfzaVOeGbFpQuYR5gsygKXsY3qJy2U itSZCeu7jUwMdM8thn3YMAfW2hgXX5WVn20zdWiLwUL6Ne2S0f83bgSN2a4qNAaI.89LmQLpZCiS BLmLOqdT1iUTgefS5uRzg6yZpmtx.s3WkS2_0kXMQw7IXe6DZlgsgkg0W.HfYdL57428zo1fB7Ho UZe_Xn95P16uqer_lJGI2DQMQu7lUeq7Me_8id3oGh7.04xTL2ETj8zPjAMJeACTxosGSXvKaAlL 2gWg5glLpM9g0_czara6uGsVkTypSvxeBmMDVOH7CyeXQxzQhLI0a6azBBcdJ9QI09I.oJZn5.j3 taGSdlnSgbIgihpT.h7MBk4oId0PU.y_Pfscz0qVMMNZmvHo9h0ojLUr_s5g4nMMLcaE.ky_bIAc TkVmqDIRH48N0.2Yg7zLxPvrZVaVxqeRK1y_mlOnfXD5x_ndKXPmoZW1OYtxVMECmpkjotJAwZPD nfkoWpaKNDGzSEQTshEceTA0FJ8PEUxF1GU5fuLW1Aifi7z5RYF.TrfLpK0cvVFKT0wusyPnBYNv 4164axQM2vKEoohS4Pjd6qBiZXHjtKQjs5qVk4emhEe1FAc8s2jdE8tRLcsDoS8X4x1Qj8vv1Cti 6umAI9qg_FfmC1k6unq4WmV_uD9Xk7QTbcz79nc.DGHHpfI06DfFKv9l2.1qrl7hNZ4g64wBFLFa 7wjVFD0xfBF_hkdy_Iihvbm34oxYXl0Ng9U47HihSF_dX4oPUZZauJ7UkE4KcuYLuggK58979Xnv g5kRJCBt9JEqy3I8y0UK_EZv3chrhjZb3GTOdLBpYBMqWNAaFHru4WetCwACWaY_FtLHYUfbXHSl PQrDY.uvJcsm5qNYRU5ppukn8nnX6NapKOTtncoCumsV9OKOhZVKaxNgwry74YpL7ip3SYObFMGd mVcQ6SfRpqBmFsancM4KaZwM9hicfItI.IJKFiEZA78r0C.SlRDtEmLgN77VFX08fR00vFwILrLG 7Ts2N0XvJmv3bYti2gy_kr35wEinWnw_siQ7U2trBaFxeMKcgrC3.mprYltqIrgWZfOhY6E6_a1X CEGdh6hQrgRDvTJZIXAEhVd4ib4eEU9AUX0Sb Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Dec 2019 04:31:19 +0000 Received: by smtp413.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 02d1fb56a2c842e1cd03d677b838f9c2; Tue, 03 Dec 2019 04:31:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: Reverting -current by date. From: Mark Millard In-Reply-To: <20191203021716.GA56261@www.zefox.net> Date: Mon, 2 Dec 2019 20:31:15 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191121031141.GB1837@www.zefox.net> <20191121175817.GA5375@www.zefox.net> <20191121190903.GB5375@www.zefox.net> <20191126010310.GA26370@www.zefox.net> <254A5077-DE9E-4B6A-9A4D-D9FA2F858F54@yahoo.com> <20191201213920.GA49395@www.zefox.net> <49C39BF2-0F0A-4D79-831C-89A6F853874B@yahoo.com> <20191203021716.GA56261@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47Rpvs10JPz3Lwf X-Spamd-Bar: / X-Spamd-Result: default: False [0.14 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.20)[0.201,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[84.69.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.44)[0.436,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (6.02), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 04:31:23 -0000 On 2019-Dec-2, at 18:17, bob prohaska wrote: > On Mon, Dec 02, 2019 at 02:11:17PM -0800, Mark Millard wrote: >>=20 >>=20 >>=20 >> I do not know if your -j2 is with or without MAKE_JOBS >> being enabled for some or all jobs. >>=20 >=20 > Possibly that's part of my problem. My system is -current, > not intentionally modified. Is there an environment > variable that now needs to be set to enable use of -j on > the make command line to limit parallelism? It might explain=20 > the behavior seen when using -j2. In that case more than two=20 > compiler instances occur. >=20 I got the context wrong and my note does not apply for -j2 directly on the make command line style of doing port builds. Sorry for the noise. So ignore my earlier babble. You were directly controlling the number of targets that are allowed to run in parallel. (Presuming the port's submakes (if any) are set up to do appropriately. Also multithreading in a process is not controlled.) To explain what I was incorrectly referring to for MAKE_JOBS . . . MAKE_JOBS is ports-infrastructure control. Some of the makefiles use MAKE_JOBS_UNSAFE=3Dyes to disable allowing the make from running targets in parallel within the job, mostly because they are known to have internal race conditions or other such that can break the builds otherwise. As I remember portmaster allows -m MAKE_JOBS_UNSAFE=3Dyes or some such to force the issue. poudriere has control over such when the makefile does not force MAKE_JOBS_UNSAFE=3DYES and does so via the likes of (this shows settings that I use, not what you might want): # grep MAKE_JOBS /usr/local/etc/poudriere.conf # By default MAKE_JOBS is disabled to allow only one process per cpu # ALLOW_MAKE_JOBS=3Dyes ALLOW_MAKE_JOBS=3Dyes # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports #ALLOW_MAKE_JOBS_PACKAGES=3D"pkg ccache py*" ALLOW_MAKE_JOBS_PACKAGES=3D"pkg ccache py* gcc* llvm* ghc* *webkit* = *office* chromium* iridium* mongodb*" poudriere also has a mean of control over how many jobs it runs at once (when dependencies allow that many): # grep PARALLEL_JOBS /usr/local/etc/poudriere.conf # You can override this default by changing PARALLEL_JOBS here, or # Example to define PARALLEL_JOBS to one single job # PARALLEL_JOBS=3D1 # be more IO bound and may be worth tweaking. Default: PARALLEL_JOBS * = 1.25 # PREPARE_PARALLEL_JOBS=3D1 I had substituted PARALLEL_JOBS=3D2 for poudriere for your -j2 in my head --without even noticing. This left open the ALLOW_MAKE_JOBS for poudriere. As you can tell, it has been a while since I have used make directly for building a port. Again, sorry for the misdirection. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Dec 3 05:55:34 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0955B1C90C2 for ; Tue, 3 Dec 2019 05:55:34 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rrn11VmZz3QbS for ; Tue, 3 Dec 2019 05:55:32 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-lj1-x22d.google.com with SMTP id h23so2295079ljc.8 for ; Mon, 02 Dec 2019 21:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CSP4KHx2DoaqUzYunq10iD0PIntVWA1sBREQc5RPK4E=; b=jJliHAga4oMPFM7Y3vgKTGzWB+eXM+QnObzr263Ypy8s1t4FaB9z88pDasze4GCGab tEMlVvSgdhyItqLxwruQx3eCAADbA2UgCeJFa07+Maz+/gmj0mwwhrFgYRkaZCHFZe8j YH7hSwJxuClGfvRIcw9fdojWBhgQmPG3G3Ish2lfvrGDn+Wm3Vufq3QYb4YikoD2r56d m+tWRD4y1uj+KBFXbKi23NFgaYeehKEZz9F76Tjo1dqeFsa7/DP6/tmySL6tw1+MapwM edlA9W7LiNwvHkMbzqGulyE9JuB5FmCEpI/Sw6kzVBmufuEQflHFnxfiKK/YO2rdLQK7 Zv3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CSP4KHx2DoaqUzYunq10iD0PIntVWA1sBREQc5RPK4E=; b=kETnTrniXnzXEHbO4d5WbGuzxLa6kZ80lA++QJCaYTFjJJnCQHHJVw2Z/Z6q4u9zYc JqPtT0HSFRljjgYtLvZUAX6knhQ72ukDLFjflsbl0laDzJJDkP2Jecl3nQytQpkETFhh tCQExWkUtOHv7Mt+vfu8qrbf91Hat0Vg+6JBm4G/ac/mOp1NgtqcHwDZZplee9bPtc+r WkEqbUwcHwrtY/HnrxNx86XgfTBap79lqXOqWOflR/1B9ll+eyLl9+8YP3yrngVuWXhg kv3fsgPWCVbPD5FRnrjncoHd0Unx+JEUqporrVFfCkZSmY/YvKpHla8HKFOxpHw7Ng/I WiZg== X-Gm-Message-State: APjAAAXNN+DGsoVdfpe8knv5qcFTgBKf32qqRYlBvVQZgZIjkJaNc5Ux caEiKOQmQ+Bx/SNS5xV2QJxd2QX5ROMt8sDV1Aw58xuB X-Google-Smtp-Source: APXvYqzDYVEN5jhtQH6qba/kFpxjf4lZ/GQCDS6t1V51DYfQjDrxtBk96uOcbbpzLlX3sNjsjNxoXUI0U+kOBnC0d8E= X-Received: by 2002:a2e:8952:: with SMTP id b18mr1483705ljk.184.1575352529911; Mon, 02 Dec 2019 21:55:29 -0800 (PST) MIME-Version: 1.0 From: Sleep Walker Date: Tue, 3 Dec 2019 08:57:11 +0300 Message-ID: Subject: Ethernet driver on RK3399 To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 47Rrn11VmZz3QbS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jJliHAga; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2a00:1450:4864:20::22d as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.05), ipnet: 2a00:1450::/32(-2.69), asn: 15169(-1.94), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[d.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; HTTP_TO_IP(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 05:55:34 -0000 Hi All! I noticed the incorrect behavior of the Ethernet driver on the RK3399 (Rock-Pi-4). ---- oot@rock-pi-4:~ # uname -a FreeBSD rock-pi-4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355283M: Mon Dec 2 11:34:20 MSK 2019 root@rock-pi-4:/usr/obj/usr/src/arm64.aarch64/sys/EXPERT arm64 root@rock-pi-4:~ # ping -c 3 google.com PING google.com (173.194.222.113): 56 data bytes 64 bytes from 173.194.222.113: icmp_seq=0 ttl=44 time=40.301 ms 64 bytes from 173.194.222.113: icmp_seq=1 ttl=44 time=40.306 ms 64 bytes from 173.194.222.113: icmp_seq=2 ttl=44 time=40.260 ms --- google.com ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 40.260/40.289/40.306/0.020 ms root@rock-pi-4:~ # ifconfig -a dwc0: flags=8843 metric 0 mtu 1500 options=80008 ether b6:7c:18:64:74:d6 inet 212.192.133.48 netmask 0xffffff00 broadcast 212.192.133.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 root@rock-pi-4:~ # ifconfig dwc0 media 100baseT ifconfig: SIOCSIFMEDIA (media): Device not configured root@rock-pi-4:~ # ping -c 3 google.com PING google.com (173.194.222.102): 56 data bytes 64 bytes from 173.194.222.102: icmp_seq=0 ttl=44 time=40.296 ms 64 bytes from 173.194.222.102: icmp_seq=1 ttl=44 time=40.007 ms ^C --- google.com ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 40.007/40.151/40.296/0.144 ms root@rock-pi-4:~ # ifconfig dwc0 media 10baseT root@rock-pi-4:~ # ping -c 3 google.com ping: cannot resolve google.com: Host name lookup failure root@rock-pi-4:~ # ifconfig dwc0 media 1000baseT root@rock-pi-4:~ # ping -c 3 google.com ping: cannot resolve google.com: Host name lookup failure root@rock-pi-4:~ # ifconfig dwc0 media 100baseT ifconfig: SIOCSIFMEDIA (media): Device not configured root@rock-pi-4:~ # ifconfig dwc0 dwc0: flags=8843 metric 0 mtu 1500 options=80008 ether b6:7c:18:64:74:d6 inet 212.192.133.48 netmask 0xffffff00 broadcast 212.192.133.255 media: Ethernet 1000baseT (none) status: no carrier nd6 options=29 root@rock-pi-4:~ # ping -c 3 google.com ping: cannot resolve google.com: Host name lookup failure -------- And at a speed of 100baseT, the Ethernet driver does not work at all, it only receives packets and sends nothing to the network. --- What's wrong ? Best regards. Sergey Tyuryukanov. From owner-freebsd-arm@freebsd.org Tue Dec 3 06:44:21 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 046031CA689 for ; Tue, 3 Dec 2019 06:44:21 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from mx.i11.co (mx.i11.co [159.69.78.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RssJ6LPlz3y65; Tue, 3 Dec 2019 06:44:20 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from [82.207.42.188] (helo=thinkpad) by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ic1uv-0005E8-CB; Tue, 03 Dec 2019 06:44:13 +0000 Date: Tue, 3 Dec 2019 08:44:11 +0200 From: Nick Kostirya To: Ian Lepore Cc: Milan Obuch , freebsd-arm@freebsd.org Subject: Re: gpioiic FDT overlays for sun8i-h3 Message-ID: <20191203084411.717e87f7@thinkpad> In-Reply-To: References: <20191128152901.39dbeb4d@thinkpad> <20191128062149.577be86eb7dc15ae5805f31a@bidouilliste.com> <20191129153754.28fb5763@thinkpad> <20191129144316.739c8664@zeta.dino.sk> <20191129155431.05d4e14f@thinkpad> <20191129150944.67a2b723a6724c46f7559f96@bidouilliste.com> <0ce78262af1dd3b404b9a85a780933d7e11f008e.camel@freebsd.org> <20191129201244.0bc85b09@thinkpad> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i386-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RssJ6LPlz3y65 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 06:44:21 -0000 On Mon, 02 Dec 2019 17:04:58 -0700 Ian Lepore wrote: > Well, it did turn complicated, but I got it all worked out. > > Are you building an image from source code, or using a downloaded > snapshot or release image, or what? > > If you are building from source, apply the attached patch to your > source tree and rebuild the kernel. > > If you are using a prebuilt image, then I'll get these changes merged > to the stable-12 tree this week, and the next stable-12 snapshot images > will include what you need. I think those images get built every > Thursday. > Many thanks! You did the great job! From owner-freebsd-arm@freebsd.org Tue Dec 3 07:45:18 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C6D831CBEE3 for ; Tue, 3 Dec 2019 07:45:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.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 47RvCd4D6hz42Y0 for ; Tue, 3 Dec 2019 07:45:17 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xB37jFqt033712; Mon, 2 Dec 2019 23:45:15 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xB37jDHS033711; Mon, 2 Dec 2019 23:45:13 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201912030745.xB37jDHS033711@gndrsh.dnsmgr.net> Subject: Re: 64 bit ARM systems with more than four cores In-Reply-To: <9B00305C-115E-4D56-97A9-D34DD37F90FF@macmic.franken.de> To: Michael Tuexen Date: Mon, 2 Dec 2019 23:45:13 -0800 (PST) CC: John F Carr , "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-Rspamd-Queue-Id: 47RvCd4D6hz42Y0 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [2.12 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.88)[-0.883,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; HAS_WP_URI(0.00)[]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.56)[0.564,0]; R_SPF_NA(0.00)[]; URIBL_XBL(1.50)[amperecomputing.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.03), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 07:45:18 -0000 > > On 1. Dec 2019, at 22:37, John F Carr wrote: > > > > I have a quad core 64 bit ARM system (SoftIron Overdrive 1000). I am wondering what faster 64 bit ARM systems exist and which of them work, or almost work, with FreeBSD. > > > > Excluding 4 core and below systems regardless of performance, and also excluding cloud-only hardware, I made the list below. Did I miss anything or inaccurately describe support? > > > > Two RK3399 based systems, 2 A-72 + 4 A-53: RockPro64 (http://www.pine64.com/) and ROCK Pi 4 (http://radxa.com). I can't use the RockPro64 due to the 1.5 MBps serial port. Apparently it works or almost works with some special handling if your serial interface can count to 1,500,000. The ROCK Pi 4 is in crochet so it must work... right? Does it have a reasonable console port bit rate? > > > > SoftIron Overdrive 3000, 8 A-53 cores. No longer available. > > > > One LX2160A based system, 16 A-72 cores: HoneyComb LX2K (https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/). I see relevant files in sys/gnu/dts/arm64/freescale but nothing outside of these files imported from Linux. It's not mentioned on https://wiki.freebsd.org/arm64. My guess is that means FreeBSD does not run. Is it a little job or a big one? > > > > SC2A11, 24 A-53 cores at 1 GHz: SynQuacer (https://www.96boards.org/product/developerbox/). I don't see any evidence of SC2A11 support in the kernel tree or on https://wiki.freebsd.org/arm64. My guess is that means FreeBSD does not run. > > > > ThunderX in various forms, rack mount or workstation. Nice specs and apparently supported but the two American system builders don't seem interested in selling me one. > > > > ThunderX2. Great specs and apparently mostly supported but rather expensive.. > I'm running a system from Ampere Computing / Lenovo: > https://amperecomputing.com/ > in my lab. More specifically I believe it is one of these that Michael has: https://amperecomputing.com/wp-content/uploads/2019/04/Lenovo_ThinkSystem_HR350A_20190409.pdf > > See the dmesg output at > https://dmesgd.nycbug.org/index.cgi?do=view&id=5068 > > Best regards > Michael > > > > (Honorable mention to Banana PI M3 with 8 cores, but 32 bits only.) -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Tue Dec 3 09:09:13 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 48E3E1CEA1C for ; Tue, 3 Dec 2019 09:09:13 +0000 (UTC) (envelope-from Michael.Tuexen@macmic.franken.de) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rx4S3HMWz47LH for ; Tue, 3 Dec 2019 09:09:11 +0000 (UTC) (envelope-from Michael.Tuexen@macmic.franken.de) Received: from [10.0.1.118] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7CB9172106C30; Tue, 3 Dec 2019 10:09:08 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: 64 bit ARM systems with more than four cores From: Michael Tuexen In-Reply-To: <201912030745.xB37jDHS033711@gndrsh.dnsmgr.net> Date: Tue, 3 Dec 2019 10:08:43 +0100 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <201912030745.xB37jDHS033711@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3601.0.10) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 47Rx4S3HMWz47LH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of Michael.Tuexen@macmic.franken.de has no SPF policy when checking 193.175.24.27) smtp.mailfrom=Michael.Tuexen@macmic.franken.de X-Spamd-Result: default: False [-2.35 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; IP_SCORE(-1.65)[ip: (-8.31), ipnet: 193.174.0.0/15(-0.01), asn: 680(0.10), country: DE(-0.01)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[franken.de]; AUTH_NA(1.00)[]; HAS_WP_URI(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[27.24.175.193.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 09:09:13 -0000 > On 3. Dec 2019, at 08:45, Rodney W. Grimes = wrote: >=20 >>> On 1. Dec 2019, at 22:37, John F Carr wrote: >>>=20 >>> I have a quad core 64 bit ARM system (SoftIron Overdrive 1000). I = am wondering what faster 64 bit ARM systems exist and which of them = work, or almost work, with FreeBSD. >>>=20 >>> Excluding 4 core and below systems regardless of performance, and = also excluding cloud-only hardware, I made the list below. Did I miss = anything or inaccurately describe support? >>>=20 >>> Two RK3399 based systems, 2 A-72 + 4 A-53: RockPro64 = (http://www.pine64.com/) and ROCK Pi 4 (http://radxa.com). I can't use = the RockPro64 due to the 1.5 MBps serial port. Apparently it works or = almost works with some special handling if your serial interface can = count to 1,500,000. The ROCK Pi 4 is in crochet so it must work... = right? Does it have a reasonable console port bit rate? >>>=20 >>> SoftIron Overdrive 3000, 8 A-53 cores. No longer available. >>>=20 >>> One LX2160A based system, 16 A-72 cores: HoneyComb LX2K = (https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/). = I see relevant files in sys/gnu/dts/arm64/freescale but nothing outside = of these files imported from Linux. It's not mentioned on = https://wiki.freebsd.org/arm64. My guess is that means FreeBSD does not = run. Is it a little job or a big one? >>>=20 >>> SC2A11, 24 A-53 cores at 1 GHz: SynQuacer = (https://www.96boards.org/product/developerbox/). I don't see any = evidence of SC2A11 support in the kernel tree or on = https://wiki.freebsd.org/arm64. My guess is that means FreeBSD does not = run. >>>=20 >>> ThunderX in various forms, rack mount or workstation. Nice specs = and apparently supported but the two American system builders don't seem = interested in selling me one. >>>=20 >>> ThunderX2. Great specs and apparently mostly supported but rather = expensive.. >> I'm running a system from Ampere Computing / Lenovo: >> https://amperecomputing.com/ >> in my lab. >=20 > More specifically I believe it is one of these that Michael has: > = https://amperecomputing.com/wp-content/uploads/2019/04/Lenovo_ThinkSystem_= HR350A_20190409.pdf Correct. Best regards Michael >=20 >>=20 >> See the dmesg output at >> https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5068 >>=20 >> Best regards >> Michael >>>=20 >>> (Honorable mention to Banana PI M3 with 8 cores, but 32 bits only.) >=20 > --=20 > Rod Grimes = rgrimes@freebsd.org > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Dec 3 10:14:46 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B01591A8C34 for ; Tue, 3 Dec 2019 10:14:46 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RyX51lT9z4CDg for ; Tue, 3 Dec 2019 10:14:44 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB3AEQru065123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Dec 2019 21:14:31 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id xB3AEKPX087189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2019 21:14:20 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id xB3AEKhS087188; Tue, 3 Dec 2019 21:14:20 +1100 (AEDT) (envelope-from peter) Date: Tue, 3 Dec 2019 21:14:20 +1100 From: Peter Jeremy To: Emmanuel Vadot Cc: Michal Meloun , freebsd-arm@freebsd.org Subject: Re: rk_tsadc breaks (my) Rock64 Message-ID: <20191203101420.GA79817@server.rulingia.com> References: <20191201110716.GA41224@server.rulingia.com> <20191202111322.GF37113@server.rulingia.com> <20191202140416.936a457adebce6fca1341b18@bidouilliste.com> <20191202154548.095d7d8ec8796af15e41e47c@bidouilliste.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20191202154548.095d7d8ec8796af15e41e47c@bidouilliste.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RyX51lT9z4CDg X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-7.71 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; IP_SCORE(-3.31)[ip: (-9.64), ipnet: 2001:19f0:5800::/38(-4.83), asn: 20473(-2.02), country: US(-0.05)]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 10:14:46 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-Dec-02 15:45:48 +0100, Emmanuel Vadot wrote: >> >> Firstly, I've found that the syscon@ff100000 FDT entry attaches as two >> >> distinct devices: >> >> rk_grf0: mem 0xff100000-0xff100fff = on ofwbus0 >> >> (via compatible =3D "rockchip,rk3328-grf") >> >> simple_mfd0: mem 0xff450000-0xf= f45ffff on ofwbus0 >> >> (via compatible =3D "simple-mfd") >> >=20 >> > ??? those aren't the same devices. Yes. Looking more closely, I was wrong. There are 2 GRF devices in the RK3328 that probe/attach separately. > This isn't enough, RK3328 initialization is V2 but needs the >AUTO_Q_SEL bit too (like v3). There might be other stuff that I >haven't found yet. > That still doesn't explain why it's working for me (both DEBUG and >NODEBUG kernels). I don't understand how the SYSCON_WRITE_4() operations can work when the offsets are outside the memory range allocated to the device. The other oddity I have is that Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf Table 9-1 (the Temperature-to-code mapping table) is identical to rk3288_calib_data and looks completely different to rk3328_calib_data. (Looking more closely, the values in the two tables sum to 4096). I've tried the following, slightly more extensive patch and now get temperature readings that aren't insane (~40=B0C idle and ~52=B0C under heavy FPU load, at 1200MHz with a small heatsink and active airflow). I haven't worked through the TRM in detail to see if there's anything else missing. Index: rk_tsadc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- rk_tsadc.c (revision 355286) +++ rk_tsadc.c (working copy) @@ -98,11 +98,6 @@ int channel; }; =20 -enum tsadc_type { - RK_TSADC_V2, - RK_TSADC_V3 -}; - struct rk_calib_entry { uint32_t raw; int temp; @@ -109,13 +104,14 @@ }; =20 struct tsadc_calib_info { - bool decrement_mode; + //bool decrement_mode; struct rk_calib_entry *table; int nentries; }; =20 struct tsadc_conf { - enum tsadc_type type; + int use_syscon; + int q_sel_ntc; int shutdown_temp; int shutdown_mode; int shutdown_pol; @@ -188,7 +184,8 @@ }; =20 struct tsadc_conf rk3288_tsadc_conf =3D { - .type =3D RK_TSADC_V2, + .use_syscon=3D 0, + .q_sel_ntc=3D 0, .shutdown_temp =3D 95000, .shutdown_mode =3D 1, /* GPIO */ .shutdown_pol =3D 0, /* Low */ @@ -241,7 +238,8 @@ }; =20 static struct tsadc_conf rk3328_tsadc_conf =3D { - .type =3D RK_TSADC_V3, + .use_syscon=3D 0, + .q_sel_ntc=3D 1, .shutdown_temp =3D 95000, .shutdown_mode =3D 0, /* CRU */ .shutdown_pol =3D 0, /* Low */ @@ -296,7 +294,8 @@ }; =20 static struct tsadc_conf rk3399_tsadc_conf =3D { - .type =3D RK_TSADC_V3, + .use_syscon=3D 1, + .q_sel_ntc=3D 1, .shutdown_temp =3D 95000, .shutdown_mode =3D 1, /* GPIO */ .shutdown_pol =3D 0, /* Low */ @@ -444,11 +443,11 @@ val |=3D TSADC_AUTO_CON_POL_HI; else val &=3D ~TSADC_AUTO_CON_POL_HI; - if (sc->conf->type =3D=3D RK_TSADC_V3) + if (sc->conf->q_sel_ntc) val |=3D TSADC_AUTO_Q_SEL; WR4(sc, TSADC_AUTO_CON, val); =20 - if (sc->conf->type =3D=3D RK_TSADC_V2) { + if (!sc->conf->use_syscon) { /* V2 init */ WR4(sc, TSADC_AUTO_PERIOD, 250); /* 250 ms */ WR4(sc, TSADC_AUTO_PERIOD_HT, 50); /* 50 ms */ --=20 Peter Jeremy --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl3mNXVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzSlxg/9Hz2oeasbmcGxMjr4LPqgAY7ozF0QoYFUCzsf8DMPjNKdtufnbPqWhH+Y nqrrDGuNJqxQSs4EmX1GnFBxXIr01i7GDF7Dz4041HbvyQ8HAzcOGQ/GSkgppdnI N8FaXlkOQex3UyoQe/IoiKqRiqsi8llZ/r3I5SIR6hWA3bv33RNilpGGAjfh4TQI 1n2iN1IhEkGX8iGYlZu+wfuxUiH+35Pzpsvz33Ioqv5Q1FUauvu8HWF/muNUzU7Z aAh98QaIiZFXl0XgcnOv2idU9cz8JhyeTXcjwl+PwXfEIvClfR6I4DBsOwwid+1+ rNNCbK4sTwfmEek9ExhMV4FwSDQvqwr6HZQw/6e72FU3g82T4NsiAnms1jvaP2Be 44jtwuiNbQXy/hxZiPzuHxn0hYrCUi5HpNAEPteP9ZLXQnZsy7Uk4UnBs4TlTIm+ 4N969Wel3Zk4qF0+AJrYH6/EKhaXovSjPbJANq8+DfobE9cB/bOJjI8vks6Y7Vl4 2ZcVXAgs3RTf75PCQOwxdOUnd/DFmaLxa7VGAYahoC47ntgytbvrd5S2ooLgahFr 0ajpbTKPXDWcMvTiR7H1mySid6szu5ALXOoMntw7tCqLcaPYA5Ya8mfcYkVsuMYh 1tiWVHRY9fk7x/eFecCTGcb65AeLoJh0UAu1dVoOpFyzBwJ5cJg= =o6z7 -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-arm@freebsd.org Tue Dec 3 14:43:53 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF7191B1186; Tue, 3 Dec 2019 14:43:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S4Vc4g7dz4S9c; Tue, 3 Dec 2019 14:43:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f42.google.com with SMTP id i11so3912565ioi.12; Tue, 03 Dec 2019 06:43:52 -0800 (PST) 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; bh=nhJJR1dcj3svzazRtkC3TJd/7MXuKrkgT6Z4BKRPdas=; b=Onys3Oe3ay+uLWi59QYsjcM0ZeCMC0eeRuqR41+X6xACARZVQZ5epW6iih9+fZkBvL JsG3E5FTt9084oTdM9D79iS/AdAuPmeho6dPXwf5+M6WpZaJr7gQFimA74QqDyWHo5JI vTdq52wws/H22AgDzWrJE8h5Dx4KwQkYNKIiWg8IGEefHeLC9s+6TropNSANbwe1nlfa 13lQ7T/tG15IRY2rY8Y70rTYLW5R6lKgGCCuE9hSdunSNEvRA6HLE7fHaZPtpkQzoXJJ 0Rxnhx4QJwwYzDB9+OxiOz950kRw8/cdIve6RepanV79llyzwJnTWiJI0zL8zKWMexGf moJQ== X-Gm-Message-State: APjAAAX93ldOF9NiRw7cFqK0RCJxGe+07Ms54Mvk+zGg+4iL8ABDMhp3 ugim4y8UV08eU5AAy9KdJbDFD2YMIEnFw+U2B3oAGoyz X-Google-Smtp-Source: APXvYqwOAleyx3rY/N/HoF9TiqGaMHcuM49r1yxE7Bsx4oetLXWaiyZTul+GGwH4dr0YaAuopX7i9vpfZhMo5eK6OIs= X-Received: by 2002:a6b:3b06:: with SMTP id i6mr2424311ioa.185.1575384230466; Tue, 03 Dec 2019 06:43:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 3 Dec 2019 05:57:18 -0500 Message-ID: Subject: arm64 as Tier 1 for FreeBSD 13 To: freebsd-arch , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47S4Vc4g7dz4S9c X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.20)[ip: (-5.84), ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.94), country: US(-0.05)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[42.166.85.209.list.dnswl.org : 127.0.5.0]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[42.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 14:43:53 -0000 The FreeBSD core team recently modernized and updated the Platform Tier documentation, available at https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html. I believe that arm64 as a platform is close to being Tier 1 and would like to determine what's still needed to get there. Many of the Tier 1 guarantees are already provided on arm64. and I won't copy them here. I've provided my comments on what I see as the gaps between the Tier 1 attributes and arm64's current state, and am very interested in hearing about anything I've missed. > Binary updates and source patches for Security Advisories and Errata > Notices will be provided for supported releases. We don't do this today, but have the ability to do so for arm64 server platforms. (Due to its design, freebsd-update does not work particularly well on devices with slow root filesystems such as SD cards.) > Changes to userland ABIs will generally include compatibility shims to > ensure correct operation of binaries compiled against any stable branch > where the platform is Tier 1. These shims might not be enabled in the > default install. If compatibility shims are not provided for an ABI > change, the lack of shims will be clearly documented in the release > notes. In the past we've used the fact that a platform is no Tier 1 to make ABI-breaking changes, like switching time_t from 32 to 64 bits. I see no issue guaranteeing we will not do that on arm64. > Changes to certain portions of the kernel ABI will include compatibility > shims to ensure correct operation of kernel modules compiled against the > oldest supported release on the branch. Note that not all parts of the > kernel ABI are protected. No concern here either - in practice I believe most of the issues that could arise here will be machine-independent and need to be addressed for all platforms. > Official binary packages for third party software will be provided by the > ports team. For embedded architectures, these packages may be cross-built > from a different architecture. We do this today, although on somewhat slow and unstable hardware. I expect faster arm64 package build machines to be added in the near future. > New features which are not inherently platform-specific will be fully > functional on all Tier 1 architectures. This introduces some additional commitments on those developing new features, but in practice I believe we already generally expect new functionality to work on arm64. > Tier 1 platforms should be fully documented. Basic operations will be > documented in the FreeBSD Handbook. Some Handbook updates are warranted for arm64, although this is true for existing Tier-1 architectures as well (e.g. documenting amd64 BIOS booting but not UEFI). > Build and test automation support either in the FreeBSD.org cluster or > some other location easily available for all developers. Embedded > platforms may substitute an emulator available in the FreeBSD.org cluster > for actual hardware. We build FreeBSD/arm64 in CI and smoke test on physical hardware today. More is needed (including adding a capable ref machine to the cluster) but I don't see any significant issues here. > Developers should be able to build packages on commonly available, > non-embedded Tier 1 systems. This can mean either native builds if > non-embedded systems are commonly available for the platform in question, > or it can mean cross-builds hosted on some other Tier 1 architecture. This is somewhat of a challenge today - there aren't many arm64 platforms readily available in a configuration most suited to developer use, such as a 4- or 8-core system with 16GB of RAM and SATA- or NVMe-connected storage. Smaller systems (e.g. Pine64) are readily available but not quite capable enough; larger systems (e.g. Marvell ThunderX and Ampere eMAG) are out of reach for typical developer use. User-mode QEMU cross-builds are a possibility, but this item is one that should resolve over time as new platforms become available. From owner-freebsd-arm@freebsd.org Tue Dec 3 15:12:54 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B3C921B2111 for ; Tue, 3 Dec 2019 15:12:54 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S5853LT3z4V7G for ; Tue, 3 Dec 2019 15:12:53 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Tue, 03 Dec 2019 15:12:51 +0000 Received: from wms0-eu-central.migadu.com (wms0-eu-central.migadu.com [139.162.159.86]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 1A3586C4-867A-4FCF-8724-46E0EDBABEED.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Tue, 03 Dec 2019 15:12:50 +0000 MIME-Version: 1.0 Date: Tue, 03 Dec 2019 15:12:50 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: "Ed Maste" , "freebsd-arch" , "freebsd-arm" In-Reply-To: References: DKIM-Signature: v=1; a=rsa-sha256; bh=soqF+E0oQCAULO2DoU7B+qJjFlar7ClmdzNHIiBaUCE=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=Br9pfxi/MeDsR0CmuQges9iiK12F/m44E4SqikpDw4uPUHKVHW/QOAu/+2a5+Tap9aI9cNpk8yrjSfLgb5i3HRi5uHmv1fXpuRer1wd5Akoovt8DiUtyJss7A6n0bUi3YG+YQtDLTKGPK0nXr9vXmusRj7h8zJP4Ycw4huT/YwA= X-Rspamd-Queue-Id: 47S5853LT3z4V7G X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=Br9pfxi/; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.30)[ip: (-9.84), ipnet: 91.121.0.0/16(-3.47), asn: 16276(1.84), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 15:12:54 -0000 December 3, 2019 1:57 PM, "Ed Maste" wrote:=0A=0A>> = Developers should be able to build packages on commonly available,=0A>> n= on-embedded Tier 1 systems. This can mean either native builds if=0A>> no= n-embedded systems are commonly available for the platform in question,= =0A>> or it can mean cross-builds hosted on some other Tier 1 architectur= e.=0A> =0A> This is somewhat of a challenge today - there aren't many arm= 64=0A> platforms readily available in a configuration most suited to=0A> = developer use, such as a 4- or 8-core system with 16GB of RAM and=0A> SAT= A- or NVMe-connected storage. Smaller systems (e.g. Pine64) are=0A> readi= ly available but not quite capable enough; larger systems (e.g.=0A> Marve= ll ThunderX and Ampere eMAG) are out of reach for typical=0A> developer u= se. User-mode QEMU cross-builds are a possibility, but this=0A> item is o= ne that should resolve over time as new platforms become=0A> available.= =0A=0AThe Marvell/SolidRun MACCHIATObin is an affordable 4-core (Cortex A= 72)=0Awith DDR4 (takes one full size DIMM), SATA, USB 3.0 and PCIe.=0AAnd= most importantly, excellent firmware support (upstream EDK2+TrustedFirmw= are).=0AThe PCIe is rather quirky (I really should make a proper blog pos= t already)=0Abut I have it working with a Radeon RX 480.=0AIt can be a de= cent developer desktop if you're fine with=0A"2013 era ultrabook" levels = of performance :D=0A=0AThough honestly if we're talking just about build = machines, the RPi4 is also=0Aa 4xA72.. Of course the elephant in the room= is the RAM :(=0ABut at least it has USB 3.0 for I/O, and we won't actual= ly need to support PCIe:=0Ahttps://github.com/pftf/edk2-platforms/commit/= f6469886e216390f460494b81a4a4bf78cb66ba8=0A=0AAlso, nothing in "non-embed= ded systems" says "hardware you physically own", right?=0AAn EC2 a1.4xlar= ge (spot) instance is an excellent way to build big software. From owner-freebsd-arm@freebsd.org Tue Dec 3 15:55:14 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 862521B3817 for ; Tue, 3 Dec 2019 15:55:14 +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 47S64x1wtxz4XwF for ; Tue, 3 Dec 2019 15:55:12 +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 xB3FtFNE058758 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2019 07:55:16 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id xB3FtF8S058757; Tue, 3 Dec 2019 07:55:15 -0800 (PST) (envelope-from fbsd) Date: Tue, 3 Dec 2019 07:55:14 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: make -j1 produces four C++ instances Message-ID: <20191203155514.GA58722@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 47S64x1wtxz4XwF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.868,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.29), ipnet: 50.1.16.0/20(0.15), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.93)[-0.933,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 15:55:14 -0000 Has the -j feature for make been changed/removed? IIRC, one could in the past limit the number of jobs created while compiling software by using make -jN on the command line. Now it seems that make -j1 spawns four instances of C++ while trying to compile www/chromium. This happens to be on a Pi3 running -current, if that matters. I'm trying to keep swap use from getting ridiculous. Apologies if I'm missed a bus, thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Dec 3 16:06:12 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9CC551B3C80 for ; Tue, 3 Dec 2019 16:06:12 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S6Kb2Dtnz4YLd for ; Tue, 3 Dec 2019 16:06:11 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Tue, 03 Dec 2019 16:06:09 +0000 Received: from wms1-eu-central.migadu.com (wms1-eu-central.migadu.com [172.104.244.218]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id EBF8FA77-9EA7-4320-B81A-A29120F5358C.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Tue, 03 Dec 2019 16:06:08 +0000 MIME-Version: 1.0 Date: Tue, 03 Dec 2019 16:06:08 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: Subject: Re: make -j1 produces four C++ instances To: "bob prohaska" , freebsd-arm@freebsd.org In-Reply-To: <20191203155514.GA58722@www.zefox.net> References: <20191203155514.GA58722@www.zefox.net> DKIM-Signature: v=1; a=rsa-sha256; bh=JkW++qloCFmUHEL5ZCUg85jPzgGp4MDogvVza2+xaIo=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=cBaAFcBzDchjMlxHJ03aRRS8xNLi3T+dGGw1/rouW8GZ7Me3sIQSxN6Ud8Qt2/pdA7dJsFdtMLmjwLwHFGuloarktRMECSebWO+fvMoTKXy4bKQSaWF6HYwCw6u7faF0qDehxPAzOcA0RQnHjRufsheTKcw9DnpukLgBHmb1H48= X-Rspamd-Queue-Id: 47S6Kb2Dtnz4YLd X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=cBaAFcBz; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.30)[ip: (-9.84), ipnet: 91.121.0.0/16(-3.49), asn: 16276(1.84), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 16:06:12 -0000 December 3, 2019 6:55 PM, "bob prohaska" wrote:=0A= =0A> Has the -j feature for make been changed/removed? =0A> =0A> IIRC, on= e could in the past limit the number of jobs created=0A> while compiling = software by using =0A> make -jN =0A> on the command line. Now it seems th= at=0A> make -j1 =0A> spawns four instances of C++ while trying to compile= www/chromium.=0A=0Amake -jN won't necessarily do anything when make spaw= ns other build systems=0Awhich do their own parallelism.=0A(*some* system= s can integrate with GNU make, see e.g.=0Ahttps://github.com/ninja-build/= ninja/issues/1139 )=0A=0AChromium is mostly built using their own GN syst= em,=0Athe backend of which actually is ninja btw From owner-freebsd-arm@freebsd.org Tue Dec 3 16:15:04 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B2B811B40E3; Tue, 3 Dec 2019 16:15:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S6Wq5BPCz4Ymb; Tue, 3 Dec 2019 16:15:03 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f196.google.com with SMTP id b15so3653903ila.7; Tue, 03 Dec 2019 08:15:03 -0800 (PST) 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=uPCtsf9w+LgX6hhhEeVT98G2+uD2Nlq213gXlpK/RKE=; b=JpohL/qnvIenMBGex/V3JiiIUvN8lNIpqaw86JT+leZFKCaFDp5dBkgfIAhcomsQ6I BHozbwJ3swMqYsfUeUcBuJ1jv3cJFPPmf3I4puGukVQbU7GGER4XX3sdO+AwixvYuv+g 72msM7ufUpBvYVAlsBhLN5+MAS9XvHapWhf5C4NVisAuHzTG047SmBX+KxfyitmYY3Yt XaoQW31JCStbXEx0k1nw1i/Bk/4RI0i5S3ey1iJokcJJ0oCfO56jATA5cX+lmVLipJnw 0wWvmPWh3DXxAgndyvHT+JSMYb/5PB3+KfIOaDOAuUN9G8d64MAbjHnNBM2EvdmXd5a8 9d/w== X-Gm-Message-State: APjAAAVYFW0rZjBVAyyURmv2GERFAsjt8ah6i8FIau1+0PgaNuNmWzlD AwYWEySQGmCeyDfXiGzRqU3J2FcZmLgtVYSumuNRyxaazVM= X-Google-Smtp-Source: APXvYqxIytEkvrcUYotw+PVQzWd/N7bB14xwg1+V2K92d/QZrqzNBREcO/9Pjtz4+tVx/7+Y7qJxEDkSXtF1p6TpYu4= X-Received: by 2002:a92:bf0a:: with SMTP id z10mr5468843ilh.115.1575389702298; Tue, 03 Dec 2019 08:15:02 -0800 (PST) MIME-Version: 1.0 References: <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> In-Reply-To: <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> From: Ed Maste Date: Tue, 3 Dec 2019 07:28:31 -0500 Message-ID: Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: Greg V Cc: freebsd-arch , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47S6Wq5BPCz4Ymb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.196 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.03 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[196.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.03)[ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.94), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[196.166.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 16:15:04 -0000 On Tue, 3 Dec 2019 at 10:12, wrote: > > The Marvell/SolidRun MACCHIATObin is an affordable 4-core (Cortex A72) > with DDR4 (takes one full size DIMM), SATA, USB 3.0 and PCIe. > And most importantly, excellent firmware support (upstream EDK2+TrustedFirmware). > The PCIe is rather quirky (I really should make a proper blog post already) > but I have it working with a Radeon RX 480. > It can be a decent developer desktop if you're fine with > "2013 era ultrabook" levels of performance :D Yeah, it looks like a pretty good platform, if we can get past "quirky PCIe" to "buy x, y, z, install the image from https://..., and it will just work". I think the performance should be fine, stability and usability are more important. From owner-freebsd-arm@freebsd.org Tue Dec 3 16:20:47 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C0A11B439F for ; Tue, 3 Dec 2019 16:20:47 +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 47S6fQ2nMdz4Z0l for ; Tue, 3 Dec 2019 16:20:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id xB3GKm8U058828 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2019 08:20:49 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id xB3GKmGn058827; Tue, 3 Dec 2019 08:20:48 -0800 (PST) (envelope-from fbsd) Date: Tue, 3 Dec 2019 08:20:47 -0800 From: bob prohaska To: greg@unrelenting.technology Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: make -j1 produces four C++ instances Message-ID: <20191203162047.GB58722@www.zefox.net> References: <20191203155514.GA58722@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-Rspamd-Queue-Id: 47S6fQ2nMdz4Z0l X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.793,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.29), ipnet: 50.1.16.0/20(0.15), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.88)[-0.879,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 16:20:47 -0000 On Tue, Dec 03, 2019 at 04:06:08PM +0000, greg@unrelenting.technology wrote: > December 3, 2019 6:55 PM, "bob prohaska" wrote: > > > Has the -j feature for make been changed/removed? > > > > IIRC, one could in the past limit the number of jobs created > > while compiling software by using > > make -jN > > on the command line. Now it seems that > > make -j1 > > spawns four instances of C++ while trying to compile www/chromium. > > make -jN won't necessarily do anything when make spawns other build systems > which do their own parallelism. > (*some* systems can integrate with GNU make, see e.g. > https://github.com/ninja-build/ninja/issues/1139 ) > Which leads to: https://github.com/ninja-build/ninja/issues/1441 > Chromium is mostly built using their own GN system, > the backend of which actually is ninja btw > Implying the behavior is controlled by ninja, not make. Is there some other way to restrain parallelism in compiling www/chromium? Thanks for replying! bob prohaska From owner-freebsd-arm@freebsd.org Tue Dec 3 16:24:02 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B6BEC1B467C for ; Tue, 3 Dec 2019 16:24:02 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S6k96bbbz4ZKZ for ; Tue, 3 Dec 2019 16:24:01 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Tue, 03 Dec 2019 16:23:59 +0000 Received: from wms0-eu-central.migadu.com (wms0-eu-central.migadu.com [139.162.159.86]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 25FA0354-D533-468B-B548-054A40BC7E06.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Tue, 03 Dec 2019 16:23:59 +0000 MIME-Version: 1.0 Date: Tue, 03 Dec 2019 16:23:59 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: <122a8efab3f30e3e118995bb288e77bc@unrelenting.technology> Subject: Re: make -j1 produces four C++ instances To: "bob prohaska" Cc: freebsd-arm@freebsd.org In-Reply-To: <20191203162047.GB58722@www.zefox.net> References: <20191203162047.GB58722@www.zefox.net> <20191203155514.GA58722@www.zefox.net> DKIM-Signature: v=1; a=rsa-sha256; bh=iZFAPprCQtQb9rxChlCPgqFEPVtGeaZZtwTrTFZRShE=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=VjruP1JMkJusaSxo6e4ROT9I2Nht2wF1sIZNjBXTYBZNvjwbkxjCP5G6nu85jvnSAy/Avwhz83aka4pL5nRG+k6eeYtAcByXNWX+pQz1TUXJoIrvpfRlZrXDYZpMKXWycLnNe88Q495vlYtI4aN2U4bCnnQzuTk+Ne7Ydx6RDNg= X-Rspamd-Queue-Id: 47S6k96bbbz4ZKZ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=VjruP1JM; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.30)[ip: (-9.84), ipnet: 91.121.0.0/16(-3.51), asn: 16276(1.84), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 16:24:02 -0000 December 3, 2019 7:20 PM, "bob prohaska" wrote:=0A= =0A> Is there some other way to restrain parallelism in=0A> compiling www= /chromium?=0A=0AFind who invokes ninja and pass the -j flag *there*? From owner-freebsd-arm@freebsd.org Tue Dec 3 16:28:34 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F41211B47BC for ; Tue, 3 Dec 2019 16:28:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47S6qP5kWsz4ZQq for ; Tue, 3 Dec 2019 16:28:33 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1575390512; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=CMpuDxabJCq0A1uuxV5BzpGoRQ3xkW58T/V/CXsnEAbdz3yKi4QJQiwiX+6Nyvc2RmEGNHS0BGTe9 YJmJyNqpBNitb1FGWhYC1lDLSra8UcJmL/YNu/2wQwG18qQqQIW4Dwohzi8ovISPxqpr8MVu6NkOIi S4/hYXF9rCT/q7L4udrTJGtQd5rpUADwqfKLk5YFrTttH29PbGbwC9oa0TlJ3itqke3wa2EWpPtO6u zs+YkZaOBSKULL3UWuIc1upQIQnt6Hx+gOoPOyscucl1Yo0eTQBmylwPZ0H+R4BoS3KTKJTpDUn27z gEH8C4YRXE81nOK3+hwqxLJmrHlXLGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=3IfC1s+bMDqfbEazAAr5WM4V10Gk6Z2ja/NVCMzy/HY=; b=tKFvL/dj1vb/zAC+IDCCM0DLBbbfHC6JXVPI2mu+zN7eHRuK6B2vWCVX2phDqCOpKY53jxS/CQ8Sl FnIKLBfkV/CugLXeMazDxPfn3rvDizQPn2nwULUTpe9k6bKUioOse//H+LtPPBpjymDwfSYl0sDu6i ZZV5+AOBuU4MJw3rzaXAKPtikXkdkvYvPjfNa88BFriwD0sIEww+p1l4ztq8WbpDGUemGdq123U27V g51Lb9ArdhVhxoDGyEhSQjXChLMOAG4jdVvcLvcboXlrMq521hcNCEmXneKVwW3T+ciov312eq3xrD rak5ocofO8n1ySPhAZJXD2omAOHZ57A== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=3IfC1s+bMDqfbEazAAr5WM4V10Gk6Z2ja/NVCMzy/HY=; b=wmHUruzmISWZBNsCNO8wBsmVGFPsRskQLFL/TCdBRT8K3H5sKJlvOT5TozqF/HP/DOvEhDAI8HmY0 lctDxHIqSWx1obcOYcQPRFLx5KlB3qI48q/i/8lYkU8lqEne7YPHCAxjx/Zx5/+EU6ORREysI2HCj+ LuM3XyIHeSJy3dMup4WmIR+yZY3OBvZTy84KiSIjktrgBwRmuQ37BmQTYmwO/H+gnKS9ol+aRwdRtq uhobQluNDIbwTCiSbXLdm6Oal3Y+cB6+J7etS7wois+UIRnGKSWAHEoju7zA2/2xRQKKDnmQEgLCG8 kYP1WFfEE2vxQvXSKWNR2M++tZXk0CA== X-MHO-RoutePath: aGlwcGll X-MHO-User: f01fc4e0-15e9-11ea-829e-79a40d15cccd 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 outbound4.ore.mailhop.org (Halon) with ESMTPSA id f01fc4e0-15e9-11ea-829e-79a40d15cccd; Tue, 03 Dec 2019 16:28:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id xB3GSSJn000137; Tue, 3 Dec 2019 09:28:28 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <84bf64123583ce7b16aa60ea42c77e86fad7ba26.camel@freebsd.org> Subject: Re: make -j1 produces four C++ instances From: Ian Lepore To: bob prohaska , greg@unrelenting.technology Cc: freebsd-arm@freebsd.org Date: Tue, 03 Dec 2019 09:28:28 -0700 In-Reply-To: <20191203162047.GB58722@www.zefox.net> References: <20191203155514.GA58722@www.zefox.net> <20191203162047.GB58722@www.zefox.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47S6qP5kWsz4ZQq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.90 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.96)[-0.962,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-0.94)[-0.942,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 16:28:34 -0000 On Tue, 2019-12-03 at 08:20 -0800, bob prohaska wrote: > On Tue, Dec 03, 2019 at 04:06:08PM +0000, greg@unrelenting.technology > wrote: > > December 3, 2019 6:55 PM, "bob prohaska" > > wrote: > > > > > Has the -j feature for make been changed/removed? > > > > > > IIRC, one could in the past limit the number of jobs created > > > while compiling software by using > > > make -jN > > > on the command line. Now it seems that > > > make -j1 > > > spawns four instances of C++ while trying to compile > > > www/chromium. > > > > make -jN won't necessarily do anything when make spawns other build > > systems > > which do their own parallelism. > > (*some* systems can integrate with GNU make, see e.g. > > https://github.com/ninja-build/ninja/issues/1139 ) > > > > Which leads to: > https://github.com/ninja-build/ninja/issues/1441 > > > Chromium is mostly built using their own GN system, > > the backend of which actually is ninja btw > > > > Implying the behavior is controlled by ninja, not make. > > Is there some other way to restrain parallelism in > compiling www/chromium? > > Thanks for replying! > > bob prohaska > When building ports, it's controlled by make variables which can be set in make.conf or on the command line. The ports build machinery does what it needs to, to pass that value down into whatever build system is used within the port (cmake or ninja or whatever). make MAKE_JOBS_NUMBER=2 # like -j2 make DISABLE_MAKE_JOBS=yes # disables multiple jobs completely -- Ian From owner-freebsd-arm@freebsd.org Tue Dec 3 16:56:27 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A4B211B5916; Tue, 3 Dec 2019 16:56:27 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S7RZ2fYGz4d6P; Tue, 3 Dec 2019 16:56:25 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.206] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 8a7255bf (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 3 Dec 2019 16:56:18 +0000 (UTC) Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: greg@unrelenting.technology, Ed Maste , freebsd-arch , freebsd-arm References: <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> From: Pete Wright Message-ID: Date: Tue, 3 Dec 2019 08:56:13 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 47S7RZ2fYGz4d6P X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-4.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[239.162.243.23.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.67)[ip: (-9.28), ipnet: 174.136.96.0/20(-3.73), asn: 25795(-0.30), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 16:56:27 -0000 On 12/3/19 7:12 AM, greg@unrelenting.technology wrote: > December 3, 2019 1:57 PM, "Ed Maste" wrote: > >>> Developers should be able to build packages on commonly available, >>> non-embedded Tier 1 systems. This can mean either native builds if >>> non-embedded systems are commonly available for the platform in question, >>> or it can mean cross-builds hosted on some other Tier 1 architecture. >> This is somewhat of a challenge today - there aren't many arm64 >> platforms readily available in a configuration most suited to >> developer use, such as a 4- or 8-core system with 16GB of RAM and >> SATA- or NVMe-connected storage. Smaller systems (e.g. Pine64) are >> readily available but not quite capable enough; larger systems (e.g. >> Marvell ThunderX and Ampere eMAG) are out of reach for typical >> developer use. User-mode QEMU cross-builds are a possibility, but this >> item is one that should resolve over time as new platforms become >> available. > The Marvell/SolidRun MACCHIATObin is an affordable 4-core (Cortex A72) > with DDR4 (takes one full size DIMM), SATA, USB 3.0 and PCIe. > And most importantly, excellent firmware support (upstream EDK2+TrustedFirmware). > The PCIe is rather quirky (I really should make a proper blog post already) > but I have it working with a Radeon RX 480. > It can be a decent developer desktop if you're fine with > "2013 era ultrabook" levels of performance :D > > Though honestly if we're talking just about build machines, the RPi4 is also > a 4xA72.. Of course the elephant in the room is the RAM :( > But at least it has USB 3.0 for I/O, and we won't actually need to support PCIe: > https://github.com/pftf/edk2-platforms/commit/f6469886e216390f460494b81a4a4bf78cb66ba8 > > Also, nothing in "non-embedded systems" says "hardware you physically own", right? > An EC2 a1.4xlarge (spot) instance is an excellent way to build big software. interesting timing in regards to using AWS for builds: https://aws.amazon.com/blogs/aws/coming-soon-graviton2-powered-general-purpose-compute-optimized-memory-optimized-ec2-instances/ if these perf numbers are real, this is something i would be interested in for general purpose systems i deploy on AWS. -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-arm@freebsd.org Tue Dec 3 17:15:42 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA3311B659C for ; Tue, 3 Dec 2019 17:15:42 +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 47S7sp59whz4fWW; Tue, 3 Dec 2019 17:15:42 +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 xB3HFixa058974 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2019 09:15:45 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id xB3HFiup058973; Tue, 3 Dec 2019 09:15:44 -0800 (PST) (envelope-from fbsd) Date: Tue, 3 Dec 2019 09:15:44 -0800 From: bob prohaska To: Ian Lepore Cc: greg@unrelenting.technology, freebsd-arm@freebsd.org, bob prohaska Subject: Re: make -j1 produces four C++ instances Message-ID: <20191203171544.GC58722@www.zefox.net> References: <20191203155514.GA58722@www.zefox.net> <20191203162047.GB58722@www.zefox.net> <84bf64123583ce7b16aa60ea42c77e86fad7ba26.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84bf64123583ce7b16aa60ea42c77e86fad7ba26.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 47S7sp59whz4fWW X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 17:15:43 -0000 On Tue, Dec 03, 2019 at 09:28:28AM -0700, Ian Lepore wrote: > > When building ports, it's controlled by make variables which can be set > in make.conf or on the command line. The ports build machinery does > what it needs to, to pass that value down into whatever build system is > used within the port (cmake or ninja or whatever). > > make MAKE_JOBS_NUMBER=2 # like -j2 > make DISABLE_MAKE_JOBS=yes # disables multiple jobs completely > > Ahhh! that's what I needed to know. Thank you! bob prohaska > From owner-freebsd-arm@freebsd.org Tue Dec 3 17:19:49 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D356B1B676F; Tue, 3 Dec 2019 17:19:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S7yY5JNmz4fk0; Tue, 3 Dec 2019 17:19:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qv1-xf34.google.com with SMTP id p2so1836162qvo.10; Tue, 03 Dec 2019 09:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+r5OFJvChiGwzNRq/ShmwtXJbEg537fe7GtixqYkbE8=; b=mP/kLg9bNTQ2Ln/UCtfqXSJxHSlRJvswIY4soWnz3LRl7bw9XRes9PoOHpSv0zCuTw 8Yv0odynNaQzsnyNOCShQYK9yKgtjuruVdSf5RkfGjZdsMMKbLvC+fSAR6UL07y4jSTF jQOQhu46jvA1NbRh8dGCSxMtnAn5I6jMevF+aEoCK9uIcvBtMVb7E+5C6MCy1V67wsBi +e8LYuEYttISS3Za1oYoXRCTiG6t6IqefO9YlVrNSR5ZRR74SLsZV5YjfJqnXovjeHVJ thlNN35cPBJKr9+70WUV1r3fytvqE+DN0MCUgCqiMZEQH+RlBC0MtFBnMr2vXG6ljU7J KPLg== 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=+r5OFJvChiGwzNRq/ShmwtXJbEg537fe7GtixqYkbE8=; b=N8eX1SqgJ6IxeT9P1T06hMIlqXUPFq5sKPQCUzpn4VPwcvPgr5PZb3qHMle+MRaOjl D+PuK1C+bdsxD+2FFbL6VoWvRsABqN0HLBysvcbMB3RaIyajKO9w2mxn/I5GSimqwJYw /TqF03IOpkFDQAyNy+/WjueV9VuBuKMhTKMzDE+k8SeSkDcmdz5RnTT6hUwZYliZzWOF uUde8cVo5vkhYVUZjfPTqA3rIW6KTU+kI/ujpaEDk2/hQSKo7/odv3+bs1mv8dRyQm4X yVq+uvslSPmhqqMq0245G3A/Y/ceV61bmjS3bEKkmrIjX/o9N9Z9nLagu/q0hBl868Kx IAoQ== X-Gm-Message-State: APjAAAVJSCBkIneQYDUWj/bcuagtUNdd5tvDqEF1hIO4CX26/nVcnsPA +FXhF6nkWpYMe6t5QbmsQ7oxLrAUXTE9FETDim1X6A== X-Google-Smtp-Source: APXvYqyZdjobZRvS2GTKqP3sbfUoW9xQMiXBT5MgeH4t0+ilJ/OmFtk8QfeRIOFxOTDY3xGfju/E5btSK8HOblKuHe8= X-Received: by 2002:a0c:8a93:: with SMTP id 19mr6234282qvv.157.1575393582371; Tue, 03 Dec 2019 09:19:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Stone Date: Tue, 3 Dec 2019 12:19:31 -0500 Message-ID: Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: Ed Maste Cc: freebsd-arch , freebsd-arm , Hiroki Sato Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47S7yY5JNmz4fk0 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 17:19:49 -0000 On Tue, Dec 3, 2019 at 9:44 AM Ed Maste wrote: > > New features which are not inherently platform-specific will be fully > > functional on all Tier 1 architectures. > > This introduces some additional commitments on those developing new > features, but in practice I believe we already generally expect new > functionality to work on arm64. For eBPF, Sato-san is working on a JIT compiler. Depending on the how it winds up being implemented, it may only support JIT'ing for amd64 (one possibility being floated is an LLVM-based implementation, in which case arm64 support is a lot easier). If arm64 has to use an interpreter to run eBPF code rather than JIT'ing it, is that acceptable for a tier-1 platform? From owner-freebsd-arm@freebsd.org Tue Dec 3 18:45:11 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B0DAC1B9395; Tue, 3 Dec 2019 18:45:11 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S9s26cglz3Hvt; Tue, 3 Dec 2019 18:45:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f194.google.com with SMTP id z90so2091721ilc.8; Tue, 03 Dec 2019 10:45:10 -0800 (PST) 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=o7LOtveNNWBHq6VKmBhv0UXk8eYuyRlKArvVzdb1Xfo=; b=o0glSsduQXUgxqkZ9uTTgN63RAmD2f0upnenAOs9C6nvrvXNCn4sJfFr/gOQWnSq0Z 5gnXj9dTmkeZGYHPJMQvYrnI8ifkBPKWE3xkR+RZTiQ6es95R8Reh/TNtk6foU5/vy6p FOBhy0yD38cTWAj51FmBam7lFbrk8omjH3zTRnz869ua22S0YOli8XVtjUNnVZ8rXinR 6GgckkfgeI0PxpwfwUZ7nvoLGTKLcEhHl4ZcZxJzwvX1TI+5MjTbb/EadpH8RKt/5Jqn YpTYFSFb5bgabBKlWzPbhuLoLe2CCS3d8DWeHWxxqcqbGYaJeAQh6gjce50Q+uJwCZXg qtiA== X-Gm-Message-State: APjAAAWnRzIZGCVB0G1/PwJ6TuFS7lkevWklEciw3XIj13iv0MvQDGth P64AKV27IodtZmlC1lyWJmlSXWRH6sd3ySRkeupC/zXXWSs= X-Google-Smtp-Source: APXvYqzj+AtpkPsW1eXTJ3loHMrj25PHGFKIxikseJRz97ZDNKZjXR4lOT0a1+46XL28Pt7b2OTCvWJuGL54hEAIavQ= X-Received: by 2002:a92:4647:: with SMTP id t68mr5816935ila.18.1575398709659; Tue, 03 Dec 2019 10:45:09 -0800 (PST) MIME-Version: 1.0 References: <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> In-Reply-To: From: Ed Maste Date: Tue, 3 Dec 2019 09:58:38 -0500 Message-ID: Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: Pete Wright Cc: Greg V , freebsd-arch , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47S9s26cglz3Hvt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.194 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[194.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.17)[ip: (-0.69), ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.94), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 18:45:11 -0000 On Tue, 3 Dec 2019 at 11:56, Pete Wright wrote: > > interesting timing in regards to using AWS for builds: > https://aws.amazon.com/blogs/aws/coming-soon-graviton2-powered-general-purpose-compute-optimized-memory-optimized-ec2-instances/ > > if these perf numbers are real, this is something i would be interested > in for general purpose systems i deploy on AWS. Hardware availability implied in this announcement will help support tier 1, and I think also contributes to the desire for it to become tier 1 (to support a compelling cloud offering). From owner-freebsd-arm@freebsd.org Tue Dec 3 18:51:11 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9D5B1B96AA; Tue, 3 Dec 2019 18:51:11 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S9zy2MDcz3JPf; Tue, 3 Dec 2019 18:51:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f41.google.com with SMTP id s2so4915989iog.10; Tue, 03 Dec 2019 10:51:10 -0800 (PST) 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=v++jeO3ACUFwELf+niFDWLYeKbgNV9Rq9Jx8DgFuwNI=; b=Swqi1EtRwD/eKOnnfC2oHtZDI1PH2Y16msMEDqYEzH+Nkwb9s7Q9tfNQYTy6WjIH6H NV7xoyi90myh7ahVD0TEAAMxZUOA53HoSA8oIqWdlVi0FC7u2+Sf8/jG9k+JF4p1Xxgg NAQ7mpKc4Qj/cK4MeWpwupZR0bVyXi+pG1M1C2+5gmwqRgiPL1XD3n5OBD8afSQeLPDe CgmbNkhOMMLiT+XLg1EJRzECxBxMfv3JujRQLWDUI2mnWEPeYYUZVvcnRHtBAVtRHfQy 9p/jQqgGeMknT/KKyLrIwnI9uVXRgo8QSLM8o3I2wS6U5Zgvo6OcQEyXXqAZDiG9kexl xSaQ== X-Gm-Message-State: APjAAAUzxVPbRdNeucL3ITqJ6PXs46UTsv54Gu/w41GxGY1axAY2LKhp Wv238TYi6zgaxyi28PBS+hy4vlSgdej+f3WuGZ6WaCuvoRY= X-Google-Smtp-Source: APXvYqylUOtrAZX/cOj1MQGZ7j2XsAB4GIigpSbFZ6Vwf9vq0+llO1sF84AwZXxGqd/SU/+5ILzIO4K6762B18NOaxc= X-Received: by 2002:a6b:c34b:: with SMTP id t72mr3367877iof.17.1575399068424; Tue, 03 Dec 2019 10:51:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 3 Dec 2019 10:04:37 -0500 Message-ID: Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: Ryan Stone Cc: freebsd-arch , freebsd-arm , Hiroki Sato Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47S9zy2MDcz3JPf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.41 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.87 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[41.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.87)[ip: (-4.24), ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.94), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[41.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 18:51:11 -0000 On Tue, 3 Dec 2019 at 12:19, Ryan Stone wrote: > > For eBPF, Sato-san is working on a JIT compiler. Depending on the how > it winds up being implemented, it may only support JIT'ing for amd64 > (one possibility being floated is an LLVM-based implementation, in > which case arm64 support is a lot easier). If arm64 has to use an > interpreter to run eBPF code rather than JIT'ing it, is that > acceptable for a tier-1 platform? I don't think that it should be a requirement for tier 1. We could argue that the feature exists on all platforms, but performance optimizations exist on only a subset. That said, if we end up with a bespoke (non-LLVM) JIT I hope we'd also add arm64. From owner-freebsd-arm@freebsd.org Tue Dec 3 23:00:24 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 567741C0F02 for ; Tue, 3 Dec 2019 23:00:24 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (flets-sg1026.kamome.or.jp [202.216.24.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SHWV1RJmz45jK for ; Tue, 3 Dec 2019 23:00:21 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [202.216.24.26]) by kx.truefc.org (8.15.2/8.15.2) with ESMTP id xB3N0FGC061069; Wed, 4 Dec 2019 08:00:15 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <201912032300.xB3N0FGC061069@kx.truefc.org> Date: Wed, 04 Dec 2019 08:00:15 +0900 From: KIRIYAMA Kazuhiko To: freebsd-arm@freebsd.org Subject: Can't boot arm64 image by qemu-system-aarch64 User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 47SHWV1RJmz45jK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of kiri@truefc.org has no SPF policy when checking 202.216.24.26) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-0.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.80)[-0.805,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.77)[-0.769,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[truefc.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4704, ipnet:202.216.0.0/19, country:JP]; IP_SCORE(0.00)[country: JP(0.02)]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 23:00:24 -0000 Hi, all # I've posted freebsd-virtualization,but any responces. # Sorry for same posting. I've installed successfully by qemu-system-aarch64 below: root@vm:/vm/test # truncate -s 16g test.img root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu cortex-a57 -name test -bios QEMU_EFI.fd -nographic -hda test.img -hdc FreeBSD-13.0-CURRENT-arm64-aarch64-20191127-r355121-memstick.img and rebooted successfully and login with root: root@test:~ # uname -a FreeBSD test.tfc 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355121: Wed Nov 27 03:49:21 UTC 2019 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 root@test:~ # df -h Filesystem Size Used Avail Capacity Mounted on /dev/vtbd0p2 14G 1.3G 12G 10% / devfs 1.0K 1.0K 0B 100% /dev root@test:~ # ifconfig vtnet0: flags=8843 metric 0 mtu 1500 options=80028 ether 52:54:00:12:34:56 inet 192.168.1.196 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet 10Gbase-T status: active nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 root@test:~ # So, I shutdowned and run by qemu-system-aarch64: root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu cortex-a57 -name test -bios QEMU_EFI.fd -nographic -drive if=none,format=raw,file=test.img,id=hd0 -device virtio-blk-device,drive=hd0 -device virtio-net-device,netdev=net0 -netdev tap,id=net0,ifname=tap2 But failed to boot: BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Found >>Start PXE over IPv4. where, tap2 is ready to use: root@vm:/vm/test # ifconfig tap2 tap2: flags=8902 metric 0 mtu 1500 description: vmnet-test-0-local options=80000 ether 58:9c:fc:10:ec:02 groups: tap qemu-port media: Ethernet autoselect status: no carrier nd6 options=21 root@vm:/vm/test # What's wrong ? Best regards. --- Kiriyama Kazuhiko From owner-freebsd-arm@freebsd.org Tue Dec 3 23:15:45 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8A12B1C175C for ; Tue, 3 Dec 2019 23:15:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 47SHsD4DVVz472l for ; Tue, 3 Dec 2019 23:15:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Me051kEVM1mF4FWCJLpqQBOlh76jT7.3AsqKUBV1VhGX.8cqOsdOuda1EgEOd_d 9.iAKwBPCaynGiHm6rOc_7Y2teIpcURNC45r8pVnEpRSuqLDvAIo3MI11zdXgUZ_TSf8mFHeTUT8 pBJsE0bculyTGFe3ZXi5goJgkEOciTB3dFtDkQukeQ9Nxrxc47BEx4XMAl320XyRX.D3OW1n3tY_ WU6xbGthttyHDwgFGP54nUM6.dv111yeC8e5XpJeRBYeXz1VSl.1S1sGYiyGSP4hHcV6DCckE69B Oe5IvaY5JA2uWH3r98xHeUhmxCqAGyvHoIENnV_LRgU6XoOFiHmplP6eeltheQRsH2zjiYzyOtr. u0Z8s8Mph.SM0Ni2jx5nuJAktO50ut2JhJA_nVusQcukfJeSPVD_pwwGJjn0PMECZVEjaxdV4cDj .71_tSqb_yfhSah5MO_TC8ndRg66pDyhIfWsLHa4s4X0sheoP.bF23LKqdmNFcpScFgucx_bPpkV 33FL3iZb5yqJB7DqhM4jrgEpiNCcMhf5MYnEeIscc_pCI11QzBwlUSWrgD7sBEnf6w.GG3K7LLpG noufabDMs1dx_4Gi48zDAjV_jhyaKHgs1Q03XkcGWu7an9dF6Bc4Qw6VB6YolbORP_f93RXZNO1T WemT6yRkonA8o32eFDKO.qwlrFlp2mo1rW5DBnv3fdYK7nL9J_NrMHqAHG4BAa5JrEfZWu2hFafJ Hv.2AK6v2NC6GGHccvHE67X9DdMVrPE9CmaeYfSej4iDRIi.TRSXlVD0nrOL_wZsjOdyUaQDHT22 ckcEoMG6OT9SzeImVYB0WU0wuszppFhzWSkzAjK83QUbBb.lpTh7dEk3JrhDGBW5AlapJ8REq5L4 w9TFki5D515sMliA_wlxooVDOy7RJ.St.dHpsPeRAI75_IVWp5c278V4j1xnCK560k54vKyoFdVN KkL2_0vl52vztile7Q9p5vKA66Hdo1KteFWml1KgEg26U7ndWj3US.2AVx0ZTF_sfStWcVMNeSST bfKf0S0jytBAlOfEhBrQPd.Pgb_mP_FizjJDpGUJIdYwpPSVo2ozSZxOiyHhPhf4BQWMq.LKRc2U VDDDSmgNsds6NfUQTVNmP.ILT6pakSHw5008gPLUImQxjfsThziRKiKPGZL0XSchLbvU0qlo4Yqq cFUzJhSa5k3AqqCWT15wuDdH_SYiljDGQ8aCSXiD0ZLc5EUxJ6yq6oBYYPBy2d4rNydb5vdJrpSp 1muk7DsfoYvbbJma17d2GIi93fiVYvyfR.vCR2Qd0IFu__45ORGEF471N2HM9aG_.1uYKKKc8saq XjYmfEkpfPycE2CHde65sDAHBvimSHOg8K1mVfaaltFVFOSojHWWby1o3W4Y195lUJ3ZSYzjQ.fG zTLW7Mgp7QPAqT2W_qJVUHmEqn7EwoFCBs9_1cA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Dec 2019 23:15:42 +0000 Received: by smtp417.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c3a8bffae04e1673f875433888ed64f1; Tue, 03 Dec 2019 23:15:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: arm64 as Tier 1 for FreeBSD 13 From: Mark Millard In-Reply-To: Date: Tue, 3 Dec 2019 15:15:40 -0800 Cc: Greg V , freebsd-arm , freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <4DE00648-791D-41A9-8037-0834D16F3CEF@yahoo.com> References: <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> To: Ed Maste X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47SHsD4DVVz472l X-Spamd-Bar: / X-Spamd-Result: default: False [0.54 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.48)[0.482,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; NEURAL_SPAM_LONG(0.56)[0.560,0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (8.20), ipnet: 98.137.64.0/21(0.88), asn: 36647(0.70), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 23:15:45 -0000 On 2019-Dec-3, at 04:28, Ed Maste wrote: > On Tue, 3 Dec 2019 at 10:12, wrote: >>=20 >> The Marvell/SolidRun MACCHIATObin is an affordable 4-core (Cortex = A72) >> with DDR4 (takes one full size DIMM), SATA, USB 3.0 and PCIe. >> And most importantly, excellent firmware support (upstream = EDK2+TrustedFirmware). >> The PCIe is rather quirky (I really should make a proper blog post = already) >> but I have it working with a Radeon RX 480. >> It can be a decent developer desktop if you're fine with >> "2013 era ultrabook" levels of performance :D >=20 > Yeah, it looks like a pretty good platform, if we can get past "quirky > PCIe" to "buy x, y, z, install the image from https://..., and it will > just work". I think the performance should be fine, stability and > usability are more important. The MACCHIATObin that I have access to (sometimes) was from: https://www.picocluster.com/products/pico-macchiatobin But, with the top on, there is not much room above the PCIe slot for the case involved: may be an inch or so. (I've never used the PCIe slot.) The SSD mount place is on the top piece. (There are pictures.) Greg provided an edk2 based image for UEFI and I set the jumpers to use it from the uSD card slot. I had to set it to use ACPI information instead of dtb to get it to work. It found and booted the SSD. It would be nice to have a port that produced a similar image, possibly preset to ACPI style. (The uSD card choice avoided any potential of messing up in a non-recoverable way in trying to update an on-board area. Just my choice to use a simple dd to a uSD card.) For EtherNet I'm using a USB3 adapter: none of the on board EtherNet ports are supported (yet?). (The context is based on head -r355027 currently.) I'm not sure about having rc.conf cause DHCP handling for ue0 instead of later. (ue0 not ready yet that early?) I've been doing "dhclient ue0" later via the serial console. I'm using a serial port connection and ssh access via EtherNet, much like I do for an OverDrive 1000. As stands, the boot messages between about the last from the loader into some from world do not show up on the serial port. (The MACCHIATObin is not configured for video output so I do not know about what would show up there if enabled.) I've done buildworld buildkernel and built a few hundred ports (multiple times). Other than points noted above, I've not seen any oddities in such basic use. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Dec 3 23:54:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7AD441C2500 for ; Tue, 3 Dec 2019 23:54:06 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SJjT1pqlz48r5 for ; Tue, 3 Dec 2019 23:54:04 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Tue, 03 Dec 2019 23:54:02 +0000 Received: from wms0-eu-central.migadu.com (wms0-eu-central.migadu.com [139.162.159.86]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id E93E9FC4-97A8-4DB8-A568-25DBABE0B13A.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Tue, 03 Dec 2019 23:54:01 +0000 MIME-Version: 1.0 Date: Tue, 03 Dec 2019 23:54:01 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: <01ca147741c3ee9b120b05d267bc4101@unrelenting.technology> Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: "Mark Millard" , "Ed Maste" Cc: "freebsd-arm" , "freebsd-arch" In-Reply-To: <4DE00648-791D-41A9-8037-0834D16F3CEF@yahoo.com> References: <4DE00648-791D-41A9-8037-0834D16F3CEF@yahoo.com> <6d9f394c670a8426c61a3d075ffaf3e9@unrelenting.technology> DKIM-Signature: v=1; a=rsa-sha256; bh=q/5vP2w+bJmgoEZuMG+Y8/P2xszFYqUwsX/T3BvdZbw=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=jUSYecP+vuHsSD3uJ5pM7qeABe1gNRiraEe5+8pAwKNyNnrJObnr9i67Cn6E5QT7fZqx7aS2ir89fLOEZGc8PqnB7RmGNfgK9uEkUZtvALRR2QSRgXP2DteNYK3O6sgUf0MzCaPr6NTy2lo+38KgO1BasAB8H1BO1tuPH2JX6dk= X-Rspamd-Queue-Id: 47SJjT1pqlz48r5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=jUSYecP+; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-5.31 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.31)[ip: (-9.85), ipnet: 91.121.0.0/16(-3.56), asn: 16276(1.84), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 23:54:06 -0000 December 4, 2019 2:15 AM, "Mark Millard" wrote:=0A=0A= > The MACCHIATObin that I have access to (sometimes) was=0A> from:=0A> = =0A> https://www.picocluster.com/products/pico-macchiatobin=0A=0AThat acr= ylic case for 99 dollars?? That's kinda ridiculous.=0AI guess that includ= es a power supply but it looks like a=0Avery basic one, plugs into the ba= rrel jack instead of the=0AATX socket.=0A=0AI would not be surprised if a= full GPU load on a reference=0ARX 480 card just melted that power jack := )=0A=0A> Greg provided an edk2 based image for UEFI and I set the=0A> jum= pers to use it from the uSD card slot. I had to set it=0A> to use ACPI in= formation instead of dtb to get it to work.=0A> It found and booted the S= SD. It would be nice to have a=0A> port that produced a similar image, po= ssibly preset to=0A> ACPI style.=0A=0AActually having a port is not a bad= idea, there's edk2=0Afor virtual machines (OVMF) already.=0A=0A> (The uS= D card choice avoided any potential of messing up=0A> in a non-recoverabl= e way in trying to update an on-board=0A> area. Just my choice to use a s= imple dd to a uSD card.)=0A=0AIt's actually always recoverable. The boot = ROM can always=0Aboot from uSD and even from the serial port (!):=0A=0Aht= tps://developer.solid-run.com/knowledge-base/a388-u-boot/#booting-from-ua= rt=0A=0A(the docs are from another SoC but it's the same here) From owner-freebsd-arm@freebsd.org Wed Dec 4 00:55:47 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93FBE1C40BD for ; Wed, 4 Dec 2019 00:55:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SL4d4t9vz4CLp for ; Wed, 4 Dec 2019 00:55:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x733.google.com with SMTP id c124so5559167qkg.0 for ; Tue, 03 Dec 2019 16:55:45 -0800 (PST) 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=cuO+yvSI2la23rnv4lVQP9nTnravmjER7xz5WBfKxlw=; b=VU9F/JAmqensOQWOLHKMvM8qOqOMDvXzNHtNgsNqZo7uQwzCfoe7wef6KSxpPl1a4W VPlevEE/ulzxirnVBXW10Mpp1YPq19OvGJuMCk/eky9WwfMVNmLHEEV7HOeNlg1t5cfP vOomauQ7yPLJbnWXd1cTQQyZcPGrxT56sh4lYY88L9wcAtJxOFp0UBhEhRjnb5Hy5LZX TTS9zCwEYTmsu9Mg7nc4yco7axINgZ02iVopBoP08Ts/ZOWced++YSSVWcokBNkFUVxD a65WexcWKmmwB2jYEtHIgMZyfijmHw0se2xV+DwUmpZ/zBX/xXjQp607cNasGOR6oGbi r9Dg== 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=cuO+yvSI2la23rnv4lVQP9nTnravmjER7xz5WBfKxlw=; b=DjGyMiFMM8zAl0vRCODsZvfCWCnt0E0qWZ9ePJ0bhLBQfytCu8OmWjAdZROmkMjtCI RcV/nXYl+8XOWObRnCl1veb3dgvislHZq1tzK8o2aZoFVN2xIF2vaO6YaJDixPS1iMj1 IioB3LvrsXm4EAWrbLkb/tPJgee3qY4zgg9vf0U3j4zQddI/SenvL7eFR4eWki6RW1LY j24ytrESj/l8QkiTqnXXgArnx/8HzjTfH0pKVaII9mP52U+M0l8FJg8oq60+id1Kxqmm 9lUWIpUy6O9kXDcd3+HnGRq7rsxo2rfCXJWm9VvPnuFK5G3YpeigJz3FdvkgRb4bkdsH ttPg== X-Gm-Message-State: APjAAAVTmCf8UtXPMW6hxD1GbxSa9/Rf2Vp63Q7K4EehMqa31xcVnlTs I5/xzYhIBnSxWNl49aatksAjcB6qDtQNGBR92fwwZMmqFw0= X-Google-Smtp-Source: APXvYqzv45kCtF/s5lPbHbfeQ2Tja/HdSPwoic0PwDFUmzcEeqJF9Bi4YfPq6NAI7MRyucqyW5MW8vo3sUZQHCzQsuE= X-Received: by 2002:a37:a3d2:: with SMTP id m201mr245366qke.495.1575420942939; Tue, 03 Dec 2019 16:55:42 -0800 (PST) MIME-Version: 1.0 References: <201912032300.xB3N0FGC061069@kx.truefc.org> In-Reply-To: <201912032300.xB3N0FGC061069@kx.truefc.org> From: Warner Losh Date: Tue, 3 Dec 2019 17:55:30 -0700 Message-ID: Subject: Re: Can't boot arm64 image by qemu-system-aarch64 To: KIRIYAMA Kazuhiko Cc: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 47SL4d4t9vz4CLp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=VU9F/JAm; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::733) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.69 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[3.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.69)[ip: (-9.24), ipnet: 2607:f8b0::/32(-2.24), asn: 15169(-1.93), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 00:55:47 -0000 On Tue, Dec 3, 2019, 4:00 PM KIRIYAMA Kazuhiko wrote: > Hi, all > > # I've posted freebsd-virtualization,but any responces. > # Sorry for same posting. > > I've installed successfully by qemu-system-aarch64 below: > > root@vm:/vm/test # truncate -s 16g test.img > root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu > cortex-a57 -name test -bios QEMU_EFI.fd -nographic -hda test.img -hdc > FreeBSD-13.0-CURRENT-arm64-aarch64-20191127-r355121-memstick.img > > and rebooted successfully and login with root: > > root@test:~ # uname -a > FreeBSD test.tfc 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355121: Wed Nov 27 > 03:49:21 UTC 2019 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC > arm64 > root@test:~ # df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/vtbd0p2 14G 1.3G 12G 10% / > devfs 1.0K 1.0K 0B 100% /dev > root@test:~ # ifconfig > vtnet0: flags=8843 metric 0 mtu > 1500 > options=80028 > ether 52:54:00:12:34:56 > inet 192.168.1.196 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet 10Gbase-T > status: active > nd6 options=29 > lo0: flags=8049 metric 0 mtu 16384 > options=680003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=21 > root@test:~ # > > So, I shutdowned and run by qemu-system-aarch64: > > root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu > cortex-a57 -name test -bios QEMU_EFI.fd -nographic -drive > if=none,format=raw,file=test.img,id=hd0 -device virtio-blk-device,drive=hd0 > -device virtio-net-device,netdev=net0 -netdev tap,id=net0,ifname=tap2 > > But failed to boot: > > BdsDxe: failed to load Boot0001 "UEFI Misc Device" from > VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found > BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from > VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Found > > >>Start PXE over IPv4. > > > where, tap2 is ready to use: > > root@vm:/vm/test # ifconfig tap2 > tap2: flags=8902 metric 0 mtu 1500 > description: vmnet-test-0-local > options=80000 > ether 58:9c:fc:10:ec:02 > groups: tap qemu-port > media: Ethernet autoselect > status: no carrier > nd6 options=21 > root@vm:/vm/test # > > What's wrong ? > Where did the efi firmware come from? Warner > Best regards. > --- > Kiriyama Kazuhiko > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Wed Dec 4 01:21:59 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD10F1C4D4D for ; Wed, 4 Dec 2019 01:21:59 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (flets-sg1026.kamome.or.jp [202.216.24.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SLft0X94z4DSZ for ; Wed, 4 Dec 2019 01:21:57 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [202.216.24.26]) by kx.truefc.org (8.15.2/8.15.2) with ESMTP id xB41LpIp062796; Wed, 4 Dec 2019 10:21:52 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <201912040121.xB41LpIp062796@kx.truefc.org> Date: Wed, 04 Dec 2019 10:21:51 +0900 From: KIRIYAMA Kazuhiko To: Warner Losh Cc: KIRIYAMA Kazuhiko , freebsd-arm@freebsd.org Subject: Re: Can't boot arm64 image by qemu-system-aarch64 In-Reply-To: References: <201912032300.xB3N0FGC061069@kx.truefc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 47SLft0X94z4DSZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of kiri@truefc.org has no SPF policy when checking 202.216.24.26) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-0.03 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.589,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[truefc.org]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.55)[-0.547,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4704, ipnet:202.216.0.0/19, country:JP]; IP_SCORE(0.00)[country: JP(0.02)]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 01:21:59 -0000 Hi, Warner On Wed, 04 Dec 2019 09:55:30 +0900, Warner Losh wrote: >=20 > [1 ] >=20 > [2 ] >=20 >=20 >=20 >=20 > On Tue, Dec 3, 2019, 4:00 PM KIRIYAMA Kazuhiko wrote: >=20 >=20 > Hi, all > =20 > # I've posted freebsd-virtualization,but any responces. > # Sorry for same posting. > =20 > I've installed successfully by qemu-system-aarch64 below: > =20 > root@vm:/vm/test # truncate -s 16g test.img > root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu c= ortex-a57 -name test > -bios QEMU_EFI.fd -nographic -hda test.img -hdc > FreeBSD-13.0-CURRENT-arm64-aarch64-20191127-r355121-memstick.img > =20 > and rebooted successfully and login with root: > =20 > root@test:~ # uname -a > FreeBSD test.tfc 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355121: Wed N= ov 27 03:49:21 UTC 2019=A0 > =A0 =A0root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/s= ys/GENERIC=A0 arm64 > root@test:~ # df -h > Filesystem=A0 =A0 =A0 Size=A0 =A0 Used=A0 =A0Avail Capacity=A0 Mount= ed on > /dev/vtbd0p2=A0 =A0 =A014G=A0 =A0 1.3G=A0 =A0 =A012G=A0 =A0 10%=A0 = =A0 / > devfs=A0 =A0 =A0 =A0 =A0 =A01.0K=A0 =A0 1.0K=A0 =A0 =A0 0B=A0 =A0100= %=A0 =A0 /dev > root@test:~ # ifconfig > vtnet0: flags=3D8843 metric = 0 mtu 1500 > =A0 =A0 =A0 =A0 options=3D80028 > =A0 =A0 =A0 =A0 ether 52:54:00:12:34:56 > =A0 =A0 =A0 =A0 inet 192.168.1.196 netmask 0xffffff00 broadcast 192.= 168.1.255 > =A0 =A0 =A0 =A0 media: Ethernet 10Gbase-T > =A0 =A0 =A0 =A0 status: active > =A0 =A0 =A0 =A0 nd6 options=3D29 > lo0: flags=3D8049 metric 0 mtu 16384 > =A0 =A0 =A0 =A0 options=3D680003 > =A0 =A0 =A0 =A0 inet6 ::1 prefixlen 128 > =A0 =A0 =A0 =A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > =A0 =A0 =A0 =A0 inet 127.0.0.1 netmask 0xff000000 > =A0 =A0 =A0 =A0 groups: lo > =A0 =A0 =A0 =A0 nd6 options=3D21 > root@test:~ # > =20 > So, I shutdowned and run by qemu-system-aarch64: > =20 > root@vm:/vm/test # qemu-system-aarch64 -machine virt -m 4096M -cpu c= ortex-a57 -name test > -bios QEMU_EFI.fd -nographic -drive if=3Dnone,format=3Draw,file=3Dte= st.img,id=3Dhd0 -device > virtio-blk-device,drive=3Dhd0 -device virtio-net-device,netdev=3Dnet= 0 -netdev > tap,id=3Dnet0,ifname=3Dtap2 > =20 > But failed to boot: > =20 > BdsDxe: failed to load Boot0001 "UEFI Misc Device" from > VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found > BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from > VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Fo= und > =20 > >>Start PXE over IPv4. > =20 > =20 > where, tap2 is ready to use: > =20 > root@vm:/vm/test # ifconfig tap2 > tap2: flags=3D8902 metric 0 mtu= 1500 > =A0 =A0 =A0 =A0 description: vmnet-test-0-local > =A0 =A0 =A0 =A0 options=3D80000 > =A0 =A0 =A0 =A0 ether 58:9c:fc:10:ec:02 > =A0 =A0 =A0 =A0 groups: tap qemu-port > =A0 =A0 =A0 =A0 media: Ethernet autoselect > =A0 =A0 =A0 =A0 status: no carrier > =A0 =A0 =A0 =A0 nd6 options=3D21 > root@vm:/vm/test # > =20 > What's wrong ? > =20 >=20 >=20 >=20 >=20 > Where did the efi firmware come from? I've got from [1]. [1] http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-u= pstream/latest/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd >=20 >=20 >=20 > Warner >=20 >=20 >=20 >=20 >=20 > Best regards. > --- > Kiriyama Kazuhiko > =20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g" > =20 >=20 >=20 --- Kiriyama Kazuhiko From owner-freebsd-arm@freebsd.org Wed Dec 4 07:30:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 039E21CBF76; Wed, 4 Dec 2019 07:30:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47SVqd63Nzz4WL3; Wed, 4 Dec 2019 07:30:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 1B4B11AF101; Wed, 4 Dec 2019 07:29:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id xB47TvBZ017940 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 Dec 2019 07:29:57 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id xB47TvKm017939; Wed, 4 Dec 2019 07:29:57 GMT (envelope-from phk) To: Ed Maste cc: freebsd-arch , freebsd-arm Subject: Re: arm64 as Tier 1 for FreeBSD 13 In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17937.1575444597.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 04 Dec 2019 07:29:57 +0000 Message-ID: <17938.1575444597@critter.freebsd.dk> X-Rspamd-Queue-Id: 47SVqd63Nzz4WL3 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 07:30:06 -0000 -------- In message , Ed Maste writes: >> Binary updates and source patches for Security Advisories and Errata >> Notices will be provided for supported releases. > >We don't do this today, but have the ability to do so for arm64 server >platforms. (Due to its design, freebsd-update does not work >particularly well on devices with slow root filesystems such as SD >cards.) I don't think storage-technology should be used as a discriminant here. First because it is quite trivial to plug in a quality USB SSD (WD passport for instance) and use that as root filesystem. Second, just because freebsd-update takes a day to run, doesn't mean that people would not want it. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arm@freebsd.org Wed Dec 4 09:24:11 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 82E001CEBC9; Wed, 4 Dec 2019 09:24:11 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SYMG5QKPz4cn8; Wed, 4 Dec 2019 09:24:10 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.15.2/8.15.2) with ESMTPS id xB49O2N0082733 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 Dec 2019 10:24:02 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.15.2/8.15.2/Submit) id xB49O2xF082732; Wed, 4 Dec 2019 10:24:02 +0100 (CET) (envelope-from fuz) Date: Wed, 4 Dec 2019 10:24:02 +0100 From: Robert Clausecker To: freebsd-arm , freebsd-arch Subject: Re: arm64 as Tier 1 for FreeBSD 13 Message-ID: <20191204092402.GA82492@fuz.su> References: <17938.1575444597@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17938.1575444597@critter.freebsd.dk> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47SYMG5QKPz4cn8 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fuz@fuz.su has no SPF policy when checking 2001:41d0:8:e508::1) smtp.mailfrom=fuz@fuz.su X-Spamd-Result: default: False [3.06 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[fuz.su]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.65)[0.652,0]; IP_SCORE(0.66)[ipnet: 2001:41d0::/32(1.47), asn: 16276(1.83), country: FR(-0.00)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.84)[0.845,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 09:24:11 -0000 On Wed, Dec 04, 2019 at 07:29:57AM +0000, Poul-Henning Kamp wrote: > In message , Ed Maste writes: > >We don't do this today, but have the ability to do so for arm64 server > >platforms. (Due to its design, freebsd-update does not work > >particularly well on devices with slow root filesystems such as SD > >cards.) > > I don't think storage-technology should be used as a discriminant here. > > First because it is quite trivial to plug in a quality USB SSD (WD > passport for instance) and use that as root filesystem. > > Second, just because freebsd-update takes a day to run, doesn't mean > that people would not want it. Indeed. For example, on a Raspberry Pi 3B, it takes multiple days to build world as the build must be done single threaded due to a lack of RAM (building LLVM is the worst offender here). Getting it down to one day is already a huge quality of life improvement. Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From owner-freebsd-arm@freebsd.org Wed Dec 4 14:49:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B81AA1C3969; Wed, 4 Dec 2019 14:49:06 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47ShZ93ynxz3Q34; Wed, 4 Dec 2019 14:49:05 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather-dld-1.lib.vt.edu (pmather-dld-1.lib.vt.edu [128.173.51.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 1CBD640D; Wed, 4 Dec 2019 09:48:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: arm64 as Tier 1 for FreeBSD 13 From: Paul Mather In-Reply-To: <20191204092402.GA82492@fuz.su> Date: Wed, 4 Dec 2019 09:48:58 -0500 Cc: freebsd-arm , freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: References: <17938.1575444597@critter.freebsd.dk> <20191204092402.GA82492@fuz.su> To: Robert Clausecker X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 47ShZ93ynxz3Q34 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-2.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.59)[ip: (-1.49), ipnet: 128.173.0.0/16(-0.74), asn: 1312(-0.68), country: US(-0.05)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 14:49:06 -0000 On Dec 4, 2019, at 4:24 AM, Robert Clausecker wrote: > On Wed, Dec 04, 2019 at 07:29:57AM +0000, Poul-Henning Kamp wrote: >> In message = , Ed = Maste writes: >>> We don't do this today, but have the ability to do so for arm64 = server >>> platforms. (Due to its design, freebsd-update does not work >>> particularly well on devices with slow root filesystems such as SD >>> cards.) >>=20 >> I don't think storage-technology should be used as a discriminant = here. >>=20 >> First because it is quite trivial to plug in a quality USB SSD (WD >> passport for instance) and use that as root filesystem. >>=20 >> Second, just because freebsd-update takes a day to run, doesn't mean >> that people would not want it. >=20 > Indeed. For example, on a Raspberry Pi 3B, it takes multiple days to > build world as the build must be done single threaded due to a lack of > RAM (building LLVM is the worst offender here). Getting it down to = one > day is already a huge quality of life improvement. I'm running FreeBSD/arm64 12-STABLE on a Raspberry Pi 3 using a = root-on-ZFS setup. I've been using packaged base for quite some time, = cross-building on FreeBSD/amd64. Every time I upgrade FreeBSD via "pkg = upgrade" it seems to me that it does not take an inordinately long time. = It takes longer than packaged base on a regular FreeBSD/amd64 server = with spinning disk, but not an excessive amount of time. It's certainly = on the order of minutes, not hours. Cheers, Paul. From owner-freebsd-arm@freebsd.org Wed Dec 4 15:12:34 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 58EF91C629A; Wed, 4 Dec 2019 15:12:34 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Sj5F3Nj7z3x8d; Wed, 4 Dec 2019 15:12:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f175.google.com with SMTP id b15so6978563ila.7; Wed, 04 Dec 2019 07:12:33 -0800 (PST) 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=wuXLtsMCRWyZB+j+m7AILi8FRKCPJBsyuC3QO1wJesI=; b=fFIX5hne8dCAFY0FUeue6fSM0QUEZr+92sKAv0yX66XEZvs4kVr/a+b6PfHfRHMtcx tuWxqJ14Z3XT7hD96vi7G/dWuvq+AaW5bFG+IZy1LdP9vLT8PqWK+cgIYzceKTx3JVg7 /Ym9Xg3EZTtlXQfF2FHoN+6l3xfisDmPJvJXpu8BpNbgnWoNnCGzOx1111yYYVS4/aoE ofRDlbZnn/rTtVTh2c4YnCgBx6zFRrQTkCFInSjfSslxJx06RsZw3ftSJKUxPye83vyG nAq8bA1BQoZWOY+m4H8gMLBqdzihddJM6wcgpu7IKICNPyQKA+DruzXHumAmWIhVZr2/ ZwHg== X-Gm-Message-State: APjAAAX4UfCytWIa+KOfzhMzoCjzXQGrewWjYcywXWCAXBvY89NeRUAg TsVb4/cY/kvk8u0k6pPwm1pYFyGugvWPYfGv6yOqav/m X-Google-Smtp-Source: APXvYqwfrFJk/vuA4glhMIz9mD1fv6KCMnv7p/IFSnJhbLWKzPHixQ+a+64ySUKF5XpJCzOt9zkEDdMoGDbYBhOpx74= X-Received: by 2002:a92:4647:: with SMTP id t68mr3765839ila.18.1575472352050; Wed, 04 Dec 2019 07:12:32 -0800 (PST) MIME-Version: 1.0 References: <17938.1575444597@critter.freebsd.dk> In-Reply-To: <17938.1575444597@critter.freebsd.dk> From: Ed Maste Date: Wed, 4 Dec 2019 06:26:02 -0500 Message-ID: Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: Poul-Henning Kamp Cc: freebsd-arch , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47Sj5F3Nj7z3x8d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.175 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.05 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[175.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.05)[ip: (-5.13), ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.93), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[175.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 15:12:34 -0000 On Wed, 4 Dec 2019 at 02:30, Poul-Henning Kamp wrote: > > -------- > In message , Ed Maste writes: > > >> Binary updates and source patches for Security Advisories and Errata > >> Notices will be provided for supported releases. > > > >We don't do this today, but have the ability to do so for arm64 server > >platforms. (Due to its design, freebsd-update does not work > >particularly well on devices with slow root filesystems such as SD > >cards.) > > I don't think storage-technology should be used as a discriminant here. > > First because it is quite trivial to plug in a quality USB SSD (WD > passport for instance) and use that as root filesystem. > > Second, just because freebsd-update takes a day to run, doesn't mean > that people would not want it. That's fair, although maybe I could have been more clear. My point is that arm64 server-class hardware like Ampere eMAG and Marvell ThunderX/ThunderX2 generally looks just like an x86 server from a storage perspective, and freebsd-update would work just as well as it does on x86. Devices do exist with slow SD card root filesystems. Running freebsd-update on them might take a very long time and might be a poor user experience. None of that implies that FreeBSD/arm64 cannot be Tier-1. From owner-freebsd-arm@freebsd.org Wed Dec 4 15:17:17 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E1B351C6A87; Wed, 4 Dec 2019 15:17:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SjBj0XQTz3xQQ; Wed, 4 Dec 2019 15:17:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f179.google.com with SMTP id z12so6968323iln.11; Wed, 04 Dec 2019 07:17:16 -0800 (PST) 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:content-transfer-encoding; bh=BLWlJlzuaKYdGtQU8GYE9gI5LuzNbsxEZbZEfKJEb+s=; b=is5Z/sWjKYSGgjgc3JfkqS3TrEYEiFypTo71JNMWCyDs+W/zacpAtDY10PoaY6ihM4 vnoPtChtM3W6m8uQ4DPax6ZIjbVyR5VKrTX6qX/9IxEC9LhepC74okPZYJn6PUMuyi0l Pz4SXrZK3TGBoqo03gNTcqV/LMXz1FiOEXZRtE1l4IB/KY8SiRVHXG99jww10/L7/0E1 Mb1fQRVnSWGj7E6waRGWbYeQcUCkH3ArZBgGse5Zz6O1iUysyG4CLShcubyYWMT2lX4n QXRBZRJzFfiVsfhPd/Uth0UTAeGGd52wSXrSZQIiLkyB3i5/QkakKz2A05GXMV5lezwH ewSw== X-Gm-Message-State: APjAAAUm4reKgZHjVe5w+iRebF8h9HULgPqGjLLCRa0+d7A8XVP5dujo Zs8CUH618Z4V6QViJExuZ4oNyomUP14Jhs+GHFfIIjp5 X-Google-Smtp-Source: APXvYqxeC/jUc2ob6a7FLv0XWFLGXFvDFVACnoMPXl2ZmJn4qfg5Ba7jQb/N8ZWijwCYG1Yrrm4BJh51jfKfsQvt3a0= X-Received: by 2002:a92:2450:: with SMTP id k77mr3874333ilk.120.1575472635852; Wed, 04 Dec 2019 07:17:15 -0800 (PST) MIME-Version: 1.0 References: <17938.1575444597@critter.freebsd.dk> <20191204092402.GA82492@fuz.su> In-Reply-To: From: Ed Maste Date: Wed, 4 Dec 2019 06:30:45 -0500 Message-ID: Subject: Re: arm64 as Tier 1 for FreeBSD 13 To: Paul Mather Cc: Robert Clausecker , freebsd-arm , freebsd-arch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 47SjBj0XQTz3xQQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.36 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[179.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.36)[ip: (-6.69), ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.93), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[179.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 15:17:17 -0000 On Wed, 4 Dec 2019 at 09:49, Paul Mather wrote: > > I'm running FreeBSD/arm64 12-STABLE on a Raspberry Pi 3 using a root-on-Z= FS setup. I've been using packaged base for quite some time, cross-buildin= g on FreeBSD/amd64. Every time I upgrade FreeBSD via "pkg upgrade" it seem= s to me that it does not take an inordinately long time. It takes longer t= han packaged base on a regular FreeBSD/amd64 server with spinning disk, but= not an excessive amount of time. It's certainly on the order of minutes, = not hours. Indeed, migrating to pkg base is the presumed solution for the "freebsd-update would be too slow on SD card root" issue. Perhaps you wouldn't mind writing up the steps you're using to cross-build and install updates? From owner-freebsd-arm@freebsd.org Wed Dec 4 16:33:12 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E6061CDEF0; Wed, 4 Dec 2019 16:33:12 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SktJ0Pvnz42rb; Wed, 4 Dec 2019 16:33:11 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather-dld-1.lib.vt.edu (pmather-dld-1.lib.vt.edu [128.173.51.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id C3B392E8; Wed, 4 Dec 2019 11:33:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: arm64 as Tier 1 for FreeBSD 13 From: Paul Mather In-Reply-To: Date: Wed, 4 Dec 2019 11:33:09 -0500 Cc: Robert Clausecker , freebsd-arm , freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <8ED17B73-97C0-4843-900D-0EC13C87651C@gromit.dlib.vt.edu> References: <17938.1575444597@critter.freebsd.dk> <20191204092402.GA82492@fuz.su> To: Ed Maste X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 47SktJ0Pvnz42rb X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 16:33:12 -0000 On Dec 4, 2019, at 6:30 AM, Ed Maste wrote: > On Wed, 4 Dec 2019 at 09:49, Paul Mather = wrote: >>=20 >> I'm running FreeBSD/arm64 12-STABLE on a Raspberry Pi 3 using a = root-on-ZFS setup. I've been using packaged base for quite some time, = cross-building on FreeBSD/amd64. Every time I upgrade FreeBSD via "pkg = upgrade" it seems to me that it does not take an inordinately long time. = It takes longer than packaged base on a regular FreeBSD/amd64 server = with spinning disk, but not an excessive amount of time. It's certainly = on the order of minutes, not hours. >=20 > Indeed, migrating to pkg base is the presumed solution for the > "freebsd-update would be too slow on SD card root" issue. >=20 > Perhaps you wouldn't mind writing up the steps you're using to > cross-build and install updates? I am using already existing documentation from the FreeBSD project. = (Many thanks to the original authors!) 1. Building and serving pkg packages For a long time I have built packages for my FreeBSD systems using = Poudriere and serve them over the network via the Poudriere build = machine. See: - https://www.freebsd.org/doc/handbook/ports-poudriere.html I use Nginx (via www/nginx) to serve the pkg repos (based on the = /usr/local/share/examples/poudriere/nginx.conf.sample file in the = ports-mgmt/poudriere installed port). Note, you don't really need Poudriere in all this, but I find it useful = for also cross-building my FreeBSD/arm64 ports. Because I was using = Poudriere long before PkgBase, I included it here as something folks = might also want to use. 2. Cross-building for FreeBSD/arm64 To cross-build, I use the "mk" script provided at the arm/crossbuild = section of the FreeBSD Wiki. See: - https://wiki.freebsd.org/arm/crossbuild In the case of my FreeBSD/arm64 systems, my "config/mk.conf" and = "config/make.conf" consist solely of the following: =3D=3D=3D=3D=3D config/mk.conf =3D=3D=3D=3D=3D mk_arch=3D"aarch64" mk_kernel=3D"GENERIC" =3D=3D=3D=3D=3D config/mk.conf =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D config/make.conf =3D=3D=3D=3D=3D REPODIR=3D/build/repo =3D=3D=3D=3D=3D config/make.conf =3D=3D=3D=3D=3D I have a simple script, "rebuild_os_pkgs" that cross-builds everything = and makes the base packages that end up under /build/repo: =3D=3D=3D=3D=3D rebuild_os_pkgs =3D=3D=3D=3D=3D #!/bin/sh mk buildworld mk buildkernel mk packages =3D=3D=3D=3D=3D rebuild_os_pkgs =3D=3D=3D=3D=3D (My "mk" script is in /usr/local/bin.) To build an updated OS I run that script after first having updated the = OS source in the "src" subdirectory (e.g., via "make update"). (You can = symlink "src" to "/usr/src" if you want to save space.) The "mk = packages" step results in a pkg-compliant repository with all the = PkgBase packages in it. 3. FreeBSD/arm64 PkgBase I followed the PkgBase documentation at the FreeBSD Wiki to set up my = Raspberry Pi 3 to use the OS packages build on the FreeBSD/amd64 build = machine using the "rebuild_os_pkgs" script. See: - https://wiki.freebsd.org/PkgBase I have this snippet on the OS package build machine to serve out the pkg = repository created as part of the rebuild_os_pkgs run: =3D=3D=3D=3D=3D location /FreeBSD-base { alias /build/repo; autoindex on; allow all; } =3D=3D=3D=3D=3D If you are used to building and serving pkg packages (e.g., ports = packages) then the real workhorse in all this is the "mk" cross-building = script + FreeBSD build system that is cross-building capable. I encourage folks to check out the FreeBSD documentation on = cross-building for ARM and PkgBase that I mention above. They have a = lot of useful information. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Fri Dec 6 09:05:20 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6FA31C6AC3 for ; Fri, 6 Dec 2019 09:05:20 +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 47Tmrb5Bs3z4CYK for ; Fri, 6 Dec 2019 09:05:19 +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=1575623108; bh=hOE28nHMDiTgt3j7AY2o0TCgWAiEN6FdDkMCKOBJtgc=; h=To:From:Subject:Date; b=PSijp3dQxC23aIVUvResf4n0s2Z6x06e0qgh5LVpijRsyq9UqdjlZmathH/J6QKZM wVgSr3XDfLb8yfiBNQzfEzggfDpoChQxzp/I2T1dD2O/cZknlJ2GYsPWQkVakkxLsK KKTLQ6ZTctZ01QN3M6bru1ShK0k9kckcYPJ0482I= To: freebsd-arm@freebsd.org From: Per olof Ljungmark Subject: FreeBSD arm with LTE or GSM modem Organization: Nethead AB Message-ID: <922d18f2-747a-2494-a560-f4410975ba7d@nethead.se> Date: Fri, 6 Dec 2019 10:05:06 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47Tmrb5Bs3z4CYK X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nethead.se header.s=NETHEADSE header.b=PSijp3dQ; dmarc=pass (policy=none) header.from=nethead.se; spf=pass (mx1.freebsd.org: domain of peo@nethead.se designates 5.150.237.139 as permitted sender) smtp.mailfrom=peo@nethead.se X-Spamd-Result: default: False [-5.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[nethead.se:s=NETHEADSE]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:5.150.237.139]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[nethead.se:+]; DMARC_POLICY_ALLOW(-0.50)[nethead.se,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.80)[ip: (-9.79), ipnet: 5.150.192.0/18(-4.90), asn: 8473(0.74), country: SE(-0.03)]; ASN(0.00)[asn:8473, ipnet:5.150.192.0/18, country:SE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 09:05:20 -0000 Hi, Does anyone on the list have a suggestion for a working FreeBSD-arm / board / modem combo? Prefer piggyback, not USB port style modem. Thanks, -- Per olof Ljungmark From owner-freebsd-arm@freebsd.org Sat Dec 7 03:45:57 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBE0A1C68C0 for ; Sat, 7 Dec 2019 03:45:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47VFjd3t93z4MQD for ; Sat, 7 Dec 2019 03:45:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 686BABEE7 for ; Sat, 7 Dec 2019 03:45:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xB73jv3L039354 for ; Sat, 7 Dec 2019 03:45:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xB73jvO1039353 for freebsd-arm@FreeBSD.org; Sat, 7 Dec 2019 03:45:57 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 222923] usr.bin/clang/lld fails to compile with arm:arm Date: Sat, 07 Dec 2019 03:45:57 +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: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Unable to Reproduce 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.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 03:45:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222923 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Unable to Reproduce Status|New |Closed --- Comment #2 from Ed Maste --- compiles now on arm --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Dec 7 23:42:01 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 15CD71D04B1 for ; Sat, 7 Dec 2019 23:42:01 +0000 (UTC) (envelope-from marcel@brickporch.com) Received: from mail.brickporch.com (mail.brickporch.com [52.33.181.202]) by mx1.freebsd.org (Postfix) with ESMTP id 47VmFg54NTz4Mbh for ; Sat, 7 Dec 2019 23:41:59 +0000 (UTC) (envelope-from marcel@brickporch.com) Received: from twill.home.brickporch.com (69-84-2-229.mxu.aerioconnect.net [69.84.2.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.brickporch.com (Postfix) with ESMTPSA id 3389C12CC9B for ; Sat, 7 Dec 2019 23:42:18 +0000 (UTC) From: Marcel Flores Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: ThunderX Networking Date: Sat, 7 Dec 2019 15:41:51 -0800 References: <340B43A0-8E12-4F8C-A7F0-844BF8A55DB8@brickporch.com> To: freebsd-arm@freebsd.org In-Reply-To: <340B43A0-8E12-4F8C-A7F0-844BF8A55DB8@brickporch.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 47VmFg54NTz4Mbh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of marcel@brickporch.com designates 52.33.181.202 as permitted sender) smtp.mailfrom=marcel@brickporch.com X-Spamd-Result: default: False [-2.05 / 15.00]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[brickporch.com]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-0.85)[ipnet: 52.32.0.0/14(-2.89), asn: 16509(-1.30), country: US(-0.05)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:52.32.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 23:42:01 -0000 > On Jul 13, 2019, at 1:46 PM, Marcel Flores = wrote: >=20 > Hi All, >=20 > I had some time to poke around at the issue regarding: > https://lists.freebsd.org/pipermail/freebsd-arm/2019-April/019798.html >=20 > On boot, with 13-CURRENT (r349796) dmesg dumps the following message: >=20 > bgx0: Could not find Matching PHY >=20 > Which seems to come from here: > = https://github.com/freebsd/freebsd/blob/master/sys/dev/vnic/thunder_bgx_fd= t.c#L456 >=20 > Playing around with some debugging output, it seems like the check is = falling > through when it checks for matching device names: >=20 > = https://github.com/freebsd/freebsd/blob/master/sys/dev/vnic/thunder_bgx_fd= t.c#L196 >=20 > But when I dump the string that it=E2=80=99s comparing to, by adding = the following above line 196: >=20 > device_printf(bgx->dev, "Matching Names: %s to %s\n", phys_name, = type); >=20 > It seems like the match is very "close", but maybe something minute is = getting > in the way: >=20 > bgx0: Checking for length and name > bgx0: Matching names: xfi00 to xfi > bgx0: Matching names: xfi01 to xfi > bgx0: Matching names: xfi02 to xfi > bgx0: Matching names: xfi03 to xfi > bgx0: Could not find matching PHY > device_attach: bgx0 attach returned 6 > bgx0: mem = 0x87e0e1000000-0x87e0e13fffff,0x87e0e1400000-0x87e0e17fffff at device = 0.129 on pci1 > bgx0: Matching names: xlaui10 to xlaui > device_attach: bgx0 attach returned 6 >=20 > In particular, it seems to be failing the second part of the check, = that > ensure's a "\0" or a "@" after the name. >=20 > Could this be an issue with the FDT setup for the thunderx? Maybe = something > simple or an indicator of bigger issues? Am I barking up the wrong = tree? Happy > to do any further digging if anyone has any ideas! >=20 > Thanks, > -Marcel > _______________________________________________ > 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" Hi All, Took another look at the this. It seems the issue arose in this commit: https://reviews.freebsd.org/rS334880 Manually removing the additional check and building a kernel allowed it = to match the PHY device. Following the steps outlined here: = https://lists.freebsd.org/pipermail/freebsd-arm/2015-November/012612.html and was able to get the onboard NIC working. This feels very much like a bug in the check logic of rS334880 to me, = but I admit I'm out of my depth on what exactly it's checking for. -Marcel From owner-freebsd-arm@freebsd.org Sat Dec 7 23:46:42 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 12C911D0644 for ; Sat, 7 Dec 2019 23:46:42 +0000 (UTC) (envelope-from marcel@brickporch.com) Received: from mail.brickporch.com (mail.brickporch.com [52.33.181.202]) by mx1.freebsd.org (Postfix) with ESMTP id 47VmM536lFz4Mkh for ; Sat, 7 Dec 2019 23:46:41 +0000 (UTC) (envelope-from marcel@brickporch.com) Received: from twill.home.brickporch.com (69-84-2-229.mxu.aerioconnect.net [69.84.2.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.brickporch.com (Postfix) with ESMTPSA id 44E1112CC9B for ; Sat, 7 Dec 2019 23:47:06 +0000 (UTC) From: Marcel Flores Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: ThunderX Networking Date: Sat, 7 Dec 2019 15:46:40 -0800 References: <340B43A0-8E12-4F8C-A7F0-844BF8A55DB8@brickporch.com> To: freebsd-arm@freebsd.org In-Reply-To: Message-Id: <2DB40DB6-73D0-440A-94B3-82A173E9DF3E@brickporch.com> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 47VmM536lFz4Mkh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of marcel@brickporch.com designates 52.33.181.202 as permitted sender) smtp.mailfrom=marcel@brickporch.com X-Spamd-Result: default: False [-2.05 / 15.00]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[brickporch.com]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-0.85)[ipnet: 52.32.0.0/14(-2.89), asn: 16509(-1.30), country: US(-0.05)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:52.32.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 23:46:42 -0000 > On Dec 7, 2019, at 3:41 PM, Marcel Flores = wrote: >=20 > Hi All, >=20 > Took another look at the this. It seems the issue arose in this = commit: >=20 > https://reviews.freebsd.org/rS334880 >=20 > Manually removing the additional check and building a kernel allowed = it to > match the PHY device. >=20 > Following the steps outlined here: >=20 > = https://lists.freebsd.org/pipermail/freebsd-arm/2015-November/012612.html >=20 > and was able to get the onboard NIC working. >=20 >=20 > This feels very much like a bug in the check logic of rS334880 to me, = but > I admit I'm out of my depth on what exactly it's checking for. >=20 > -Marcel >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org=E2=80=9D Of course, I linked to the wrong commit, that should be: https://reviews.freebsd.org/rS336281 In particular rS336281 seems to have been a follow up to rS334880. -Marcel