From owner-freebsd-arm@freebsd.org Sun Apr 19 01:03:58 2020 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 919C32B37D3 for ; Sun, 19 Apr 2020 01:03:58 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f226.i.mail.ru (f226.i.mail.ru [94.100.178.212]) (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 494Wmr6QtBz4FFf for ; Sun, 19 Apr 2020 01:03:56 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: by f226.i.mail.ru with local (envelope-from ) id 1jPyNF-0004dW-LX for freebsd-arm@freebsd.org; Sun, 19 Apr 2020 04:03:53 +0300 Received: by e.mail.ru with HTTP; Sun, 19 Apr 2020 04:03:53 +0300 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: freebsd-arm@freebsd.org Subject: =?UTF-8?B?TXVsdGl0aHJlYWRlZCBsYXRlbmN5IHRvbyByYW5kb20u?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 Date: Sun, 19 Apr 2020 04:03:53 +0300 Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= X-Priority: 3 (Normal) Message-ID: <1587258233.899122295@f226.i.mail.ru> X-7564579A: B8F34718100C35BD X-77F55803: 0A44E481635329DB4E7FAE048FD183FFD32E5E48865217364D5B7DD64928291150CA885A68A10851FBDBF69DD7E3F538567D1905E5B40DE7254773CA284D50E92137CEE3F0C8AF3DB07B21E007F288A4 X-7FA49CB5: 70AAF3C13DB7016878DA827A17800CE7F382128C16B1711CD82A6BABE6F325AC9EB98D58427B1C2ABCF491FFA38154B613377AFFFEAFD269ACC50219273B5BD86D34FAA3D8B31588C2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE788D3B7A20D1C4246EA1F7E6F0F101C674E70A05D1297E1BBC6CDE5D1141D2B1C570BED0DEE4E67B94958825FCE56EEC8CAE5EF399F09CDEB9FA2833FD35BB23D9E625A9149C048EE9ECD01F8117BC8BEA471835C12D1D9774AD6D5ED66289B524E70A05D1297E1BBF6B57BC7E64490611E7FA7ABCAF51C92A417C69337E82CC2CC7F00164DA146DA6F5DAA56C3B73B23E7DDDDC251EA7DABAAAE862A0553A39223F8577A6DFFEA7C565C1E6824D8037B43847C11F186F3C5E7DDDDC251EA7DABCC89B49CDF41148FA8EF81845B15A4842623479134186CDE6BA297DBC24807EABDAD6C7F3747799A X-D57D3AED: Y8kq8+OzVozcFQziTi/Zi098oNK9gy3Irm5KFwLuDg60je4lC+GbTj0M8KbzpOmgsB7wYP6nnel8wfEHQiZAetlEg7qy07ISeqrIhHPnkjxzStmLfnHHvA== X-Mailru-Internal-Actual: A:0.87711379118612 X-Mailru-MI: 900 X-Mailru-Sender: 015BA6FC0EFA223AC9497D3904BE6119151FB9038F44B9CD73F520445443750E2072F220CF90AE66DAA8D66BCF563755BC76079D514E5C4AC62600DFC3A8D7422F84BEB09BBDFF4283FE72BCEDE54D2A523B62E302B269B5B4A721A3011E896F X-Mras: Ok X-Rspamd-Queue-Id: 494Wmr6QtBz4FFf X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; HAS_REPLYTO(0.00)[samspeed@mail.ru]; SUBJ_EXCESS_BASE64(0.00)[]; FROM_EXCESS_BASE64(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[212.178.100.94.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:94.100.176.0/20]; FREEMAIL_FROM(0.00)[mail.ru]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[mail.ru:+]; MIME_BASE64_TEXT(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; MAIL_RU_MAILER_BASE64(0.00)[]; MAIL_RU_MAILER(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.178.100.94.list.dnswl.org : 127.0.5.1]; FREEMAIL_ENVFROM(0.00)[mail.ru]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ZERO(0.00)[0]; DWL_DNSWL_NONE(0.00)[mail.ru.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; REPLYTO_EXCESS_BASE64(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[mail.ru]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ipnet: 94.100.176.0/20(0.06), asn: 47764(0.23), country: RU(0.01)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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, 19 Apr 2020 01:03:58 -0000 Ckkgd3JvdGUgc2ltcGxlIG11bHRpdGhyZWFkZWQgZXhhbXBsZSA6CsKgCm1haW4uY3BwOgojaW5j bHVkZSA8dGhyZWFkPgojaW5jbHVkZSA8dW5pc3RkLmg+CiNpbmNsdWRlIDx0aW1lLmg+CmludCBk VGltZU1heCA9IDA7CmludCBkVGltZU1pbiA9IDB4N0ZGRkZGRkY7CmludCBOYW5vc2VjOwpib29s IFRocmVhZEV4aXQgPSBmYWxzZTsKdm9pZCBUaHJlYWQoKQp7CsKgwqAgwqB0aW1lc3BlYyBUMSxU MjsKwqDCoCDCoGZvciggOyAhVGhyZWFkRXhpdCA7ICkKwqDCoCDCoHsKwqDCoCDCoMKgwqAgwqBj bG9ja19nZXR0aW1lKCBDTE9DS19SRUFMVElNRV9QUkVDSVNFLCAmVDEgKTsKwqDCoCDCoMKgwqAg wqBjbG9ja19nZXR0aW1lKCBDTE9DS19SRUFMVElNRV9QUkVDSVNFLCAmVDIgKTsKwqDCoCDCoMKg wqAgwqBOYW5vc2VjID0gKCBUMi50dl9zZWMgLSBUMS50dl9zZWMgKSoxMDAwMDAwMDAwICsgVDIu dHZfbnNlYyAtIFQxLnR2X25zZWMgOwrCoMKgIMKgwqDCoCDCoGlmICggTmFub3NlYyA+IGRUaW1l TWF4ICkgZFRpbWVNYXggPSBOYW5vc2VjOwrCoMKgIMKgwqDCoCDCoGlmICggTmFub3NlYyA8IGRU aW1lTWluICkgZFRpbWVNaW4gPSBOYW5vc2VjOwrCoMKgIMKgfQp9CmludCBtYWluKCBpbnQgYXJn YywgY2hhciAqYXJndltdICkKewrCoMKgIMKgc3RkOjp0aHJlYWQgVGhyKCBUaHJlYWQgKTsKwqDC oCDCoGZvciggaW50IE49MDsgTjwxMDAwMDA7ICsrTiApCsKgwqAgwqDCoMKgIMKgcHJpbnRmKCIl ZCBcdCVkIFx0JWRcbiIsIGRUaW1lTWF4LCBkVGltZU1pbiwgTmFub3NlYyApOwrCoMKgIMKgVGhy ZWFkRXhpdD10cnVlOwrCoMKgIMKgVGhyLmpvaW4oKTsKfQrCoApPbiBteSBQQ8KgCsKgIGRUaW1l TWF4IOKAlCBkVGltZU1pbiA8IDgwMDAgaW4gY29uc29sZSBvdmVyIHNzaC4KwqAgZFRpbWVNYXgg 4oCUIGRUaW1lTWluIDwgNTAwMCBpbiB0bXBmcyBmaWxlIG91dHB1dC4KwqAKT24gbXkgT3Jhbmdl LVBpIFplcm8gYm9hcmQgaXQgcHJvZHVjZSB2ZXJ5IHJhbmRvbSB2YWx1ZXM6CsKgZFRpbWVNYXgg 4oCUIGRUaW1lTWluID4gMiAwMDAgMDAwIGluIGNvbnNvbGUgb3ZlciBzc2ggLgrCoCBkVGltZU1h eCDigJQgZFRpbWVNaW4gPiAxNSAwMDAgaW4gdG1wZnMgZmlsZSBvdXRwdXQuCsKgCldoYXQgY2Fu IGhlbHAgZGlzYWJsZSBpbnRlcnJ1cHQgb2YgdGhyZWFkID8KwqAKU2V0IGtlcm4uaHo9MjUwMDAw IG5vdCBjaGFuZ2UgcmVzdWx0LgrCoApGcmVlQlNEIG9yYW5nZXBpLXplcm8gMTMuMC1DVVJSRU5U IEZyZWVCU0QgMTMuMC1DVVJSRU5UICMwIHIzNTk5Mjk6IFRodSBBcHIgMTYgMDY6MTA6NDIgTVNL IDIwMjDCoCAvdXNyL3NyYy9hcm0uYXJtdjcvc3lzL0dFTkVSSUMtTk9ERUJVR8KgIGFybQrCoAp0 byBjb21waWxlOiBjKysgbWFpbi5jcHAgLWx0aHIKwqAKwqAKwqAKwqAKLS0KQW5kcmV5IFNtYWdp bg== From owner-freebsd-arm@freebsd.org Sun Apr 19 16:56:52 2020 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 A67FA27AE2B for ; Sun, 19 Apr 2020 16:56:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 494wwN1dXkz4ZxC for ; Sun, 19 Apr 2020 16:56:51 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1587315410; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=RRiWNqxz8Lj4JMj/Svmz9VV5lxEoh05WU9/JNDgjKG/QWi4QkV/MTpTUf8ylpc2s7UEPTgbH31bIw jzwhaCxH4DnRLEqL394VWBisjR+ZCJe3JVINzv3mZl3fKZuGsWHUbaS/QbLE+bFLrUeEsHD7dbbxel NAKSlwmeiP4dCntW3HfT6Utvq/dt39memyIqIgBuDXJo8MWLD1608056mQ6yG+RbYdhpnIckCW5JWM d+yYp8pMBOig/F6O4IrhX46Ropo5XdMuQ3fxCCZEPJWWDkYNI11aQaFel0MJmyOz1TRzVuOwjbQ4Ht LY6swZjomDrT9zN1u934/QnF9dohKEw== 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:to:from:subject:message-id:dkim-signature:from; bh=aYZjg8fR66Ebsvs+mwq6nelt1fIPSD0t8i5y5RZjJsk=; b=ltrVd4mdMZd5JkJ6ZPmJJn3yS/MJGVH/ex59s1sUR5JkzuKpJ+LBRTkmP3OEHBk4SVvpbMgZCr6xB QTJ/APo6BXrCuF8r9Qw7mppMPDb60ZTDydruaqGOnI4ilOWHtzWvkuXrF0I1pbVBp7oHI7Gi7T6f+K cyOv0SFU+5UjLwEemUll+ZDVjRH20HsFR5JdNadwpLlaNhmlRIApWRpLOVZeEfpB+98mh6CvAORMmY HzWryqzimTOrG0cErHKSiYyMaIdLyRpAVN4jSW3WaIyaHTKhlzTeN+6bfLmNGtR1vqHQpQ97wOAgNM mgu7K0vFtsoMCcsfF0Y4pex2t/lDWxw== 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:to:from:subject:message-id:from; bh=aYZjg8fR66Ebsvs+mwq6nelt1fIPSD0t8i5y5RZjJsk=; b=q5aaZaMvaY8PyGki0OU9+SwND1V2F4s7kheLaZyN++MxZSZolmEF0uHatwPXmJkQo+kCaIs9zGPhL 3Y7pMd5pu53OU98tq/qz0fiv82LtwODYUI1EKqq8eUczeBEuOX+hRvLGrW6MvCxxjKLZSr19yjTQBs 6gLbL62q4QptNA6I1rZTGY0I5aU+18oR7HFNtMXPAZLhZ5ETTVQNbeT35Rw7FwwDHcgk2bh4CGOi+l T4lLL5RC8vwvP1pvTx0JSAwP9A7oOOLzznH84cDyAvSfblMkD0O13f7GWPA10Q2NpI+6zFnhuf2W3z dXiHdT3yuR0iCy8aUmcdcMsLYmVICFw== X-MHO-RoutePath: aGlwcGll X-MHO-User: c1dd6683-825e-11ea-a065-6d02e42e573a 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 (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id c1dd6683-825e-11ea-a065-6d02e42e573a; Sun, 19 Apr 2020 16:56:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 03JGulPr087230; Sun, 19 Apr 2020 10:56:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Multithreaded latency too random. From: Ian Lepore To: Andrey Smagin , freebsd-arm@freebsd.org Date: Sun, 19 Apr 2020 10:56:47 -0600 In-Reply-To: <1587258233.899122295@f226.i.mail.ru> References: <1587258233.899122295@f226.i.mail.ru> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 494wwN1dXkz4ZxC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.94 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.97)[-0.969,0]; NEURAL_HAM_LONG(-0.97)[-0.968,0]; ASN(0.00)[asn:16509, ipnet:54.148.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: Sun, 19 Apr 2020 16:56:52 -0000 On Sun, 2020-04-19 at 04:03 +0300, Andrey Smagin via freebsd-arm wrote: > I wrote simple multithreaded example : > > main.cpp: > #include > #include > #include > int dTimeMax = 0; > int dTimeMin = 0x7FFFFFFF; > int Nanosec; > bool ThreadExit = false; > void Thread() > { > timespec T1,T2; > for( ; !ThreadExit ; ) > { > clock_gettime( CLOCK_REALTIME_PRECISE, &T1 ); > clock_gettime( CLOCK_REALTIME_PRECISE, &T2 ); > Nanosec = ( T2.tv_sec - T1.tv_sec )*1000000000 + T2.tv_nsec - > T1.tv_nsec ; > if ( Nanosec > dTimeMax ) dTimeMax = Nanosec; > if ( Nanosec < dTimeMin ) dTimeMin = Nanosec; > } > } > int main( int argc, char *argv[] ) > { > std::thread Thr( Thread ); > for( int N=0; N<100000; ++N ) > printf("%d \t%d \t%d\n", dTimeMax, dTimeMin, Nanosec ); > ThreadExit=true; > Thr.join(); > } > > On my PC > dTimeMax — dTimeMin < 8000 in console over ssh. > dTimeMax — dTimeMin < 5000 in tmpfs file output. > > On my Orange-Pi Zero board it produce very random values: > dTimeMax — dTimeMin > 2 000 000 in console over ssh . > dTimeMax — dTimeMin > 15 000 in tmpfs file output. > > What can help disable interrupt of thread ? > > Set kern.hz=250000 not change result. > > FreeBSD orangepi-zero 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r359929: > Thu Apr 16 06:10:42 MSK 2020 /usr/src/arm.armv7/sys/GENERIC-NODEBUG > arm > > to compile: c++ main.cpp -lthr > > > The only thing I find surprising about that is the 2ms of variability in the arm console over ssh case. The 15us in the tmpfs case is actually better than I would have guessed. I wonder what it is about ssh over console? Is it the network activity? It might be interesting to run the tmpfs test while having iperf or something similiar running in another window to load up the network. I wonder if dtrace might be able to answer any questions here? I'm not very good with dtrace, but I suspect we have some people reading here who might suggest some of the canned dtrace scripts that could help figure out what's causing the high variability in timing in the ssh case. kern.hz doesn't really control anything anymore like it did in the old days. It has some indirect effects on performance, but nothing like it did in the days before eventtimers and the tickless kernel changes. -- Ian From owner-freebsd-arm@freebsd.org Mon Apr 20 17:25:19 2020 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 0962F2A8978 for ; Mon, 20 Apr 2020 17:25:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 495YVj6Bt4z3DPS for ; Mon, 20 Apr 2020 17:25:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 03KHPDeb094535 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Apr 2020 10:25:13 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03KHPD0D094534; Mon, 20 Apr 2020 10:25:13 -0700 (PDT) (envelope-from fbsd) Date: Mon, 20 Apr 2020 10:25:12 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: Booting from USB on RPi3 Message-ID: <20200420172512.GA94315@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 495YVj6Bt4z3DPS 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 [4.80 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.91)[0.910,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.94)[0.940,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: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: Mon, 20 Apr 2020 17:25:19 -0000 Back on October 24, 2019 Mason Loring Bliss mason at blisses.org wrote in part: ----------begin excerpt---------- I'm struggling with how to boot FreeBSD 12 directly from a hard drive on an RPi3b+, with no MMC card. It happens automatically with a Raspbian image, and I got Devuan to boot this way by changing the right pointers in config.txt, but I'm struggling to figure out how to do it on FreeBSD. I'm not sure what dictates the boot behaviour. ----------end excerpt--------- The complete post is at: https://lists.freebsd.org/pipermail/freebsd-arm/2019-October/020608.html Far as I can tell there were no replies. In the meantime I've become interested (again) in trying to boot a Pi3B from a mechanical hard drive by using the "boot from USB" OTP feature on my Pi3B v.1.2. The feature has been set, according to the instructions at https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md but when the microSD card is removed nothing happens (no rainbow screen) on power-up. Presumably my Pi3B is too old. At some point the Raspberry Pi foundation introduced a new bootcode.bin as described in https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md which was intended to give older Pi2 and Pi3 models the ability to boot from USB at the price of keeping a minimal microSD card in place. All that's required on the card is the new version of bootcode.bin plus an empty file named timeout to give a mechanical drive time to spin up. Has anybody tried it? I wouldn't expect it to work "out of the box", but perhaps with some adjustments. In the meantime, I've gotten u-boot to the point of issuing a prompt and recognizing a usbboot command, but can't seem to get the syntax right. A usb reset command produces resetting USB... Bus usb@7e980000: scanning bus usb@7e980000 for devices... 8 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found and U-Boot> help usbboot usbboot - boot from USB device Usage: usbboot loadAddr dev:part The only command that doesn't cause a syntax error is U-Boot> usbboot 7e980000 0:1 Loading from usb device 0, partition 1: Name: usbda1 Type: U-Boot "Synchronous Abort" handler, esr 0x96000045 elr: 00000000000cd2f8 lr : 00000000000aef5c (reloc) elr: 000000003b3a92f8 lr : 000000003b38af5c x0 : 000000007e980000 x1 : 000000003af6d900 x2 : 0000000000000200 x3 : 0000000000000000 x4 : 0000000000000200 x5 : 0000000000000040 x6 : 2e34445342903ceb x7 : 000000003af7d9c1 x8 : 0000000000010041 x9 : 0000000000000008 x10: 0000000000000006 x11: 000000003af6b2e0 x12: 0000000000000820 x13: 0000000000000001 x14: 0000000000000001 x15: 00000000ffffffff x16: 0000000000000001 x17: 000000000000004b x18: 000000003af57de8 x19: 0000000000000001 x20: 000000003af6d900 x21: 0000000000000200 x22: 0000000000000200 x23: 0000000000000000 x24: 000000003af7db90 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000200 x28: 000000003f980000 x29: 000000003af4ff60 Resetting CPU .. That seems to suggest I'm using the wrong address or address format. So far, I've not been able to find any docs beyond the help feature at the u-boot prompt. The usb drive is recognized as /dev/da0 when the machine boots 12.1-stable and has a 12.1 stable image on it. Thanks for reading, and any guidance! bob prohaska From owner-freebsd-arm@freebsd.org Mon Apr 20 18:22:40 2020 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 70E0A2AA0AF for ; Mon, 20 Apr 2020 18:22:40 +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 495Zmv1LR1z3JWr for ; Mon, 20 Apr 2020 18:22:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .Hsv2KAVM1lvy7uv4yFHGTbl38YbfUQzq9xELEHw_IOhgWyv1L9WB.KuylXzcTI Ft0Z2Wju.MN9JvlzMTdETooStXBDitojPZv7Fupf644Ddo.QjXmutSNePghUNjMdv.aG.A6HgKIZ Mpu4mmTgiyESj_f8cum1Q5288H1ApWCFMjH0Kcofru6xaMXLWA7F.5HZ7WJq6YGHVT4RtkVL7Y.J wduQd9JyuQZ8MI_chQ28_FpIyu9LKbt1P0d4IHhExoEYyxRazYmps5ZdPFI9kHpPBjt2Tjgf.pTv H_oVbdzaBv1uuppJQTrmMxUPgh5YxgaN4uy3j5sHg.2m9jb6_PoZ0Xr5FvDwZBOoVxzsdXAK_olX LOtkMp5kGnhBaAcHD.im5hf36_.Gg.SvkiW1IN3xMWfnSrqhwMjA8flizGZM09LWY5djMEL9n.Rj dNo6ny1D28A4wqLJFpxbcCIe9XyfdZOVlNfq1wAYZzNJrHshEyn5PBXva5zfeO6Q_ctep2VVKWkJ .qm7yYqVW4oMVHlSxtxiSRcaRJV6T_K6o1ordgaA4mqmWf.Jr4inq1fwaKsY1v78dDHKqwbFD9yJ TMkPFcJID869pcSkYbouRcGU_ksKO1FupLak8iJNlpVGYHt1X3W9ESWVGEKOeyT6cWSh7jdAq11b XhPGPkO67lhBSQlRsYazQYKHD2AzJtroN40uNVqhgY7UWljmcIBuNYYuai8B27ivqUvKOD8GbzFx zJPNjP88mikiw4FI2bU0rQ8QL.1gCs0l3t_sgfRacW85MYhkHp7FtVrULiYMH5NDdP2jdiWUcaTX oBcxUKHrraCTPdN.ZSNdHYO3BFAFMeANNaPWlor7kGn_mrxuVg6YmJZSzmc_ustUsKUMXWDAGyYk qwKafSyvKvZYE_927m9KGtUipa3OwauqmROtRntaZsW_4y4yToO8IKj9n05TXyq0A61IefPsHz0h Qx8zq8PHsrQxFs5pyyq7DPu7Ugxzl3869GyWQzxGshHlWp_RbfTOLcwKMJu2B2mj_HfKUCEo5CTd CSC8b26AQvxa138Aa3QWVEcr1Rpqs.BcHHchFscXvMrqU0rB7Jvxnya8UgQjWkbHO_6a5p3rHCks 524Z.fQwP3b9VsntWnhhY.rhcVf0IU5rRkqNgCj9dhABxZqFTpoXhKbVf7y.wTTfoMeGoW3HO0Bk sagqqwnZxm7Fca5TOyAF7rXcr7.9ceYRCiA7Q8.1_.nx4qyjtSuBugRDSGsxAt3i82uya70wOYkl 67DUYFncL3wiPd2kq6YSwzhVl8W9LiRCQMrg6eRBH8yyygnYTorQNzG0_Y0xnzT0161MBMhhceQ3 SJd3RvZT4749JA1UYY19GVSrb9s99JsLA3UV6GAA02cM0BK7KKSQO_j4KzmszzYxhL3_RazDD4rj bcmHIojzhsAGxZF7AJgGj8cCDnuti5PTMp5mHNdEzbcjRvJz40K8DaXMiVbDO Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Apr 2020 18:22:37 +0000 Received: by smtp411.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 287e492ff757795507ed7eb29f0b74c8; Mon, 20 Apr 2020 18:22:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPi3 From: Mark Millard In-Reply-To: <20200420172512.GA94315@www.zefox.net> Date: Mon, 20 Apr 2020 11:22:32 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200420172512.GA94315@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 495Zmv1LR1z3JWr X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.958,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)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; 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)[83.65.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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: (2.36), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), 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, 20 Apr 2020 18:22:40 -0000 On 2020-Apr-20, at 10:25, bob prohaska wrote: > Back on October 24, 2019 Mason Loring Bliss mason at blisses.org > wrote in part: >=20 > ----------begin excerpt---------- >=20 > I'm struggling with how to boot FreeBSD 12 directly from a hard drive = on an > RPi3b+, with no MMC card. It happens automatically with a Raspbian = image, and > I got Devuan to boot this way by changing the right pointers in = config.txt, > but I'm struggling to figure out how to do it on FreeBSD. I'm not sure = what > dictates the boot behaviour. >=20 > ----------end excerpt--------- > The complete post is at: > = https://lists.freebsd.org/pipermail/freebsd-arm/2019-October/020608.html > Far as I can tell there were no replies. >=20 > In the meantime I've become interested (again) in trying to > boot a Pi3B from a mechanical hard drive by using the "boot > from USB" OTP feature on my Pi3B v.1.2. The feature has been > set, according to the instructions at > = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md > but when the microSD card is removed nothing happens (no rainbow = screen) on > power-up. Presumably my Pi3B is too old. Quoting = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md : QUOTE (presumes temporary boot of the typical RPi OS instead of FreeBSD) . . . check that the OTP has been programmed with: $ vcgencmd otp_dump | grep 17: 17:3020000a Check that the output 0x3020000a is shown. If it is not, then the OTP = bit has not been successfully programmed. In this case, go through the = programming procedure again. If the bit is still not set, this may = indicate a fault in the Pi hardware itself. END QUOTE Have you checked this? Does it report 3020000a? > At some point the Raspberry Pi foundation introduced a new = bootcode.bin > as described in=20 > = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md > which was intended to give older Pi2 and Pi3 models the ability to = boot from=20 > USB at the price of keeping a minimal microSD card in place. All = that's > required on the card is the new version of bootcode.bin plus an empty > file named timeout to give a mechanical drive time to spin up. >=20 > Has anybody tried it? I wouldn't expect it to work "out of the box", > but perhaps with some adjustments.=20 >=20 > In the meantime, I've gotten u-boot to the point of issuing a > prompt and recognizing a usbboot command, but can't seem to get > the syntax right.=20 >=20 > A usb reset command produces > resetting USB... > Bus usb@7e980000: scanning bus usb@7e980000 for devices... 8 USB = Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > and=20 > U-Boot> help usbboot > usbboot - boot from USB device >=20 > Usage: > usbboot loadAddr dev:part >=20 > The only command that doesn't cause a syntax error is >=20 > U-Boot> usbboot 7e980000 0:1 >=20 > Loading from usb device 0, partition 1: Name: usbda1 Type: U-Boot > "Synchronous Abort" handler, esr 0x96000045 > elr: 00000000000cd2f8 lr : 00000000000aef5c (reloc) > elr: 000000003b3a92f8 lr : 000000003b38af5c > x0 : 000000007e980000 x1 : 000000003af6d900 > x2 : 0000000000000200 x3 : 0000000000000000 > x4 : 0000000000000200 x5 : 0000000000000040 > x6 : 2e34445342903ceb x7 : 000000003af7d9c1 > x8 : 0000000000010041 x9 : 0000000000000008 > x10: 0000000000000006 x11: 000000003af6b2e0 > x12: 0000000000000820 x13: 0000000000000001 > x14: 0000000000000001 x15: 00000000ffffffff > x16: 0000000000000001 x17: 000000000000004b > x18: 000000003af57de8 x19: 0000000000000001 > x20: 000000003af6d900 x21: 0000000000000200 > x22: 0000000000000200 x23: 0000000000000000 > x24: 000000003af7db90 x25: 0000000000000000 > x26: 0000000000000000 x27: 0000000000000200 > x28: 000000003f980000 x29: 000000003af4ff60 >=20 > Resetting CPU .. >=20 > That seems to suggest I'm using the wrong address or=20 > address format. So far, I've not been able to find any > docs beyond the help feature at the u-boot prompt. >=20 > The usb drive is recognized as /dev/da0 when the machine > boots 12.1-stable and has a 12.1 stable image on it. =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 Apr 20 19:31:59 2020 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 B2C6C2AC6F2 for ; Mon, 20 Apr 2020 19:31:59 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-oo1-xc44.google.com (mail-oo1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (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 495cJt6bkzz3wxl for ; Mon, 20 Apr 2020 19:31:57 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-oo1-xc44.google.com with SMTP id x17so2399817ooa.3 for ; Mon, 20 Apr 2020 12:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BGPM1tw8XImBAxLoLf/u4patt5GHIzqdF+CnuwHMYq0=; b=X17V/xEj3ccPNB4LbG4RaJwrO6/Mk7zDTqpiiZPo8mA361BJFBPnzlHvYHc/tyFm5S 3y/6oYbnY2LLNtJyME/uL/ouP4PfUb8PWOGKjQuONpLlIXjFS/iQkx0yZVVUik3ueaBy 7RJIWajHhv4k0LuDx7MCJaabFjfn5rYSTakVL7iaJb6fOQz1buPsrDF4ZUvBUAYwulad 1YzGPaWFzUI39OP91IaZvJQexar65SFZjRfn/AMlL4hJwEMO9sbRaFs+eeVo7sXTsaDP VzfoGhbvvz90wyOMsGQC24VaESGVY072ysrP3AS4WwrfoO2dDKh/38nMeeb43L+MKpOj WIfA== 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=BGPM1tw8XImBAxLoLf/u4patt5GHIzqdF+CnuwHMYq0=; b=Wgd5JUPM0ACZJU6VKic5LxiPktZintDJDWA26buwdcjlgxPrAfIFGkC7CVzVupRIRG q4cT3Q6tu+O3m2jMi6bBglOkdoieg9gW9G8ohapD3jf9BVaTwM2oEaubn+A3qkhgG7i7 7SvzLGaTrUSE753CQZGcdjsRHIbsbu1Zigr2SrM+IoKDh3GdP/EiMSt/Z0KmtbVzwSSa 98mGnD6bGCT9ZunRtGeaq17Qq6xbXSqbjpFrHNzhK1oK5HvbNVn26bvn/UDW6uGP5ZKK QXqa/JLHzYq2Y3pvzAsEa2W2INiIRVgpmgOunnRdJUjFtcjnO4oymIrA/qtnxFrznx7h 3qVQ== X-Gm-Message-State: AGi0PubkAja2E7Y8JNxxhVg0ySMiAdeYS8ukJ4LroKw0Nei0AaZn/waa jKjFEy6EBqzC0txSorDN4q0YRMktM61Ob2cechDY3x7CBNE= X-Google-Smtp-Source: APiQypLVb8L84fNQ3FSB1uowvEYvHJ55IAz8TZaLhHqI7Er042JBTTRkwrKgYHnWru8WBjyJa0WpUUyg4bWVxHGU7WM= X-Received: by 2002:a4a:7504:: with SMTP id j4mr14260031ooc.10.1587411116641; Mon, 20 Apr 2020 12:31:56 -0700 (PDT) MIME-Version: 1.0 References: <20200420172512.GA94315@www.zefox.net> In-Reply-To: <20200420172512.GA94315@www.zefox.net> From: Jonathan Chen Date: Tue, 21 Apr 2020 07:31:40 +1200 Message-ID: Subject: Re: Booting from USB on RPi3 To: bob prohaska Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 495cJt6bkzz3wxl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=X17V/xEj; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::c44 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.4.c.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.29)[ip: (2.25), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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, 20 Apr 2020 19:31:59 -0000 On Tue, 21 Apr 2020 at 05:25, bob prohaska wrote: [...] > At some point the Raspberry Pi foundation introduced a new bootcode.bin > as described in > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md > which was intended to give older Pi2 and Pi3 models the ability to boot from > USB at the price of keeping a minimal microSD card in place. All that's > required on the card is the new version of bootcode.bin plus an empty > file named timeout to give a mechanical drive time to spin up. > > Has anybody tried it? I wouldn't expect it to work "out of the box", > but perhaps with some adjustments. [...] This is how I got my RPI3 running 12-STABLE to boot off USB. It does require a microSD card with u-boot, and the loader.efi built sometime after Sep 2019 though. However, my root-filesystem (and swap) lives on an external USB drive. 1. Copy the loader.efi to EFI/BOOT/bootaa64.efi 2. Create a text file: EFI/FreeBSD/loader.env, this file contains a one-line directive to loader(8) on where to find a kernel to boot. Mine contains: rootdev=disk1p1: The disk entry should be the same as what loader(8) expects with your USB disk setup. Mine has a GPT partitioning scheme, with the root-fs on partition-1. 3. All /etc/fstab entries should use symbolic name entries instead of da0*. eg: 7:27am# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/gpt/topaz-root / ufs rw 1 1 /dev/gpt/topaz-swap none swap sw 0 0 Hope this helps. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Mon Apr 20 19:46:57 2020 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 C8C5D2AD31A for ; Mon, 20 Apr 2020 19:46:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 495cf73kQDz3yRl for ; Mon, 20 Apr 2020 19:46:55 +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 03KJkuaX094753 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Apr 2020 12:46:57 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03KJkuK7094752; Mon, 20 Apr 2020 12:46:56 -0700 (PDT) (envelope-from fbsd) Date: Mon, 20 Apr 2020 12:46:56 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting from USB on RPi3 Message-ID: <20200420194656.GB94315@www.zefox.net> References: <20200420172512.GA94315@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 495cf73kQDz3yRl 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 [2.52 / 15.00]; ARC_NA(0.00)[]; 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.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.13)[0.131,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.44)[0.435,0]; 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: Mon, 20 Apr 2020 19:46:57 -0000 On Mon, Apr 20, 2020 at 11:22:32AM -0700, Mark Millard wrote: > > > On 2020-Apr-20, at 10:25, bob prohaska wrote: > > > but when the microSD card is removed nothing happens (no rainbow screen) on > > power-up. Presumably my Pi3B is too old. > > Quoting https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md : > > QUOTE (presumes temporary boot of the typical RPi OS instead of FreeBSD) > . . . check that the OTP has been programmed with: > > $ vcgencmd otp_dump | grep 17: > > 17:3020000a > > Check that the output 0x3020000a is shown. If it is not, then the OTP bit has not been successfully programmed. In this case, go through the programming procedure again. If the bit is still not set, this may indicate a fault in the Pi hardware itself. > END QUOTE > > Have you checked this? Does it report 3020000a? > Yes, it does, using an old Raspbian Stretch installation on microSD. AIUI, this feature only allows boot with no microSD at all. If a microSD is present, whatever bootloader is on it will start and that seems to be the case here. Elsewhere the Pi Foundation notes that some Rpi3's were unable to use the boot-from-usb feature without requiring a microSD card. It's said that the "special" bootcode.bin will work in those cases. However, it's unlikely the new bootcode.bin will correctly load and start Freebsd. Since FreeBSD's u-boot seems able to see the USB hard disk that looked like a good place to start. My error (I think) is the command syntax for usbboot. It requires an address, a device and a partition. The only address the system reports is usb@7e980000, but using that string verbatim causes a syntax error, thus: U-Boot> usbboot usb@7e980000 0:1 Loading from usb device 0, partition 1: Name: usbda1 Type: U-Boot ** Unknown image type If I omit the usb@, _something_ gets loaded, but causes a reboot. Replacing 0:1 with 1:1 silently renews the u-boot prompt with no error. Replacing 0:1 with 0:2 reproduces the synchronous abort handler message. Using U-Boot> usb dev reports IDE device 0: Vendor: Initio Rev: 1.06 Prod: MHT2040AH Type: Hard Disk Capacity: 38154.3 MB = 37.2 GB (78140160 x 512) The reference to IDE probably stems from having an IDE drive in a USB 2.0 adapter. In any case, it's the only USB drive on the system. It contains a FreeBSD image written using dd, just like a bootable microSD card. Thanks for reading, and any ideas! bob prohaska From owner-freebsd-arm@freebsd.org Mon Apr 20 22:07:59 2020 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 CD8552B17A3 for ; Mon, 20 Apr 2020 22:07:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 495gmt1hWWz4CgC for ; Mon, 20 Apr 2020 22:07:57 +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 03KM7vcP094986 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Apr 2020 15:07:57 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03KM7uE0094985; Mon, 20 Apr 2020 15:07:57 -0700 (PDT) (envelope-from fbsd) Date: Mon, 20 Apr 2020 15:07:56 -0700 From: bob prohaska To: Jonathan Chen Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting from USB on RPi3 Message-ID: <20200420220756.GC94315@www.zefox.net> References: <20200420172512.GA94315@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 495gmt1hWWz4CgC 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 [2.29 / 15.00]; ARC_NA(0.00)[]; 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.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.08)[0.080,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.26)[0.260,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: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: Mon, 20 Apr 2020 22:07:59 -0000 On Tue, Apr 21, 2020 at 07:31:40AM +1200, Jonathan Chen wrote: > > This is how I got my RPI3 running 12-STABLE to boot off USB. It does > require a microSD card with u-boot, and the loader.efi built sometime > after Sep 2019 though. However, my root-filesystem (and swap) lives on > an external USB drive. > > 1. Copy the loader.efi to EFI/BOOT/bootaa64.efi > > 2. Create a text file: EFI/FreeBSD/loader.env, this file contains a > one-line directive to loader(8) on where to find a kernel to boot. > Mine contains: > rootdev=disk1p1: > The disk entry should be the same as what loader(8) expects with your > USB disk setup. Mine has a GPT partitioning scheme, with the root-fs > on partition-1. > > 3. All /etc/fstab entries should use symbolic name entries instead of da0*. eg: > 7:27am# cat /etc/fstab > # Device Mountpoint FStype Options Dump Pass# > /dev/gpt/topaz-root / ufs rw 1 1 > /dev/gpt/topaz-swap none swap sw 0 0 > > Hope this helps. > -- Where is the kernel loading from? I gather it's been long-time practice to load the kernel from microSD and then mount the USB device as root; it that what you're doing? It appears that using usbboot (correctly!) would eliminate that extra step. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Mon Apr 20 22:30:46 2020 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 7117B2B1D4D for ; Mon, 20 Apr 2020 22:30:46 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 495hH9456nz4FBG for ; Mon, 20 Apr 2020 22:30:44 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-pj1-x1042.google.com with SMTP id kb16so520527pjb.1 for ; Mon, 20 Apr 2020 15:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vv28bl+dh6Kd57GntlTSDnQASrzL3SIQ3Vu2hiDELb0=; b=MDHtGIHdFcRhRj1tmaNMh62s6hctB0Lqw1u62zweVPi52veETO/nyfAfw2WgqserTV 3BS8ciFg8pThSy+5f+A03n+Hf8N86ZGYoNVERRwPZoH/u2MfkBXbhabMyPe+sw5X/ksv 5TxYpswtuwToU6CEz3NWEcbenp+SDzs7tKJn2ealTs27RZDeWHp3CmraCcidZE1izs2R kwHcnEo+BR33M7gO4hBxFH9+ZrzhArCNZMtBCgpxrmBWBwcS70T049KReq2ro8kzOoHD Zm/xaF57ugXoOGHueuE9Lh6H73s66AT3R1mdCVab87P4Hs+EKtlLq6YYp1Abz1Bp3fG8 1QVw== 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=Vv28bl+dh6Kd57GntlTSDnQASrzL3SIQ3Vu2hiDELb0=; b=lnYjg2GjGqRNeFY59jmwrgbaK+bH2ASwO1Q+Kz5a7K8vftuT1IezNmDuO/4+or/o1U D3r1Z17Zbg1CrRTvskhiETbAUXIxX8+GhmMKIQQFT0N3MA9pRjjnU2TQpSnpCoRdEUOZ 4ElF9/wSozR89YUNE9AxTmTMFhGWc0H0wDzA7mKLd9mcTg5jc4vUnbSEaK9y3quDz25f 5ZG93MVBCpYVmykYrmHUwuWHrcWEes06TQwaot814pW7ju8LTitIwte+pL7pgCOA5AYn dQQb51BTi8KAuXBWhj/Lz6hrze920GkSfAXrYSxLBgKgMmXbQOqh4DTDptJBT8jZkAs4 fY+A== X-Gm-Message-State: AGi0PubU/XSzaaH/I23Nfar/qazs4BD0/D86PM8AlmZpX6XC9enLY5vw cY9Wuo2+2MZFoZWjaug2QyUVvBY4rYvSmpe0LqYw7+21 X-Google-Smtp-Source: APiQypINhPreF+VqqU1nHfrJGtT8Fwc/bmuErg4swlp0BL5L0F//OIghsWGx6q26rp3hg2X6/kexynnQmszxJF2Vi7Y= X-Received: by 2002:a17:902:261:: with SMTP id 88mr13012837plc.308.1587421843238; Mon, 20 Apr 2020 15:30:43 -0700 (PDT) MIME-Version: 1.0 References: <20200420172512.GA94315@www.zefox.net> <20200420220756.GC94315@www.zefox.net> In-Reply-To: <20200420220756.GC94315@www.zefox.net> From: Jonathan Chen Date: Tue, 21 Apr 2020 10:30:27 +1200 Message-ID: Subject: Re: Booting from USB on RPi3 To: bob prohaska Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 495hH9456nz4FBG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=MDHtGIHd; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::1042 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.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)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2.4.0.1.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.16)[ip: (-0.01), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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, 20 Apr 2020 22:30:46 -0000 On Tue, 21 Apr 2020 at 10:07, bob prohaska wrote: > > On Tue, Apr 21, 2020 at 07:31:40AM +1200, Jonathan Chen wrote: > > > > This is how I got my RPI3 running 12-STABLE to boot off USB. It does > > require a microSD card with u-boot, and the loader.efi built sometime > > after Sep 2019 though. However, my root-filesystem (and swap) lives on > > an external USB drive. > > > > 1. Copy the loader.efi to EFI/BOOT/bootaa64.efi > > > > 2. Create a text file: EFI/FreeBSD/loader.env, this file contains a > > one-line directive to loader(8) on where to find a kernel to boot. > > Mine contains: > > rootdev=disk1p1: > > The disk entry should be the same as what loader(8) expects with your > > USB disk setup. Mine has a GPT partitioning scheme, with the root-fs > > on partition-1. > > > > 3. All /etc/fstab entries should use symbolic name entries instead of da0*. eg: > > 7:27am# cat /etc/fstab > > # Device Mountpoint FStype Options Dump Pass# > > /dev/gpt/topaz-root / ufs rw 1 1 > > /dev/gpt/topaz-swap none swap sw 0 0 > > > > Hope this helps. > > -- > > Where is the kernel loading from? I gather it's been long-time > practice to load the kernel from microSD and then mount the USB > device as root; it that what you're doing? It appears that using > usbboot (correctly!) would eliminate that extra step. The kernel loads from the external USB drive. The only thing on the microSD card is the renamed loader.efi and the loader.env file. Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Mon Apr 20 22:32:21 2020 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 7C34D2B1FAC for ; Mon, 20 Apr 2020 22:32:21 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 495hK0535Wz4FT7 for ; Mon, 20 Apr 2020 22:32:20 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-pg1-x543.google.com with SMTP id p8so5803218pgi.5 for ; Mon, 20 Apr 2020 15:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QwognIwuQ+yFjmOj+ip37rV5kobHg8EVYmmmUuWqKWc=; b=xxDuTq7Q0Ya6xPQDzyWJM2tKry5rdIvbmlFnywtxEYSl6hD5Eziip5RpezVFt8Ul3e JCrfpP5vcsMxTXrLsdRiPaMEDzFku4y35bBIK5XfqD+P4DE5JvNDlXn3e+ENr4zdlk6l G/LLA1zmmEJWAohJlw6VZ45Eda2rdaAW7d5nbn1s0Yl/x9gmsSpJPcYr+wLQaphZGEOw Fm7FQloZqhsvHAU/+EmdfUxp5i4OHUr5pstmz7A0NP90CWi+3i3F3lsRLMgdLTiBURqf VqyX4IdNwAyd/KVViJf0ja243Ash1Rc8sGcE3gmfIepBNbSiNHiKtNUwG+TDEGiu9Oyv A/iQ== 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=QwognIwuQ+yFjmOj+ip37rV5kobHg8EVYmmmUuWqKWc=; b=pjJ5FDw/hxKIWBb55j4t6niapgU88zfnCI0NvEEpHMWtv4zyWyHamEyX2Lh78gIY+b FCAP47XWREp9Nq4fpJ/nLiNzND0aONqe61+fYRXDfMOaES8Qzyl6opOgCPqi19xQ7qCn D+lRHLZjrRgJ3lN+9K1ne6kbK4J6+IWy3wqstoWc1+8L1ri4fcl4aeC3wY4IYUkUmvxW fWj6rJLwKqgm01/thPnTJLPtgZ1suOhQW1161NavjvHZkzfQALOb/F8fXIswOidEzRnt qccpce/0XVQeTgaPM7Dkb14bICHNwebLs95RqMTuT6rRDnsGVuQq8wB7CWWREkFs38uy 1sQg== X-Gm-Message-State: AGi0PuZG7rg885PSzY0PIiPbEkGNr9o/bOH2+sIqKL02ZtmAO8QXOBd7 VS9UM3TdTxFTcOe0OhXneJnKE0yl7ozr3BAXTu5ZeXOs X-Google-Smtp-Source: APiQypLJ+QAKxpw2DE8plXIK0Qm3fpyzdovb7ui4eCq/qWCQwxLWCZPaozS4FWsCZeTGpgtAuG9w0URC/I3CqchKk0M= X-Received: by 2002:aa7:931a:: with SMTP id 26mr18155422pfj.11.1587421939172; Mon, 20 Apr 2020 15:32:19 -0700 (PDT) MIME-Version: 1.0 References: <20200420172512.GA94315@www.zefox.net> <20200420220756.GC94315@www.zefox.net> In-Reply-To: From: Jonathan Chen Date: Tue, 21 Apr 2020 10:32:03 +1200 Message-ID: Subject: Re: Booting from USB on RPi3 To: bob prohaska Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 495hK0535Wz4FT7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=xxDuTq7Q; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::543 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.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)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[3.4.5.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.17)[ip: (-0.03), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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, 20 Apr 2020 22:32:21 -0000 On Tue, 21 Apr 2020 at 10:30, Jonathan Chen wrote: [...] > > Where is the kernel loading from? I gather it's been long-time > > practice to load the kernel from microSD and then mount the USB > > device as root; it that what you're doing? It appears that using > > usbboot (correctly!) would eliminate that extra step. > > The kernel loads from the external USB drive. The only thing on the > microSD card is the renamed loader.efi and the loader.env file. And the u-boot, of course. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Mon Apr 20 22:32:39 2020 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 C90BA2B2027 for ; Mon, 20 Apr 2020 22:32:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (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 495hKL3cBsz4FY9 for ; Mon, 20 Apr 2020 22:32:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 082xhdkVM1n8HOmJSb5rUVWloJdnjDl9eU8m7Txe.TfL3xQqMxAiRsZNHxmVOIv EboTcZjwut5ix86.nzT9u3nfW1AoeptQTw5AF50RjG3L2UR0Q3TAhbEnK3Z2kk5zSyKo9ztGV7jF 5WyVbDoV2UGM_qf.iJeaS8T8xwlhq_KdtXxc9zV.7mmLHC7Fzi9dpUfEnFXSaZL7Cj2MFin_n4MP zbfrgLo5XbxkLS6YWbWRqAs_jkK9KBrX5ZMLJ.dZNo4BmJDjcDc_LbSq0QzpaESMtEqvDpktdB49 _n53moOuH562nsLe2Gf1Cc_pea82R.E8OY7fFy6llxe0wMfoUNcP1lcRrgcj5ztDh3tiBnANpvEy KRl_4ri8Rlmssz8BsuUTNY.lY9RRfNHTgr_9xC884Rj09iSuEU3tQxE633VmRA5rF_OsSlduoN.i zNbZRxqEyomC8JR8Ijt8pu9qIPRxPNVpMHkLo3jt3JN2Uw9RQKb1anBGjgvlmBuEqXvhXivvX7Pn 9d7GQAK7FPSPFJE1aTLoF7Nfx3TvhZ1NaiGVqXNP_YgPH7WQMLfD671Uu_XVBjdvrkg1YNNLNIt1 Ctu21mjEAwBm7mTaRQ4oulFHpT5nNTAQ0jbIsMVgKTOkrLm4Jbj2Tgguzc_P29zDhKGVCX3M0wJb 5HXSvudnVjozCRUASYnvdMcOkkId1zosRek3QeoM4_43bMYw9n8cqYUywDZufRCwLDROhjDs1MEL 4M1fEwEsRf8lCpJniFxzC.3kr3R_r.hrMy0Fwlp8pbL15Bz9yshqq8fNfS7Ep1oewr3J.1ImRMTC e3.BDWmDDeZXnorNraBEER8IDdjdoF1hnepz5NQ6Czui60ozLbYvos.IrnqADwSVvXQ92yZYF7NY dNW7o3HRNuxXbG76KF3_5ohq7YkYDdgJyXkCqdiTeYIm8CGQiSq4iPwAe_wJISHDx37q2x5U4Hw7 xBZQzU0y63YMNxHLKwR2KzCIuxIEm5zE1DY0ySbfJeJ7nf4_N05bY2CEy6h.Pp_DvWYHliBKEkDS BnbCspwAbiojRPC1M8azHXcO1Zuy0zjKPwgaWXTyBec1y8DwHds9bS5uBsVrn.ZFinJFuBRCAbM7 e6K9NkUndnNFL8lSMqLbm.d9lraucfBk860inl9Rl4bA.uqZZsFheeNRgS28qcS39yjiBftxamTr 7bIg83A9R8rFMYKFfmvv1QQdqLqVrw_1ypX5GfJIC2BX1iYloBNGYjXMHcA9vFYofKs.0McLeaXU 50Fq5UgkAvPoMWZ1GhVRJa5l7WNZeDuydRJkBAwbyuk3x_gCU887ZCHVswyUdt5_Xg9t8O5dWF1N rYHKYNH0y3NtVg.Ey9NdbkYd5mywx.A7S4tz59sztt1paHQ1PhBURbcfGLJFaJqtq7dGY0fM0Mbb 0TkwqKJmwbBKiN1N4PDVqVX0oaXDSqu_nRWdSiBtWbW_Uw9UWysjP8s9WP26I Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Apr 2020 22:32:36 +0000 Received: by smtp407.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9e90aea6acc560efeadf58d1911a62fa; Mon, 20 Apr 2020 22:32:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPi3 From: Mark Millard In-Reply-To: <20200420220756.GC94315@www.zefox.net> Date: Mon, 20 Apr 2020 15:32:31 -0700 Cc: Jonathan Chen , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <39CD6D0A-AF9B-4E5E-95C9-11E343F02082@yahoo.com> References: <20200420172512.GA94315@www.zefox.net> <20200420220756.GC94315@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 495hKL3cBsz4FY9 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.793,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.98)[-0.977,0]; TO_DN_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[32.64.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; 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: (5.20), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), 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, 20 Apr 2020 22:32:39 -0000 On 2020-Apr-20, at 15:07, bob prohaska wrote: > On Tue, Apr 21, 2020 at 07:31:40AM +1200, Jonathan Chen wrote: >>=20 >> This is how I got my RPI3 running 12-STABLE to boot off USB. It does >> require a microSD card with u-boot, and the loader.efi built sometime >> after Sep 2019 though. However, my root-filesystem (and swap) lives = on >> an external USB drive. >>=20 >> 1. Copy the loader.efi to EFI/BOOT/bootaa64.efi >>=20 >> 2. Create a text file: EFI/FreeBSD/loader.env, this file contains a >> one-line directive to loader(8) on where to find a kernel to boot. >> Mine contains: >> rootdev=3Ddisk1p1: >> The disk entry should be the same as what loader(8) expects with your >> USB disk setup. Mine has a GPT partitioning scheme, with the root-fs >> on partition-1. >>=20 >> 3. All /etc/fstab entries should use symbolic name entries instead of = da0*. eg: >> 7:27am# cat /etc/fstab >> # Device Mountpoint FStype Options Dump = Pass# >> /dev/gpt/topaz-root / ufs rw 1 = 1 >> /dev/gpt/topaz-swap none swap sw 0 = 0 >>=20 >> Hope this helps. >> --=20 >=20 > Where is the kernel loading from? I gather it's been long-time > practice to load the kernel from microSD and then mount the USB > device as root; it that what you're doing? It appears that using > usbboot (correctly!) would eliminate that extra step. Looks to me like the rootdev assignment is controlling where the kernel is loaded from but the FreeBSD loader and its loader.env still are found on the microsd card and used from there. So if "extra step" means any use of a miscrosd card, then it would not meet what appear to be your criteria. But if you are okay with only needing a msdos file system based microsd card with appropriate materials added to the msdos file system (no freebsd partitions required), then it might be okay. I'm not sure if armv7's without an EFI-like context have a msdos file system path analogous to EFI/FreeBSD/loader.env to allow the same sort of rootdev-assignment technique or not. If your context is an example of: QUOTE in situations where a Pi 3 fails to boot (the latest bootcode.bin = includes additional bugfixes for the Pi 3B, compared to the boot code = burned into the BCM2837A0) END QUOTE then I'm not sure that you can avoid the microsd card being involved. But that would be testable in a normal RPi OS context: If you can boot Raspbian via USB-only in the normal USB-only manor, then the problem is elsewhere for doing so for FreeBSD. Going the other way: If you can not boot Raspbian via USB-only, then the microsd card is likely going to be involved for any OS for that specific RPi3. =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 Apr 21 17:18:20 2020 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 5158A2B0FC4 for ; Tue, 21 Apr 2020 17:18:20 +0000 (UTC) (envelope-from georg.lindenberg@web.de) Received: from mout.web.de (mout.web.de [212.227.15.3]) (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 "mout.web.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4969JC0LvZz3Crw for ; Tue, 21 Apr 2020 17:18:18 +0000 (UTC) (envelope-from georg.lindenberg@web.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587489497; bh=TWyEA/5711w42f4RwH52OdWcV1tAZMQUt+m/R1CmSkc=; h=X-UI-Sender-Class:From:To:Subject:Date:In-Reply-To:References; b=BUSNZxxu/gkUf4CB7V/PS89/YLZumu4JscrpEm3T12MfOX1rn3mCEdJmZ3s/YsDoW s5FlY9XUbe8iYTAcUPA/4ApDqCEYHrRCHhNBtIBTi17avdkoDa8saaVU530P6g3fhv ZOOBVQQmSVVVtPXhxrY7yh7cTyL9azTjbt/pddyY= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [46.253.79.38] ([46.253.79.38]) by web-mail.web.de (3c-app-webde-bs65.server.lan [172.19.170.190]) (via HTTP); Tue, 21 Apr 2020 19:18:17 +0200 MIME-Version: 1.0 Message-ID: From: "Georg Lindenberg" To: freebsd-arm@freebsd.org Subject: Booting from USB on RPI3 Content-Type: text/plain; charset=UTF-8 Date: Tue, 21 Apr 2020 19:18:17 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:rgqdsc1/ex+MudgnwHkMDXcTC0Ead9E7y/8RFftEqkNxAHhoN9XFdfJF1+FCw5RxolZaP gGLEjRvWiBI+SbUFqiuraoO/a4QdZdT/imhSfvBMZ1vVagT7627ykd2u8GdR3fGfx3A/LFCnm+UE Mj+QlvOmgmlxcWZYeciE0fh3uvV/qvzR/p7Bj3QykHVLcLw0USAslIa95LbgIYZGpT20zMKauRoc 3eC/1EExT5Ry6Qp0YC/koLOevClpvi3dQrFzhxg3bAMIw1on6p20PdI08Kpbl/8ZbciTr2nXSoaa UE= X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:nkdCu1FxgzE=:bzD29zlw6Ysb5K01bN5g1l i9Exwji3UU21coU17ioZU1YBVenhrowGsRW3sfpOC7CBRIXqrPfjmErxw7WoI4WFYhEtDcZcg lougcuE6XRlQjrpqmgw/SB2nNpFmX5Lup6oK83akQjvhSvim9yE9Nwdsd0JsWNcU+1nc5AqBt K5ZhVEZpntqCu3gAhQaqU5jMFZnHP4rFwhT0ypYJZWe3WjEWdqQeG9VXksN58NQkWg8M+OWUL /9oNnRY18xjk3tjifHh+bGTrE7Rf2zjWEowj/rhRrchQP+IjsTxyGpdTF/nx1z3Me3YIWlBjz 1yqd/7wbCns/K2PDx2Pyn3H93KUrzVp4EpIh5efjqE+m6h25tkOAIQsXkykeOkx/rs4whzv1Y RlRCHgXxGTHOX+iYvkRmlJ0WpnswppSsFlSF3338cHLafi4VzcdaMOdJlg068Y660eyDxWFGW MRuT8G0mplUmySZ/8HYxnoC0u3VB3ebBYHRl08vn/pQAKeO+VUw+curLBN0qYlkUhuotldYIM NXxU7ojRTnVTT+vjKIGZIJNIXM5cWXkrCgXgORgzk6VUH+LH8F2bgxm1581dJ4MjAph2H+BLx /RaiOhZ4HnUxMWLtYyL7uTE/uegiubDsS+4IwB2GVIfX8Hw2wpoq2Uqrvinj9O4g96pEIiRzT NmyCYWGI+14PAV9jv4BvlyPr3sVCWoYC4nWOosPBQXWt/nebedIfGXWuuwC+SytCQkZY= X-Rspamd-Queue-Id: 4969JC0LvZz3Crw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=web.de header.s=dbaedf251592 header.b=BUSNZxxu; dmarc=none; spf=pass (mx1.freebsd.org: domain of georg.lindenberg@web.de designates 212.227.15.3 as permitted sender) smtp.mailfrom=georg.lindenberg@web.de X-Spamd-Result: default: False [-3.09 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[3.15.227.212.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; FREEMAIL_FROM(0.00)[web.de]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[web.de:+]; HAS_X_PRIO_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[3.15.227.212.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_ENVFROM(0.00)[web.de]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; R_DKIM_ALLOW(-0.20)[web.de:s=dbaedf251592]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[web.de]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[web.de.dwl.dnswl.org : 127.0.5.1]; IP_SCORE(0.00)[ipnet: 212.227.0.0/16(-1.20), asn: 8560(2.08), country: DE(-0.02)]; MID_RHS_NOT_FQDN(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, 21 Apr 2020 17:18:20 -0000 Hey, These are the steps I took to boot my RPI3B from usb. 1. Put the .img file on both the usb device and the SD Card (e.g. with dd). 2. Plug in everything. RPI starts uboot from the SD Card. 3. Type any key to enter the U-Boot prompt. Then type "run usb_boot". You can see all the uboot variables with "env print". Maybe it is possible to add "boot_cmd=run usb_boot" to one of the config files, but I was too scared to try it. From owner-freebsd-arm@freebsd.org Tue Apr 21 17:26:52 2020 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 1851D2B1682 for ; Tue, 21 Apr 2020 17:26:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4969V25rcZz3DTs for ; Tue, 21 Apr 2020 17:26: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 03LHQiVh097176 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Apr 2020 10:26:45 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03LHQig9097175; Tue, 21 Apr 2020 10:26:44 -0700 (PDT) (envelope-from fbsd) Date: Tue, 21 Apr 2020 10:26:44 -0700 From: bob prohaska To: Jonathan Chen Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting from USB on RPi3 Message-ID: <20200421172644.GA96994@www.zefox.net> References: <20200420172512.GA94315@www.zefox.net> <20200420220756.GC94315@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4969V25rcZz3DTs 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 [1.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.30)[-0.302,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.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.05)[0.052,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: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, 21 Apr 2020 17:26:52 -0000 On Tue, Apr 21, 2020 at 10:32:03AM +1200, Jonathan Chen wrote: > On Tue, 21 Apr 2020 at 10:30, Jonathan Chen wrote: > [...] > > > Where is the kernel loading from? I gather it's been long-time > > > practice to load the kernel from microSD and then mount the USB > > > device as root; it that what you're doing? It appears that using > > > usbboot (correctly!) would eliminate that extra step. > > > > The kernel loads from the external USB drive. The only thing on the > > microSD card is the renamed loader.efi and the loader.env file. > > And the u-boot, of course. You're doing what I'd like to accomplish. However, I take it the chain of events is that the Pi's GPU starts u-boot on the microSD, that starts FreeBSD's loader on the microSD card then FreeBSD's loader acceses the USB drive. I gather there is no bootable FAT32 partition on the USB drive. Have I got that right? Thank you! bob prohaska From owner-freebsd-arm@freebsd.org Tue Apr 21 18:05:29 2020 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 EA8AF2B323E for ; Tue, 21 Apr 2020 18:05:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 496BLc5j0Mz3J8R for ; Tue, 21 Apr 2020 18:05:28 +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 03LI5SBr097267 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Apr 2020 11:05:29 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03LI5Sph097266; Tue, 21 Apr 2020 11:05:28 -0700 (PDT) (envelope-from fbsd) Date: Tue, 21 Apr 2020 11:05:28 -0700 From: bob prohaska To: Mark Millard Cc: Jonathan Chen , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting from USB on RPi3 Message-ID: <20200421180528.GB96994@www.zefox.net> References: <20200420172512.GA94315@www.zefox.net> <20200420220756.GC94315@www.zefox.net> <39CD6D0A-AF9B-4E5E-95C9-11E343F02082@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39CD6D0A-AF9B-4E5E-95C9-11E343F02082@yahoo.com> X-Rspamd-Queue-Id: 496BLc5j0Mz3J8R 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 [1.85 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.26)[-0.256,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(0.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.15)[0.150,0]; 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, 21 Apr 2020 18:05:30 -0000 On Mon, Apr 20, 2020 at 03:32:31PM -0700, Mark Millard wrote: > > > On 2020-Apr-20, at 15:07, bob prohaska wrote: > > > On Tue, Apr 21, 2020 at 07:31:40AM +1200, Jonathan Chen wrote: > >> > >> This is how I got my RPI3 running 12-STABLE to boot off USB. It does > >> require a microSD card with u-boot, and the loader.efi built sometime > >> after Sep 2019 though. However, my root-filesystem (and swap) lives on > >> an external USB drive. > >> > >> 1. Copy the loader.efi to EFI/BOOT/bootaa64.efi > >> > >> 2. Create a text file: EFI/FreeBSD/loader.env, this file contains a > >> one-line directive to loader(8) on where to find a kernel to boot. > >> Mine contains: > >> rootdev=disk1p1: > >> The disk entry should be the same as what loader(8) expects with your > >> USB disk setup. Mine has a GPT partitioning scheme, with the root-fs > >> on partition-1. > >> > >> 3. All /etc/fstab entries should use symbolic name entries instead of da0*. eg: > >> 7:27am# cat /etc/fstab > >> # Device Mountpoint FStype Options Dump Pass# > >> /dev/gpt/topaz-root / ufs rw 1 1 > >> /dev/gpt/topaz-swap none swap sw 0 0 > >> > >> Hope this helps. > >> -- > > > > Where is the kernel loading from? I gather it's been long-time > > practice to load the kernel from microSD and then mount the USB > > device as root; it that what you're doing? It appears that using > > usbboot (correctly!) would eliminate that extra step. > > Looks to me like the rootdev assignment is controlling > where the kernel is loaded from but the FreeBSD loader > and its loader.env still are found on the microsd card > and used from there. > > So if "extra step" means any use of a miscrosd card, then > it would not meet what appear to be your criteria. My only real criteria is that I be able carry out the steps needed to make it work 8-). There's nothing intrinsically wrong with using the microSD card. In some ways it's good. > But if > you are okay with only needing a msdos file system > based microsd card with appropriate materials added > to the msdos file system (no freebsd partitions required), > then it might be okay. > > I'm not sure if armv7's without an EFI-like context have > a msdos file system path analogous to EFI/FreeBSD/loader.env > to allow the same sort of rootdev-assignment technique or > not. > > If your context is an example of: > > QUOTE > in situations where a Pi 3 fails to boot (the latest bootcode.bin includes additional bugfixes for the Pi 3B, compared to the boot code burned into the BCM2837A0) > END QUOTE > > then I'm not sure that you can avoid the microsd card > being involved. > > But that would be testable in a normal RPi OS > context: If you can boot Raspbian via USB-only > in the normal USB-only manor, then the problem > is elsewhere for doing so for FreeBSD. Going > the other way: If you can not boot Raspbian via > USB-only, then the microsd card is likely going > to be involved for any OS for that specific RPi3. > I think you're correct that I should test this using default Raspbian. I originally hoped that setting the USB boot OTP bit would guide the Pi to boot the msdos partition on the USB device, exactly as it boots from the microSD. In my case, even with the USB boot OTP bit set the Pi does not flash the rainbow screen when the microSD card is absent; it just sits inert on power-up. Only with a bootable microSD does the Pi seem to do anything. In principle having a dual-boot configuration seems desirable: A microSD-based "repair" installation, which can by default boot a USB-based "production" installation. It would be reminiscent of older FreeBSD versions that brought up a boot manager, allowing dual boot between, in those days, Windows and FreeBSD. Unfortunately Raspbian can't read UFS, but it does at least provide a hardware test. I expected the boot sequence to hop from microSD msdos partition to USB msdos partition. If I'm reading right that that's not how it's presently being done. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Tue Apr 21 18:12:24 2020 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 8FE742B37D8 for ; Tue, 21 Apr 2020 18:12:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 496BVb4Vx4z3JfY for ; Tue, 21 Apr 2020 18:12:23 +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 03LICPQJ097292 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Apr 2020 11:12:25 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03LICO0d097291; Tue, 21 Apr 2020 11:12:24 -0700 (PDT) (envelope-from fbsd) Date: Tue, 21 Apr 2020 11:12:24 -0700 From: bob prohaska To: Georg Lindenberg Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200421181224.GC96994@www.zefox.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 496BVb4Vx4z3JfY 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 [1.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.39)[-0.393,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.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.10)[-0.100,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[web.de]; 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, 21 Apr 2020 18:12:24 -0000 On Tue, Apr 21, 2020 at 07:18:17PM +0200, Georg Lindenberg wrote: > Hey, > These are the steps I took to boot my RPI3B from usb. > > 1. Put the .img file on both the usb device and the SD Card (e.g. with dd). > 2. Plug in everything. RPI starts uboot from the SD Card. > 3. Type any key to enter the U-Boot prompt. Then type "run usb_boot". > That's a command I didn't know about, despite considerable looking. Is it described anywhere? It'll be my next experiment! > You can see all the uboot variables with "env print". Maybe it is possible to add "boot_cmd=run usb_boot" to one of the config files, but I was too scared to try it. My Pi3's setup is experimental, so crashing/corrupting it isn't a problem. Thanks very much for writing! bob prohaska From owner-freebsd-arm@freebsd.org Tue Apr 21 18:34:54 2020 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 B07872B4646 for ; Tue, 21 Apr 2020 18:34:54 +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 496C0Y3bWYz3LCG for ; Tue, 21 Apr 2020 18:34:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: nrpQKloVM1kLeJAMRffcHxy4TAgnODN3M5fB_BsCJkWid8g3QO62wdwB9r43raD Xk1i0J12kCnIh8ZZi9NvBCl6r0QdaENvff8nIvJPaE4ENLHkJldmCwEaAxx4b3JoX3Gfr5FBfT9z Kh.dOQycmKKBoKGO88idOToTMbfleC_DRv46WcSfp2y2K2Ep8UwB1nLwFQyfswOuupfecPEFetWW UTy9ZeG2YDi1ZrR5QbsXSDanJuVGSeBJq7TbhUQfcs0u67Gqvby.NwAYWzUTJuSKxt3vPchXHUj0 4kBFhvVLxcYTA63bUPxUzukI5Ur5TVIiC22.53Lbqn3o56ELYa7iMCP83A2vFnZjdE2ZJfCloGy8 t5VUO8A44F8XRBndmEwx5fI80GLSzVg0P0tSEFPCmnjYJBF99USJJ8Q95t.ZrwnNU2S_mhBfVbPE 4_amtqRc9VbhxbPWjgFJiAWvgEyYzjCfrO.msPOVg_B2MaXRADC_55BPD5Rf3oZmsFRwW0cC0t6a h0OWj0RMF3EwyA8JU8tAIE1GF1UO00JyOdF8yZEjKwhw2IeDerwHt6VEurxkwG_Fq882FZ0SPJfM 9yiCUKhiPPvhBfHjWeomxpWvHLoshHGe0R639JBbkliE6guimyB37r00lbHpZ40rjN.0ztC7M.Yw u9pqf1upyfRIBYV5QHvVjSGDCHgrqR6609znRy.Jb8wPx7_T1xjh_Cqbhm.t.LDP8LKVoirECzK1 D1OlugcRMKtWgPL8Fcru9u3XSCAiMhoTybmdZG6uE203cQCOVyylwZT4CjZ5QaE5iOtPe5_5_03t nhflCMPcJ0X1OFU7wB820V9wA7flfhMorhkzGhfH3aFPY83Ss..08Qb6QbMoUOyEGChk6haFQeeq 6ZVJotAmswSVvWBsRespJ3AftMLZZbQKu8nI5r0N_tvoZXhfyLEGWKB0IqoR1bqN3VblR2.r5vmP FxyPINSSr3XLXemLJn5Rr5mTApRoe7LTqUVTU6IXFuS_dTeU_Vq3obIdEkIGhxvFnJMRmufwt3fb YeeaX6Ethq_C1ckYxT3FCZ8hIfketUY2flEe8Rm.QR.K8JRymFeBA5c4be2unsN0pRw8F6MqjJz6 5ICnp3xy7nd.gd4Ll.E4YukhiuD6vKZ61kHb1uU_Mkfxqyp7.QdPTYPq9TDB4HO4EGf1YS8xb1l6 2zaADrgyhyDV6QqqSYpr2_Bmm2NdiWDp6ccRvyCSbTc0hV6hX5O1UllwtUz2E97mwQWzIddN0C0J Dqi96T5PB_xnC9lH.uYGU_lpUlxayL0RPZ6ZCvaLbeOtx3jZ81BMpedrUaFexlSv0bNq3ZSWzzun KdRR8Vhw4uhqHf4r35HLoGOKOztMK30YJdKypMQuaznFC75BNHXD1IH4G3UGhT6vKb2uioPihhd6 Pc_6JqI4WzGmCh.Uf.VWqQeo- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Apr 2020 18:34:51 +0000 Received: by smtp429.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2343a2e60d9e669a2d9f3a2a1863ad1c; Tue, 21 Apr 2020 18:34:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPi3 From: Mark Millard In-Reply-To: <20200421180528.GB96994@www.zefox.net> Date: Tue, 21 Apr 2020 11:34:48 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <29E271DA-7E32-43EE-A029-4B9C35C1D1E9@yahoo.com> References: <20200420172512.GA94315@www.zefox.net> <20200420220756.GC94315@www.zefox.net> <39CD6D0A-AF9B-4E5E-95C9-11E343F02082@yahoo.com> <20200421180528.GB96994@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 496C0Y3bWYz3LCG X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982,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]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.99)[-0.991,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[83.65.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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: (2.09), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), 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, 21 Apr 2020 18:34:54 -0000 On 2020-Apr-21, at 11:05, bob prohaska wrote: > On Mon, Apr 20, 2020 at 03:32:31PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2020-Apr-20, at 15:07, bob prohaska wrote: >>=20 >>> On Tue, Apr 21, 2020 at 07:31:40AM +1200, Jonathan Chen wrote: >>>>=20 >>>> This is how I got my RPI3 running 12-STABLE to boot off USB. It = does >>>> require a microSD card with u-boot, and the loader.efi built = sometime >>>> after Sep 2019 though. However, my root-filesystem (and swap) lives = on >>>> an external USB drive. >>>>=20 >>>> 1. Copy the loader.efi to EFI/BOOT/bootaa64.efi >>>>=20 >>>> 2. Create a text file: EFI/FreeBSD/loader.env, this file contains a >>>> one-line directive to loader(8) on where to find a kernel to boot. >>>> Mine contains: >>>> rootdev=3Ddisk1p1: >>>> The disk entry should be the same as what loader(8) expects with = your >>>> USB disk setup. Mine has a GPT partitioning scheme, with the = root-fs >>>> on partition-1. >>>>=20 >>>> 3. All /etc/fstab entries should use symbolic name entries instead = of da0*. eg: >>>> 7:27am# cat /etc/fstab >>>> # Device Mountpoint FStype Options = Dump Pass# >>>> /dev/gpt/topaz-root / ufs rw 1 = 1 >>>> /dev/gpt/topaz-swap none swap sw 0 = 0 >>>>=20 >>>> Hope this helps. >>>> --=20 >>>=20 >>> Where is the kernel loading from? I gather it's been long-time >>> practice to load the kernel from microSD and then mount the USB >>> device as root; it that what you're doing? It appears that using >>> usbboot (correctly!) would eliminate that extra step. >>=20 >> Looks to me like the rootdev assignment is controlling >> where the kernel is loaded from but the FreeBSD loader >> and its loader.env still are found on the microsd card >> and used from there. >>=20 >> So if "extra step" means any use of a miscrosd card, then >> it would not meet what appear to be your criteria.=20 >=20 > My only real criteria is that I be able carry out the steps > needed to make it work 8-). There's nothing intrinsically > wrong with using the microSD card. In some ways it's good.=20 >=20 >> But if >> you are okay with only needing a msdos file system >> based microsd card with appropriate materials added >> to the msdos file system (no freebsd partitions required), >> then it might be okay. >>=20 >> I'm not sure if armv7's without an EFI-like context have >> a msdos file system path analogous to EFI/FreeBSD/loader.env >> to allow the same sort of rootdev-assignment technique or >> not. >>=20 >> If your context is an example of: >>=20 >> QUOTE >> in situations where a Pi 3 fails to boot (the latest bootcode.bin = includes additional bugfixes for the Pi 3B, compared to the boot code = burned into the BCM2837A0) >> END QUOTE >>=20 >> then I'm not sure that you can avoid the microsd card >> being involved. >>=20 >> But that would be testable in a normal RPi OS >> context: If you can boot Raspbian via USB-only >> in the normal USB-only manor, then the problem >> is elsewhere for doing so for FreeBSD. Going >> the other way: If you can not boot Raspbian via >> USB-only, then the microsd card is likely going >> to be involved for any OS for that specific RPi3. >>=20 >=20 > I think you're correct that I should test this using > default Raspbian. I originally hoped that setting the > USB boot OTP bit would guide the Pi to boot the msdos=20 > partition on the USB device, exactly as it boots from > the microSD.=20 >=20 > In my case, even with the USB boot OTP bit set the Pi > does not flash the rainbow screen when the microSD > card is absent; it just sits inert on power-up. Only=20 > with a bootable microSD does the Pi seem to do anything.=20 >=20 > In principle having a dual-boot configuration seems desirable: > A microSD-based "repair" installation, which can by default=20 > boot a USB-based "production" installation. It would be > reminiscent of older FreeBSD versions that brought up a boot > manager, allowing dual boot between, in those days, Windows > and FreeBSD. Unfortunately Raspbian can't read UFS, but it > does at least provide a hardware test.=20 >=20 > I expected the boot sequence to hop from microSD msdos partition > to USB msdos partition. If I'm reading right that that's not how=20 > it's presently being done.=20 Cross checking on other things: Which style of partitioning is in use on the USB drive? Same style as on the microsd card(s) that you use for booting? The RPi*'s do not deal with gpt or such for boot media. One thing that I do not know: does the RPi3 boot handle USB hubs (beyond its internal one(s))? In other contexts, I've had access to machines that could only handle direct connections for a USB boot drive, not boot-drives that were off a powered hub. =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 Apr 21 19:01:00 2020 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 1619A2B55C1 for ; Tue, 21 Apr 2020 19:01:00 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 496CZg0lrsz3MWR for ; Tue, 21 Apr 2020 19:00:58 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-ot1-x341.google.com with SMTP id g19so1994738otk.5 for ; Tue, 21 Apr 2020 12:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3NJ5ulicK+ldsP3tSOgCGtHapC1gGrDAXhT2ENWG/QE=; b=ybK2BjoHJBsYAWGNKEoQZYxd3ucyus7+3AHWY9mXOf14LcH6l+O5QXS1u5z1YUc9vQ V0rbYedpARj/TyVOiheuAu6bVqmoBZx79g8KAjkVT/H0ciWZxr1VjHzyaDtMjCP46FQ5 JaVWQvCde5jEbtQhbfMoXZOLOpD9fqPErTunOBNHwdgj0wBDs9HG7GPTSyphp+KiQE2y kyFKIq4Gsc4DJz5IVfov0zy8x/XvOGshyGmN+XLC1yPqNnTONYrd3D5BRIT0osKlXGMk H88/3IgZHf8d0kEnSexTu4FzEeRvo86XwgYeMyPPZlK00k4bMPNYjtZv2rhwZwEfTssr OkdA== 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=3NJ5ulicK+ldsP3tSOgCGtHapC1gGrDAXhT2ENWG/QE=; b=eaQUIh24mOvZOo5fZz1Wo3sNKT5Cb5iiIGrHpDgFOa7vhsd90VHaw5+KpqSjwJOIRp PorHegmRIqM5T2Q4667pG/pnPGx4Q+0Vptmw2RJwKKbhHe7Zoh68ww3XHHVI+2yqIe57 BW7JnSIGr7tJShtmserC9fwjiGw99BKmbfpP2vG2KZuDHuACRvojyt1Vo+r/x+kKRqxs mbFYeiK0xlell4G1JPkTSLgj5Y3ZU9RJeQ1BkATyi6qO8qOhiQ+pntnULWO10bd6A3J5 GDwXhxbQHK6bwIgH88/zyzPEG72o90W6IZr8dHd9SxIu4Lv7sS/ORWicMrQcetBI9dCR wqmA== X-Gm-Message-State: AGi0PuZI3cOMFMZvRUjUkhhOBHJkLlp2ecn/J0qVOsdkkKrnGPxwYOJi ABKpXvla6INAOoJh/1bBTHktrWxoHGCM46TBeynBtPIB X-Google-Smtp-Source: APiQypKlaTRCI2rtrMxN5PR8e0K1HfXkMMq8ty6DPAo2LibzwcNHMelJh5oXb5PdKupt40cIM+I1Bu1OCaHOpU+Kjm0= X-Received: by 2002:a9d:202:: with SMTP id 2mr15594003otb.255.1587495656860; Tue, 21 Apr 2020 12:00:56 -0700 (PDT) MIME-Version: 1.0 References: <20200420172512.GA94315@www.zefox.net> <20200420220756.GC94315@www.zefox.net> <20200421172644.GA96994@www.zefox.net> In-Reply-To: <20200421172644.GA96994@www.zefox.net> From: Jonathan Chen Date: Wed, 22 Apr 2020 07:00:40 +1200 Message-ID: Subject: Re: Booting from USB on RPi3 To: bob prohaska Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 496CZg0lrsz3MWR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=ybK2BjoH; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::341 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.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)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.4.3.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.08)[ip: (0.42), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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, 21 Apr 2020 19:01:00 -0000 On Wed, 22 Apr 2020 at 05:26, bob prohaska wrote: > > On Tue, Apr 21, 2020 at 10:32:03AM +1200, Jonathan Chen wrote: > > On Tue, 21 Apr 2020 at 10:30, Jonathan Chen wrote: > > [...] > > > > Where is the kernel loading from? I gather it's been long-time > > > > practice to load the kernel from microSD and then mount the USB > > > > device as root; it that what you're doing? It appears that using > > > > usbboot (correctly!) would eliminate that extra step. > > > > > > The kernel loads from the external USB drive. The only thing on the > > > microSD card is the renamed loader.efi and the loader.env file. > > > > And the u-boot, of course. > > You're doing what I'd like to accomplish. However, I take it the > chain of events is that the Pi's GPU starts u-boot on the microSD, > that starts FreeBSD's loader on the microSD card then FreeBSD's > loader acceses the USB drive. I gather there is no bootable FAT32 > partition on the USB drive. > > Have I got that right? Yes. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Wed Apr 22 06:06:01 2020 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 A0DC92C6DD0 for ; Wed, 22 Apr 2020 06:06:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 496VL01KMjz3FvQ for ; Wed, 22 Apr 2020 06:05:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: TAGhd0sVM1k1TgPaMEPdtoJdQ8_MWbTr0vLC2LqG5G5PaNqJJterxgEz5eXnxPW Zqg4iFTxc07KZ7bsjWGBt0SH79zhJpxgY0qs8pShKBaHrX0x0NmQ52gF2fzzGOfmI8C4fOO1kTcE DeS_8EltN3e941dGoPw7Q8n.CdagkvN6L5XAdBLtHh650pIxTrO0zPVOOTlwOEDbzF2EYejEhvo6 NqJHsmYXyLXqu1Yfmr_9MyTp4TLcz3XgxjtaUpjuLf_O383DGUY6g6AwXp6jVq06bqWdIuFHmjUA _AJYHj_kwNFmBQUhX4nHZK6x6qmOMDpztQCO4DZ3A1.lKoTEEXh.lRDhd7wfUd0CSyvyAuih23Yn 9cM0L7F7arXFjGFQxXfa.BvAouGXP1iw4EgkjoUVa4Ohp7U17DxwsLLF6hJwcP3wtFZbOm.24Pax nqvYXR9_IRYbBwGRnPM8BifDsTrcShHtSnijQbfUzQ2CD9fggLIVH0wfwLN0CVPzDszjcQf7nEv_ _7HGJbDQhKyHm4g.Za_kX4xhwLnha5zqzqZly7VFaTGskQPDKHKqNYvkOKNNegjZeqPkW26QvSlM ZOF9O4AU_G5F4Kg88NxxtPYLzs9TthzsczAagw7o2aBRBCNh9EC9Vr9dXj8rhhE11PrJwRwGF1h_ MEhmklc87cEIgP.S7ybb3tMDDhHRNF6tnEssYIEtpz94bno0IypvICK_D2LIWGCtSy1si_snThIS n0yme3OoxrXRn541laosDSgu9w0K_2G2It2Wso4Q.LnCu1pFWjCgU8E5KVE51dkM3DHoyT3uU1Nw oQIaZ5.VnARb4rLMitBqKc9TK.9erEHxiVVBBLd3LzTAsrNuDW3PiFEzzb_SJayJzhiBjqeOy2xj xD3toPKezliNApfwl3iKyGxz1I2v5EZ.LETnOke6_QNyCFliOSCYKPVyqvoe1xaLCZpv1c9p5l54 gzlWVmeSG8l5zRds6So_X6EIQu3hJ2C9BO6Wnuv_lpdCZ8V9HVGronyAKAJm0qxEzQ6Jy3WKdzJu Ytz5CSBFGLMuvoelfv4HushZaHw7Z2vlPADs3FEZv1ie2SIPIJElfX82oQLKbbdQ3gIen.62AB_e w8UW6kTg_Ndp8X1L.G8apB4EaieMGBLpfgU37GqBGvynw.IluuRnM_gxNkmdST1SokV8lryDaCF8 xdU1Kd4R_xZaaz4r2LQ3RR10nLspKaLWIOQCnw9qiIBPFjuoiXxsZAUw4QtygAzrsCjRjvF3FCGB tzM2aaiSEXaj7cLbcf2VImWCw8M8buezTBthDX4H9ek7546BWRSxeQ2TDXGA2Z1fnFdvbdRkmWjW PtBKepSPWqoLO_UNUXJr86t1Aca3J8pKAI_4SiTynvT8LS8pz16IxtgBj.iYKPpP0yz2Ii62HjBN TJ.lwA_SBHN8y1zmDWFsmt3Xlhq3rTIDLp1ZjQFq41cRfbPwl096Wajr_9A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Apr 2020 06:05:58 +0000 Received: by smtp415.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d93002460936ee26a904081f3c78f17c; Wed, 22 Apr 2020 06:05:53 +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.4 \(3608.80.23.2.2\)) Subject: "ARM64TODO: fill_fpregs32" showed up while building armv7 ports via poudriere on aarch64 (head -r359427) Message-Id: <113EADFC-53B1-4B88-B8D6-EEC9E5BF3FE2@yahoo.com> Date: Tue, 21 Apr 2020 23:05:52 -0700 To: freebsd-arm , FreeBSD Hackers X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <113EADFC-53B1-4B88-B8D6-EEC9E5BF3FE2.ref@yahoo.com> X-Rspamd-Queue-Id: 496VL01KMjz3FvQ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.34 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; 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.91)[-0.906,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.94)[-0.936,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.99), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[146.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: Wed, 22 Apr 2020 06:06:01 -0000 This is a aarch64 head -r359427 based FreeBSD context. While building armv7 ports via poudriere-devel on a OverDrive 1000 (cortex-A57 aarch64 head -r359427 FreeBSD context) I got: [00:24:07] [04] [00:00:00] Building x11/libICE | libICE-1.0.10,1 ARM64TODO: fill_fpregs32[00:24:28] [03] [00:00:22] Finished = devel/libltdl | libltdl-2.4.6: Success (poudiere was running on the console.) devel/gettext-tools and devel/swig30 were also building at the time. man arch reports: QUOTE aarch64 will support execution of armv6 or armv7 binaries if the = CPU implements AArch32 execution state, however armv5 binaries aren't supported. END QUOTE (It is referencing chroot style, not lib32, despite not being explicit about the distinctions.) Is the support of armv7 binaries not yet fully true? Does the "ARM64TODO: fill_fpregs32" notice imply that there might be problems with what was built? FYI: # poudriere jail -jFBSDFSSDjailArmV7 -i Jail name: FBSDFSSDjailArmV7 Jail version: 13.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud Jail fs: =20 Jail updated: 2020-04-21 22:05:27 # poudriere ports -l PORTSTREE METHOD TIMESTAMP PATH default null 2018-10-05 13:09:56 /usr/ports =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Apr 22 10:31:33 2020 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 424DB2AF42D; Wed, 22 Apr 2020 10:31:33 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sd-123398", Issuer "sd-123398" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 496cDN2lLJz43cT; Wed, 22 Apr 2020 10:31:31 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (localhost [127.0.0.1]) by kanar.ci0.org (8.15.2/8.15.2) with ESMTPS id 03MAUqHN034878 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2020 12:30:52 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.15.2/8.15.2/Submit) id 03MAUqiB034877; Wed, 22 Apr 2020 12:30:52 +0200 (CEST) (envelope-from mlfbsd) Date: Wed, 22 Apr 2020 12:30:52 +0200 From: Olivier Houchard To: Mark Millard Cc: freebsd-arm , FreeBSD Hackers Subject: Re: "ARM64TODO: fill_fpregs32" showed up while building armv7 ports via poudriere on aarch64 (head -r359427) Message-ID: <20200422103052.GA34731@ci0.org> References: <113EADFC-53B1-4B88-B8D6-EEC9E5BF3FE2.ref@yahoo.com> <113EADFC-53B1-4B88-B8D6-EEC9E5BF3FE2@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <113EADFC-53B1-4B88-B8D6-EEC9E5BF3FE2@yahoo.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Rspamd-Queue-Id: 496cDN2lLJz43cT X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mlfbsd@kanar.ci0.org has no SPF policy when checking 2001:bc8:35e6::1) smtp.mailfrom=mlfbsd@kanar.ci0.org X-Spamd-Result: default: False [2.80 / 15.00]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; IP_SCORE(0.02)[ipnet: 2001:bc8::/32(-0.35), asn: 12876(0.44), country: FR(0.00)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ci0.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.69)[0.692,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.90)[0.895,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[mlfbsd@ci0.org,mlfbsd@kanar.ci0.org]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:2001:bc8::/32, country:FR]; FROM_NEQ_ENVFROM(0.00)[mlfbsd@ci0.org,mlfbsd@kanar.ci0.org]; 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: Wed, 22 Apr 2020 10:31:33 -0000 Hi Mark, On Tue, Apr 21, 2020 at 11:05:52PM -0700, Mark Millard via freebsd-arm wrote: > This is a aarch64 head -r359427 based FreeBSD context. > > While building armv7 ports via poudriere-devel on a OverDrive 1000 > (cortex-A57 aarch64 head -r359427 FreeBSD context) I got: > > [00:24:07] [04] [00:00:00] Building x11/libICE | libICE-1.0.10,1 > ARM64TODO: fill_fpregs32[00:24:28] [03] [00:00:22] Finished devel/libltdl | libltdl-2.4.6: Success > > (poudiere was running on the console.) > > devel/gettext-tools and devel/swig30 were also building > at the time. > > man arch reports: > > QUOTE > aarch64 will support execution of armv6 or armv7 binaries if the CPU > implements AArch32 execution state, however armv5 binaries aren't > supported. > END QUOTE > > (It is referencing chroot style, not lib32, despite not being > explicit about the distinctions.) > > Is the support of armv7 binaries not yet fully true? > > Does the "ARM64TODO: fill_fpregs32" notice imply that > there might be problems with what was built? > This should mostly shows up when a process crashes, so I'd guess you have a core dump somewhere. We should probably just get ride of the printf(), fill_fpregs32() is mostly compatible with what the arm port does, where fill_fpregs() just zeroes the registers. AFAIK the support for armv7 binaries is pretty complete, that doesn't mean there's no bug, though. Regards, Olivier From owner-freebsd-arm@freebsd.org Wed Apr 22 19:06:15 2020 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 CB2172BE0F0 for ; Wed, 22 Apr 2020 19:06:15 +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 496qfG4QY1z4g4g for ; Wed, 22 Apr 2020 19:06:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: H5XvWhIVM1mI3IFfI2ttUQAzf2b47KmOOcCFhi987oC9YdcRHKSOpuSVvgMBMAP e2NMO9bkN6wF0S75StZO92laaXAul0beoTm6o1SJQ3zAiXqxfIgIyx9_BEXNhELNlaDOTjK8pd5o LyMBtekooU4WcAM9C.pYhBsct3U.W7u01TbyeKC3gndDsq8TLqpLU76QTh09Yzc_qzjEN_O2EUTJ 69QJ7T583v9Xu32rH1aloXN8Y5MIISni8cMkGOnKYFkGRecoipNAmN4YrbMAE8TVDFdZnwogiooE oIejJFy_aqTbp2U56Y5oljUSwQYeqb6s4udxdUh3SJRxQqIrhdflTgjGIpsqYA0ngy0QzHUjpQ9t bQo5VjU0TndqYx0UM8F_N9ak0Y0fqlABdioJU0F1uj65o_UaN1wywgcNvMykRuEHrrEtD85hDr9V 8hp.0VFJZNR3xjnvt8j8UE.KNwKT0UDqe2Fekn2CYx2VP6emIPdT8Y3JnJXBRDZoJaF0NHIbRouw 2oT43xjru.8wwhyNRX_GpqwrBwzW2H0_AbLmyVQIwQF83pBm7NIK9UQcrOcNY4Kkq9faGWoHwjke Rd1LqaYLqXzhM3ELV0fj98EJ.pv_jCBgwXoKciE7_3kWClk73RCJ0oqt17Xp7iTSiUFmK75LHgm6 bxwLS3hBHVRcoYNbnz5.exCsxT4yddMZ1G3qfJIXpH147zadYOHcYA6.coI6fBv9U2vdY6q.1K.G GG_gJxpuMT7ad5XhFViNXRSo1BQqYS34h3Rg3p6kVCsv1.eiois0bPbo1K1wsmWFkKRinvO9mXEB 8JhE7GPDImR4WFXAzOtx2nS_NqvKw5sDCok5noGPMm2fMauwjwPs0uqCln9dSHwUAeDI5zK028wD .sWrkvJaNuF5sK4NLBryaeaN6LjXJtLegH4wL8xUh0DmLe4uPxKINmvTJOOptr.HI_GFOI8fpY7i na6oJTK0BYobbxd4wigCQfeVZrRl_tv4Pn7.6cteHRg7._J8W_PNy6PHEnQNIDhbWXRDps_LTyKH VVK8evTB_PK1yiaQpxU5a8.uP8cdJHYau_eMRq2fu3PGNrNzgHqlTeVC1lNPNxw23EUwSVsIxJhT KgngBQLC8cQf874n9B0kNvF27zE1NfpgfAduZy3mutAJGW0ZKCk6DwvYv57Lctl2SRvbF.kZncO6 91sZqnZiafNv7.4cgXpf.xLZLsOIz7SsdIddKl3ZshZ9_AJ5sR.thrrKhAqRBHd2FGYbnf2e8OUq hrkBfA0xvnUyEcqA18sBkyDS9RB_gARO8htGQC2kMRnQ8A0Vh_CxSwgeB0LLsmRfqEW2VuktPkON WcGPsRrJSaSYL3ZyN35HWoD0g3oVxAfE5x3f4hK.wNlkT0Z3uegRsb0Bl2KZOpfAdeRm6VC930lQ uJlRHzZMEdAQGb9aPiy7e_fiZopStUuDooKZwlY.tYZI17rtrsPFpBapoFYCSDQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Apr 2020 19:06:12 +0000 Received: by smtp413.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1740edae8c634be167d9c340650191d1; Wed, 22 Apr 2020 19:06:10 +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.4 \(3608.80.23.2.2\)) Subject: WITHOUT_BINUTILS= based head -r356427 FreeBSD context: x11-toolkits/qt5-gui build fails in poudriere: unable to execute command: Executable "as" doesn't exist! Message-Id: Date: Wed, 22 Apr 2020 12:06:08 -0700 To: FreeBSD ports , FreeBSD Toolchain , freebsd-arm X-Mailer: Apple Mail (2.3608.80.23.2.2) References: X-Rspamd-Queue-Id: 496qfG4QY1z4g4g X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.26 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; SUBJECT_ENDS_EXCLAIM(0.00)[]; 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.82)[-0.824,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.93)[-0.935,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.29), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.68.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: Wed, 22 Apr 2020 19:06:15 -0000 [Ports was at -r528828 so this did not check -r531601 update to 5.14.2 of Qt5.] This is based on worlds built via WITHOUT_BINUTILS=3D . I was checking to see how things are for "[o]ne of the goals of this process [ExternalGCC] is to deprecate and remove the old GCC 4.2.1 and binutils 2.17.50 in the base system". On an aarch64 machine with head -r356427 that has a armv7 world directory tree for the same version that is set up for poudriere-devel use, I attempted to build ports but I ran into the following for the indirectly needed qt5-qui (I un-interlaced the output for easier reading): --- .obj/pixman-arm-neon-asm.o --- cc -c -O2 -pipe -mcpu=3Dcortex-a7 -g -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -std=3Dgnu11 -fvisibility=3Dhidden= -fno-exceptions -Wall -W -pthread -fPIC -DQT_ACCESSIBILITY - DQT_DBUS -DQT_FONTCONFIG -DQT_FREETYPE -DQT_GLIB -DQT_IMAGEFORMAT_PNG = -DQT_OPENGL -DQT_SHAPE -DQT_XCB -DQT_XKB -DQT_XKBCOMMON -DQT_XRENDER = -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWH ELPERS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB = -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS = -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT _DISABLE_DEPRECATED_BEFORE=3D0x050000 -DQT_NO_EXCEPTIONS = -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB = -fno-integrated-as -I. -I../../include -I../../include/QtGui = -I../../include/QtGui/5.13.2 -I../../include/QtGui/5.13.2/QtGui -I.tracegen -isystem = /usr/local/include/libdrm -isystem /usr/local/include/qt5/QtCore/5.13.2 = -isystem /usr/local/include/qt5/QtCore/5.13.2/QtCore -isystem /usr/loca l/include/qt5 -isystem /usr/local/include/qt5/QtCore -I.moc -isystem = /usr/local/include/libpng16 -isystem /usr/local/include = -I/usr/local/lib/qt5/mkspecs/freebsd-clang = ../3rdparty/pixman/pixman-arm-ne on-asm.S -o .obj/pixman-arm-neon-asm.o . . . --- .obj/pixman-arm-neon-asm.o --- cc: error: unable to execute command: Executable "as" doesn't exist! --- .obj/qdrawhelper_neon_asm.o --- cc -c -O2 -pipe -mcpu=3Dcortex-a7 -g -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -std=3Dgnu11 -fvisibility=3Dhidden= -fno-exceptions -Wall -W -pthread -fPIC -DQT_ACCESSIBILITY - DQT_DBUS -DQT_FONTCONFIG -DQT_FREETYPE -DQT_GLIB -DQT_IMAGEFORMAT_PNG = -DQT_OPENGL -DQT_SHAPE -DQT_XCB -DQT_XKB -DQT_XKBCOMMON -DQT_XRENDER = -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWH ELPERS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB = -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS = -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT _DISABLE_DEPRECATED_BEFORE=3D0x050000 -DQT_NO_EXCEPTIONS = -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB = -fno-integrated-as -I. -I../../include -I../../include/QtGui = -I../../include/QtGui/5.13.2 -I../../include/QtGui/5.13.2/QtGui -I.tracegen -isystem = /usr/local/include/libdrm -isystem /usr/local/include/qt5/QtCore/5.13.2 = -isystem /usr/local/include/qt5/QtCore/5.13.2/QtCore -isystem /usr/loca l/include/qt5 -isystem /usr/local/include/qt5/QtCore -I.moc -isystem = /usr/local/include/libpng16 -isystem /usr/local/include = -I/usr/local/lib/qt5/mkspecs/freebsd-clang = painting/qdrawhelper_neon_asm.S=20 -o .obj/qdrawhelper_neon_asm.o . . . --- .obj/qdrawhelper_neon_asm.o --- cc: error: unable to execute command: Executable "as" doesn't exist! This suggests that a dependency on a ports binutils is needed and use of it is needed to keep this building when binutils 2.17.50 is absent in head. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Apr 22 20:28:32 2020 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 A51002C019E for ; Wed, 22 Apr 2020 20:28:32 +0000 (UTC) (envelope-from georg.lindenberg@web.de) Received: from mout.web.de (mout.web.de [212.227.17.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.web.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496sTC2GDjz3H5q for ; Wed, 22 Apr 2020 20:28:30 +0000 (UTC) (envelope-from georg.lindenberg@web.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587587309; bh=QTRXQQVoBTOYvOYIZidBMXQMHu5K3XycQvPESnXTfoU=; h=X-UI-Sender-Class:From:To:Subject:Date:In-Reply-To:References; b=NYQjwcM5gz47eEt1VwvfxIYdoxACtlHp4GvpLAZ+XYj/ibSkmm0ImiZpH02sQNR72 KYu/JEEjJnfQZjhuPLgtcXx6vxYPp9JDreLrdbM7MGNFdvEmHI7T6Ns5bBU53iCPGP oGuBrRtqlsTXkgf0hZFd1bEVBLl8gs3vd4CqvHCM= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [31.209.170.56] ([31.209.170.56]) by web-mail.web.de (3c-app-webde-bap64.server.lan [172.19.172.160]) (via HTTP); Wed, 22 Apr 2020 22:28:29 +0200 MIME-Version: 1.0 Message-ID: From: "Georg Lindenberg" To: freebsd-arm@freebsd.org Subject: Booting from USB on RPI3 Content-Type: text/plain; charset=UTF-8 Date: Wed, 22 Apr 2020 22:28:29 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20200421181224.GC96994@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:5zdvaGlB+A+J3ukSNd0O2aBZiCdKWpRWYk5maLFgid8Et3Odj3DSOWcp12nemwENvki/o hn9+gkEKfgCVTy1NmfRCYr+FkjtCZLf2/8Pc7WCaTU9inU/d/TwAqwzu+IYXjREHyiYbi2jq3g1T w/9Duf0Bmkw4nD/z2Ddn9Hv/vvGl7JpL5eXzV8u95dFgMSEeQpFXaUaNiJMZMZ7f2kH0TevKB2ss 2cUY+xlWX4WUx6DDI2uGaF8p/+SMMOX7fVSUxawC0RWn5PkEDhnOTRAQKm7TXez2eYT8tkhWM2f+ uk= X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gFdSPt1gqKE=:H3GKRa0H6+G8jG2iKjcKL6 m4Rk/6r2oU2fK4/1WU2NxYPLHNyQPIWRe5x9l6E3gtcX4Flk2HZMtLY1Sns4zAe2HU8VfxGl2 f+ZZlQJQHe8FnLGvPQgDIa/GRAuDPZEIFUXxarxI3v7hndxtPSPat5WSS+vc/hXPNAOcWOEZE eWiIWJsVVWm/Go/a5RPAwfYWM0qJa8mDJwEbU62Dl9kqNaEj5TP+FTV4jcO4Wintws8A1Ujqp eh+eN0+KvqoH+zk2A22l4QnuTWijv830dD+IMoV1OgdcB/n7OW5uZ7SQz7tuzoA5x+AEyyIfU /5GKAl2Rr8ygvqBFqXMBxrswOfB70U/PovrIJ2VI0yfkJZj+XMaohDeIcg13svTB+j5kji8MJ 5SSE5LEiYCZTliXR0OgSN2Jw/vMnrVZX4bq/6a/FQWG/m1B19Qk/dXFo+zOW4NCGV1bPIYu8f AnY/x6FOFdTa3v1MwTkDYR+1F0D64xlruJiN4yAFWuka0MYlvUq9UjFQsdgxYJ9WNsGOwjtfz cORfUbYymBNqLLmVcr4QXZfT5oZDuAif+JPLXXJvrxbjAMzNWa6CMr07V9njDJduL+feSuUya 7Fm7rXEFKmtv+/x1GxaSLx4pkL4XDQjXJUA5F1d0Hea1Xia7QcuxrSPwqE90bCF5rmxB3IMhi CEpsOs/oytf38DIGft+hjnzddvZQO1KUE91cV0aJgVUKW+zlS7H2QIqYFqGJtiERPlXk= Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 496sTC2GDjz3H5q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=web.de header.s=dbaedf251592 header.b=NYQjwcM5; dmarc=none; spf=pass (mx1.freebsd.org: domain of georg.lindenberg@web.de designates 212.227.17.11 as permitted sender) smtp.mailfrom=georg.lindenberg@web.de X-Spamd-Result: default: False [-3.09 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[11.17.227.212.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; FREEMAIL_FROM(0.00)[web.de]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[web.de:+]; HAS_X_PRIO_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[11.17.227.212.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_ENVFROM(0.00)[web.de]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; R_DKIM_ALLOW(-0.20)[web.de:s=dbaedf251592]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[web.de]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[web.de.dwl.dnswl.org : 127.0.5.1]; IP_SCORE(0.00)[ipnet: 212.227.0.0/16(-1.21), asn: 8560(2.07), country: DE(-0.02)]; MID_RHS_NOT_FQDN(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: Wed, 22 Apr 2020 20:28:32 -0000 > Gesendet: Dienstag, 21. April 2020 um 20:12 Uhr > Von: "bob prohaska" > An: "Georg Lindenberg" > Cc: freebsd-arm@freebsd.org, "bob prohaska" > Betreff: Re: Booting from USB on RPI3 > > On Tue, Apr 21, 2020 at 07:18:17PM +0200, Georg Lindenberg wrote: > > Hey, > > These are the steps I took to boot my RPI3B from usb. > > > > 1. Put the .img file on both the usb device and the SD Card (e.g. with= dd). > > 2. Plug in everything. RPI starts uboot from the SD Card. > > 3. Type any key to enter the U-Boot prompt. Then type "run usb_boot". > > > > That's a command I didn't know about, despite considerable looking. > Is it described anywhere? > > It'll be my next experiment! > > > You can see all the uboot variables with "env print". Maybe it is poss= ible to add "boot_cmd=3Drun usb_boot" to one of the config files, but I wa= s too scared to try it. > > My Pi3's setup is experimental, so crashing/corrupting it isn't a proble= m. > > Thanks very much for writing! > > bob prohaska > > Uboot will run bootcmd, unless you hit a key. Then it will enter the shell= . You can track down bootcmd (env print bootcmd): bootcmd=3Ddistro_bootcmd distro_bootcmd=3Dfor target in ${boot_targets}; do run bootcmd_${target} boot_targets=3Dmmc0 mmc1 usb0 pxe dhcp So, in this loop, usb0 is in third place. :-/ mmc will boot first. U-Boot> env print bootcmd_usb0 bootcmd_usb0=3Ddevnum=3D0; run usb_boot Anyways, one way to tell uboot to boot the usb permanently would be sth li= ke this: setenv bootcmd=3Drun usb_boot saveenv However: U-Boot> saveenv Saving Environment to FAT... Failed (1) This makes me wonder whether CONF_ENV_FAT_DEVICE_AND_PART is set correctly= . It should be 0:1, or 0:auto, not 1:1. From owner-freebsd-arm@freebsd.org Thu Apr 23 16:21:55 2020 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 E26282BC06A for ; Thu, 23 Apr 2020 16:21:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 497MyB5Hgyz40dg for ; Thu, 23 Apr 2020 16:21:54 +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 03NGLViG003638 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 09:21:31 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03NGLPiF003637; Thu, 23 Apr 2020 09:21:25 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Apr 2020 09:21:24 -0700 From: bob prohaska To: Georg Lindenberg Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200423162124.GA3583@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 497MyB5Hgyz40dg 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 [2.04 / 15.00]; ARC_NA(0.00)[]; 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.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.06)[0.056,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.03)[0.027,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[web.de]; 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: Thu, 23 Apr 2020 16:21:55 -0000 On Wed, Apr 22, 2020 at 10:28:29PM +0200, Georg Lindenberg wrote: > > Uboot will run bootcmd, unless you hit a key. Then it will enter the shell. > > You can track down bootcmd (env print bootcmd): > > bootcmd=distro_bootcmd > distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target} > boot_targets=mmc0 mmc1 usb0 pxe dhcp > > So, in this loop, usb0 is in third place. :-/ mmc will boot first. > > U-Boot> env print bootcmd_usb0 > bootcmd_usb0=devnum=0; run usb_boot > For some reason I can't use run usb_boot, it's necessary to use U-Boot> usb reset resetting USB... Bus usb@7e980000: scanning bus usb@7e980000 for devices... 8 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found U-Boot> run bootcmd_usb0 Device 0: Vendor: Initio Rev: 1.06 Prod: MHT2040AH Type: Hard Disk Capacity: 38154.3 MB = 37.2 GB (78140160 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 6 disks BootOrder not defined ^^^^^^^^^^^^^^^^^^^^^ this is trouble if it includes microsd devices EFI boot manager: Cannot load any image ^^^^^^^^^^^^^^^^^^^^^ more bad news 687984 bytes read in 402 ms (1.6 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ^^^^^^^^^^^^^^^^ not sure about this Next comes a couple screens of linefeeds, then: Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk1p1: FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Apr 16 06:59:37 UTC 2020 root@releng1.nyi.freebsd.org) Command line arguments: loader.efi Image base: 0x39e91000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8217.4096) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) Setting currdev to disk1p1: Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39) Setting currdev to disk1p2: Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... /boot/kernel/kernel text=0x9b804c data=0x192958 data=0x0+0x3a21fe syms=[0x8+0x10f740+0x8+0x134f85] Loading configured modules... /boot/kernel/umodem.ko text=0x2100 text=0x1390 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e] can't find '/boot/entropy' Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. It's unclear where the kernel loaded from, but at this point a listing of /boot reports the files on the USB disk, not microSD. The image is from a 12.1 snapshot. /firstboot has been renamed no.firstboot, might that be significant? It looks as if loader is confused about what disk it's on: OK show rootdev variable 'rootdev' not found OK Running show reports, among many other things: currdev=disk1p2: kernel=kernel kernel_options= kernel_path=/boot/kernel kernelname=/boot/kernel/kernel kernels_autodetect=YES loaddev=disk1p2: ^ the colon looks a little odd The loaddev would make sense if mmcsd is device 0, I'm not sure that's true. What's the simplest way to inform loader on the usb device it's actually _on_ the usb device. I've tried setting rootdev=da0s2a, didn't work. Thanks for reading, and all your help! bob prohaska From owner-freebsd-arm@freebsd.org Thu Apr 23 19:15:08 2020 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 47B0F2C0CC9 for ; Thu, 23 Apr 2020 19:15:08 +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 497Rp16wx7z4DDr for ; Thu, 23 Apr 2020 19:15:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: te3EwFwVM1kUO5fOPJBA50vgMvnHSoHOOxt8FFrXaVUj3e_qUPBZ1JMuJY8nwAY sU2oeETMtGkrbE4Gp2HnCxwxI.Fr6ACEUAlkaCKcmq4tjI2zkUuf9AsSGGpsFGb6yG2Gkd1CEKpF WoUqRXEqLK7eC5zSaG_rTX5r7ZI5wg7stU0ZVFnRSYa_kVRYNwfhOhDsGU1gAK.dfc6xOEjg.3Ws 3_hevzHafrLj57uCvJy8fGGYr8_fR8KgnKWlr3xeosTEE7iLTdp.uWWdPL4zSY8oJsCAluf1A8qd 9EyPDg6z8JuJs9T8yoiDzpaO_CvNru7QzxxigqAR6anBQKF2h9gxCWMOOLE5Kz1ju0IxqBl4m094 MmvY6LK_OlM1FqARCbEy6TkWJAiCths0uARRiadTVZptbsFGOGrxdpWcW9.KPpdpZAdc6lSFvjkB iwo81vJ7Ohz65_WyRBRWw_UNbqJJhfof1jI6KCnlR3Kk8W87NLWggv6KpDMH0NG90hdic3vT.YdS ZSfziyM9XUH5_NG5c3W4vrinwu_albmaDVRvXV5KThgrfxuazI4uYcgk9CpthsrvXpQzQmroz9RC 1fWvObrOriQaUH9pTiy6Yj9WKUhUyNyv08.gsxXqiHJvSPwu1yHay2_Hh11ljpHx4YCtnCO4F4rA gnvQB4MTXig3.wTQPJqZX1ZgiVLAqotxan7mIDTqnDh4BsWrD1GHXV_iFnNOCh51mG3UcwMc8QSi Wzc6lOGO8Xwo3fS9dKCBKGq2xdXILJe00wb2KOBYtBF8SE4NhWV77TIvQXU8y5.RnSppIxQZ.q.9 HoPLUjhJvslMYR2MVM9OMsjkOgvIDBR7AY3mQ9QAe6e.fuJUZaS_uhY842D6Y18cujJprdvp.ZH4 pNiIRPr3h7C.njwULZ_9j.uFw2NXjUt3kicMYjy.au0M1XP_fnOzRw_BauFP2xKevyEAjrjsH5AP QoRgu6btIV7JM3LD5_Urb1nZaeQZvoC4Vc1p1y67QWQdA3WDOKo7rmv7xlTsgdGBi4ZCpjMbEKaK qri6RnVj8y9o_pV1w.m0t_ABBzfY1F.X1d1XatOD5HX.jVIUL4ATS6gqD.tU0yR0Ew7yVnLAqs4k JVtWjDtdaIg..u7NUJSm4UYygbq09AZ37vw__SYja4W6Lo6oLjE45riGlkl2V_yZ6p3sGgCt.Zkh LlyVAACJroDwFAr73ZGfSgBwo151VQp46R5bNzF04aZCtCsCNoq6PLcLePU0bHK1wm2jYKcSm35O pobBK_svPCshKaFhTqXMIwL9EE.jN8WKRrRaeEl1Sy0YejvrQ7jzpDk938sx84LwNKpJJP1fZmmp UZprTm2AG2pl.REHAp7_489AqXCjG765RjfFcU__hP9Vd7f5SHJ35NyVvqe5MNJA.0GERcayH5ig 2BnNtTt7ZzDuqsynnX2eSSpE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Apr 2020 19:15:04 +0000 Received: by smtp431.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 032f4c63dbb0dce5d98e4e8540eb629a; Thu, 23 Apr 2020 19:14:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <20200423162124.GA3583@www.zefox.net> Date: Thu, 23 Apr 2020 12:14:57 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9C2E0F98-AF80-4105-B109-B4767AE53FFF@yahoo.com> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497Rp16wx7z4DDr X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.23 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; 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.78)[-0.776,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.954,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.89), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.68.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: Thu, 23 Apr 2020 19:15:08 -0000 On 2020-Apr-23, at 09:21, bob prohaska wrote: > On Wed, Apr 22, 2020 at 10:28:29PM +0200, Georg Lindenberg wrote: >>=20 >> Uboot will run bootcmd, unless you hit a key. Then it will enter the = shell. >>=20 >> You can track down bootcmd (env print bootcmd): >>=20 >> bootcmd=3Ddistro_bootcmd >> distro_bootcmd=3Dfor target in ${boot_targets}; do run = bootcmd_${target} >> boot_targets=3Dmmc0 mmc1 usb0 pxe dhcp >>=20 >> So, in this loop, usb0 is in third place. :-/ mmc will boot first. >>=20 >> U-Boot> env print bootcmd_usb0 >> bootcmd_usb0=3Ddevnum=3D0; run usb_boot >>=20 >=20 > For some reason I can't use run usb_boot, it's necessary to use > U-Boot> usb reset > resetting USB... > Bus usb@7e980000: scanning bus usb@7e980000 for devices... 8 USB = Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > U-Boot> run bootcmd_usb0 >=20 > Device 0: Vendor: Initio Rev: 1.06 Prod: MHT2040AH =20 > Type: Hard Disk > Capacity: 38154.3 MB =3D 37.2 GB (78140160 x 512) > ... is now current device > Scanning usb 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disk mmc@7e300000.blk... > Scanning disk usb_mass_storage.lun0... I ignore the above and start below. > Found 6 disks > BootOrder not defined > ^^^^^^^^^^^^^^^^^^^^^ this is trouble if it includes microsd devices My context has the msdosfs/EFI materials and FreeBSD loader.conf and kernel materials on the microsd card and a gpt partitioned USB SSD with the ufs file sytem on USB (loader.conf directs it there). I'll note things that you marked and how they look in my microsd card based. For the above: Found 7 disks BootOrder not defined I expect that the RPi3 set things up so a microsd card "wins" when present, even without the u-boot BootOrder definition being present. > EFI boot manager: Cannot load any image > ^^^^^^^^^^^^^^^^^^^^^ more bad news EFI boot manager: Cannot load any image So the same as you get for your USB-only experiments. > 687984 bytes read in 402 ms (1.6 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > ^^^^^^^^^^^^^^^^ not sure about this libfdt fdt_check_header(): FDT_ERR_BADMAGIC So the same as you get for your USB-only experiments. > Next comes a couple screens of linefeeds, then: My binary capture of the serial stream shows escape sequences with [2J [2J and then lots of [?25h interlaced with what follows (for some distance). There are also sub-sequences of a repeating |/-\ sequence mixed in at various points. I'll omit such. > Consoles: EFI console =20 >=20 > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk1p1: =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B= =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B So that is from the microsd card in my context. > FreeBSD/arm64 EFI loader, Revision 1.1 > (Thu Apr 16 06:59:37 UTC 2020 root@releng1.nyi.freebsd.org) I do not get the above line's content. > Command line arguments: loader.efi > Image base: 0x39e91000 The detailed figures is different in my context. I'll not list it. > EFI version: 2.80 > EFI Firmware: Das U-Boot (rev 8217.4096) > Console: comconsole (0) > Load Path: /efi\boot\bootaa64.efi > Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) > Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) I'll not show the long lines for the microsd card here. > Setting currdev to disk1p1: S=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B = =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B (So the microsd card device.) > Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39) > Setting currdev to disk1p2: (Another long line then:) =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B= =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B2=1B:=1B There are no long lines or references to the USB SSD that is present in my context: no examples if disk1p*: matches. Probably because of the gpt partitioning on that drive (and lack of any msdos like file systems). > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > Loading /boot/loader.conf.local > Loading kernel... > /boot/kernel/kernel text=3D0x9b804c data=3D0x192958 data=3D0x0+0x3a21fe = syms=3D[0x8+0x10f740+0x8+0x134f85] The detailed figures are different in my context. I'll not list them. > Loading configured modules... > /boot/kernel/umodem.ko text=3D0x2100 text=3D0x1390 data=3D0x6e0+0x10 = syms=3D[0x8+0xf48+0x8+0xb6e] The detailed figures are different in my context. I'll not list them. > can't find '/boot/entropy' I have a /boot/entropy file setup that is working so I got: /=1Bb=1Bo=1Bo=1Bt=1B/=1Be=1Bn=1Bt=1Br=1Bo=1Bp=1By=1B = =1Bs=1Bi=1Bz=1Be=1B=3D=1B0=1Bx=1B1=1B0=1B0=1B0=1B > Hit [Enter] to boot immediately, or any other key for command prompt. >=20 >=20 > Type '?' for a list of commands, 'help' for more detailed help. >=20 >=20 > It's unclear where the kernel loaded from, Given the lack of references to any disk0p*: in your sequence, yours came from the USB drive. And if there is only one kernel instance there, it came from that copy. > but at this point a=20 > listing of /boot reports the files on the USB disk, not microSD. > The image is from a 12.1 snapshot. /firstboot has been renamed > no.firstboot, might that be significant?=20 >=20 > It looks as if loader is confused about what disk it's on: >=20 > OK show rootdev > variable 'rootdev' not found > OK=20 Type '?' for a list of commands, 'help' for more detailed help. OK show rootdev variable 'rootdev' not found OK=20 So this appears to be normal for microsd card use as well. > Running show reports, among many other things: > currdev=3Ddisk1p2: > kernel=3Dkernel > kernel_options=3D > kernel_path=3D/boot/kernel > kernelname=3D/boot/kernel/kernel > kernels_autodetect=3DYES > loaddev=3Ddisk1p2: > ^ the colon looks a little odd currdev=3Ddisk0p2: kernel=3Dkernel kernel_options=3D kernel_path=3D/boot/kernel kernelname=3D/boot/kernel/kernel kernels_autodetect=3DYES loaddev=3Ddisk0p2: So this appears to be normal for microsd card use and your is analogous for USB drive use (when there is only one USB drive present). > The loaddev would make sense if mmcsd is device 0, I'm not sure that's = true. "disk0" is apparently reserved for the microsd card slot media, even when there is no media there. "disk1" for the USB disk (when there is only one). "disk1", "disk2", . . . when there are multiple USB disks. The binding of each to which disk might not be stable or might track which USB connection point was used or some such. I've not tested. > What's the simplest way to inform loader on the usb device it's = actually > _on_ the usb device. I've tried setting rootdev=3Dda0s2a, didn't work. da0s2a is FreeBSD notation. This appears to be too early for that and is using a different "name space" that has "diskNpM:" notation. Your disk0p2: is what turns into da0s2 or da0s2a in FreeBSD. This is another stage where having multiple USB drives might not have a stable binding to daN naming. such is one of the reasons that using labeling for identification is recommended: Identification my referencing unique content set up for the purpose. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Apr 23 19:27:30 2020 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 2FE102C107C for ; Thu, 23 Apr 2020 19:27:30 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 497S4K2H67z4Dx0 for ; Thu, 23 Apr 2020 19:27:28 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-ot1-x342.google.com with SMTP id z25so8111575otq.13 for ; Thu, 23 Apr 2020 12:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7hXdBMEBE+fMLKu6LcB5dgVU4QlH5Ld/f6wUVOuI+4o=; b=jePrxn7iQjhjOVZRyM/30JsMWjwQK8sd3mB8+8hhh760jQe/kA1T5V00re8if4EIvA kz24Fe9t1rHgbxejJmJ78jNoL/XEZE51llLB4RShb/VpVgsHRMS/55tPfKXjuOjI/1pB qU8qCXsCfSbNtdGvwIADCIR/1jQdJRwW5Ib85Ns2NKOEq4CxWva35Iih008xCt3kfXkM EErkmj/9ox4FK16X3H5Fnonph7sxxU5Ewi23KOeixjNOeZaM9+4ML8XI2e8tWQINxNw7 ZweiABUXZInVuzbNlGpzmWO86DyiZ0q6qQRqwaMzPUCckbO/OYfIDEd/cFkVHpFrzji5 E7/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7hXdBMEBE+fMLKu6LcB5dgVU4QlH5Ld/f6wUVOuI+4o=; b=Z4LjFjU8JN6BAM5LIHhaLyxGoar1mjhdu7EO+B+a78sd607ELcX9Ns0t0yGC8YWHZ7 w/KhXOs+SGax/PIm1Yt5cXRkW6LUwlAU5G4/O5a/fAaf66oS+dTYHrohP9iE4Y7BRyl/ OH5QOAkNxJhKo8vds6YKumgJaNL0LauV6oN4xEA8NeuAvltVINHTlNSOQ4kJIW+2feha 6YjVEOerpuNms4jqMvWlKbNM0oxqliHcmzmfLmGNDf4owqb9LT1YAjxJOJIqyX2r4VTt QIeMzk6oBmcc/mEdo19++K4Jz+EPdOdm9UKmRKHEht9ZiU3EDIRbWOjspP/qbDs3l3Vn BixA== X-Gm-Message-State: AGi0PuarWqvA7RDwr4h1m/DlOrDrS2cBMxAUoqmKoqi/1uHleyeRADkg 7doL174udhzh5jFTuSATFdNgT1k62LloPgmxe6BzPA== X-Google-Smtp-Source: APiQypLwsHIo5LUSuIYfMwF3Z1VJQ8LzLiEZOTXDLMxRblD1MqcIPLqo86l6U7VQWf578sYoua4b0fkCuJcw9/GG27E= X-Received: by 2002:aca:5790:: with SMTP id l138mr4391777oib.154.1587670047831; Thu, 23 Apr 2020 12:27:27 -0700 (PDT) MIME-Version: 1.0 References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> In-Reply-To: <20200423162124.GA3583@www.zefox.net> From: Jonathan Chen Date: Fri, 24 Apr 2020 07:27:12 +1200 Message-ID: Subject: Re: Booting from USB on RPI3 To: bob prohaska Cc: Georg Lindenberg , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 497S4K2H67z4Dx0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=jePrxn7i; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::342 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; 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)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2.4.3.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.08)[ip: (0.41), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_CC(0.00)[web.de]; 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: Thu, 23 Apr 2020 19:27:30 -0000 On Fri, 24 Apr 2020 at 04:22, bob prohaska wrote: [...] > Consoles: EFI console > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk1p1: > FreeBSD/arm64 EFI loader, Revision 1.1 > (Thu Apr 16 06:59:37 UTC 2020 root@releng1.nyi.freebsd.org) > > Command line arguments: loader.efi > Image base: 0x39e91000 > EFI version: 2.80 > EFI Firmware: Das U-Boot (rev 8217.4096) > Console: comconsole (0) > Load Path: /efi\boot\bootaa64.efi > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) > Setting currdev to disk1p1: > Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39) > Setting currdev to disk1p2: > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > Loading /boot/loader.conf.local > Loading kernel... You've set rootdev=disk1p1: , but your kernel appears to be on disk1p2: You should double-check this and make sure you're booting off the correct partition. > /boot/kernel/kernel text=0x9b804c data=0x192958 data=0x0+0x3a21fe syms=[0x8+0x10f740+0x8+0x134f85] > Loading configured modules... > /boot/kernel/umodem.ko text=0x2100 text=0x1390 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e] > can't find '/boot/entropy' > It looks like your kernel has loaded, but it can't find the file-system. This is usually due to unusual content in /etc/fstab. You have to use symbolic names (eg: /dev/gpt/some-gpt-label) instead of /dev/da* names. Can you show the contents of "gpart show -l" of your USB disk, and /etc/fstab ? Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Thu Apr 23 19:32:46 2020 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 D2DE72C12BE for ; Thu, 23 Apr 2020 19:32:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 497SBP6Fncz4FKM for ; Thu, 23 Apr 2020 19:32:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Bs959Z8VM1mgVPTHQqx7MhuyjG8jRO3wlorhxWNPZfpfJN3XwUyowgVJTSfdu7u v4iAC5BXLE0M0RH0nNj38SmyjCa0NyTdU5r5MeV8258A1TdaTA5hB.CF4sr.rB9HfEDdU811L.Om gmdIL7PLQrg1.B9.58HNhdpXwt69YUZjrW5LNumB6Fd5uXd.xOm148MyQ_8TFhX._wNqXUs26K39 xhVFBcMB6MR.0N7.LWkWR6ADNi5FdaQFYzaJL2G1KKvIm.NUeOUHZnz4OSkdidoTU5Sm79yWQK5d wSdR7yJGLYskiqSUkMG2huGpBg.bLM4581iK8wQXoU.dldzJBfg.GhAj_hiWS6xYAEEURRQ48eNZ G3ia_hOheXxVpz5SMtpkBjW3ntPJLPsf_Ned9QWdC50ooRIKZQvWWPlHPA7._0HnIe2K3TSxGhn0 4W.1NvJHg.plhiImM5Ij4nIT4IuiaoqULYRSDT9R1Z41U9JZORYAwZjJAoCbTvrkG48RDvYtc8cY qu9vnBzfZ1r41f0eiWP1Af9js_Girf1.vG_acKBCqYwpd3qbnZeF_anjLX3LXYIOj6thVHnaXKb0 1o6eCVSXljK.OgILwIlmpTnU8i5Xv4pGb7I2orssCquzIIQzDNGm2Ha1l3pR1I6xBUNVX0mRZ_xi gEc7T3oejUSgtYDYepjJoc4J3LGlwovnod6biBg_qnTQT8zrTWFNT86Yx89j.qLZzAXCOatOnSUf AZIlln5tu9IFRUD9AYNdNloZUS3QCIp5UdH10w.Nzqvo.eQFWHE3_krWC89vA_OC5ju51wUZ1Xqt Jj4rwTXuU_rINSh6Qvut7fcRUQ5eV1WBrlXubj69WMhketVLRkjdGKx0MS4sKHyq.euibNnI2WqB 4GN81y4Gj0WCDiZuuWMzxbo1dX5moE7TTPjkNrMgICvFU01QARHJhFe6WeVlvzl.8qY2k5vwf7Q9 _mux.P4BtrlfQM71UvzvQDQonqe7BvGc2okLn2wNKBX91IFDVtUDUO0alwrNHCX5hPxJBeK9qd8k XfNSOwEcHnnHB.Zp3HMgLwlmvv2anbjWR3h8Cd93nYOuK2cjAT54_HjOc.nDmP4E8oDwQLiAlo5e TeEqdBvsFVVmgDS5yVpI32mm.3cIzV47NOVcd7dxhQEGQrpBrcKh7DRBJLaWWXGj_Wm1_n6hqXPV 2Ihl_Kr4p78UalbRcLQlGyZVEpuagGCYnQcuL8qr4niL5RyP7iwEqZvpAs_M6.V.gA5MatBvQza0 T2Pmj0CwgA_KTQ7bqcarcsQO3b0i2GQcokr7.zLC1QGrb_8scH6aSo6gcDdqnfrXcSXQzKYvwxmi SwfNiEUbmUAtbRaJMuzYSvGG03Ww7VAuhp1wWDvpkd1Wm.QEPpuCihvhP2if5E_KPATIHAaqaT85 bZcJRlsNd.ascdYBVNxmg1yOC Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Apr 2020 19:32:43 +0000 Received: by smtp401.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e9bc10b74b115041fed43096d118eec9; Thu, 23 Apr 2020 19:32:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <9C2E0F98-AF80-4105-B109-B4767AE53FFF@yahoo.com> Date: Thu, 23 Apr 2020 12:32:37 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <66AB22DA-9128-4A8B-8DAB-F846653A410E@yahoo.com> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <9C2E0F98-AF80-4105-B109-B4767AE53FFF@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497SBP6Fncz4FKM X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.44 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; 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.94)[-0.944,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.87), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[83.64.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[83.64.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: Thu, 23 Apr 2020 19:32:46 -0000 On 2020-Apr-23, at 12:14, Mark Millard wrote: > On 2020-Apr-23, at 09:21, bob prohaska wrote: >=20 >> On Wed, Apr 22, 2020 at 10:28:29PM +0200, Georg Lindenberg wrote: >>>=20 >>> Uboot will run bootcmd, unless you hit a key. Then it will enter the = shell. >>>=20 >>> You can track down bootcmd (env print bootcmd): >>>=20 >>> bootcmd=3Ddistro_bootcmd >>> distro_bootcmd=3Dfor target in ${boot_targets}; do run = bootcmd_${target} >>> boot_targets=3Dmmc0 mmc1 usb0 pxe dhcp >>>=20 >>> So, in this loop, usb0 is in third place. :-/ mmc will boot first. >>>=20 >>> U-Boot> env print bootcmd_usb0 >>> bootcmd_usb0=3Ddevnum=3D0; run usb_boot >>>=20 >>=20 >> For some reason I can't use run usb_boot, it's necessary to use >> U-Boot> usb reset >> resetting USB... >> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 8 USB = Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> U-Boot> run bootcmd_usb0 >>=20 >> Device 0: Vendor: Initio Rev: 1.06 Prod: MHT2040AH =20 >> Type: Hard Disk >> Capacity: 38154.3 MB =3D 37.2 GB (78140160 x 512) >> ... is now current device >> Scanning usb 0:1... >> Found EFI removable media binary efi/boot/bootaa64.efi >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> Scanning disk mmc@7e300000.blk... >> Scanning disk usb_mass_storage.lun0... >=20 > I ignore the above and start below. >=20 >> Found 6 disks >> BootOrder not defined >> ^^^^^^^^^^^^^^^^^^^^^ this is trouble if it includes microsd devices >=20 > My context has the msdosfs/EFI materials and FreeBSD loader.conf > and kernel materials on the microsd card and a gpt partitioned USB > SSD with the ufs file sytem on USB (loader.conf directs it there). > I'll note things that you marked and how they look in my microsd > card based. For the above: >=20 > Found 7 disks > BootOrder not defined >=20 > I expect that the RPi3 set things up so a microsd card > "wins" when present, even without the u-boot BootOrder > definition being present. >=20 >> EFI boot manager: Cannot load any image >> ^^^^^^^^^^^^^^^^^^^^^ more bad news >=20 > EFI boot manager: Cannot load any image >=20 > So the same as you get for your USB-only experiments. >=20 >> 687984 bytes read in 402 ms (1.6 MiB/s) >=20 >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> ^^^^^^^^^^^^^^^^ not sure about this >=20 > libfdt fdt_check_header(): FDT_ERR_BADMAGIC >=20 > So the same as you get for your USB-only experiments. >=20 >> Next comes a couple screens of linefeeds, then: >=20 > My binary capture of the serial stream shows > escape sequences with [2J [2J and then lots of > [?25h interlaced with what follows (for some > distance). There are also sub-sequences of a > repeating |/-\ sequence mixed in at various > points. I'll omit such. >=20 >> Consoles: EFI console =20 >>=20 >> Reading loader env vars from /efi/freebsd/loader.env >> Setting currdev to disk1p1: >=20 > =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo= =1B =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B >=20 > So that is from the microsd card in my context. >=20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >=20 >> (Thu Apr 16 06:59:37 UTC 2020 root@releng1.nyi.freebsd.org) >=20 > I do not get the above line's content. >=20 >> Command line arguments: loader.efi >=20 >> Image base: 0x39e91000 >=20 > The detailed figures is different in my context. > I'll not list it. >=20 >> EFI version: 2.80 >> EFI Firmware: Das U-Boot (rev 8217.4096) >> Console: comconsole (0) >> Load Path: /efi\boot\bootaa64.efi >=20 >> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) >> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) >=20 > I'll not show the long lines for the microsd card here. >=20 >> Setting currdev to disk1p1: >=20 > S=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B= =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B >=20 > (So the microsd card device.) >=20 >> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39) >> Setting currdev to disk1p2: >=20 > (Another long line then:) >=20 > =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo= =1B =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B2=1B:=1B >=20 > There are no long lines or references to the > USB SSD that is present in my context: no > examples if disk1p*: matches. Probably because > of the gpt partitioning on that drive (and > lack of any msdos like file systems). >=20 >> Loading /boot/defaults/loader.conf >> Loading /boot/device.hints >> Loading /boot/loader.conf >> Loading /boot/loader.conf.local >> Loading kernel... >=20 >> /boot/kernel/kernel text=3D0x9b804c data=3D0x192958 data=3D0x0+0x3a21fe= syms=3D[0x8+0x10f740+0x8+0x134f85] >=20 > The detailed figures are different in my context. > I'll not list them. >=20 >> Loading configured modules... >=20 >> /boot/kernel/umodem.ko text=3D0x2100 text=3D0x1390 data=3D0x6e0+0x10 = syms=3D[0x8+0xf48+0x8+0xb6e] >=20 > The detailed figures are different in my context. > I'll not list them. >=20 >> can't find '/boot/entropy' >=20 > I have a /boot/entropy file setup that is working > so I got: >=20 > /=1Bb=1Bo=1Bo=1Bt=1B/=1Be=1Bn=1Bt=1Br=1Bo=1Bp=1By=1B = =1Bs=1Bi=1Bz=1Be=1B=3D=1B0=1Bx=1B1=1B0=1B0=1B0=1B >=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >>=20 >>=20 >> Type '?' for a list of commands, 'help' for more detailed help. >>=20 >>=20 >> It's unclear where the kernel loaded from, >=20 > Given the lack of references to any disk0p*: in your > sequence, yours came from the USB drive. And if there > is only one kernel instance there, it came from that > copy. >=20 >> but at this point a=20 >> listing of /boot reports the files on the USB disk, not microSD. >> The image is from a 12.1 snapshot. /firstboot has been renamed >> no.firstboot, might that be significant?=20 >>=20 >> It looks as if loader is confused about what disk it's on: >>=20 >> OK show rootdev >> variable 'rootdev' not found >> OK=20 >=20 > Type '?' for a list of commands, 'help' for more detailed help. > OK show rootdev > variable 'rootdev' not found > OK=20 >=20 > So this appears to be normal for microsd card use > as well. >=20 >> Running show reports, among many other things: >> currdev=3Ddisk1p2: >> kernel=3Dkernel >> kernel_options=3D >> kernel_path=3D/boot/kernel >> kernelname=3D/boot/kernel/kernel >> kernels_autodetect=3DYES >> loaddev=3Ddisk1p2: >> ^ the colon looks a little odd >=20 > currdev=3Ddisk0p2: > kernel=3Dkernel > kernel_options=3D > kernel_path=3D/boot/kernel > kernelname=3D/boot/kernel/kernel > kernels_autodetect=3DYES > loaddev=3Ddisk0p2: >=20 > So this appears to be normal for microsd card use > and your is analogous for USB drive use (when there > is only one USB drive present). >=20 >> The loaddev would make sense if mmcsd is device 0, I'm not sure = that's true. >=20 > "disk0" is apparently reserved for the microsd card slot > media, even when there is no media there. >=20 > "disk1" for the USB disk (when there is only one). >=20 > "disk1", "disk2", . . . when there are multiple USB disks. > The binding of each to which disk might not be stable or > might track which USB connection point was used or some > such. I've not tested. >=20 >> What's the simplest way to inform loader on the usb device it's = actually >> _on_ the usb device. I've tried setting rootdev=3Dda0s2a, didn't = work. >=20 > da0s2a is FreeBSD notation. This appears to be too early > for that and is using a different "name space" that has > "diskNpM:" notation. Your disk0p2: is what turns into > da0s2 or da0s2a in FreeBSD. This is another stage where > having multiple USB drives might not have a stable > binding to daN naming. such is one of the reasons that > using labeling for identification is recommended: > Identification my referencing unique content set up > for the purpose. I should have also shown two more commands with output for my context: OK lsdev disk devices: disk0: 249737217 X 512 blocks (removable) disk0s1: DOS/Windows disk0s2: FreeBSD disk0s2a: FreeBSD UFS disk1: 468862129 X 512 blocks disk1p1: FreeBSD UFS disk1p2: FreeBSD swap disk1p4: FreeBSD swap So the above shows the loader's notation. But, if there are multiple drives with the same size and partition/slice types and sizes, figuring out what is which is which could be a problem. The lack of a disk1p3: is from historical gpt partition editing, including delation in the history for the USB SSD drive. OK efi-show global BS,RS OsIndicationsSupported =3D 0x0 global NV,BS,RS PlatformLang =3D en-US global BS,RS PlatformLangCodes =3D en-US global BS,RS RuntimeServicesSupported =3D=20 80 05=20 freebsd BS,RS LoaderDev =3D = /VenHw(LONG-ID-REMOVED)/SD(0)/SD(0)/HD(1,0x01,0,0x403b,0x1ffe0) freebsd BS,RS LoaderPath =3D /efi\boot\bootaa64.efi Note: "LONG-ID-REMOVED" is not the original output text. So the 2 "freebsd" lines show where bootaa64.efi (the loader) is from, but in an even earlier namespace for such identification. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Apr 23 20:22:16 2020 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 11A612C25C0 for ; Thu, 23 Apr 2020 20:22:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (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 497THV0gs4z4HvL for ; Thu, 23 Apr 2020 20:22:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: sKfVYX4VM1neIbRBF.fcwdTr4.kxZ2Umz_BuKc3rS25oK70wyVw_9fDQuTvlf0d uPDQ3.bXeWtAUQnSv0mhgjXiGurwoYprd3VD99cHQcVC2pybycCRgV1dWpDWZgGnKhaNG1MUY5BM HgYBPeIqR1ztv4u3US6p5unqvdPbSSdRYR7MFrpOhNXDddW7yts1.ERQoeC.tEWeSdwlx6IS65gg esiyj5FDwgL5MjxGECdVsGA7Hiq8ilQ7IWz1OwSPcUL5E8vBkmZETna1cdy9u14zHITl.wuC0_ql ebzeDQMdsXhSjAMfX8EoSNwQ9.j19gJZcEC2prAEqTCwH6QhKGPBoySvMWCF.baZ0YNnAN.MTWJG dTt4j8C1bJcnIUkLfy3DOgtOk6UicZXCfGiBsg75XHynDkDHeSdnX9YwcknFTyT56GEe8fgkGzS9 xnJW15kq8EQwB84ISOUj0XEeY7sp1bQqHNYu3dGb0y1DDW.IT3.tmsqRHhoiJ8BhLNh.KP482KfE 98Js53uyJmmVKl7lZQfhwTSJDxweYjNoYAz2gCkgDHv8nGIy6WqpwHx6cA8ZAotboKtJvw2mpT6p yoZv8Gj_5.oyfDkaQdT1gl0HgscyFZSERc1_0GFjzEAyuHhGd6scORJWNbgtaniMTCNX7jOB_kvv GFYd8deh9y_kIFfejxgvKIwwn7vijHe5RQV_FWa1JP6lVzplGG.TdJuW_vldyLj1jt0.iaBXoX71 Me1ogjzlzLh4.MGIcPC74yCjoAL6fbd3g5BJmZlGgi_3yxYkjzW88NXfnWy.9zan3xut007ADo0F 1eWHTT5Nj8_CbadOVpxpwrQrZl5QqLTwqmkYWdb.PsKWlvTvRRJ.s3PbS5TJfTDXv_TlvtijIpns SucYWo3BFsM9VuSkgw1uQmvq4bUUaDVgZbU.9acbUifKKezmKi9eZ_k3Yl69f9J1oOFX0R6sdX9m 2_m10Ir7Q4hyGJxst7AQMk5Qk76l04q6buUPhTxMrsWSG8tBHTeb8dCYYJU85BUALkIupT5SjiwG AIMRQQ_sweX0SJVg_LUEwIS4TPv1acmlKuzeEznlc_UjRwC.2_OG9nlFBlXbk6NygQ6voUPNFRTK 3F8I6DlcuulQPg6ADnsqsQVg8_3I2deicAJc_U4aLH4PS65PvpcZBZjaKo3bskOfIwTkTtfvY445 WQPIZUk2s4BV305rILSrnhL3BLQ.jFDnvstLjTLOsAlq8Ps.WCfgBhq98dkIfOlbYADyLqG7Zzaq loF4qeqm4lqTatbU9jxqHsn7AgPfcj0bCCdL2tPaZ_M9OKIKISekCgRo.lBS6Sj_m9PkZcPkumxx eU994Dma4km.FdzVT6gNcL7WCnm6bHqwRFtr_lpXzms0Lsz701AUwWaL0BwikWo2XeUYORUQt4Ti gMWxgMVKebzQaDAqu1dZ3j_kitfBOsqsD_Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Apr 2020 20:22:12 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 91bc8bef92218d7f5bb5af583671207c; Thu, 23 Apr 2020 20:22:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: Date: Thu, 23 Apr 2020 13:22:06 -0700 Cc: freebsd-arm , Georg Lindenberg Content-Transfer-Encoding: quoted-printable Message-Id: <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> To: Jonathan Chen , bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497THV0gs4z4HvL X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.35 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; 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.88)[-0.877,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.98)[-0.978,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.56), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.67), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[31.64.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[31.64.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: Thu, 23 Apr 2020 20:22:16 -0000 On 2020-Apr-23, at 12:27, Jonathan Chen wrote: >=20 > On Fri, 24 Apr 2020 at 04:22, bob prohaska wrote: > [...] >> Consoles: EFI console >> Reading loader env vars from /efi/freebsd/loader.env >> Setting currdev to disk1p1: >> FreeBSD/arm64 EFI loader, Revision 1.1 >> (Thu Apr 16 06:59:37 UTC 2020 root@releng1.nyi.freebsd.org) >>=20 >> Command line arguments: loader.efi >> Image base: 0x39e91000 >> EFI version: 2.80 >> EFI Firmware: Das U-Boot (rev 8217.4096) >> Console: comconsole (0) >> Load Path: /efi\boot\bootaa64.efi >> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) >> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) >> Setting currdev to disk1p1: >> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)= /UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/Us= bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39) >> Setting currdev to disk1p2: >> Loading /boot/defaults/loader.conf >> Loading /boot/device.hints >> Loading /boot/loader.conf >> Loading /boot/loader.conf.local >> Loading kernel... >=20 > You've set rootdev=3Ddisk1p1: , but your kernel appears to be on > disk1p2: You should double-check this and make sure you're booting off > the correct partition. >=20 >> /boot/kernel/kernel text=3D0x9b804c data=3D0x192958 data=3D0x0+0x3a21fe= syms=3D[0x8+0x10f740+0x8+0x134f85] >> Loading configured modules... >> /boot/kernel/umodem.ko text=3D0x2100 text=3D0x1390 data=3D0x6e0+0x10 = syms=3D[0x8+0xf48+0x8+0xb6e] >> can't find '/boot/entropy' >>=20 >=20 > It looks like your kernel has loaded, but it can't find the > file-system. This is usually due to unusual content in /etc/fstab. You > have to use symbolic names (eg: /dev/gpt/some-gpt-label) instead of > /dev/da* names. The RPi3 will not start to boot from a gpt partitioned media. So picking gpt labeling as the example is somewhat misleading for single-media booting. glabel based labeling would be more realistic for the context. > Can you show the contents of "gpart show -l" of your > USB disk, and /etc/fstab ? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Apr 23 20:33:13 2020 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 591D52C29C6 for ; Thu, 23 Apr 2020 20:33:13 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 497TX825QYz4JQG for ; Thu, 23 Apr 2020 20:33:11 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-ot1-x335.google.com with SMTP id i27so8497902ota.7 for ; Thu, 23 Apr 2020 13:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DLtZdeDIPKN+pL71go031LtjzpOIf8dpSTlYLlBj+gc=; b=cCHm0eyHq4f+3H6hXMz0TfpwK5ypFXTttgOMsmDQSez6YNrUpBn9h3HD6XaYsyR+Ft OED4YQ5byV0XomC9l0K08OATT5ByTtuqqLtu6+vKocW3BUlS6HIwRU7Rk6MbyCu99G20 6AgdWkKY+usY5t553wvucJ2UR02YbfyiQctKCiZpzFLxPLr04vbiVvhGzSmHyfZ1JJWJ u6sancieNx4siqhavHQGO7GU7RS53XFIqM8P7ASttuT9ccCODAAAm3pTwUj01ChsbjRx cLeQjV4LE/28eOE6lr7j7srGGC7c6iFOT+v2OvaADZuX9cGKW0nmNj2ra6nn6KW1yOUY zXGQ== 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=DLtZdeDIPKN+pL71go031LtjzpOIf8dpSTlYLlBj+gc=; b=kNI4kDGO6kUpHrbKvx+VqI5w28XiXKWxllzDD0F5S2tgQCwRcixfsy2jmon3V1wXOD ds2m0qlDtNq+7PiUH9YGxzDzyC7/mpmgvI82z+XFfhoWhJXNtY0b/x8/STKjMMXkzbKY qXbjTYvvgR8lWm8kuylwQFgYul0WzzWffg7NDIeRVq+Ed+UTpjxdFjKeIphLLXa+m7bt 7iIvdyhdD23aeoyfNP+p3roqeHcl2ma9yL1sKakCvVtD7bVcukY0MwYaeDt6Ynoe0dJh f0ysUDzmzUhVzrH4j7gIsKs6EpkTrsWntOgZ0JeK/tXbBQ4kTpqHpann4GCTQVhk7G0Q 8RNQ== X-Gm-Message-State: AGi0PubBFZvIRUkFonyswXKkvrDKKw6yVh6wPm2dHiGt43dgwuS2KKcC 3Xs8UFn1OdJub/v6Y0ZrfE4UxzDnRBDIeAdYZ2R9qA== X-Google-Smtp-Source: APiQypIOlwMjU1g8AEUBgu8UbI8LrXS7M2lPWtNAaQ9sQphkOQbZs6RT4lPKOMiXkZ2y9ywVySeMt8Eh4KhZtlhjGrc= X-Received: by 2002:a05:6830:1bc9:: with SMTP id v9mr4772897ota.169.1587673990535; Thu, 23 Apr 2020 13:33:10 -0700 (PDT) MIME-Version: 1.0 References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> In-Reply-To: <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> From: Jonathan Chen Date: Fri, 24 Apr 2020 08:32:54 +1200 Message-ID: Subject: Re: Booting from USB on RPI3 To: Mark Millard Cc: bob prohaska , freebsd-arm , Georg Lindenberg Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 497TX825QYz4JQG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=cCHm0eyH; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::335 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-3.95 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; 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)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[5.3.3.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]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.65)[ip: (-7.46), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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: Thu, 23 Apr 2020 20:33:13 -0000 On Fri, 24 Apr 2020 at 08:22, Mark Millard wrote: [...] > The RPi3 will not start to boot from a gpt partitioned > media. So picking gpt labeling as the example is somewhat > misleading for single-media booting. glabel based > labeling would be more realistic for the context. The OP is attempting to boot off an external USB drive via loader.env. So it's the external drive's partitioning system that is of interest. FYI, my RPI3 boots off a GPT partition fine: 1.topaz:~,8:30am# uname -a FreeBSD topaz.inside.chen.org.nz 12.1-STABLE FreeBSD 12.1-STABLE #0 r358927: Sun Mar 15 22:24:30 NZDT 2020 jonc@onyx.inside.chen.org.nz:/xbuilds/rpi3/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 1.topaz:~,8:30am# gpart show -l da0 => 40 976773088 da0 GPT (466G) 40 8152 - free - (4.0M) 8192 964689920 1 topaz-root (460G) 964698112 12075016 2 topaz-swap (5.8G) 1.topaz:~,8:30am# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/gpt/topaz-root / ufs rw 1 1 /dev/gpt/topaz-swap none swap sw 0 0 Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Thu Apr 23 21:21:06 2020 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 D09692C3D0B for ; Thu, 23 Apr 2020 21:21:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 497VbN5YsVz4LnS for ; Thu, 23 Apr 2020 21:21:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1JTq5_8VM1kxF.NpKlBneAd79tFgvXl.NgR9DxBXBqDo9_A5GQby7AObvL0qFJ3 fQ9iGU4KolrAKKIfjL87CLboJt.rowzc3.OSvdvEfWQmuYbvzjeP73QuiydGZnu0sAHuuQQpQs4n i0VYKZoxGW.gpWPrdzkYAEFSZ.kgUE86lvHxDYZ.WsPf36dzg1WcPzlcDWv5f_.9uOXr_LYhL0je VnEX5me.8qbdEa53N1fhg6ZF4jX_XhP93If.8WJWzYTMUAE58T9TaTrWihrbX6_a2DFNydtusp9z g8.3NMGf3CkyikIi50izMGWXDodDAmJt74bWI_S1t_NKiHf.SV.4xQiNniR3M.vvt1UV0aXGyVYL WUOiprlCwJMqmgin3nnCAaY2ST2WSH.xFtk6P4olZuvpmdZJs2r4zQD5qSMJiCghIRVjQWY0Nhuw 7gJ1hVBXYuQ9p1wkrWtTvg8.7NIDjgqLOdCpCRqC1MsKFUGdNCGapyWXjU9YIemfCOkgdouAhebK kOzWXBvmtjs676cze.4HqStgS1Y5GvYZhjd1eNFRpfYlqXJCVoFCgEecuLfLQe6pMecneXkIFl.m oH0.TRXvjhr7Y3jmc.33l.szSH0cDiumClR.gB.CEgM4Zj8juDVVH5MT7Bn7pq.3Vc0oHpVpEEMo ILUpHT5DUBFDKznUsyP91UPldekvQTkJ5GY4dU7E6Flcu1aPn8EuKlLHAoHOpyVLbGRiyNT_GZQq s1jfaMGdx7x9DbbKm_g8D_6T4ZYKeXHmQ6dDrDI78r1MgnYU9HOwwJPtnDRzFM7.qvryn_eXNgg2 9ha16D8Q8.jxh06Azv5f_Oseg13gjNUJTu5Wa14KTAgJOzy5aT4FdHUTwt1VM9YqajbrJHMcVwxH rwKFFiWeZuICi3FmJ8R.Ym3IL9Uz7xnGNJcu0G4lHD2Lrjs1lsIUF.uFI6_WnjGEQD5QfVISpFgo KVXlcSytBIXv3wRonMhCU2tJ1H3Mq8jGednIaRfi.rAeCL0s9fHcpS7ja8lWCCl0T6VHRi3kblml 09KT6XtmBP1IOKnzOLJXEy8cuGLkhDP60Iv0rkWWM9qtKzMTPJdWRIkEnBYt4X6lmf90raJt6.zT cCGaJDGd6q7MuZQWhvhjgvvDLHxTVZFpDKhmDmk9w8UYfC2lI.AF6iEgKtkLheUk8aCvTwwvDwPd PfBZHHgEAbLBjweKykRz.Vz8ZyCSBi.QroReVPX.cB7HygE2mtI.FLH4Y1U.kdsOjGiVIgqAsAS9 0r6FbIh3zQkEdsQMI5KSuA8m4gWIDvByDfEp3rghm91fMIriDwsKgC33A5Z_SHBU7cvGi24YU2dk rmDs6RMKqTqjWgbSQTVGKcYwA4nal5XtZ7O5SjLUn8.SkT8sT7mYPZZEug8ehlu9Dvv0qFtSZGYc WEfKePC9LTXKXlfEs3MYWadNhwvg5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Apr 2020 21:21:02 +0000 Received: by smtp413.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1c76b8df0beb6eb015039c4fe0e79371; Thu, 23 Apr 2020 21:20:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: Date: Thu, 23 Apr 2020 14:20:57 -0700 Cc: freebsd-arm , Georg Lindenberg Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> To: Jonathan Chen , bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497VbN5YsVz4LnS X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.45 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; 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.96)[-0.957,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (2.08), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[205.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[205.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: Thu, 23 Apr 2020 21:21:06 -0000 On 2020-Apr-23, at 13:32, Jonathan Chen wrote: > On Fri, 24 Apr 2020 at 08:22, Mark Millard wrote: > [...] >> The RPi3 will not start to boot from a gpt partitioned >> media. So picking gpt labeling as the example is somewhat >> misleading for single-media booting. glabel based >> labeling would be more realistic for the context. Note the "single-media booting" reference above. > The OP is attempting to boot off an external USB drive via loader.env. > So it's the external drive's partitioning system that is of interest. > FYI, my RPI3 boots off a GPT partition fine: >=20 > 1.topaz:~,8:30am# uname -a > FreeBSD topaz.inside.chen.org.nz 12.1-STABLE FreeBSD 12.1-STABLE #0 > r358927: Sun Mar 15 22:24:30 NZDT 2020 > = jonc@onyx.inside.chen.org.nz:/xbuilds/rpi3/obj/usr/src/arm64.aarch64/sys/G= ENERIC > arm64 > 1.topaz:~,8:30am# gpart show -l da0 > =3D> 40 976773088 da0 GPT (466G) > 40 8152 - free - (4.0M) > 8192 964689920 1 topaz-root (460G) > 964698112 12075016 2 topaz-swap (5.8G) >=20 > 1.topaz:~,8:30am# cat /etc/fstab > # Device Mountpoint FStype Options Dump = Pass# > /dev/gpt/topaz-root / ufs rw 1 = 1 > /dev/gpt/topaz-swap none swap sw 0 = 0 >=20 That does not appear to have the msdosfs/EFI material on the USB drive. So I'd guess that you are using the microsd card for that: 2 media overall, not single-media. I also use a form of two-media instead of single-media and use gpt on the USB media: # gpart show =3D> 63 249737153 mmcsd0 MBR (119G) 63 16380 - free - (8.0M) 16443 131040 1 fat32lba [active] (64M) 147483 997 - free - (499K) 148480 241172480 2 freebsd (115G) 241320960 8416256 - free - (4.0G) =3D> 0 241172480 mmcsd0s2 BSD (115G) 0 230686720 1 freebsd-ufs (110G) 230686720 10485760 - free - (5.0G) =3D> 40 468862048 da0 GPT (224G) 40 2008 - free - (1.0M) 2048 413138944 1 freebsd-ufs (197G) 413140992 6291456 2 freebsd-swap (3.0G) 419432448 6291456 4 freebsd-swap (3.0G) 425723904 43138184 - free - (21G) # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/PINE642Groot 195378 34775 144973 19% / devfs 0 0 0 100% /dev /dev/label/PINE64P2Groot 109101 219 100153 0% /microsd_ufs /dev/label/PINE642GAboot 63 43 20 69% /boot/efi I choose to have a copy of /boot on /microsd_ufs and to use vfs.root.mountfrom=3D"ufs:/dev/gpt/PINE642Groot" in the loader.conf file in my context. But such is not what Bob P. is trying to do from what I can tell. He looks to be trying to avoid microsd card media use if he can. He needs MBR on the USB media for that (or some hybrid MBR that proves compatibile). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Apr 23 21:26:18 2020 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 E57FF2C3FC9 for ; Thu, 23 Apr 2020 21:26:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 497VjP1b18z4Lyl for ; Thu, 23 Apr 2020 21:26:16 +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 03NLQFTq004166 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 14:26:15 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03NLQEtU004165; Thu, 23 Apr 2020 14:26:14 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Apr 2020 14:26:14 -0700 From: bob prohaska To: Jonathan Chen Cc: Mark Millard , freebsd-arm , Georg Lindenberg , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200423212614.GA3996@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 497VjP1b18z4Lyl 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 [1.65 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.26)[-0.255,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-0.05)[-0.049,0]; 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:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; FREEMAIL_CC(0.00)[yahoo.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: Thu, 23 Apr 2020 21:26:19 -0000 On Fri, Apr 24, 2020 at 08:32:54AM +1200, Jonathan Chen wrote: > On Fri, 24 Apr 2020 at 08:22, Mark Millard wrote: > [...] > > The RPi3 will not start to boot from a gpt partitioned > > media. So picking gpt labeling as the example is somewhat > > misleading for single-media booting. glabel based > > labeling would be more realistic for the context. > > The OP is attempting to boot off an external USB drive via loader.env. > So it's the external drive's partitioning system that is of interest. The USB drive on my system was written with dd using FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200409-r359731.img It's been resized to fill the hard disk and given a swap partition. Gpart reports bob@www:~ % gpart show da0 => 63 78140097 da0 MBR (37G) 63 2016 - free - (1.0M) 2079 102312 1 fat32lba [active] (50M) 104391 78035769 2 freebsd (37G) gpart show da0s2 => 0 78035769 da0s2 BSD (37G) 0 57 - free - (29K) 57 71303168 1 freebsd-ufs (34G) 71303225 6732544 2 freebsd-swap (3.2G) To my surprise, gpart show da0s1 reports gpart: No such geom: da0s1. even though there is a /dev/da0s1. I thought it would at least report the size. No attempt has been made to alter the msdos partition, That does mean the u-boot on the USB drive isn't quite the same as the u-boot on the microSD, which uses https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin and modified to turn on its serial console. Could that matter? Since it appears the USB installation is getting all the way to the loader prompt on USB I'm tempted to think the trouble's on the FreeBSD side of the USB setup. Thanks to all for reading, and any suggestions. bob prohaska From owner-freebsd-arm@freebsd.org Thu Apr 23 21:31:28 2020 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 9B2FD2C42EB for ; Thu, 23 Apr 2020 21:31:28 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0: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 497VqM3NpHz4MDw for ; Thu, 23 Apr 2020 21:31:26 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-ot1-x343.google.com with SMTP id z17so8832093oto.4 for ; Thu, 23 Apr 2020 14:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oC+MEOR23/u0MjZ+LQfi5PJ0UQfFv8y+bSMfP5vvO5k=; b=jvSjVKwwf9Cezo/sYHa82MvGGjPMLYYElAz3jHXQsJ/O9TnMYxG0wIAffCIRt46DX7 WcUiP/maErei/x4smII/rET2UmW2KVj6n2hr8RFOCvuhBDFjwAiDs1w2xMzahKe1w/RY F6q83wnYeMw4HIIz7mhXPiI8r09aSJhZ3jZEx4cHFqS5NQ2d9SrN8eNsYSilEa4ycK08 LzuXrSCiJcQmE7IpoXtWkCepDyjASHjJ2dB14hV7Do1rCTsOmcuSpjhfL+pH24ZfCCT7 WnH+avYlfZucXS/TjI81rUI3hhWn8WaWh9iq8rX3kWHtLaqPAn7HSgM9eTg0s0am1nd+ 4/5A== 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=oC+MEOR23/u0MjZ+LQfi5PJ0UQfFv8y+bSMfP5vvO5k=; b=a6VrHnYj/BB2uo2bsnMzaeQeqaHQekSdoVv+tFC+BstSUzk2VPYCAiXnHhT7qovtg1 0JcHwuj24soTY9oVu8/AnHeBAjdfR0raieV3qoRiH2MZuWGLzYHDgZxyVRNU4kXPCvQk 2UCl2GU6VnhWPhJwC8OrHINRusoONcUtlQRMFM2vg8+FXTyaJTab0orlb7cllz35aTUS vDvFXmUZ5s1YvK5+KCIkVJXSLOxVpv2ur3VUyz8oSeUUKOZyIF7atxpN3y7zCpbE/eo3 6UBZgCDApRp8TfhU4C5+0Zm1aqe0A/pKa2AeSRrv1p/aXbxkwU7avjC7jYGP9JUbrNcY SHTw== X-Gm-Message-State: AGi0PuanIV6ZoJzBB0Z50BsObU9Cc6uTcpo3ZtT4YmLPwFXLhQIz+34D TAvGgYZhwAn/qSBC9Rri/17LMbF8PwiW1t0eeF/JYQ== X-Google-Smtp-Source: APiQypJk7slRzBB7/cZWSHBJC0jNuTCrIeHKdQLEW1owGeynVnuGZRIki16dHXAf7yU3JU3UCE9e8Zaut5e+BwS6PFM= X-Received: by 2002:aca:ba05:: with SMTP id k5mr4540949oif.35.1587677485704; Thu, 23 Apr 2020 14:31:25 -0700 (PDT) MIME-Version: 1.0 References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> In-Reply-To: <20200423212614.GA3996@www.zefox.net> From: Jonathan Chen Date: Fri, 24 Apr 2020 09:31:09 +1200 Message-ID: Subject: Re: Booting from USB on RPI3 To: bob prohaska Cc: Mark Millard , freebsd-arm , Georg Lindenberg Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 497VqM3NpHz4MDw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=jvSjVKww; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::343 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; 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)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; 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.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.08)[ip: (0.40), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_CC(0.00)[yahoo.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: Thu, 23 Apr 2020 21:31:28 -0000 On Fri, 24 Apr 2020 at 09:26, bob prohaska wrote: > > On Fri, Apr 24, 2020 at 08:32:54AM +1200, Jonathan Chen wrote: > > On Fri, 24 Apr 2020 at 08:22, Mark Millard wrote: > > [...] > > > The RPi3 will not start to boot from a gpt partitioned > > > media. So picking gpt labeling as the example is somewhat > > > misleading for single-media booting. glabel based > > > labeling would be more realistic for the context. > > > > The OP is attempting to boot off an external USB drive via loader.env. > > So it's the external drive's partitioning system that is of interest. > > The USB drive on my system was written with dd using > FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200409-r359731.img > It's been resized to fill the hard disk and given a swap partition. > Gpart reports > bob@www:~ % gpart show da0 > => 63 78140097 da0 MBR (37G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba [active] (50M) > 104391 78035769 2 freebsd (37G) > This is consistent with what your boot messages are showing. Your loader.env should have rootdev=disk1p2: Your current boot failure is due to the contents of /etc/fstab. What do you have in there? Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Thu Apr 23 21:37:51 2020 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 BA1B72C43C5 for ; Thu, 23 Apr 2020 21:37:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 497Vyk5VpQz4MVk for ; Thu, 23 Apr 2020 21:37: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 03NLbptP004193 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 14:37:51 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03NLboow004192; Thu, 23 Apr 2020 14:37:50 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Apr 2020 14:37:50 -0700 From: bob prohaska To: Mark Millard Cc: Jonathan Chen , freebsd-arm , Georg Lindenberg , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200423213750.GB3996@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 497Vyk5VpQz4MVk 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 [1.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.107,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; IP_SCORE(0.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-0.15)[-0.150,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(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: Thu, 23 Apr 2020 21:37:51 -0000 On Thu, Apr 23, 2020 at 02:20:57PM -0700, Mark Millard wrote: > > > > But such is not what Bob P. is trying to do from what > I can tell. He looks to be trying to avoid microsd > card media use if he can. He needs MBR on the USB > media for that (or some hybrid MBR that proves > compatibile). > > I've abandoned the goal of doing without a microSD card, simply becasue I think my Pi3B is too old to support it. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Apr 23 22:25:04 2020 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 7D8FA2C535D for ; Thu, 23 Apr 2020 22:25: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 497X1C6ml1z4PpN for ; Thu, 23 Apr 2020 22:25:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8uxF0h0VM1nOa28yVMhW_JAzJzba1oKR9pK32291ex64mXELyidMtMA5C09uCYu ch_Gg_.MXFgpYm2igb_Ix9DvctN.0xea7K3Wh4mprmTKcIBeAdNWWZDXaaxrArXS.Gr0r0vLxP6n NpwJNyjw1dWcwYmja8C_e6t0OA05IreLrIuHn7gObdIoAR9sV21TdsD2_uuLSkOi6YF3ge1xmbfG Z4b9NUIBvGtxysoClUGcB5ONxQogphBJxStpD6KcIeu2wG0MdbcMomN2yz27.2nQ2sg8U7UtcQar Fl5Cl5nQr_2U0m9uIqN709wAGpyex5rsgx0_q.zeQytp_jwWCGjh70YSa4Ca3E2daZPQxB17rEVg SyRnjmbHkau9OQvAVKRCIkACFNsld9vcM9qBxk1q_350Rh69pIG5NyDr9SqiW3gXFIomNVM8hloF cvnJC5YyU2Bb8Ib4U9bBR.EsphV3TKWXK79HWXT4o_q6SyWZ3Ennb87jcO0L_dbfEVLrYYh1j_lk 3kc5_.WbWie8ZJPxcRvyb2AX7kZjHcIGzFtz9dwqcyK0nGdAj7ZZafBrb1YnzLubvtk6NfmeCxYO u9L8hizx35FAeKUpXe7_WZaUWXW7O_L5.9Tnp236NugOCIpnWbTplJJaDX6VMHcuUqDyEaVjJ0VG Lh.5uMeJhzfwtEM9VF2lvNe5BnsZTBzRwxLTLFOMqsH7VjL3bqx6scNZ6.vnoW9VW6EDr.Hn4rQL gKolSOq9o2HTTqrm05PzrhKg8JqxH5Teznprbgp_cNbKSr9e.BB0ntfhGEW0cF18P6F0aJPN0PXt Pcf5r7H8c_Tv.7SG7RpjogtqqLhfd.ofFLm8KkFG3d4ALKo25D93QQxb3NQwiLlTJoSKm6tau31E C57DB6nVu0xSF.SarWkJKEVtePTbS_Au.aeqRDS_wlYhGnFd7okwToSgqXrVN15Bboc1lg0hkVbg thIs_RslwsIroK2Ui3kJv15C1Lz3tGtjXkJ.5U1.S0KfyW6olM80nkgkwauDh1UcQH6bKS1ZXaZJ SLgG8eMQVrSDtKRQUhjYHOGIIxhrCl61qwbRgR8.4jJ76Zah4W6I_iOo50Vi7ERnKVLT3WODfpL0 xOpWB9iTCaw7qYIqbyoVgL1mEaiu6Bj_ico3ucm3kjKUDo_IEBTXop7GFcBDX.zrZ5kfgjJh.IEn ntiws0fOkNyWEyM2koTPPKKz.35U2Zq03TDq6tKPUa77XRclBGa7SmZkUNdrt5x4AJLPI0acyIhw tV72RZc7UDtozkxz7nWtItJ13DMpgpczNQIXqH.eplp73cDYU5AcJxQUTrb0bG80G9kEUH7lbTz1 bnyd.duF0g5_Y1AhICk2Dsz8z2qnz8e0eor1C1LSW5nOLgDd6U_2gIXckeShIqFP3pDhypE50ETD JcMj.Bb7l4pjUl44w35uI8A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Apr 2020 22:25:03 +0000 Received: by smtp432.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a0072a81a18d939e2193a119b4c2f3a8; Thu, 23 Apr 2020 22:24:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <20200423212614.GA3996@www.zefox.net> Date: Thu, 23 Apr 2020 15:24:57 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497X1C6ml1z4PpN X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.30 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; 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.83)[-0.825,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.971,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.61), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.68.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: Thu, 23 Apr 2020 22:25:04 -0000 On 2020-Apr-23, at 14:26, bob prohaska wrote: > On Fri, Apr 24, 2020 at 08:32:54AM +1200, Jonathan Chen wrote: >> On Fri, 24 Apr 2020 at 08:22, Mark Millard wrote: >> [...] >>> The RPi3 will not start to boot from a gpt partitioned >>> media. So picking gpt labeling as the example is somewhat >>> misleading for single-media booting. glabel based >>> labeling would be more realistic for the context. >> >> The OP is attempting to boot off an external USB drive via loader.env. >> So it's the external drive's partitioning system that is of interest. > > The USB drive on my system was written with dd using > FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200409-r359731.img > It's been resized to fill the hard disk and given a swap partition. > Gpart reports > bob@www:~ % gpart show da0 > => 63 78140097 da0 MBR (37G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba [active] (50M) > 104391 78035769 2 freebsd (37G) > > gpart show da0s2 > => 0 78035769 da0s2 BSD (37G) > 0 57 - free - (29K) > 57 71303168 1 freebsd-ufs (34G) > 71303225 6732544 2 freebsd-swap (3.2G) > > To my surprise, > gpart show da0s1 reports > gpart: No such geom: da0s1. > even though there is a /dev/da0s1. I thought it would at least report > the size. da0s1 is analogous ot da0s2a, not da0s2: # gpart show da0s2a gpart: No such geom: da0s2a. It is the "BSD" that makes da0s2 special, much like "MBR" being special for da0. Both MBR and BSD contain other slices. fat32lba and freebsd-ufs and freebsd-swap do not. That makes the "geom" distinction involved. > No attempt has been made to alter the msdos partition, > That does mean the u-boot on the USB drive isn't quite > the same as the u-boot on the microSD, which uses > https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin > and modified to turn on its serial console. Could that matter? Since > it appears the USB installation is getting all the way to the loader > prompt on USB I'm tempted to think the trouble's on the FreeBSD side > of the USB setup. > Note: bootcode.bin may have fixes of RPi* problems for the boot code that is burned into the part involved. For USB-only or for microsd card also in use, have you tried the equivalent of: OK lsdev and then used the naming convention shown in the output for any loader commands/settings instead of using FreeBSD-stage da0 based naming? (You might want to report what lsdev shows.) Note: the disk0 and disk1 like prefixes are copied from the u-boot notations that the loader gets from u-boot, if I understand right. Does your loader.conf do anything to control what is booted? As Joanathan asked: what does your /etc/fstab have listed? (/etc/fstab should have FreeBSD notations, not loader device names.) Are there any other boot-contributing files that would be appropriate to show together in one message for review, including any on the msdos file system? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Apr 23 22:41:10 2020 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 D65C52C5A3C for ; Thu, 23 Apr 2020 22:41:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 497XMn5nqgz4QNV for ; Thu, 23 Apr 2020 22:41:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 03NMf9hm004295 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 15:41:09 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03NMf99S004294; Thu, 23 Apr 2020 15:41:09 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Apr 2020 15:41:08 -0700 From: bob prohaska To: Jonathan Chen Cc: Mark Millard , freebsd-arm , Georg Lindenberg , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200423224108.GC3996@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 497XMn5nqgz4QNV 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 [2.12 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.05)[ip: (0.23), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.08)[0.082,0]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.08)[0.083,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:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; FREEMAIL_CC(0.00)[yahoo.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: Thu, 23 Apr 2020 22:41:10 -0000 On Fri, Apr 24, 2020 at 09:31:09AM +1200, Jonathan Chen wrote: > On Fri, 24 Apr 2020 at 09:26, bob prohaska wrote: > > > > On Fri, Apr 24, 2020 at 08:32:54AM +1200, Jonathan Chen wrote: > > > On Fri, 24 Apr 2020 at 08:22, Mark Millard wrote: > > > [...] > > > > The RPi3 will not start to boot from a gpt partitioned > > > > media. So picking gpt labeling as the example is somewhat > > > > misleading for single-media booting. glabel based > > > > labeling would be more realistic for the context. > > > > > > The OP is attempting to boot off an external USB drive via loader.env. > > > So it's the external drive's partitioning system that is of interest. > > > > The USB drive on my system was written with dd using > > FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200409-r359731.img > > It's been resized to fill the hard disk and given a swap partition. > > Gpart reports > > bob@www:~ % gpart show da0 > > => 63 78140097 da0 MBR (37G) > > 63 2016 - free - (1.0M) > > 2079 102312 1 fat32lba [active] (50M) > > 104391 78035769 2 freebsd (37G) > > > > This is consistent with what your boot messages are showing. Your > loader.env should have rootdev=disk1p2: > I've added /boot/loader.env and tried to boot again. After loading the kernel I stopped at the loader prompt: Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. OK show rootdev variable 'rootdev' not found OK more /boot/loader.env *** FILE /boot/loader.env BEGIN *** rootdev=disk1p2: *** FILE /boot/loader.env END *** It's pretty clear loader is looking at USB. > Your current boot failure is due to the contents of /etc/fstab. What > do you have in there? Only what was supplied by the snapshot image file: # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs / ufs rw 1 1 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 At the loader prompt /boot is populated, apparently from USB, but /dev is empty. It may be crude, but would replacing /dev/ufs/rootfs with /dev/da0s2a work for now? I.e., would it become meaningful by the time the kernel needs to know where it lives? I expected that to happen automatically, but since /etc/fstab will have to be edited anyway to turn on swap it's relatively easy. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Apr 23 22:49:13 2020 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 5EEE02C5D37 for ; Thu, 23 Apr 2020 22:49:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.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 497XY33DGDz4Qkn for ; Thu, 23 Apr 2020 22:49:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: UYugoUcVM1nPEr1anm7Y.MpT4deZCUBHua1GlFFWLJWpWr9tD_8VLJzQCnwC8e9 GHM5uyvqkG5Eok9L2uueG7mfDSR64m6QfqxHIfcWO8EYC1Nq.zAfZoAVQK9E9s_s3VZw4NoF3EJB R1_JhUmQtgUq9ru9Oudky8UvdPrJzfAIrZsAgWxPOgDYeKpOIVYJ4Qp9svp_NWwntwdHQmR3SiiM hvcV3jRCtodO9WOmeNKsAzMM0RmsArEaaW2qK4W1EMrqGpVymaza5QRIHoxIsN3v5A489OvnxYrY 7twi6cRfwlvnBPiQXIBsYpKAKk_.BP3rtqnggfV_0fmcAmxQWh3UevnolJkAF8OBIRVSJ.CA5bxI qlz.8ODFVaaV0wNhxZDf5rYCyFi0adZrfB9z3zRFXKwvq2KKl5tV04isfVNgZKkAKLzohQR3Fgjy oWncI_upYFZ48wBRwBjfdiHeE.JIjCiUTIdcrdBAKXgAKKyONNEf18NfTP5OACUrzxoEqDVCQ85h NxsaOSGRSxeSx56Tsj6wNqLZdviGjW_ZVdk1fMGK0tRvXk_MN2EAenUuEujmFeXFCrDWZ6tnD5eL h.W3IW8BatBllimafXCJNb82oMJgd0sxxR5KPbsUICBX5xaiL256EgYd9OXtU83aKHeVdcjaxhMo 8JDxHJq4N_O20.4dDi9mgVV1fH22Ap1EURkeMlPNKTrC67lTjtit.C_jAucQo746yheAJ0RJJzii gobQxPyOaXZm_gGZ4JSQlF81ocHdTFLLQUy3JoTt1qDkouxHxom6HsSt13odydP68xo.d7FpL2Gw oTkem0jfLNZHMc9qQiqPytQgYinfDX5hdyn..QB1CasE.j0yyPTtYhyse6asA2FbbwVsJ0_jt86Y 0mzdI8XDuydr5l2W_NRRj5er.hY_nP3wJRF.eTajet4IKAW1rVdpmBJn3v0QDK7AekcMsD2i8WML 7T7m16l2fGajJlfG_u5dYLGBQkgsrlp9GzU1u_t51hbsel3j3CAiHQTdtbQE5M4UZQtqV.y84ugW AZBPgT5UC3fFHEsK9fYD87hCczOiduLkZGurJa_lgtA1M8sXJ1L3kR6itcDsdb1M6.CwI0rGb7e9 fqzKcCw0j.hwTwyEZuCZjI1VLpuBYvE3dSduwlChU_0jP_1j6wjkN2AJ4z2dbWfLvDi6hwRPNELB _tSbL0TekZ0DlMZYQD83WFcXan3anNmSwmZZM.fdjgou2qEv_gwiqCthOYbLnRkqqm8fDb7.kOw7 61DXtaYwIgSNiQokPocbEVpf4mLVua9lWh0x4hQB51KR37z4T9Tj7eQhRDwy7jGcvz5is.tGXBg6 7nWWhcGZZmUKLvG2JYg11NAxwRO8ecQHDJEY6a_7jhwk6WvbNuBdc1B09BVwNyMmj7XYoSLcmexB F9J2B1OSghekcKc4TOoDnRu_Y2ZZn8B94 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Apr 2020 22:49:10 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b7ae6bff673ad7ba69a6e32fc75ceaeb; Thu, 23 Apr 2020 22:49:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: Date: Thu, 23 Apr 2020 15:49:07 -0700 Cc: freebsd-arm , Georg Lindenberg Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> To: Jonathan Chen , bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497XY33DGDz4Qkn X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.75)[-0.748,0]; 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)[]; NEURAL_HAM_LONG(-0.95)[-0.950,0]; RCVD_COUNT_TWO(0.00)[2]; 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)[83.69.137.98.list.dnswl.org : 127.0.5.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: (4.88), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), 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: Thu, 23 Apr 2020 22:49:13 -0000 On 2020-Apr-23, at 14:20, Mark Millard wrote: > On 2020-Apr-23, at 13:32, Jonathan Chen wrote: >=20 >> On Fri, 24 Apr 2020 at 08:22, Mark Millard wrote: >> [...] >>> The RPi3 will not start to boot from a gpt partitioned >>> media. So picking gpt labeling as the example is somewhat >>> misleading for single-media booting. glabel based >>> labeling would be more realistic for the context. >=20 > Note the "single-media booting" reference above. >=20 >> The OP is attempting to boot off an external USB drive via = loader.env. >> So it's the external drive's partitioning system that is of interest. >> FYI, my RPI3 boots off a GPT partition fine: >>=20 >> 1.topaz:~,8:30am# uname -a >> FreeBSD topaz.inside.chen.org.nz 12.1-STABLE FreeBSD 12.1-STABLE #0 >> r358927: Sun Mar 15 22:24:30 NZDT 2020 >> = jonc@onyx.inside.chen.org.nz:/xbuilds/rpi3/obj/usr/src/arm64.aarch64/sys/G= ENERIC >> arm64 >> 1.topaz:~,8:30am# gpart show -l da0 >> =3D> 40 976773088 da0 GPT (466G) >> 40 8152 - free - (4.0M) >> 8192 964689920 1 topaz-root (460G) >> 964698112 12075016 2 topaz-swap (5.8G) >>=20 >> 1.topaz:~,8:30am# cat /etc/fstab >> # Device Mountpoint FStype Options Dump = Pass# >> /dev/gpt/topaz-root / ufs rw 1 = 1 >> /dev/gpt/topaz-swap none swap sw 0 = 0 >>=20 >=20 > That does not appear to have the msdosfs/EFI material > on the USB drive. So I'd guess that you are using > the microsd card for that: 2 media overall, not > single-media. >=20 > I also use a form of two-media instead of single-media > and use gpt on the USB media: >=20 > # gpart show > =3D> 63 249737153 mmcsd0 MBR (119G) > 63 16380 - free - (8.0M) > 16443 131040 1 fat32lba [active] (64M) > 147483 997 - free - (499K) > 148480 241172480 2 freebsd (115G) > 241320960 8416256 - free - (4.0G) >=20 > =3D> 0 241172480 mmcsd0s2 BSD (115G) > 0 230686720 1 freebsd-ufs (110G) > 230686720 10485760 - free - (5.0G) >=20 > =3D> 40 468862048 da0 GPT (224G) > 40 2008 - free - (1.0M) > 2048 413138944 1 freebsd-ufs (197G) > 413140992 6291456 2 freebsd-swap (3.0G) > 419432448 6291456 4 freebsd-swap (3.0G) > 425723904 43138184 - free - (21G) >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/gpt/PINE642Groot 195378 34775 144973 19% / > devfs 0 0 0 100% /dev > /dev/label/PINE64P2Groot 109101 219 100153 0% /microsd_ufs > /dev/label/PINE642GAboot 63 43 20 69% /boot/efi >=20 > I choose to have a copy of /boot on /microsd_ufs > and to use vfs.root.mountfrom=3D"ufs:/dev/gpt/PINE642Groot" > in the loader.conf file in my context. >=20 > But such is not what Bob P. is trying to do from what > I can tell. He looks to be trying to avoid microsd > card media use if he can. He needs MBR on the USB > media for that (or some hybrid MBR that proves > compatibile). Correcting my mistaken memory of what raspberrypi.org documents . . . The BCM2837 (RPi3) and BCM2837B0 (RPi3B) have documentation at: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/b= ootflow.md that does report: =E2=80=A2 The boot ROM also now supports GUID partitioning and = has been tested with hard drives partitioned using Mac, Windows, and = Linux. It also notes (prior to the above): =E2=80=A2 It is no longer necessary for the first partition to = be the FAT partition, as the MSD boot will continue to search for a FAT = partition beyond the first one. (I guess MSD is short for "mass storage device".) It also documents that for USB hubs these RPi3* vintages do recurse for each port. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Apr 23 23:07:53 2020 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 0199F2C64B1 for ; Thu, 23 Apr 2020 23:07:53 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 497Xyb5V83z4Rt2 for ; Thu, 23 Apr 2020 23:07:51 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-ot1-x342.google.com with SMTP id e20so9179298otk.12 for ; Thu, 23 Apr 2020 16:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7WJqSAD/UpOuh6rK3dnjKEofUzISDU/rHBY4K3rwPgo=; b=gTiWnfUfDeFgApWkXvzXunV4fYwD9y39fmWYBL346UqyJg50NZBAzhHHheOTqmiKx7 qUF0oChj/7k+9GTEdnlPvE/HGkrToxh3CtthiXpEBuUjuzErVaFvR/5nFDLrcY3rnXyw HPlvVw5dRrO6LIuGHqXCYfS3sdl4XNd6UlNbad1UjBFEauRKOcM8HQW/JdFGZmueu0wL Pnj1dnz3aaT2LztVUIhfI99SIP/zqIxXq3JViqewef1ZIyGkSGS1/jEm5EM7ohIcVhaS ZjD0YRmdY63W3SyMsYocxezkJJDZY0ZAUP6KKwGW5TPWzEn+bUSj/sJGNXsN9QzN6vF0 9V7Q== 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=7WJqSAD/UpOuh6rK3dnjKEofUzISDU/rHBY4K3rwPgo=; b=dRN2z6ZScoD5m18BOxRzEwDurHXSBrxVag2Haa5qmvseGp+p3BZP17V1E/bTazy/i2 3OemZkKSygQx8U9ZGwaLi6Mv/TRVpRRjB28sJRfZG012KELfadiTzzYCgT71f9Wru6Yt Y58A2Bggluhzu6QbIdftLmGB70IOMssBOTjbroDUHi7ImdRx6QRXpAnaCe6LITDNhGhk d9Bn+wR1zi07ymLPDrJHAKC48Oln1hUZykz8bLbDm+EkZ0gtPuwWTYHkx8udlkEMLgks urONE5PKHjKLlcOnYwozu+yvrOYm6sUiCqOwWUHsQxH5Ldqxa1uYswhQeptwjoz0GrGj +toQ== X-Gm-Message-State: AGi0PuYMapVlnQgkLmSWAvy7BbpmeuF82U+eHTEbfIrlpe/ObU5YmQR2 zNJdrjCx1DEichGhxGzoQkhKsvzKn5WJxWpLZQ9EmA== X-Google-Smtp-Source: APiQypIgH8DS+NNAvAT9w+RJQyAjUtYhZUI+mxWrU71OF+InIFB4E4Smb6xETfuwkpDZzPrtu0puk/RWbUfp2rbBswc= X-Received: by 2002:a9d:5e0d:: with SMTP id d13mr5636710oti.162.1587683270634; Thu, 23 Apr 2020 16:07:50 -0700 (PDT) MIME-Version: 1.0 References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <20200423224108.GC3996@www.zefox.net> In-Reply-To: <20200423224108.GC3996@www.zefox.net> From: Jonathan Chen Date: Fri, 24 Apr 2020 11:07:34 +1200 Message-ID: Subject: Re: Booting from USB on RPI3 To: bob prohaska Cc: Mark Millard , freebsd-arm , Georg Lindenberg Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 497Xyb5V83z4Rt2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=gTiWnfUf; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::342 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; 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)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2.4.3.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.08)[ip: (0.41), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_CC(0.00)[yahoo.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: Thu, 23 Apr 2020 23:07:53 -0000 On Fri, 24 Apr 2020 at 10:41, bob prohaska wrote: > On Fri, Apr 24, 2020 at 09:31:09AM +1200, Jonathan Chen wrote: > > On Fri, 24 Apr 2020 at 09:26, bob prohaska wrote: > > > Gpart reports > > > bob@www:~ % gpart show da0 > > > => 63 78140097 da0 MBR (37G) > > > 63 2016 - free - (1.0M) > > > 2079 102312 1 fat32lba [active] (50M) > > > 104391 78035769 2 freebsd (37G) > > > > > > > This is consistent with what your boot messages are showing. Your > > loader.env should have rootdev=disk1p2: > > > I've added /boot/loader.env and tried to boot again. Actually, I was talking about /EFI/FreeBSD/loader.env on your microSD card. [...] > > Your current boot failure is due to the contents of /etc/fstab. What > > do you have in there? > > Only what was supplied by the snapshot image file: > > # Custom /etc/fstab for FreeBSD embedded images > /dev/ufs/rootfs / ufs rw 1 1 > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 > > At the loader prompt /boot is populated, apparently from USB, > but /dev is empty. It may be crude, but would replacing > /dev/ufs/rootfs > with > /dev/da0s2a > work for now? I.e., would it become meaningful by the > time the kernel needs to know where it lives? I expected that to > happen automatically, but since /etc/fstab will have to be edited > anyway to turn on swap it's relatively easy. Yes, I think that could work. I'm not sure why your UFS label name isn't showing. Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Thu Apr 23 23:32:59 2020 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 8755F2C6EC9 for ; Thu, 23 Apr 2020 23:32:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 497YWZ2CzYz4TZ0 for ; Thu, 23 Apr 2020 23:32:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 03NNX0b5004405 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 16:33:00 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03NNX0l9004397; Thu, 23 Apr 2020 16:33:00 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Apr 2020 16:32:59 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200423233259.GD3996@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> X-Rspamd-Queue-Id: 497YWZ2CzYz4TZ0 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 [2.15 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.22), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.09)[0.091,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.11)[0.106,0]; 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: Thu, 23 Apr 2020 23:32:59 -0000 On Thu, Apr 23, 2020 at 03:24:57PM -0700, Mark Millard wrote: > > > > For USB-only or for microsd card also in use, > have you tried the equivalent of: > > OK lsdev > Another surprise. First time I tried, after some time idle: OK lsdev unknown command but a simple ls listed the contents of the root directory. Apparently the drive was asleep after an idle timeout. A second attempt at lsdev produced OK lsdev disk devices: disk0: 250085377 X 512 blocks (removable) disk0s1: DOS/Windows disk0s2: FreeBSD disk0s2a: FreeBSD UFS disk0s2b: FreeBSD swap disk1: 78140161 X 512 blocks disk1s1: DOS/Windows disk1s2: FreeBSD disk1s2a: FreeBSD UFS disk1s2b: FreeBSD swap http: (unknown) net devices: net0: > and then used the naming convention shown in > the output for any loader commands/settings > instead of using FreeBSD-stage da0 based naming? > (You might want to report what lsdev shows.) > > Note: the disk0 and disk1 like prefixes are > copied from the u-boot notations that the > loader gets from u-boot, if I understand > right. > > Does your loader.conf do anything to control > what is booted? Not in a way I recognize, but you might: OK more /boot/loader.conf *** FILE /boot/loader.conf BEGIN *** # Configure USB OTG; see usb_template(4). hw.usb.template=3 umodem_load="YES" # Multiple console (serial+efi gop) enabled. boot_multicons="YES" boot_serial="YES" # Disable the beastie menu and color beastie_disable="YES" loader_color="NO" *** FILE /boot/loader.conf END *** As Joanathan asked: what does > your /etc/fstab have listed? (/etc/fstab should > have FreeBSD notations, not loader device names.) OK more /etc/fstab *** FILE /etc/fstab BEGIN *** # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs / ufs rw 1 1 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 *** FILE /etc/fstab END *** OK > Are there any other boot-contributing files that > would be appropriate to show together in one > message for review, including any on the > msdos file system? > I don't know how to answer that question. Since the machine has gotten to loader and it's looking at the USB drive it's very tempting to think the msdos part is done. I'll admit that names like /dev/ufs/rootfs seem rather obscure. Are they required for RAID? Thanks for reading, apologies for less-than-insightful questions! bob prohaska From owner-freebsd-arm@freebsd.org Fri Apr 24 01:16:22 2020 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 7E6662C9A98 for ; Fri, 24 Apr 2020 01:16:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.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 497bps1qhfz4b4t for ; Fri, 24 Apr 2020 01:16:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: L4OJnOIVM1krPTXoJ8RmQFOVCeZ65hrvhJp329ZPwUITNCKfoOMDLoUq5IQKVWa wja1mJKPuCn0N290CFmYyxa4dHBojE9A.nU52_lcEYzWqk5hJgW7rOdfrdbUTXOVbO0LRHOAoT27 rSxV0F.15V8.p8fG3cL2hOvzxfY5ZbndATLIMtHrRDK_DGXJIFH.K_rDE51Ni_UkLegls8X1YKHw PynQ8BiiKVhWhU2Ne1d_EdamMWHXbWPuoLaeRDGocDyOBPlu4fg.FpGO3yQm_G13dOhZh5p1GAEp CkjY19BbCMDwUsB6oEeRUIZ.4yzaNl1Oscgo.ff8TDzf8jYtu9SrRezN43SqPLi1iFFTgSB4zGRG OqDz6ZygFGmoyaRdye2kBUECJLExKkJpOmjuwcKJPep8hNKo8t8iGNJtfN_B1LrsLgsEsHzzNU0L PBMucv5vwtri1fC5xCpF9NssdYnBGsfPo.qXj5VokavsaUFTKK5OuBVlAO7B7MPE1TrV2v_4OjDG i593GqDSnU2FrIGyGNctHjur1izVGn67V1ah5q3gzYjIN22IYD7xA9_MtIyyb2_oT_wHG151axAb R9l2sBZZ9i2T4.yVquod0u6uqdDHHfTJoEbShjic8p9FLC3Eb8OnskgeSApfuXUnj3hpQ8k1xcg. DzFWpn2AvyFy6SgmDoYyT43SMch5q2.h.245DQ5zjE_SCopYMjbiAecMGo.dTcFF2yVCnrTNjPms ohDV0M1UTzTuHu2bnjFUbzH73g1aUvw9EhD4mk_1hFSCX27_pfjCqZOBbhII670.bTxuwsUOdE9D ako7X0yR.SpA2nOjgLFVCii0MPzJbgT62iL9nBdKuOipCw9f1atZTV1KFMN5SV9jzObpIqHiN.b0 xAqug1pOwZFivmwNHE0cfOsj7uR_27lvyorYqo4v9dnz38m_g3cygh99PVaUR1DQviINqiwQDi4b CCG9yAvSUxbGzyP54p2b2levEkwny7nxbv3hyvxt3VU_5BfX8hMwEPEka859sS252ao2XZExmGws KMbvbAyNVFPGYK_uVseYtmBTrygPK6Boys.umJBUcdJSrxL2D5AFYgfVErJfE_xU0OWgpTVLVlnJ 3zHpf.GmaLyqXuE2L3se2_oJyDiZAXQMiKGtXL_3FCAzzRp3Mel999OwIsbJy5Bd.wmAqRg.7sRW xf3oRjF9fv6209H32Q.OB9gxUtKu3Napc5efLW3LEy3LFCIlca2kokGduD72u53opdrhqz4UFKtC dwm6UD1NaLJOF7U8Yp_gTbqgsoPZ5mGOkAKSAqzPPQKMf_LDPlKaXwtBoj2MJ.t9nRShzlMS5djr kPfvJzDXXHZ9TDe2EulKmrZNCCeO3R1PEUVvddsIwPCtRpyhW4gMccnMuOLnaZ08Q0wggDtgtboF hFl6wIsfMavmOM4q4BMG8CQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Apr 2020 01:16:19 +0000 Received: by smtp424.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 95dae3bcd0f1be9579c66eb242c8b5b4; Fri, 24 Apr 2020 01:16:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <20200423233259.GD3996@www.zefox.net> Date: Thu, 23 Apr 2020 18:16:14 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497bps1qhfz4b4t X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (0.38), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[206.68.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: Fri, 24 Apr 2020 01:16:22 -0000 On 2020-Apr-23, at 16:32, bob prohaska wrote: > On Thu, Apr 23, 2020 at 03:24:57PM -0700, Mark Millard wrote: >> >> >> >> For USB-only or for microsd card also in use, >> have you tried the equivalent of: >> >> OK lsdev >> > Another surprise. First time I tried, after some time idle: > OK lsdev > unknown command > but a simple > ls > listed the contents of the root directory. Apparently the > drive was asleep after an idle timeout. > > A second attempt at lsdev produced > OK lsdev > disk devices: > disk0: 250085377 X 512 blocks (removable) > disk0s1: DOS/Windows > disk0s2: FreeBSD > disk0s2a: FreeBSD UFS > disk0s2b: FreeBSD swap > disk1: 78140161 X 512 blocks > disk1s1: DOS/Windows > disk1s2: FreeBSD > disk1s2a: FreeBSD UFS > disk1s2b: FreeBSD swap > http: (unknown) > net devices: > net0: Where both the microsd card (disk0) and the USB drive (disk1) set up via installing FreeBSD distributed .iso's, at least for how the file systems were created (even if somewhat adjusted later)? If yes, it may be that you have two instances of each of: /dev/msdosfs/MSDOSBOOT /dev/ufs/rootfs one per disk* for each. These types of naming are expecting to have been set up with what is after the last / being a unique name relative to everything else potentially present at the same time. This means that two .iso installs would need to have been adjusted to make the names distinct before trying to use the media together. If these names are duplicated, then use of the notations in /etc/fstab would be ambiguous for identifying the drives and I've no clue which instance wins --or if which wins is even stable. For ufs, tunefs has an option for setting the file system label: -L volname Add/modify an optional file system volume label. Legal characters are alphanumerics, dashes, and underscores. Once the adjustment is seen (remount/reboot?), that should make: /dev/ufs/... change to the new name. I'm only aware of file systsem creation-time setting for msdos via newfs_msdos : -L label Volume label (up to 11 characters). The label should consist of only those characters permitted in regular DOS (8+3) filenames. That should make /dev/msdosfs/... be the assigned name. But newfs_msdos would not preserve the contents of the file system that was present before (if any). glabel can be used to assign labels that are independent of the file system and of the partition metadata, labels that would appear under /dev/label/ instead of under /dev/ufs/ or /dev/msdosfs/ or /dev/gpt/ . (gpt is not an option for MBR contexts.) >> and then used the naming convention shown in >> the output for any loader commands/settings >> instead of using FreeBSD-stage da0 based naming? >> (You might want to report what lsdev shows.) >> >> Note: the disk0 and disk1 like prefixes are >> copied from the u-boot notations that the >> loader gets from u-boot, if I understand >> right. >> >> Does your loader.conf do anything to control >> what is booted? > > Not in a way I recognize, but you might: > OK more /boot/loader.conf > *** FILE /boot/loader.conf BEGIN *** > # Configure USB OTG; see usb_template(4). > hw.usb.template=3 > umodem_load="YES" > # Multiple console (serial+efi gop) enabled. > boot_multicons="YES" > boot_serial="YES" > # Disable the beastie menu and color > beastie_disable="YES" > loader_color="NO" > *** FILE /boot/loader.conf END *** Nothing there to control what is booted. > As Joanathan asked: what does >> your /etc/fstab have listed? (/etc/fstab should >> have FreeBSD notations, not loader device names.) > > OK more /etc/fstab > *** FILE /etc/fstab BEGIN *** > # Custom /etc/fstab for FreeBSD embedded images > /dev/ufs/rootfs / ufs rw 1 1 > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 > *** FILE /etc/fstab END *** > OK See earlier notes: each media may be defining what causes /dev/ufs/rootfs , leading to ambiguity. Similarly for /dev/msdosfs/MSDOSBOOT . /etc/fstab should use notation that is a unique identification for each device. The media should have names assigned that are unique compared to anything else potentially connected at the same time if labeling style names are to be used. Names like /dev/da* are not stable from boot to boot if multiple USB media are present at the same time: which media gets which da* name could vary from boot to boot. Using some form of unique label assignment is a way of avoiding this. However, if you stick to only one USB drive being present, likely /dev/da0s2a would be a stable USB drive ufs file system reference for that context. Similarly for /dev/da0s1 being a stable reference to the USB msdosfs . /dev/mmcsd0s1 would likely also be a stable microsd card msdosfs reference for your context. Similarly for /dev/mmcsd0s2a for being a stable reference to your microsd card ufs file system. For now such notations may be better for your /etc/fstab file(s). >> Are there any other boot-contributing files that >> would be appropriate to show together in one >> message for review, including any on the >> msdos file system? >> > > I don't know how to answer that question. Since the machine > has gotten to loader and it's looking at the USB drive it's > very tempting to think the msdos part is done. I'll admit > that names like /dev/ufs/rootfs seem rather obscure. > Are they required for RAID? > An example: does either media have in its msdos file system: /EFI/FreeBSD/loader.env ? If yes, are the settings present in loader.env that contribute to what boots? (That is something from Jonathan's exchanges with you.) A separate question is: Other than bootcode.bin , are the contents in the two msdos files systems identical? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Apr 24 02:18:08 2020 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 ED66F2CB2BE for ; Fri, 24 Apr 2020 02:18:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 497dB75F3vz4f1s for ; Fri, 24 Apr 2020 02:18:07 +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 03O2I9bd004713 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 19:18:09 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03O2I9La004712; Thu, 23 Apr 2020 19:18:09 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Apr 2020 19:18:08 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200424021808.GA4638@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> X-Rspamd-Queue-Id: 497dB75F3vz4f1s 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 [2.05 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.22), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.09)[0.095,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.01)[0.006,0]; 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: Fri, 24 Apr 2020 02:18:09 -0000 On Thu, Apr 23, 2020 at 06:16:14PM -0700, Mark Millard wrote: > On 2020-Apr-23, at 16:32, bob prohaska wrote: > > > On Thu, Apr 23, 2020 at 03:24:57PM -0700, Mark Millard wrote: > >> > >> > >> > >> For USB-only or for microsd card also in use, > >> have you tried the equivalent of: > >> > >> OK lsdev > >> > > Another surprise. First time I tried, after some time idle: > > OK lsdev > > unknown command > > but a simple > > ls > > listed the contents of the root directory. Apparently the > > drive was asleep after an idle timeout. > > > > A second attempt at lsdev produced > > OK lsdev > > disk devices: > > disk0: 250085377 X 512 blocks (removable) > > disk0s1: DOS/Windows > > disk0s2: FreeBSD > > disk0s2a: FreeBSD UFS > > disk0s2b: FreeBSD swap > > disk1: 78140161 X 512 blocks > > disk1s1: DOS/Windows > > disk1s2: FreeBSD > > disk1s2a: FreeBSD UFS > > disk1s2b: FreeBSD swap > > http: (unknown) > > net devices: > > net0: > > Where both the microsd card (disk0) and > the USB drive (disk1) set up via installing > FreeBSD distributed .iso's, at least for > how the file systems were created (even > if somewhat adjusted later)? > (thinking you meant "were both...") The answer is yes, both were written with dd from a downloaded .img file. > If yes, it may be that you have two instances > of each of: > > /dev/msdosfs/MSDOSBOOT > /dev/ufs/rootfs > > one per disk* for each. > Yes, but if I'm quick enough stopping u-boot wouldn't only one be read per boot attempt? > These types of naming are expecting to have > been set up with what is after the last / being > a unique name relative to everything else > potentially present at the same time. This > means that two .iso installs would need > to have been adjusted to make the names > distinct before trying to use the media > together. > > If these names are duplicated, then use of > the notations in /etc/fstab would be ambiguous > for identifying the drives and I've no clue > which instance wins --or if which wins is even > stable. > > For ufs, tunefs has an option for setting the > file system label: > > -L volname > Add/modify an optional file system volume label. Legal > characters are alphanumerics, dashes, and underscores. > > Once the adjustment is seen (remount/reboot?), > that should make: > > /dev/ufs/... > > change to the new name. > > I'm only aware of file systsem creation-time setting > for msdos via newfs_msdos : > > -L label > Volume label (up to 11 characters). The label should consist of > only those characters permitted in regular DOS (8+3) filenames. > > That should make > > /dev/msdosfs/... > > be the assigned name. But newfs_msdos would not > preserve the contents of the file system that > was present before (if any). > > glabel can be used to assign labels that are > independent of the file system and of the > partition metadata, labels that would appear > under /dev/label/ instead of under /dev/ufs/ > or /dev/msdosfs/ or /dev/gpt/ . (gpt is not > an option for MBR contexts.) > > > >> and then used the naming convention shown in > >> the output for any loader commands/settings > >> instead of using FreeBSD-stage da0 based naming? > >> (You might want to report what lsdev shows.) > >> > >> Note: the disk0 and disk1 like prefixes are > >> copied from the u-boot notations that the > >> loader gets from u-boot, if I understand > >> right. > >> > >> Does your loader.conf do anything to control > >> what is booted? > > > > Not in a way I recognize, but you might: > > OK more /boot/loader.conf > > *** FILE /boot/loader.conf BEGIN *** > > # Configure USB OTG; see usb_template(4). > > hw.usb.template=3 > > umodem_load="YES" > > # Multiple console (serial+efi gop) enabled. > > boot_multicons="YES" > > boot_serial="YES" > > # Disable the beastie menu and color > > beastie_disable="YES" > > loader_color="NO" > > *** FILE /boot/loader.conf END *** > > Nothing there to control what is booted. > > > As Joanathan asked: what does > >> your /etc/fstab have listed? (/etc/fstab should > >> have FreeBSD notations, not loader device names.) > > > > OK more /etc/fstab > > *** FILE /etc/fstab BEGIN *** > > # Custom /etc/fstab for FreeBSD embedded images > > /dev/ufs/rootfs / ufs rw 1 1 > > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > > tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 > > *** FILE /etc/fstab END *** > > OK > > See earlier notes: each media may be defining > what causes /dev/ufs/rootfs , leading to ambiguity. > Similarly for /dev/msdosfs/MSDOSBOOT . > > /etc/fstab should use notation that is a unique > identification for each device. The media should > have names assigned that are unique compared to > anything else potentially connected at the same > time if labeling style names are to be used. > > Names like /dev/da* are not stable from boot to > boot if multiple USB media are present at the > same time: which media gets which da* name could > vary from boot to boot. Using some form of unique > label assignment is a way of avoiding this. > > However, if you stick to only one USB drive > being present, likely /dev/da0s2a would be > a stable USB drive ufs file system reference > for that context. Similarly for /dev/da0s1 > being a stable reference to the USB msdosfs . > > /dev/mmcsd0s1 would likely also be a stable > microsd card msdosfs reference for your context. > Similarly for /dev/mmcsd0s2a for being a stable > reference to your microsd card ufs file system. > > For now such notations may be better for your > /etc/fstab file(s). > That seems to be key. Using /dev/da... notation in /etc/fstab on the USB device allows a successful boot. One very important detail that I forgot was adding kern.cam.boot_delay="20000" to /boot/loader.conf. Otherwise boots are successful only if something else (like me) delays the boot process. The erratic results observed likely owe much to that oversight. > >> Are there any other boot-contributing files that > >> would be appropriate to show together in one > >> message for review, including any on the > >> msdos file system? > >> > > > > I don't know how to answer that question. Since the machine > > has gotten to loader and it's looking at the USB drive it's > > very tempting to think the msdos part is done. I'll admit > > that names like /dev/ufs/rootfs seem rather obscure. > > Are they required for RAID? > > > > An example: does either media have in its msdos file > system: /EFI/FreeBSD/loader.env ? If yes, are the > settings present in loader.env that contribute to what > boots? > Apparently not by default; nothing in microSD, but I added a /boot/loader.env to the USB device, holding rootdev=disk1p2: It didn't seem to affect booting behavior, at least not on the first try. > (That is something from Jonathan's exchanges with > you.) > > > A separate question is: Other than bootcode.bin , > are the contents in the two msdos files systems > identical? > > Clearly not. Those on the the USB device are about six months newer and different in size. For now it looks as if the immediate problem is solved. Both microSD and USB storage boot and run. Thanks to all! bob prohaska From owner-freebsd-arm@freebsd.org Fri Apr 24 03:07:51 2020 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 DFB402CCCC2 for ; Fri, 24 Apr 2020 03:07:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 497fHV75LRz3DGT for ; Fri, 24 Apr 2020 03:07: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 03O37r3e004822 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Apr 2020 20:07:53 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03O37qq2004821; Thu, 23 Apr 2020 20:07:52 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Apr 2020 20:07:52 -0700 From: bob prohaska To: Georg Lindenberg Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200424030752.GB4638@www.zefox.net> References: <20200421181224.GC96994@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 497fHV75LRz3DGT 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 [1.56 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.16)[-0.158,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.05)[ip: (0.22), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.23)[-0.232,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[web.de]; 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: Fri, 24 Apr 2020 03:07:51 -0000 Hi Georg, Thank you for revealing some fine points of u-boot. I'd have given up without your help! bob prohaska On Wed, Apr 22, 2020 at 10:28:29PM +0200, Georg Lindenberg wrote: > > Gesendet: Dienstag, 21. April 2020 um 20:12 Uhr > > Von: "bob prohaska" > > An: "Georg Lindenberg" > > Cc: freebsd-arm@freebsd.org, "bob prohaska" > > Betreff: Re: Booting from USB on RPI3 > > > > On Tue, Apr 21, 2020 at 07:18:17PM +0200, Georg Lindenberg wrote: > > > Hey, > > > These are the steps I took to boot my RPI3B from usb. > > > > > > 1. Put the .img file on both the usb device and the SD Card (e.g. with dd). > > > 2. Plug in everything. RPI starts uboot from the SD Card. > > > 3. Type any key to enter the U-Boot prompt. Then type "run usb_boot". > > > > > > > That's a command I didn't know about, despite considerable looking. > > Is it described anywhere? > > > > It'll be my next experiment! > > > > > You can see all the uboot variables with "env print". Maybe it is possible to add "boot_cmd=run usb_boot" to one of the config files, but I was too scared to try it. > > > > My Pi3's setup is experimental, so crashing/corrupting it isn't a problem. > > > > Thanks very much for writing! > > > > bob prohaska > > > > > > Uboot will run bootcmd, unless you hit a key. Then it will enter the shell. > > You can track down bootcmd (env print bootcmd): > > bootcmd=distro_bootcmd > distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target} > boot_targets=mmc0 mmc1 usb0 pxe dhcp > > So, in this loop, usb0 is in third place. :-/ mmc will boot first. > > U-Boot> env print bootcmd_usb0 > bootcmd_usb0=devnum=0; run usb_boot > > Anyways, one way to tell uboot to boot the usb permanently would be sth like this: > setenv bootcmd=run usb_boot > saveenv > > However: > U-Boot> saveenv > Saving Environment to FAT... Failed (1) > This makes me wonder whether CONF_ENV_FAT_DEVICE_AND_PART is set correctly. It should be 0:1, or 0:auto, not 1:1. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Apr 24 04:26:59 2020 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 E31012CE49E for ; Fri, 24 Apr 2020 04:26:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 497h2p6c1lz3Hy8 for ; Fri, 24 Apr 2020 04:26:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: hX.2E1sVM1kv82_9yiMyL.GPHT8rK9IkH_4ZqIkXDmExSfyfvp6SNpX.WaYKfez sYoLJwnJQnGNetqyYL1puKBOH1zQDl9nuVSDfIJOajxNYcNYVb8GqJnUgj2_VXA5JEY9CrOjTu2F pf2bHvU9UqCNp1.0cvJZLcvxpryUESKA8q2I42kIl8f.3bo54Cs.BmGQT7gL3YP6TH3FHBeaBa9E rKbhRlOi3_fB7EJFSPXJENDE.Lisy5gLo8kwk5LXHMLK42SU2zxiMfsAUU672XIYD0sS74qX8fWY XNYjM_uVm1g963UrAw4HNS1RJ20OqCngqIsi4M7DqNCfd9ZXOf0L1lwgMSi0ma9Ks5Mosqpsde.d wlAXv8SjgdEiI2IgS3nheW2BMQNIeBIlBQtuo.DsDbqObKthq8pjJ.s7THZzyhR.SSpPvbn2mu5_ qPfjSk4hQY64A8kyJLlJFnyocuiRdhw7tNkdSI2rX3KDsJ1QY67OumMPTUd0fBYR70MKV27DJl7d lG8PR846jWmRxLZwu5sMXER8TwSX3_2BN6I4CPB3IT4Sek0QDgHL4D.0tG6cehq3ogQM7apO4n9G cOoPjLs70U_.WrgnSOLU6iZqcm2zBuLd4Wx0o2GguCCw60S4We_GZbYu8sUT.WHTHnUb.hngvOEu 5MFWxH3Y53tgNVoUZqeUbyIICLzxA7DZez2.vTJMxgK4zydAJl17CdPLranIMttn1wWKzfTt6._1 fByzFtH3J0IFePJplZQOkZ0g2GdIF5.9DltclzAx22eqUperqcfj3.veZrCQKI2D8bGMtM1Xx06S gCYwuJobVo8rivKETpxUaGqPGRjHCAD4Sq5KhMgUMGqBPy2rpe5OD5OpdwCU8uFM1ZrZI36cXa8h J.TFxMvc9Qj4tmwWkZZU1Qd7Qqy9iL.2vHWcMguRpIWDHMiTtH1OwyfO7Pj13kxtOiOTiLlTPlHw bzWQVJYBSgQB0ook4wlkMIRme2ndZjbz2k9870GqCsZgC2ORcJ9ef.0yLeTdZUWgzg1naTJzWVWu u08DDfQgntA_QddSLyFrceAf.TDRMadDYUCUOWzAsaZ2r6lDybm1Rj1RDq4n2zTpbvU8dKpa3ZxV XKOmFWXmnvQTSz4BcIoW6gvZoCSH2nacKZnW7Tx0YOe_hldG9vsIW1iM9xheiq6MpDSfcfDOHQUf LzkgiKD98zrrNUUX660SQz0i1ikaY6UkhplBRiJzvVNoOggEa5R6hgJVyeClEyt6zGH13cXfwI9M NtG49sYy3xSEnlmQS9u4kT2afuiww9liB0dCIRb43cD782JnCzHpxPlUjN85Dt3qYBWKYDhN0Xgx ZqDtkdjId4cMjn4RCmH_gHwZwJYB3P4sYHy6TIISrUn4XeD2YBr5EPP3TJPEFfcD.tVr_Ra4AlVb KsRLyj6U6jQuQiHuKx6vYv9ZaxRrECitgR_axD5fnwiaBfLbzj6pl1xc_vK6W Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Apr 2020 04:26:56 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1cc883d11fb204601ddbb224c720111c; Fri, 24 Apr 2020 04:26:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <20200424021808.GA4638@www.zefox.net> Date: Thu, 23 Apr 2020 21:26:53 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200421181224.GC96994@www.zefox.net> <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497h2p6c1lz3Hy8 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.954,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]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.98)[-0.978,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[146.64.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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: (3.25), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), 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: Fri, 24 Apr 2020 04:27:00 -0000 On 2020-Apr-23, at 19:18, bob prohaska wrote: > On Thu, Apr 23, 2020 at 06:16:14PM -0700, Mark Millard wrote: >> On 2020-Apr-23, at 16:32, bob prohaska wrote: >>=20 >>> On Thu, Apr 23, 2020 at 03:24:57PM -0700, Mark Millard wrote: >>>>=20 >>>>=20 >>>>=20 >>>> For USB-only or for microsd card also in use, >>>> have you tried the equivalent of: >>>>=20 >>>> OK lsdev >>>>=20 >>> Another surprise. First time I tried, after some time idle: >>> OK lsdev >>> unknown command >>> but a simple=20 >>> ls >>> listed the contents of the root directory. Apparently the >>> drive was asleep after an idle timeout. >>>=20 >>> A second attempt at lsdev produced >>> OK lsdev >>> disk devices: >>> disk0: 250085377 X 512 blocks (removable) >>> disk0s1: DOS/Windows >>> disk0s2: FreeBSD >>> disk0s2a: FreeBSD UFS >>> disk0s2b: FreeBSD swap >>> disk1: 78140161 X 512 blocks >>> disk1s1: DOS/Windows >>> disk1s2: FreeBSD >>> disk1s2a: FreeBSD UFS >>> disk1s2b: FreeBSD swap >>> http: (unknown) >>> net devices: >>> net0: >>=20 >> Where both the microsd card (disk0) and >> the USB drive (disk1) set up via installing >> FreeBSD distributed .iso's, at least for >> how the file systems were created (even >> if somewhat adjusted later)? >>=20 > (thinking you meant "were both...") True. Dumb typo. > The answer is yes, both were written with dd from a downloaded .img = file. >=20 >> If yes, it may be that you have two instances >> of each of: >>=20 >> /dev/msdosfs/MSDOSBOOT >> /dev/ufs/rootfs >>=20 >> one per disk* for each. >>=20 > Yes, but if I'm quick enough stopping u-boot wouldn't > only one be read per boot attempt?=20 If you stop the boot at: Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 then you are in u-boot/EFI before the FreeBSD loader is loaded/in-use. This is a very different context and does not involve or support the various types of labels or notations from FreeBSD. I assume you are not referring to this rather early stage of the boot sequence. FreeBSD looks at disks before mounting them and it looks at partitions/slices before they are mounted. It creates the bindings for the labels of various types (msdosfs, ufs, gpt, label) before mounting is even possible. It does so across all the media present at the time. This is so all the labels are available to use to pick what to mount (in FreeBSD terms). But it means that the loader has to pick what to do about ambiguous labeling before you are involved. (I've no clue if it keeps just the first-find or last-find or what. But in the end a label identifies only one thing, not multiple things.) There is meta-data on the media and in the partitions/slices/file-systems that indicates what labels to create. (The kernel may well repeat doing some things that the loader had to do, for all I know. Refinding labels could be an example.) >> These types of naming are expecting to have >=20 >> been set up with what is after the last / being >> a unique name relative to everything else >> potentially present at the same time. This >> means that two .iso installs would need >> to have been adjusted to make the names >> distinct before trying to use the media >> together. >>=20 >> If these names are duplicated, then use of >> the notations in /etc/fstab would be ambiguous >> for identifying the drives and I've no clue >> which instance wins --or if which wins is even >> stable. >>=20 >> For ufs, tunefs has an option for setting the >> file system label: >>=20 >> -L volname >> Add/modify an optional file system volume label. Legal >> characters are alphanumerics, dashes, and underscores. >>=20 >> Once the adjustment is seen (remount/reboot?), >> that should make: >>=20 >> /dev/ufs/... >>=20 >> change to the new name. >>=20 >> I'm only aware of file systsem creation-time setting >> for msdos via newfs_msdos : >>=20 >> -L label >> Volume label (up to 11 characters). The label should = consist of >> only those characters permitted in regular DOS (8+3) = filenames. >>=20 >> That should make >>=20 >> /dev/msdosfs/... >>=20 >> be the assigned name. But newfs_msdos would not >> preserve the contents of the file system that >> was present before (if any). >>=20 >> glabel can be used to assign labels that are >> independent of the file system and of the >> partition metadata, labels that would appear >> under /dev/label/ instead of under /dev/ufs/ >> or /dev/msdosfs/ or /dev/gpt/ . (gpt is not >> an option for MBR contexts.) >>=20 >>=20 >>>> and then used the naming convention shown in >>>> the output for any loader commands/settings >>>> instead of using FreeBSD-stage da0 based naming? >>>> (You might want to report what lsdev shows.) >>>>=20 >>>> Note: the disk0 and disk1 like prefixes are >>>> copied from the u-boot notations that the >>>> loader gets from u-boot, if I understand >>>> right. >>>>=20 >>>> Does your loader.conf do anything to control >>>> what is booted?=20 >>>=20 >>> Not in a way I recognize, but you might: >>> OK more /boot/loader.conf >>> *** FILE /boot/loader.conf BEGIN *** >>> # Configure USB OTG; see usb_template(4). >>> hw.usb.template=3D3 >>> umodem_load=3D"YES" >>> # Multiple console (serial+efi gop) enabled. >>> boot_multicons=3D"YES" >>> boot_serial=3D"YES" >>> # Disable the beastie menu and color >>> beastie_disable=3D"YES" >>> loader_color=3D"NO" >>> *** FILE /boot/loader.conf END *** >>=20 >> Nothing there to control what is booted. >>=20 >>> As Joanathan asked: what does >>>> your /etc/fstab have listed? (/etc/fstab should >>>> have FreeBSD notations, not loader device names.) >>>=20 >>> OK more /etc/fstab >>> *** FILE /etc/fstab BEGIN *** >>> # Custom /etc/fstab for FreeBSD embedded images >>> /dev/ufs/rootfs / ufs rw 1 1 >>> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 >>> tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m 0 0 >>> *** FILE /etc/fstab END *** >>> OK=20 >>=20 >> See earlier notes: each media may be defining >> what causes /dev/ufs/rootfs , leading to ambiguity. >> Similarly for /dev/msdosfs/MSDOSBOOT . >>=20 >> /etc/fstab should use notation that is a unique >> identification for each device. The media should >> have names assigned that are unique compared to >> anything else potentially connected at the same >> time if labeling style names are to be used. >>=20 >> Names like /dev/da* are not stable from boot to >> boot if multiple USB media are present at the >> same time: which media gets which da* name could >> vary from boot to boot. Using some form of unique >> label assignment is a way of avoiding this. >>=20 >> However, if you stick to only one USB drive >> being present, likely /dev/da0s2a would be >> a stable USB drive ufs file system reference >> for that context. Similarly for /dev/da0s1 >> being a stable reference to the USB msdosfs . >>=20 >> /dev/mmcsd0s1 would likely also be a stable >> microsd card msdosfs reference for your context. >> Similarly for /dev/mmcsd0s2a for being a stable >> reference to your microsd card ufs file system. >>=20 >> For now such notations may be better for your >> /etc/fstab file(s). >>=20 > That seems to be key. Using /dev/da... notation in /etc/fstab > on the USB device allows a successful boot. One very important > detail that I forgot was adding kern.cam.boot_delay=3D"20000" > to /boot/loader.conf. Otherwise boots are successful only if > something else (like me) delays the boot process. The erratic > results observed likely owe much to that oversight. As I remember there is a RPi* way of increasing its 2 second wait for a device on a port to indicate it is present. If you end up with problems despite the FreeBSD stage materials indicating delays, you might have to have the RPi3 increase its delay. The RPi3 activity for this is before FreeBSD is involved, possibly even before u-boot is involved. >>>> Are there any other boot-contributing files that >>>> would be appropriate to show together in one >>>> message for review, including any on the >>>> msdos file system? >>>>=20 >>>=20 >>> I don't know how to answer that question. Since the machine >>> has gotten to loader and it's looking at the USB drive it's >>> very tempting to think the msdos part is done. I'll admit >>> that names like /dev/ufs/rootfs seem rather obscure. >>> Are they required for RAID? >>>=20 >>=20 >> An example: does either media have in its msdos file >> system: /EFI/FreeBSD/loader.env ? If yes, are the >> settings present in loader.env that contribute to what >> boots? >>=20 > Apparently not by default; nothing in microSD, but I added=20 > a /boot/loader.env to the USB device, holding rootdev=3Ddisk1p2: > It didn't seem to affect booting behavior, at least not on > the first try.=20 There is no reason to have a /boot/loader.env as far as I know. It would be ignored: that is the wrong place for the file. EFI/FreeBSD/loader.env in the msdos file system is a way to supply input to EFI/BOOT/bootaa64.efi (the FreeBSD loader) before the loader tries to find the FreeBSD /boot it is going to use --and before you can type to the loader. That is why Jonathan was indicating to create the rootdev assignment there. (That rootdev is then used to find the /boot to use, as I understand things.) >> (That is something from Jonathan's exchanges with >> you.) >>=20 >>=20 >> A separate question is: Other than bootcode.bin , >> are the contents in the two msdos files systems >> identical? >>=20 >>=20 > Clearly not. Those on the the USB device are about six months > newer and different in size. You may want to make your msdosfs content matching and keep them matching as they progress, at least for anything that you do not have a specific reason to make a distinction for. (Avoids odd variations in behavior.) > For now it looks as if the immediate problem is solved. Both > microSD and USB storage boot and run.=20 Does that wording mean that you got USB-only to work too? Now that you can boot, you should be able to show the ufs labels (and more) with: tunefs -p /dev/mmcsd0s2a tunefs -p /dev/da0s2a The outputs will each have a line starting with: tunefs: volume label: (-L) and ending with the label (or empty for no label). If the two volume labels match, you should change at least one such that they are distinct. After that future boots should end up with two separate /dev/ufs/* names that you can use to pick the ufs file system with. The -L is the command line option involved in specifying a volume/file-system label. Unfortunately, I'm not aware of anything directly in FreeBSD analogous to "tunefs -p" or to "tunefs -L NAME . . .". for the msdos file systems. There seems to be only newfs_msdos --which would wipe out the existing msdosfs content by creating a new file system. But it does have a -L option for indicating the volume/file-system label to put in place. May be after doing such the content of the other msdos file system couple be copied into the new/empty file system. (Not via dd. dd'ing the slice would replace the label too, not just the content placed in the file system.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Apr 24 09:58:09 2020 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 7EF592AE1A4 for ; Fri, 24 Apr 2020 09:58:09 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 497qNv6hhXz46QZ for ; Fri, 24 Apr 2020 09:58:07 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id k1so10055163wrx.4 for ; Fri, 24 Apr 2020 02:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=1WAC7w3x+017mYrZ7+GBBxS/jNzUCsSxn1jWTaKfom8=; b=MYQVOmU6Hf/MTaUSOkJLxETRVQg/rmizncP/+I90pGJuL/gn8eMtbKd8JqtELD0fsO bt/cSsAaI71QjlpPATlYiVg5LzFPSUNHvnc731TBtHgO3qsuqFZkTjk7cXzK5lJQFNUI J2dZFKxy6Yj0+3nj7PgJOcpiwS2ixhbK1ItVVViE7tjqjNRhucOEuc3ctLcfHuyPjQYE tj5W9nnh9WMXNutVcaFEaH6CcXYniP6S8eeTUMISPxujPBgcaTxwGMsYpHldLsipkM10 z2uUiyWRubYjsT8KoekveQaVrKLmBJoP0E+qnQij1acVmnCmTQ1jhBcqFaIqjnw2YWcW nB2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=1WAC7w3x+017mYrZ7+GBBxS/jNzUCsSxn1jWTaKfom8=; b=JkM/jAxqpcAkdw3f7Fegk+x6bIXyGfdICMDejz+QMTV2nMy1wy9g7D5kLhE/mQlvSw RJvRkR2fceBtpD2vAOQQEyuhZgQpnKElleYdHTM0LsqYb3GaMpSbOYkzv2XHAyg6xEdp AAPv15ARu1h36dKgZBeeX/bmpboNbjrn5me/LjQ/sdtQarxX8ym7t3/0Vhyg7ExPoKRh 5Jlw8Ygi3yCdY7Rkfz1brPpZh6sJheRAPTtfywqnZpRlxH4ykWyTo9L1F0m0VFsgRI+d 8wqZfdIJbfpFdKSiSBJNf4utYh003ooJIcIRp+YQEiuGzMBdbt3uC9d7WD8WikaTSAKC doAw== X-Gm-Message-State: AGi0PuYALF2IK1nvmyWIKFno80OJG0bPCsx4+okjFM702r6cxTnTjUR8 t4sbjbhda+YHdiQFfY3bJlothAFtMN0= X-Google-Smtp-Source: APiQypIQ8coMpcf0LL0C9q/ULdg1IhUoYWn3VS9r9F6RFJo/lkH4Es0c52fUaUGvGQFUl8XKKahwmw== X-Received: by 2002:a5d:4843:: with SMTP id n3mr9917003wrs.7.1587722285471; Fri, 24 Apr 2020 02:58:05 -0700 (PDT) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id z22sm2105390wma.20.2020.04.24.02.58.04 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2020 02:58:04 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: RPI4 mmc device fails without WITNESS option ? Message-Id: Date: Fri, 24 Apr 2020 11:58:04 +0200 To: freebsd-arm X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 497qNv6hhXz46QZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=MYQVOmU6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::435 as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.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)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; 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]; IP_SCORE(0.00)[ip: (-9.35), ipnet: 2a00:1450::/32(-2.33), asn: 15169(-0.43), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[5.3.4.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]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 24 Apr 2020 09:58:09 -0000 Hi Just wanted to check perf on a 4G RPI=E2=82=AC here, and without WITNESS = in the kernel config it hangs: CPU 1: ARM Cortex-A72 r0p3 affinity: 1 CPU 2: ARM Cortex-A72 r0p3 affinity: 2 CPU 3: ARM Cortex-A72 r0p3 affinity: 3 regulator: shutting down unused regulators sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x000000c8 | Version: 0x00001002 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000004 sdhci_bcm0-slot0: Argument: 0x01cf7fc1 | Trn mode: 0x00000036 sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff0009 sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mountroot: waiting for device /dev/mmcsd0s2a... Mounting from ufs:/dev/mmcsd0s2a failed with error 19. With WITNESS enabled it just chuck along and boots.. Ideas ? -S=C3=B8ren From owner-freebsd-arm@freebsd.org Fri Apr 24 19:59:59 2020 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 128662C0F2F for ; Fri, 24 Apr 2020 19:59:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4984lK4qVBz43h1 for ; Fri, 24 Apr 2020 19:59:57 +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 03OJxson006832 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Apr 2020 12:59:54 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03OJxrAc006831; Fri, 24 Apr 2020 12:59:53 -0700 (PDT) (envelope-from fbsd) Date: Fri, 24 Apr 2020 12:59:53 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200424195953.GA6707@www.zefox.net> References: <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Rspamd-Queue-Id: 4984lK4qVBz43h1 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 [2.30 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.22), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.19)[0.191,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.16)[0.155,0]; 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: Fri, 24 Apr 2020 19:59:59 -0000 On Thu, Apr 23, 2020 at 09:26:53PM -0700, Mark Millard wrote: > On 2020-Apr-23, at 19:18, bob prohaska wrote: >=20 > > On Thu, Apr 23, 2020 at 06:16:14PM -0700, Mark Millard wrote: > >> On 2020-Apr-23, at 16:32, bob prohaska wrote: > >>=20 > >>> On Thu, Apr 23, 2020 at 03:24:57PM -0700, Mark Millard wrote: > >>>>=20 > >>>>=20 > >>>>=20 > >>>> For USB-only or for microsd card also in use, > >>>> have you tried the equivalent of: > >>>>=20 > >>>> OK lsdev > >>>>=20 > >>> Another surprise. First time I tried, after some time idle: > >>> OK lsdev > >>> unknown command > >>> but a simple=20 > >>> ls > >>> listed the contents of the root directory. Apparently the > >>> drive was asleep after an idle timeout. > >>>=20 > >>> A second attempt at lsdev produced > >>> OK lsdev > >>> disk devices: > >>> disk0: 250085377 X 512 blocks (removable) > >>> disk0s1: DOS/Windows > >>> disk0s2: FreeBSD > >>> disk0s2a: FreeBSD UFS > >>> disk0s2b: FreeBSD swap > >>> disk1: 78140161 X 512 blocks > >>> disk1s1: DOS/Windows > >>> disk1s2: FreeBSD > >>> disk1s2a: FreeBSD UFS > >>> disk1s2b: FreeBSD swap > >>> http: (unknown) > >>> net devices: > >>> net0: > >>=20 > >> Where both the microsd card (disk0) and > >> the USB drive (disk1) set up via installing > >> FreeBSD distributed .iso's, at least for > >> how the file systems were created (even > >> if somewhat adjusted later)? > >>=20 > > (thinking you meant "were both...") >=20 > True. Dumb typo. >=20 > > The answer is yes, both were written with dd from a downloaded .img fil= e. > >=20 > >> If yes, it may be that you have two instances > >> of each of: > >>=20 > >> /dev/msdosfs/MSDOSBOOT > >> /dev/ufs/rootfs > >>=20 > >> one per disk* for each. > >>=20 > > Yes, but if I'm quick enough stopping u-boot wouldn't > > only one be read per boot attempt?=20 >=20 > If you stop the boot at: >=20 > Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 >=20 > then you are in u-boot/EFI before the FreeBSD > loader is loaded/in-use. This is a very > different context and does not involve or > support the various types of labels or > notations from FreeBSD. I assume you are > not referring to this rather early stage > of the boot sequence. >=20 There's a very early prompt from u-boot, which must be invoked to stop booting the microSD. That's the point where one gets the u-boot>=20 prompt, and the place to run the usb reset and run bootcmd_usb0 commands. The next chance to intervene is at the pause before booting the loaded kernel, which is where I was poking around. > FreeBSD looks at disks before mounting them > and it looks at partitions/slices before they > are mounted. It creates the bindings for > the labels of various types (msdosfs, ufs, > gpt, label) before mounting is even possible. > It does so across all the media present at > the time. This is so all the labels are > available to use to pick what to mount (in > FreeBSD terms). But it means that the loader > has to pick what to do about ambiguous labeling > before you are involved. >=20 I suspect that had I not used a microSD with a runnable FreeBSD installation the boot of USB would have been trouble-free. =20 > (I've no clue if it keeps just the first-find > or last-find or what. But in the end a label > identifies only one thing, not multiple things.) >=20 > There is meta-data on the media and in the > partitions/slices/file-systems that indicates > what labels to create. >=20 Are the labels created at each boot? I thought they were defined at partitioning.=20 > (The kernel may well repeat doing some things > that the loader had to do, for all I know. > Refinding labels could be an example.) >=20 > >> These types of naming are expecting to have > >=20 > >> been set up with what is after the last / being > >> a unique name relative to everything else > >> potentially present at the same time. This > >> means that two .iso installs would need > >> to have been adjusted to make the names > >> distinct before trying to use the media > >> together. > >>=20 > >> If these names are duplicated, then use of > >> the notations in /etc/fstab would be ambiguous > >> for identifying the drives and I've no clue > >> which instance wins --or if which wins is even > >> stable. > >>=20 > >> For ufs, tunefs has an option for setting the > >> file system label: > >>=20 > >> -L volname > >> Add/modify an optional file system volume label. Legal > >> characters are alphanumerics, dashes, and underscores. > >>=20 > >> Once the adjustment is seen (remount/reboot?), > >> that should make: > >>=20 > >> /dev/ufs/... > >>=20 > >> change to the new name. > >>=20 > >> I'm only aware of file systsem creation-time setting > >> for msdos via newfs_msdos : > >>=20 > >> -L label > >> Volume label (up to 11 characters). The label should cons= ist of > >> only those characters permitted in regular DOS (8+3) filen= ames. > >>=20 > >> That should make > >>=20 > >> /dev/msdosfs/... > >>=20 > >> be the assigned name. But newfs_msdos would not > >> preserve the contents of the file system that > >> was present before (if any). > >>=20 > >> glabel can be used to assign labels that are > >> independent of the file system and of the > >> partition metadata, labels that would appear > >> under /dev/label/ instead of under /dev/ufs/ > >> or /dev/msdosfs/ or /dev/gpt/ . (gpt is not > >> an option for MBR contexts.) > >>=20 > >>=20 > >>>> and then used the naming convention shown in > >>>> the output for any loader commands/settings > >>>> instead of using FreeBSD-stage da0 based naming? > >>>> (You might want to report what lsdev shows.) > >>>>=20 > >>>> Note: the disk0 and disk1 like prefixes are > >>>> copied from the u-boot notations that the > >>>> loader gets from u-boot, if I understand > >>>> right. > >>>>=20 > >>>> Does your loader.conf do anything to control > >>>> what is booted?=20 > >>>=20 > >>> Not in a way I recognize, but you might: > >>> OK more /boot/loader.conf > >>> *** FILE /boot/loader.conf BEGIN *** > >>> # Configure USB OTG; see usb_template(4). > >>> hw.usb.template=3D3 > >>> umodem_load=3D"YES" > >>> # Multiple console (serial+efi gop) enabled. > >>> boot_multicons=3D"YES" > >>> boot_serial=3D"YES" > >>> # Disable the beastie menu and color > >>> beastie_disable=3D"YES" > >>> loader_color=3D"NO" > >>> *** FILE /boot/loader.conf END *** > >>=20 > >> Nothing there to control what is booted. > >>=20 > >>> As Joanathan asked: what does > >>>> your /etc/fstab have listed? (/etc/fstab should > >>>> have FreeBSD notations, not loader device names.) > >>>=20 > >>> OK more /etc/fstab > >>> *** FILE /etc/fstab BEGIN *** > >>> # Custom /etc/fstab for FreeBSD embedded images > >>> /dev/ufs/rootfs / ufs rw 1 1 > >>> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > >>> tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m 0 0 > >>> *** FILE /etc/fstab END *** > >>> OK=20 > >>=20 > >> See earlier notes: each media may be defining > >> what causes /dev/ufs/rootfs , leading to ambiguity. > >> Similarly for /dev/msdosfs/MSDOSBOOT . > >>=20 > >> /etc/fstab should use notation that is a unique > >> identification for each device. The media should > >> have names assigned that are unique compared to > >> anything else potentially connected at the same > >> time if labeling style names are to be used. > >>=20 > >> Names like /dev/da* are not stable from boot to > >> boot if multiple USB media are present at the > >> same time: which media gets which da* name could > >> vary from boot to boot. Using some form of unique > >> label assignment is a way of avoiding this. > >>=20 > >> However, if you stick to only one USB drive > >> being present, likely /dev/da0s2a would be > >> a stable USB drive ufs file system reference > >> for that context. Similarly for /dev/da0s1 > >> being a stable reference to the USB msdosfs . > >>=20 > >> /dev/mmcsd0s1 would likely also be a stable > >> microsd card msdosfs reference for your context. > >> Similarly for /dev/mmcsd0s2a for being a stable > >> reference to your microsd card ufs file system. > >>=20 > >> For now such notations may be better for your > >> /etc/fstab file(s). > >>=20 > > That seems to be key. Using /dev/da... notation in /etc/fstab > > on the USB device allows a successful boot. One very important > > detail that I forgot was adding kern.cam.boot_delay=3D"20000" > > to /boot/loader.conf. Otherwise boots are successful only if > > something else (like me) delays the boot process. The erratic > > results observed likely owe much to that oversight. >=20 > As I remember there is a RPi* way of increasing its > 2 second wait for a device on a port to indicate it > is present. If you end up with problems despite the > FreeBSD stage materials indicating delays, you might > have to have the RPi3 increase its delay. The RPi3 > activity for this is before FreeBSD is involved, > possibly even before u-boot is involved. > There is, by adding an empty file named timeout to the msdos partition holding bootcode.bin, but it only gives six seconds. I think my hard drive needs about ten.=20 That's why the first run of usb scan fails to see the hard disk. Running usb reset at the u-boot prompt finds the disk. =20 > >>>> Are there any other boot-contributing files that > >>>> would be appropriate to show together in one > >>>> message for review, including any on the > >>>> msdos file system? > >>>>=20 > >>>=20 > >>> I don't know how to answer that question. Since the machine > >>> has gotten to loader and it's looking at the USB drive it's > >>> very tempting to think the msdos part is done. I'll admit > >>> that names like /dev/ufs/rootfs seem rather obscure. > >>> Are they required for RAID? > >>>=20 > >>=20 > >> An example: does either media have in its msdos file > >> system: /EFI/FreeBSD/loader.env ? If yes, are the > >> settings present in loader.env that contribute to what > >> boots? > >>=20 > > Apparently not by default; nothing in microSD, but I added=20 > > a /boot/loader.env to the USB device, holding rootdev=3Ddisk1p2: > > It didn't seem to affect booting behavior, at least not on > > the first try.=20 >=20 > There is no reason to have a /boot/loader.env as far > as I know. It would be ignored: that is the wrong > place for the file. >=20 Indeed, my mistake. And, in hindsight, probably unhelpful. > EFI/FreeBSD/loader.env in the msdos file system is > a way to supply input to EFI/BOOT/bootaa64.efi (the > FreeBSD loader) before the loader tries to find the > FreeBSD /boot it is going to use --and before you > can type to the loader. That is why Jonathan was > indicating to create the rootdev assignment there. > (That rootdev is then used to find the /boot to use, > as I understand things.) >=20 > >> (That is something from Jonathan's exchanges with > >> you.) > >>=20 > >>=20 > >> A separate question is: Other than bootcode.bin , > >> are the contents in the two msdos files systems > >> identical? > >>=20 > >>=20 > > Clearly not. Those on the the USB device are about six months > > newer and different in size. >=20 > You may want to make your msdosfs content matching and > keep them matching as they progress, at least for > anything that you do not have a specific reason to make > a distinction for. (Avoids odd variations in behavior.) >=20 > > For now it looks as if the immediate problem is solved. Both > > microSD and USB storage boot and run.=20 >=20 > Does that wording mean that you got USB-only to > work too? > Yes, bootstrapping _through_ microSD.=20 > Now that you can boot, you should be able to show > the ufs labels (and more) with: >=20 > tunefs -p /dev/mmcsd0s2a > tunefs -p /dev/da0s2a >=20 > The outputs will each have a line starting with: >=20 > tunefs: volume label: (-L) >=20 > and ending with the label (or empty for no label). >=20 > If the two volume labels match, you should > change at least one such that they are > distinct. After that future boots should > end up with two separate /dev/ufs/* names > that you can use to pick the ufs file system > with. The -L is the command line option > involved in specifying a volume/file-system > label. > Both microSD and USB root filesystems have the same label. That seems to be the crux of the problem. For now hard-coding device file names in /etc/fstab is probably the most idiot-proof method.=20 > Unfortunately, I'm not aware of anything > directly in FreeBSD analogous to "tunefs -p" > or to "tunefs -L NAME . . .". for the msdos > file systems. There seems to be only > newfs_msdos --which would wipe out the existing > msdosfs content by creating a new file system. > But it does have a -L option for indicating the > volume/file-system label to put in place. >=20 > May be after doing such the content of the > other msdos file system couple be copied into > the new/empty file system. (Not via dd. dd'ing > the slice would replace the label too, not just > the content placed in the file system.) Once, a long time ago, FreeBSD had a boot manager that lived, I think, in the msdos partition of each bootable hard disk. On startup, it presented a menu, something like 1 msdos 2 freebsd 3 next disk in the boot order defaulting to whatever was last selected. I think that recollection gave me false hope that dual-booting a Pi would be much simpler than it turned out. Thanks for your help and patience! bob prohaska From owner-freebsd-arm@freebsd.org Fri Apr 24 22:09:45 2020 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 1B20B2C4802 for ; Fri, 24 Apr 2020 22:09:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 4987d33gh1z4DJG for ; Fri, 24 Apr 2020 22:09:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 2tQYvIMVM1m.2SB6D2R.BdFUJRo_sgy2.yl5gGtWW7HDuUe4WA7FfvTtKe71j.S zUzSRtGZI8DGTXCKJrsfV37P2.HllVsMGKzkApjfnrKJQmI8gRFkdskuUuaYOxogm4lCj0DvMGBf UWfVY3.LNql2f.GvyIMV2RMPCK7DGFzjguraWEvOF5uuOGKxSKC_nlodN6X1CqmIg8REZHhZZ2Aj qgmvvWQEr0Rdt8cl0S8vsUexsWu0b9WwIx4l82truo84EDelBzgunzCpdFnTz4eSFYYHSim6_q52 cDTQpxwbwUNV6VYhRBNzAsxSTKSGv.QzyYNsoL3_zBb_S6Q.CYydqVSC1CJ0wHvHhx.qH0qoSJvj 84Xk5rvZqbc7j.GP8vtRMKEYHmIpMpnfNNSTaNU0z.rgtF0A.YTVSH3eJmOeJLN76pzuxNaLBSsf 7AFdpYHpJ21chTlugzeE6PBMMbLxqOJQtOfMrv1tgYnzXPND3a5Moiom0ONZSQ98odiHEhtYApPF DuU2.DWiB.g7Tnm1p_6fFqmSdiGm1EADtMcvasE84CVMNVF71yamwzl5s1abGJkkUIsBI7bL8LZ1 t0_PT6qR7cJby_eQRVph7K39NXaTuUrLKWToo8cgLNl86fSs1DoE0qChFEPeR72Y4IUXSOeGWXri 1rZqMyqpAnB4c5smNIHW5JrYXzBDhjfBIYIcnHse6g5On9Y2IfNcGC1m0mQL_CombtijGQdZqh1b OR1Y6m2frpbWE39j1c6YvEQ4iuMG719Z6NdpoicXdHttXNhlG4EfkjxGk9ZGEgAy_t6CFAHNvif7 Lid3rgeL7meSs3.AgFyH4Mkk3dkdCQ8uxqi7GBZUuFoCW6TvXJhTcrblpU.ZAbn2UUWMiDghZa2s 09aQVFrrvvL69Yf2J_P.2KtNhMMyKFaKyO7HCH_gdNVLaDuTjehbr47tnUfsA_o._igjK4btUVON LUfSzoxMd8xY_WA2gXhDPdjfD0a6L1iScqFpX75lRx.5ENfrn5Oos2I2ejSBbFbynLHmPe25mehT gEnscacxw4P71nwUs9DI6InzqnD_FgfdgUuler5Emmdnjm9MTkC01fZdjvu1nfUr_JoRPPvfweiO aPTCuCUtR0oCtMLDbZ5faErh3OOWm_kAsGgMIJ9V9OzZw8eSeuACIwR_nW3QKh2EBA9dEaiJDwxn QBDBtrTAMSrqghVXfNtVOAOQrFYMr4aZWGclAX89vSWa79itZBFzCsrwVY4Otj_B.a6zBw8PMTRy RsK5TLJOHaObDENQZLQNWypBr4KLu2T8c2rb2lZAXxgVrloB5UHx7JPmX_I76s5OsOxrOTMqQOJi UC_XppwU84eA_y4R.z6gAFdIbliNb8JIqKivI50AjIOcGOhRA34gSnsyLsDmSz3bTpMMx3NHlYqx dnrOUtl8FQKVBDouO.0RExZZjCRTDI8nWMNiZvGK0AgNwJ_ydWLzSfsRpIcya Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Apr 2020 22:09:41 +0000 Received: by smtp426.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c20f5f95d89f02fd50ad8655e308fcd7; Fri, 24 Apr 2020 22:09:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <20200424195953.GA6707@www.zefox.net> Date: Fri, 24 Apr 2020 15:09:35 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> References: <20200423162124.GA3583@www.zefox.net> <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> <20200424195953.GA6707@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4987d33gh1z4DJG X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.36 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.898,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]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.97)[-0.967,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[205.65.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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: (3.86), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), 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: Fri, 24 Apr 2020 22:09:45 -0000 On 2020-Apr-24, at 12:59, bob prohaska wrote: > On Thu, Apr 23, 2020 at 09:26:53PM -0700, Mark Millard wrote: >> On 2020-Apr-23, at 19:18, bob prohaska wrote: >>=20 >>> On Thu, Apr 23, 2020 at 06:16:14PM -0700, Mark Millard wrote: >>>> On 2020-Apr-23, at 16:32, bob prohaska = wrote: >>>>=20 >>>>> On Thu, Apr 23, 2020 at 03:24:57PM -0700, Mark Millard wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> For USB-only or for microsd card also in use, >>>>>> have you tried the equivalent of: >>>>>>=20 >>>>>> OK lsdev >>>>>>=20 >>>>> Another surprise. First time I tried, after some time idle: >>>>> OK lsdev >>>>> unknown command >>>>> but a simple=20 >>>>> ls >>>>> listed the contents of the root directory. Apparently the >>>>> drive was asleep after an idle timeout. >>>>>=20 >>>>> A second attempt at lsdev produced >>>>> OK lsdev >>>>> disk devices: >>>>> disk0: 250085377 X 512 blocks (removable) >>>>> disk0s1: DOS/Windows >>>>> disk0s2: FreeBSD >>>>> disk0s2a: FreeBSD UFS >>>>> disk0s2b: FreeBSD swap >>>>> disk1: 78140161 X 512 blocks >>>>> disk1s1: DOS/Windows >>>>> disk1s2: FreeBSD >>>>> disk1s2a: FreeBSD UFS >>>>> disk1s2b: FreeBSD swap >>>>> http: (unknown) >>>>> net devices: >>>>> net0: >>>>=20 >>>> Where both the microsd card (disk0) and >>>> the USB drive (disk1) set up via installing >>>> FreeBSD distributed .iso's, at least for >>>> how the file systems were created (even >>>> if somewhat adjusted later)? >>>>=20 >>> (thinking you meant "were both...") >>=20 >> True. Dumb typo. >>=20 >>> The answer is yes, both were written with dd from a downloaded .img = file. >>>=20 >>>> If yes, it may be that you have two instances >>>> of each of: >>>>=20 >>>> /dev/msdosfs/MSDOSBOOT >>>> /dev/ufs/rootfs >>>>=20 >>>> one per disk* for each. >>>>=20 >>> Yes, but if I'm quick enough stopping u-boot wouldn't >>> only one be read per boot attempt?=20 >>=20 >> If you stop the boot at: >>=20 >> Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 >>=20 >> then you are in u-boot/EFI before the FreeBSD >> loader is loaded/in-use. This is a very >> different context and does not involve or >> support the various types of labels or >> notations from FreeBSD. I assume you are >> not referring to this rather early stage >> of the boot sequence. >>=20 > There's a very early prompt from u-boot, which > must be invoked to stop booting the microSD. > That's the point where one gets the u-boot>=20 > prompt, and the place to run the usb reset and > run bootcmd_usb0 commands. The next chance to > intervene is at the pause before booting the > loaded kernel, which is where I was poking around. But the "run bootcmd_usb0" continues the boot and the FreeBSD loader still runs and there still is the finding of all the label information and the conflicting labeling resolution. The u-boot stage has no effect on this if the boot is continued. >> FreeBSD looks at disks before mounting them >> and it looks at partitions/slices before they >> are mounted. It creates the bindings for >> the labels of various types (msdosfs, ufs, >> gpt, label) before mounting is even possible. >> It does so across all the media present at >> the time. This is so all the labels are >> available to use to pick what to mount (in >> FreeBSD terms). But it means that the loader >> has to pick what to do about ambiguous labeling >> before you are involved. >>=20 >=20 > I suspect that had I not used a microSD with a > runnable FreeBSD installation the boot of USB > would have been trouble-free. =20 >=20 >> (I've no clue if it keeps just the first-find >> or last-find or what. But in the end a label >> identifies only one thing, not multiple things.) >>=20 >> There is meta-data on the media and in the >> partitions/slices/file-systems that indicates >> what labels to create. >>=20 > Are the labels created at each boot? I thought > they were defined at partitioning.=20 There is static information stored on the drive. There is run-time activity to use it to get the labeling behaviors. The run-time activity is certainly per-boot (and drive attachment/detachment while booted). There is code in FreeBSD's loader to create the behaviors. There is code in FreeBSD to create the behaviors. Only some types of labels are tied to partitioning. Some types of partitioning do not support labels. Some other types of labels are tied to file-systems, no matter if the partition type that the file system is in has partition/slice labeling or not. One type of label is tied to GEOM. It can be possible to have all 3 types of labels for the same content. Partitioning (when the partition type supports labels): gpart add -l gpart modify -l gpart show -l File Systems: newfs -L tunefs -L tunefs -p (will show the label assigned, if any) newfs_msdos -L GEOM (I'll only list the one command variant): glabel label >> (The kernel may well repeat doing some things >> that the loader had to do, for all I know. >> Refinding labels could be an example.) >>=20 >>>> These types of naming are expecting to have >>>=20 >>>> been set up with what is after the last / being >>>> a unique name relative to everything else >>>> potentially present at the same time. This >>>> means that two .iso installs would need >>>> to have been adjusted to make the names >>>> distinct before trying to use the media >>>> together. >>>>=20 >>>> If these names are duplicated, then use of >>>> the notations in /etc/fstab would be ambiguous >>>> for identifying the drives and I've no clue >>>> which instance wins --or if which wins is even >>>> stable. >>>>=20 >>>> For ufs, tunefs has an option for setting the >>>> file system label: >>>>=20 >>>> -L volname >>>> Add/modify an optional file system volume label. Legal >>>> characters are alphanumerics, dashes, and underscores. >>>>=20 >>>> Once the adjustment is seen (remount/reboot?), >>>> that should make: >>>>=20 >>>> /dev/ufs/... >>>>=20 >>>> change to the new name. >>>>=20 >>>> I'm only aware of file systsem creation-time setting >>>> for msdos via newfs_msdos : >>>>=20 >>>> -L label >>>> Volume label (up to 11 characters). The label should = consist of >>>> only those characters permitted in regular DOS (8+3) = filenames. >>>>=20 >>>> That should make >>>>=20 >>>> /dev/msdosfs/... >>>>=20 >>>> be the assigned name. But newfs_msdos would not >>>> preserve the contents of the file system that >>>> was present before (if any). >>>>=20 >>>> glabel can be used to assign labels that are >>>> independent of the file system and of the >>>> partition metadata, labels that would appear >>>> under /dev/label/ instead of under /dev/ufs/ >>>> or /dev/msdosfs/ or /dev/gpt/ . (gpt is not >>>> an option for MBR contexts.) >>>>=20 >>>>=20 >>>>>> and then used the naming convention shown in >>>>>> the output for any loader commands/settings >>>>>> instead of using FreeBSD-stage da0 based naming? >>>>>> (You might want to report what lsdev shows.) >>>>>>=20 >>>>>> Note: the disk0 and disk1 like prefixes are >>>>>> copied from the u-boot notations that the >>>>>> loader gets from u-boot, if I understand >>>>>> right. >>>>>>=20 >>>>>> Does your loader.conf do anything to control >>>>>> what is booted?=20 >>>>>=20 >>>>> Not in a way I recognize, but you might: >>>>> OK more /boot/loader.conf >>>>> *** FILE /boot/loader.conf BEGIN *** >>>>> # Configure USB OTG; see usb_template(4). >>>>> hw.usb.template=3D3 >>>>> umodem_load=3D"YES" >>>>> # Multiple console (serial+efi gop) enabled. >>>>> boot_multicons=3D"YES" >>>>> boot_serial=3D"YES" >>>>> # Disable the beastie menu and color >>>>> beastie_disable=3D"YES" >>>>> loader_color=3D"NO" >>>>> *** FILE /boot/loader.conf END *** >>>>=20 >>>> Nothing there to control what is booted. >>>>=20 >>>>> As Joanathan asked: what does >>>>>> your /etc/fstab have listed? (/etc/fstab should >>>>>> have FreeBSD notations, not loader device names.) >>>>>=20 >>>>> OK more /etc/fstab >>>>> *** FILE /etc/fstab BEGIN *** >>>>> # Custom /etc/fstab for FreeBSD embedded images >>>>> /dev/ufs/rootfs / ufs rw 1 1 >>>>> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 >>>>> tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m 0 0 >>>>> *** FILE /etc/fstab END *** >>>>> OK=20 >>>>=20 >>>> See earlier notes: each media may be defining >>>> what causes /dev/ufs/rootfs , leading to ambiguity. >>>> Similarly for /dev/msdosfs/MSDOSBOOT . >>>>=20 >>>> /etc/fstab should use notation that is a unique >>>> identification for each device. The media should >>>> have names assigned that are unique compared to >>>> anything else potentially connected at the same >>>> time if labeling style names are to be used. >>>>=20 >>>> Names like /dev/da* are not stable from boot to >>>> boot if multiple USB media are present at the >>>> same time: which media gets which da* name could >>>> vary from boot to boot. Using some form of unique >>>> label assignment is a way of avoiding this. >>>>=20 >>>> However, if you stick to only one USB drive >>>> being present, likely /dev/da0s2a would be >>>> a stable USB drive ufs file system reference >>>> for that context. Similarly for /dev/da0s1 >>>> being a stable reference to the USB msdosfs . >>>>=20 >>>> /dev/mmcsd0s1 would likely also be a stable >>>> microsd card msdosfs reference for your context. >>>> Similarly for /dev/mmcsd0s2a for being a stable >>>> reference to your microsd card ufs file system. >>>>=20 >>>> For now such notations may be better for your >>>> /etc/fstab file(s). >>>>=20 >>> That seems to be key. Using /dev/da... notation in /etc/fstab >>> on the USB device allows a successful boot. One very important >>> detail that I forgot was adding kern.cam.boot_delay=3D"20000" >>> to /boot/loader.conf. Otherwise boots are successful only if >>> something else (like me) delays the boot process. The erratic >>> results observed likely owe much to that oversight. >>=20 >> As I remember there is a RPi* way of increasing its >> 2 second wait for a device on a port to indicate it >> is present. If you end up with problems despite the >> FreeBSD stage materials indicating delays, you might >> have to have the RPi3 increase its delay. The RPi3 >> activity for this is before FreeBSD is involved, >> possibly even before u-boot is involved. >>=20 > There is, by adding an empty file named timeout to the > msdos partition holding bootcode.bin, but it only gives > six seconds. I think my hard drive needs about ten.=20 > That's why the first run of usb scan fails to see the > hard disk. Running usb reset at the u-boot prompt finds > the disk. >=20 >>>>>> Are there any other boot-contributing files that >>>>>> would be appropriate to show together in one >>>>>> message for review, including any on the >>>>>> msdos file system? >>>>>>=20 >>>>>=20 >>>>> I don't know how to answer that question. Since the machine >>>>> has gotten to loader and it's looking at the USB drive it's >>>>> very tempting to think the msdos part is done. I'll admit >>>>> that names like /dev/ufs/rootfs seem rather obscure. >>>>> Are they required for RAID? >>>>>=20 >>>>=20 >>>> An example: does either media have in its msdos file >>>> system: /EFI/FreeBSD/loader.env ? If yes, are the >>>> settings present in loader.env that contribute to what >>>> boots? >>>>=20 >>> Apparently not by default; nothing in microSD, but I added=20 >>> a /boot/loader.env to the USB device, holding rootdev=3Ddisk1p2: >>> It didn't seem to affect booting behavior, at least not on >>> the first try.=20 >>=20 >> There is no reason to have a /boot/loader.env as far >> as I know. It would be ignored: that is the wrong >> place for the file. >>=20 > Indeed, my mistake. And, in hindsight, probably unhelpful. >=20 >> EFI/FreeBSD/loader.env in the msdos file system is >> a way to supply input to EFI/BOOT/bootaa64.efi (the >> FreeBSD loader) before the loader tries to find the >> FreeBSD /boot it is going to use --and before you >> can type to the loader. That is why Jonathan was >> indicating to create the rootdev assignment there. >> (That rootdev is then used to find the /boot to use, >> as I understand things.) >>=20 >>>> (That is something from Jonathan's exchanges with >>>> you.) >>>>=20 >>>>=20 >>>> A separate question is: Other than bootcode.bin , >>>> are the contents in the two msdos files systems >>>> identical? >>>>=20 >>>>=20 >>> Clearly not. Those on the the USB device are about six months >>> newer and different in size. >>=20 >> You may want to make your msdosfs content matching and >> keep them matching as they progress, at least for >> anything that you do not have a specific reason to make >> a distinction for. (Avoids odd variations in behavior.) >>=20 >>> For now it looks as if the immediate problem is solved. Both >>> microSD and USB storage boot and run.=20 >>=20 >> Does that wording mean that you got USB-only to >> work too? >>=20 > Yes, bootstrapping _through_ microSD.=20 Now that using both the microsd card and USB drive as a pair to boot has been shown to work, have you made the USB drive match what is used on from the microsd card (such as the msdos file system) and checked what the USB drive does without involving the microsd card? (Although, I wonder if the "10 sec" issue ends up involved, possibly blocking this way of working.) >> Now that you can boot, you should be able to show >> the ufs labels (and more) with: >>=20 >> tunefs -p /dev/mmcsd0s2a >> tunefs -p /dev/da0s2a >>=20 >> The outputs will each have a line starting with: >>=20 >> tunefs: volume label: (-L) >>=20 >> and ending with the label (or empty for no label). >>=20 >> If the two volume labels match, you should >> change at least one such that they are >> distinct. After that future boots should >> end up with two separate /dev/ufs/* names >> that you can use to pick the ufs file system >> with. The -L is the command line option >> involved in specifying a volume/file-system >> label. >>=20 > Both microSD and USB root filesystems have the same > label. That seems to be the crux of the problem. > For now hard-coding device file names in /etc/fstab > is probably the most idiot-proof method.=20 For UFS tunefs -l can be used to change the label. It might have to be when the file system chanberd is not mounted/live. The msdosfs labeling is messier to deal with. >> Unfortunately, I'm not aware of anything >> directly in FreeBSD analogous to "tunefs -p" >> or to "tunefs -L NAME . . .". for the msdos >> file systems. There seems to be only >> newfs_msdos --which would wipe out the existing >> msdosfs content by creating a new file system. >> But it does have a -L option for indicating the >> volume/file-system label to put in place. >>=20 >> May be after doing such the content of the >> other msdos file system couple be copied into >> the new/empty file system. (Not via dd. dd'ing >> the slice would replace the label too, not just >> the content placed in the file system.) >=20 > Once, a long time ago, FreeBSD had a boot manager > that lived, I think, in the msdos partition of each > bootable hard disk. On startup, it presented a menu, > something like > 1 msdos > 2 freebsd > 3 next disk in the boot order > defaulting to whatever was last selected. I think > that recollection gave me false hope that dual-booting > a Pi would be much simpler than it turned out. Ahh. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Apr 25 00:17:47 2020 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 7BDD12C6AD9 for ; Sat, 25 Apr 2020 00:17:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 498BSm4KSvz4KNb for ; Sat, 25 Apr 2020 00:17:43 +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 03P0HjCx007385 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Apr 2020 17:17:46 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03P0HixT007380; Fri, 24 Apr 2020 17:17:44 -0700 (PDT) (envelope-from fbsd) Date: Fri, 24 Apr 2020 17:17:43 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200425001743.GA7044@www.zefox.net> References: <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> <20200424195953.GA6707@www.zefox.net> <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> X-Rspamd-Queue-Id: 498BSm4KSvz4KNb 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 [1.81 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.02)[-0.015,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.22), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.13)[-0.128,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(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: Sat, 25 Apr 2020 00:17:47 -0000 On Fri, Apr 24, 2020 at 03:09:35PM -0700, Mark Millard wrote: [huge snip, hope nothing vital was lost] > > Now that using both the microsd card and USB drive > as a pair to boot has been shown to work, have you > made the USB drive match what is used on from > the microsd card (such as the msdos file system) > and checked what the USB drive does without > involving the microsd card? > > (Although, I wonder if the "10 sec" issue ends up > involved, possibly blocking this way of working.) No. If there's no microSD at all the Pi3B is simply inert on power-up. No rainbow screen, no serial console, nothing. The OTP boot-from-usb bit is set according to Raspbian, so mine is one of the Pi3's that requires a microSD card. If there's no microSD filesystem to fall back to, maybe u-boot would keep trying until the USB hard drive woke up. Somebody also mentioned recompiling u-boot with a longer timeout, not an unreasonable step. For now I'll declare victory and retreat 8-) I gather the Raspberry Pi Foundation didn't more widely publicise the boot-from-usb feature because it didn't work with a too-large fraction of USB storage devices. Having now seen the exercise in person, I understand their motives. There was absolutely no chance of success without the vast amount of help I got on this list. With my thanks, bob prohaska From owner-freebsd-arm@freebsd.org Sat Apr 25 00:47:41 2020 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 DF6012C725F for ; Sat, 25 Apr 2020 00:47:41 +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 498C7J1sgWz4LYG for ; Sat, 25 Apr 2020 00:47:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Ik5U40YVM1mJbwbAVA5I7GYU2L0yYtKc.SLopEB5L2wzTQrazs9v_nImP6jjnZC 7VsMf5iyzwql.XGUWNwZ.8u0mwbZ6lo714exos_mRPjhjZLqT.bO16zUmZFAJnZwZvWY.hladbRf CzTSK2gN4P61hq1G5ksMmhg0a0YUgglF4rnzC9ObNczEq6aUYG.O1Bct5H.6OHhLr6PMMXQ3Dm8N 555CxTBg8kl0SvUN691.r6kxgIrXVeor7TJ_RCy2X_ks.VGMs3R5xEaGG_vrs9c5nEIqqfV4Irw6 zKF0ZsJPjHx4w8yBDfVrZlh.80nQ3LzRmjVhIZDxJh1jzZWOUO7CCSPTRaMdIbEm9SSDzt6Uuf5e N65JcRDFOALH9pJ7ksch_pNE3cxtCarh0eSFZ9dm7k2tFIdOOhrGFKApNp.vcCyxxCmGpRyVn5o1 izJNxdW5obrzB6b69KZE_XBJDTub4Gv8KrKJ6ytfvGAB8P5LbWBgFGb.zaRyUeeu0hb.wRLORprr 8HHiEJmwwQJ0BrBdHyxZImz_6XhEDWxnMOkmLQT47SJbEQ_bFN_isXGjWr9h2FGcZChPrCQDM521 M0xTuPeBBUK2jdsuga1COyqYUX4mX57EpLUL.EOd6nuKHdsyiEb6aXMWYWwhePUlc.4iHsuOyS7Q yVR69Tnz.DPNAoh6SBJ87c9q9EWgIVK_SqclcY.gXaXFYNwpqR9DUMphWxQcKnR9gzkYY85j.D9x 2tYjsoCv.x0.KhjKYloH5mAP5Uibbn00N8EzO424zKFsykltR6CYxSvRNXZOLxaKe5uryoi4_4qB iiHWvxBSH5yovXuXeVHorjj5HXUQmCybydtMaP1ZD8FnK7NTMCyLsux2B45Xs0ApdMi6xQAo9OGM 9K4bpp7djJ1E2ufmHTRaM2A6CSC4APmHz8p9ny_SO8CdZvSJyy47lDS6r3AUzVtYuUBGVjYwR.Na oI.YK6Prr_Gqf0YnxySMNsE9vmHVM05oovIz_dk48jUAlQ9jI6GMNAc03IbeSEFw0h2oi_4jprFA seKyNsUoQ5EQ.M1rZl22dEFzUh_M3zfu1NrMoO4OLUSR0ELBsKAgBJxKdRm1tWooZephJS7bfDdo v2UX.FZv_9FMxcadiPcsLhjcx1k12hLuOeo61ocPQuQmYghKw_zwtqfM2YlfIzER7cRzLzr_Pju2 CUHte5kdCdum0gC2B_Glxovbo3PRwfsJSjlsITG0A6sWpghcCxcnzPWnNJ5rQ9hmIVkxKE5V6QX7 Jtw4AFCmRADONdYef6I_cDmIWy8xdLj7DrViiAFrCzwTIRD53u6MUBSSho6MJ1RFEVy3nHHS6HIi SveAK32ubp6jqWgi.yjJK75FEET9dSEGVF4jDUNW6kJUAu9cu7aUj9PkumWuW_Z_ZaaFsTdMX7yo lk.CzNt_S9U2ymzoQaiva Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Apr 2020 00:47:38 +0000 Received: by smtp405.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4be60310d0dfb85635791cd909bba4bf; Sat, 25 Apr 2020 00:47:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <20200425001743.GA7044@www.zefox.net> Date: Fri, 24 Apr 2020 17:47:33 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <5A943B45-FE58-452D-BBC5-534756782276@yahoo.com> References: <8D1F6A8D-4910-4C1E-8EB5-2F5F89E31120@yahoo.com> <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> <20200424195953.GA6707@www.zefox.net> <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> <20200425001743.GA7044@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498C7J1sgWz4LYG X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.971,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]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.995,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[83.65.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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: (1.84), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), 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: Sat, 25 Apr 2020 00:47:41 -0000 On 2020-Apr-24, at 17:17, bob prohaska wrote: > On Fri, Apr 24, 2020 at 03:09:35PM -0700, Mark Millard wrote: > [huge snip, hope nothing vital was lost] >> >> Now that using both the microsd card and USB drive >> as a pair to boot has been shown to work, have you >> made the USB drive match what is used on from >> the microsd card (such as the msdos file system) >> and checked what the USB drive does without >> involving the microsd card? >> >> (Although, I wonder if the "10 sec" issue ends up >> involved, possibly blocking this way of working.) > > No. If there's no microSD at all the Pi3B is simply inert > on power-up. No rainbow screen, no serial console, nothing. > The OTP boot-from-usb bit is set according to Raspbian, > so mine is one of the Pi3's that requires a microSD card. Is the RPi3 attached to a powered USB hub? Directly to the USB drive? Do both ways behave the same absent a a microsd card? (I presume the 6 sec configuration in both cses.) A different, probably better, experiment is suggested later, one that avoids this USB drive. > If there's no microSD filesystem to fall back to, maybe > u-boot would keep trying until the USB hard drive woke up. u-boot would have to load from someplace and be started first in order to be involved at all. The initial code is not u-boot code but code internal to the SoC (internal firmware). > Somebody also mentioned recompiling u-boot with a longer > timeout, not an unreasonable step. For now I'll declare > victory and retreat 8-) Such would not change the internal firmware code involved in looking for msdos file system(s) on mass storage devices with a bootcode.bin in the proper place. If that code does not find the device in its time frame, bootcode.bin is not found and, so, not used. Failing to find such a bootcode.bin means using the older, buggier code that is the reset of the internal firmware. This code is more likely to have problems with drives. > I gather the Raspberry Pi Foundation didn't more widely > publicise the boot-from-usb feature because it didn't work > with a too-large fraction of USB storage devices. Which leads to an alternate experiment: a different USB "drive", one without the long wait. Technically this could be a USB microsd card reader with the media you can boot from the microsd card slot: That might well prove that you can boot without use of the microsd card slot so long as the USB drive is compatibile. If yes: Then it becomes a case of selecting an appropriate USB drive and getting it set up. > Having > now seen the exercise in person, I understand their motives. > There was absolutely no chance of success without the vast > amount of help I got on this list. Given the above possible experiment, are you sure that you want to give up now? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Apr 25 03:00:08 2020 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 484962C9667 for ; Sat, 25 Apr 2020 03:00:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 498G471YFSz4RLl for ; Sat, 25 Apr 2020 03:00:06 +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 03P309QG008692 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Apr 2020 20:00:09 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03P3082k008691; Fri, 24 Apr 2020 20:00:08 -0700 (PDT) (envelope-from fbsd) Date: Fri, 24 Apr 2020 20:00:08 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200425030008.GB7044@www.zefox.net> References: <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> <20200424195953.GA6707@www.zefox.net> <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> <20200425001743.GA7044@www.zefox.net> <5A943B45-FE58-452D-BBC5-534756782276@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A943B45-FE58-452D-BBC5-534756782276@yahoo.com> X-Rspamd-Queue-Id: 498G471YFSz4RLl 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 [2.05 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.22), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.09)[0.087,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.01)[0.011,0]; 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: Sat, 25 Apr 2020 03:00:08 -0000 On Fri, Apr 24, 2020 at 05:47:33PM -0700, Mark Millard wrote: > On 2020-Apr-24, at 17:17, bob prohaska wrote: > > > On Fri, Apr 24, 2020 at 03:09:35PM -0700, Mark Millard wrote: > > [huge snip, hope nothing vital was lost] > >> > >> Now that using both the microsd card and USB drive > >> as a pair to boot has been shown to work, have you > >> made the USB drive match what is used on from > >> the microsd card (such as the msdos file system) > >> and checked what the USB drive does without > >> involving the microsd card? > >> > >> (Although, I wonder if the "10 sec" issue ends up > >> involved, possibly blocking this way of working.) > > > > No. If there's no microSD at all the Pi3B is simply inert > > on power-up. No rainbow screen, no serial console, nothing. > > The OTP boot-from-usb bit is set according to Raspbian, > > so mine is one of the Pi3's that requires a microSD card. > > Is the RPi3 attached to a powered USB hub? Yes. > Directly to the USB drive? Tried that long ago, the power supply on the Pi couldn't cope. No obvious reason to think it'd be different now. > A different, probably better, experiment is suggested > later, one that avoids this USB drive. > > > If there's no microSD filesystem to fall back to, maybe > > u-boot would keep trying until the USB hard drive woke up. > > u-boot would have to load from someplace and be started > first in order to be involved at all. The initial code > is not u-boot code but code internal to the SoC (internal > firmware). The Pi3 is able to load bootcode.bin (alone) from the microSD promptly. Then u-boot can rattle the USB drive. If there's nothing else to boot on the microSD it might keep trying, how long I don't know. > > > Somebody also mentioned recompiling u-boot with a longer > > timeout, not an unreasonable step. For now I'll declare > > victory and retreat 8-) > > Such would not change the internal firmware code involved > in looking for msdos file system(s) on mass storage devices > with a bootcode.bin in the proper place. Thus the need for a microSD with a customizable bootcode.bin. > If that code > does not find the device in its time frame, bootcode.bin > is not found and, so, not used. > > Failing to find such a bootcode.bin means using the older, > buggier code that is the reset of the internal firmware. > This code is more likely to have problems with drives. > Indeed, on mine it does not appear to even start. AIUI, a Pi set up to boot without a microSD card should at least flash the rainbow screen. Mine does nothing. > > I gather the Raspberry Pi Foundation didn't more widely > > publicise the boot-from-usb feature because it didn't work > > with a too-large fraction of USB storage devices. > > Which leads to an alternate experiment: a different USB > "drive", one without the long wait. > > Technically this could be a USB microsd card reader > with the media you can boot from the microsd card > slot: That might well prove that you can boot without > use of the microsd card slot so long as the USB drive > is compatibile. If yes: Then it becomes a case of > selecting an appropriate USB drive and getting it set > up. > Is there some larger question that I'm not recognizing? I've tried a usb flash drive with FreeBSD on it a couple of times with no microSD. Nothing happened, not even an output on the serial console. No powered hub in the loop. > > Having > > now seen the exercise in person, I understand their motives. > > There was absolutely no chance of success without the vast > > amount of help I got on this list. > > Given the above possible experiment, are you sure that > you want to give up now? What is the question to be answered? I wanted to see if buildworld works any better on a mechanical disk than a well-used microSD card. So far, the answer appears to be yes: Not a single "indefinite wait...." warning even when ~900 megs of swap is in use and the machine is crawling at around 70% idle. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sat Apr 25 04:32:22 2020 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 17B2D2CB22D for ; Sat, 25 Apr 2020 04:32:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 498J6X3jZ7z4WZ5 for ; Sat, 25 Apr 2020 04:32:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: UHfXZu4VM1n7U_CyOasLwiWPsmq3pmJ6EFkZV58qltYiqweJZbVYUvxAttApIpC Rd_9MoY8A8Qx2jwVoZEwMGXUxlQU6Fc._wiwgCX5iX1fK4yrLrWaYJ8N2f9_CMDlYhDlOU3h3f0Z Syd.YECT8IotMirPgKh6lIUFL0vgP5G8MbVx8DFrYGpOc0CtyDeYUeauHCLmcU2ZzZXjLzLOhARo ZThQChDZKvhLBFqnAi82ZAIq6eyNpV5jHAgW1IBTt9a.MiQ0yh70W_fCukfXgLAFOhUtkFoV8dfH _luse2wviJriIBp0C8BMBXNSE5QB6hOKFH9N6r0z8qHsyWbdiOfl9Kzli1ZdHSe9mVKTRD.lFb5K XpXUA6va9A8db8PuuTBdbFmfYSjQfPbCenaH.1GY6O5wip1efIvOJgyYvea9nf9iX2GG8W4pAtZ5 VAB24T_7HZW80fCFOtygkrVsbBrnUQg_qTDrewZztgjCnr_oTNjX3OT0ULqujRT4b0i.9TOJ8rYE vytAFWfpVCDhh7xRP977Qg19dsHbZPAjPyOEj2AMj2Fm8vdHtxWMv1k09lwYKytIj1lBzFMg.1iE hkkyN3iXMmoBGpfyjtzP3h28gsvA3bE4XF8ItAfOuCQ2t636zo8_X.ufknsgoVP8pqJp7vw187zZ SncTsJSh_5vP7ix9WtBG2vVuM6qMkDp8u5MASfwzh7_A4l4BdfTmMnFPzosMlYNXr0WSitoSuhP2 4yLzZunabouI1ObH3HqvdnJVqvHoqcRw_I7WG7R3cmlPPeZDIifdbWL9_w.C5V7KODSeW5d7mYAV B2aS8mnQyQ.3Z_G9lzn24l0UqbANshoXElSu0ZqVICAdH4HFoXOTgkIFFNqG7l4tE65RciZIXYP4 YIlPKDW4tlju4d.d6IPe_ap55FF5jBj9tkWcpfuuxu98LwKXEKvjEtmUFw466Upchv9KB4ZIhVsP HEIYk3xNuXpsDsGtMoL_XJ0uNljBXu3ZN0DA8unIL4kho5TWOoF4E2RQcbWDxkMLSQe4YMOb7ifL RDgMcv_FK.BX1QI5G4VVHa7vBnYH6VOGV6UstNxRof6h7uIMs9iSzSXKddwMho59loEbG.h3Nim0 Mw8.pXGPjoT7Ztyl6xybJS7T4oEGyl6T8wDzi4MNPgfRqB98HDsh5eDKaLJTIWRq4imH3HiW5aa1 65FTyyaJNqQOHP8SFABN13SubNd4j1l6mtheJVwCzUrPSdhUVpeTVUieO0ldpjWjQh147GPEwxzc qrwzKqudkFejmyxOgm79YfEUPbqGYi6h1J1i.M13TeGBhuES85MEFbJ5COSFSIaXAdNvIibqtWuX UnZThHabiCC7V4sn07hi5em4TY.nY0KYfWkAK.erCIzjbVIquopSJJ7cX..mFvhzvEv57W3PvrbE CCaAQfE.eVWT5UhNJUeh7nA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Apr 2020 04:32:18 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9f558f96d4e82e367d7bdf2e7dfdc68c; Sat, 25 Apr 2020 04:32:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Booting from USB on RPI3 From: Mark Millard In-Reply-To: <20200425030008.GB7044@www.zefox.net> Date: Fri, 24 Apr 2020 21:32:13 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <592BD226-145D-4A89-81E4-257FB20624FE@yahoo.com> References: <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> <20200424195953.GA6707@www.zefox.net> <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> <20200425001743.GA7044@www.zefox.net> <5A943B45-FE58-452D-BBC5-534756782276@yahoo.com> <20200425030008.GB7044@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498J6X3jZ7z4WZ5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.16 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.78)[-0.780,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]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.88)[-0.880,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[204.68.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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: (7.37), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), 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: Sat, 25 Apr 2020 04:32:22 -0000 On 2020-Apr-24, at 20:00, bob prohaska wrote: > On Fri, Apr 24, 2020 at 05:47:33PM -0700, Mark Millard wrote: >> On 2020-Apr-24, at 17:17, bob prohaska wrote: >>=20 >>> On Fri, Apr 24, 2020 at 03:09:35PM -0700, Mark Millard wrote: >>> [huge snip, hope nothing vital was lost] >>>>=20 >>>> Now that using both the microsd card and USB drive >>>> as a pair to boot has been shown to work, have you >>>> made the USB drive match what is used on from >>>> the microsd card (such as the msdos file system) >>>> and checked what the USB drive does without >>>> involving the microsd card? >>>>=20 >>>> (Although, I wonder if the "10 sec" issue ends up >>>> involved, possibly blocking this way of working.) >>>=20 >>> No. If there's no microSD at all the Pi3B is simply inert >>> on power-up. No rainbow screen, no serial console, nothing.=20 >>> The OTP boot-from-usb bit is set according to Raspbian, >>> so mine is one of the Pi3's that requires a microSD card. >>=20 >> Is the RPi3 attached to a powered USB hub?=20 > Yes. >=20 >> Directly to the USB drive?=20 > Tried that long ago, the power supply on the Pi couldn't cope. > No obvious reason to think it'd be different now. Okay. >> A different, probably better, experiment is suggested >> later, one that avoids this USB drive. >>=20 >>> If there's no microSD filesystem to fall back to, maybe >>> u-boot would keep trying until the USB hard drive woke up. >>=20 >> u-boot would have to load from someplace and be started >> first in order to be involved at all. The initial code >> is not u-boot code but code internal to the SoC (internal >> firmware). > The Pi3 is able to load bootcode.bin (alone) from the=20 > microSD promptly. Then u-boot can rattle the USB drive.=20 > If there's nothing else to boot on the microSD it might=20 > keep trying, how long I don't know.=20 Ahh. I see now what you were referring to. >>=20 >>> Somebody also mentioned recompiling u-boot with a longer=20 >>> timeout, not an unreasonable step. For now I'll declare=20 >>> victory and retreat 8-) >>=20 >> Such would not change the internal firmware code involved >> in looking for msdos file system(s) on mass storage devices >> with a bootcode.bin in the proper place.=20 > Thus the need for a microSD with a customizable bootcode.bin. Understood. >> If that code >> does not find the device in its time frame, bootcode.bin >> is not found and, so, not used. >>=20 >> Failing to find such a bootcode.bin means using the older, >> buggier code that is the reset of the internal firmware. >> This code is more likely to have problems with drives. >>=20 > Indeed, on mine it does not appear to even start. AIUI, > a Pi set up to boot without a microSD card should at least > flash the rainbow screen. Mine does nothing. That is not what: https://www.raspberrypi.org/forums/viewtopic.php?f=3D28&t=3D58151 reports relative to what causes the rainbow screen=20 on the RPi3*'s (and when). Code from start.elf is what draws the rainbow screen (as part of testing the GPU). start.elf comes after bootcode.bin . Here is the sequencing documented that leads to the rainbow screen: QUOTE . . . uses its MMC hardware to attempt to read a file from a MMC = compatible device. On the Pi, this is the SD card; the file should be on = a FAT16 or FAT32-compatible filing system, and is called bootcode.bin. = At this point, the ARM CPU is still in reset, so the contents of = bootcode.bin are executed by the dedicated processor of the GPU: this = code has more smarts, and can read the next file called start.elf, which = in turn reads and interprets config.txt. It configures things like = memory and Video/HDMI modes, console frame buffers, tests the GPU = (resulting in the "rainbow screen"), and then handles the loading and = configuring of the Linux Kernel (addresses, device tree, uart/console = baud rates and suchlike). Only after this is the ARM CPU started, to = execute the kernel code. END QUOTE (For FreeBSD that "kernel code" above is not the FreeBSD kernel yet: more stages before reaching that point.) Early on the LEDs are what needs to be looked at: QUOTE Error ACT LED patterns (for RPI up-to but not including RPI4 While booting, the ACT LED should blink in an irregular pattern, = indicating that it is reading from the card. If it starts blinking in a = regular, Morse code-like pattern, then it is signalling an error.=20 If it blinks just once, it could be that you have a Raspberry Pi with = SDRAM from Micron. If the processor has a logo showing an M with an = orbit around it, then using the latest software should solve your = problem. Also make sure you are using a 4GB SD card, as a 2GB won't work = in this particular case. These are the other patterns that the ACT LED might show during a failed = boot, together with their meanings (the below blink codes are NOT valid = for a RPI4, read the RPI4 section for ACT LED flash messages!): * 3 flashes: start.elf not found * 4 flashes: start.elf not launch-able (corrupt) See below: (not valid = for RPI4! On an RPI4 four flashes means no boot code found!) * 7 flashes: kernel.img not found * 8 flashes: SDRAM not recognized. You need newer bootcode.bin/start.elf = firmware, or your SDRAM is damaged END QUOTE (Same URL.) >>> I gather the Raspberry Pi Foundation didn't more widely=20 >>> publicise the boot-from-usb feature because it didn't work=20 >>> with a too-large fraction of USB storage devices. >>=20 >> Which leads to an alternate experiment: a different USB >> "drive", one without the long wait. >>=20 >> Technically this could be a USB microsd card reader >> with the media you can boot from the microsd card >> slot: That might well prove that you can boot without >> use of the microsd card slot so long as the USB drive >> is compatibile. If yes: Then it becomes a case of >> selecting an appropriate USB drive and getting it set >> up. >>=20 >=20 > Is there some larger question that I'm not recognizing? > I've tried a usb flash drive with FreeBSD on it a couple > of times with no microSD. I did not remember that you had done so. That would be approximately what I was suggesting (depending on what materials were on the USB flash drive). > Nothing happened, not even an > output on the serial console. No powered hub in the loop. Got it. >>> Having=20 >>> now seen the exercise in person, I understand their motives.=20 >>> There was absolutely no chance of success without the vast >>> amount of help I got on this list. =20 >>=20 >> Given the above possible experiment, are you sure that >> you want to give up now?=20 >=20 > What is the question to be answered?=20 Apparently you had already done analogous experiments. So my idea provided little or nothing new. > I wanted to see if buildworld works any better on a=20 > mechanical disk than a well-used microSD card. So far,=20 > the answer appears to be yes: Not a single "indefinite=20 > wait...." warning even when ~900 megs of swap is in=20 > use and the machine is crawling at around 70% idle. =20 Cool. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Apr 25 07:43:38 2020 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 118342CE12D for ; Sat, 25 Apr 2020 07:43:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 498NMD6bKWz4dyy for ; Sat, 25 Apr 2020 07:43:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: pq3WAaMVM1mI_720qkN5tuXK8o1qbyZj8_3mq_YVwY0nIGSMmUEnpVu0tkDN2cM 9m4PLp_A8qgURqCdVgg6MVJDxOu_G9871dXnV7BVu.dt2zYVnry_FcnwwCeVzz8FSNUZEGP66rLh colZHhH2M1HD8rpckqigsPm2ie0PzqFcRu3a8VlJTNcuacwuQdWPHYVy9KnJAa15Gw2fHQPc6IEc 5hdX0XDg.Le9ksx0WKgaeAKt2V5XSI.bEpIZRBXW9CmXINfZZWaNMsNC0xlFAA7SjOijM7Injufc 14SyWqfRZs.QMPIE.OwPMJs6ijvXPUY8mXdQ8QDTtqOjIBFOmLbAHK.7j0D_RMsYpQgdBFocSIVZ CWJh3lY4oKaFuHATFrc7l9_tOYv18NxUCVKPr3n2PZta2oPBRVtmTNTJj7TZ0XWgPYgfncYeP0Gk JrbgRb7u5HWQ9L0PI4T5QjpEsTC26.RfVL0_WBbF9nQfciQp8Z49zn_riBXj1O3L8BsCZ4NcubTw MZ1gkrx1myFhbA8OzSbChC0gS_8Jp3OrAN7ubzNEvB.8bxnB2Qv8X1CsnooIrgSZyW6S_oJusAGE UtIS9vpFxztF_u3nqR.qIvZUyeZxg_ZdSOI.stOVxNZB013IUgjaKCzMooOqsWLjtakYQutKs_cw SOXdyCyFxvixPnS8WKd57p8_f1l7bV.4BWY.c73sW6dKs28vAJ.yOAW0ksfFKRvd9owkIfW_s6oL cLfuwbHk7l5WC_EhUjPtpK_NmSLIcYVJyyE1aFsfxprwT_kwVhHiWeGRnzadKb7kSvb.BMkl1ebO F5wewkwh4wWaKOiq20n8pS7zEVOfynpB_W53iqHM3AzpGONOpkj78URsPB2AWkUOcuIQf7gEXxAH Mr4LFXazU0gtB7VybXkHfZ74Dgiw0D2xA_iOeWeCZOZM1VFmZDOQSdnsG95TFKTgrz2mLIYFB.C8 7avcCOjuyoPySvYEQ9W8PfKfr2_8E.9lc1Wbdke3NoxcKsz.KlR_4WCns9N0Fqj.aNHOk6yvUs0K AfN5s8qdEtYQ7TMPcgwkxEcmm4ZbWXCKefFperkSFCpdY4WxZTG_QstAUKisnr6lzt4XuQOxmfad 8x5n7I0d63VWApTEB4iJFdO8bV2ChZxcCTTVGTjjRw0aiLq9ZQGkDlR8jMgphmtspiM3VYatv1Nz B0k4LKD0hFH460TFYNg_.zt_R56ZABS1xC_Zz.LDDE.tpTtwSayk0EUDLzWbW2EKOS_x0PA.p9ks eJutiyHDUym6aog0s5YdjQTV0r3oRT.FI2qQL.BIS9TWoHnqxH8P_7Ptfdxyrijv0NlC5nzBSsGA CvNrqcSsNIdsPZzPrT07hgomwv9Uf5myLGNKscCkNVojk5..mrMBZN0Z6NYJ7LtwrlVnK1njMdGi 7tuSR.tBfNISixIaPbXgPCdUVAxB0MjK.VZAD7G7EtD0H_MnKCWxVXSfZ4cOrjlvRrOqMG63RgtB j4O1LWQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Apr 2020 07:43:34 +0000 Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7ff9b3cebe4989a42e138148803b9d5c; Sat, 25 Apr 2020 07:43:29 +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.4 \(3608.80.23.2.2\)) Subject: Applying distribution patches for u-boot-rpi4-2020.04 fails during build (poudriere-devel context) Message-Id: <2AB77D60-F960-4C84-A9DC-8C2873A5C1FE@yahoo.com> Date: Sat, 25 Apr 2020 00:43:27 -0700 To: freebsd-arm , freebsd-uboot@freebsd.org, FreeBSD ports X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <2AB77D60-F960-4C84-A9DC-8C2873A5C1FE.ref@yahoo.com> X-Rspamd-Queue-Id: 498NMD6bKWz4dyy X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.38 / 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)[]; 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.91)[-0.914,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.97)[-0.969,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.82), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[146.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: Sat, 25 Apr 2020 07:43:38 -0000 =46rom the log file: =3D=3D=3D> Patching for u-boot-rpi4-2020.04 =3D=3D=3D> Applying distribution patches for u-boot-rpi4-2020.04 2 out of 2 hunks failed--saving rejects to = scripts/dtc/libfdt/fdt_addresses.c.rej *** Error code 1 Details: amd64 head -r360289 context. Ports head -r532914 context. # svnlite status /usr/ports/sysutils/u-boot-rpi4/ #=20 # svnlite status /usr/ports/sysutils/u-boot-master/ #=20 # more = /wrkdirs/usr/ports/sysutils/u-boot-rpi4/work/u-boot-2020.04/scripts/dtc/li= bfdt/fdt_addresses.c.rej @@ -1,6 +1,7 @@ /* * libfdt - Flat Device Tree manipulation * Copyright (C) 2014 David Gibson + * Copyright (C) 2018 embedded brains GmbH * * libfdt is dual licensed: you can use it either under the terms of * the GPL, or the BSD license, at your option. @@ -55,42 +56,32 @@ =20 #include "libfdt_internal.h" =20 -int fdt_address_cells(const void *fdt, int nodeoffset) +static int fdt_cells(const void *fdt, int nodeoffset, const char *name) { - const fdt32_t *ac; + const fdt32_t *c; int val; int len; =20 - ac =3D fdt_getprop(fdt, nodeoffset, "#address-cells", &len); - if (!ac) + c =3D fdt_getprop(fdt, nodeoffset, name, &len); + if (!c) return 2; =20 - if (len !=3D sizeof(*ac)) + if (len !=3D sizeof(*c)) return -FDT_ERR_BADNCELLS; =20 - val =3D fdt32_to_cpu(*ac); + val =3D fdt32_to_cpu(*c); if ((val <=3D 0) || (val > FDT_MAX_NCELLS)) return -FDT_ERR_BADNCELLS; =20 return val; } =20 -int fdt_size_cells(const void *fdt, int nodeoffset) +int fdt_address_cells(const void *fdt, int nodeoffset) { - const fdt32_t *sc; - int val; - int len; - - sc =3D fdt_getprop(fdt, nodeoffset, "#size-cells", &len); - if (!sc) - return 2; - - if (len !=3D sizeof(*sc)) - return -FDT_ERR_BADNCELLS; - - val =3D fdt32_to_cpu(*sc); - if ((val < 0) || (val > FDT_MAX_NCELLS)) - return -FDT_ERR_BADNCELLS; + return fdt_cells(fdt, nodeoffset, "#address-cells"); +} =20 - return val; +int fdt_size_cells(const void *fdt, int nodeoffset) +{ + return fdt_cells(fdt, nodeoffset, "#size-cells"); } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Apr 25 08:57:01 2020 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 3A4552CFA64; Sat, 25 Apr 2020 08:57:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 498Pzv59Ftz3DnQ; Sat, 25 Apr 2020 08:56:59 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1587805008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u9K8eeTJFuhvLfoMHba4laop/WNPzGGRyGSWkglN32k=; b=NBFnay/G4WW/niXQPXXgpOIhufx6h2bSF6FBKl4xXPuwsvDEqCkEfm7rilCvwwHCmP2UpI Efls98eBT3e8WeHwiLJE6Y0wSKoNpRVRQT264AgrOXnrVtH4Fuv+TYRwwfAWpxt+AR7FQe gEW8Xf5zWQ80xtfiNkvVfNbnkki3jp4= Received: from tails.home (lfbn-idf2-1-900-181.w86-238.abo.wanadoo.fr [86.238.131.181]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 26a35bda (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 25 Apr 2020 08:56:48 +0000 (UTC) Date: Sat, 25 Apr 2020 10:56:47 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Mark Millard via freebsd-uboot , freebsd-arm , FreeBSD ports Subject: Re: Applying distribution patches for u-boot-rpi4-2020.04 fails during build (poudriere-devel context) Message-Id: <20200425105647.1406a2357cb0b825e19696a5@bidouilliste.com> In-Reply-To: <2AB77D60-F960-4C84-A9DC-8C2873A5C1FE@yahoo.com> References: <2AB77D60-F960-4C84-A9DC-8C2873A5C1FE.ref@yahoo.com> <2AB77D60-F960-4C84-A9DC-8C2873A5C1FE@yahoo.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: 498Pzv59Ftz3DnQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=NBFnay/G; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.89 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.39)[ip: (-9.22), ipnet: 212.83.128.0/19(1.87), asn: 12876(0.43), country: FR(0.00)]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, 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: Sat, 25 Apr 2020 08:57:01 -0000 On Sat, 25 Apr 2020 00:43:27 -0700 Mark Millard via freebsd-uboot wrote: > From the log file: > > ===> Patching for u-boot-rpi4-2020.04 > ===> Applying distribution patches for u-boot-rpi4-2020.04 > 2 out of 2 hunks failed--saving rejects to scripts/dtc/libfdt/fdt_addresses.c.rej We don't have such patch in the tree. > *** Error code 1 > > Details: > > amd64 head -r360289 context. Ports head -r532914 context. > > # svnlite status /usr/ports/sysutils/u-boot-rpi4/ > # > > # svnlite status /usr/ports/sysutils/u-boot-master/ > # > > # more /wrkdirs/usr/ports/sysutils/u-boot-rpi4/work/u-boot-2020.04/scripts/dtc/libfdt/fdt_addresses.c.rej > @@ -1,6 +1,7 @@ > /* > * libfdt - Flat Device Tree manipulation > * Copyright (C) 2014 David Gibson > + * Copyright (C) 2018 embedded brains GmbH > * > * libfdt is dual licensed: you can use it either under the terms of > * the GPL, or the BSD license, at your option. > @@ -55,42 +56,32 @@ > > #include "libfdt_internal.h" > > -int fdt_address_cells(const void *fdt, int nodeoffset) > +static int fdt_cells(const void *fdt, int nodeoffset, const char *name) > { > - const fdt32_t *ac; > + const fdt32_t *c; > int val; > int len; > > - ac = fdt_getprop(fdt, nodeoffset, "#address-cells", &len); > - if (!ac) > + c = fdt_getprop(fdt, nodeoffset, name, &len); > + if (!c) > return 2; > > - if (len != sizeof(*ac)) > + if (len != sizeof(*c)) > return -FDT_ERR_BADNCELLS; > > - val = fdt32_to_cpu(*ac); > + val = fdt32_to_cpu(*c); > if ((val <= 0) || (val > FDT_MAX_NCELLS)) > return -FDT_ERR_BADNCELLS; > > return val; > } > > -int fdt_size_cells(const void *fdt, int nodeoffset) > +int fdt_address_cells(const void *fdt, int nodeoffset) > { > - const fdt32_t *sc; > - int val; > - int len; > - > - sc = fdt_getprop(fdt, nodeoffset, "#size-cells", &len); > - if (!sc) > - return 2; > - > - if (len != sizeof(*sc)) > - return -FDT_ERR_BADNCELLS; > - > - val = fdt32_to_cpu(*sc); > - if ((val < 0) || (val > FDT_MAX_NCELLS)) > - return -FDT_ERR_BADNCELLS; > + return fdt_cells(fdt, nodeoffset, "#address-cells"); > +} > > - return val; > +int fdt_size_cells(const void *fdt, int nodeoffset) > +{ > + return fdt_cells(fdt, nodeoffset, "#size-cells"); > } > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-uboot@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-uboot > To unsubscribe, send any mail to "freebsd-uboot-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Apr 25 09:00:22 2020 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 37FCF2CFE18; Sat, 25 Apr 2020 09:00:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 498Q3n1vC9z3F0g; Sat, 25 Apr 2020 09:00:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1587805219; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MlJMjQIz+p/nA76dfC6ybmjg8x7YaV1pMP89O/1C2o4=; b=B15pAteY8Gkjota+nTC//quIqWl0sDVlw/X2xchcoyx+00UsTL9u6Zohqo40Q46izvrhGZ 2dnZFN854Jgg7bZOaAbrraC4m9HzwzdbWU6BqeSqGHGpbcM+hCX6Q1AGxc/2wzVN4zoC6X DTGBwVYDp5XGws8RsqrUJPVI2nSpCgQ= Received: from tails.home (lfbn-idf2-1-900-181.w86-238.abo.wanadoo.fr [86.238.131.181]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 044fc5d5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 25 Apr 2020 09:00:19 +0000 (UTC) Date: Sat, 25 Apr 2020 11:00:19 +0200 From: Emmanuel Vadot To: Emmanuel Vadot Cc: Mark Millard , freebsd-arm , FreeBSD ports , Mark Millard via freebsd-uboot Subject: Re: Applying distribution patches for u-boot-rpi4-2020.04 fails during build (poudriere-devel context) Message-Id: <20200425110019.ec2e012449fa242346dcb641@bidouilliste.com> In-Reply-To: <20200425105647.1406a2357cb0b825e19696a5@bidouilliste.com> References: <2AB77D60-F960-4C84-A9DC-8C2873A5C1FE.ref@yahoo.com> <2AB77D60-F960-4C84-A9DC-8C2873A5C1FE@yahoo.com> <20200425105647.1406a2357cb0b825e19696a5@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: 498Q3n1vC9z3F0g X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=B15pAteY; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.89 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.39)[ip: (-9.26), ipnet: 212.83.128.0/19(1.85), asn: 12876(0.43), country: FR(0.00)]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; FREEMAIL_CC(0.00)[yahoo.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: Sat, 25 Apr 2020 09:00:22 -0000 On Sat, 25 Apr 2020 10:56:47 +0200 Emmanuel Vadot wrote: > On Sat, 25 Apr 2020 00:43:27 -0700 > Mark Millard via freebsd-uboot wrote: > > > From the log file: > > > > ===> Patching for u-boot-rpi4-2020.04 > > ===> Applying distribution patches for u-boot-rpi4-2020.04 > > 2 out of 2 hunks failed--saving rejects to scripts/dtc/libfdt/fdt_addresses.c.rej > > We don't have such patch in the tree. Sorry, it's https://patchwork.ozlabs.org/project/uboot/patch/20190726091339.24420-1-matthias.bgg@kernel.org/ I think I didn't had this port on my list of u-boot port to check, I'll fix that today. > > > *** Error code 1 > > > > Details: > > > > amd64 head -r360289 context. Ports head -r532914 context. > > > > # svnlite status /usr/ports/sysutils/u-boot-rpi4/ > > # > > > > # svnlite status /usr/ports/sysutils/u-boot-master/ > > # > > > > # more /wrkdirs/usr/ports/sysutils/u-boot-rpi4/work/u-boot-2020.04/scripts/dtc/libfdt/fdt_addresses.c.rej > > @@ -1,6 +1,7 @@ > > /* > > * libfdt - Flat Device Tree manipulation > > * Copyright (C) 2014 David Gibson > > + * Copyright (C) 2018 embedded brains GmbH > > * > > * libfdt is dual licensed: you can use it either under the terms of > > * the GPL, or the BSD license, at your option. > > @@ -55,42 +56,32 @@ > > > > #include "libfdt_internal.h" > > > > -int fdt_address_cells(const void *fdt, int nodeoffset) > > +static int fdt_cells(const void *fdt, int nodeoffset, const char *name) > > { > > - const fdt32_t *ac; > > + const fdt32_t *c; > > int val; > > int len; > > > > - ac = fdt_getprop(fdt, nodeoffset, "#address-cells", &len); > > - if (!ac) > > + c = fdt_getprop(fdt, nodeoffset, name, &len); > > + if (!c) > > return 2; > > > > - if (len != sizeof(*ac)) > > + if (len != sizeof(*c)) > > return -FDT_ERR_BADNCELLS; > > > > - val = fdt32_to_cpu(*ac); > > + val = fdt32_to_cpu(*c); > > if ((val <= 0) || (val > FDT_MAX_NCELLS)) > > return -FDT_ERR_BADNCELLS; > > > > return val; > > } > > > > -int fdt_size_cells(const void *fdt, int nodeoffset) > > +int fdt_address_cells(const void *fdt, int nodeoffset) > > { > > - const fdt32_t *sc; > > - int val; > > - int len; > > - > > - sc = fdt_getprop(fdt, nodeoffset, "#size-cells", &len); > > - if (!sc) > > - return 2; > > - > > - if (len != sizeof(*sc)) > > - return -FDT_ERR_BADNCELLS; > > - > > - val = fdt32_to_cpu(*sc); > > - if ((val < 0) || (val > FDT_MAX_NCELLS)) > > - return -FDT_ERR_BADNCELLS; > > + return fdt_cells(fdt, nodeoffset, "#address-cells"); > > +} > > > > - return val; > > +int fdt_size_cells(const void *fdt, int nodeoffset) > > +{ > > + return fdt_cells(fdt, nodeoffset, "#size-cells"); > > } > > > > > > === > > Mark Millard > > marklmi at yahoo.com > > ( dsl-only.net went > > away in early 2018-Mar) > > > > _______________________________________________ > > freebsd-uboot@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-uboot > > To unsubscribe, send any mail to "freebsd-uboot-unsubscribe@freebsd.org" > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Apr 25 12:22:01 2020 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 8F2332AF357 for ; Sat, 25 Apr 2020 12:22:01 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (gromit.grondar.org [IPv6:2a01:348:e::1]) (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 498VXT17SYz3yVp; Sat, 25 Apr 2020 12:22:01 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from [2a02:8011:300b:42:f50b:eca:e030:bbf5] by gromit.grondar.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jSJof-0000o7-Gy; Sat, 25 Apr 2020 13:21:53 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_83AF40BC-9A5F-4833-BC9F-543C9C74A94A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Bootable image for Macchatobin Double Shot? From: Mark Murray In-Reply-To: Date: Sat, 25 Apr 2020 13:21:52 +0100 Cc: freebsd-arm@freebsd.org Message-Id: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> References: <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> To: Marcel Flores X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498VXT17SYz3yVp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.61 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.67)[-0.674,0]; NEURAL_HAM_LONG(-0.94)[-0.938,0]; ASN(0.00)[asn:39326, ipnet:2a01:348::/32, country:GB] 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, 25 Apr 2020 12:22:01 -0000 --Apple-Mail=_83AF40BC-9A5F-4833-BC9F-543C9C74A94A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Apologies for not responding to this earlier. Things got disorganised = before I got organised. Thanks for this response; I was able to make progress, but now I'm = stuck. > On 21 Mar 2020, at 17:03, Marcel Flores wrote: >=20 >> On Mar 21, 2020, at 3:58 AM, Mark Murray wrote: >>=20 >> Hi Folks, >>=20 >> I'm keen to get a Macchiatobin Double Shot running as both a firewall = and native build box at home. Part of the appeal is also to retire a = very old, large, slow and power-hungry PC. >>=20 >> I know there are no drivers for the on-board network devices, and I'm = very happy to use a dual-port PCIe card. Serial console is fine. I'll be = needing the SATA. If SATA doesn't work, this is a hard failure. >>=20 >> Does anybody here have a recipe for creating a bootable image for = this board please? Success/failure stories also welcome! >>=20 >> Thanks! >>=20 >> M >> -- >> Mark R V Murray >=20 > I=E2=80=99ve had no trouble using edk2 UEFI and CURRENT. My setup has = the edk2 > binary on an SD Card and the FreeBSD install on SATA (though it booted = fine > from the USB originally to install it). An intel PCIE nic seems to = work fine as > well, but I=E2=80=99ve not really played with it exhaustively to see = what works. >=20 > I used the 18.09.4 UEFI image from here: >=20 > = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/Binar= ies >=20 > Did something like: >=20 > dd if=3D/root/flash-image-18.09.4.bin bs=3D512 seek=3D1 = of=3D conv=3Dsync >=20 > to copy to the SD card. And it basically booted straight away with no = issue. This worked for me, thanks! I had to tell UEFI to use ACPI not = Device_Tree, and I was able to boot a recent FreeBSD-13 MemStick image off USB. With this I = could install onto SATA HDD with GPT volumes and ZFS filesystem. So far so good! :-) - but see the dmesg(8) output at the end of this; = there is a lot missing. I have a PCIeX4 Intel dual ethernet card installed, and it doesn't = appear on the booted OS. NO PCi is visible, in fact, according to "pciconf -l". I suspect that the lack of DTB is to blame, so I built a kernel with a = modified src/sys/modules/dtb/mv/Makefile to add armada-8040-mcbin.dts to the = existing armada-3720-espressobin.dts in the DTS. At boot time, I loaded the resulting DTB (transcribed by hand): OK unload OK load boot/kernel/kernel boot /kernel/kernel text=3D.... (etc) OK load -t dts boot/dtb/marvell/armada-8040-mcbin.dtb boot/dtb/marvell/armada-8040-mcbin.dtb size=3D0xb970 OK boot -v Using DTB from loaded file 'boot/dtb/marvell/armada-8040-mcbin.dtb'. ******(nothing else) ... where the "*****" chars are my terminal's "unknown character" = symbol. I can't get any attempt to boot with DTB loaded to work; it always ends up with = that short line of garbage and nothing else. Is the FDT stuff in CURRENT out of sync with the device drivers? I know = Jacques Schidt about FDT. :-) > Sorted this based on discussion in this thread: > = https://lists.freebsd.org/pipermail/freebsd-arm/2019-December/020823.html I had similar problems to the folks in this thread, and I tried some of = the same things. I tried building a DTB (see above). I tried using UEFI DTB - hang similar to above. I tried a FreeBSD-12 image - boots with ACPI, but PCI not present. With = UEFI DTB I get the same hang. Any ideas? M ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #0: Sat Apr 25 11:33:44 BST 2020 root@grimoire:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.0-0-gd32170dbd5b) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. module firmware already present! Starting CPU 1 (1) Starting CPU 2 (100) Starting CPU 3 (101) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface MAP bf810000 mode 2 pages 992 MAP bfc90000 mode 2 pages 848 MAP f4284000 mode 0 pages 1 MAP f4440000 mode 0 pages 1 MAP f4700000 mode 0 pages 1 MAP f93c0000 mode 0 pages 48 WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD = 13.0. kbd0 at kbdmux0 WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. acpi0: acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: Could not update all GPEs: AE_NOT_CONFIGURED psci0: on acpi0 gic0: iomem = 0xf0210000-0xf0210fff,0xf022f000-0xf022ffff on acpi0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 352 gic0: frame: 0 f0280000 0 0 0 gic0: frame: 1 f0290000 0 0 0 gic0: frame: 2 f02a0000 0 0 0 gic0: frame: 3 f02b0000 0 0 0 gicv2m0: mem = 0xf0280000-0xf0280fff on gic0 gicv2m1: mem = 0xf0290000-0xf0290fff on gic0 gicv2m2: mem = 0xf02a0000-0xf02a0fff on gic0 gicv2m3: mem = 0xf02b0000-0xf02b0fff on gic0 generic_timer0: irq 8,9,10 on acpi0 Timecounter "ARM MPCore Timecounter" frequency 25000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 25000000 Hz quality 1000 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.000000s cpu0: on acpi0 ahci0: iomem 0xf2540000-0xf2541fff irq 0 on acpi0 ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahci1: iomem 0xf4540000-0xf4541fff irq 1 on acpi0 ahci1: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS ahcich2: at channel 0 on ahci1 ahcich3: at channel 1 on ahci1 xhci0: iomem 0xf2500000-0xf2503fff irq 2 on = acpi0 xhci0: 32 bytes context size, 32-bit DMA usbus0 on xhci0 xhci1: iomem 0xf2510000-0xf2513fff irq 3 on = acpi0 xhci1: 32 bytes context size, 32-bit DMA usbus1 on xhci1 xhci2: iomem 0xf4500000-0xf4503fff irq 4 on = acpi0 xhci2: 32 bytes context size, 32-bit DMA usbus2 on xhci2 uart0: <16550 or compatible> iomem 0xf0512000-0xf05120ff irq 5 on acpi0 uart0: console (115200,n,8,1) pcib0: on acpi0 pci0: on pcib0 cryptosoft0: ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 Release APs...usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 5.0Gbps Super Speed USB v3.0 done CPU 0: ARM Cortex-A72 r0p1 affinity: 0 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Trying to mount root from zfs:zroot/ROOT/default []... Instruction Set Attributes 0 =3D Root mount waiting for: Instruction Set Attributes 1 =3D <> CAM Processor Features 0 =3D usbus0 Processor Features 1 =3D <> usbus1 Memory Model Features 0 =3D = usbus2 Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> CPU 1: ARM Cortex-A72 r0p1 affinity: 0 1 CPU 2: ARM Cortex-A72 r0p1 affinity: 1 0 CPU 3: ARM Cortex-A72 r0p1 affinity: 1 1 WARNING: WITNESS option enabled, expect reduced performance. ugen2.1: at usbus2 ugen0.1: at usbus0 ugen1.1: at usbus1 uhub0 on usbus2 uhub1 on usbus1 uhub1: on = usbus1 uhub0: on = usbus2 uhub2 on usbus0 uhub2: on = usbus0 ada0 at ahcich2 bus 0 scbus2 target 0 lun 0 ada0: ATA8-ACS SATA 3.x device ada0: Serial Number 5VMRHEHM ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) ada1 at ahcich3 bus 0 scbus3 target 0 lun 0 ada1: ACS-3 ATA SATA 3.x device ada1: Serial Number 1942A1801501 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors) ada1: quirks=3D0x3<4K,NCQ_TRIM_BROKEN> uhub2: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen2.2: at usbus2 umass0 on uhub0 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks =3D 0x4000 umass0:4:0: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SPC-2 SCSI device da0: Serial Number FBH1210240200727 da0: 40.000MB/s transfers da0: 7648MB (15663104 512 byte sectors) da0: quirks=3D0x2 GEOM: da0: the secondary GPT header is not in the last LBA. lo0: link state changed to UP --Apple-Mail=_83AF40BC-9A5F-4833-BC9F-543C9C74A94A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAl6kK2AACgkQQlsJDh9C UqC7SAf+L3XSgQx8CGWgs5jyVYRkKGxAu3hdpwyCk96G0ipfbaOFDozb27VT/eaI pb95xWcfD+O4R2rPiq8obFbujhsBoifPqCHtW1rvh3i2qJT5TIcS2lxLyg2khP8I gFpcNd9Ek23/YvEJfN+xBH1MDJWKJn1RKU+TqYKOIU75UIvkIL1w8ztGTTh1Y1r5 MWtqoyehs50VZGWGrqViH1TrgsSJubijj5cq4FymoDGaO2ujyKPZSR3972hvL/tP yhtELqpl2Wnk664UfxWJZBoqPUMPlvhhj+PwGHoKwG8k2vOxyALVefeGENxogwrg QxS3xWA3S0HXzL5zxEJ18JCzO90Rhw== =weqV -----END PGP SIGNATURE----- --Apple-Mail=_83AF40BC-9A5F-4833-BC9F-543C9C74A94A-- From owner-freebsd-arm@freebsd.org Sat Apr 25 14:14:58 2020 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 729682B2F45 for ; Sat, 25 Apr 2020 14:14:58 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (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 498Y2m6rlLz47Gy; Sat, 25 Apr 2020 14:14:56 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1587824086; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FsPSTZrZwDdRQqsLfpIfdFgqO1mcdDD8J4vDVbDKqn8=; b=DR/8rHEC2rEgCxkdJQ2nw/Fuz5s7SUqpE9Zlq/+69lg6Jit/QdmAttQwC6RQK/DBHa363H h8Wd8KjRmhWxRZ4XQqiWTcSslhYNyHwKqT+/1eCGp1jOxDoDZLvxIvJQw+OhIUr7uZxn/S 99AOgnU/viBECMOoEGGp+TbzxEPo1XQ= Date: Sat, 25 Apr 2020 14:14:46 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> Subject: Re: Bootable image for Macchatobin Double Shot? To: "Mark Murray" , "Marcel Flores" Cc: freebsd-arm@freebsd.org In-Reply-To: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> References: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> X-Spam-Score: 0.90 X-Rspamd-Queue-Id: 498Y2m6rlLz47Gy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=DR/8rHEC; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-0.14 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.897,0]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; NEURAL_HAM_LONG(-0.63)[-0.627,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.38)[ipnet: 2001:41d0::/32(4.91), asn: 16276(2.01), country: FR(0.00)]; 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_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; 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: Sat, 25 Apr 2020 14:14:58 -0000 April 25, 2020 3:21 PM, "Mark Murray" wrote:=0A=0A> I= tried a FreeBSD-12 image - boots with ACPI, but PCI not present. With UE= FI DTB=0A> I get the same hang.=0A=0AIt is present:=0A=0A> pcib0: on acpi0=0A> pci0: on pcib0=0A=0ABut not= the device.=0A=0AThe thing is, the PCIe controller has a bug (in ECAM mo= de).=0AIt doesn't properly filter something, so a device could appear rep= licated multiple times.=0ASo the Semihalf engineers decided to do a worka= round: move the memory address in ACPI=0Aso that the OS only sees the las= t device.=0A=0AI don't know which devices they tried, but my Radeon RX 48= 0 *does not* get replicated.=0ASame with an Intel and Mellanox NIC.=0AA R= adeon HD 7970 was replicated but only twice, not 32 times.=0A=0AYou can t= ry my EDK2 builds, at least one of them should work. I reverted that work= around.=0A=0Ahttps://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com= /flash-image.bin=0Ahttps://unrelentingtech.s3.dualstack.eu-west-1.amazona= ws.com/flash-image2.bin=0A=0ARelevant discussion links:=0A=0Ahttps://gith= ub.com/MarvellEmbeddedProcessors/edk2-open-platform/issues/11=0Ahttps://g= ithub.com/andreiw/MacchiatoBin-edk2/commit/2c49a74d3c0438b656e56ef133a469= 9ab3f8b22f#commitcomment-34139610 From owner-freebsd-arm@freebsd.org Sat Apr 25 14:51:15 2020 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 6219C2B4382 for ; Sat, 25 Apr 2020 14:51:15 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (gromit.grondar.org [IPv6:2a01:348:e::1]) (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 498Yrf4Zpyz49G7; Sat, 25 Apr 2020 14:51:14 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from [2a02:8011:300b:42:3d80:3407:95a6:57a5] by gromit.grondar.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jSM97-00012r-71; Sat, 25 Apr 2020 15:51:09 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_1D87CD7B-C712-4481-979F-A39446FB2ADF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Bootable image for Macchatobin Double Shot? From: Mark Murray In-Reply-To: <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> Date: Sat, 25 Apr 2020 15:51:08 +0100 Cc: Marcel Flores , freebsd-arm@freebsd.org Message-Id: References: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> To: greg@unrelenting.technology X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498Yrf4Zpyz49G7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.73 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.77)[-0.768,0]; ASN(0.00)[asn:39326, ipnet:2a01:348::/32, country:GB]; NEURAL_HAM_LONG(-0.96)[-0.958,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, 25 Apr 2020 14:51:15 -0000 --Apple-Mail=_1D87CD7B-C712-4481-979F-A39446FB2ADF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi > On 25 Apr 2020, at 15:14, greg@unrelenting.technology wrote: >=20 > April 25, 2020 3:21 PM, "Mark Murray" wrote: >=20 >> I tried a FreeBSD-12 image - boots with ACPI, but PCI not present. = With UEFI DTB >> I get the same hang. >=20 > It is present: >=20 >> pcib0: on acpi0 >> pci0: on pcib0 Hmm. I saw that but thought it was a meta-device or bus-master or = something :-) > But not the device. Right :-( > The thing is, the PCIe controller has a bug (in ECAM mode). > It doesn't properly filter something, so a device could appear = replicated multiple times. > So the Semihalf engineers decided to do a workaround: move the memory = address in ACPI > so that the OS only sees the last device. OK - I recall that part of the thread. > I don't know which devices they tried, but my Radeon RX 480 *does not* = get replicated. > Same with an Intel and Mellanox NIC. > A Radeon HD 7970 was replicated but only twice, not 32 times. >=20 > You can try my EDK2 builds, at least one of them should work. I = reverted that workaround. Thanks! > = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image.b= in > = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image2.= bin The second has the same binary bits as the one I downloaded from the = link in my original post. The first fails with this at power-up: BootROM - 2.03 Starting CP-0 IOROM 1.07 Booting from SD 0 (0x29) SD - wait_for_sd_interrupt: Error interrupt - 00008000 SD - wait_for_sd_interrupt: Error interrupt status 00000003 SD - sd_get_cmd_response: Get command response failed. SD - sd_init: Failed - ret =3D 00000081 Error: Failed initializing interface Error: Failed boot attempt 01. error =3D 0x0C1 BootROM - 2.03 Starting CP-0 IOROM 1.07 Booting from SD 0 (0x29) SD - wait_for_sd_interrupt: Error interrupt - 00008000 SD - wait_for_sd_interrupt: Error interrupt status 00000003 SD - sd_get_cmd_response: Get command response failed. SD - sd_init: Failed - ret =3D 00000081 Error: Failed initializing interface Found valid image at boot postion 0x000 lNOTICE: Starting binary extension NOTICE: SVC: DEV ID: 8040, FREQ Mode: 0x1 NOTICE: SVC: AVS work point changed from 0x28 to 0x28 mv_ddr: mv_ddr-devel-18.12.0-g618dadd (Jun 25 2019 - 14:56:37) mv_ddr: completed successfully NOTICE: Cold boot NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):1f8ca7e0-dirty (Marvell-devel-18.12.2) NOTICE: BL1: Built : 14:57:35, Jun 25 2019 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):1f8ca7e0-dirty (Marvell-devel-18.12.2) NOTICE: BL2: Built : 14:58:37, Jun 25 2019 BL2: Initiating SCP_BL2 transfer to SCP NOTICE: SCP_BL2 contains 5 concatenated images NOTICE: Skipping MSS CP3 related image NOTICE: Skipping MSS CP2 related image NOTICE: Load image to CP1 MSS AP0 NOTICE: Loading MSS image from addr. 0x40269f4 Size 0x1cd8 to MSS at = 0xf4280000 NOTICE: Done NOTICE: Load image to CP0 MSS AP0 NOTICE: Loading MSS image from addr. 0x40286cc Size 0x1cd8 to MSS at = 0xf2280000 NOTICE: Done NOTICE: Load image to AP0 MSS NOTICE: Loading MSS image from addr. 0x402a3a4 Size 0x5420 to MSS at = 0xf0580000 NOTICE: Done NOTICE: SCP Image doesn't contain PM firmware NOTICE: BL1: Booting BL31 lNOTICE: MSS PM is not supported in this build NOTICE: BL31: v1.5(release):1f8ca7e0-dirty (Marvell-devel-18.12.2) NOTICE: BL31: Built : 14:59:06, Jun 25 2019 Error: Image at 000BF7FE000 start failed: Invalid Parameter remove-symbol-file = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/edk2-platforms/Silicon/Marvell/Drivers/BoardDesc/MvBo= ardDescDxe/DEBUG/BoardDescDxe.dll 0xBF7FF000 Armada Platform Init Error: Image at 000BF7DB000 start failed: Not Found remove-symbol-file = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/edk2-platforms/Silicon/Marvell/Drivers/I2c/MvI2cDxe/M= vI2cDxe/DEBUG/MvI2cDxe.dll 0xBF7DC000 Error: Image at 000BF7CB000 start failed: Not Found remove-symbol-file = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/edk2-platforms/Silicon/Marvell/Drivers/Net/MvMdioDxe/= MvMdioDxe/DEBUG/MdioDxe.dll 0xBF7CC000 Succesfully installed protocol interfaces MvGpioEntryPoint: Cannot locate BoardDesc protocol Error: Image at 000BF763000 start failed: Not Found remove-symbol-file = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/edk2-platforms/Silicon/Marvell/Drivers/Gpio/MvGpioDxe= /MvGpioDxe/DEBUG/MvGpioDxe.dll 0xBF764000 Error: Image at 000BF752000 start failed: Not Found remove-symbol-file = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/edk2-platforms/Silicon/Marvell/Drivers/NonDiscoverabl= eDxe/NonDiscoverableDxe/DEBUG/NonDiscoverableDxe.dll 0xBF753000 Error: Image at 000BF702000 start failed: 00000001 remove-symbol-file = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatf= ormDxe/DEBUG/AcpiPlatform.dll 0xBF703000 Detected w25q32bv SPI NOR flash with page size 256 B, erase size 4 KB, = total 4 MB Error: Image at 000BF6F0000 start failed: Not Found remove-symbol-file = /home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/REL= EASE_CLANG38/AARCH64/edk2-platforms/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2= Dxe/DEBUG/Pp2Dxe.dll 0xBF6F1000 Armada7k8kPciHostBridgeLibConstructor: Cannot locate BoardDesc protocol 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) M -- --Apple-Mail=_1D87CD7B-C712-4481-979F-A39446FB2ADF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAl6kTlwACgkQQlsJDh9C UqCy0QgAo5vVZSw+g7Pve3ZX3wiFm3oZuLgYbLUtFP6OvY3IpvyvIB0PVLZMf4Fr iVeAsvF0RZ87alzdBB27f4wKscwn4/c3yqrXBfE8WqwQJdufTDgaKhIK5Wyizusc DWgwAtl4/Byvw19eK7KzxunVsFn+XpCJYPWGsnOX1+/mKjmGDEHoS67Ht8Nv/sva /j5y89vEhV8i09E4P4VKypsdnf7Mf1Zaf9li76eF5kE4vuC/Uv+nvZR7s6AhSCCt BMFKy+4qrLO1BLkaPNdYv7deHXChebe11uLvch/1oM6QCurFX02QE04yoX6pTHI7 JxybPN2uRcAxIac8YFn81xx/LOciOw== =HgGU -----END PGP SIGNATURE----- --Apple-Mail=_1D87CD7B-C712-4481-979F-A39446FB2ADF-- From owner-freebsd-arm@freebsd.org Sat Apr 25 15:22:31 2020 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 0175E2B53C3 for ; Sat, 25 Apr 2020 15:22:31 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) (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 498ZXj4mr4z4C6C; Sat, 25 Apr 2020 15:22:29 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1587828140; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sWgHF1D0ICnnyMnKaEBWrRGeSen4vVk63Wh+LGwGLOI=; b=iTkCSLVMkBS8Ud3BWyQjcNYORt/MhYEF9zI5mbukOZwT+ApJyqMEJ00t7REGeGNFeVV1TQ 5Zn82qTSqNl3xeLa0TI67uElJK72OyDLYcmNvZvvke3Em6J0P2DA0tWYupydLKqI6MhkoA 6Ij42g5oTWNbCLd6oJU6PR1Ap6sUXnw= Date: Sat, 25 Apr 2020 15:22:21 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: Subject: Re: Bootable image for Macchatobin Double Shot? To: "Mark Murray" Cc: "Marcel Flores" , freebsd-arm@freebsd.org In-Reply-To: References: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> X-Spam-Score: 0.90 X-Rspamd-Queue-Id: 498ZXj4mr4z4C6C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=iTkCSLVM; 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 [-3.87 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; 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]; IP_SCORE(-1.87)[ip: (-9.78), ipnet: 91.121.0.0/16(-1.56), asn: 16276(2.01), country: FR(0.00)]; 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_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.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)[] 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, 25 Apr 2020 15:22:31 -0000 April 25, 2020 5:51 PM, "Mark Murray" wrote:=0A=0A>> = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image.= bin=0A>> https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/fla= sh-image2.bin=0A> =0A> The second has the same binary bits as the one I d= ownloaded from the link in my original post.=0A=0AIt should work then..= =0A=0AUnless I really screwed something up and *somehow* this is not a go= od image -=0Ayou can check by running (as root):=0A=0A/usr/sbin/acpidump = -t -d -o /dev/null | grep -a -C10 PNP0C02=0A=0Athat should find the PCIe = controller in the DSDT table, its Memory32Fixed resource should=0Acontain= the address 0xE0000000, NOT 0xE0008000.=0A=0A=0AWhat does the pci comman= d in the EFI Shell say? Run `pci 00 00 00 -i` to get info about a particu= lar device,=0Ae.g. https://gist.github.com/myfreeweb/8b09f1c93ee9572aef01= 513ba9bf756f=0A=0AAlso, have you tried any other PCIe cards?=0A=0A> The f= irst fails with this at power-up:=0A=0AOh, okay, that's the bad one. Dele= ted. From owner-freebsd-arm@freebsd.org Sat Apr 25 15:46:18 2020 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 6964A2B6269 for ; Sat, 25 Apr 2020 15:46:18 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (gromit.grondar.org [IPv6:2a01:348:e::1]) (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 498b4B1KpPz4FRQ; Sat, 25 Apr 2020 15:46:17 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from [2a02:8011:300b:42:3d80:3407:95a6:57a5] by gromit.grondar.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jSN0Q-00018r-NB; Sat, 25 Apr 2020 16:46:14 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_2525FE15-2C02-4C58-BF69-71E9E3304ED5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Bootable image for Macchatobin Double Shot? From: Mark Murray In-Reply-To: Date: Sat, 25 Apr 2020 16:46:13 +0100 Cc: Marcel Flores , freebsd-arm@freebsd.org Message-Id: References: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> To: greg@unrelenting.technology X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498b4B1KpPz4FRQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.51 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.60)[-0.605,0]; NEURAL_HAM_LONG(-0.90)[-0.904,0]; ASN(0.00)[asn:39326, ipnet:2a01:348::/32, country:GB] 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, 25 Apr 2020 15:46:18 -0000 --Apple-Mail=_2525FE15-2C02-4C58-BF69-71E9E3304ED5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Apr 2020, at 16:22, greg@unrelenting.technology wrote: >=20 > April 25, 2020 5:51 PM, "Mark Murray" wrote: >=20 >>> = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image.b= in >>> = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image2.= bin >>=20 >> The second has the same binary bits as the one I downloaded from the = link in my original post. >=20 > It should work then.. >=20 > Unless I really screwed something up and *somehow* this is not a good = image - > you can check by running (as root): >=20 > /usr/sbin/acpidump -t -d -o /dev/null | grep -a -C10 PNP0C02 # /usr/sbin/acpidump -t -d -o /dev/null | grep -a -C10 PNP0C02 acpidump: FACS is corrupt > that should find the PCIe controller in the DSDT table, its = Memory32Fixed resource should > contain the address 0xE0000000, NOT 0xE0008000. Not quite there yet :-) > What does the pci command in the EFI Shell say? Run `pci 00 00 00 -i` = to get info about a particular device, > e.g. = https://gist.github.com/myfreeweb/8b09f1c93ee9572aef01513ba9bf756f Shell> pci Seg Bus Dev Func --- --- --- ---- 00 00 00 00 =3D=3D> Network Controller - Ethernet controller Vendor 8086 Device 1521 Prog Interface 0 00 00 00 01 =3D=3D> Network Controller - Ethernet controller Vendor 8086 Device 1521 Prog Interface 0 ASSERT [PciHostBridgeDxe] = /home/mw/git/uefi-27/edk2-platforms/Silicon/Marvell/Armada7k8k/Library/Arm= ada7k8kPciExpressLib/PciExpressLib.c(78): Address < (0x0 + 1) * = 0x00100000 Looks like something went badly wrong there :-( After reboot to unwedge: Shell> pci 00 00 00 -i PCI Segment 00 Bus 00 Device 00 Func 00 [EFI 0000000000] 00000000: 86 80 21 15 00 00 10 00-01 00 00 02 20 00 80 00 = *..!......... ...* 00000010: 00 00 10 C0 00 00 00 00-00 00 00 00 00 40 28 C0 = *.............@(.* 00000020: 00 00 00 00 00 00 00 00-00 00 00 00 86 80 02 00 = *................* 00000030: 00 00 F8 FF 40 00 00 00-00 00 00 00 FF 01 00 00 = *....@...........* 00000040: 01 50 23 C8 08 20 00 00-00 00 00 00 00 00 00 00 *.P#.. = ..........* 00000050: 05 70 80 01 00 00 00 00-00 00 00 00 00 00 00 00 = *.p..............* 00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000070: 11 A0 09 00 03 00 00 00-03 20 00 00 00 00 00 00 *......... = ......* 00000080: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000090: 00 00 00 00 00 00 00 00-00 00 00 00 FF FF FF FF = *................* 000000A0: 10 00 02 00 C2 8C 00 10-10 28 19 00 42 EC 42 04 = *.........(..B.B.* 000000B0: 00 00 42 10 00 00 00 00-00 00 00 00 00 00 00 00 = *..B.............* 000000C0: 00 00 00 00 1F 08 00 00-00 00 00 00 00 00 00 00 = *................* 000000D0: 02 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000000E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000000F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* Start dumping PCIex extended configuration space (0x100 - 0xFFF). 00000100: 01 00 02 14 00 00 00 00-00 00 00 00 31 20 46 00 = *............1 F.* 00000110: 01 20 00 00 00 20 00 00-A0 00 00 00 00 00 00 00 *. ... = ..........* 00000120: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000130: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000140: 03 00 01 15 CC 36 0A FF-FF 9F 36 A0 00 00 00 00 = *.....6....6.....* 00000150: 0E 00 01 16 00 01 00 00-00 00 00 00 00 00 00 00 = *................* 00000160: 10 00 01 1A 02 00 00 00-10 00 00 00 08 00 08 00 = *................* 00000170: 00 00 00 00 80 00 04 00-00 00 20 15 53 05 00 00 *.......... = .S...* 00000180: 01 00 00 00 00 40 26 C0-00 00 00 00 00 00 00 00 = *.....@&.........* 00000190: 00 40 24 C0 00 00 00 00-00 00 00 00 00 00 00 00 = *.@$.............* 000001A0: 17 00 01 1C 05 02 07 00-00 00 00 00 00 00 00 00 = *................* 000001B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000001C0: 18 00 01 1D 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000001D0: 0D 00 01 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000001E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000001F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000200: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000210: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000220: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000230: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000240: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000250: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000260: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000270: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000280: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000290: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000002A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000002B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000002C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000002D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000002E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000002F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000300: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000310: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000320: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000330: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000340: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000350: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000360: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000370: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000380: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000390: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000003A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000003B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000003C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000003D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000003E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000003F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000400: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000410: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000420: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000430: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000440: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000450: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000460: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000470: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000480: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000490: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000004A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000004B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000004C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000004D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000004E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000004F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000500: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000510: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000520: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000530: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000540: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000550: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000560: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000570: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000580: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000590: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000005A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000005B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000005C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000005D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000005E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000005F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000600: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000610: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000620: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000630: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000640: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000650: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000660: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000670: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000680: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000690: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000006A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000006B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000006C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000006D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000006E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000006F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000700: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000710: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000720: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000730: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000740: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000750: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000760: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000770: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000780: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000790: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000007A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000007B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000007C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000007D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000007E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000007F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000800: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000810: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000820: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000830: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000840: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000850: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000860: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000870: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000880: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000890: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000008A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000008B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000008C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000008D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000008E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000008F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000900: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000910: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000920: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000930: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000940: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000950: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000960: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000970: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000980: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000990: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000009A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000009B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000009C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000009D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000009E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 000009F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A00: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A10: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A20: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A50: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A60: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A70: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000A90: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000AA0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000AB0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000AC0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000AD0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000AE0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000AF0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B00: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B10: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B20: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B50: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B60: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B70: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000B90: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000BA0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000BB0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000BC0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000BD0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000BE0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000BF0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C00: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C10: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C20: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C50: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C60: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C70: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000C90: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000CA0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000CB0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000CC0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000CD0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000CE0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000CF0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D00: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D10: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D20: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D50: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D60: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D70: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000D90: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000DA0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000DB0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000DC0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000DD0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000DE0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000DF0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E00: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E10: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E20: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E50: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E60: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E70: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000E90: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000EA0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000EB0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000EC0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000ED0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000EE0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000EF0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F00: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F10: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F20: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F30: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F50: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F60: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F70: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000F90: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000FA0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000FB0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000FC0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000FD0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000FE0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* 00000FF0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................* Vendor ID(0): 8086 Device ID(2): 1521 Command(4): 0000 (00)I/O space access enabled: 0 (01)Memory space access = enabled: 0 (02)Behave as bus master: 0 (03)Monitor special cycle = enabled: 0 (04)Mem Write & Invalidate enabled: 0 (05)Palette snooping is = enabled: 0 (06)Assert PERR# when parity error: 0 (07)Do address/data stepping: = 0 (08)SERR# driver enabled: 0 (09)Fast back-to-back = transact...: 0 Status(6): 0010 (04)New Capabilities linked list: 1 (05)66MHz Capable: = 0 (07)Fast Back-to-Back Capable: 0 (08)Master Data Parity Error: = 0 (09)DEVSEL timing: Fast (11)Signaled Target Abort: = 0 (12)Received Target Abort: 0 (13)Received Master Abort: = 0 (14)Signaled System Error: 0 (15)Detected Parity Error: = 0 Revision ID(8): 01 BIST(0F): Incapable Cache Line Size(C): 20 Latency Timer(D): 00 Header Type(0E): 80, Multi-function, PCI device Class: Network Controller - Ethernet controller - Pci Express device capability structure: CapID( 0): 10 NextCap Ptr( 1): 00 Cap Register( 2): 0002 Capability Version(3:0): 0x0002 Device/PortType(7:4): PCI Express Endpoint Interrupt Message Number(13:9): 0x00000 Device Capabilities( 4): 10008CC2 Max_Payload_Size Supported(2:0): 512 bytes Phantom Functions Supported(4:3): 0 Extended Tag Field Supported(5): 5-bit Tag field supported Endpoint L0s Acceptable Latency(8:6): Maximum of 512 ns Endpoint L1 Acceptable Latency(11:9): Maximum of 128 us Role-based Error Reporting(15): 1 Function Level Reset Capability(28): 1 Device Control( 8): 2810 Correctable Error Reporting Enable(0): 0 Non-Fatal Error Reporting Enable(1): 0 Fatal Error Reporting Enable(2): 0 Unsupported Request Reporting Enable(3): 0 Enable Relaxed Ordering(4): 1 Max_Payload_Size(7:5): 128 bytes Extended Tag Field Enable(8): 0 Phantom Functions Enable(9): 0 Auxiliary (AUX) Power PM Enable(10): 0 Enable No Snoop(11): 1 Max_Read_Request_Size(14:12): 512 bytes Device Status( A): 0019 Correctable Error Detected(0): 1 Non-Fatal Error Detected(1): 0 Fatal Error Detected(2): 0 Unsupported Request Detected(3): 1 AUX Power Detected(4): 1 Transactions Pending(5): 0 Link Capabilities( C): 0442EC42 Maximum Link Speed(3:0): 5.0 GT/s Maximum Link Width(9:4): x4 Active State Power Management Support(11:10): L0s and L1 = Supported L0s Exit Latency(14:12): 2us-4us L1 Exit Latency(17:15): 16us to less than = 32us Clock Power Management(18): 0 Surprise Down Error Reporting Capable(19): 0 Data Link Layer Link Active Reporting Capable(20): 0 Link Bandwidth Notification Capability(21): 0 Port Number(31:24): 0x04 Link Control(10): 0000 Active State Power Management Control(1:0): Disabled Read Completion Boundary (RCB)(3): 64 byte Common Clock Configuration(6): 0 Extended Synch(7): 0 Enable Clock Power Management(8): 0 Hardware Autonomous Width Disable(9): 0 Link Bandwidth Management Interrupt Enable(10): 0 Link Autonomous Bandwidth Interrupt Enable(11): 0 Link Status(12): 1042 Current Link Speed(3:0): 5.0 GT/s Negotiated Link Width(9:4): x4 Link Training(11): 0 Slot Clock Configuration(12): 1 Data Link Layer Link Active(13): 0 Link Bandwidth Management Status(14): 0 Link Autonomous Bandwidth Status(15): 0 Slot Capabilities(14): 00000000 Slot Control(18): 0000 Slot Status(1A): 0000 Root Control(1C): 0000 Root Capabilities(1E): 0000 Root Status(20): 00000000 Advanced Error Reporting UncorrectableErrorStatus 00000000 UncorrectableErrorMask 00000000 UncorrectableErrorSeverity 00462031 CorrectableErrorStatus 00002001 CorrectableErrorMask 00002000 AdvancedErrorCapAndControl 000000A0 HeaderLog1 00000000 HeaderLog2 00000000 HeaderLog3 00000000 HeaderLog4 00000000 RootErrorCommand 00000000 RootErrorStatus 00000000 ErrorSourceIdentification 0000 CorrectableErrorSourceIden 0000 TlpPrefixLog1 00000000 TlpPrefixLog2 00000000 TlpPrefixLog3 15010003 TlpPrefixLog4 FF0A36CC 00000100: 01 00 02 14 00 00 00 00-00 00 00 00 31 20 46 00 = *............1 F. * 00000110: 01 20 00 00 00 20 00 00-A0 00 00 00 00 00 00 00 *. ... = .......... * 00000120: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................ * 00000130: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 = *................ * 00000140: 03 00 01 15 CC 36 0A FF- = *.....6..* Serial Number SerialNumber A0369FFFFF0A36CC 00000140: 03 00 01 15 CC 36 0A FF-FF 9F 36 A0 = *.....6....6.* ARI AriCapability 0100 AriControl 0000 00000150: 0E 00 01 16 00 01 00 00- = *........* Unknown PCIe extended capability ID (0010h). No interpretation = available. TPH TphRequesterCapability 00070205 TphRequesterControl 0000 TphTable (optional): 000001AC: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 = *............ ..* 000001A0: 17 00 01 1C 05 02 07 00-00 00 00 00 00 00 00 00 = *................ * 000001B0: 00 00 00 00 00 00 00 00-00 00 = *..........* Latency Tolerance Reporting MaxSnoopLatency 0000 MaxNoSnoopLatency 0000 000001C0: 18 00 01 1D 00 00 00 00- = *........* ACS CapabilityRegister 0000 ControlRegister 0000 000001D0: 0D 00 01 00 00 00 00 00- = *........* > Also, have you tried any other PCIe cards? Nope - 'fraid not :-(. My intention is to use this dual-port NIC until (if?) the on-board NICs = are made to work, then I'll use them and then buy a cheapo PCIe video = card to make a proper console I can use with a KVM switch. But I need to = get the PCI going first :-) Thanks for helping, BTW! M -- --Apple-Mail=_2525FE15-2C02-4C58-BF69-71E9E3304ED5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAl6kW0UACgkQQlsJDh9C UqA3aggAieMk3qdmQ6t6J8ikl3EwqzFxwCU0D/5T77zFi2PyD+3Isqmwyu4OGiur 2dvZJ+z2YIbZ03heL7uKa7aOnGRpgYkGUd5p/pSJsUtPdh5yDP9/LaIOPQh1rGK4 T4BPEk6M9zm7z27nEktP32ns//s7faxcnvT1LsZqEFiejElYzxeJyk80fi4uo11L xaViyg8qJVOd2HZpwf3tvAqsGBHtdHKx3QGxq6OOYoPX4eXQYLG8bAX3dTR0y1iZ NoA6ZRgkerF37RcEr6gFUZ359hF2Pg4qwzSkAtWNH4lNFu1fDZZF8jRkMkhfc0MM hLFcpfBar0vKSkUZ5VgK5pFeMoeXzA== =EoYf -----END PGP SIGNATURE----- --Apple-Mail=_2525FE15-2C02-4C58-BF69-71E9E3304ED5-- From owner-freebsd-arm@freebsd.org Sat Apr 25 16:12:27 2020 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 DAE322B7135 for ; Sat, 25 Apr 2020 16:12:27 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) (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 498bfL3kkjz4H8J; Sat, 25 Apr 2020 16:12:26 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1587831138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JzU+DofXYzQsxS5Ug9OKPVPbywN6xquBeiTaHE6fOUY=; b=OEgC0hyCX/Wq5AZzzAa5e+PLswk2hvioDvgB7rjJOJ07ULzpzp+U1yOIhrpsz9zA5ifgP7 FDMhxSC3thARdd8qSN3QPSb6OmQnYAzq3PHftmRtQJ4TbGqKp/c1p+iezPcaR+XJCnWdwH DKUUe+8uFB7mYG960/VTZDv1ceaNqZc= Date: Sat, 25 Apr 2020 16:12:16 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: Subject: Re: Bootable image for Macchatobin Double Shot? To: "Mark Murray" Cc: "Marcel Flores" , freebsd-arm@freebsd.org In-Reply-To: References: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> X-Spam-Score: 0.90 X-Rspamd-Queue-Id: 498bfL3kkjz4H8J X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=OEgC0hyC; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 94.23.1.103 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-0.51 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.915,0]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.23.1.103]; NEURAL_HAM_LONG(-0.72)[-0.720,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.13)[ipnet: 94.23.0.0/16(3.62), asn: 16276(2.01), country: FR(0.00)]; 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_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:94.23.0.0/16, country:FR]; 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: Sat, 25 Apr 2020 16:12:27 -0000 April 25, 2020 6:46 PM, "Mark Murray" wrote:=0A=0A>> = On 25 Apr 2020, at 16:22, greg@unrelenting.technology wrote:=0A>> =0A>> A= pril 25, 2020 5:51 PM, "Mark Murray" wrote:=0A>> =0A>= > https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-imag= e.bin=0A>> https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/f= lash-image2.bin=0A>>> The second has the same binary bits as the one I do= wnloaded from the link in my original post.=0A>> =0A>> It should work the= n..=0A>> =0A>> Unless I really screwed something up and *somehow* this is= not a good image -=0A>> you can check by running (as root):=0A>> =0A>> /= usr/sbin/acpidump -t -d -o /dev/null | grep -a -C10 PNP0C02=0A> =0A> # /u= sr/sbin/acpidump -t -d -o /dev/null | grep -a -C10 PNP0C02=0A> acpidump: = FACS is corrupt=0A> =0A>> that should find the PCIe controller in the DSD= T table, its Memory32Fixed resource should=0A>> contain the address 0xE00= 00000, NOT 0xE0008000.=0A> =0A> Not quite there yet :-)=0A> =0A>> What do= es the pci command in the EFI Shell say? Run `pci 00 00 00 -i` to get inf= o about a=0A>> particular device,=0A>> e.g. https://gist.github.com/myfre= eweb/8b09f1c93ee9572aef01513ba9bf756f=0A> =0A> Shell> pci=0A> Seg Bus Dev= Func=0A> --- --- --- ----=0A> 00 00 00 00 =3D=3D> Network Controller - E= thernet controller=0A> Vendor 8086 Device 1521 Prog Interface 0=0A> 00 00= 00 01 =3D=3D> Network Controller - Ethernet controller=0A> Vendor 8086 D= evice 1521 Prog Interface 0=0A> ASSERT [PciHostBridgeDxe]=0A> /home/mw/gi= t/uefi-27/edk2-platforms/Silicon/Marvell/Armada7k8k/Library/Armada7k8kPci= ExpressLib/PciEx=0A> ressLib.c(78): Address < (0x0 + 1) * 0x00100000=0A> = =0A> Looks like something went badly wrong there :-(=0A=0AWoah, "/home/mw= /git/uefi-27" doesn't look like something that should appear in one of my= builds..!=0A=0AI guess flash-image2 is a reupload of an old build from t= he github wiki, and flash-image was my build,=0Abut I might have overwrit= ten it with a bad one. *facepalm*=0A=0AUploaded a new untested build that= should work as=0Ahttps://unrelentingtech.s3.dualstack.eu-west-1.amazonaw= s.com/flash-image.bin=0A(sha256:8ae81d0cb07b36bd145ae56621e63c48c303641e1= cf1a574714ca60211d66c66)=0A=0AI really should finally get around to makin= g this a proper "release", with a setting in the Setup screen=0Athat woul= d allow toggling the ECAM workaround on and off, and toggling the SPCR Li= nux workaround.=0ABut first I'd like to switch to upstream TrustedFirmwar= e, but my builds of it (using clang) don't work..=0A(This is currently us= ing older Marvell-forked TF-A.)=0A=0A>> Also, have you tried any other PC= Ie cards?=0A> =0A> Nope - 'fraid not :-(.=0A> =0A> My intention is to use= this dual-port NIC until (if?) the on-board NICs are made to work, then = I'll=0A> use them and then buy a cheapo PCIe video card to make a proper = console I can use with a KVM=0A> switch. But I need to get the PCI going = first :-)=0A=0AI've started an attempt at porting the onboard NIC driver = last summer:=0Ahttps://github.com/myfreeweb/pepevtwo-kmod=0A=0AGot as far= as initializing stuff (except DMA) that's initialized before the ports. From owner-freebsd-arm@freebsd.org Sat Apr 25 16:32:07 2020 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 7FEAF2B7714 for ; Sat, 25 Apr 2020 16:32:07 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (gromit.grondar.org [IPv6:2a01:348:e::1]) (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 498c531KYQz4HmW; Sat, 25 Apr 2020 16:32:06 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from [2a02:8011:300b:42:3d80:3407:95a6:57a5] by gromit.grondar.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jSNij-00089j-D9; Sat, 25 Apr 2020 17:32:01 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_10BAB081-06F9-46C1-9996-6C3916C262E1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Bootable image for Macchatobin Double Shot? From: Mark Murray In-Reply-To: Date: Sat, 25 Apr 2020 17:32:00 +0100 Cc: Marcel Flores , freebsd-arm@freebsd.org Message-Id: <0532198F-B7DE-46A2-B262-6358EE8370E1@FreeBSD.org> References: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> To: greg@unrelenting.technology X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498c531KYQz4HmW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.57 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.65)[-0.648,0]; ASN(0.00)[asn:39326, ipnet:2a01:348::/32, country:GB]; NEURAL_HAM_LONG(-0.92)[-0.919,0] 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: Sat, 25 Apr 2020 16:32:07 -0000 --Apple-Mail=_10BAB081-06F9-46C1-9996-6C3916C262E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Greg > On 25 Apr 2020, at 17:12, greg@unrelenting.technology wrote: >=20 > Woah, "/home/mw/git/uefi-27" doesn't look like something that should = appear in one of my builds..! >=20 > I guess flash-image2 is a reupload of an old build from the github = wiki, and flash-image was my build, > but I might have overwritten it with a bad one. *facepalm* Hehehe! It happens! > Uploaded a new untested build that should work as > = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image.b= in = > = (sha256:8ae81d0cb07b36bd145ae56621e63c48c303641e1cf1a574714ca60211d66c66) It's different: UEFI Interactive Shell v2.2 EDK II UEFI v2.70 (EDK II, 0x00010000) map: No mapping found. Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> pci pci: Protocol - PciRootBridgeIo not found. Shell> I get straight to the UEFI shell, and it won't boot. In the UEFI options = pages, the usual list of devices etc is missing: = /-------------------------------------------------------------------------= -----\ | Boot Manager = | = \-------------------------------------------------------------------------= -----/ Device Path : Boot Manager Menu = HD(1,GPT,58E6C0D3-86DB = -11EA-ADE5-F5837826388 FreeBSD = B,0x28,0x64000)/\EFI\f UEFI Shell = reebsd\loader.efi Use the <^> and keys to choose a boot option, the key to select a boot option, and the key to exit the Boot Manager Menu. = /-------------------------------------------------------------------------= -----\ | = | | ^v=3DMove Highlight =3DSelect Entry Esc=3DExit = | = \-------------------------------------------------------------------------= -----/ ... but trying to boot just lands me back at the UEFI Shell. > I really should finally get around to making this a proper "release", = with a setting in the Setup screen > that would allow toggling the ECAM workaround on and off, and toggling = the SPCR Linux workaround. > But first I'd like to switch to upstream TrustedFirmware, but my = builds of it (using clang) don't work.. > (This is currently using older Marvell-forked TF-A.) Can I help in any way? I'm used to big build (but no good at building on = Windows). >>> Also, have you tried any other PCIe cards? >>=20 >> Nope - 'fraid not :-(. >>=20 >> My intention is to use this dual-port NIC until (if?) the on-board = NICs are made to work, then I'll >> use them and then buy a cheapo PCIe video card to make a proper = console I can use with a KVM >> switch. But I need to get the PCI going first :-) >=20 > I've started an attempt at porting the onboard NIC driver last summer: > https://github.com/myfreeweb/pepevtwo-kmod = Oooh! Are you amenable to bribery? ;-) > Got as far as initializing stuff (except DMA) that's initialized = before the ports. Progress is progress! M -- --Apple-Mail=_10BAB081-06F9-46C1-9996-6C3916C262E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAl6kZgAACgkQQlsJDh9C UqDWzgf+LnG1tZMz76+9Y2EdKROeOgR2yXHqL8Bc0zNWh2OvBzf+JSKFavOOI8tW x9zEMdsB7rjFtL0jarWs5iDevx1fc5gqKyivqkhx/2CYYDKRe8QWFhspcGBdOeeu 8pKA+DHUi0looe8mgEgc1hG2+djbgt+u8ZmtJu13V3D3sW89ztmHEE3hO7S7Njoi /kdWV/KCVL2CEg8f2LiQOtYrAl30zyPuTlgBy7aLwIjFlgycc7+9zJ3gn4JcbmlV tItP9qTNlEyE8WKuvwDrDtkDuqm4AJUqatI0c/88ifwcC7bV1eVdfZVpLhItfZit UCF17zpVTo23PptlcupeCrJHAw/Sew== =uQSF -----END PGP SIGNATURE----- --Apple-Mail=_10BAB081-06F9-46C1-9996-6C3916C262E1-- From owner-freebsd-arm@freebsd.org Sat Apr 25 18:01:35 2020 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 81DC32BB73F for ; Sat, 25 Apr 2020 18:01:35 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (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 498f4F6bW7z4P2T; Sat, 25 Apr 2020 18:01:33 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1587837690; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GFZDsTVeKjTVtEQqjOz+wiR+EVbiKOVGJZetmBuf2TI=; b=Akahcx6Dz0WjN7GZAVZ9gWEGJxkGwwr4tahatmSMlhGgmuENr3tF8sw4Xcd+/Os4+DZh+Y gKjxXJwGcpFYPXntY2MfoNePQP9Fjk/UliCnUu9E36h8PjOGUgmGBVo6Hw1nMQYhc6BvZq XtC4AAN8HGh1VTBFiP13uTICMjy2eSY= Date: Sat, 25 Apr 2020 18:01:30 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: <461d8d1da4ad0c03e0f3a256e4ff4b77@unrelenting.technology> Subject: Re: Bootable image for Macchatobin Double Shot? To: "Mark Murray" Cc: "Marcel Flores" , freebsd-arm@freebsd.org In-Reply-To: <0532198F-B7DE-46A2-B262-6358EE8370E1@FreeBSD.org> References: <0532198F-B7DE-46A2-B262-6358EE8370E1@FreeBSD.org> <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> X-Spam-Score: 0.90 X-Rspamd-Queue-Id: 498f4F6bW7z4P2T X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=Akahcx6D; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-0.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.870,0]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; NEURAL_HAM_LONG(-0.59)[-0.586,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.38)[ipnet: 2001:41d0::/32(4.91), asn: 16276(2.01), country: FR(0.00)]; 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_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; 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: Sat, 25 Apr 2020 18:01:35 -0000 Okay, so for some reason RELEASE builds don't work properly, what the hec= k.=0AUploaded a working DEBUG build to that URL,=0Asha256:86fba8d239e83d8= 7389a641c90d40137a15604a4b1ec0a7a047cb55f58b1e944=0A=0Anow it's actually = tested, sorry for being too lazy to test :D=0A=0AApril 25, 2020 7:32 PM, = "Mark Murray" wrote:=0A=0A> Can I help in any way? I'= m used to big build (but no good at building on Windows).=0A=0AWindows is= not required, the build is not really big either.=0AEverything builds on= FreeBSD (if you patch a couple things to use gmake instead of make, etc)= .=0A=0AX86_64 now can actually use clang's native PE output btw.=0AThis h= asn't been done for AARCH64 yet, so we still have to rely on the weird "b= uild-ELF-and-repack" system..=0A=0A>>>> Also, have you tried any other PC= Ie cards?=0A>>> =0A>>> Nope - 'fraid not :-(.=0A>>> =0A>>> My intention i= s to use this dual-port NIC until (if?) the on-board NICs are made to wor= k, then I'll=0A>>> use them and then buy a cheapo PCIe video card to make= a proper console I can use with a KVM=0A>>> switch. But I need to get th= e PCI going first :-)=0A=0AThat's a surprising usage for a mcbin by the w= ay :)=0A=0AIt's quite expensive for its capabilities, I only bought it be= cause of pure aarch64 enthusiasm=0Aand desire to have a physical ARM desk= top dev box with a working AMD GPU.=0AIf I needed something as practical = as a console, I would've picked up some cheap Intel thing=0Athat wouldn't= even need an external video card.=0A=0AAlso, a USB3 NIC should be more t= han enough for a console, right?=0AI recommend axge(4) ASIX chips found i= n "Nintendo Switch compatible" dongles.=0AMy mcbin gets ~600 Mbit/s on ip= erf3 tcp with that thing.=0A=0A>> =0A>> I've started an attempt at portin= g the onboard NIC driver last summer:=0A>> https://github.com/myfreeweb/p= epevtwo-kmod=0A> =0A> Oooh! Are you amenable to bribery? ;-)=0A=0AThe lac= k of knowledge is bigger than the lack of motivation here, haha.=0AI'm no= t really familiar with DMA, iflib (or the more basic kernel API for NICs)= , all that stuff.=0AI basically don't know what I'm doing, my driver dev = skills max out at making tiny=0Adrivers for simple things like watchdogs = and fixing stuff in existing drivers. From owner-freebsd-arm@freebsd.org Sat Apr 25 18:20:21 2020 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 286A52BC4B5 for ; Sat, 25 Apr 2020 18:20:21 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 498fTw2QdZz4Q7f for ; Sat, 25 Apr 2020 18:20:20 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-il1-x12e.google.com with SMTP id u189so12695133ilc.4 for ; Sat, 25 Apr 2020 11:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=RrEErGPzyKIaUBs7BgRyl1uMAKF521+U3VM0aBWuNLY=; b=bO/YkemveRJdRlQXutCLqHMxLnqtr5fu9jZzcSaso2LkzJnSp42gzF1tDgDDJijyGy ywuACC70yM5nKJ+NOvh/0Scd9mAngVh+frZeum6nkhTdO0c0gM6tNh/sW/mlFOSE+PIc FMaFRMCkYzHCjZkHDQsHMmJhZMbUJLtlVgW/l6n5DJT3777wQNCXwC0G87EMEOiFQu2x wzX6T4uMAP2fJvHiW56uFJ/OhGuLAl8rSG3ucxlqDmwmyv8KESBT0XakTb/H2MnRMMp2 2F6n6UtdcqaOgEn69puUsREBqBmk4pkJAVhXVr5P7ltV19K2ewk81c/+fJJuY7Nl16np dqzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=RrEErGPzyKIaUBs7BgRyl1uMAKF521+U3VM0aBWuNLY=; b=QuM8Ka9+HzIF17lF5njJwVELIIuCpyJNsAN9SOv8vuOJnit4M0FbOkvkbDGDNzDf/M b5hnX0vvyT/5GotFBwAgvZ1NucXz5Q4UEaw/HXWSssa7LueUUEbQkh5azpWVjroKlZWX Z5CPUivK5/eJx8WxaB/JqUVJSBz2Kladn/C3xmCrHExVc//z8Q6IpCr7TYdr5ElIyMaj YLH6lF98JC4xAED3PxLsUMQ+5Q2yF5Y2i5sq2CBfbggHrEh0X8bZdFNuoKYqzvLoTgyq 1THxxLNv2oaqqPwC86Dx7HHbmuMr+45kDUWZlybBBRvEX8W06GpvUIaFCsKB3Ke17JMq Olrw== X-Gm-Message-State: AGi0Pub4wsPhsDsF8I9mP8GxQDITlnHhTqvOg/AEBn7FIX5WnJPWoOep eA4I8HlLpyMxTuvgzqDI5rN44XH3CCM8EE/wiQIaf2WV2g== X-Google-Smtp-Source: APiQypKpgLRHJD7MnTxtBZtBPf+SjBLC8zY0Xj9Qx/0ZMy/y8zukJEtcPGlLL+zj+v5Fei+18iQ7D4mdmTj4d57FYwc= X-Received: by 2002:a92:a04a:: with SMTP id b10mr13870651ilm.219.1587838818764; Sat, 25 Apr 2020 11:20:18 -0700 (PDT) MIME-Version: 1.0 Reply-To: kamalp@acm.org From: "Kamal R. Prasad" Date: Sat, 25 Apr 2020 23:50:07 +0530 Message-ID: Subject: pl022 controller To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 498fTw2QdZz4Q7f X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=bO/Ykemv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kamalpr@gmail.com designates 2607:f8b0:4864:20::12e as permitted sender) smtp.mailfrom=kamalpr@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; HAS_REPLYTO(0.00)[kamalp@acm.org]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0: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: (-8.63), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), 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]; 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]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[e.2.1.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: Sat, 25 Apr 2020 18:20:21 -0000 hello, has anyone managed to interface a pl022 controller with Infineon 9670 on freebsd-arm? I am having difficulty in reading data from 960 registers. thanks -kamal From owner-freebsd-arm@freebsd.org Sat Apr 25 18:37:19 2020 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 068A72BD006 for ; Sat, 25 Apr 2020 18:37:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.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 498fsT1B3Nz4RgD for ; Sat, 25 Apr 2020 18:37:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .ii5EEIVM1nCdYrM2a9WeNitbtyRJLYyeJHNl4Fy8dTLZQYxFxu66RT95m0y4QY YUfs327._pt0OE6vHtpo2Q4f3X6V2WuTS.p5HyKZp_uCw_ydWnjGTnfMB22xO6Ze9XBZBbm3LTTc cfOOOoXlmZ4GeKN6xVTqo2kEaNR3SMicWbcOV7ttZ2gmqnnBJcFa4HfUCC2xjOTamMuQJYk9SiUg dAKRj63ISLUcT4hbycxDak2hl2c1X6ftT2ugkBHLSNzinxkIuQTauy2GdO0h.fnEFsa71IX3XXnu X4lvQ5NQ2KLhlFi4KxkNmy.YREuMmGNE_6ScJEoQN5iRAENa3sZkMvQYxsMk5ma7jIxtGwuSI1Un G3.XFaedPuwtLePDiUjPF8tHRWsCipIhC1OCkTRK73HnGqFqnIzjJvP2qVDQpqGQcjEnnBhd1T_8 uT5H.fqsJZBxEmTlP1slVikspjKciM_7mCdBelypkQo9SijDn.VtkDDwx7slhOgivHiw9rZJYeyy PQ.jL0AwzGY79iHZpqBdo6wIrF81FNug6HLszlQTyeAbf3_kiV4lLkHyaYMOkUgPzm4hqAy9xLoG zqkOOJrbT4.3QMTqSqQceJYiFEls9K8_IFpLpb_2ytQwZbmuA7b8HVGYyYiYKgUER4RqvwmupIND YF_fJZJyE047aQyKdJtwPbNzquLDSXUXTzw2FyNYW8uQkgrS4M3YGv9FjGY5I9KP_UPgC6pcs5r0 .BDFLCAk2oEZOFuZp6c9QUoiyw3PBSEQ7w98buq9umai3Qe2_MDuN.YbgKJaXpcN.Mdtg8ExrUWt MGANHkJryBZ29oJ.8SJwra6hlXxfnpWRQ.7a9.bunGQ.uWJ0EYcDYFe.Rnku5f1k3IUPS_lHbUUn D53TdB1Y.6zWGSYj4qdsMWNbq.af8isZYeUGw7Zz7uImjaZ1GU2QB7lS.SBthxVzWbGVpeduQOpq r8a2guJgeNdKGXa9fH04YYnpi5tfw62W021EKHvqLnSjXxZTZGPV72qQXt0U5BHpfNGgQ_Q0li5N MUIPBeLQ.5WT4lPlb3UH1_ZjJ7AonLsTn_uRL7VqovRuB0iCDHn0U3fErfMyIYLaIKgQngm7RQ4F M8KR3fyZs5y4.cje.0_9n84JCQyXZ1bUN6pGsDxz8zOcEwynYyXEgKmsWh40hNkAOb0CzxaXbWpr ptX32xyqm6J3OpzBOgF4GsKf3L0NAsPmO_cKHULqFBt0f1JvaIKNtdZgXsSvXTTrmqF1EHV73v93 fcYLj3Zd7Fnp0yMQIDteSN2e0yB1D6jtr92nqMg98aVKYNBBajlGjekVF0ZepYBEsisgjNCJDjbL h4okx_KmTI8R5ADS1luFQ5G_I5SCpAs83QQpwXQY2_z.aU7YCS2LrOGNv8_seZLuCGHP4yblIW_0 6nCEefyEXNRT9.1LsKTfZ Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Apr 2020 18:37:15 +0000 Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 105df8f1376c989f38bcd53cd1fdb621; Sat, 25 Apr 2020 18:37:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Bootable image for Macchatobin Double Shot? From: Mark Millard In-Reply-To: Date: Sat, 25 Apr 2020 11:37:10 -0700 Cc: Mark Murray , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8E7C39A7-624F-4692-8418-11E073F2376D@yahoo.com> References: <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> To: Greg V X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498fsT1B3Nz4RgD X-Spamd-Bar: / X-Spamd-Result: default: False [-0.30 / 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)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.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.37)[-0.370,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.44)[-0.435,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.81), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[83.69.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(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, 25 Apr 2020 18:37:20 -0000 On 2020-Apr-25, at 09:12, greg@unrelenting.technology wrote: > April 25, 2020 6:46 PM, "Mark Murray" wrote: >=20 >>> On 25 Apr 2020, at 16:22, greg@unrelenting.technology wrote: >>>=20 >>> April 25, 2020 5:51 PM, "Mark Murray" wrote: >>>=20 >>> = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image.b= in >>> = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image2.= bin >>>> The second has the same binary bits as the one I downloaded from = the link in my original post. >>>=20 >>> It should work then.. >>>=20 >>> Unless I really screwed something up and *somehow* this is not a = good image - >>> you can check by running (as root): >>>=20 >>> /usr/sbin/acpidump -t -d -o /dev/null | grep -a -C10 PNP0C02 >>=20 >> # /usr/sbin/acpidump -t -d -o /dev/null | grep -a -C10 PNP0C02 >> acpidump: FACS is corrupt >>=20 >>> that should find the PCIe controller in the DSDT table, its = Memory32Fixed resource should >>> contain the address 0xE0000000, NOT 0xE0008000. >>=20 >> Not quite there yet :-) >>=20 >>> What does the pci command in the EFI Shell say? Run `pci 00 00 00 = -i` to get info about a >>> particular device, >>> e.g. = https://gist.github.com/myfreeweb/8b09f1c93ee9572aef01513ba9bf756f >>=20 >> Shell> pci >> Seg Bus Dev Func >> --- --- --- ---- >> 00 00 00 00 =3D=3D> Network Controller - Ethernet controller >> Vendor 8086 Device 1521 Prog Interface 0 >> 00 00 00 01 =3D=3D> Network Controller - Ethernet controller >> Vendor 8086 Device 1521 Prog Interface 0 >> ASSERT [PciHostBridgeDxe] >> = /home/mw/git/uefi-27/edk2-platforms/Silicon/Marvell/Armada7k8k/Library/Arm= ada7k8kPciExpressLib/PciEx >> ressLib.c(78): Address < (0x0 + 1) * 0x00100000 >>=20 >> Looks like something went badly wrong there :-( >=20 > Woah, "/home/mw/git/uefi-27" doesn't look like something that should = appear in one of my builds..! >=20 > I guess flash-image2 is a reupload of an old build from the github = wiki, and flash-image was my build, > but I might have overwritten it with a bad one. *facepalm* Back in 2019-Dec my success was based on getting and using: = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image2.= bin as it was at the time. flash-image.bin did not work back then. (I've not checked if there have since been replacements of the file.) I still have a copy of the flash-image2.bin file sitting on the macOS machine where I downloaded it and: % strings /Users/markmi/Downloads/flash-image2.bin | grep uefi-27 /home/mw/git/uefi-27/MdePkg/Library/BaseLib/String.c /home/mw/git/uefi-27/MdePkg/Library/BasePrintLib/PrintLibInternal.c . . . = /home/mw/git/uefi-27/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/Md= eModulePkg/Core/DxeIplPeim/DxeIpl/DEBUG/AutoGen.c = /home/mw/git/uefi-27/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/Md= eModulePkg/Core/DxeIplPeim/DxeIpl/DEBUG/DxeIpl.dll So it appears that, no matter if the 2019-Dec flash-image2.bin was your build or not, it worked on the DoubleShot (and is still working on the DoubleShot). For identification: % openssl dgst -sha512 /Users/markmi/Downloads/flash-image2.bin SHA512(/Users/markmi/Downloads/flash-image2.bin)=3D = 48c6a9bbd0d5bac7ae107bb5fc3a2413c46bde8d3ec63af6b38ad08189a8917d784fb08eb2= 84b907eb18df1116a2caa7c15d26bfab71a42e62c1b5f2d829fcd4 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Apr 25 19:21:04 2020 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 EED562BE0E4 for ; Sat, 25 Apr 2020 19:21:04 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (gromit.grondar.org [IPv6:2a01:348:e::1]) (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 498gr04nCCz4TR5; Sat, 25 Apr 2020 19:21:04 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from [2a02:8011:300b:42:3d80:3407:95a6:57a5] by gromit.grondar.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jSQMD-0008P0-JP; Sat, 25 Apr 2020 20:20:57 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_9495AE25-3A1A-47B8-9E29-DE27C17BDBA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Bootable image for Macchatobin Double Shot? From: Mark Murray In-Reply-To: <461d8d1da4ad0c03e0f3a256e4ff4b77@unrelenting.technology> Date: Sat, 25 Apr 2020 20:20:56 +0100 Cc: Marcel Flores , freebsd-arm@freebsd.org Message-Id: References: <0532198F-B7DE-46A2-B262-6358EE8370E1@FreeBSD.org> <9F7FB8F8-A29C-4F95-B0BB-CFEFEAFDDD5E@FreeBSD.org> <1039B382-2CA4-4F49-9F95-08BD1386A447@FreeBSD.org> <092721df6b1de3e75820acd32ba1b0e7@unrelenting.technology> <461d8d1da4ad0c03e0f3a256e4ff4b77@unrelenting.technology> To: greg@unrelenting.technology X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 498gr04nCCz4TR5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.73 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.77)[-0.768,0]; ASN(0.00)[asn:39326, ipnet:2a01:348::/32, country:GB]; NEURAL_HAM_LONG(-0.96)[-0.958,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, 25 Apr 2020 19:21:05 -0000 --Apple-Mail=_9495AE25-3A1A-47B8-9E29-DE27C17BDBA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Greg, > On 25 Apr 2020, at 19:01, greg@unrelenting.technology wrote: >=20 > Okay, so for some reason RELEASE builds don't work properly, what the = heck. > Uploaded a working DEBUG build to that URL, > = sha256:86fba8d239e83d87389a641c90d40137a15604a4b1ec0a7a047cb55f58b1e944 It works! It works! Thank you! > now it's actually tested, sorry for being too lazy to test :D No problem. It's very chatty on startup, but that's DEBUG builds for = you. I'm not complaining. > April 25, 2020 7:32 PM, "Mark Murray" wrote: >=20 >> Can I help in any way? I'm used to big build (but no good at building = on Windows). >=20 > Windows is not required, the build is not really big either. > Everything builds on FreeBSD (if you patch a couple things to use = gmake instead of make, etc). I could do that! > X86_64 now can actually use clang's native PE output btw. > This hasn't been done for AARCH64 yet, so we still have to rely on the = weird "build-ELF-and-repack" system.. Cool. =46rom where do I clone? >>>>> Also, have you tried any other PCIe cards? >>>>=20 >>>> Nope - 'fraid not :-(. >>>>=20 >>>> My intention is to use this dual-port NIC until (if?) the on-board = NICs are made to work, then I'll >>>> use them and then buy a cheapo PCIe video card to make a proper = console I can use with a KVM >>>> switch. But I need to get the PCI going first :-) >=20 > That's a surprising usage for a mcbin by the way :) Its going to be a combination build-box (occasionally) and = firewall/gateway (permanently on). I'm retiring an old, power-hungry PC and I want a gateway that can do = double-duty as a background buildibox. "Console" here doesn't imply graphics; just enough to do = basic administration. > It's quite expensive for its capabilities, I only bought it because of = pure aarch64 enthusiasm > and desire to have a physical ARM desktop dev box with a working AMD = GPU. I chose it because of its capabilities :-) the price is acceptable. > If I needed something as practical as a console, I would've picked up = some cheap Intel thing > that wouldn't even need an external video card. I also have RPIs, WandBoards and so on, but these aren't much good for = building. Pretty, though! > Also, a USB3 NIC should be more than enough for a console, right? > I recommend axge(4) ASIX chips found in "Nintendo Switch compatible" = dongles. > My mcbin gets ~600 Mbit/s on iperf3 tcp with that thing. Naah. It will be routing DSL broadband for a living. >>>=20 >>> I've started an attempt at porting the onboard NIC driver last = summer: >>> https://github.com/myfreeweb/pepevtwo-kmod >>=20 >> Oooh! Are you amenable to bribery? ;-) >=20 > The lack of knowledge is bigger than the lack of motivation here, = haha. > I'm not really familiar with DMA, iflib (or the more basic kernel API = for NICs), all that stuff. > I basically don't know what I'm doing, my driver dev skills max out at = making tiny > drivers for simple things like watchdogs and fixing stuff in existing = drivers. Aah, OK. I have zero knowledge of that myself. :-( M -- --Apple-Mail=_9495AE25-3A1A-47B8-9E29-DE27C17BDBA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAl6kjZgACgkQQlsJDh9C UqDhTgf/dN2UwD4Ww8QNb+vwEKiFDBEKW2Try+jeJS1KyQc14NGOKFAIPvqmQR7t 7zViyaYz8CgQCWYj3P3oQ4+oETtJy01BEqkXxHO8jW2bp2QRwu1Pe4AxfXkIOg+9 fMUxAESfd37m3K2MhnxX5KEtY1Ege6Bf0xjLfuSjJkKXYZtds5JYPLG6OUKJsGUa trsIdVjR/hd6YMWMGujP4ondfK9c8ZKpuebgajyrreelTZ4pj1VRurTEgSSFR0tA wtF/B3b0GsIrhGqQkJcn70Ag4wam0G+NSzWLr+Vms+YkpZZ+4CC+YKBlwUAQ+01s iFwj0HGcaf15lnHrjB4HAK0RlSh6Qw== =g5X0 -----END PGP SIGNATURE----- --Apple-Mail=_9495AE25-3A1A-47B8-9E29-DE27C17BDBA8-- From owner-freebsd-arm@freebsd.org Sat Apr 25 22:27:04 2020 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 D40122C2CF2 for ; Sat, 25 Apr 2020 22:27:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 498lyb4QLbz4f9h for ; Sat, 25 Apr 2020 22:27:03 +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 03PMQw8E011135 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 25 Apr 2020 15:26:58 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 03PMQwBK011134; Sat, 25 Apr 2020 15:26:58 -0700 (PDT) (envelope-from fbsd) Date: Sat, 25 Apr 2020 15:26:57 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: Booting from USB on RPI3 Message-ID: <20200425222657.GA11076@www.zefox.net> References: <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> <20200424195953.GA6707@www.zefox.net> <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> <20200425001743.GA7044@www.zefox.net> <5A943B45-FE58-452D-BBC5-534756782276@yahoo.com> <20200425030008.GB7044@www.zefox.net> <592BD226-145D-4A89-81E4-257FB20624FE@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <592BD226-145D-4A89-81E4-257FB20624FE@yahoo.com> X-Rspamd-Queue-Id: 498lyb4QLbz4f9h 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 [1.99 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.22), ipnet: 50.1.16.0/20(0.11), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.11)[0.107,0]; NEURAL_HAM_LONG(-0.06)[-0.065,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(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: Sat, 25 Apr 2020 22:27:04 -0000 On Fri, Apr 24, 2020 at 09:32:13PM -0700, Mark Millard wrote: [much snippage] > > https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=58151 > > reports relative to what causes the rainbow screen > on the RPi3*'s (and when). Code from start.elf is what draws > the rainbow screen (as part of testing the GPU). start.elf > comes after bootcode.bin . > I looked at that page but didn't read far enough 8-( It's possible my Pi3 requires a microSD card, but the "no rainbow screen" doesn't prove anything. > Here is the sequencing documented that leads to the rainbow > screen: > > QUOTE > . . . uses its MMC hardware to attempt to read a file from a MMC compatible device. On the Pi, this is the SD card; the file should be on a FAT16 or FAT32-compatible filing system, and is called bootcode.bin. At this point, the ARM CPU is still in reset, so the contents of bootcode.bin are executed by the dedicated processor of the GPU: this code has more smarts, and can read the next file called start.elf, which in turn reads and interprets config.txt. It configures things like memory and Video/HDMI modes, console frame buffers, tests the GPU (resulting in the "rainbow screen"), and then handles the loading and configuring of the Linux Kernel (addresses, device tree, uart/console baud rates and suchlike). Only after this is the ARM CPU started, to execute the kernel code. > END QUOTE > > (For FreeBSD that "kernel code" above is not the FreeBSD > kernel yet: more stages before reaching that point.) > > Early on the LEDs are what needs to be looked at: > > QUOTE > Error ACT LED patterns (for RPI up-to but not including RPI4 > While booting, the ACT LED should blink in an irregular pattern, indicating that it is reading from the card. If it starts blinking in a regular, Morse code-like pattern, then it is signalling an error. > This Pi3 blinks once, very briefly. Hard to catch in the act. > If it blinks just once, it could be that you have a Raspberry Pi with SDRAM from Micron. If the processor has a logo showing an M with an orbit around it, then using the latest software should solve your problem. Also make sure you are using a 4GB SD card, as a 2GB won't work in this particular case. > > These are the other patterns that the ACT LED might show during a failed boot, together with their meanings (the below blink codes are NOT valid for a RPI4, read the RPI4 section for ACT LED flash messages!): > > * 3 flashes: start.elf not found > * 4 flashes: start.elf not launch-able (corrupt) See below: (not valid for RPI4! On an RPI4 four flashes means no boot code found!) > * 7 flashes: kernel.img not found > * 8 flashes: SDRAM not recognized. You need newer bootcode.bin/start.elf firmware, or your SDRAM is damaged > END QUOTE > > (Same URL.) > > >>> I gather the Raspberry Pi Foundation didn't more widely > >>> publicise the boot-from-usb feature because it didn't work > >>> with a too-large fraction of USB storage devices. > >> > >> Which leads to an alternate experiment: a different USB > >> "drive", one without the long wait. > >> > >> Technically this could be a USB microsd card reader > >> with the media you can boot from the microsd card > >> slot: That might well prove that you can boot without > >> use of the microsd card slot so long as the USB drive > >> is compatibile. If yes: Then it becomes a case of > >> selecting an appropriate USB drive and getting it set > >> up. > >> Sticking the existing microSD in a USB adapter and trying to boot it is easy and worth a try, if only to debunk my claim that this particular Pi3 _requires_ a microSD card to start. > > > > Is there some larger question that I'm not recognizing? > > I've tried a usb flash drive with FreeBSD on it a couple > > of times with no microSD. > > I did not remember that you had done so. That would be > approximately what I was suggesting (depending on what > materials were on the USB flash drive). > Don't think I mentioned it. The experiment was flawed and done without sufficient care, the results too confusing to recount. I was looking at the serial console and screen, not the LEDs. When it didn't respond I just accepted the Pi needed a card. The larger question is now raised 8-) The machine is still chewing away at buildworld. No "indefinite wait" warnings, but it's panic'd twice with panic: non-current pmap [long hex number] So far buildworld has picked up where it left off, but there's still plenty of time for things to go wrong. At the next convenient pause I'll stick the microSD card in a USB adapter and watch the LEDs, then look at the serial console. Thanks _very_ much for writing! bob prohaska